WO2023014085A1 - 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법 - Google Patents

포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법 Download PDF

Info

Publication number
WO2023014085A1
WO2023014085A1 PCT/KR2022/011485 KR2022011485W WO2023014085A1 WO 2023014085 A1 WO2023014085 A1 WO 2023014085A1 KR 2022011485 W KR2022011485 W KR 2022011485W WO 2023014085 A1 WO2023014085 A1 WO 2023014085A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
point cloud
information
user terminal
pcc
Prior art date
Application number
PCT/KR2022/011485
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 엘지전자 주식회사
Priority to EP22853461.6A priority Critical patent/EP4383735A1/en
Publication of WO2023014085A1 publication Critical patent/WO2023014085A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/6437—Real-time Transport Protocol [RTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T9/00—Image coding
    • 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/10—Architectures or entities
    • H04L65/1045—Proxies, e.g. for session initiation protocol [SIP]
    • 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
    • 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/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • 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
    • H04L65/403—Arrangements for multi-party communication, e.g. for conferences
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/816—Monomedia components thereof involving special video data, e.g 3D video
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/85403—Content authoring by describing the content as an MPEG-21 Digital Item

Definitions

  • Embodiments relate to a method and apparatus for processing point cloud content.
  • the point cloud content is content expressed as a point cloud, which is a set of points belonging to a coordinate system representing a 3D space.
  • Point cloud content can express three-dimensional media, and provides various services such as VR (Virtual Reality), AR (Augmented Reality), MR (Mixed Reality), and autonomous driving service.
  • VR Virtual Reality
  • AR Augmented Reality
  • MR Magnetic Reality
  • autonomous driving service used to provide VR technology provides only CG (Computer Graphic) images of objects or backgrounds in the real world
  • AR technology provides CG images created virtually on top of images of real objects
  • MR technology mixes and combines virtual objects in the real world It is a computer graphics technology provided by ordering. All of the aforementioned VR, AR, MR, and the like are simply referred to as XR (extended reality) technology.
  • XR extended reality
  • Embodiments provide an apparatus and method for efficiently processing point cloud data.
  • Embodiments provide a point cloud data processing method and apparatus for solving latency and encoding/decoding complexity.
  • a point cloud service providing method includes the steps of performing a call connection for a call between a first user terminal and a second user terminal, and when the call connection is performed, the second user terminal has at least one RTP (Real and transmitting point cloud data to the first user terminal using a Time Transport Protocol (Time Transport Protocol) packet, wherein the point cloud data is G-PCC data compressed based on Geometry-based Point Cloud Compression (G-PCC).
  • RTP Real and transmitting point cloud data to the first user terminal using a Time Transport Protocol (Time Transport Protocol) packet, wherein the point cloud data is G-PCC data compressed based on Geometry-based Point Cloud Compression (G-PCC).
  • the header of the at least one RTP packet may include identification information for identifying the G-PCC data.
  • the header of the at least one RTP packet further includes information indicating a type of frame including the point cloud data.
  • the header of the at least one RTP packet further includes profile information of the point cloud data.
  • the performing of the call connection includes transmitting an SDP offer message from the first user terminal to the second user terminal, and transmitting an SDP answer message from the second user terminal to the first user terminal. Doing is an embodiment.
  • the SDP offer message includes profile information of the point cloud data.
  • the point cloud data is V-PCC data compressed based on Video-based Point Cloud Compression (V-PCC), and the identification information determines whether the point cloud data included in the at least one RTP packet is the G-PCC data. - Identifying whether it is PCC data is an embodiment.
  • An apparatus for providing a point cloud service includes a first user terminal, a second user terminal, and at least one edge enabler positioned between the first user terminal and the second user terminal to perform an initialization process. and, when a call connection is performed for a call between the first user terminal and the second user terminal, the second user terminal transmits point cloud data to the first user terminal using at least one Real Time Transport Protocol (RTP) packet.
  • RTP Real Time Transport Protocol
  • the point cloud data is G-PCC data compressed based on Geometry-based Point Cloud Compression (G-PCC), and the header of the at least one RTP packet identifies the G-PCC data It may include identification information for
  • the header of the at least one RTP packet further includes information indicating a type of frame including the point cloud data.
  • the header of the at least one RTP packet further includes profile information of the point cloud data.
  • an SDP offer message is transmitted from the first user terminal to the second user terminal, and an SDP answer message is transmitted from the second user terminal to the first user terminal. Transmitting is an embodiment.
  • the SDP offer message includes profile information of the point cloud data.
  • the point cloud data is V-PCC data compressed based on Video-based Point Cloud Compression (V-PCC), and the identification information determines whether the point cloud data included in the at least one RTP packet is the G-PCC data. - Identifying whether it is PCC data is an embodiment.
  • the first user terminal performs an initialization process in which a discovery request is made to the at least one edge enabler and a discovery response is provided from the edge enabler.
  • the second user terminal performs an initialization process in which a discovery request is made to the at least one edge enabler and a discovery response is received from the edge enabler.
  • an edge enabler performing a discovery request/response with the first user terminal is different from an edge enabler performing a discovery request/response with the second user terminal.
  • an edge enabler performing a discovery request/response with the first user terminal and an edge enabler performing a discovery request/response with the second user terminal are the same.
  • Apparatus and method according to embodiments may process point cloud data with high efficiency.
  • Devices and methods according to embodiments may provide a point cloud service of high quality.
  • Devices and methods according to embodiments may provide point cloud content for providing general-purpose services such as XR services and autonomous driving services.
  • FIG. 1 is a block diagram illustrating an example of a communication system 1 according to embodiments.
  • FIG. 2 illustrates a block configuration diagram of a wireless communication system to which methods according to embodiments may be applied.
  • 3 shows an example of a 3GPP signal transmission/reception method.
  • FIG. 4 shows an example in which a physical channel is mapped into a self-contained slot according to embodiments.
  • FIG. 5 shows an example of an ACK/NACK transmission process and a PUSCH transmission process.
  • FIG. 6 shows a downlink structure for media transmission of a 5GMS service according to embodiments.
  • FIG. 7 shows an example of a FLUS structure for Uplink service.
  • FIG. 8 shows a point cloud data processing system according to embodiments.
  • FIG 9 shows an example of a point cloud data processing device according to embodiments.
  • FIG. 10 shows an example of a point cloud data processing device according to embodiments.
  • FIG. 11 shows an example of a point cloud data processing device according to embodiments.
  • FIG. 12 shows an example of a point cloud data processing device according to embodiments.
  • FIG. 13 shows an example of a point cloud data processing device according to embodiments.
  • FIG. 14 shows an example of a point cloud data processing device according to embodiments.
  • 15 shows a transmission structure for a UE on a visited network according to embodiments.
  • 16 illustrates a call connection between UEs according to embodiments.
  • FIG 17 shows an apparatus for transmitting and receiving point cloud data according to embodiments.
  • FIG. 18 shows an architecture for XR communication on a 5G network according to embodiments.
  • Figure 19 shows a structure for XR communication according to embodiments
  • 20 illustrates a protocol stack for XR interactive service on 3GPP 5G according to embodiments.
  • 21 illustrates point-to-point XR videoconferencing according to embodiments.
  • FIG. 22 shows an XR videoconferencing extension according to embodiments.
  • Figure 23 shows XR videoconferencing extensions according to embodiments.
  • FIG. 24 shows an example of a Point Cloud Encoder according to embodiments according to embodiments.
  • 24 is a flowchart illustrating an example of a process of creating a basic telephone network for forming a 1:1 conversation.
  • 25 is a flowchart illustrating another example of a process of creating a basic telephone network for forming a 1:1 conversation.
  • 26 is a detailed block diagram of an IM subsystem according to embodiments.
  • FIG. 27 is a flowchart illustrating an example of a service registration process according to embodiments.
  • FIG. 28 is a flowchart illustrating another example of a service registration process according to embodiments.
  • 29 is a diagram showing an example of a payload type allocated to a payload type (PT) field in a header of an RTP packet according to embodiments.
  • PT payload type
  • FIG. 30 is a diagram showing an example of a minimum extension structure of an RTP packet for transmission of G-PCC data according to embodiments.
  • 31 is a diagram showing an example of a profile and a length value defined before extension according to embodiments.
  • 32 is a diagram showing an example of an extension header of an RTP packet according to embodiments.
  • 33 is a diagram showing an example of values allocated to an SPS_Flag field according to embodiments.
  • SPS sequence parameter set
  • 35 is a diagram showing an embodiment of a syntax structure of a geometry parameter set (geometry_parameter_set_RTP( )) (GPS) according to embodiments.
  • FIG. 36 is a diagram showing an embodiment of a syntax structure of an attribute parameter set (attribute_parameter_set_RTP( )) (APS) according to embodiments.
  • 38 is a diagram illustrating an example of transmitting a 200 OK message in response to the same request according to embodiments.
  • FIG. 39(a) shows an example of an SDP offer message according to embodiments
  • FIG. 39(b) shows an example of an SDP answer message.
  • 40 is a diagram showing an example of an SDP offer message according to embodiments.
  • FIG. 1 is a block diagram illustrating an example of a communication system 1 according to embodiments.
  • a communication system 1 includes wireless devices 100a to 100f, a base station (BS) 200 and a network 300 .
  • a base station (BS) 200 includes a fixed station, a Node B, an evolved-NodeB (eNB), a Next Generation NodeB (gNB), a base transceiver system (BTS), an access point (AP) ), a network or a 5G (5th generation) network node, an Artificial Intelligence (AI) system, a road side unit (RSU), a robot, an Augmented Reality/Virtual Reality (AR/VR) system, a server, and the like.
  • AI Artificial Intelligence
  • RSU road side unit
  • AR/VR Augmented Reality/Virtual Reality
  • a wireless device refers to a device that communicates with a base station and / or other wireless devices using a radio access technology (eg, 5G New RAT (NR), Long Term Evolution (LTE)), It may be called a communication/wireless/5G device or a user equipment (UE).
  • a radio access technology eg, 5G New RAT (NR), Long Term Evolution (LTE)
  • NR 5G New RAT
  • LTE Long Term Evolution
  • UE user equipment
  • the wireless device is not limited to the above embodiments, and includes a robot 100a, a vehicle 100b-1 and 100b-2, an XR (eXtended Reality) device 100c, and a hand-held device 100d.
  • home appliances 100e Internet of Thing (IoT) devices 100f
  • AI devices/servers 400 e.g., Internet of Thing (IoT) devices 100f, and AI devices/servers 400.
  • the XR device 100c represents a device that provides XR content (eg, Augmented Reality (AR)/Virtual Reality (VR)/Mixed Reality (MR) content).
  • an XR device may be referred to as an AR/VR/MR device.
  • the XR device 100c is a Head-Mounted Device (HMD), a Head-Up Display (HUD) installed in a vehicle, a television, a smartphone, a computer, a wearable device, a home appliance, and a digital signage. , can be implemented in the form of vehicles, robots, etc.
  • HMD Head-Mounted Device
  • HUD Head-Up Display
  • the vehicles 100b-1 and 100b-2 are vehicles equipped with a wireless communication function, self-driving vehicles, vehicles capable of performing inter-vehicle communication, UAVs (Unmanned Aerial Vehicles) (eg, drones), and the like.
  • the mobile device 100d may include a smart phone, a smart pad, a wearable device (eg, a smart watch, a smart glass), a computer (eg, a laptop computer), and the like.
  • the home appliance 100e may include a TV, a refrigerator, a washing machine, and the like.
  • the IoT device 100f may include a sensor, a smart meter, and the like.
  • the wireless devices 100a to 100f may be connected to the network 300 through the base station 200 .
  • the wireless devices 100a to 100f may be connected to the AI server 400 through the network 300 .
  • the network 300 may be configured using a 3G network, a 4G (eg, LTE) network, a 5G (eg, NR) network, or a 6G network.
  • the wireless devices 100a to 100f may communicate with each other through the base station 200/network 300, but may also communicate directly (eg, sidelink communication) without going through the base station/network.
  • the wireless devices 100a to 100f/base station 200 and base station 200/base station 200 may transmit and receive radio signals through wireless communication/connection 150a, 150b, and 150c.
  • Wireless communication/connection includes uplink/downlink communication (150a), which is communication between wireless devices and base stations, sidelink communication (150b) (or D2D communication), which is communication between wireless devices, and communication between base stations (150c). ) (e.g. relay, integrated access backhaul (IAB) and various radio access technologies (eg, 5G, NR, etc.).
  • IAB integrated access backhaul
  • the wireless devices 100a to 100f and the base station 200 according to the embodiments Signals can be transmitted/received through various physical channels of the wireless communication/connection 150a, 150b, and 150c.
  • various types of transmission/reception of radio signals can be performed.
  • At least one or more of a configuration information setting process, various signal processing processes (eg, channel encoding/decoding, modulation/demodulation, resource mapping/demapping, etc.), resource allocation process, etc. may be performed.
  • a user terminal (eg, an XR device (eg, the XR device 100c of FIG. 1 )) according to embodiments provides XR content such as audio/video data, voice data, and surrounding information data. Specific information including XR data (or AR/VR data) required for this may be transmitted to a base station or other user terminal through a network.
  • a user terminal may perform an initial access operation to a network. During the initial access process, the user terminal may acquire cell search and system information for acquiring downlink (DL) synchronization.
  • Downlink represents communication from a base station (eg, BS) or a transmitter that is part of the base station to a user equipment (UE) or a receiver included in the user equipment.
  • a user terminal may perform a random access operation for accessing a network.
  • the user terminal may transmit a preamble for uplink (UL) synchronization acquisition or UL data transmission, and may perform a random access response reception operation.
  • Uplink represents communication from a UE or a transmitting unit that is part of a UE to a BS or a receiving unit that is part of a BS.
  • the UE may perform an UL Grant reception operation to transmit specific information to the BS.
  • the uplink grant is for receiving time/frequency resource scheduling information for uplink data transmission.
  • a user terminal may transmit specific information to a base station through a 5G network based on a UL grant.
  • a base station may perform XR content processing.
  • the user terminal may perform a downlink grant (DL Grant) reception operation to receive a response to specific information through the 5G network.
  • DL Grant downlink grant
  • a downlink grant represents receiving time/frequency resource scheduling information to receive downlink data.
  • the user terminal may receive a response to specific information through the network based on the downlink grant.
  • FIG. 2 illustrates a block configuration diagram of a wireless communication system to which methods according to embodiments may be applied.
  • the wireless communication system includes a first communication device 910 and/or a second communication device 920 .
  • 'A and/or B' may be interpreted as having the same meaning as 'including at least one of A or B'.
  • the first communication device may represent a BS and the second communication device may represent a UE (or the first communication device may represent a UE and the second communication device may represent a BS).
  • the first communication device and the second communication device include processors 911 and 921, memories 914 and 924, one or more Tx/Rx RF modules (radio frequency modules 915 and 925), Tx processors 912 and 922, and Rx processors 913 and 923. , antennas 916 and 926. Tx/Rx modules are also called transceivers.
  • the processor 911 may perform a signal processing function of a layer higher than the physical layer (eg, layer 2 (L2)). For example, in the Downlink, or DL (communication from a first communication device to a second communication device), higher layer packets from the core network are provided to the processor 911 .
  • L2 layer 2
  • the processor 911 provides multiplexing between logical channels and transport channels and radio resource allocation to the second communication device 920, and is responsible for signaling to the second communication device do.
  • the first communication device 910 and the second communication device 920 are processors (eg, audio/video encoder, audio/video decoder, etc. ) may further include.
  • the processor according to the embodiments processes video data corresponding to various video standards (eg, video standards such as MPEG2, AVC, HEVC, and VVC) and various audio standards (eg, MPEG 1 Layer 2 Audio, AC3, and HE).
  • video standards eg, video standards such as MPEG2, AVC, HEVC, and VVC
  • various audio standards eg, MPEG 1 Layer 2 Audio, AC3, and HE
  • -Audio data processed by audio standards such as AAC, E-AC-3, HE-AAC, NGA, etc.
  • the processor may process XR data or XR media data processed using Video-based Point Cloud Compression (V-PCC) or Geometry-based Point Cloud Compression (G-PCC).
  • a processor processing higher layer data may be implemented as a single processor or a single chip by being combined with the processors 911 and 921 .
  • a processor processing upper layer data may be implemented as a separate chip or a separate processor from the processors 911 and 921 .
  • the transmit (TX) processor 912 implements various signal processing functions for the L1 layer (ie, physical layer).
  • the signal processing function of the physical layer can facilitate forward error correction (FEC) in the second communication device.
  • the signal processing function of the physical layer includes coding and interleaving.
  • a signal that has undergone encoding and interleaving is modulated into complex valued modulation symbols through scrambling and modulation.
  • BPSK, QPSK, 16QAM, 64QAM, 246QAM, etc. may be used for modulation depending on the channel.
  • Complex-valued modulation symbols (hereafter referred to as modulation symbols) are divided into parallel streams, each stream mapped to an OFDM subcarrier, multiplexed with a reference signal in the time and/or frequency domain, and put together using IFFT. Combined to create a physical channel carrying a stream of time domain OFDM symbols.
  • OFDM symbol streams are spatially precoded to create multiple spatial streams.
  • Each spatial stream may be provided to a different antenna 916 via a separate Tx/Rx module (or transceiver 915).
  • Each Tx/Rx module can frequency upconvert each spatial stream to an RF carrier for transmission.
  • each Tx/Rx module (or transceiver) 925 receives a signal of an RF carrier through each antenna 926 of each Tx/Rx module.
  • Each Tx/Rx module restores the signal of the RF carrier to a baseband signal and provides it to the receive (RX) processor 923.
  • the RX processor implements various signal processing functions of L1 (ie, physical layer).
  • the RX processor may perform spatial processing on the information to recover any spatial stream destined for the second communication device.
  • multiple spatial streams are destined for the second communication device, they may be combined into a single OFDMA symbol stream by multiple RX processors.
  • the RX processor converts the OFDM symbol stream, which is a time domain signal, into a frequency domain signal using a Fast Fourier Transform (FFT).
  • FFT Fast Fourier Transform
  • the frequency domain signal includes a separate OFDM symbol stream for each subcarrier of the OFDM signal.
  • the modulation symbols and reference signal on each subcarrier are recovered and demodulated by determining the most probable signal constellation points transmitted by the first communication device. These soft decisions may be based on channel estimate values.
  • the soft decisions are decoded and deinterleaved to recover the data and control signals originally transmitted by the first communication device on the physical channel. Corresponding data and control signals are provided to processor 921 .
  • the UL (communication from the second communication device to the first communication device) is handled in the first communication device 910 in a manner similar to that described with respect to the receiver function in the second communication device 920 .
  • Each Tx/Rx module 925 receives a signal through a respective antenna 926.
  • Each Tx/Rx module provides an RF carrier and information to the RX processor 923.
  • Processor 921 may be associated with memory 924 that stores program codes and data. Memory may be referred to as a computer readable medium.
  • FIGS. 3 to 5 show examples of one or more signal processing methods and/or operations for a physical L1 layer (ie, physical layer). Examples disclosed in FIGS. 3 to 5 may be the same as or similar to examples of signal processing methods and/or operations performed by the transmit (TX) processor 912 and/or the transmit (TX) processor 922 described in FIG. 2 . there is.
  • 3 shows an example of a 3GPP signal transmission/reception method.
  • the UE when the UE is powered on or enters a new cell, it may perform an initial cell search task such as synchronizing with a BS (S201).
  • the UE may synchronize with the BS by receiving a primary synchronization channel (P-SCH) and a secondary synchronization channel (S-SCH) from the BS and obtain information such as a cell ID. .
  • the P-SCH and the S-SCH may be referred to as a primary synchronization signal (PSS) and a secondary synchronization signal (SSS), respectively.
  • the UE may obtain intra-cell broadcast information by receiving a physical broadcast channel (PBCH) from the BS. Meanwhile, the UE may check the downlink channel state by receiving a downlink reference signal (DL RS) in the initial cell search step.
  • PBCH physical broadcast channel
  • DL RS downlink reference signal
  • the UE can obtain more detailed system information by receiving the PDSCH according to the PDCCH and the information carried on the PDCCH (S202).
  • the UE may perform a random access procedure for the BS (steps S203 to S206).
  • the UE may transmit a specific sequence as a preamble through PRACH (S203 and S205) and receive a random access response (RAR) message for the preamble through a PDCCH and a corresponding PDSCH (S204 and S205).
  • RAR random access response
  • a contention resolution procedure may be additionally performed.
  • the UE may perform PDCCH/PDSCH reception (S207) and PUSCH/PUCCH transmission (S208) as a general uplink/downlink signal transmission process.
  • the UE receives DCI through the PDCCH.
  • the UE monitors a set of PDCCH candidates at monitoring occasions configured in one or more control element sets (CORESETs) on the serving cell according to corresponding search space configurations.
  • the set of PDCCH candidates to be monitored by the UE may be defined in terms of search space sets.
  • a search space set according to embodiments may be a common search space set or a UE-specific search space set.
  • a CORESET consists of a set of (physical) resource blocks having a time duration of 1 to 3 OFDM symbols.
  • the network may configure the UE to have multiple CORESETs.
  • the UE monitors PDCCH candidates in one or more search space sets.
  • monitoring means attempting to decode PDCCH candidate(s) within the search space. If the UE succeeds in decoding one of the PDCCH candidates in the search space, the UE determines that it has detected a PDCCH in the corresponding PDCCH candidate, and can perform PDSCH reception or PUSCH transmission based on the DCI in the detected PDCCH.
  • PDCCH may be used to schedule DL transmissions on PDSCH and UL transmissions on PUSCH.
  • the DCI on the PDCCH is a downlink assignment (i.e., DL grant) that includes at least modulation and coding format and resource allocation information related to the downlink shared channel, or related to the uplink shared channel. , may include a UL grant including modulation and coding formats and resource allocation information.
  • the UE can acquire DL synchronization by detecting the SSB.
  • the UE can identify the structure of the SSB burst set based on the detected SSB (time) index (SSB index, SSBI), and can detect the symbol/slot/half-frame boundary accordingly.
  • the frame/half-frame number to which the detected SSB belongs may be identified using system frame number (SFN) information and half-frame indication information.
  • SFN system frame number
  • the UE may obtain a 10-bit SFN for a frame to which the PBCH belongs from the PBCH.
  • the UE may acquire 1-bit half-frame indication information to determine whether the corresponding PBCH belongs to the first half-frame or the second half-frame among frames.
  • the half-frame indication bit value when the half-frame indication bit value is 0, it indicates that the SSB to which the PBCH belongs belongs to the first half-frame within the frame. If the half-frame indication bit value is 1, it indicates that the SSB to which the PBCH belongs belongs to the second half-frame within the frame.
  • the UE may acquire the SSBI of the SSB to which the PBCH belongs based on the DMRS sequence and the PBCH payload carried by the PBCH.
  • Table 1 below shows a random access procedure of a UE.
  • Step 1 PRACH preamble in UL * initial beam acquisition
  • Step 4 Contention resolution on DL * Temporary C-RNTI on PDCCH for initial access
  • the random access process is used for a variety of purposes.
  • the random access procedure may be used for network initial access, handover, and UE-triggered UL data transmission.
  • the UE may acquire UL synchronization and UL transmission resources through a random access procedure.
  • the random access process is divided into a contention-based random access process and a contention-free random access process.
  • FIG. 4 shows an example in which a physical channel is mapped into a self-contained slot according to embodiments.
  • PDCCH may be transmitted in the DL control region, and PDSCH may be transmitted in the DL data region.
  • PUCCH may be transmitted in the UL control region, and PUSCH may be transmitted in the UL data region.
  • the GP provides a time gap between the base station and the UE in a process of switching from a transmission mode to a reception mode or a process of switching from a reception mode to a transmission mode. Some symbols at the time of transition from DL to UL within a subframe may be set as GPs.
  • a PDCCH carries Downlink Control Information (DCI).
  • DCI Downlink Control Information
  • PCCCH includes transmission format and resource allocation of downlink shared channel (DL-SCH), resource allocation information for uplink shared channel (UL-SCH), paging information for paging channel (PCH), It carries system information on DL-SCH, resource allocation information for higher layer control messages such as random access response transmitted on PDSCH, transmission power control command, and activation/cancellation of Configured Scheduling (CS).
  • the DCI includes a cyclic redundancy check (CRC), and the CRC is masked/scrambled with various identifiers (eg, Radio Network Temporary Identifier, RNTI) according to the owner or usage of the PDCCH.
  • CRC cyclic redundancy check
  • the CRC is masked with a terminal identifier (eg, Cell-RNTI, C-RNTI). If the PDCCH is for paging, the CRC is masked with Paging-RNTI (P-RNTI). If the PDCCH is related to system information (eg, System Information Block, SIB), the CRC is masked with System Information RNTI (SI-RNTI). If the PDCCH is for a random access response, the CRC is masked with RA-RNTI (Random Access-RNTI).
  • a terminal identifier eg, Cell-RNTI, C-RNTI
  • P-RNTI Paging-RNTI
  • SIB System Information Block
  • SI-RNTI System Information RNTI
  • RA-RNTI Random Access-RNTI
  • the PDCCH is composed of 1, 2, 4, 8, and 16 Control Channel Elements (CCEs) according to Aggregation Levels (ALs).
  • CCE is a logical allocation unit used to provide a PDCCH of a predetermined code rate according to a radio channel state.
  • CCE consists of six REGs (Resource Element Groups).
  • REG is defined as one OFDM symbol and one (P)RB.
  • the PDCCH is transmitted through a CORESET (Control Resource Set).
  • CORESET is defined as a set of REGs with a given numonology (eg SCS, CP length, etc.).
  • a plurality of CORESETs for one UE may overlap in the time/frequency domain.
  • CORESET may be set through system information (eg, Master Information Block, MIB) or UE-specific upper layer (eg, Radio Resource Control, RRC, layer) signaling. Specifically, the number of RBs and the number of OFDM symbols constituting the CORESET (up to 3) may be set by higher layer signaling.
  • MIB Master Information Block
  • RRC Radio Resource Control
  • the UE monitors PDCCH candidates.
  • the PDCCH candidate indicates CCE(s) that the UE should monitor for PDCCH detection.
  • Each PDCCH candidate is defined as 1, 2, 4, 8, or 16 CCEs according to AL.
  • Monitoring includes (blind) decoding of PDCCH candidates.
  • a set of PDCCH candidates monitored by the UE is defined as a PDCCH search space (Search Space, SS).
  • the search space includes a Common Search Space (CSS) or a UE-specific search space (USS).
  • the UE may obtain DCI by monitoring PDCCH candidates in one or more search spaces configured by MIB or higher layer signaling.
  • Each CORESET is associated with one or more search spaces, and each search space is associated with one COREST.
  • a search space can be defined based on the following parameters.
  • controlResourceSetId Indicates a CORESET related to the search space
  • An opportunity (eg, time / frequency resource) to monitor PDCCH candidates is defined as a PDCCH (monitoring) opportunity.
  • PDCCH (monitoring) opportunity One or more PDCCH (monitoring) opportunities may be configured within a slot.
  • UCI Uplink Control Information
  • -HARQ (Hybrid Automatic Repeat request)-ACK (Acknowledgement): This is a response to a downlink data packet (eg, codeword) on the PDSCH. Indicates whether a downlink data packet has been successfully received. In response to a single codeword, 1 bit of HARQ-ACK may be transmitted, and 2 bits of HARQ-ACK may be transmitted in response to two codewords.
  • HARQ-ACK responses include positive ACK (simply, ACK), negative ACK (NACK), DTX or NACK/DTX.
  • HARQ-ACK is mixed with HARQ ACK/NACK and ACK/NACK.
  • MIMO-related feedback information includes a Rank Indicator (RI) and a Precoding Matrix Indicator (PMI).
  • PUSCH carries uplink data (eg, UL-SCH transport block, UL-SCH TB) and / or uplink control information (UCI), and CP-OFDM (Cyclic Prefix - Orthogonal Frequency Division Multiplexing) waveform or It is transmitted based on a DFT-s-OFDM (Discrete Fourier Transform - spread - Orthogonal Frequency Division Multiplexing) waveform.
  • DFT-s-OFDM Discrete Fourier Transform - spread - Orthogonal Frequency Division Multiplexing
  • the terminal when transform precoding is impossible (eg, transform precoding is disabled), the terminal transmits a PUSCH based on a CP-OFDM waveform, and when transform precoding is possible (eg, transform precoding is enabled), the terminal transmits a CP-OFDM waveform.
  • the PUSCH may be transmitted based on an OFDM waveform or a DFT-s-OFDM waveform.
  • PUSCH transmission is dynamically scheduled by the UL grant in DCI or semi-static based on higher layer (eg, RRC) signaling (and/or Layer 1 (L1) signaling (eg, PDCCH)) It can be scheduled (configured grant).
  • PUSCH transmission may be performed on a codebook basis or a non-codebook basis.
  • FIG. 5 shows an example of an ACK/NACK transmission process and a PUSCH transmission process.
  • 5(a) shows an example of an ACK/NACK transmission process.
  • the UE may detect the PDCCH in slot #n.
  • the PDCCH includes downlink scheduling information (eg, DCI formats 1_0 and 1_1), and the PDCCH indicates a DL assignment-to-PDSCH offset (K0) and a PDSCH-HARQ-ACK reporting offset (K1).
  • DCI formats 1_0 and 1_1 may include the following information.
  • -Frequency domain resource assignment Represents a set of RBs allocated to PDSCH
  • K0 indicating the start position (eg, OFDM symbol index) and length (eg, number of OFDM symbols) of the PDSCH in the slot
  • HARQ process ID (Identity) for data (eg, PDSCH, TB)
  • the UE may receive PDSCH in slot #(n+K0) according to the scheduling information of slot #n, and then transmit UCI through PUCCH in slot #(n+K1).
  • UCI includes a HARQ-ACK response for PDSCH. If the PDSCH is configured to transmit up to 1 TB, the HARQ-ACK response may consist of 1-bit. When the PDSCH is configured to transmit up to two TBs, the HARQ-ACK response may consist of 2-bits if spatial bundling is not configured and 1-bit if spatial bundling is configured.
  • the UCI transmitted in slot #(n+K1) includes HARQ-ACK responses for the plurality of PDSCHs.
  • MAC medium access control
  • Each DL HARQ process manages state variables related to the number of transmissions of MAC PDUs (Physical Data Blocks) in the buffer, HARQ feedback for the MAC PDUs in the buffer, and the current redundancy version.
  • MAC PDUs Physical Data Blocks
  • Each HARQ process is distinguished by a HARQ process ID.
  • 5(b) shows an example of a PUSCH transmission process.
  • the UE may detect the PDCCH in slot #n.
  • the PDCCH includes uplink scheduling information (eg, DCI format 0_0, 0_1).
  • DCI formats 0_0 and 0_1 may include the following information.
  • -Frequency domain resource assignment Represents a set of RBs allocated to the PUSCH
  • Time domain resource assignment Indicates the slot offset K2, the start position (eg, symbol index) and length (eg, number of OFDM symbols) of the PUSCH in the slot.
  • the start symbol and length may be indicated through SLIV (Start and Length Indicator Value) or may be indicated separately.
  • the UE may transmit PUSCH in slot #(n+K2) according to the scheduling information of slot #n.
  • PUSCH includes UL-SCH TB.
  • Embodiments may be applied to a 5G-based media streaming (hereinafter referred to as 5GMS) system.
  • the 5GMS structure is a system that supports MNO (Mobile Network Operator) and third party's media downlink streaming service.
  • MNO Mobile Network Operator
  • the 5GMS structure supports related network or UE functions and APIs, and provides backward compatibles regardless of whether MBMS is supported or not and/or 5G standard or EUTRAN installation.
  • the definition of Streaming used in media using 5G is defined as the generation and delivery of time-continuous media, and the definition of Streaming Point indicates that the transmitter and receiver directly transmit and consume.
  • the 5GMS structure basically operates in downlink and uplink environments and has bidirectionality.
  • the 5GMS service may use 3G, 4G, and 6G networks as well as 5G networks, and is not limited to the above-described embodiments.
  • Embodiments may also provide a network slicing function according to service types.
  • FIG. 6 shows a downlink structure for media transmission of a 5GMS service according to embodiments.
  • FIG. 6 shows a media transmission structure for at least one of 4G, 5G, and 6G networks and is a device method capable of operating in a unidirectional downlink media streaming environment. Since it is a downlink system, media is produced in the network and Trusted Media Function, and the media is delivered to the UE.
  • Each block diagram is conceptually composed of a set of functions necessary for media transmission and reception.
  • Inter-Connection Interface refers to a link for sharing or controlling a specific part of each media block, and is used when not all necessary element technologies are utilized. For example, 3rd party external application and operator application can be connected to enable communication through Inter-Connection Interface when functions such as information sharing (user data, media track, etc.) are required even though independent application operation is performed.
  • Media includes all information and media such as time continuous, time discontinuous, image, picture, video, audio, text, etc., and additionally includes all the format and size of the format in which the corresponding media is to be transmitted. .
  • Sink in FIG. 6 represents a UE, a processor included in the UE (for example, the processor 911 for signal processing of a higher layer described in FIG. 2 ), or hardware constituting the UE.
  • the sink according to the embodiments may perform a receiving operation in which a streaming service is received in the form of unicast from a source providing media to the sink.
  • a sink according to embodiments may receive control information from a source and perform a signal processing operation based on the control information.
  • Sink according to embodiments may receive media/metadata (eg, XR data or extended media data) from a source.
  • Sink according to embodiments may include a 3rd Party External Application block, an Operator Application block, and/or a 5G Media Reception Function block.
  • the 3rd Party External Application block and the Operator Application block represent UE Applications operating in the Sink stage.
  • the 3rd Party External Application block according to the embodiments is an application operated by a third party that exists other than 4G, 5G, and 6G networks, and can drive API access of Sink.
  • the 3rd Party External Application block according to embodiments may receive information using 4G, 5G, or 6G networks or through direct Point-to-Point Communication. Therefore, Sink's UE can receive additional services through Native or Download Installed Applications.
  • An operator application block according to embodiments may manage applications (5G Media Player) associated with a media streaming driving environment including media applications.
  • Sink's UE When the application is installed, Sink's UE can start accessing the media service through API using Application Socket and send and receive related data information.
  • the API according to the embodiments enables data to be transmitted to a specific end-system through a session configuration using a socket.
  • Socket connection method can be transmitted through general TCP-based Internet connection.
  • Sink can receive control/data information from Cloud Edge and perform offloading to transmit control/data information to Cloud Edge.
  • a sink may include an offloading management block. Offloading management according to embodiments may control operations of an operator application block and/or a 3rd party application block in order to control sink offloading.
  • the 5G Media Reception Function block may receive operations related to offloading from the offloading management block, obtain media that can be received through 4G, 5G, and 6G networks, and process the media.
  • a 5G Media Reception Function block may include a general Media Access Client block, a DRM Client block, a Media Decoder, a Media Rendering Presentation block, an XR Rendering block, an XR Media Processing block, and the like.
  • the corresponding block is only an example, and the name and/or operation are not limited to the embodiments.
  • the Media Access Client block may receive data, eg, a media segment, received through at least one or more of 4G, 5G, and 6G networks.
  • the Media Access Client block may de-format (or decapsulate) various media transmission formats such as DASH, CMAF, and HLS.
  • Data output from the Media Access Client block can be processed and displayed according to each decoding characteristic.
  • the DRM Client block may determine whether to use the received data. For example, the DRM client block can perform a control operation so that authorized users can use media information within the access range.
  • the Media Decoding block is a general audio/video decoder, and among deformatted data, various standards (video standards such as MPEG2, AVC, HEVC, VVC, and MPEG 1 Layer 2 Audio, AC3, HE-AAC, E- Audio/video data processed according to audio standards such as AC-3, HE-AAC, NGA, etc.) can be decoded.
  • a Media Rendering Presentation block may render media suitable for a receiving device.
  • a Media Rendering Presentation block according to embodiments may be included in a Media decoding block.
  • An XR Media Processing block and an XR Rendering block according to embodiments are blocks for processing XR data among deformatted data (or decapsulated data).
  • the XR Media Processing block (for example, the processor 911 described in FIG. 2 or a processor that processes higher layer data) is the XR data received from the source or the information received from the offloading management block (for example, Object information, Position information). etc.) can be used to perform processing on XR media.
  • An XR rendering block according to embodiments may render and display XR media data among received media data.
  • An XR Media Processing block and an XR rendering block according to embodiments may process and render point cloud data processed according to a Video-based Point Cloud Compression (V-PCC) or Geometry-based Point Cloud Compression (G-PCC) method.
  • V-PCC Video-based Point Cloud Compression
  • G-PCC Geometry-based Point Cloud Compression
  • V-PCC Video-based Point Cloud Compression
  • G-PCC Geometry-based Point Cloud Compression
  • Source indicates a media server using at least one of 4G, 5G, and 6G networks or a UE capable of providing media and can perform Control Function and Server Function functions.
  • the Server Function starts and hosts 4G, 5G, and 6G media services.
  • 3rd Party Media Server refers to various media servers operated by third parties that exist outside of 4G, 5G, and 6G networks, and can be a Network External Media Application Server.
  • External Server which is generally operated by a third party service, can equally perform media creation, encoding, formatting, etc. in a non-4G, 5G, or 6G network.
  • the control function represents a network-based application function, and may include a control-oriented information delivery function when performing authentication of Sink and other media servers and media.
  • the source can start a connection through the API connection of the internal application through the control function, form a media session, or perform other additional information requests.
  • the source exchanges PCF information with other network functions through the control function.
  • the source can check the external network capability using NEF through the control function and perform general monitoring and provisioning through the exposure process. Therefore, NEF can receive other network information and store the received information as structured data using a specific standardized interface. The stored information can be exposed/re-exposure to other networks and applications by NEF, and the information exposed in various network environments can be collected and used for analysis.
  • an API control plane is formed, and when a session connection is made, an environment in which media can be transmitted is formed including tasks such as security (authentication, authorization, etc.).
  • multiple APIs can be created or a Control Plane can be created through one API.
  • APIs can be created from third party media servers, and Media Control Functions and APIs of UEs can form Media User Plane APIs.
  • Source can generate and deliver media in various ways to perform Downlink media service functions, and includes all functions that can deliver media to the UE corresponding to the sink, the final destination, starting from simply storing media and serving as a media relaying. can do.
  • Modules or blocks inside Sink and Source may transmit and share information through an Inter-Connection Link and Inter-Connection Interface having bi-directionality.
  • Embodiments describe a UL structure and method for transmitting media produced content in real time in a 5GMS system to social media, users, and servers.
  • Uplink basically defines that media is not delivered to users in the form of distribution, but media is produced from the user terminal UE's point of view and delivered to the media server.
  • the uplink system is configured in a form in which individual users directly provide content, so the use case and system structure to utilize the system configuration method handled by the terminal can be configured in a form different from that of the downlink.
  • the FLUS system consists of a source entity that produces media and a sink entity that consumes media, and services such as voice, video, and text are delivered through 1:1 communication.
  • the FLUS Source can be a single UE or multiple scattered UEs or Capture Devices. Since it is based on the 5G network, it can support 3GPP IMS/MTSI service, support IMS service through IMS Control Plane, and support service by complying with MTSI Service Policy regulations. If IMS/MTSI service is not supported, various user plane instantiation services can be supported through Network Assistance function for Uplink service.
  • FIG. 7 shows an example of a FLUS structure for Uplink service.
  • the FLUS structure may include the Source and Sink described in FIG. 6 .
  • a Source according to embodiments may correspond to a UE.
  • Sink according to embodiments may correspond to a UE or a network.
  • Uplink is composed of Source and Sink according to media creation and delivery goals, and Source can be a terminal device, UE, and Sink can be another UE or network.
  • a Source can receive media content from one or more Capture Devices.
  • a Capture Device may or may not be connected as part of a UE. If the sink receiving the media exists in the UE rather than the network, the decoding and rendering functions are included in the UE, and the received media must be delivered to the corresponding function. Conversely, if the sink corresponds to the network, the received media can be delivered to the Processing or Distribution Sub-Function.
  • F Link is more specifically Media Source and Sink (F-U end-points), Control Source and Sink (F-C end-points), Remote Controller and Remote Control Target (F-RC end-points) and Assistance Sender and Receiver (F-A end-points). All of these source sinks are classified as logical functions. Therefore, the corresponding functions may exist on the same physical device or may not exist on the same device due to separation of functions.
  • Each function can also be separated into multiple physical devices and connected by different interfaces.
  • Multiple F-A and F-RC points can exist in a single FLUS Source. Each point is independent of FLUS Sink and can be created according to Offered Service. As described above, the F Link Point assumes the security function of all sub-functions and links that exist in the F Point, and the corresponding authentication process can be included.
  • FIG. 8 shows a point cloud data processing system according to embodiments.
  • the point cloud processing system 1500 shown in FIG. 8 obtains, encodes, and transmits point cloud data (e.g., a BS or UE described in FIGS. 1 to 7) and receives and decodes video data. It may include a receiving device (eg, the UE described in FIGS. 1 to 7) that acquires point cloud data. As shown in FIG. 8 , point cloud data according to embodiments may be acquired through a process of capturing, synthesizing, or generating point cloud data (S1510).
  • 3D position (x, y, z)/attribute (color, reflectance, transparency, etc.) data e.g., PLY (Polygon File format or the Stanford Triangle format) file, etc.
  • PLY Polygon File format or the Stanford Triangle format
  • Metadata related to point cloud data for example, metadata related to capture, etc.
  • a transmission device or an encoder may encode point cloud data using a Geometry-based Point Cloud Compression (G-PCC) method and output one or more video streams (S1520).
  • G-PCC Geometry-based Point Cloud Compression
  • G-PCC is a method of encoding point cloud data by dividing it into two streams: geometry (or geometry information) and attribute (or attribute information).
  • a geometry stream may be generated by reconstructing and encoding location information of points, and an attribute stream may be generated by reconstructing and encoding attribute information (eg, color, etc.) associated with each point.
  • One or more output bit streams may be encapsulated in the form of a file (for example, a file format such as ISOBMFF) together with related metadata and transmitted through a network or a digital storage medium (S1530).
  • a file format for example, a file format such as ISOBMFF
  • S1530 digital storage medium
  • point cloud related metadata itself may be encapsulated in a file.
  • a device or processor (for example, the processor 911 or processor 921 described in FIG. 2, the upper layer processor, or the Sink described in FIG. 6 or the XR Media Processing block included in the Sink) according to the embodiments is
  • the received video data may be decapsulated to obtain one or more bit streams and related metadata, and the obtained bit streams may be decoded using the G-PCC method to restore 3D point cloud data (S1540).
  • a renderer for example, the sink described in FIG. 6 or an XR rendering block included in the sink
  • a device or processor may perform a feedback process of transferring various feedback information acquired in a rendering/display process to a transmitting device or a decoding process (S1560).
  • Feedback information may include head orientation information, viewport information indicating a region currently viewed by a user, and the like. Since the interaction between the user and the service (or content) provider is made through the feedback process, the device according to the embodiments can provide various services considering higher user convenience, as well as the aforementioned G-PCC method. There is a technical effect that provides a faster data processing speed or enables a clear video composition by using .
  • FIG 9 shows an example of a point cloud data processing device according to embodiments.
  • FIG. 9 shows a device that performs a point cloud data processing operation according to the G-PCC method.
  • the point cloud data processing apparatus shown in FIG. 9 is the UE described in FIGS. 1 to 7 (for example, the processor 911 or processor 921 described in FIG. 2, the processor for processing higher layer data, or the processor described in FIG. 6).
  • a point cloud data processing apparatus includes a point cloud acquisition unit (Point Cloud Acquisition), a point cloud encoding unit (Point Cloud Encoding), a file / segment encapsulation unit (File / Segment Encapsulation), and / or a delivery unit (Delivery) included.
  • Each component of the processing device may be a module/unit/component/hardware/software/processor or the like.
  • the geometry, attribute, auxiliary data, and mesh data of the point cloud can be configured as separate streams or stored in different tracks in a file. Furthermore, it may be included in a separate segment.
  • the Point Cloud Acquisition unit acquires a point cloud.
  • point cloud data may be acquired through a process of capturing, synthesizing, or generating a point cloud through one or more cameras.
  • point cloud data including the 3D position of each point (which can be expressed as x, y, z position values, etc., hereinafter referred to as geometry) and the attributes of each point (color, reflectance, transparency, etc.) It can be obtained and can be generated as, for example, a PLY (Polygon File format or the Stanford Triangle format) file including it.
  • PLY Polygon File format or the Stanford Triangle format
  • point cloud-related metadata for example, metadata related to capture, etc.
  • point cloud-related metadata for example, metadata related to capture, etc.
  • the Point Cloud Encoding unit performs a Geometry-based Point Cloud Compression (G-PCC) procedure, which performs a series of procedures such as prediction, transformation, quantization, and entropy coding, and the encoded data ( Encoded video/video information) may be output in the form of a bitstream.
  • G-PCC Geometry-based Point Cloud Compression
  • the point cloud encoding unit may divide point cloud data into geometry (or geometry information) and attribute (attribute information) and encode them respectively. Also, the encoded geometry information and attribute information may be output as bitstreams, respectively. Output bitstreams may be multiplexed into one bitstream.
  • the point cloud encoding unit may receive metadata. Metadata represents metadata related to content for Point Cloud. For example, there may be initial viewing orientation metadata.
  • Metadata indicates whether the point cloud data indicates forward or backward data, and the like.
  • the point cloud encoding unit may receive orientation information and/or viewport information. Encoding may be performed based on point cloud encoding unit metadata, orientation information, and/or viewport information.
  • a non-stream output from the point cloud encoding unit according to embodiments may include point cloud related metadata.
  • the Point Cloud Encoding unit according to embodiments performs geometry compression, attribute compression, auxiliary data compression, and mesh data compression.
  • Geometry compression encodes the geometry information of point cloud data. Geometry (or geometry information) represents points (or location information of each point) on a 3D space.
  • Attribute compression encodes attributes of point cloud data. Attribute (or attribute information) represents an attribute of each point (for example, attributes such as color and reflectance).
  • Attribute compression can process one or more attributes of one or more points.
  • Auxiliary data compression encodes auxiliary data associated with a point cloud.
  • Auxiliary data represents metadata about a point cloud.
  • Mesh data compression encodes Mesh data.
  • Mesh data represents connection information between point clouds.
  • Mesh data according to embodiments may include mesh data representing a triangular shape.
  • the Point Cloud encoding unit encodes the geometry, attributes, auxiliary data, and mesh data related to the point, which are information necessary for rendering the point.
  • the point cloud encoding unit can encode geometry, attributes, auxiliary data, and mesh data and transmit them as a single bitstream.
  • the point cloud encoding unit may encode geometry, attribute, auxiliary data, and mesh data, respectively, and output one or more bitstreams or encoded data for transmitting the encoded data (for example, a geometry bitstream , attribute bitstream, etc.).
  • Each operation of the point cloud encoding unit may be performed in parallel.
  • the file/segment encapsulation unit performs media track encapsulation and/or metadata track encapsulation.
  • the file/segment encapsulation unit creates tracks to deliver encoded geometry (geometry information), encoded attributes, encoded auxiliary data, and encoded mesh data in a file format.
  • a bitstream including encoded geometry (geometry information), a bitstream including encoded attributes, a bitstream including encoded Auxiliary data, and a bitstream including encoded Mesh data are assigned to one or more tracks.
  • the file/segment encapsulation unit encapsulates geometry (geometry information), attributes, auxiliary data, and mesh data into one or more media tracks.
  • the file/segment encapsulation unit includes metadata in a media track or encapsulates metadata in a separate metadata track.
  • the file/segment encapsulation unit encapsulates the point cloud stream(s) in the form of files and/or segments. When the point cloud stream(s) is encapsulated in the form of segment(s) and delivered, it is delivered in DASH format.
  • the file/segment encapsulation unit delivers the file when encapsulating the point cloud stream(s) in the form of a file.
  • the delivery unit may deliver a point cloud bitstream or a file/segment including the corresponding bitstream to a receiving unit of a receiving device through a digital storage medium or a network. For transmission, processing according to any transmission protocol may be performed. Data that has been processed for transmission can be delivered through a broadcasting network and/or broadband. These data may be delivered to the receiving side in an on-demand manner. Digital storage media may include various storage media such as USB, SD, CD, DVD, Blu-ray, HDD, and SSD.
  • the delivery unit may include an element for generating a media file through a predetermined file format, and may include an element for transmission through a broadcasting/communication network. The delivery unit receives orientation information and/or viewport information from the receiver.
  • the delivery unit may deliver the acquired orientation information and/or viewport information (or information selected by the user) to the file/segment encapsulation unit and/or the point cloud encoding unit.
  • the point cloud encoding unit may encode all point cloud data or encode point cloud data indicated by the orientation information and/or viewport information.
  • the file/segment encapsulation unit may encapsulate all point cloud data or encapsulate point cloud data indicated by the orientation information and/or viewport information.
  • the delivery unit may deliver all point cloud data or point cloud data indicated by the orientation information and/or the viewport information.
  • FIG. 10 shows an example of a point cloud data processing device according to embodiments.
  • FIG. 10 shows an example of a device performing an operation of receiving and processing point cloud data processed according to the G-PCC method.
  • the device of FIG. 10 may process data in a manner corresponding to the manner described in FIG. 9 .
  • the point cloud data processing device shown in FIG. 10 corresponds to or may be included in the UE described in FIGS. 1 to 10 (for example, the processor 911 or processor 921 described in FIG. 2 or described in FIG. 8 ). Sink or the XR Media Processing block included with the Sink, etc.).
  • Point Cloud data processing device includes a delivery client, a sensing/tracking unit, a file/segment decapsulation unit, a Point Cloud decoding unit ) and/or Point Cloud Rendering, and a display.
  • Each configuration of the receiving device may be a module/unit/component/hardware/software/processor or the like.
  • a delivery client may receive point cloud data, a point cloud bitstream, or a file/segment including the corresponding bitstream transmitted by the point cloud data processing device described in FIG. 9 .
  • the device of FIG. 10 may receive point cloud data through a broadcasting network or point cloud data through a broadband.
  • point cloud video data may be received through a digital storage medium.
  • the device of FIG. 10 may perform a process of decoding the received data and rendering it according to the user's viewport.
  • the apparatus of FIG. 10 may include a reception processing unit (eg, the processor 911 of FIG. 2 ) for processing the received point cloud data according to a transmission protocol.
  • the reception processing unit may perform the reverse process of the transmission processing unit so as to correspond to processing for transmission performed on the transmission side.
  • the reception processing unit can deliver the acquired point cloud data to the decapsulation processing unit, and the acquired point cloud related metadata to the metadata parser.
  • a sensing/tracking unit obtains orientation information and/or viewport information.
  • the sensing/tracking unit may transmit the obtained orientation information and/or viewport information to a delivery client, a file/segment decapsulation unit, and a point cloud decoding unit.
  • the delivery client may receive all point cloud data based on the orientation information and/or viewport information or point cloud data indicated by the orientation information and/or viewport information.
  • the file/segment decapsulation unit may decapsulate all point cloud data or point cloud data indicated by the orientation information and/or viewport information based on the orientation information and/or the viewport information.
  • the point cloud decoding unit may decode all point cloud data or decode point cloud data indicated by the orientation information and/or viewport information, based on the orientation information and/or viewport information.
  • the file/segment decapsulation unit performs media track decapsulation and/or metadata track decapsulation.
  • the decapsulation processing unit (file/segment decapsulation) may decapsulate point cloud data in the form of a file received from the reception processing unit.
  • the decapsulation processor may decapsulate files or segments according to ISOBMFF and the like to obtain a point cloud bitstream or point cloud related metadata (or a separate metadata bitstream).
  • the acquired point cloud bitstream can be delivered to the point cloud decoder, and the acquired metadata (or metadata bitstream) related to the point cloud can be delivered to the metadata processing unit.
  • a point cloud bitstream may contain metadata (metadata bitstream).
  • the metadata processing unit may be included in the point cloud video decoder or configured as a separate component/module.
  • Point cloud-related metadata acquired by the decapsulation processing unit may be in the form of a box or track in a file format.
  • the decapsulation processing unit may receive metadata necessary for decapsulation from the metadata processing unit, if necessary. Metadata related to the point cloud may be transmitted to the point cloud decoder and used for the point cloud decoding procedure, or may be transmitted to the renderer and used for the point cloud rendering procedure.
  • the Point Cloud Decoding unit performs geometry decompression, attribute decompression, auxiliary data decompression, and/or mesh data decompression.
  • the Point Cloud decoder can decode data by receiving a bitstream and performing an operation corresponding to the operation of the Point Cloud encoder. In this case, the Point Cloud decoder can decode the Point Cloud data by dividing it into geometry and attributes as will be described later.
  • a Point Cloud decoder can restore (decode) geometry from a geometry bitstream contained in an input bitstream, and restore (decode) attribute values based on an attribute bitstream contained in an input bitstream and the restored geometry. )can do.
  • the mesh may be restored (decoded) based on the mesh bitstream included in the input bitstream and the restored geometry.
  • Point cloud can be restored by restoring the position of each point in 3D and the attribute information of each point based on the position information according to the restored geometry and the (color) texture attribute according to the decoded attribute value.
  • Each operation of the point cloud decoding unit may be performed in parallel.
  • Geometry decompression decodes the geometry data from the point cloud stream(s). Attribute decompression decodes attribute data from the point cloud stream(s). Auxiliary data decompression decodes Auxiliary data from point cloud stream(s). Mesh data decompression decodes the mesh data from the point cloud stream(s).
  • the Point Cloud Rendering unit restores the position of each point in the point cloud and attributes of the point based on the decoded geometry, attribution, auxiliary data, and mesh data, and renders the corresponding point cloud data. .
  • the point cloud rendering unit generates and renders mesh (connection) data between point clouds based on the restored geometry, the restored attributes, the restored auxiliary data, and/or the restored mesh data.
  • the point cloud rendering unit receives metadata from the file/segment encapsulation unit and/or the point cloud decoding unit.
  • the point cloud rendering unit may render point cloud data based on metadata according to an orientation or a viewport.
  • the device of FIG. 10 may include a display.
  • a display according to embodiments may display a rendered result.
  • FIG. 11 shows an example of a point cloud data processing device according to embodiments.
  • V-PCC is a method of compressing point cloud data based on 2D video codecs such as HEVC and VVC.
  • the point cloud data processing apparatus shown in FIG. 11 is the UE described in FIGS. 1 to 8 (for example, the processor 911 or processor 921 described in FIG. 2, or the sink described in FIG. 6 or XR Media included in the sink) Processing block, etc.) or BS, or may correspond to the UE.
  • Point Cloud data processing apparatus includes Point Cloud Acquisition, Patch Generation, Geometry Image Generation, Attribute Image Generation, Accupancy Map Generation Occupancy Map Generation, Auxiliary Data Generation, Mesh Data Generation, Video Encoding, Image Encoding, File/Segment Encapsulation ), including the delivery department.
  • patch generation, geometry image generation, attribute image generation, accupancy map generation, auxiliary data generation, and mesh data generation are referred to as point cloud pre-processing, pre-processor, or controller. can do.
  • Video encoding unit includes Geometry video compression, Attribute video compression, Occupancy map compression, Auxiliary data compression, and Mesh data compression do.
  • the image encoding unit includes Geometry video compression, Attribute video compression, Occupancy map compression, Auxiliary data compression, and Mesh data compression do.
  • the file/segment encapsulation unit includes video track encapsulation, metadata track encapsulation, and image encapsulation.
  • Each configuration of the transmission device may be a module/unit/component/hardware/software/processor or the like.
  • the geometry, attribute, auxiliary data, and mesh data of the point cloud can be configured as separate streams or stored in different tracks in a file. Furthermore, it may be included in a separate segment.
  • the Point Cloud Acquisition unit acquires a point cloud.
  • point cloud data may be acquired through a process of capturing, synthesizing, or generating a point cloud through one or more cameras.
  • point cloud data including the 3D position of each point (which can be expressed as x, y, z position values, etc., hereinafter referred to as geometry) and the attributes of each point (color, reflectance, transparency, etc.) It can be obtained and can be generated as, for example, a PLY (Polygon File format or the Stanford Triangle format) file including it.
  • PLY Polygon File format or the Stanford Triangle format
  • point cloud-related metadata for example, metadata related to capture, etc.
  • point cloud-related metadata for example, metadata related to capture, etc.
  • a patch generation or patch generator generates patches from point cloud data.
  • a patch generator generates point cloud data or point cloud video into one or more pictures/frames.
  • a picture/frame may generally mean a unit representing one image in a specific time period.
  • the points constituting the point cloud video are one or more patches (a set of points constituting a point cloud, points belonging to the same patch are adjacent to each other in the 3D space, and in the process of mapping to a 2D image, among the planes of the 6-sided bounding box When divided into a set of points mapped in the same direction) and mapped to a 2D plane, a binary map indicating whether data exists at the corresponding location on the 2D plane as a value of 0 or 1, occupancy You can create map pictures/frames.
  • a geometry picture/frame which is a picture/frame in the form of a depth map expressing positional information (geometry) of each point constituting the point cloud video in a patch unit
  • a texture picture/frame which is a picture/frame that expresses the color information of each point constituting a point cloud video in units of patches
  • metadata needed to reconstruct a point cloud from individual patches can be generated, which can include patch information such as the location and size of each patch in 2D/3D space.
  • the patch can be used for 2D image mapping.
  • point cloud data can be projected onto each face of a cube.
  • a geometry image, one or more attribute images, an accupancy map, auxiliary data, and/or mesh data may be generated based on the generated patch.
  • Geometry Image Generation Geometry Image Generation, Attribute Image Generation, Occupancy Map Generation, Auxiliary Data Generation and/or Mesh by a pre-processor or controller Data generation (Mesh Data Generation) is performed.
  • Geometry Image Generation generates a geometry image based on a result of patch generation.
  • a geometry represents a point in a three-dimensional space.
  • a geometry image is generated using an accupancy map including information related to the 2D image packing of the patch, auxiliary data (patch data), and/or mesh data.
  • the geometry image is related to information such as depth (e.g., near, far) of the patch generated after patch generation.
  • Attribute Image Generation creates an attribute image.
  • an attribute may indicate a texture.
  • the texture may be a color value matched to each point.
  • a plurality of (N) attributes attributes (attributes such as color and reflectance) images including textures may be generated.
  • a plurality of attributes may include material (information about a material), reflectance, and the like.
  • an attribute may additionally include information that can change color by time and light, even in the same texture.
  • Occupancy Map Generation generates an Occupancy Map from patches.
  • the accupancy map includes information indicating whether data exists in a pixel of a corresponding geometry or attribute image.
  • Auxiliary Data Generation generates auxiliary data including patch information. That is, Auxiliary data represents metadata about patches of Point Cloud objects. For example, information such as a normal vector for a patch may be indicated. Specifically, according to embodiments, auxiliary data may include information necessary for reconstructing a point cloud from patches (eg, information about the position and size of a patch in 2D/3D space, projection normal ) identification information, patch mapping information, etc.)
  • Mesh Data Generation generates mesh data from patches.
  • Mesh represents connection information between adjacent points.
  • triangular data may be represented.
  • mesh data according to embodiments means connectivity information between points.
  • the point cloud pre-processor or control unit generates metadata related to patch generation, geometry image generation, attribute image generation, accupancy map generation, auxiliary data generation, and mesh data generation.
  • the point cloud transmission device performs video encoding and/or image encoding in response to the result generated by the pre-processor.
  • the point cloud transmission device may generate point cloud image data as well as point cloud video data.
  • point cloud data includes only video data, only image data, and/or both video data and image data. there may be
  • the video encoding unit performs geometry video compression, attribute video compression, accupancy map compression, auxiliary data compression, and/or mesh data compression.
  • the video encoding unit generates video stream(s) containing each encoded video data.
  • geometry video compression encodes point cloud geometry video data.
  • Attribute video compression encodes attribute video data in a point cloud.
  • Auxiliary data compression encodes auxiliary data associated with point cloud video data.
  • Mesh data compression encodes the mesh data of point cloud video data. Each operation of the point cloud video encoding unit may be performed in parallel.
  • the image encoding unit performs geometry image compression, attribute image compression, accupancy map compression, auxiliary data compression, and/or mesh data compression.
  • the image encoding unit generates image(s) including each encoded image data.
  • geometry image compression encodes point cloud geometry image data.
  • Attribute image compression encodes the attribute image data of a point cloud.
  • Auxiliary data compression encodes auxiliary data associated with point cloud image data.
  • Mesh data compression encodes mesh data associated with point cloud image data. Each operation of the point cloud image encoding unit may be performed in parallel.
  • the video encoding unit and/or the image encoding unit may receive metadata from the pre-processor.
  • the video encoding unit and/or the image encoding unit may perform each encoding process based on metadata.
  • a file/segment encapsulation unit encapsulates video stream(s) and/or image(s) in the form of a file and/or segment.
  • the file/segment encapsulation unit performs video track encapsulation, metadata track encapsulation, and/or image encapsulation.
  • Video track encapsulation may encapsulate one or more video streams in one or more tracks.
  • Metadata track encapsulation may encapsulate metadata related to a video stream and/or image into one or more tracks. Metadata includes data related to the content of point cloud data. For example, initial viewing orientation metadata may be included. According to embodiments, metadata may be encapsulated in a metadata track, or may be encapsulated together in a video track or an image track.
  • Image encapsulation may encapsulate one or more images in one or more tracks or items.
  • 4 video streams and 2 images may be encapsulated in one file.
  • the file/segment encapsulation unit may receive metadata from the pre-processor.
  • the file/segment encapsulation unit may perform encapsulation based on metadata.
  • the files and/or segments generated by the file/segment encapsulation are transmitted by the point cloud transmission device or transmission unit.
  • segment(s) may be delivered based on a DASH-based protocol.
  • the delivery unit may deliver a point cloud bitstream or a file/segment including the corresponding bitstream to a receiving unit of a receiving device through a digital storage medium or a network. For transmission, processing according to any transmission protocol may be performed. Data that has been processed for transmission can be delivered through a broadcasting network and/or broadband. These data may be delivered to the receiving side in an on-demand manner. Digital storage media may include various storage media such as USB, SD, CD, DVD, Blu-ray, HDD, and SSD.
  • the delivery unit may include an element for generating a media file through a predetermined file format, and may include an element for transmission through a broadcasting/communication network. The delivery unit receives orientation information and/or viewport information from the receiver.
  • the delivery unit may deliver the acquired orientation information and/or viewport information (or information selected by the user) to a pre-processor, a video encoding unit, an image encoding unit, a file/segment encapsulation unit, and/or a point cloud encoding unit.
  • the point cloud encoding unit may encode all point cloud data or encode point cloud data indicated by the orientation information and/or viewport information.
  • the file/segment encapsulation unit may encapsulate all point cloud data or encapsulate point cloud data indicated by the orientation information and/or viewport information.
  • the delivery unit may deliver all point cloud data or point cloud data indicated by the orientation information and/or the viewport information.
  • the pre-processor may perform the above-described operation for all point cloud data or for point cloud data indicated by orientation information and/or viewport information.
  • the video encoding unit and/or the image encoding unit may perform the above-described operation for all point cloud data or may perform the above-described operation for point cloud data indicated by orientation information and/or viewport information.
  • the file/segment encapsulation unit may perform the above-described operation for all point cloud data or for point cloud data indicated by orientation information and/or viewport information.
  • the transmitter may perform the above-described operation for all point cloud data or for point cloud data indicated by orientation information and/or viewport information.
  • FIG. 12 shows an example of a point cloud data processing device according to embodiments.
  • the point cloud data processing apparatus shown in FIG. 12 may process data in a method corresponding to the method described in FIG. 11 .
  • the point cloud data processing apparatus shown in FIG. 12 corresponds to the UE described in FIGS. 1 to 8 or may be included in the UE (for example, the processor 911 or processor 921 described in FIG. 2), which processes higher layer data. processor, or the Sink described in FIG. 6 or the XR Media Processing block included in the Sink).
  • Point Cloud data processing apparatus includes a delivery client, a sensing/tracking unit, a file/segment decapsulation unit, a video decoding unit, It includes an image decoding unit, point cloud processing and/or point cloud rendering unit, and a display.
  • the video decoding unit performs geometry video decompression, attribute video decompression, occupancy map decompression, auxiliary data decompression, and/or mesh data decompression.
  • the image decoding unit performs geometry image decompression, attribute image decompression, occupancy map decompression, auxiliary data decompression, and/or mesh data decompression.
  • Point cloud processing includes Geometry Reconstruction and Attribute Reconstruction.
  • a delivery client may receive point cloud data, a point cloud bitstream, or a file/segment including the corresponding bitstream transmitted by the point cloud data processing apparatus according to the embodiments of FIG. 13 .
  • the device of FIG. 14 may receive point cloud data through a broadcasting network or point cloud data through a broadband.
  • point cloud video data may be received through a digital storage medium.
  • the device of FIG. 14 may perform a process of decoding the received data and rendering it according to the user's viewport.
  • the device of FIG. 14 may include a reception processing unit (eg, the processor 911 of FIG. 2 ) although not shown in the drawing.
  • the reception processing unit according to embodiments may perform processing according to a transport protocol on the received point cloud data.
  • the receiving processing unit may perform the reverse process of the above-described transmission processing unit so as to correspond to processing for transmission performed on the transmission side.
  • the reception processing unit can deliver the acquired point cloud data to the decapsulation processing unit, and the acquired point cloud related metadata to the metadata parser.
  • a sensing/tracking unit obtains orientation information and/or viewport information.
  • the sensing/tracking unit may transmit the obtained orientation information and/or viewport information to a delivery client, a file/segment decapsulation unit, and a point cloud decoding unit.
  • the delivery client may receive all point cloud data based on the orientation information and/or viewport information or point cloud data indicated by the orientation information and/or viewport information.
  • the file/segment decapsulation unit may decapsulate all point cloud data or point cloud data indicated by the orientation information and/or viewport information based on the orientation information and/or the viewport information.
  • the point cloud decoding unit (video decoding unit and/or image decoding unit) may decode all point cloud data or decode point cloud data indicated by the orientation information and/or viewport information, based on the orientation information and/or viewport information.
  • the point cloud processing unit may process all point cloud data or process point cloud data indicated by orientation information and/or viewport information.
  • the file/segment decapsulation unit performs video track decapsulation, metadata track decapsulation, and/or image decapsulation.
  • the decapsulation processing unit may decapsulate point cloud data in the form of a file received from the reception processing unit.
  • the decapsulation processor may decapsulate files or segments according to ISOBMFF and the like to obtain a point cloud bitstream or point cloud related metadata (or a separate metadata bitstream).
  • the acquired point cloud bitstream can be delivered to the point cloud decoder, and the acquired metadata (or metadata bitstream) related to the point cloud can be delivered to the metadata processing unit.
  • a point cloud bitstream may contain metadata (metadata bitstream).
  • the metadata processing unit may be included in the point cloud video decoder or configured as a separate component/module.
  • Point cloud-related metadata acquired by the decapsulation processing unit may be in the form of a box or track in a file format.
  • the decapsulation processing unit may receive metadata necessary for decapsulation from the metadata processing unit, if necessary. Metadata related to the point cloud may be transmitted to the point cloud decoder and used for the point cloud decoding procedure, or may be transmitted to the renderer and used for the point cloud rendering procedure.
  • the file/segment decapsulation unit may generate metadata related to point cloud data.
  • Video Track Decapsulation decapsulates video tracks contained in files and/or segments. Decapsulate video stream(s) including geometry video, attribute video, accupancy map, Auxiliary data and/or Mesh data.
  • Metadata track decapsulation decapsulates a bitstream including metadata and/or additional data related to point cloud data.
  • Image decapsulation decapsulates image(s) including geometry image, attribute image, accupancy map, auxiliary data and/or mesh data.
  • the video decoding unit performs geometry video decompression, attribute video decompression, accupancy map decompression, auxiliary data decompression, and/or mesh data decompression.
  • the video decoding unit decodes geometry video, attribute video, auxiliary data, and/or mesh data in response to a process performed by the video encoding unit of the point cloud transmission device according to embodiments.
  • the image decoding unit performs geometry image decompression, attribute image decompression, accupancy map decompression, auxiliary data decompression, and/or mesh data decompression.
  • the image decoding unit decodes the geometry image, the attribute image, the auxiliary data and/or the mesh data in response to the process performed by the image encoding unit of the point cloud transmission device according to the embodiments.
  • the video decoding unit and/or the image decoding unit may generate metadata related to video data and/or image data.
  • the point cloud processing unit performs geometry reconstruction and/or attribute reconstruction.
  • the geometry reconstruction reconstructs a geometry video and/or a geometry image from decoded video data and/or decoded image data based on an accupancy map, auxiliary data, and/or mesh data.
  • Attribute Reconstruction reconstructs an attribute video and/or an attribute image from a decoded attribute video and/or a decoded attribute image based on an accupancy map, auxiliary data, and/or mesh data.
  • the attribute may be a texture.
  • an attribute may mean a plurality of attribute information.
  • the point cloud processing unit may receive metadata from the video decoding unit, the image decoding unit and/or the file/segment decapsulation unit, and process the point cloud based on the metadata.
  • the point cloud rendering unit renders the reconstructed point cloud.
  • the point cloud rendering unit may receive metadata from the video decoding unit, the image decoding unit and/or the file/segment decapsulation unit, and render the point cloud based on the metadata.
  • the device of FIG. 12 may include a display.
  • a display according to embodiments may display a rendered result.
  • FIG. 13 shows an example of a point cloud data processing device according to embodiments.
  • An apparatus for processing point cloud data includes a data input unit 12000, a quantization processing unit 12001, a voxelization processing unit 12002, an octree occupancy code generation unit 12003, a four-surface model processing unit 12004, intra/inter coding processing unit 12005, arithmetic coder 12006, metadata processing unit 12007, color conversion processing unit 12008, attribute conversion processing unit 12009, prediction/lifting/RAHT conversion processing unit 12010, arithmetic coder 12011 and/or Alternatively, the transmission processing unit 12012 may be included.
  • the data input unit 12000 receives or acquires point cloud data.
  • the data input unit 12000 may correspond to the point cloud acquisition unit 10001 of FIG. 1 according to embodiments.
  • the quantization processing unit 12001 quantizes the geometry of point cloud data, for example, position value information of points.
  • the voxelization processing unit 12002 according to the exemplary embodiments voxels position value information of quantized points.
  • the octree occupancy code generation unit 12003 may represent position value information of voxelized points as an octree based on an octree occupancy code.
  • the four-surface model processing unit 12004 may express and process an octree for location value information of points of a point cloud based on a surface model method.
  • the intra/inter coding processing unit 12005 may intra/inter code the point cloud data.
  • the arithmetic coder 12006 may encode point cloud data based on an arithmetic coding scheme.
  • the metadata processing unit 12007 processes metadata related to point cloud data, eg, setting values, and provides them to a necessary process such as a geometry encoding process and/or an attribute encoding process. Also, the metadata processing unit 12007 according to embodiments may generate and/or process signaling information related to geometry encoding and/or attribute encoding. Signaling information according to embodiments may be encoded separately from geometry encoding and/or attribute encoding. Also, signaling information according to embodiments may be interleaved.
  • the color conversion processing unit 12008 may convert colors of point cloud data based on attributes of the point cloud data, for example, attribute value information of points and/or reconstructed position values.
  • the attribute conversion processing unit 12009 may convert attribute values of point cloud data.
  • the prediction/lifting/RAHT conversion processing unit 12010 may attribute-code point cloud data based on a combination of a prediction method, a lifting method, and/or a RAHT method.
  • the arithmetic coder 12011 may encode point cloud data based on an arithmetic coding scheme.
  • the transmission processing unit 12012 transmits each bitstream including encoded geometry information and/or encoded attribute information and metadata information, or transmits encoded geometry information and/or encoded attribute information and metadata Information can be configured and transmitted as one bit stream.
  • the bitstream may include one or more sub-bitstreams.
  • the bitstream according to the embodiments includes Sequence Parameter Set (SPS) for signaling at the sequence level, Geometry Parameter Set (GPS) for signaling of geometry information coding, Attribute Parameter Set (APS) for signaling of attribute information coding, tile It may include signaling information and slice data including TPS (Tile Parameter Set) for level signaling.
  • SPS Sequence Parameter Set
  • GPS Geometry Parameter Set
  • APS Attribute Parameter Set
  • tile may include signaling information and slice data including TPS (Tile Parameter Set) for level signaling.
  • Slice data may include information on one or more slices.
  • One slice may include one geometry bitstream Geom00 and one or more attribute bitstreams Attr00 and Attr10.
  • a TPS may include information about each tile (for example, coordinate value information and height/size information of a bounding box) for one or more tiles.
  • a geometry bitstream may include a header and a payload.
  • the header of the geometry bitstream may include identification information (geom_geom_parameter_set_id) of a parameter set included in GPS, a tile identifier (geom_tile id), a slice identifier (geom_slice_id), and information about data included in a payload.
  • the metadata processing unit 12007 may generate and/or process signaling information and transmit it to the transmission processing unit 12012.
  • a process for position values of points and a process for attribute values of points may perform each process by sharing data/information with each other.
  • FIG. 14 shows an example of a point cloud data processing device according to embodiments.
  • FIG. 14 shows an example of a device that performs a point cloud data processing operation according to the G-PCC scheme described in FIG. 10 .
  • the point cloud data processing apparatus shown in FIG. 14 may perform the reverse process of the point cloud data processing apparatus described in FIG. 13 .
  • An apparatus for processing point cloud data includes a receiving unit 13000, a receiving processing unit 13001, an arithmetic decoder 13002, an octree reconstruction processing unit 13003 based on an Occupancy code, and a surface model processing unit (triangle reconstruction, up-sampling, voxel). image) 13004, inverse quantization processing unit 13005, metadata parser 13006, arithmetic decoder 13007, inverse quantization processing unit 13008, prediction/lifting/RAHT inverse transformation processing unit 13009, color inverse transformation processing unit 13010 and/or a renderer 13011.
  • the receiving unit 13000 receives point cloud data.
  • the reception processing unit 13001 may obtain a geometry bitstream and/or an attribute bitstream included in the received point cloud data, metadata including signaling information, and the like.
  • the arithmetic decoder 13002 may decode a geometry bitstream based on an arithmetic method.
  • the octree reconstruction processing unit 13003 based on the occupancy code may reconstruct the decoded geometry into an octree based on the occupancy code.
  • the surface model processing unit 13004 performs triangle reconstruction, up-sampling, voxelization, and/or a combination thereof on point cloud data based on a surface model method. processing can be performed.
  • the inverse quantization processing unit 13005 may inverse quantize point cloud data.
  • the metadata parser 13006 may parse metadata included in the received point cloud data, for example, setting values.
  • the metadata parser 13006 may pass metadata to each step of the geometry decoding process and/or attribute decoding process. Each process according to embodiments may be performed based on necessary metadata.
  • the arithmetic decoder 13007 may decode an attribute bitstream of point cloud data in an arithmetic manner based on a reconstructed position value.
  • the inverse quantization processing unit 13008 may inverse quantize point cloud data.
  • the prediction/lifting/RAHT inverse transform processing unit 13009 may process point cloud data based on a prediction/lifting/RAHT method and/or a method according to a combination thereof.
  • the inverse color transformation processing unit 13010 may inversely transform color values of point cloud data.
  • the renderer 13011 may render point cloud data.
  • 15 shows a transmission structure for a UE on a visited network according to embodiments.
  • 3GPP The 3rd Generation Partnership Project
  • the Multimedia Division establishes and distributes standards for transmitting and receiving media by defining protocols related to media codecs.
  • the definition of media and transmission scenarios covers a wide range. This includes cases in which mobile/fixed reception is performed by a personal computer or portable receiver along with Radio Access and Internet-based technology.
  • This wide-ranging standard enactment in 3GPP enabled ubiquitous multimedia services to cover various users and use cases, and enable users to quickly experience high-quality media anytime, anywhere.
  • media services are classified according to their unique characteristics and are divided into Conversational, Streaming, and other services according to the target application. Conversational Service is extended from Session Initiation Protocol (SIP) based telephone service network.
  • SIP Session Initiation Protocol
  • the Multimedia Telephony Service for the IP Multimedia Subsystem aims at a low-latency real-time conversation service.
  • Streaming service delivers real-time or re-acquired content in Unicast based on Packet Switched Service (PSS).
  • PSS Packet Switched Service
  • broadcasting services within the PSS system can use mobile TV through Multimedia Broadcast/Multicast Service (MBMS).
  • MBMS Multimedia Broadcast/Multicast Service
  • 3GPP provides Messaging or reality services.
  • the three basic services described above are continuously being revised or updated in order to satisfy the highest possible user experience, and provide scalability so that they can be mutually compatible with available network resources or existing standards.
  • Media includes video codec, voice, audio, image, graphic, and text corresponding to each service.
  • IMS IP Multimedia Subsystem
  • IETF Internet Engineering Task Force
  • IMS is used as the basic protocol of SIP protocol, and it manages multimedia sessions efficiently through this.
  • MTSI Multimedia Telephony Service for IMS
  • MTSI includes not only Signaling, Transport, Jitter Buffer, Management, Packet-Loss Handling, and Adaptation, but also Adding/Dropping Media During Call, etc., so that predictable media can be created, transmitted, and received.
  • MTSI uses the 3GPP network
  • NR, LTE, and HSPA are connected to IMS
  • Wi-Fi and Bluetooth are also extended and connected.
  • MTSI transmits and receives data negotiation messages to the existing IMS network, and has a structure in which data is transmitted between users when transmission and reception are completed. Therefore, the IMS network can be equally used, and MTSI additionally defines only Audio Encoder/Decoder, Video Encoder/Decoder, Text, Session Setup and Control, and Data Channel.
  • Data Channel Capable MTSI represents an enabling channel to support media transmission and uses Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) and Web Real-Time Communication (WebRTC).
  • SCTP Stream Control Transmission Protocol
  • DTLS Datagram Transport Layer Security
  • WebRTC Web Real-Time Communication
  • SCTP is used to provide security services between Network Layer and Transport Layer of TCP. Since it is extended from the existing platform, it defines Media Control Data as well as Media Control and Media Codec for media management, and general control is handled through Media Streaming Setup through SIP/SDP. Since Setup/Control is passed between clients, Adding/Dropping of media is also included. MTSI also includes IMS Messaging, a non-conversational service. Media is carried over 3GPP Layer 2 using the Packet Data Convergence Protocol (PDCP). PDCP delivers IP packets from the client to the base station and generally performs user plane data, control plane data, header compression, and ciphering/protection.
  • PDCP Packet Data Convergence Protocol
  • UE 15 is a transmission structure in which a call session can be transferred between two UEs existing in an arbitrary visited network when User Equipment (UE) A/B exists.
  • UE A/B may exist in operator A or B or the same network, and it is assumed that four other networks exist to describe the entire system of MTSI.
  • UE A and B perform session establishment to transmit media within the IMS system. After the session is established, UE A and B transmit media through the IP network.
  • the main function of IMS is the Call State Control Function (CSCF), which manages multimedia sessions using SIP.
  • CSCF Call State Control Function
  • Each CSCF plays the role of server or proxy and performs different types of functions according to each purpose.
  • Proxy CSCF acts as a SIP proxy server.
  • the P-CSCF internally analyzes and transmits SIP messages in order to receive all SIP messages and deliver them to the UE to transmit.
  • P-CSCF can perform resource management and is closely connected to the gateway of the network.
  • the gateway is associated with the IP access bearer General Packet Radio Service (GPRS).
  • GPRS General Packet Radio Service
  • GPRS is a second-generation wireless system, it is linked with basic functions to support PS services.
  • P-CSCF and GPRS must be in the same network.
  • UE A exists in any Visited Network, and UE A and P-CSCF exist in the network.
  • S-CSCF Serving CSCF
  • HSS Home Subscriber Server
  • the S-CSCF can receive the message and connect to another CSCF in the vicinity or connect to the Application Server (AS) and forward the SIP message to another AS.
  • Interrogating CSCF (I-CSCF) performs the same proxy server function as P-CSCF, but is connected to an external network.
  • the process of encrypting SIP messages can be performed by observing network availability and network configuration.
  • HSS is a central data server that contains user-related information.
  • the Subscriber Location Function (SLF) represents an information map linking a user's address to a corresponding HSS.
  • the Multimedia Resource Function (MRF) includes multimedia resources in the home network. MRF consists of Multimedia Resource Function Controller (MRFC) and Multimedia Resource Function Processor (MRFP).
  • MRFC is a control plane of MRC and plays a control role of managing stream resources within MRFP.
  • the Breakout Gateway Control Function (BGCF) is a SIP server that is connected to Public-Switched Telephone Network (PSTN) or Communication Server (CS) and represents a gateway that transmits SIP messages.
  • PSTN Public-Switched Telephone Network
  • CS Communication Server
  • MGWF Media Gateway Control Function
  • MGW Media Gateway
  • 16 illustrates a call connection between UEs according to embodiments.
  • IP connection In an IMS-based network, an environment where IP connection is possible is required, and IP connection is performed in the Home Network or the Visited Network.
  • an IP connection When an IP connection is established, an interactive environment composition, which is a detailed element of XR, is formed, and the transmitted data is virtual reality such as 360 Video/G-PCC (Geometry-based Point Cloud Compression)/V-PCC (Video-based Point Cloud Compression). Information in which data is compressed is exchanged or data is transmitted. XR data can be subdivided into two areas and delivered.
  • the AS When transmitted based on the MTSI standard, the AS transfers the Call/Hold/Resume method through Route Control Plane signaling using the CSCF mechanism and performs a third party call connection.
  • media transmission When a call connection is performed, media transmission is simply transmitted between UEs A and B, and when two UEs exist, MTSI operates as shown in FIG. 16 within the IMS network.
  • FIG 17 shows an apparatus for transmitting and receiving point cloud data according to embodiments.
  • the video encoder and audio encoder may correspond to the XR device 100c, the encoding in FIG. 8 (S1520), and the point cloud encoder in FIG. 9, FIG. 11, and FIG. 13.
  • the video decoder and the audio decoder may correspond to the XR device 100c, the decoding in FIG. 8 (S1540), the point cloud decoder in FIG. 10, FIG. 12, and FIG. 14.
  • MTSI limits the relevant elements and connection points of Client Terminals within the IMS network. Therefore, the scope for the configuration is defined as shown in FIG.
  • the determination of the physical interaction of synchronization related to the speaker, display, user interface, microphone, camera, and keyboard is not discussed in MTSI.
  • the area within box 170 determines the scope of how to control media or related media.
  • transmitting SIP corresponds to IMS
  • MTSI does not include a part that controls specific SIP. Therefore, the range of MTSI and IMS can be determined according to the data structure, delivery method, and service definition. If it is defined like MTSI, it can be defined as a standard within the following range.
  • RFC 4566-based SDP and SDP Capability Negotiation must be used and related Streaming Setup must be used.
  • the transmission medium that transmits media must comply with not only Coded Media (to which Transport Protocol is applied) but also Packet-based Network Interface.
  • the method of transmitting data uses RTP Stream of RFC 3550, and SCTP (RFC 4960) or WebRTC Data Channel can be used for Data Channel.
  • Devices for transmitting and receiving point cloud data may include all devices configured as devices such as mobile phones, desktops, and AR glasses. Assuming that it is a mobile phone, there are a speaker, display, user interface, microphone, camera, and keyboard, and the input signal can be transmitted to the encoding/decoding block.
  • Methods/operations according to embodiments may be processed by the video encoder of FIG. 17 . It can be linked with software.
  • the G-PCC structure call flow may be included in a session setup & control part.
  • Each component of FIG. 17 may correspond to hardware, software, processor, and/or a combination thereof.
  • An apparatus for transmitting and receiving point cloud data may support IP connection.
  • XR range exists in RAN (Radio Access Network) such as UMTS (Universal Mobile Telecommunications System) and Visited Networks such as SGSN (Serving SPRC Support Node) and GGSN (Gateway GPRS Support Note) roaming service and IP connectivity scenarios should be considered. If IP connectivity is to be considered, IP service must be provided even where the IMS network does not exist, and GPRS (General Packet Radio Service) roaming must also be connected to the home network. If an IMS-based network is provided, End-to-End QoS (Quality of Service) must be provided to maintain IP connectivity.
  • RAN Radio Access Network
  • UMTS Universal Mobile Telecommunications System
  • Visited Networks such as SGSN (Serving SPRC Support Node) and GGSN (Gateway GPRS Support Note) roaming service and IP connectivity scenarios should be considered. If IP connectivity is to be considered, IP service must be provided even where the IMS network does not exist, and GPRS (General Packet Radio Service) roaming must also
  • QoS Requirement generally uses SIP (Session Initiation Protocol) to define a session, change a session, or terminate a session, and can deliver the following information: type of media, direction of traffic (upward or downward), Bitrate, Packet Size, Packet Transport Frequency, RTP Payload, Bandwidth Adaptation.
  • SIP Session Initiation Protocol
  • An apparatus for transmitting and receiving point cloud data may perform IP policy control/secure communication.
  • the Policy Control Element can activate a bearer suitable for media traffic through a SIP message, and prevents the operator from using bearer resources incorrectly.
  • the IP address and bandwidth of transmission and reception can also be adjusted equally at the bearer level.
  • a start or stop point of media traffic can be set using a policy control element, and problems related to synchronization can be solved.
  • a acknowledgment message can be transmitted through the IP network using the Policy Control Element, and the Bearer service can be modified, stopped, or terminated.
  • Privacy can be requested for the security of the UE.
  • An apparatus for transmitting and receiving point cloud data may be associated with other networks.
  • the IMS network of any type of terminal should be able to connect various users and networks as much as possible. It can include PSTN or ISDN as well as mobile and Internet users.
  • the entity visiting the Visited Network provides service and control information for the user and performs Registration/Session Establishment within the Internet network. In this way, if it exists in the Visited Network, service control restrictions occur, and considerations arise according to multiple roaming model scenarios.
  • the quality may deteriorate due to the service speed of the Visited Network.
  • a role such as security or charging is added, the area of service control and execution method for the Home Network/Visited Network should be considered.
  • the 3GPP standard defines the architecture layered in the IMS network. Therefore, Transport/Bearer are defined separately.
  • the application plane generally covers the scope of the application server, the control plane can be divided into HSS, CSCF, BGCF, MRFC, MRFP, SGW, SEG, and the user plane can be divided into SGSN, GGSN, IM-MGW, etc.
  • FIG. 18 shows an architecture for XR communication on a 5G network according to embodiments.
  • An apparatus for transmitting and receiving point cloud data may efficiently perform XR communication based on a communication network, as shown in FIG. 18 .
  • Real-time point cloud two-way conversation using 5G networks can be achieved using three methods. 1) point cloud data exchange using IMS telephone network, 2) point cloud data streaming using 5GMS media network, 3) web-based media transmission method using WebRTC. Therefore, it is necessary to define an XR interactive service scenario to transmit data. Scenarios can be delivered in various forms, and can be divided into the process of acquiring data, the process of all end-to-end services using the 5G network, and the composition of scenarios.
  • Application Download In order to proceed with the XR Teleconference, Application Download must be performed in advance.
  • a built-in or downloadable application program is required. This program can transmit data by selecting 1) telephone network 2) media network 3) web network as the transmission type of data transmitted through 5G.
  • the program When the program is installed, check the access authority of the general device and the account personal information authority to check the basic environment for sending and receiving data.
  • Capture equipment of point cloud equipment including a receiving device and a transmitting device for receiving the other party's data, or a converter capable of converting dimensional data into 3D, or any video input capable of transmitting or converting data in 3D at 360 degrees.
  • Voice data includes a built-in microphone or speaker, and also includes a check of hardware capabilities to minimally process point cloud data.
  • Hardware includes GPU/CPU functions that can perform Pre-Rendering or Post-Rendering, and may include hardware capacity and memory size performed during processing.
  • Personal information includes things that can additionally deliver real-time information of users such as account information for accessing applications, IP, and cookies, and use consent is performed to transmit in advance.
  • Figure 19 shows a structure for XR communication according to embodiments
  • an identifier that can distinguish between user authentication and user is created.
  • users are distinguished by using e-mail or ID and password, and the authenticated user's tag is formed by itself.
  • a guide mode for an initial user to effectively exchange point cloud data or use a system may be provided.
  • it can determine how the field of view can be accessed. If it is a device capable of directly capturing or receiving a point cloud, data can be transmitted and received as it is. If a point cloud is received using an HMD, scaling or transformation suitable for a 360 degree environment must be preceded.
  • the received display is a 2D display based on a commonly used mobile phone or monitor rather than a device that receives 3D data, it should be able to faithfully express 3D within a 2D screen.
  • a method of rotating or enlarging the screen with a finger it is possible to implement or check a 3D image in a 2D display.
  • an avatar In order for a user to express himself in a 3D space, an avatar must be created.
  • the avatar can be virtual data by graphic, 3D transformation form of a person or object directly acquired as a point cloud, or audio without any data.
  • Avatar expressed in 3D can be modified by the user's definition or selection. For example, a person can change the shape of their face or wear clothes, hats, accessories, etc. that can represent their individuality, and can transform into various forms to express their individuality.
  • emotions can be expressed through conversations between people, and emotions can be adjusted according to changes in the face shape of text or graphics.
  • the created avatar participates in a virtual space. If it is 1:1 interactive, each data is transmitted to the other party, but the space where the other party receives it also needs to be formed simply. When there are multiple participants, spaces that can be shared by multiple participants must be created, and these spaces can be spaces composed of arbitrary graphics or data spaces directly obtained as point clouds. Depending on the size and situation of the data to be shared, the data can be stored in each device and processed quickly, and if the size of the data is large, it can be stored in the cloud or central server and shared. As the user's avatar, an avatar created in advance using a library or the like may be used. A basic common avatar therefore does not need to be newly created from the user's point of view or to capture and transmit data.
  • various objects used in the space may be added according to a user request, and the data may be graphics or data acquired as a point cloud.
  • objects can be objects that are easily accessible or familiar in the conference room, such as documents, cups, and laser pointers.
  • users composed of respective avatars can participate in the space, and the user can participate in the meeting place by moving his or her avatar to the created space.
  • the space is determined by the host in charge of the meeting, and the host can change the space by selecting it. Acquisition of a well-known conference hall in advance can give the effect of attending a company meeting room at home, and obtaining an overseas travel or famous historical site can give the effect of meeting at home at the historic site.
  • the space created with virtual random graphics rather than point clouds may vary depending on the idea or implementation method of the space organizer who creates the user's space.
  • a user participates in a space, he or she can enter by forming a user profile.
  • the user's profile is used to classify the list of conference hall or space participants, and if multiple users participate, it is possible to check whether a conversation is possible and whether the user's receiving status is working correctly.
  • the user's name or nickname should be displayed, and whether the user is currently busy or muted should be displayed.
  • Space limitations may vary depending on the application constituting the host or server. In an environment where free movement in space is restricted, the user must be able to move to a desired location.
  • 20 illustrates a protocol stack for XR interactive service on 3GPP 5G according to embodiments.
  • 5G XR media can be transmitted in a variety of ways. 1) point cloud data exchange using IMS telephone network, 2) point cloud data streaming using 5GMS media network, 3) web-based media transmission method using WebRTC, WebRTC method shares two data at the application level .
  • each transmission protocol is defined, and transmission and reception must be performed in compliance with the specifications.
  • XR Conversational Service needs to add dimension information and data parameters to observe QoS.
  • fast data processing and low-latency conversation service are possible because the data is transmitted using the real-time telephone network.
  • there is no protocol for recovering errors in transmission escape there is a disadvantage of having to proceed with a conversation by relying on continuous feedback information.
  • Point cloud-based real-time two-way video conversation can be divided into 1:1 conversation transmission and participation in multiple video conferences like a single phone call.
  • both scenarios require a processor that handles media rather than directly delivering data, and must be provided in an environment where virtual meetings can be held.
  • 21 illustrates point-to-point XR videoconferencing according to embodiments.
  • the basic phone call request of the conversation is processed by the network function, and when using the MTSI network, the transmission and reception media uses MRF (Media Source Function) or MCU (Media Control Unit).
  • MRF Media Source Function
  • MCU Media Control Unit
  • the MRF/MCU receives point cloud compressed data, and when the sender wants to transmit additional information (view screen, camera information, view direction, etc.) in addition to the compressed data, the data is also transmitted to the MRF/MCU.
  • a video is created through an internal process, and one video includes a main video and several thumbnails.
  • the processed video is delivered to each receiver again, and processing such as transcoding and resize may occur. If MRF requires a process such as transcoding, it may have an effect of increasing the maximum delay time by the processing time.
  • a pre-processing process may be performed by transmitting thumbnail data to each sender and receiver in advance.
  • MRF performs audio and media analysis, application server, billing server linkage, and resource management functions.
  • the AS (Application Server) connected to the MRF includes the HSS linkage function for checking the subscriber's status in the telephone network and provides MRF connection and additional functions. Additional functions include a password call service, lettering service, ringback tone service, incoming and outgoing call blocking service, etc. on a real phone.
  • each user must have a 3D point cloud capture camera.
  • the camera must include the user's color information, location information, and depth information. If depth cannot be expressed, a converter capable of expressing a 2D image in 3D can be used.
  • the captured information used includes geometry-based point cloud compression (G-PCC) or video-based point cloud compression (V-PCC) data.
  • G-PCC geometry-based point cloud compression
  • V-PCC video-based point cloud compression
  • the transmitter must have equipment capable of receiving the other party's data.
  • Receiving equipment generally refers to any equipment that can represent the acquired point cloud data. Therefore, it can be a 2D-based display and can include all equipment capable of visually expressing point cloud graphics such as HMD and holographic.
  • the expressed data must be capable of receiving and processing the data transmitted from the MRF/MCU where the transmission and receiver data are processed.
  • the captured point cloud data is transmitted to the MRF/MCU, and the received data generates and transmits data to each user by an internal process. It transmits basic information necessary for a conversation, a virtual space of a conversation where a conversation is required, or view information of a point of view desired by the other party, or transmits compressed data.
  • the virtual space is simply used as a space to simplify by projecting a point cloud, and if the projection space is not used, all data captured by the camera is simply transmitted to the other party.
  • B and C require an application to operate a video conference.
  • the application checks the following basic service operations.
  • Transmitter Check AR Glass, 360 Camera, Fisheye Camera, Phone Camera, Mic, Kinnect, LiDAR, etc.
  • B and C acquire point data to transmit to the other party using a point cloud capture camera before participating in a conversation.
  • the point data is generally data obtained by acquiring faces or shapes of B and C, and data acquired through each unique equipment can be output.
  • the above scenario can be implemented based on a simple telephone network in an environment that does not know any media.
  • Prior data must be received through MRF/MCU before creating a telephone network, and MRF/MCU receives all data transmitted from B and C.
  • the video conversation scenario of two people in a point cloud is divided into two types as follows.
  • scenario (a) all data is transmitted in a one-to-one conversation. All point cloud information of B is directly delivered to C, and C can process all of B's data or partially process it based on the additional information delivered from B. Similarly, B needs to receive all the point cloud data transmitted by C and can process some based on the additional information transmitted by C.
  • scenario (b) MRF/MCU exists between the telephone networks, and B and C deliver point cloud data to the MRF/MCU existing between the two. The MRF/MCU processes the received data and delivers the corresponding data to B and C according to the specific conditions requested by B and C. Therefore, B and C may not receive all the data from the point cloud they send to each other.
  • the multiperson video conference function can also be expanded, and an additional virtual space A can be included and delivered to B or C.
  • an additional virtual space A can be included and delivered to B or C.
  • B and C rather than directly receiving a point cloud, it is possible to place B and C in a virtual meeting space and transmit the entire virtual space to B and C in the form of a third person or a first person.
  • David (D) participating, B, C, and D can freely talk to each other in the space of A.
  • FIG. 22 shows an XR videoconferencing extension according to embodiments.
  • the MRF/MCU can receive each data and process one data, and its schematic diagram is represented as shown in FIG. 22.
  • B, C, and D deliver the acquired point cloud data to MRF/MCU.
  • Each received data forms one unit frame by transcoding and creates a scene that can compose the data of the aggregated points.
  • the composition of the scene is given to the person who requested hosting among B, C, and D, and in general, a point space can be created by forming various scenes.
  • MRF/MCU transmits all or part of the point cloud data based on the received data information and the camera Viewpoint and Viewport requested by B, C, and D. can be conveyed
  • Figure 23 shows XR videoconferencing extensions according to embodiments.
  • B who has host authority, can share his data or screen with conference participants.
  • Data that can be shared includes media that can be delivered to a third party, such as overlay form, independent screen, data, etc., other than image dialogue.
  • B transmits the data to be shared to the MRF/MCU, and C and D can receive the shared data by their own request.
  • SDP can be used to determine the number of Overlays or Laying, and capability must be measured whether all data can be received during the Offer/Answer process and whether all data to be delivered can be received. This process can be determined at the beginning of participation in multiple conferences, and data processing capability for each user can be confirmed when a telephone network is created when a data sharing function must be provided by default.
  • Sharing data is generally created to share some or all of the screens of applications running in the host during a conversation, such as presentation files, excel files, and desktop screens. The generated data is compressed or the resolution is converted and delivered to the user who wants to receive it.
  • this document provides an efficient human eye tracking and recognition system for real-time and bi-directional 3D acquisition of a user's face and a realistic virtual conversation and conferencing system capable of having a conversation in a virtual environment. Describe how to do it.
  • a camera field capable of recognizing a plurality of people
  • a point camera capable of physically acquiring a user's shape or face
  • a color camera capable of expressing depth
  • a method of recognizing and classifying objects of people or objects is considered important.
  • Most 3D technology methods use a sensor recognition method using LiDAR, and in particular, point cloud data acquired in real time is used in a method of recognizing objects such as animals, people, and cars.
  • a service network in order to achieve interactive service of real-time point cloud, a service network is required.
  • the service network connects to the Internet or a wireless network, transmits user information in both directions, and acquires initial data. Acquired data includes all of acquiring overall information about what kind of user the user is and what kind of service the user wants.
  • the real-time point cloud can perform a service using a network to be previously delivered in order to acquire the service.
  • the service should add detailed rules to implement the service for each connection point, rather than simply activating the service. The rules must be fixed and cannot be utilized by simply using the method of the existing system as it is.
  • the existing telephone network is used.
  • the telephone network is generally transmitted based on the voice of conversation, and since it is based on the voice of conversation, as shown in FIG. 24 or 25, a method for correcting the voice to be transmitted or protecting errors is proposed There is not.
  • discussions have been made to transmit high-capacity and high-definition media such as VR through a telephone network, but it is difficult to expand and use the existing method as it is.
  • 24 is a flowchart illustrating an example of a process of creating a basic telephone network for forming a 1:1 conversation.
  • a user equipment communicates with a base station and / or other user equipment using a radio access technology (eg, 5G New RAT (NR), Long Term Evolution (LTE)) device (e.g., smart phone) that
  • a radio access technology e.g, 5G New RAT (NR), Long Term Evolution (LTE)
  • NR 5G New RAT
  • LTE Long Term Evolution
  • smart phone e.g., smart phone
  • Session Description Protocol is a protocol for negotiating media types and formats related to multimedia sessions between terminals, and operates in an offer and answer model.
  • UE B and UE C perform five basic transmission processes to create a media-based phone call.
  • UE B transmits an SDP offer message to UE C to find out whether UE C can perform the corresponding function (S50001).
  • the transmitted SDP offer message (or SDP offer information) includes basic information on whether a video codec can be supported or whether an audio parameter can be supported.
  • UE C grasps the SDP offer message for connection with UE B, determines the same or possible parameters for actually possible content, and delivers an SDP answer message including it to UE B (S50002). If the contents of the SDP offer and the SDP answer are not different in this process, the telephone network is formed.
  • UE C converts the media into RTP (Real Time Transport Protocol) packets and transmits the media through a route (flow) on which a telephone network is formed (S50003).
  • RTP Real Time Transport Protocol
  • video codecs to be used for RTP transmission include AVC, HEVC, and the like.
  • data transmitted through the RTP packet may optionally receive a feedback signal based on RTCP (Real Time Transport Control Protocol) (S50004).
  • RTCP Real Time Transport Control Protocol
  • the feedback signal refers to a parameter continuously transmitted from UE B to UE C at a predetermined period.
  • step S50004 that is, a feedback process is included
  • UE C may deliver media to UE B again based on the feedback parameters (S50005).
  • the retransmitted media may be media modified and optimized to some extent suitable for each network or UE B in the existing media to be transmitted.
  • 25 is a flowchart illustrating another example of a process of creating a basic telephone network for forming a 1:1 conversation.
  • MRF/MCU media source function
  • MCU media control unit
  • UE B delivers an SDP offer message to UE C, but intermediate data passes through the MCU/MRF present in the IMS network (ie, telephone network).
  • the SDP offer message provided by UE B is delivered to the MCU/MRF (S50011).
  • the MCU/MRF transfers the received SDP offer message to UE C as it is (S50012).
  • UE C grasps the SDP offer message for connection with UE B, determines the same or possible parameters for actual possible content, and delivers an SDP answer message including it to the MCU/MRF (S50013).
  • the SDP answer message returned by UE C is a message that occurs between UE B and UE C in the same way as a 1:1 conversation.
  • the MCU/MRF forwards the received SDP answer message to UE B as it is (S50014).
  • the MCU/MRF can acquire in advance that a telephone network is formed between UEs through the received SDP offer message/SDP answer message, and prepares data service in the middle based on the information obtained in advance.
  • UE C converts the media into RTP packets and transmits them to the MCU/MRF through the RTP media flow (S50015).
  • the MCU/MRF delivers the received RTP packet as it is to UE B through the RTP media flow (S50016).
  • data transmitted through the RTP packet may optionally receive a feedback signal based on RTCP (S50017).
  • the feedback signal refers to a parameter continuously transmitted from the UE B to the MCU/MRF at a predetermined period.
  • step S50017 that is, RTCP feedback is performed
  • UE B transmits feedback information to the MRF/MCU.
  • the transmitted feedback information is processed in the MRF/MCU, and the MRF/MCU also processes data (i.e., media) received from UE C.
  • the processed media is delivered to UE B in the form of an RTP packet (S50018).
  • the retransmitted media may be media modified and optimized to some extent suitable for each network or UE B in the existing media to be transmitted.
  • the existing IMS network transmission form generates and delivers an SDP negotiation message for media transmission.
  • the existing method is not suitable for media processing for transmitting high-capacity media such as point clouds. That is, in the case of one-to-one communication, point cloud data can be transmitted, but there is no processing method for processing high-capacity data generated in the telephone network, and when multiple users have a video conference in the form of a point cloud, the contents The method to deliver and process cannot be solved by the existing method.
  • high-capacity point cloud data is transmitted through a single IMS network, but internal equipment cannot perform all functions.
  • connection flow for service registration, basic data exchange, and service registration process for proceeding point cloud-based interactive service in the existing network will be described next.
  • This document includes VR (Virtual Reality) of MTSI of 3GPP TS 26.114 and XR (Extended Reality) of TR26.928, and includes 3GPP TS26.223 standard that discusses IMS-based Telepresence.
  • 3GPP TS26.223 standard discusses IMS-based Telepresence.
  • a mobile or separate receiver can participate in a immersive conference by attending a virtual conference.
  • interactive data can be delivered in media format
  • this document includes 5G Media Architecture 3GPP TS26.501, TS26.512, TS26.511. Additionally, related standards may include TS26.238, TS26.939, TS24.229, TS26.295, TS26.929, and TS26.247 for the specification of services.
  • FIG. 26 is a detailed block diagram of an IM subsystem according to embodiments.
  • a thick line represents traffic delivered to the IP multimedia network
  • a dotted line represents a portion through which an interface related to signaling is delivered.
  • Multimedia can work interchangeably with either IMS or non-IMS networks, and only IMS networks are dealt with in this document.
  • CSCF Call State Control Function
  • Proxy CSCF acts as a SIP proxy server.
  • the P-CSCF internally analyzes and transmits SIP messages in order to receive all SIP messages and deliver them to the UE to transmit.
  • P-CSCF can perform resource management and is closely connected to the gateway of the network.
  • MRF Multimedia Resource Function
  • MRF includes multimedia resources in the home network.
  • MRF consists of Multimedia Resource Function Controller (MRFC) and Multimedia Resource Function Processor (MRFP).
  • MRFC is a control plane of MRC and plays a control role of managing stream resources within MRFP.
  • the Breakout Gateway Control Function is a SIP server that is connected to Public-Switched Telephone Network (PSTN) or Communication Server (CS) and represents a gateway that transmits SIP messages.
  • PSTN Public-Switched Telephone Network
  • CS Communication Server
  • IM-MGW plays a role in delivering interface and signaling for delivering media to CS network.
  • MRF performs the main function of delivering characteristics by integrating all networks and applications.
  • MRF can control multiple services, media, control protocols, codecs, and platforms by controlling one media processing unit, which is generally required for independent media.
  • a telephone network for processing high-volume media includes a method using MRF and a method of applying a cloud process in UE without using MRF, and a signal transmission scheme for the method will be described below.
  • the UE internally accesses the cloud service, not the IMS network, to activate the cloud service.
  • the activated cloud service can be used in two ways.
  • One method is an internal data processing method
  • the other method is an external data processing method. That is, large-capacity transmission and reception of point cloud data is entrusted to MTSI, and data obtained in real time is processed in the cloud.
  • FIG. 27 or 28 it is necessary to access the cloud in the SDP negotiation process, and the service registration process proceeds as shown in FIG. 27 or 28. That is, FIGS. 27 and 28 define a session flow for transmitting/receiving point cloud data (eg, G-PCC data or V-PCC data) between UEs.
  • the edge enabler client and the edge enabler server constituting the enabler are functional blocks used for distributed processing. This document aims to enable 1:1 XR communication between UE B and UE C using this function.
  • the edge enabler may process them instead. So, even if the computer is not very good, it can replace high-capacity computing.
  • MTSI is an IMS-based standard for transmitting Conversational Speech, Video, and Text through RTP/RTCP, and was established to provide users with the same or higher efficiency services than the existing Circuit Switched (CS)-based Conversational Service through Flexible Data Channel Handling. It became. MTSI includes not only Signaling, Transport, Jitter Buffer, Management, Packet-Loss Handling, and Adaptation, but also Adding/Dropping Media During Call, etc., so that predictable media can be created, transmitted, and received. Since MTSI uses the 3GPP network, NR, LTE, and HSPA are connected to IMS, and Wi-Fi and Bluetooth are also extended and connected.
  • MTSI transmits and receives data negotiation messages to the existing IMS network, and has a structure in which data is transmitted between users when transmission and reception are completed. Therefore, the IMS network can be equally used, and MTSI additionally defines only Audio Encoder/Decoder, Video Encoder/Decoder, Text, Session Setup and Control, and Data Channel.
  • the system may include at least a plurality of user equipments (UEs), an Edge Enabler Client, and an Edge Enabler Server.
  • UEs user equipments
  • Edge Enabler Client is also referred to as Edge Enabler
  • Edge Enabler includes Edge Enabler Client and Edge Enabler Server.
  • UE B and UE C form a telephone network according to UE B's request.
  • UE B and UE C perform a cloud service initialization process before establishing a telephone network.
  • UE B considers a trigger condition before forming a telephone network with UE C.
  • edge enabler existence PDU session formation, geographical location information, and periodic timing inspection are performed.
  • the cloud service is available, the UE B performs a discovery request to itself, that is, to an edge enabler client closest to the UE B, using an application (S50021).
  • Discovery execution includes query values for the purpose of data operation processing, rendering, etc. according to the purpose to be used, and the value to be transmitted is included in the application tag, location, etc.
  • the enabler can proceed with checking the authority of the value that the Edge Enabler Client transmits to the Edge Enabler Server. If the received request value is suitable for the requirements to be transmitted, it is possible to proceed to the next step. That is, when suitability is confirmed, information such as an IP address is tracked, and a discovery response is performed including information related to the Edge Enabler Server, such as whether or not it is connected to the located Edge Data Network (S50022).
  • UE B After UE B acquires the available features of the Edge Enabler Server, it inserts an SDP offer message including parameters, edge possibilities, and available capabilities suitable for the requirements, and delivers it to UE C. If discovery is obtained, the SDP offer message provided by UE B is delivered to the Edge Enabler Server (S50023), and the Edge Enabler server forwards the received SDP offer message to UE C (S50024).
  • UE C when UE C wants to use edge computing, UE C performs a service discovery process using its own Edge Enabler, that is, existing in UE C. That is, UE C performs a discovery request to itself, that is, to an edge enabler client closest to UE C, using an application (S50025).
  • Edge computing refers to performing computing at or near the physical location of a user or data source. Processing computing services in a location close to the user's terminal device provides users with faster and more reliable services, and businesses can benefit from flexible hybrid cloud computing.
  • Edge computing is one way enterprises distribute data computation and processing by using a common pool of resources in multiple locations.
  • edge computing is about running fewer processes in the cloud and moving those processes to a local location, such as on the user's computer, IoT device, or edge server. Bringing computing to the edge of the network minimizes the amount of long-distance communication required between clients and servers.
  • This document enables Edge Enabler Server and Edge Enabler Client to be used in the telephone network.
  • UE B and UE C may have different edge enabler clients and edge enabler servers depending on the location of a user (ie, UE).
  • UE ie, UE
  • FIG. 27 it is assumed that one Edge Enabler client and one Edge Enabler server exist for the sake of understanding.
  • the Edge Enabler server delivers a discovery response to the Edge Enabler discovery request received from UE C to UE C (S50026).
  • UE C adjusts appropriate parameters or possible parameters in response to the SDP Offer message received in step S50024, and transmits an SDP Answer message including these parameters to UE B. If edge computing is intended to be used and the value is acquired, UE C forwards the SDP Answer message to the Edge Enabler server, and the Edge Enabler server forwards the received SDP Answer message to UE B as it is (S50028).
  • UE C converts the media to be delivered into RTP packets and transmits them to the Edge Enabler server through the RTP media flow (S50029).
  • the Edge Enabler server delivers the received RTP packet as it is to UE B through the RTP media flow (S50030).
  • a video codec used in the 3GPP standard to be transmitted through the RTP media path AVC, HEVC, and the like are generally used.
  • the Edge Enabler server may determine whether or not to process media received from UE C in the form of an RTP packet. If an additional process such as split rendering is performed using the Edge Enabler server, the RTP packet after this additional process is performed is delivered to UE B.
  • data transmitted through the RTP packet may optionally receive a feedback signal based on RTCP (S50031).
  • the feedback signal refers to a parameter continuously transmitted from the UE B to the MCU/MRF at a predetermined period.
  • step S50031 that is, when RTCP feedback is performed, UE B transmits feedback information to the Edge Enabler server.
  • the transmitted feedback information is processed in the Edge Enabler server, and the Edge Enabler server also processes data (ie, media) received from UE C (S50032). That is, when a feedback process is included, UE C can deliver media to UE B again based on the feedback parameters.
  • the retransmitted media may be media modified and optimized to some extent suitable for each network or UE B in the existing media to be transmitted.
  • S50021 to S50026 are referred to as a cloud service initialization process.
  • the cloud service initialization process some of the above steps may be omitted or some steps may be further included.
  • an Edge Enabler client may send a Configuration Provisioning Request directly to a data network without going through an Edge Enabler server.
  • the system may include at least a plurality of user equipments (UEs), an MCU/MRF, an Edge Enabler Client, and an Edge Enabler Server.
  • UEs user equipments
  • MCU/MRF user equipments
  • Edge Enabler Client an Edge Enabler Server
  • UE B and UE C form a telephone network according to UE B's request.
  • UE B and UE C perform a cloud service initialization process before establishing a telephone network.
  • UE B transmits the SDP offer message to the MCU/MRF (S50041).
  • the MCU/MRF determines whether or not to use the cloud function according to the profile of the delivered SDP offer message.
  • the MCU/MRF determines to use the cloud service according to the data transmission capacity and profile, it makes a discovery request to the Edge Enabler client existing in the network (S50042). Then, the Edge Enabler client transmits a Discovery Request to the Edge Enabler server connected within the network (S50043).
  • the discovery response value returned between the Edge Enabler client and the Edge Enabler server is delivered to the MCU/MRF via the Edge Enabler client. That is, the Edge Enabler server generates a Discovery Response to the Discovery Request and transfers it to the Edge Enabler client (S50044), and the Edge Enabler client transfers the received Discovery Response to the MCU/MRF as it is (S50045).
  • the value of the SDP offer can be changed.
  • the MCU/MRF transmits the SDP offer message to UE C (S50046).
  • UE C adjusts appropriate parameters or possible parameters based on the SDP Offer message received in step S50046, and transfers the SDP Answer message including these parameters to the MCU/MRF (S50047).
  • UE C converts the media to be delivered into RTP packets and transmits them to the Edge Enabler server through the RTP media flow (S50048).
  • the Edge Enabler server delivers the received RTP packet as it is to the MCU/MRF through the RTP media path (flow) (S50049).
  • RTP packets packetized in UE C are transmitted to the Edge Enabler server. If edge processing is not performed, RTP packets are forwarded to the MCU/MRF.
  • the MCU/MRF delivers the received RTP packet as it is to UE B through the RTP media flow (S50050).
  • data transmitted through the RTP packet may optionally receive a feedback signal based on RTCP.
  • the feedback signal refers to a parameter continuously transmitted from the UE B to the MCU/MRF at a predetermined period.
  • UE B transmits feedback information to the MRF/MCU (S50051).
  • the transmitted feedback information is processed in the MRF/MCU, and the MRF/MCU also processes data (i.e., media) received from UE C. If the feedback information is reflected in the Split Rendering process, the MCU/MRF transfers the received feedback information to the Edge Enabler server (S50052).
  • the media processed by the UE C is delivered to the Edge Enabler server in the form of an RTP packet (S50053), and the Edge Enabler server forwards the received RTP packet to the MCU/MRF (S50054).
  • the MCU/MRF forwards the received RTP packet to UE B (S50055). That is, if the cloud information is connected in advance, the media included in the RTP packet is processed by the cloud server (ie Edge Enabler server) and then delivered to the MRF/MCU, and the delivered media is transmitted to UE B by the process. do.
  • the retransmitted media may be media modified and optimized to some extent suitable for each network or UE B in the existing media to be transmitted. For parts not described in FIG. 28, FIG. 27 will be referred to.
  • S50041 to S50047 are referred to as a cloud service initialization process.
  • the cloud service initialization process some of the above steps may be omitted or some steps may be further included.
  • the following effects can be obtained. That is, it is possible to provide a signal delivery method capable of delivering point cloud data using a 5G telephone network.
  • the existing 5G telephony media network may or may not be used depending on the traffic and data processing capability of the telephone network, including whether or not the cloud network is used.
  • it can be easily linked with geometry information used in general G-PCC or V-PCC.
  • the media transmitted in the form of RTP packets may be XR data.
  • the XR data may be point cloud data.
  • the point cloud data may be G-PCC-based compressed data (referred to as G-PCC data) or V-PCC-based compressed data (referred to as V-PCC data).
  • the G-PCC data may include geometry information and/or attribute information compressed based on G-PCC.
  • the G-PCC data may include parameter sets such as SPS, GPS, and APS.
  • the next step is to form and transmit G-PCC data when a 5G network is used in a realistic virtual conversation and conference system that acquires a user's face in real time and in both directions in three dimensions and has a conversation in a virtual environment.
  • the service system using the 5G network connects to the Internet or a wireless network, transfers user information in both directions, and acquires initial data.
  • Acquired data includes all of acquiring overall information about what kind of user the user is and what kind of service the user wants.
  • the G-PCC data may be transmitted as media data or may be transmitted using a telephone network.
  • This document proposes a delivery method and configuration device for transmitting realistic point cloud data (eg, G-PCC data) using a 5G telephone network.
  • this document proposes an RTP packet structure for transmitting G-PCC data in RTP packets.
  • RTP Real Time Protocol
  • SDP Session Description Protocol
  • point cloud data is classified into V-PCC data or G-PCC data according to a compression method.
  • This document proposes an RTP packet structure for transmitting real-time point cloud data, especially G-PCC data, using a 5G network.
  • the V-PCC method is generally a method of converting realistic 3D point cloud data into a 2D video image and transmitting the video image.
  • a High Efficiency Video Coding (HEVC) bit stream is formed.
  • the HEVC bitstream can be applied and extended in the form of a NAL unit suitable for the existing RTP protocol.
  • G-PCC bitstream generated by compressing realistic 3D point cloud data using the G-PCC method
  • G-PCC data a G-PCC bitstream generated by compressing realistic 3D point cloud data using the G-PCC method.
  • the RTP protocol aims to transmit video coding units or voice data, a specific protocol for transmitting 3D virtual data such as a G-PCC bitstream is not implemented.
  • undefined data can be transmitted using the RTP header extension, data in a redundant form is repeatedly transmitted, so there is a need for efficiency of the data structure.
  • the data included in the payload of the RTP packet is not G-PCC data. Data cannot be identified. Also, the methods or parameters required for the process are not defined.
  • G-PCC codec parameters cannot be transmitted as they are in an extended method to the RTP protocol due to problems of Time Synchronization and Encoding Type. If G-PCC data is arbitrarily transmitted as the payload of the RTP packet, problems such as reduction in efficiency due to the header in the data set and the inability of a third party to grasp the structure of the content in the RTP payload occur. In addition, it is necessary to acquire all data and perform a decompression process rather than real-time data decoding.
  • G-PCC data is transmitted in RTP packets by simply extending the payload type nomenclature, it is necessary to expand the existing system in which parameter synchronization is not performed or consider a new transfer driving method.
  • a 3D-based video within a 2D-based video image it is configured based on a timestamp of 90000Hz, and when this method is used, it is easily synchronized with a television frequency rate such as HDTV and NTSC. can If an error such as resolution or jitter occurs, the receiver needs adjustment, so the timestamp value is not fixedly used.
  • the video formats currently supported by RTP are composed of CelB, JPEG, H.261, H.263, H.263-1998, MPV, MP2T, etc. by referring to the contents of the payload type (PT) value. It is defined as shown in FIG. 29.
  • 29 is a diagram showing an example of a payload type allocated to a payload type (PT) field in a header of an RTP packet according to embodiments. That is, the PT field indicates the type of data included in the payload of the corresponding RTP packet, and CelB, JPEG, H.261, H.263, H.263-1998, MPV, MP2T, etc. may be included in the payload. indicating that there is
  • This document can identify that data included in the payload of the RTP packet is G-PCC data by assigning an arbitrary value (eg, 72).
  • 3D video can be transmitted, but 3D and 2D information can be separated by media type, clock rate rate) cannot be defined. Therefore, information and configuration of independent or extended headers are required.
  • extension method can be useful for 1:1 delivery method, but when multiple users participate and share RTP packets, necessary element technology or information cannot be delivered within the 5G network.
  • general G-PCC compressed data is transmitted through existing RTP and an environment in which a large number of users participate is considered, the receiver obtains all data in advance and then performs G-PCC decoding or header information. A process of reprocessing after pre-acquisition is additionally required.
  • RTP is structured according to the G-PCC stream and new parameters are designed, header and data can be separated, and a plurality of immersive videos can be filtered using the separated information.
  • this document proposes the delivery structure of G-PCC data delivered in the 5G network, SDP negotiation, and related parameters, rather than the concept of simple extension as above.
  • the header extension function when using the header extension function by utilizing the RTP format, it is possible to modify the header of the RTP packet or to define information delivery according to the purpose to be added or used. However, since the definition of transmission is a variable and non-fixed value, the included information and parameters must be redefined.
  • a header of an RTP packet has a size of 12 bytes by default, and this header is referred to as a fixed header or a basic header.
  • the basic header includes V (version) field, P (Padding) field, X (Extension) field, CC (CSRC Count) field, M (Marker) field, PT (Payload Type) field, Sequence Number field, Timestamp field, Includes a Synchronization Source (SSRC) Identifier field.
  • the V (version) field has a length of 2 bits and indicates the RTP version.
  • the P (padding) field has a length of 1 bit and indicates whether one or more padding bytes are present at the end of a packet.
  • the X (Extension) field has a length of 1 bit or 3 bits and indicates whether an extension header is added after the basic header.
  • the CC (CSRC Count) field has a length of 4 bits and indicates the number of CSRC identifier fields displayed after a 12-byte basic header.
  • the M (Marker) field has a length of 1 bit and is used to indicate important events such as frame boundaries within a packet stream.
  • the PT (Payload Type) field has a length of 7 bits and indicates the payload type of the corresponding RTP packet.
  • the sequence number field has a length of 16 bits and is used to determine whether a packet is lost at the receiving side.
  • the sequence number field starts with a random number for security reasons, but increases by 1 whenever the number of packets increases.
  • the Timestamp field has a length of 32 bits and indicates the sampling moment of the first byte of the corresponding RTP packet.
  • the SSRC (Synchronization Source) Identifier field has a length of 32 bits, indicates a synchronization source, and is randomly determined.
  • a contributing source (CSRC) identifiers field may optionally be added to a basic header of an RTP packet.
  • the CSRC (Contributing Source) Identifiers field has a length of 32 bits and represents a case where multiple sound sources are integrated into one through an audio mixer.
  • RTP provides a header extension capable of transmitting additional additional information in addition to the basic header.
  • header extensions are referred to as extension headers.
  • the RTP packet may be composed of a basic header, an extension header, and a payload.
  • the extension header includes a 2-byte (i.e., 16-bit) defined by profile (a kind of identification information) field, a 2-byte length field, and an extension header body field into which actual data is inserted. can do. That is, one header is extended for each RTP packet, and the extended header includes a 16-bit profile field (ie, defined by profile or Identify), a 16-bit Length field, and/or an extended header body field.
  • profile a kind of identification information
  • the value of the 3-bit X field present in the basic header must be set to 1. If not set to 1, an RTP packet consists of only a basic header and payload. As such, in RTP, the structure of the header to be transmitted is essentially fixed. If a header is to be extended to transmit additional data, the above mandatory selection rules must exist. When a header extension value is expressed, the header of an RTP packet may be extended with one or more structures.
  • FIG. 30 is a diagram showing an example of a minimum extension structure of an RTP packet for transmission of G-PCC data according to embodiments. That is, it is an example of an extended header body field in which actual data is transmitted.
  • a 4-bit ID field represents an ID value capable of distinguishing the type of G-PCC bitstream.
  • the type of the G-PCC bitstream may be identified by taking a value of 1-14.
  • the value of 15 is stored in a preserved form and is not used according to regulations. If a value of 15 is recognized, the process stops without proceeding any further.
  • a 4-bit length field following the ID field indicates the length of data included in the extension header in bytes. For example, if the value of the length field is 0, it indicates that the extension header includes 1 byte of data, and if it is 15, it indicates that it includes 16 bytes of data.
  • 31 is a diagram showing an example of a profile and a length value defined before extension according to embodiments.
  • a 2-byte profile (ie, defined by profile) field allocates a fixed value as an example.
  • the profile field is fixed to a value of 0xBEDE.
  • a Length field of 2 bytes i.e., 16 bits may define the number of extensions actually occurring. For example, assuming that data is transmitted in a minimum extended structure, one unit is composed of 8 bits.
  • FIG. 32 is a diagram showing an example of an extension header of an RTP packet according to embodiments. That is, FIG. 32 is a diagram showing an example of a data field when the value of the length field of the extension header of the RTP packet is set to 1 and the value of the L field of the extension header body field is set to 3.
  • the L field indicates the length of the data field.
  • the data field may be referred to as a data chunk field.
  • initial data of the header of the RTP packet extended to transmit the G-PCC stream is a parameter (or referred to as parameter information or parameters) required as information for synchronizing a plurality of data.
  • the required parameter is a parameter used for the 5G network and serves as a separator that efficiently synchronizes and distinguishes a plurality of transmission parameters.
  • Parameters newly required for transmission of G-PCC data are as follows.
  • the parameters may include a T (Type) field, an F (Frame Type) field, an H (Header/Data) field, a HT (Header Type) field, an SPS_Flag (5 bit) field, and/or an SPS_atr_bitdepth field.
  • the T field indicates whether data transmitted in a corresponding RTP packet (or payload of the RTP packet) is V-PCC data (or referred to as V-PCC video) or G-PCC data (or referred to as G-PCC video). instruct The T field is referred to as a synchronization parameter.
  • the F field determines a frame type. For example, if the value of the F field is 0, it represents a pure video compression stream. That is, it represents a G-PCC stream in which no other encapsulation has been performed. If the value of the F field is 1, it represents G-PCC data configured in a TLV (Type-Length-Value) format, and if it is 2, it represents an ISO BMFF format stream combined with the PCC system. A value of 3 is kept in preserved form.
  • the H field identifies whether it is a header or data. For example, if the value of the H field indicates H, the header part is combined with the RTP header and transmitted. That is, when the value of the H field indicates H (ie, 0), it is recognized as a header to prevent a redundant transmission structure or to sequentially transmit profile-type data. If the value of the H field is 1, since there is no data that can be recognized as a header, the extended value provides only minimal information.
  • the HT field indicates an identifier capable of indicating SPS, GPS, and APS.
  • the value of the HT field is determined between 0 and 2.
  • the main profile values of the G-PCC bitstream are sequentially transmitted, and parameter delivery information related to the SPS is as follows.
  • the SPS_Flag field has a length of 5 bits, and each bit represents a binary value representing a flag.
  • 33 is a diagram showing an example of values allocated to an SPS_Flag field according to embodiments.
  • SPS_Flag field For example, if the value of the SPS_Flag field is 10000, G-PCC data transmitted in the corresponding RTP packet is compressed in simple mode, 01000 in dense mode, 00100 in prediction mode, and 00010 in main mode. indicates that it has been sent. And, if the value of the SPS_Flag field is 00001, it represents a combination of simple mode, prediction mode, and main mode.
  • the SPS_Flag field basically consists of 5 bits, but may consist of 2 bits depending on the compression method. If the SPS_Flag field consists of 2 bits, 0 may indicate simple, 1 dense, 2 prediction, and 3 main mode (or profile mode).
  • the SPS_atr_bitdepth field has a length of 4 bits and represents the value of the attribute_bitdepth_minus1 field.
  • the following are parameters for transmitting GPS, which are determined by the HT field value and are sequentially configured in a bit combination form.
  • a 1-bit Geom_tree_type field indicates whether slice point positions are coded using an accupancy tree or a prediction tree.
  • a 1-bit Inferred_direct_coding mode field indicates whether a direct_mode_flag field exists in a corresponding geometry node syntax. For example, if the value of the inferred_direct_coding_mode_enabled_flag field is 1, it indicates that the direct_mode_flag field exists in the corresponding geometry node syntax. For example, if the value of the inferred_direct_coding_mode_enabled_flag field is 0, it indicates that the direct_mode_flag field does not exist in the corresponding geometry node syntax.
  • a 1-bit Bitwise_occupnacy_coding_flag field indicates whether geometry node occupancy is encoded using bitwise contextualization of its syntax element occupancy map. For example, if the value of the bitwise_occupancy_coding_flag field is 1, it indicates that geometry node occupancy is encoded using bitwise contextualization of its syntax element occupancy_map. For example, if the value of the bitwise_occupancy_coding_flag field is 0, it indicates that geometry node occupancy is encoded using the directory encoded syntax element occupancy_byte.
  • Geom_tree_coded_axis_list_present_flag field indicates that the geometry data unit (GDU) header includes occtree_coded_axis syntax elements used to derive the node size of each occupancy tree level. If the value of the Geom_tree_coded_axis_list_present_flag field is 0, occtree_coded_axis syntax elements do not exist in the GDU syntax, and the occupancy tree represents a cubic volume.
  • a 4-bit log2_neighbour_avail_boundary_minus1 field indicates the value of the variable NeighbAvailBoundary used in the decoding process as follows (specifies the value of the variable NeighbAvailBoundary that is used in the decoding process as follows: ).
  • NeighbAvailBoundary 2 log2_neighbour_avail_boundary
  • NeighbAvailabilityMask may be set to 1. For example, if the value of the neighbor_context_restriction_flag field is 0, NeighbAvailabilityMask may be set to 1 ⁇ log2_neighbour_avail_boundary.
  • a 1-bit log2_intra_pred_max_node_size field specifies the octree nodesize eligible for occupancy intra prediction.
  • a 1-bit adjacent_child_contextualization_enabled_flag field indicates whether adjacent children of neighboring octree nodes are used for bitwise occupancy contextualization. For example, if the value of the adjacent_child_contextualization_enabled_flag field is 1, it indicates that adjacent children of neighboring octree nodes are used for bitwise occupancy contextualization. For example, if the value of the adjacent_child_contextualization_enabled_flag field is 0, it indicates that children of neighboring octree nodes are not used for bitwise occupancy contextualization.
  • the value of the 1-bit geometry_planar_enabled_flag field is 1, it indicates that the planar coding mode is active. If the value of the geometry_planar_enabled_flag field is 0, it indicates that the planar coding mode is not active.
  • the 1-bit geometry_angular_enabled_flag field indicates whether the geometry is coded using the previous set of beams located at the angular origin (whether geometry is coded using the priors of a set of beams located at, and rotating around the V-axis of, the angular origin).
  • some of the parameters mentioned above may be omitted, or other fields may be newly added.
  • the following are parameters for transmitting APS, which are determined by the HT field value and are sequentially configured in a bit combination form.
  • a 1-bit attr_coding_type field indicates a coding type for an attribute. According to embodiments, if the value of the attr_coding_type field is 0, the coding type may indicate predicting weight lifting, if it is 1, the coding type may indicate RAHT, and if it is 2, fix weight lifting may be indicated. .
  • a 1-bit num_detail_levels_minus1 field indicates the number of LODs for attribute coding (specifies the number of levels of detail for the attribute coding).
  • the 2-bit lod_decimation_mode field indicates the decimation method used to generate LODs.
  • a 1-bit lod_scalability_enabled_flag field indicates whether an attribute decoding process allows pruned occupancy tree decode results for input geometry points.
  • a 2-bit max_num_direct_predictors field indicates the maximum number of predictors to be used for direct prediction.
  • a 1-bit raht_prediction_enabled_flag field indicates whether transform weight prediction from the neighbor points is enabled in a RAHT decoding process. For example, if the value of the raht_prediction_enabled_flag field is 1, it indicates that transform weight prediction from the neighbor points is enabled in a RAHT decoding process, and if it is 0, it is disabled.
  • a 1-bit aps_coord_conv_flag field indicates whether an angular coordinate conversion process is applied to an attribute decoding process.
  • the basic table used in the above structure is applied as the G-PCC compression technology standard, but all or only part of the information is transmitted to the values used in the 5G network.
  • the actual values used for the available tabular SPS, GPS and APS can be summarized as below.
  • SPS sequence parameter set
  • the simple_profile_compatibility_flag field indicates whether the bitstream follows the simple profile.
  • the dense_profile_compatibility_flag field indicates whether the bitstream conforms to the dense profile.
  • the predictive_profile_compatibility_flag field indicates whether the bitstream conforms to the predictive profile.
  • the main_profile_compatibility_flag field indicates whether the bitstream conforms to the main profile.
  • the slice_reordering_constraint_flag field indicates whether the bitstream is sensitive to reordering and removal of slices.
  • the unique_point_positions_constraint_flag field indicates whether all points in each coded point cloud frame have unique positions.
  • the level_idc field indicates the level that the bitstream follows.
  • the sps_seq_parameter_set_id field provides an identifier for the SPS referenced by other syntax elements (provides an identifier for the SPS for reference by other syntax elements).
  • bypass_stream_enabled_flag field indicates whether the bypass coding mode can be used to read the bitstream.
  • FIG. 35 is a diagram showing an embodiment of a syntax structure of a geometry parameter set (geometry_parameter_set_RTP()) (GPS) according to embodiments. Since each field included in the GPS of FIG. 35 has been described above, it is omitted here to avoid redundant description.
  • FIG. 36 is a diagram showing an embodiment of a syntax structure of an attribute parameter set (attribute_parameter_set_RTP( )) (APS) according to embodiments.
  • the attr_coding_type field represents a coding type for an attribute. According to embodiments, if the value of the attr_coding_type field is 0, the coding type may indicate predicting weight lifting, if it is 1, the coding type may indicate RAHT, and if it is 2, fix weight lifting may be indicated. .
  • the aps_slice_qp_offset_present_flag field represents whether ash_attr_qp_delta_luma and ash_attr_qp_delta_chroma syntax elements are present in a corresponding attribute slice header (ASH).
  • the raht_prediction_enabled_flag field indicates whether transform weight prediction from the neighbor points is enabled in a RAHT decoding process.
  • the last_component_prediction_enabled_flag field indicates whether a primary component of a multi-component attribute is used to predict reconstructed values of non-primary components.
  • the lod_scalability_enabled_flag field indicates whether an attribute decoding process allows pruned occupancy tree decode results for input geometry points.
  • Adding 1 to the value of the max_nn_range_minus1 field indicates the maximum nearest neighbor range used to limit the distance of points registered as neighbors.
  • the max_num_detail_levels_minus1 field represents the maximum number of LODs for attribute coding.
  • the morton_sort_skip_enabled_flag field indicates whether a morton code sorting process is skipped.
  • lod_decimation_mode field indicates a decimation method used to generate LODs.
  • the lod_dist2_init field represents a value used to derive an initial slice subsampling factor used in LOD generation.
  • the aps_slice_lod_dist2_offset_present_flag field indicates whether a spatial subsampling factor offset exists in an attribute data unit.
  • the max_num_direct_predictors field represents the maximum number of predictors to be used for direct prediction.
  • the direct_avg_predictor_disabled_flag field indicates whether neighbor average prediction can be selected as a direct prediction mode.
  • the intra_lod_prediction_skip_layers field specifies the number of detail layers for which intra-layer prediction is disabled.
  • lod_search_range_intra field represents a search range used to determine nearest neighbors for intra-detail level prediction.
  • the inter_component_prediction_enabled_flag field indicates whether a primary component of a multi-component attribute is used to predict reconstructed values of non-primary components.
  • the neighbor_blending_enabled_flag field indicates whether neighbor weights used for prediction can be blended based on their related spatial positions.
  • the raw_attr_fixed_width_flag field indicates whether the number of bits used for coding raw attribute values is the same as the attribute component bit depth.
  • the aps_coord_conv_flag field indicates whether an angular coordinate conversion process is applied to an attribute decoding process.
  • the aps_extension_flag field indicates whether an aps_extension_data syntax structure exists in a corresponding APS syntax structure.
  • G-PCC data can be generated suitable for the RTP stream and combined with the payload unit.
  • a portion or all of the G-PCC data, a header unit of the G-PCC data, and the like may be distributed or combined with the payload of the RTP packet to form multiplexing.
  • some or all of the SPS, APS, and GPS may be included in the RTP packet.
  • G-PCC data can be transmitted using header extension as well as RTP streaming.
  • SPS, APS, and GPS for G-PCC can be transmitted through the header of the RTP packet.
  • actual G-PCC data (i.e., compressed geometry information and/or attribute information) is transmitted through the payload of an RTP packet, and signaling information such as SPS, GPS, and APS and/or actual G-PCC data.
  • Signaling information related to an RTP packet transmitting PCC data may be transmitted through an extension header of the corresponding RTP packet.
  • the header (eg, extension header) of the RTP packet transmitting the G-PCC data includes information for identifying whether data included in the payload of the corresponding RTP packet is G-PCC data (eg, T field) .
  • the header (eg, extension header) of the RTP packet includes information capable of identifying whether the parameter set transmitted through the RTP is SPS, APS, or GPS (eg, HT field).
  • the G-PCC data can be transmitted through the RTP protocol, and the receiver can identify and process the G-PCC data included in the RTP packet.
  • this document can transmit and receive G-PCC/V-PCC XR data through real-time telephone network.
  • RTP data can be transmitted to a telephone network and an external network, and a repeater or cloud processor can perform scaling, multiplexing, and transcoding of data.
  • an SDP negotiation process is performed before data (eg, G-PCC data) is transmitted through the RTP packet.
  • the SDP negotiation process is a process of determining whether transmitters and receivers (ie, UEs) connected to a telephone network have the ability to process transmitted/received data.
  • the SDP negotiation process is a process of transmitting an SDP offer message between UEs and receiving an SDP answer message.
  • data transmitted through an RTP packet during call connection between UEs can selectively receive a feedback signal based on RTCP.
  • This document configures attribute parameters of G-PCC data and transmits parsing information (eg, profile information of video data) in advance, so that the data to be transmitted (eg, G-PCC data) is simple, predictive, and dense (eg, G-PCC data) in the receiver. dense), it is possible to check in advance which profile mode is compressed in the main profile. In addition, it is possible to determine in advance whether or not the user has the ability to process data compressed by the corresponding profile.
  • the proposed method can be transmitted in a bypass method such as multi-parameters or video information parameters, it can be used only for G-PCC transmission calls. Therefore, in the process of SDP negotiation, a parameter indicating G-PCC can be obtained, and if a prior value is confirmed, the UE can check the profile and processing capability of the received video.
  • RTCP reverse direction
  • This method can be used as one of the network optimization parameters because it is delivered in the RTCP packet rather than the existing configurable attribute definition. Therefore, information of all data can be transmitted through RTP, but information can be exchanged distributed over RTCP.
  • RTCP is basically used as feedback information sent to the original sender at consistent or regular intervals. The loss of RTCP packets is therefore used to measure the quality of transmitters and receivers or to evaluate the quality of receivers over a period corresponding to a period.
  • the payload type is determined as 206, and the feedback information can be extended using parameters used for commonly known 360 video or realistic video.
  • the method using the existing method may refer to delivery of 2D video and utilization of VR standards based on this to express data related to the definition of metadata.
  • a region of interest is defined as a ROI (Region of Interest), which is used to define a part of a sphere expressed within the range of Elevation and Azimuth among 360 spheres.
  • ROI_ID can be identified by defining an identifier for each ROI when there are several ROIs. When ROI_ID is defined, each parameter corresponding to the ROI must be defined in detail.
  • ROI_type is used to define an Arbitrary/Pre-Defined ROI during initial negotiation. If it is defined as an Arbitrary ROI, since there is only one ROI_ID, the decoder does not have to process multiple ROIs.
  • ROI_IDs when defined as a pre-defined ROI, multiple ROI_IDs may be input.
  • the UE can select one of the received IDs and transmit it to the server, and data is initially transmitted based on the value.
  • ROI_Azimuth/ROI_Elevation values can be used.
  • the center value becomes a dot-shaped position focused on the user's focus and is used as the median value or reference point of the ROI.
  • ROI_azimuth_range/ROI_elevation_range indicates which angle is allowed based on the median value. If this value is small, the size of the ROI is implemented in a relatively small form, and if the angle is transmitted as a large value, the size of the ROI becomes relatively large.
  • ROI_Name is used when you want to use a character-type ROI identifier rather than an integer-type identifier, and it is not necessary to use it.
  • ROI_Description can transmit text-type sentences or paragraphs when additional explanation of metadata is required.
  • the text identifier defined as ROI_name can be expressed using a part thereof, and ROI_description describes detailed contents so that the user can check the description of the additional ROI while experiencing the service in the network.
  • ROI_expression uses a method for expressing ROI. To collect information related to the pre-defined ROI, the receiver collects a plurality of pre-defined ROI information, and the MTSI transmitter transmits the information. The ROI Index information determined during the SDP negotiation process is then used when feedback information of the ROI information is periodically received by the transmitter.
  • Pre-defined ROI can be determined bi-directionally or uni-directionally, and arbitrary ROI can be selected in a uni-directional environment. Therefore, the two parameters can be used together or simultaneously, but the pre-defined ROI is determined with priority. If the Pre-defined ROI does not exist, it can be checked whether the Arbitrary ROI parameter exists. If the two parameters do not exist, MTSI-based virtual conference transmission and reception must transmit all data without determining a recommendation or any Viewport-based ROI. When the received ROI information is obtained, the MTSI transmitter or receiver must encode or decode data according to the ROI, and the resolution present in the ROI is set higher than the resolution of the object present outside the background or viewing angle and transmitted.
  • the above concept can be used as it is for a G-PCC stream in which the center point is determined or known in advance.
  • a specific area of interest or median value can be used in a 3D system.
  • the SDP negotiation process must be preceded in the 5G network. And, after the negotiation is completed, media (eg, G-PCC data) is transmitted through RTP and information requiring feedback is transmitted through RTCP.
  • This negotiation process includes MTSI VR of 3GPP TS 26.114 and 3GPP TS26.223 standard that discusses IMS-based telepresence. Attributes are defined as follows based on the 3GPP VR Teleconference Permanent Document.
  • SP represents a space within ABNF grammar. If an attribute or specific content not defined in 3gpp_360video is input, it is assumed that the input signal is ignored, and the negotiation parameter is recognized in the form below. As in the actual example above, the value can be used as it is in the G-PCC-based video (or G-PCC data), and the process of identifying the system can proceed similarly.
  • the MTSI transmitter/receiver must be able to identify that the input signal is a virtual reality system within the 5G network by identifying the 3gpp_360video attribute during the SDP negotiation process.
  • the HEVC codec for video can use or include AVC and VVC codecs, and the NAL unit, which is a component of the codec, must contain decoder information or include related information.
  • HEVC Main 10 Profile, Main Tier, Level 5.1 must be supported as a minimum.
  • AVC Progressive High Profile, Main Tier, Level 5.1 must be supported as a minimum.
  • the user's Viewport information must be continuously delivered through RTCP feedback, and information related to Arbitrary/Pre-defined ROI is also included.
  • RTP header extension If additional data needs to be transmitted, it can be delivered through RTP header extension or related data can be delivered through data channel.
  • VDP Video Datagram Protocol
  • Sub-Picture Based Streaming Full maximum resolution video obtained by an omnidirectional camera is composed of a plurality of independent sub-pictures, which cover part of the entire content.
  • the user's viewport can observe a video composed of one or more subpictures. High quality video is sent to the viewport the user is currently viewing, and low quality video is sent to the other areas. is sent
  • the corresponding parameter may be implemented by passing a motion-constrained tile set or a sub-picture based flag.
  • Region-wise Quality Ranking Based on a specific region in a panoramic scene, region-based quality can be emphasized or the corresponding part can be encoded in high quality. Other areas may be transmitted after downscaling. For example, it can be transmitted in the form of a Truncated Square Pyramid method.
  • Overlay Rendering The entire video is transmitted in a low-quality, low-quality method, and the transmitted video is used as a background form outside of the user's viewing. At the same time, high quality is transmitted in a dual form by transmitting the viewport transmission part as an overlay based on RTCP information.
  • a video transmitted as an overlay may be composed of one or more subpictures and transmitted.
  • the MTSI transmitter must transmit including 3gpp_video in the SDP negotiation process.
  • VDP In the delivery process, VDP must be specified to indicate that the type of video to be transmitted is viewport dependent. If the VDP mode is connected, the characteristics of the corresponding VDP can be selected through the mapping function. The VDP characteristic can be a text type configuration or can be specified and transmitted as a single variable. These characteristics can be extended to G-PCC.
  • CSCF In SIP-based network, Network Announcement, User Interaction, and Conferencing Service are provided.
  • CSCF existing in MTSI occurs between caller and media server in the form of SIP proxy, application server, and media gateway. Assuming that the server is a proxy, the caller forms an INVITE message and delivers it to the SIP proxy.
  • the SIP proxy responds with 100 TRYING and then sends an INVITE message to the media server.
  • the media server sends a 200 OK message to the caller, and the caller sends an ACK message to the SIP proxy.
  • the SIP proxy Upon receiving the ACK message, the SIP proxy delivers the corresponding ACK to the media. And, a session is established through the SIP delivery message, and the media server delivers the requested media (eg, G-PCC data) through RTP.
  • the media server forwards the BYE message to the SIP proxy, and the SIP proxy forwards the BYE message to the caller.
  • the caller When reception is complete, the caller forwards a 200 OK message in the reverse direction.
  • the SDP message When sending the SIP message, the SDP message is included and delivered.
  • the SDP there are specific parameter attribute values included in the media, and the media type is configured through SDP negotiation. If no SIP proxy exists, the process of sending/receiving SIP messages between callers and callees can be simplified as follows.
  • PhoneB has an IP address of 172.20.120.30 and indicates that SIP version 2.0 is INVITE.
  • Via represents the address and port number of the proxy server transmitted along the way, and is expressed in the form of URI to transfer from Phone A to Phone B.
  • the value after Contact-Length is transmitted by inserting SDP message.
  • 38 is a diagram illustrating an example of transmitting a 200 OK message in response to the same request according to embodiments.
  • the SDP message is a message referred to when application/sdp is defined in the SIP message and is configured in a text-based format.
  • SDP field names and attribute names are used only in US-ASCII, but attribute text values are sometimes UTF-8 encoded and transmitted.
  • the SDP message is composed of an Offer/Answer form, and examples of messages in which both negotiations are performed are shown in FIGS. 39(a) and 39(b).
  • FIG. 39(a) shows an example of an SDP offer message according to embodiments
  • FIG. 39(b) shows an example of an SDP answer message.
  • G-PCC data In order to transmit G-PCC data using the media exchange method used in the 5G network, it is recognized through the SDP signal between users in advance and transmitted through the Offer/Answer method. If it is transmitted using SDP, attributes must be defined, and if G-PCC data (or G-PCC bitstream) can be received and some header information can be included, information must be exchanged. In addition, after the media session is formed, the receiver must answer some or supportable parameters suggested in the SDP Offer message in the form of an SDP Answer message.
  • Attribute parameters of SDP signals related to G-PCC data are defined as follows.
  • the value included in ⁇ info> can be the Id value of the media source in the stream or can be a parameter that can be sent in advance.
  • Mtype can be RTP data including a media header or a method of extracting and delivering only data units.
  • ⁇ info1> ⁇ info2> ⁇ info3> ⁇ info4> can be any information related to G-PCC.
  • ⁇ info1> may correspond to simple_profile_compatibility_flag, ⁇ info2> to dense_profile_compatibility_flag, ⁇ info3> to predictive_profile_compatibility_flag, and ⁇ info4> to main_profile_compatibility_flag.
  • This case is shown as Example 1 in FIG. 40 . That is, assuming that video (eg, G-PCC data) is transmitted in order to apply some of the simple, predict, dense, and main profiles presented in this document, examples 1 or 2 of FIG. 40 can be used.
  • the above method serves as a transmitter for transmitting parameters corresponding to SPS, GPS, and APS through RTP as shown in FIG. 40 . Therefore, the additionally inserted parameters are significant in pre-transmitting parsing information required for performing G-PCC video profile or decoding.
  • 40 is a diagram showing an example of an SDP offer message according to embodiments.
  • Example 1 shows that data to be transmitted in an RTP packet (eg, G-PCC data) is compressed in the simple profile mode using ⁇ info1> ⁇ info2> ⁇ info3> ⁇ info4> as follows.
  • example 2 shows that data to be transmitted in an RTP packet (eg, G-PCC data) is compressed in the simple profile mode using mtype in text form as follows.
  • FIG. 40 may indicate that SPS and/or GPS are transmitted through a header of an RTP packet.
  • any G-PCC related information transmitted through the SDP offer message is possible.
  • the header or data unit of the G-PCC video may be separated and transmitted according to the profile or media definition, but a completely different general video stream may be inserted into the data unit and transmitted.
  • an identifier identifier may be included and an array of data and headers corresponding to each may be sorted.
  • each drawing has been divided and described, but it is also possible to design to implement a new embodiment by merging the embodiments described in each drawing. And, according to the needs of those skilled in the art, designing a computer-readable recording medium in which programs for executing the previously described embodiments are recorded falls within the scope of the embodiments.
  • the device and method according to the embodiments are not limited to the configuration and method of the embodiments described above, but the embodiments are selectively combined with all or part of each embodiment so that various modifications can be made. may be configured.
  • Various components of the device of the embodiments may be implemented by hardware, software, firmware or a combination thereof.
  • Various components of the embodiments may be implemented as one chip, for example, as one hardware circuit.
  • components according to the embodiments may be implemented as separate chips.
  • at least one or more of the components of the device according to the embodiments may be composed of one or more processors capable of executing one or more programs, and the one or more programs may be executed. Any one or more of the operations/methods according to the examples may be performed or may include instructions for performing the operations/methods.
  • Executable instructions for performing methods/operations of an apparatus may be stored in a non-transitory CRM or other computer program products configured for execution by one or more processors, or may be stored in one or more may be stored in transitory CRM or other computer program products configured for execution by processors.
  • the memory according to the embodiments may be used as a concept including not only volatile memory (eg, RAM) but also non-volatile memory, flash memory, PROM, and the like. Also, those implemented in the form of a carrier wave such as transmission through the Internet may be included.
  • the processor-readable recording medium is distributed in computer systems connected through a network, so that processor-readable codes can be stored and executed in a distributed manner.
  • first, second, etc. may be used to describe various components of the embodiments. However, interpretation of various components according to embodiments should not be limited by the above terms. These terms are only used to distinguish one component from another. Only thing For example, a first user input signal may be referred to as a second user input signal. Similarly, the second user input signal may be referred to as the first user input signal. Use of these terms should be construed as not departing from the scope of the various embodiments. Although both the first user input signal and the second user input signal are user input signals, they do not mean the same user input signals unless the context clearly indicates otherwise.
  • operations according to embodiments described in this document may be performed by a transceiver including a memory and/or a processor according to embodiments.
  • the memory may store programs for processing/controlling operations according to embodiments, and the processor may control various operations described in this document.
  • a processor may be referred to as a controller or the like.
  • Operations in embodiments may be performed by firmware, software, and/or a combination thereof, and the firmware, software, and/or combination thereof may be stored in a processor or stored in a memory.
  • the transmitting/receiving device may include a transmitting/receiving unit for transmitting/receiving media data, a memory for storing instructions (program codes, algorithms, flowcharts and/or data) for processes according to embodiments, and a processor for controlling operations of the transmitting/receiving device.
  • a transmitting/receiving unit for transmitting/receiving media data
  • a memory for storing instructions (program codes, algorithms, flowcharts and/or data) for processes according to embodiments
  • a processor for controlling operations of the transmitting/receiving device.
  • a processor may be referred to as a controller or the like, and may correspond to, for example, hardware, software, and/or combinations thereof. Operations according to the above-described embodiments may be performed by a processor. Also, the processor may be implemented as an encoder/decoder for the operations of the above-described embodiments.
  • the embodiments may be applied in whole or in part to an apparatus and system for transmitting and receiving point cloud data.
  • Embodiments may include changes/variations, which do not depart from the scope of the claims and their equivalents.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

실시예들에 따른 포인트 클라우드 서비스 제공 방법은 제1 사용자 단말과 제2 사용자 단말간 통화를 위해 콜 연결을 수행하는 단계, 및 상기 콜 연결이 수행되면 상기 제2 사용자 단말은 적어도 하나의 RTP(Real Time Transport Protocol) 패킷을 이용하여 포인트 클라우드 데이터를 상기 제1 사용자 단말로 전송하는 단계를 포함하며, 상기 포인트 클라우드 데이터는 G-PCC 기반으로 압축된 G-PCC 데이터이고, 상기 적어도 하나의 RTP 패킷의 헤더는 상기 G-PCC 데이터를 식별하기 위한 식별 정보를 포함할 수 있다.

Description

포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법
실시예들은 포인트 클라우드 콘텐트(Point Cloud Content)를 처리하는 방법 및 장치에 대한 것이다.
포인트 클라우드 콘텐트는 3차원 공간을 표현하는 좌표계에 속한 점(포인트)들의 집합인 포인트 클라우드로 표현되는 콘텐트이다. 포인트 클라우드 콘텐트는3차원으로 이루어진 미디어를 표현할 수 있으며, VR (Virtual Reality, 가상현실), AR (Augmented Reality, 증강현실), MR (Mixed Reality, 혼합현실), 및 자율 주행 서비스 등의 다양한 서비스를 제공하기 위해 사용된다. VR 기술은 현실 세계의 객체나 배경 등을 CG (Computer Graphic) 영상으로만 제공하고, AR 기술은 실제 사물 영상 위에 가상으로 만들어진 CG 영상을 함께 제공하며, MR 기술은 현실 세계에 가상 객체들을 섞고 결합시켜서 제공하는 컴퓨터 그래픽 기술이다. 전술한 VR, AR, MR 등을 모두 간단히 XR (extended reality) 기술로 지칭하기도 한다. 하지만 포인트 클라우드 콘텐트를 표현하기 위해서는 수만개에서 수십만개의 포인트 데이터가 필요하다. 따라서 방대한 양의 포인트 데이터를 효율적으로 처리하기 위한 방법이 요구된다.
실시예들은 포인트 클라우드 데이터를 효율적으로 처리하기 위한 장치 및 방법을 제공한다. 실시예들은 지연시간(latency) 및 인코딩/디코딩 복잡도를 해결하기 위한 포인트 클라우드 데이터 처리 방법 및 장치를 제공한다.
다만, 전술한 기술적 과제만으로 제한되는 것은 아니고, 기재된 전체 내용에 기초하여 당업자가 유추할 수 있는 다른 기술적 과제로 실시예들의 권리범위가 확장될 수 있다.
실시예들에 따른 포인트 클라우드 서비스 제공 방법은 제1 사용자 단말과 제2 사용자 단말간 통화를 위해 콜 연결을 수행하는 단계, 및 상기 콜 연결이 수행되면 상기 제2 사용자 단말은 적어도 하나의 RTP(Real Time Transport Protocol) 패킷을 이용하여 포인트 클라우드 데이터를 상기 제1 사용자 단말로 전송하는 단계를 포함하며, 상기 포인트 클라우드 데이터는 G-PCC (Geometry-based Point Cloud Compression) 기반으로 압축된 G-PCC 데이터이고, 상기 적어도 하나의 RTP 패킷의 헤더는 상기 G-PCC 데이터를 식별하기 위한 식별 정보를 포함할 수 있다.
상기 적어도 하나의 RTP 패킷의 헤더는 상기 포인트 클라우드 데이터를 포함하는 프레임의 타입을 지시하는 정보를 더 포함하는 것을 일 실시예로 한다.
상기 적어도 하나의 RTP 패킷의 헤더는 상기 포인트 클라우드 데이터의 프로파일 정보를 더 포함하는 것을 일 실시예로 한다.
상기 콜 연결을 수행하는 단계는 상기 제1 사용자 단말에서 상기 제2 사용자 단말로 SDP offer 메시지를 전송하는 단계, 및 상기 제2 사용자 단말에서 상기 제1 사용자 단말로 SDP answer 메시지를 전송하는 단계를 포함하는 것을 일 실시예로 한다.
상기 SDP offer 메시지는 상기 포인트 클라우드 데이터의 프로파일 정보를 포함하는 것을 일 실시예로 한다.
상기 포인트 클라우드 데이터는 V-PCC (Video-based Point Cloud Compression) 기반으로 압축된 V-PCC 데이터이며, 상기 식별 정보는 상기 적어도 하나의 RTP 패킷에 포함된 포인트 클라우드 데이터가 상기 G-PCC 데이터인지 V-PCC 데이터인지를 식별하는 것을 일 실시예로 한다.
실시예들에 따른 포인트 클라우드 서비스 제공 장치는 제1 사용자 단말, 제2 사용자 단말, 및 상기 제1 사용자 단말과 상기 제2 사용자 단말 사이에 위치하여 초기화 과정을 수행하는 적어도 하나의 에지 인에이블러를 포함하며, 상기 제1 사용자 단말과 상기 제2 사용자 단말간 통화를 위해 콜 연결이 수행되면, 상기 제2 사용자 단말은 적어도 하나의 RTP(Real Time Transport Protocol) 패킷을 이용하여 포인트 클라우드 데이터를 상기 제1 사용자 단말로 전송하고, 상기 포인트 클라우드 데이터는 G-PCC (Geometry-based Point Cloud Compression) 기반으로 압축된 G-PCC 데이터이고, 상기 적어도 하나의 RTP 패킷의 헤더는 상기 G-PCC 데이터를 식별하기 위한 식별 정보를 포함할 수 있다.
상기 적어도 하나의 RTP 패킷의 헤더는 상기 포인트 클라우드 데이터를 포함하는 프레임의 타입을 지시하는 정보를 더 포함하는 것을 일 실시예로 한다.
상기 적어도 하나의 RTP 패킷의 헤더는 상기 포인트 클라우드 데이터의 프로파일 정보를 더 포함하는 것을 일 실시예로 한다.
상기 제1 사용자 단말과 상기 제2 사용자 단말 간의 콜 연결을 위해 상기 제1 사용자 단말에서 상기 제2 사용자 단말로 SDP offer 메시지를 전송하고, 상기 제2 사용자 단말에서 상기 제1 사용자 단말로 SDP answer 메시지를 전송하는 것을 일 실시예로 한다.
상기 SDP offer 메시지는 상기 포인트 클라우드 데이터의 프로파일 정보를 포함하는 것을 일 실시예로 한다.
상기 포인트 클라우드 데이터는 V-PCC (Video-based Point Cloud Compression) 기반으로 압축된 V-PCC 데이터이며, 상기 식별 정보는 상기 적어도 하나의 RTP 패킷에 포함된 포인트 클라우드 데이터가 상기 G-PCC 데이터인지 V-PCC 데이터인지를 식별하는 것을 일 실시예로 한다.
상기 제1 사용자 단말은 상기 적어도 하나의 에지 인에이블러로 디스커버리 요청을 하고, 상기 에지 인에이블러로부터 디스커버리 응답을 제공받는 초기화 과정을 수행하는 것을 일 실시예로 한다.
상기 제2 사용자 단말은 상기 적어도 하나의 에지 인에이블러로 디스커버리 요청을 하고, 상기 에지 인에이블러로부터 디스커버리 응답을 제공받는 초기화 과정을 수행하는 것을 일 실시예로 한다.
상기 제1 사용자 단말과 디스커버리 요청/응답을 수행하는 에지 인에이블러와 상기 제2 사용자 단말과 디스커버리 요청/응답을 수행하는 에지 인에이블러는 서로 다른 것을 일 실시예로 한다.
상기 제1 사용자 단말과 디스커버리 요청/응답을 수행하는 에지 인에이블러와 상기 제2 사용자 단말과 디스커버리 요청/응답을 수행하는 에지 인에이블러는 동일한 것을 일 실시예로 한다.
실시예들에 따른 장치 및 방법은 높은 효율로 포인트 클라우드 데이터를 처리할 수 있다.
실시예들에 따른 장치 및 방법은 높은 퀄리티의 포인트 클라우드 서비스를 제공할 수 있다.
실시예들에 따른 장치 및 방법은 XR 서비스, 자율주행 서비스 등 범용적인 서비스를 제공하기 위한 포인트 클라우드 콘텐트를 제공할 수 있다.
도면은 실시예들을 더욱 이해하기 위해서 포함되며, 도면은 실시예들에 관련된 설명과 함께 실시예들을 나타낸다. 이하에서 설명하는 다양한 실시예들의 보다 나은 이해를 위하여, 하기 도면들에 걸쳐 유사한 참조 번호들이 대응하는 부분들을 포함하는 다음의 도면들과 관련하여 이하의 실시예들의 설명을 반드시 참조해야 한다.
도 1은 실시예들에 따른 통신 시스템(1)의 예시를 나타내는 블록도이다.
도 2는 실시예들에 따른 방법들이 적용될 수 있는 무선 통신 시스템의 블록 구성도를 예시한다.
도 3은 3GPP 신호 전송/수신 방법의 예시를 나타낸다.
도 4는 실시예들에 따른 자기-완비 슬롯 내에 물리 채널이 매핑되는 예시를 나타낸다.
도 5은 ACK/NACK 전송 과정 및 PUSCH 전송 과정의 예시를 나타낸다.
도 6은 실시예들에 따른 5GMS 서비스의 미디어 전송을 위한 다운링크 구조를 나타낸다.
도 7은 Uplink서비스를 위한 FLUS 구조의 예시를 나타낸다.
도 8은 실시예들에 따른 포인트 클라우트 데이터 처리 시스템을 나타낸다.
도 9는 실시예들에 따른 포인트 클라우드(point cloud) 데이터 처리 장치의 예시를 나타낸다.
도 10은 실시예들에 따른 포인트 클라우드(point cloud) 데이터 처리 장치의 예시를 나타낸다.
도 11은 실시예들에 따른 포인트 클라우드(point cloud) 데이터 처리 장치의 예시를 나타낸다.
도 12는 실시예들에 따른 포인트 클라우드(point cloud) 데이터 처리 장치의 예시를 나타낸다.
도 13은 실시예들에 따른 포인트 클라우드(point cloud) 데이터 처리 장치의 예시를 나타낸다.
도 14는 실시예들에 따른 포인트 클라우드(point cloud) 데이터 처리 장치의 예시를 나타낸다.
도15는 실시예들에 따른 임의 방문 네트워크(Visited Network) 상 UE를 위한 전송 구조를 나타낸다.
도16은 실시예들에 따른 UE간 콜 연결을 나타낸다.
도17은 실시예들에 따른 포인트 클라우드 데이터 송수신 장치를 나타낸다.
도18은 실시예들에 따른 5G 네트워크 상 XR 커뮤니케이션을 위한 구조를 나타낸다.
도19는 실시예들에 따른 XR 커뮤니케이션을 위한 구조를 나타낸다
도20은 실시예들에 따른 3GPP 5G 상 XR 대화형 서비스를 프로토콜 스택을 나타낸다.
도21은 실시예들에 따른 포인트-투-포인트 XR 화상회의를 나타낸다.
도22는 실시예들에 따른 XR 화상회의 확장을 나타낸다.
도23은 실시예들에 따른 XR 화상회의 확장을 나타낸다.
도24는 실시예들에 따른 실시예들에 따른 포인트 클라우드 인코더(Point Cloud Encoder)의 예시를 나타낸다.
도 24는 1:1 대화 형성을 위해 기본 전화망을 생성하는 과정의 일 예시를 도시한 흐름도이다.
도 25는 1:1 대화 형성을 위해 기본 전화망을 생성하는 과정의 다른 예시를 도시한 흐름도이다.
도 26은 실시예들에 따른 IM subsystem의 구체적인 블록도를 나타낸 도면이다.
도 27은 실시예들에 따른 서비스 등록 과정의 일 예시를 도시한 흐름도이다.
도 28은 실시예들에 따른 서비스 등록 과정의 다른 예시를 도시한 흐름도이다.
도 29는 실시예들에 따른 RTP 패킷의 헤더 내 Payload Type(PT) 필드에 할당되는 페이로드 타입의 예시를 보인 도면이다.
도 30은 실시예들에 따른 G-PCC 데이터의 전송을 위한 RTP 패킷의 최소 확장 구조의 예시를 보인 도면이다.
도 31은 실시예들에 따른 확장을 진행하기 이전에 정의되는 프로파일과 길이 값의 예시를 보인 도면이다.
도 32는 실시예들에 따른 RTP 패킷의 확장 헤더의 예시를 보인 도면이다.
도 33은 실시예들에 따른 SPS_Flag 필드에 할당되는 값들의 예시를 보인 도면이다.
도 34는 실시예들에 따른 시퀀스 파라미터 세트 (seq_parameter_set_RTP())(SPS)의 신택스 구조의 일 실시예를 보인 도면이다.
도 35는 실시예들에 따른 지오메트리 파라미터 세트 (geometry_parameter_set_RTP())(GPS)의 신택스 구조의 일 실시예를 보인 도면이다.
도 36은 실시예들에 따른 어트리뷰트 파라미터 세트 (attribute_parameter_set_RTP())(APS)의 신택스 구조의 일 실시예를 보인 도면이다.
도 37은 실시예들에 따른 SIP INVITE 및 응답의 실제 예시를 보인 도면이다.
도 38은 실시예들에 따른 동일한 요청에 대한 응답으로 200 OK메시지가 전달되는 예시를 나타낸 도면이다.
도 39(a)는 실시예들에 따른 SDP offer 메시지의 예시를 보이고, 도 39(b)는 SDP answer 메시지의 예시를 보인 도면이다.
도 40은 실시예들에 따른 SDP offer 메시지의 일 예시를 보인 도면이다.
실시예들의 바람직한 실시예에 대해 구체적으로 설명하며, 그 예는 첨부된 도면에 나타낸다. 첨부된 도면을 참조한 아래의 상세한 설명은 실시예들의 실시예에 따라 구현될 수 있는 실시예만을 나타내기보다는 실시예들의 바람직한 실시예를 설명하기 위한 것이다. 다음의 상세한 설명은 실시예들에 대한 철저한 이해를 제공하기 위해 세부 사항을 포함한다. 그러나 실시예들이 이러한 세부 사항 없이 실행될 수 있다는 것은 당업자에게 자명하다.
실시예들에서 사용되는 대부분의 용어는 해당 분야에서 널리 사용되는 일반적인 것들에서 선택되지만, 일부 용어는 출원인에 의해 임의로 선택되며 그 의미는 필요에 따라 다음 설명에서 자세히 서술한다. 따라서 실시예들은 용어의 단순한 명칭이나 의미가 아닌 용어의 의도된 의미에 근거하여 이해되어야 한다.
도 1은 실시예들에 따른 통신 시스템(1)의 예시를 나타내는 블록도이다.
도 1에 도시된 바와 같이 실시예들에 따른 통신 시스템(1)은 무선 기기(100a-100f), 기지국(BS)(200) 및 네트워크(300)를 포함한다. 실시예들에 따른 기지국(BS)(200)는 고정국(fixed station), Node B, eNB(evolved-NodeB), gNB(Next Generation NodeB), BTS(base transceiver system), 접속 포인트(access point, AP), 네트워크 혹은 5G (5th generation) 네트워크 노드, AI (Artificial Intelligence) 시스템, RSU(road side unit), 로봇, AR/VR(Augmented Reality/Virtual Reality) 시스템, 서버 등으로 호칭될 수 있다. 실시예들에 따라, 무선 기기는 무선 접속 기술(예, 5G NR(New RAT), LTE(Long Term Evolution))을 이용하여, 기지국 및/또는 다른 무선 기기와 통신을 수행하는 기기를 의미하며, 통신/무선/5G 기기, 사용자 단말(User Equipment, UE)라고 호칭될 수 있다. 또한 무선 기기는 위 실시예들에 국한되지 않으며, 로봇(100a), 차량(100b-1, 100b-2), XR(eXtended Reality) 기기(100c), 휴대 기기(Hand-held device)(100d), 가전(100e), IoT(Internet of Thing) 기기(100f), AI기기/서버(400)를 포함할 수 있다. XR 기기(100c)는 XR 컨텐트 (예를 들면 AR(Augmented Reality)/VR(Virtual Reality)/MR(Mixed Reality) 컨텐트 등)를 제공하는 기기를 나타낸다. 실시예들에 따라 XR 기기는 AR/VR/MR 기기로 호칭될 수 있다. XR 기기(100c)는 실시예들에 따라 HMD(Head-Mounted Device), 차량에 구비된 HUD(Head-Up Display), 텔레비전, 스마트폰, 컴퓨터, 웨어러블 디바이스, 가전 기기, 디지털 사이니지(signage), 차량, 로봇 등의 형태로 구현될 수 있다. 예를 들어, 차량(100b-1, 100b-2)은 무선 통신 기능이 구비된 차량, 자율 주행 차량, 차량간 통신을 수행할 수 있는 차량, UAV(Unmanned Aerial Vehicle)(예, 드론)등을 포함할 수 있다. 휴대 기기(100d)는 스마트폰, 스마트패드, 웨어러블 기기(예, 스마트워치, 스마트글래스), 컴퓨터(예, 노트북 등) 등을 포함할 수 있다. 가전(100e)은 TV, 냉장고, 세탁기 등을 포함할 수 있다. IoT 기기(100f)는 센서, 스마트미터 등을 포함할 수 있다. 무선 기기(100a~100f)는 기지국(200)을 통해 네트워크(300)와 연결될 수 있다. 무선 기기(100a~100f)는 네트워크(300)를 통해 AI 서버(400)와 연결될 수 있다. 네트워크(300)는 3G 네트워크, 4G(예, LTE) 네트워크 또는 5G(예, NR) 네트워크, 6G 네트워크 등을 이용하여 구성될 수 있다. 무선 기기(100a~100f)는 기지국(200)/네트워크(300)를 통해 서로 통신할 수도 있지만, 기지국/네트워크를 통하지 않고 직접 통신(e.g. 사이드링크 통신(sidelink communication))할 수도 있다.
무선 기기(100a~100f)/기지국(200), 기지국(200)/기지국(200)은 무선 통신/연결(150a, 150b, 150c)을 통해 무선 신호를 송수신 할 수 있다. 실시예들에 따른 무선 통신/연결은 무선기기와 기지국간 통신인 상향/하향링크 통신(150a), 무선 기기 사이의 통신인 사이드링크 통신(150b)(또는, D2D 통신), 기지국간의 통신(150c)(e.g. relay, IAB(Integrated Access Backhaul)과 같은 다양한 무선 접속 기술들(예, 5G, NR등)을 포함할 수 있다. 실시예들에 따른 무선 기기(100a~100f), 기지국(200)은 무선무선 통신/연결(150a, 150b, 150c)의 다양한 물리 채널을 통해 신호를 송신/수신할 수 있다. 무선무선 통신/연결(150a, 150b, 150c)을 위하여 무선 신호의 송신/수신을 위한 다양한 구성정보 설정 과정, 다양한 신호 처리 과정(예, 채널 인코딩/디코딩, 변조/복조, 자원 매핑/디매핑 등), 자원 할당 과정 등 중 적어도 하나 이상의 과정이 수행될 수 있다.
실시예들에 따른 사용자 단말(UE)(예를 들면 XR 디바이스(예를 들면 도 1의 XR 디바이스(100c)등))은 오디오/비디오 데이터, 음성 데이터, 주변 정보 데이트 등의 XR 컨텐트를 제공하기 위해 필요한 XR 데이터(또는 AR/VR 데이터)를 포함하는 특정 정보를 네트워크를 통해 기지국 또는 다른 사용자 단말로 전송할 수 있다. 실시예들에 따른 사용자 단말은 네트워크에 초기 접속 동작(initial access operation)을 수행할 수 있다. 초기 접속 과정에서, 사용자 단말은 하향링크(Downlink, DL) 동기 획득을 위한 셀 서치 및 시스템 정보를 획득할 수 있다. 실시예들에 따른 하향링크는 기지국(예를 들면 BS) 또는 기지국의 일부인 송신부로부터 사용자 단말(UE) 또는 사용자 단말에 포함된 수신부로의 통신을 나타낸다. 실시예들에 따른 사용자 단말은네트워크에 접속하기 위한 임의 접속 동작(random access operation)을 수행할 수 있다. 임의 접속 동작에서, 사용자 단말은 상향링크(Uplink, UL) 동기 획득 또는 UL 데이터 전송을 위해 프리앰블을 전송하고, 임의 접속 응답 수신 동작을 수행할 수 있다. 실시예들에 따른 상향링크는 UE 또는 UE의 일부인 송신부로부터 BS 또는 BS의 일부인 수신부로의 통신을 나타낸다. 또한 사용자 단말은 BS로 특정 정보를 전송하기 위해 상향링크 그랜트 (UL Grant) 수신 동작을 수행할 수 있다. 실시예들에 상향링크 그랜트는 상향링크 데이터 전송을 위해 시간/주파수 자원 스케쥴링 정보를 수신하기 위한 것이다. 실시예들에 따른 사용자 단말은 UL 그랜트에 기반하여 특정 정보를 5G 네트워크를 통해 기지국으로 전송할 수 있다. 실시예에 따른 기지국은 XR 컨텐트 프로세싱을 수행할 수 있다. 사용자 단말은 5G 네트워크를 통해 특정 정보에 대한 응답을 수신하기 위해 다운링크 그랜트 (DL Grant) 수신 동작을 수행할 수 있다. 실시예들에 따른 다운링크 그랜트는 다운링크 데이터를 수신하기 위하여 시간/주파수 자원 스케쥴링 정보를 수신하는 것을 나타낸다. 사용자 단말은 다운링크 그랜트를 기반으로 네트워크를 통해 특정 정보에 대한 응답을 수신할 수 있다.
도 2는 실시예들에 따른 방법들이 적용될 수 있는 무선 통신 시스템의 블록 구성도를 예시한다.
무선 통신 시스템은 제 1 통신 장치(910) 및/또는 제 2 통신 장치(920)을 포함한다. 'A 및/또는 B'는 'A 또는 B 중 적어도 하나를 포함한다'와 동일한 의미로 해석될 수 있다. 제 1 통신 장치가 BS를 나타내고, 제 2 통신 장치가 UE를 나타낼 수 있다(또는 제 1 통신 장치가 UE를 나타내고, 제 2 통신 장치가 BS를 나타낼 수 있다).
제 1 통신 장치와 제 2 통신 장치는 프로세서(processor, 911,921), 메모리(memory, 914,924), 하나 이상의 Tx/Rx RF 모듈(radio frequency module, 915,925), Tx 프로세서(912,922), Rx 프로세서(913,923), 안테나(916,926)를 포함한다. Tx/Rx 모듈은 트랜시버라고도 한다. 실시예들에 따른 프로세서(911)는 물리계층 이상의 레이어 (예를 들면 레이어 2(L2)) 계층의 신호처리기능을 수행할 수 있다. 예를 들어, 다운링크(Downlink), 또는 DL(제 1 통신 장치에서 제 2 통신 장치로의 통신)에서, 코어 네트워크로부터의 상위 계층 패킷은 프로세서(911)에 제공된다. 실시예들에 따른 프로세서(911)는 DL에서, 프로세서는 논리 채널과 전송 채널 간의 다중화(multiplexing), 무선 자원 할당을 제 2 통신 장치(920)에 제공하며, 제 2 통신 장치로의 시그널링을 담당한다. 제 1 통신 장치(910) 및 제 2 통신 장치(920)는 프로세서(911,921)에서 처리된 상위 계층 패킷 보다 더 상위 계층의 데이터를 처리하는 프로세서(예를 들면 오디오/비디오 인코더, 오디오/비디오 디코더 등)를 더 포함할 수 있다. 실시예들에 따른 프로세서는 다양한 비디오 표준(예를 들면 MPEG2, AVC, HEVC, VVC등의 비디오 표준)에 대응하여 처리된 비디오 데이터 및 다양한 오디오 표준(예를 들면 MPEG 1 Layer 2 Audio, AC3, HE-AAC, E-AC-3, HE-AAC, NGA등과 같은 오디오 표준 등)에 의해 처리된 오디오 데이터를 처리할 수 있다. 또한 실시예들에 따른 프로세서는 Video-based Point Cloud Compression (V-PCC) 또는 Geometry-based Point Cloud Compression (G-PCC) 방식으로 처리된 XR 데이터 또는 XR 미디어 데이터를 처리할 수 있다. 상위 계층 데이터를 처리하는 프로세서는 프로세서(911,921)와 결합되어 하나의 프로세서 또는 하나의 칩 등으로 구현될 수 있다. 또한 상위 계층 데이터를 처리하는 프로세서는 프로세서(911,921)와 별도의 칩, 별도의 프로세서로 구현될 수 있다. 전송(TX) 프로세서(912)는 L1 계층(즉, 물리 계층)에 대한 다양한 신호 처리 기능을 구현한다. 물리 계층의 신호 처리 기능은 제 2 통신 장치에서 FEC(forward error correction)을 용이하게 할 수 있다. 물리 계층의 신호 처리 기능은 코딩 및 인터리빙(coding and interleaving)을 포함한다. 인코딩 및 인터리밍을 거친 신호는 스크램블링(scrambling) 및 변조(modulation)을 거쳐 복소 값(complex valued) 변조 심볼들로 변조된다. 변조에는 채널에 따라 BPSK, QPSK, 16QAM, 64QAM, 246QAM 등이 사용될 수 있다. 복소 값 변조 심볼들(이하, 변조 심볼들)은 병렬 스트림으로 분할되고, 각각의 스트림은 OFDM 부반송파에 매핑되고, 시간 및/또는 주파수 도메인에서 참조 신호와 다중화(multiplexing)되며, IFFT를 사용하여 함께 결합되어 시간 도메인 OFDM 심볼 스트림을 운반하는 물리적 채널을 생성한다. OFDM 심볼 스트림은 다중 공간 스트림을 생성하기 위해 공간적으로 프리코딩된다. 각각의 공간 스트림은 개별 Tx/Rx 모듈(또는 트랜시버, 915)를 통해 상이한 안테나(916)에 제공될 수 있다. 각각의 Tx/Rx 모듈은 전송을 위해 각각의 공간 스트림을 RF 반송파로 주파수 상향변환(upconvert)할 수 있다. 제 2 통신 장치에서, 각각의 Tx/Rx 모듈(또는 트랜시버, 925)는 각 Tx/Rx 모듈의 각 안테나(926)을 통해 RF 반송파의 신호를 수신한다. 각각의 Tx/Rx 모듈은 RF 반송파의 신호를 기저대역(baseband) 신호로 복원하여, 수신(RX) 프로세서(923)에 제공한다. RX 프로세서는 L1(즉, 물리 계층)의 다양한 신호 프로세싱 기능을 구현한다. RX 프로세서는 제 2 통신 장치로 향하는 임의의 공간 스트림을 복구하기 위해 정보에 공간 프로세싱을 수행할 수 있다. 만약 다수의 공간 스트림들이 제 2 통신 장치로 향하는 경우, 다수의 RX 프로세서들에 의해 단일 OFDMA 심볼 스트림으로 결합될 수 있다. RX 프로세서는 고속 푸리에 변환 (FFT)을 사용하여 시간 도메인 신호인 OFDM 심볼 스트림을 주파수 도메인 신호로 변환한다. 주파수 도메인 신호는 OFDM 신호의 각각의 부반송파에 대한 개별적인 OFDM 심볼 스트림을 포함한다. 각각의 부반송파 상의 변조 심볼들 및 참조 신호는 제 1 통신 장치에 의해 전송된 가장 가능성 있는 신호 성상(constellation) 포인트들을 결정함으로써 복원되고 복조된다. 이러한 연 판정(soft decision)들은 채널 추정 값들에 기초할 수 있다. 연판정들은 물리 채널 상에서 제 1 통신 장치에 의해 원래 전송된 데이터 및 제어 신호를 복원하기 위해 디코딩 및 디인터리빙되다. 해당 데이터 및 제어 신호는 프로세서(921)에 제공된다.
UL(제 2 통신 장치에서 제 1 통신 장치로의 통신)은 제 2 통신 장치(920)에서 수신기 기능과 관련하여 기술된 것과 유사한 방식으로 제 1 통신 장치(910)에서 처리된다. 각각의 Tx/Rx 모듈(925)는 각각의 안테나(926)을 통해 신호를 수신한다. 각각의 Tx/Rx 모듈은 RF 반송파 및 정보를 RX 프로세서(923)에 제공한다. 프로세서 (921)는 프로그램 코드 및 데이터를 저장하는 메모리 (924)와 관련될 수 있다. 메모리는 컴퓨터 판독 가능 매체로서 지칭될 수 있다.
도 3 내지 도 5는 물리적인 L1 계층(즉, 물리 계층)에 대한 하나 또는 그 이상의 신호처리 방법 및/또는 동작들의 예시를 나타낸다. 도 3 내지 도 5에 개시된 예시들은 도 2에서 설명한 전송(TX) 프로세서(912) 및/또는 전송(TX) 프로세서(922)에서 수행되는 신호처리 방법 및/또는 동작들의 예시와 동일 또는 유사할 수 있다.
도 3은 3GPP 신호 전송/수신 방법의 예시를 나타낸다.
실시예들에 따르면 UE는 전원이 켜지거나 새로운 셀에 진입한 경우 BS와 동기를 맞추는 등의 초기 셀 탐색(initial cell search) 작업을 수행할 수 있다(S201). UE는 BS로부터 1차 동기 채널(primary synchronization channel, P-SCH) 및 2차 동기 채널(secondary synchronization channel, S-SCH)을 수신하여 BS와 동기를 맞추고, 셀 ID 등의 정보를 획득할 수 있다. LTE 시스템과 NR 시스템에서 P-SCH와 S-SCH는 각각 1차 동기 신호(primary synchronization signal, PSS)와 2차 동기 신호(secondary synchronization signal, SSS)로 호칭될 수 있다. 초기 셀 탐색 후, UE는 BS로부터 물리 브로드캐스트 채널(physical broadcast channel, PBCH)를 수신하여 셀 내 브로드캐스트 정보를 획득할 수 있다. 한편, UE는 초기 셀 탐색 단계에서 하향링크 참조 신호(downlink reference Signal, DL RS)를 수신하여 하향링크 채널 상태를 확인할 수 있다.
초기 셀 탐색을 마친 UE는 PDCCH 및 PDCCH에 실린 정보에 따라 PDSCH를 수신함으로써 좀더 구체적인 시스템 정보를 획득할 수 있다(S202).
한편, BS에 최초로 접속하거나 신호 전송을 위한 무선 자원이 없는 경우 UE는 BS에 대해 임의 접속 과정(random access procedure)을 수행할 수 있다(단계 S203 내지 단계 S206). 이를 위해, UE는 PRACH를 통해 특정 시퀀스를 프리앰블로서 전송하고(S203 및 S205), PDCCH 및 대응하는 PDSCH를 통해 프리앰블에 대한 임의 접속 응답(random access response, RAR) 메시지를 수신할 수 있다(S204 및 S206). 경쟁 기반 임의 접속 과정의 경우, 추가적으로 충돌 해결 과정(contention resolution procedure)를 수행할 수 있다.
상술한 과정을 수행한 UE는 이후 일반적인 상향링크/하향링크 신호 전송 과정으로서 PDCCH/PDSCH 수신(S207) 및 PUSCH/PUCCH 전송(S208)을 수행할 수 있다. 특히 UE는 PDCCH를 통하여 DCI를 수신한다. UE는 해당 탐색 공간 설정(configuration)들에 따라 서빙 셀 상의 하나 이상의 제어 요소 세트(control element set, CORESET)들에 설정된 모니터링 기회(occasion)들에서 PDCCH 후보(candidate)들의 세트를 모니터링한다. UE가 모니터할 PDCCH 후보들의 세트는 탐색 공간 세트들의 관점에서 정의될 수 있다. 실시예들에 따른 탐색 공간 세트는 공통 탐색 공간 세트 또는 UE-특정 탐색 공간 세트일 수 있다. CORESET은 1~3개 OFDM 심볼들의 시간 지속기간을 갖는 (물리) 자원 블록들의 세트로 구성된다. 네트워크는 UE가 복수의 CORESET들을 갖도록 설정할 수 있다. UE는 하나 이상의 탐색 공간 세트들 내 PDCCH 후보들을 모니터링한다. 여기서 모니터링이라 함은 탐색 공간 내 PDCCH 후보(들)에 대한 디코딩을 시도하는 것을 의미한다. UE가 탐색 공간 내 PDCCH 후보들 중 하나에 대한 디코딩에 성공하면, UE는 해당 PDCCH 후보에서 PDCCH를 검출했다고 판단하고, 검출된 PDCCH 내 DCI를 기반으로 PDSCH 수신 혹은 PUSCH 전송을 수행할 수 있다. 실시예들에 따른 PDCCH는 PDSCH 상의 DL 전송들 및 PUSCH 상의 UL 전송들을 스케줄링하는 데 사용될 수 있다. PDCCH 상의 DCI는 하향링크 공유 채널과 관련된, 변조(modulation) 및 코딩 포맷과 자원 할당(resource allocation) 정보를 적어도 포함하는 하향링크 배정(assignment)(즉, DL 그랜트), 또는 상향링크 공유 채널과 관련된, 변조 및 코딩 포맷과 자원 할당 정보를 포함하는 상향링크 그랜트(UL grant)를 포함할 수 있다.
UE는 SSB를 검출함으로써 DL 동기를 획득할 수 있다. UE는 검출된 SSB (시간) 인덱스(SSB index, SSBI)에 기반하여 SSB 버스트 세트의 구조를 식별할 수 있고, 이에 따라 심볼/슬롯/하프-프레임 경계를 검출할 수 있다. 검출된 SSB가 속하는 프레임/하프-프레임의 번호는 시스템 프레임 번호(system frame number, SFN) 정보와 하프-프레임 지시 정보를 이용하여 식별될 수 있다. UE는 PBCH로부터 PBCH가 속한 프레임에 대한 10 비트의 SFN을 획득할 수 있다. UE는 1 비트의 하프-프레임 지시 정보를 획득하여 해당 PBCH가 프레임 중 첫번째 하프-프레임에 속하는지 두번째 하프-프레임에 속하는지 판단할 수 있다. 예를 들어 하프-프레임 지시 비트 값이 0 인 경우, PBCH가 속한 SSB가 프레임 내 첫 번째 하프-프레임에 속한다는 것을 나타낸다. 하프-프레임 지시 비트 값이 1 인 경우, PBCH가 속한 SSB가 프레임 내 두 번째 하프-프레임에 속한다는 것을 나타낸다. UE는 DMRS 시퀀스와 PBCH가 나르는 PBCH 페이로드에 기반하여 PBCH가 속한 SSB의 SSBI를 획득할 수 있다.
다음의 표 1는 UE의 임의 접속 과정을 나타낸다.
표 1
신호의 타입 획득되는 동작/정보
제 1단계 UL에서의 PRACH 프리앰블(preamble) * 초기 빔 획득
* 임의 접속 프리앰블 ID의 임의 선택
제 2단계 PDSCH 상의 임의 접속 응답 * 타이밍 어드밴스 정보
* 임의 접속 프리앰블 ID
* 초기 UL 그랜트, 임시 C-RNTI
제 3단계 PUSCH 상의 UL 전송 * RRC 연결 요청
* UE 식별자
제 4단계 DL 상의 경쟁 해결(contention resolution) * 초기 접속을 위한 PDCCH 상의 임시 C-RNTI
* RRC_CONNECTED인 UE에 대한 PDCCH 상의 C-RNTI
임의 접속 과정은 다양한 용도로 사용된다. 예를 들어, 임의 접속 과정은 네트워크 초기 접속, 핸드오버, UE-트리거드(triggered) UL 데이터 전송에 사용될 수 있다. UE는 임의 접속 과정을 통해 UL 동기와 UL 전송 자원을 획득할 수 있다. 임의 접속 과정은 경쟁 기반(contention-based) 임의 접속 과정과 경쟁 프리(contention free) 임의 접속 과정으로 구분된다.
도 4는 실시예들에 따른 자기-완비 슬롯 내에 물리 채널이 매핑되는 예시를 나타낸다.
DL 제어 영역에서는 PDCCH가 전송될 수 있고, DL 데이터 영역에서는 PDSCH가 전송될 수 있다. UL 제어 영역에서는 PUCCH가 전송될 수 있고, UL 데이터 영역에서는 PUSCH가 전송될 수 있다. GP는 기지국과 UE가 송신 모드에서 수신 모드로 전환하는 과정 또는 수신 모드에서 송신 모드로 전환하는 과정에서 시간 갭을 제공한다. 서브프레임 내에서 DL에서 UL로 전환되는 시점의 일부 심볼이 GP로 설정될 수 있다.
실시예들에 따른 PDCCH는 DCI(Downlink Control Information)를 운반한다. 예를 들어, PCCCH (즉, DCI)는 DL-SCH(downlink shared channel)의 전송 포맷 및 자원 할당, UL-SCH(uplink shared channel)에 대한 자원 할당 정보, PCH(paging channel)에 대한 페이징 정보, DL-SCH 상의 시스템 정보, PDSCH 상에서 전송되는 랜덤 접속 응답과 같은 상위 계층 제어 메시지에 대한 자원 할당 정보, 전송 전력 제어 명령, CS(Configured Scheduling)의 활성화/해제 등을 나른다. DCI는 CRC(cyclic redundancy check)를 포함하며, CRC는 PDCCH의 소유자 또는 사용 용도에 따라 다양한 식별자(예, Radio Network Temporary Identifier, RNTI)로 마스킹/스크램블 된다. 예를 들어, PDCCH가 특정 단말을 위한 것이면, CRC는 단말 식별자(예, Cell-RNTI, C-RNTI)로 마스킹 된다. PDCCH가 페이징에 관한 것이면, CRC는 P-RNTI(Paging-RNTI)로 마스킹 된다. PDCCH가 시스템 정보(예, System Information Block, SIB)에 관한 것이면, CRC는 SI-RNTI(System Information RNTI)로 마스킹 된다. PDCCH가 랜덤 접속 응답에 관한 것이면, CRC는 RA-RNTI(Random Access-RNTI)로 마스킹 된다.
PDCCH는 AL(Aggregation Level)에 따라 1, 2, 4, 8, 16개의 CCE(Control Channel Element)로 구성된다. CCE는 무선 채널 상태에 따라 소정 부호율의 PDCCH를 제공하기 위해 사용되는 논리적 할당 단위이다. CCE는 6개의 REG(Resource Element Group)로 구성된다. REG는 하나의 OFDM 심볼과 하나의 (P)RB로 정의된다. PDCCH는 CORESET(Control Resource Set)를 통해 전송된다. CORESET는 주어진 뉴모놀로지(예, SCS, CP 길이 등)를 갖는 REG 세트로 정의된다. 하나의 UE를 위한 복수의 CORESET는 시간/주파수 도메인에서 중첩될 수 있다. CORESET는 시스템 정보(예, Master Information Block, MIB) 또는 단말-특정(UE-specific) 상위 계층(예, Radio Resource Control, RRC, layer) 시그널링을 통해 설정될 수 있다. 구체적으로, CORESET을 구성하는 RB 개수 및 OFDM 심볼 개수(최대 3개)가 상위 계층 시그널링에 의해 설정될 수 있다.
PDCCH 수신/검출을 위해, 단말은 PDCCH 후보들을 모니터링 한다. PDCCH 후보는 PDCCH 검출을 위해 UE가 모니터링 해야 하는 CCE(들)을 나타낸다. 각 PDCCH 후보는 AL에 따라 1, 2, 4, 8, 16개의 CCE로 정의된다. 모니터링은 PDCCH 후보들을 (블라인드) 디코딩 하는 것을 포함한다. UE가 모니터링 하는 PDCCH 후보들의 세트를 PDCCH 검색 공간(Search Space, SS)이라고 정의한다. 검색 공간은 공통 검색 공간(Common Search Space, CSS) 또는 단말-특정 검색 공간(UE-specific search space, USS)을 포함한다. 단말은 MIB 또는 상위 계층 시그널링에 의해 설정된 하나 이상의 검색 공간에서 PDCCH 후보를 모니터링 하여 DCI를 획득할 수 있다. 각각의 CORESET는 하나 이상의 검색 공간과 연관되고, 각 검색 공간은 하나의 COREST과 연관된다. 검색 공간은 다음의 파라미터들에 기초하여 정의될 수 있다.
- controlResourceSetId: 검색 공간과 관련된 CORESET를 나타냄
- monitoringSlotPeriodicityAndOffset: PDCCH 모니터링 주기 (슬롯 단위) 및 PDCCH 모니터링 구간 오프셋 (슬롯 단위)을 나타냄
- monitoringSymbolsWithinSlot: 슬롯 내 PDCCH 모니터링 심볼을 나타냄(예, CORESET의 첫 번째 심볼(들)을 나타냄)
- nrofCandidates: AL={1, 2, 4, 8, 16} 별 PDCCH 후보의 수 (0, 1, 2, 3, 4, 5, 6, 8 중 하나의 값)를 나타냄
* PDCCH 후보들을 모니터링을 해야 하는 기회(occasion)(예, 시간/주파수 자원)을 PDCCH (모니터링) 기회라고 정의된다. 슬롯 내에 하나 이상의 PDCCH (모니터링) 기회가 구성될 수 있다.
PUCCH는 UCI(Uplink Control Information)를 나른다. UCI는 다음을 포함한다.
- SR(Scheduling Request): UL-SCH 자원을 요청하는데 사용되는 정보이다.
- HARQ(Hybrid Automatic Repeat reQuest)-ACK(Acknowledgement): PDSCH 상의 하향링크 데이터 패킷(예, 코드워드)에 대한 응답이다. 하향링크 데이터 패킷이 성공적으로 수신되었는지 여부를 나타낸다. 단일 코드워드에 대한 응답으로 HARQ-ACK 1비트가 전송되고, 두 개의 코드워드에 대한 응답으로 HARQ-ACK 2비트가 전송될 수 있다. HARQ-ACK 응답은 포지티브 ACK(간단히, ACK), 네거티브 ACK(NACK), DTX 또는 NACK/DTX를 포함한다. 여기서, HARQ-ACK은 HARQ ACK/NACK, ACK/NACK과 혼용된다.
- CSI(Channel State Information): 하향링크 채널에 대한 피드백 정보이다. MIMO(Multiple Input Multiple Output)-관련 피드백 정보는 RI(Rank Indicator) 및 PMI(Precoding Matrix Indicator)를 포함한다.
PUSCH는 상향링크 데이터(예, UL-SCH transport block, UL-SCH TB) 및/또는 상향링크 제어 정보(UCI)를 운반하고, CP-OFDM(Cyclic Prefix - Orthogonal Frequency Division Multiplexing) 파형(waveform) 또는 DFT-s-OFDM(Discrete Fourier Transform - spread - Orthogonal Frequency Division Multiplexing) 파형에 기초하여 전송된다. PUSCH가 DFT-s-OFDM 파형에 기초하여 전송되는 경우, 단말은 변환 프리코딩(transform precoding)을 적용하여 PUSCH를 전송한다. 일 예로, 변환 프리코딩이 불가능한 경우(예, transform precoding is disabled) 단말은 CP-OFDM 파형에 기초하여 PUSCH를 전송하고, 변환 프리코딩이 가능한 경우(예, transform precoding is enabled), 단말은 CP-OFDM 파형 또는 DFT-s-OFDM 파형에 기초하여 PUSCH를 전송할 수 있다. PUSCH 전송은 DCI 내 UL 그랜트에 의해 동적으로 스케줄링 되거나, 상위 계층(예, RRC) 시그널링 (및/또는 Layer 1(L1) 시그널링(예, PDCCH))에 기초하여 반-정적(semi-static)으로 스케줄링 될 수 있다(configured grant). PUSCH 전송은 코드북 기반 또는 비-코드북 기반으로 수행될 수 있다.
도 5은 ACK/NACK 전송 과정 및 PUSCH 전송 과정의 예시를 나타낸다.
도 5(a)는 ACK/NACK 전송 과정의 예시를 나타낸다.
UE는 슬롯 #n에서 PDCCH를 검출할 수 있다. 여기서, PDCCH는 다운링크 스케줄링 정보(예, DCI 포맷 1_0, 1_1)를 포함하며, PDCCH는 DL assignment-to-PDSCH offset (K0)과 PDSCH-HARQ-ACK reporting offset (K1)를 나타낸다. 예를 들어, DCI 포맷 1_0, 1_1은 다음의 정보를 포함할 수 있다.
- Frequency domain resource assignment: PDSCH에 할당된 RB 세트를 나타냄
- Time domain resource assignment: K0, 슬롯 내의 PDSCH의 시작 위치(예, OFDM 심볼 인덱스) 및 길이(예 OFDM 심볼 개수)를 나타냄
- PDSCH-to-HARQ_feedback timing indicator: K1를 나타냄
- HARQ process number (4비트): 데이터(예, PDSCH, TB)에 대한 HARQ process ID(Identity)를 나타냄
이후, 단말은 슬롯 #n의 스케줄링 정보에 따라 슬롯 #(n+K0)에서 PDSCH를 수신한 뒤, 슬롯 #(n+K1)에서 PUCCH를 통해 UCI를 전송할 수 있다. 여기서, UCI는 PDSCH에 대한 HARQ-ACK 응답을 포함한다. PDSCH가 최대 1개 TB를 전송하도록 구성된 경우, HARQ-ACK 응답은 1-비트로 구성될 수 있다. PDSCH가 최대 2개의 TB를 전송하도록 구성된 경우, HARQ-ACK 응답은 공간(spatial) 번들링이 구성되지 않은 경우 2-비트로 구성되고, 공간 번들링이 구성된 경우 1-비트로 구성될 수 있다. 복수의 PDSCH에 대한 HARQ-ACK 전송 시점이 슬롯 #(n+K1)로 지정된 경우, 슬롯 #(n+K1)에서 전송되는 UCI는 복수의 PDSCH에 대한 HARQ-ACK 응답을 포함한다. 기지국/UE에는 DL 전송을 위해 복수의 병렬 DL HARQ 프로세스가 존재한다. 복수의 병렬 HARQ 프로세스는 이전 DL 전송에 대한 성공 또는 비성공 수신에 대한 HARQ 피드백을 기다리는 동안 DL 전송이 연속적으로 수행되게 한다. 각각의 HARQ 프로세스는 MAC(Medium Access Control) 계층의 HARQ 버퍼와 연관된다. 각각의 DL HARQ 프로세스는 버퍼 내의 MAC PDU(Physical Data Block)의 전송 횟수, 버퍼 내의 MAC PDU에 대한 HARQ 피드백, 현재 리던던시 버전(redundancy version) 등에 관한 상태 변수를 관리한다. 각각의 HARQ 프로세스는 HARQ 프로세스 ID에 의해 구별된다.
도 5(b)는 PUSCH 전송 과정의 예시를 나타낸다.
UE는 슬롯 #n에서 PDCCH를 검출할 수 있다. 여기서, PDCCH는 업링크스케줄링 정보(예, DCI 포맷 0_0, 0_1)를 포함한다. DCI 포맷 0_0, 0_1은 다음의 정보를 포함할 수 있다.
- Frequency domain resource assignment: PUSCH에 할당된 RB 세트를 나타냄
- Time domain resource assignment: 슬롯 오프셋 K2, 슬롯 내의 PUSCH의 시작 위치(예, 심볼 인덱스) 및 길이(예 OFDM 심볼 개수)를 나타냄. 시작 심볼과 길이는 SLIV(Start and Length Indicator Value)를 통해 지시되거나, 각각 지시될 수 있음. UE는 슬롯 #n의 스케줄링 정보에 따라 슬롯 #(n+K2)에서 PUSCH를 전송할 수 있다. 여기서, PUSCH는 UL-SCH TB를 포함한다.
실시예들은 5G 기반 미디어 스트리밍(이하 5GMS) 시스템에 적용될 수 있다. 5GMS구조는 MNO (Mobile Network Operator) 및 제 3자의 미디어 다운링크 Streaming서비스를 지원하는 시스템이다. 또한 5GMS구조는 관련된 네트워크나 UE 기능 및 API를 지원하며, MBMS지원 여부 및/또는 5G표준, EUTRAN 설치와 상관 없이 상호호환성 (backward compatibles)을 제공한다. 5G를 이용한 미디어에서 사용되는 Streaming의 정의란 시간 연속적인 미디어의 생성, 전달로 정의되며 Streaming Point의 정의란 송신기와 수신기가 직접적으로 송신하며 소비하는 것을 나타낸다. 5GMS구조는 기본적으로 다운링크 (Downlink) 및 업링크 (Uplink)환경에서 동작하며 양방향성을 가지고 있다. 사용하고자 하는 시나리오와 단말과 서버간 디바이스 캐퍼빌리티(Device Capability)에 따라 Streaming을 하는 방식이며 기술적으로 다르게 기능 블록이 구성되어 운용된다. 미디어가 다운링크를 통해 전달되는 경우 네트워크가 미디어의 생산 주체이며 UE가 미디어를 소비하는 소비자 장치로 정의된다. 5GMS 서비스는 5G네트워크 뿐만 아니라 3G, 4G, 6G 등의 네트워크를 이용할 수 있으며 상술한 실시예에 국한되지 않는다. 실시예들은 서비스 형태에 따라 네트워크 슬라이스 (Network Slicing)기능도 제공할 수 있다.
도 6은 실시예들에 따른 5GMS 서비스의 미디어 전송을 위한 다운링크 구조를 나타낸다.
도 6은 4G, 5G, 6G 네트워크 중 적어도 어느 하나 이상의 네트워크를 위한 미디어 전송 구조를 나타내며 단방향 다운링크 미디어 Streaming환경에서 동작할 수 있는 장치 방법이다. Downlink 시스템이기 때문에 네트워크 및 Trusted Media Function에서 미디어를 생산하고 미디어는 UE로 전달되는 형태를 갖게 된다. 각 블록도는 개념적으로 미디어 송수신에 필요한 기능의 집합의 구성 형태로 이루어 진다. Inter-Connection Interface는 미디어 블록별 특정 일부의 기능을 공유하거나 조절하기 위한 Link를 의미하며 필요 요소 기술을 모두 활용하지 않는 경우 사용된다. 예를 들어, 3rd Party External Application과 Operator Application은 독립적인 Application 작동이 이루어 지나 필요에 의해 정보 공유 (사용자 데이터, 미디어 Track 등)과 같은 기능이 필요한 경우 Inter-Connection Interface를 통해 통신 가능하도록 연결될 수 있다. 실시예들에 따른 미디어는 시간 연속적, 시간 비연속적, 이미지, 그림, 동영상, 오디오, 텍스트 등의 정보, 매개체를 모두 포함하며, 추가적으로 해당 미디어를 전송하고자 하는 포멧, 포멧의 크기 등을 모두 포함한다.
도 6의 Sink는 UE, UE에 포함된 프로세서(예를 들면 도 2 에서 설명한 상위 계층의 신호처리를 위한 프로세서(911) 등) 또는 UE를 구성하는 하드웨어를 나타낸다. 실시예들에 따른 Sink는 미디어를 제공하는 Source에서 Sink까지 Streaming 서비스를 Unicast형태로 받는 수신 동작을 수행할 수 있다. 실시예들에 따른 Sink는 Source 로부터 Control 정보를 수신하여 Control 정보를 기반으로 신호처리 동작을 수행할 수 있다. 실시예들에 따른 Sink는 Source로부터 미디어/메타데이터(예를 들면 XR 데이터 또는 확장된 미디어 데이터 등)를 수신할 수 있다. 실시예들에 따른 Sink는 3rd Party External Application 블록, Operator Application 블록 및/또는 5G Media Reception Function 블록 등을 포함할 수 있다. 실시예들에 따른 Sink는 3rd Party External Application 블록 및 Operator Application 블록은 Sink단에서 작동하는 UE Application을 나타낸다. 실시예들에 따른 3rd Party External Application 블록은 4G, 5G, 6G망 이외에 존재하는 제 3자에 의해 운용되는 어플리케이션으로, Sink의 API접속을 구동시킬 수 있다. 실시예들에 따른 3rd Party External Application 블록은 4G, 5G, 6G망을 이용하거나 직접적인 Point-to-Point Communication을 통해 정보를 수신할 수 있다. 따라서 Sink의 UE에서는 Native또는 Download Installed된 Application을 통해 추가 서비스를 제공받을 수 있다. 실시예들에 따른 Operator application블록은 미디어 Application을 포함한 미디어 스트리밍 구동 환경에 연관된 Application (5G Media Player) 들을 관리할 수 있다. Application이 설치되면, Sink의 UE는 Application Socket을 이용하여 API를 통한 미디어 서비스를 접속을 시작하고 관련된 데이터 정보를 주고받을 수 있다. 실시예들에 따른 API는 Socket을 이용한 세션 구성으로 데이터를 특정 end-system까지 전달할 수 있게 한다. Socket연결 방식은 일반적인 TCP기반의 인터넷 연결을 통해 전달될 수 있다. Sink는 Cloud Edge로부터 control/data 정보 등을 수신하고, Cloud Edge에 control/data 정보 등을 전송하는 Offloading을 수행할 수 있다. 도면에 도시되지 않았으나 실시예들에 따른 Sink는 Offloading Management 블록을 포함할 수 있다. 실시예들에 따른 Offloading Management는 Sink의 Offloading을 제어하기 위하여 operator application 블록 및/또는 3rd party application 블록의 동작을 제어할 수 있다.
실시예들에 따른 5G Media Reception Function 블록은 Offloading Management 블록으로부터 offloading 과 관련된 동작을 수신하고 4G, 5G, 6G망을 통해 수신할 수 있는 미디어를 획득 하고 미디어를 처리할 수 있다. 실시예들에 따른 5G Media Reception Function 블록은 일반적인 Media Access Client 블록, DRM Client 블록, Media Decoder, Media Rendering Presentation블록, XR Rendering 블록, XR Media Processing 블록 등을 포함할 수 있다. 해당 블록은 예시에 불과하며 명칭 및/또는 동작 등은 실시예들에 한정되지 않는다.
실시예들에 따른 Media Access Client 블록은 4G, 5G, 6G 네트워크 중 적어도 어느 하나 이상의 네트워크를 통해 수신된 데이터, 예를 들어, 미디어 Segment를 수신할 수 있다. 실시예들에 따른 Media Access Client 블록은 DASH, CMAF, HLS등과 같이 다양한 미디어 전송 Format을 De-formatting(또는 디캡슐레이션)할 수 있다. Media Access Client 블록에서 출력된 데이터는 각 디코딩 특성에 따라 처리되어 디스플레이 될 수 있다. 실시예들에 따른 DRM Client 블록은 수신된 데이터의 이용여부를 판단할 수 있다. 예를 들어 DRM client 블록은 허가된 사용자가 Access 범위 내 미디어 정보를 이용할 수 있도록 제어하는 동작을 수행할 수 있다. 실시예들에 따른 Media Decoding 블록은 일반적인 오디오/비디오 디코더로서, 디포맷된 데이터 중 다양한 표준(MPEG2, AVC, HEVC, VVC등의 비디오 표준 및 MPEG 1 Layer 2 Audio, AC3, HE-AAC, E-AC-3, HE-AAC, NGA등과 같은 오디오 표준 등)에 따라 처리된 오디오/비디오 데이터를 디코딩할 수 있다. 실시예들에 따른 Media Rendering Presentation 블록은 수신 장치에 적합하도록 미디어를 렌더링을 할 수 있다. 실시예들에 따른 Media Rendering Presentation 블록은 Media decoding 블록에 포함될 수 있다. 실시예들에 따른 XR Media Processing 블록 및 XR Rendering 블록은 디포맷된 데이터(또는 디 캡슐레이션된 데이터) 중 XR 데이터를 처리하기 위한 블록들이다. XR Media Processing 블록(예를 들면 도 2에서 설명한 프로세서(911) 또는 상위 계층 데이터를 처리하는 프로세서 등)은 source로부터 수신한 XR 데이터 또는 offloading management블록으로부터 수신한 정보 (예를 들면 Object정보, Position정보 등)를 이용하여 XR 미디어에 대한 Processing을 수행할 수 있다. 실시예들에 따른 XR Rendering 블록은 수신한 미디어 데이터 중 XR 미디어 데이터를 렌더링하여 디스플레이 할 수 있다. 실시예들에 따른 XR Media Processing 블록 및 XR rendering 블록은 Video-based Point Cloud Compression (V-PCC) 또는 Geometry-based Point Cloud Compression (G-PCC) 방식에 따라 처리된 포인트 클라우드 데이터를 프로세싱 및 렌더링 할 수 있다. Video-based Point Cloud Compression (V-PCC) 또는 Geometry-based Point Cloud Compression (G-PCC) 방식에 대해서는 도 8 내지 도 14에서 상세히 설명한다. 실시예들에 따른 XR Media Processing 블록 및 XR Rendering 블록은 하나의 XR decoder로 구성될 수 있다.
Source는 4G, 5G, 6G 네트워크 중 적어도 어느 하나 이상의 네트워크를 이용한 미디어 서버 또는 미디어를 제공할 수 있는 UE를 나타내며 Control Function과 Server Function 기능을 수행할 수 있다. Server Function은 4G, 5G, 6G 미디어 서비스를 시작하고 Hosting한다. 3rd Party Media Server는 4G, 5G, 6G 망 이외에 존재하는 제 3자에 의해 운용되는 다양한 미디어 서버를 의미하며, Network External Media Application Server가 될 수 있다. 일반적으로 제 3자 서비스에 의해 운용되는 External Server에서는4G, 5G, 6G망이 아닌 곳에서 미디어 제작, 인코딩, formatting등을 동일하게 수행할 수 있다. Control Function은 네트워크 기반 어플리케이션 기능 (Application Function)을 나타내며, Sink 및 기타 미디어 서버, 미디어 인증을 수행할 경우 컨트롤 위주의 정보 전달 기능을 포함할 수 있다. 따라서 Source는 Control Function을 통해 내부 Application의 API접속을 통해 접속을 시작하고 미디어 세션을 형성하거나, 기타 부가 정보 Request등을 수행할 수 있다. 또한 Source는 Control Function을 통해 타 네트워크 기능과의 PCF 정보 교환을 수행한다. Source는 Control Function을 통해 NEF를 이용하여 외부 네트워크 Capability를 확인하고 노출 과정을 통해 일반적으로 Monitoring, Provisioning을 수행할 수 있다. 그러므로 NEF는 다른 네트워크 정보를 수신하고 특정 표준화된 인터페이스를 이용하여 구조화된 데이터로서 수신된 정보를 저장할 수 있다. 저장된 정보는 NEF에 의해 다른 네트워크 및 어플리케이션 에게 Exposure/Re-exposure를 수행할 수 있으며 다양한 네트워크 환경에서 Exposure된 정보를 모아 분석의 목적으로 이용될 수 있다. 도 6과 같이 서비스 구성 연결이 이루어 지면 API Control Plane이 형성되며 세션 접속이 이루어 지면 보안 (인증, 권한 부여 등)과 같은 작업을 포함되어 미디어를 전송할 수 있는 환경이 형성된다. Source에서 다수개의 4G, 5G, 6G Media Function이 존재할 경우 다수개의 API를 생성하거나 한 개의 API를 통해서 Control Plane을 생성할 수 있다. 마찬가지로 제 3자의 Media 서버로부터 API가 생성될 수 있으며 Media Control Function과 UE의 API는 Media User Plane API를 형성할 수 있다. Source는 Downlink미디어 서비스 기능을 수행하기 위해 다양한 방법으로 미디어를 생성, 전달 가능하며 단순히 미디어를 저장하는 것부터 시작해서 미디어 Relaying 역할 등 미디어를 최종 목적지인 Sink에 해당하는 UE까지 전달할 수 있는 모든 기능을 포함할 수 있다. 실시예들에 따른 Sink 및 Source 내부의 모듈, 또는 블록들은 양방향성을 지닌 Inter-Connection Link 및 Inter-Connection Interface을 통해 정보를 전달 및 공유할 수 있다.
실시예들은 5GMS시스템에서 실시간으로 미디어를 제작된 Content가 소셜미디어, 사용자, 서버 등에 전송할 수 있는 UL 구조 및 방법에 대하여 설명한다. Uplink는 기본적으로 Distribution의 형태로 사용자에게 미디어가 전달되는 것이 아닌 사용자 단말 UE입장에서 미디어를 제작하고 Media Server쪽으로 전달되는 것으로 정의한다. Downlink 시스템과는 달리 Uplink시스템은 개인 사용자가 직접적인 Content를 제공하는 형태로 구성되어 있기 때문에 단말에서 처리하는 시스템 구성 방법 활용하고자 하는 Use Case, 시스템 구조가 Downlink와는 다른 형태로 구성될 수 있다. FLUS 시스템은 미디어를 제작하는 Source Entity와 미디어를 소비하는 Sink Entity로 구성되며 1:1 커뮤니케이션을 통해 음성, 비디오, 텍스트등과 같은 서비스가 전달된다. 따라서 Signalling, Transport Protocol, Packet-loss Handling, Adaptation등과 같은 기법이 적용될 수 있으며 FLUS시스템을 통해 예상 가능한 미디어의 품질과 Flexibility를 제공할 수 있다. FLUS Source는 단일개의 UE 또는 다수 개로 흩어져 있는 UE, Capture Device등이 될 수 있다. 5G망을 전제로 하고 있기 때문에 3GPP IMS/MTSI서비스를 지원할 수 있으며 IMS Control Plane을 통해 IMS 서비스를 지원하고 MTSI Service Policy규정을 준수하여 서비스를 지원할 수 있다. 만약 IMS/MTSI서비스를 지원하지 않는다면 Uplink서비스를 위해 Network Assistance기능을 통해 다양한 User Plane Instantiation으로 서비스가 지원될 수 있다.
도 7은 Uplink서비스를 위한 FLUS 구조의 예시를 나타낸다.
FLUS 구조는 도 6에서 설명한 Source 및 Sink를 포함할 수 있다. 실시예들에 따른 Source는 UE에 해당할 수 있다. 실시예들에 따른 Sink는 UE 또는 Network에 해당할 수 있다. Uplink는 미디어의 생성과 전달 목표에 따라 Source와 Sink로 구성되며 Source는 단말 장치인 UE에 그리고 Sink는 또 다른 UE또는 네트워크가 될 수 있다. Source는 미디어 Content를 한 개 또는 그 이상의 Capture Device로부터 전달 받을 수 있다. Capture Device는 UE의 일부로 연결되어 있거나 연결되지 않을 수 있다. 미디어를 수신하는 Sink가 네트워크가 아닌 UE에 존재할 경우 Decoding 및 Rendering Function기능이 UE에 포함되며 수신된 미디어는 해당 기능에 전달해야 한다. 반대로 Sink가 네트워크에 해당하는 경우 수신된 미디어는 Processing 또는 Distribution Sub-Function으로 전달할 수 있다. Sink가 네트워크에 위치한 경우 때로는 역할에 따라서 Media Gateway Function 또는 Application Function의 역할을 포함할 수 있다. 도 9에 도시된 F link는 Source와 Sink를 연결하는 역할을 하며 세부적으로 이 Link를 통해 FLUS 세션의 Control과 Establishment를 가능하게 한다. 또한 F link를 통해 Source와 Sink간 Authentication/Authorization을 포함할 수 있다. F Link는 조금 더 세부적으로 Media Source and Sink (F-U end-points), Control Source and Sink (F-C end-points), Remote Controller and Remote Control Target (F-RC end-points) 그리고 Assistance Sender and Receiver (F-A end-points)로 구분화 할 수 있다. 이러한 Source Sink간은 모두 Logical Function으로 구분된다. 그러므로 해당 기능들은 같은 물리적 장치에 존재해도 되거나 때로는 기능의 분리가 이루어져 같은 장치에 존재하지 않아도 된다. 각각의 기능들은 또한 다수개의 물리적 장치로 분리되어 서로 다른 Interface에 의해 연결될 수 있다. 단일개의 FLUS Source에서 다수개의 F-A, F-RC point가 존재할 수 있다. 각각의 point는 FLUS Sink와 독립적이며 Offered Service에 따라 생성될 수 있다. 앞서 설명한 바와 같이 F Link Point는 F Point 세부적 존재하는 모든 Sub-function 및 Link의 Security 기능을 가정하고 해당 인증 과정이 포함될 수 있다.
도 8은 실시예들에 따른 포인트 클라우트 데이터 처리 시스템을 나타낸다.
도 8에 도시된 포인트 클라우드 처리 시스템(1500)은 포인트 클라우드 데이터를 획득하여 인코딩 처리하여 전송하는 전송 디바이스(예를 들면 도 1 내지 도 7에서 설명한 BS 또는 UE) 및 비디오 데이터를 수신하여 디코딩 처리하여 포인트 클라우드 데이터를 획득하는 수신 디바이스(예를 들면 도 1 내지 도 7에서 설명한 UE)를 포함할 수 있다. 도 8에 도시된 바와 같이 실시예들에 따른 포인트 클라우드 데이터는 포인트 클라우드 데이터의 캡처, 합성 또는 생성 과정 등을 통하여 획득될 수 있다(S1510). 획득 과정에서 포인트들에 대한 3D 위치(x, y, z)/어트리뷰트 (color, reflectance, transparency 등) 데이터 (예를 들어, PLY(Polygon File format or the Stanford Triangle format) 파일 등)이 생성될 수 있다. 여러 개의 프레임을 갖는 비디오의 경우 하나 이상의 파일들이 획득될 수 있다. 캡처 과정에서 포인트 클라우드 데이터 관련 메타데이터 (예를 들어 캡처와 관련된 메타데이터 등)가 생성될 수 있다. 실시예들에 따른 전송 디바이스 또는 인코더는 Geometry-based Point Cloud Compression (G-PCC) 방식을 이용하여 포인트 클라우드 데이터를 인코딩하여 하나 또는 그 이상의 비디오 스트림들을 출력할 수 있다(S1520). G-PCC는 포인트 클라우드 데이터를 지오메트리 (geometry) (또는 지오메트리 정보)및 어트리뷰트(attribute) (또는 어트리뷰트 정보)의 두 가지 스트림으로 나누어 인코딩하는 방법이다. 지오메트리 스트림은 포인트들의 위치 정보를 재구성하고 인코딩하여 생성될 수 있으머, 어트리뷰트 스트림은 각 포인트와 연관된 어트리뷰트 정보 (예를 들면 색상 등)를 재구성하고 인코딩하여 생성될 수 있다. 출력된 하나 또는 그 이상의 비트 스트림들은 관련 메타데이터와 함께 파일 등의 형태 (예를 들면 ISOBMFF 등의 파일 포맷 등)로 인캡슐레이션되어 네트워크 또는 디지털 저장매체를 통해 전송될 수 있다(S1530). 실시 예에 따라, Point cloud관련 메타데이터 자체는 파일로 인캡슐레이션될 수 있다.
실시예들에 따른 디바이스(UE) 또는 프로세서(예를 들면 도 2에서 설명한 프로세서(911) 또는 프로세서(921), 상위 계층 프로세서, 또는 도 6에서 설명한 Sink 또는 Sink에 포함된 XR Media Processing 블록)는 수신한 비디오 데이터를 디캡슐레이션 처리하여 하나 또는 그 이상의 비트 스트림들을 및 관련 메타 데이터를 획득하고, 획득한 비트 스트림들을 G-PCC 방식으로 디코딩하여 3차원의 포인트 클라우드 데이터를 복원할 수 있다(S1540). 렌더러(예를 들면 도 6에서 설명한 Sink 또는 Sink에 포함된 XR rendering 블록 등)는 디코딩된 포인트 클라우드 데이터를 렌더링하고 디스플레이부를 통해 사용자에게 VR/AR/MR/ 서비스에 맞는 콘텐트를 제공할 수 있다(S1550). 도 8에 도시된 바와 같이, 실시예들에 따른 디바이스 또는 프로세서는 렌더링/디스플레이 과정에서 획득한 다양한 피드백 정보들을 송신 디바이스로 전달하거나, 디코딩 과정에 전달하는 피드백 프로세스를 수행할 수 있다(S1560). 실시예들에 따른 피드백 정보는 헤드 오리엔테이션(Head Orientation) 정보, 사용자가 현재 보고 있는 영역을 나타내는 뷰포트(Viewport) 정보 등을 포함할 수 있다. 피드백 프로세스를 통해 사용자와 서비스 (또는 콘텐트) 프로바이더 간의 상호작용이 이루어지므로, 실시예들에 따른 디바이스는 보다 높은 사용자 편의가 고려된 다양한 서비스들을 제공할 수 있을 뿐만 아니라, 전술한 G-PCC 방식을 이용하여 보다 빠른 데이터 처리 속도를 제공하거나 선명한 비디오 구성이 가능한 기술적 효과가 있다.
도 9는 실시예들에 따른 포인트 클라우드(point cloud) 데이터 처리 장치의 예시를 나타낸다.
도 9는 G-PCC 방식에 따른 포인트 클라우드 데이터 처리 동작을 수행하는 장치를 나타낸다. 도 9에 도시된 포인트 클라우드 데이터 처리 장치는 도 1 내지 도 7에서 설명한 UE (예를 들면 도 2에서 설명한 프로세서(911) 또는 프로세서(921), 상위 계층 데이터를 처리하는 프로세서, 또는 도 6에서 설명한 Sink 또는 Sink에 포함된 XR Media Processing 블록 등) 또는 BS에 포함되거나 UE에 해당할 수 있다.
실시예들에 따른 Point Cloud 데이터 처리 장치는 Point Cloud 획득부(Point Cloud Acquisition), Point Cloud 인코딩부(Point Cloud Encoding), 파일/세그먼트 인캡슐레이션부(File/Segment Encapsulation),및/또는 딜리버리부(Delivery)를 포함한다. 처리 장치의 각 구성은 모듈/유닛/컴포넌트/하드웨어/소프트웨어/프로세서 등일 수 있다. Point cloud 의 geometry, attribute, auxiliary data, mesh data 등은 각각 별도의 스트림으로 구성되거나 혹은 파일 내 각각 다른 트랙에 저장될 수 있다. 더 나아가 별도의 세그먼트에 포함될 수 있다.
Point Cloud 획득부(Point Cloud Acquisition)은 point cloud 를 획득한다. 예를 들어 하나 이상의 카메라를 통하여 Point Cloud의 캡쳐, 합성 또는 생성 과정 등을 통한 Point Cloud 데이터를 획득할 수 있다. 이러한 획득 과정에 의해 각 포인트의 3D 위치(x, y, z 위치 값 등으로 나타낼 수 있다. 이하 이를 지오메트리라고 일컫는다), 각 포인트의 어트리뷰트 (color, reflectance, transparency 등)을 포함하는 point cloud 데이터를 획득할 수 있으며 이를 포함하는, 예를 들어, PLY(Polygon File format or the Stanford Triangle format) 파일 등으로 생성 될 수 있다. 여러 개의 프레임을 갖는 point cloud 데이터의 경우 하나 이상의 파일들이 획득될 수 있다. 이러한 과정에서 point cloud 관련 메타데이터 (예를 들어 캡처 등과 관련된 메타데이터 등)가 생성될 수 있다.
Point Cloud 인코딩부(Point Cloud Encoding)는 Point Cloud인코더는 Geometry-based Point Cloud Compression (G-PCC) 절차를 수행하며 이는 예측, 변환, 양자화, 엔트로피 코딩 등의 일련의 절차를 수행하고 인코딩된 데이터(인코딩된 비디오/영상 정보)는 비트스트림(bitstream) 형태로 출력될 수 있다. Point Cloud 인코딩부는 포인트 클라우드 데이터를 지오메트리 (Geometry)(또는 지오메트리 정보) 및 어트리뷰트(attribute) (어트리뷰트 정보)로 나누어 각각 인코딩 할 수 있다. 또한 인코딩된 지오메트리 정보 및 어트리뷰트 정보는 각각 비트스트림으로 출력될 수 있으며. 출력된 비트스트림들은 하나의 비트 스트림으로 멀티플렉싱될 수 있다. Point Cloud 인코딩부는 메타데이터(Metadata)를 수신할 수 있다. 메타데이터는 Point Cloud를 위한 콘텐츠에 관련된 메타데이터를 나타낸다. 예를 들어 이니셜 뷰잉 오리엔테이션 메타데이터(Initial viewing orientation metadata)가 있을 수 있다. 메타데이터는 포인트 클라우드 데이터가 앞을 나타내는 데이터인지 뒤를 나타내는 데이터인지 등을 나타낸다. Point Cloud 인코딩부는 오리엔테이션 정보 및/또는 뷰포트 정보를 수신할 수 있다. Point Cloud 인코딩부 메타데이터, 오리엔테이션 정보 및/또는 뷰포트 정보에 기반하여 인코딩을 수행할 수 있다. 실시예들에 따른 포인트 클라우드 인코딩 부에서 출력된 비스트림은 포인트 클라우드 관련 메타데이터를 포함할 수 있다. 실시예들에 따른 Point Cloud 인코딩부(Point Cloud Encoding)는 지오메트리 컴프레션(Geometry compression), 어트리뷰트 컴프레션(Attribute compression), Auxiliary 데이터 컴프레션(Auxiliary data compression), Mesh 데이터 컴프레션(Mesh data compression)을 수행한다. 지오메트리 컴프레션(Geometry compression)은 point cloud 데이터의 지오메트리 정보를 인코딩한다. 지오메트리 (또는 지오메트리 정보)는 3차원 공간상의 포인트(또는 각 포인트의 위치 정보)를 나타낸다. 어트리뷰트 컴프레션(Attribute compression)은 point cloud 데이터의 어트리뷰트를 인코딩한다. 어트리뷰트 (또는 어트리뷰트 정보)는 각 포인트의 어트리뷰트(예를 들면 color, reflectance 등의 어트리뷰트)을 나타낸다. 어트리뷰트 컴프레션은 하나 또는 그 이상의 포인트들에 대한 하나 또는 그 이상의 어트리뷰트들을 처리할 수 있다. Auxiliary 데이터 컴프레션(Auxiliary data compression)은, point cloud 와 연관된 Auxiliary 데이터를 인코딩한다. Auxiliary 데이터는 Point Cloud에 관한 메타데이터를 나타낸다. Mesh 데이터 컴프레션(Mesh data compression)은 Mesh 데이터를 인코딩한다. Mesh 데이터는 Point Cloud간의 연결 정보를 나타낸다. 실시예들에 따른 Mesh 데이터는 삼각형 형태를 나타내는 Mesh 데이터를 포함할 수 있다.
Point Cloud 인코딩부는 포인트를 렌더링하기 위해 필요한 정보들인 포인트에 관한 지오메트리, 어트리뷰트, Auxiliary 데이터, Mesh데이터를 인코딩한다. Point Cloud 인코딩부는 지오메트리, 어트리뷰트, Auxiliary 데이터, Mesh 데이터를 인코딩하여 하나의 비트스트림으로 전달할 수 있다. 또는, Point Cloud 인코딩부는 지오메트리, 어트리뷰트, Auxiliary 데이터, Mesh 데이터를 각각 인코딩하고, 인코딩된 데이터들을 전송하는 하나 또는 그 이상의 비트스트림들 또는 인코딩된 데이터를 각각 출력할 수 있다(예를 들면 지오메트리 비트스트림, 어트리뷰트 비트스트림등). 포인트 클라우드 인코딩부의 각 동작은 병렬적으로 수행될 수 있다.
파일/세그먼트 인캡슐레이션부(File/Segment Encapsulation)는 미디어 트랙 인캡슐레이션(Media track encapsulation) 및/또는 메타데이터 트랙 인캡슐레이션(metadata track encapsulation)을 수행한다. 파일/세그먼트 인캡슐레이션부는 인코딩된 지오메트리(지오메트리 정보), 인코딩된 어트리뷰트, 인코딩된 Auxiliary 데이터, 인코딩된 Mesh데이터를 파일 형태로 전달하기 위한 트랙을 생성한다. 인코딩된 지오메트리(지오메트리 정보)를 포함하는 비트스트림, 인코딩된 어트리뷰트를 포함하는 비트스트림, 인코딩된 Auxiliary데이터를 포함하는 비트스트림, 인코딩된 Mesh데이터를 포함하는 비트스트림을 하나 또는 하나 이상의 복수의 트랙에 포함시킬 수 있다. 파일/세그먼트 인캡슐레이션부는 지오메트리(지오메트리 정보), 어트리뷰트, Auxiliary 데이터, Mesh 데이터를 하나 또는 하나 이상의 미디어 트랙으로 인캡슐레이션한다. 또한, 파일/세그먼트 인캡슐레이션부는 메타데이터를 미디어 트랙에 포함하거나 별도의 메타데이터 트랙으로 인캡슐레이션한다. 파일/세그먼트 인캡슐레이션부는 포인트 클라우드 스트림(들)을 파일 및/또는 세그먼트의 형태로 인캡슐레이션한다. 포인트 클라우드 스트림(들)을 세그먼트(들) 형태로 인캡슐레이션하여 전달하는 경우 DASH포맷으로 딜리버리한다. 파일/세그먼트 인캡슐레이션부는 포인트 클라우드 스트림(들)을 파일 형태로 인캡슐레이션하는 경우 파일을 딜리버리한다.
딜리버리부(Delivery)는 point cloud 비트스트림 혹은 해당 비트스트림을 포함하는 파일/세그먼트를 디지털 저장매체 또는 네트워크를 통하여 수신 디바이스의 수신부로 전달할 수 있다. 전송을 위해 임의의 전송 프로토콜에 따른 처리가 수행될 수 있다. 전송을 위한 처리를 마친 데이터들은 방송망 및/또는 브로드밴드를 통해 전달될 수 있다. 이 데이터들은 온 디맨드(On Demand) 방식으로 수신측으로 전달될 수도 있다. 디지털 저장 매체는 USB, SD, CD, DVD, 블루레이, HDD, SSD 등 다양한 저장 매체를 포함할 수 있다. 딜리버리부는 미리 정해진 파일 포멧을 통하여 미디어 파일을 생성하기 위한 엘리먼트를 포함할 수 있고, 방송/통신 네트워크를 통한 전송을 위한 엘레멘트를 포함할 수 있다. 딜리버리부는 수신부로부터 오리엔테이션 정보 및/또는 뷰포트 정보를 수신한다. 딜리버리부는 획득한 오리엔테이션 정보 및/또는 뷰포트 정보(또는 사용자가 선택한 정보)를 파일/세그먼트 인캡슐레이션부 및/또는 포인트 클라우드 인코딩부에 전달할 수 있다. 오리엔테이션 정보 및/또는 뷰포트 정보에 기반하여, 포인트 클라우드 인코딩부는 모든 포인트 클라우드 데이터를 인코딩하거나 또는 오리엔테이션 정보 및/또는 뷰포트 정보가 나타내는 포인트 클라우드 데이터를 인코딩할 수 있다. 오리엔테이션 정보 및/또는 뷰포트 정보에 기반하여, 파일/세그먼트 인캡슐레이션부는 모든 포인트 클라우드 데이터를 인캡슐레이션하거나 또는 오리엔테이션 정보 및/또는 뷰포트 정보가 나타내는 포인트 클라우드 데이터를 인캡슐레이션할 수 있다. 오리엔테이션 정보 및/또는 뷰포트 정보에 기반하여, 딜리버리부는 모든 포인트 클라우드 데이터를 딜리버리하거나 또는 오리엔테이션 정보 및/또는 뷰포트 정보가 나타내는 포인트 클라우드 데이터를 딜리버리할 수 있다.
도 10은 실시예들에 따른 포인트 클라우드(point cloud) 데이터 처리 장치의 예시를 나타낸다.
도 10은 G-PCC 방식에 따라 처리된 포인트 클라우드 데이터를 수신하고 처리하는 동작을 수행하는 장치의 예시를 나타낸다. 도 10의 장치는 도 9에서 설명한 방식에 대응하는 방식으로 데이터를 처리할 수 있다. 도 10에 도시된 포인트 클라우드 데이터 처리 장치는 도 1 내지 도 10에서 설명한 UE에 해당하거나 UE에 포함될 수 있다(예를 들면 도 2에서 설명한 프로세서(911) 또는 프로세서(921), 또는 도 8에서 설명한 Sink 또는 Sink에 포함된 XR Media Processing 블록 등).
실시예들에 따른 Point Cloud 데이터 처리 장치는 딜리버리 클라이언트(Delivery Client), 센싱/트랙킹부(Sensing/Tracking), 파일/세그먼트 디캡슐레이션부(File/Segment decapsulation),Point Cloud 디코딩부(Point Cloud Decoding) 및/또는 Point Cloud 렌더링부(Point Cloud Rendering), 디스플레이를 포함한다. 수신 장치의 각 구성은 모듈/유닛/컴포넌트/하드웨어/소프트웨어/프로세서 등일 수 있다.
딜리버리 클라이언트(Delivery Client)는 도 9에서 설명한 point cloud 데이터 처리 장치가 전송한 point cloud 데이터, point cloud 비트스트림 혹은 해당 비트스트림을 포함하는 파일/세그먼트를 수신할 수 있다. 전송되는 채널에 따라 도 10의 장치는 방송망을 통하여 point cloud데이터를 수신할 수도 있고, 브로드밴드를 통하여 point cloud데이터를 수신할 수도 있다. 혹은 디지털 저장 매체를 통하여 point cloud 비디오 데이터를 수신할 수도 있다. 도 10의 장치는 수신한 데이터를 디코딩 하고 이를 사용자의 뷰포트 등에 따라 랜더링하는 과정을 수행할 수 있다. 도 10의 장치는 수신된 point cloud데이터에 대해 전송 프로토콜에 따른 처리를 수행하기 위한 수신 처리부(예를 들면 도 2의 프로세서(911) 등)를 포함할 수 있다. 즉, 전송측에서 전송을 위한 처리가 수행된 것에 대응되도록, 수신 처리부는 전송 처리부의 역과정을 수행할 수 있다. 수신 처리부는 획득한 point cloud 데이터는 디캡슐레이션 처리부로 전달하고, 획득한 point cloud 관련 메타데이터는 메타데이터 파서로 전달할 수 있다.
센싱/트랙킹부(Sensing/Tracking)는 오리엔테이션 정보 및/또는 뷰포트 정보를 획득한다. 센싱/트랙킹부는 획득한 오리엔테이션 정보 및/또는 뷰포트 정보를 딜리버리 클라이언트, 파일/세그먼트 디캡슐레이션부, 포인트 클라우드 디코딩부에 전달할 수 있다.
딜리버리 클라이언트는 오리엔테이션 정보 및/또는 뷰포트 정보에 기반하여, 모든 포인트 클라우드 데이터를 수신하거나 또는 오리엔테이션 정보 및/또는 뷰포트 정보가 나타내는 포인트 클라우드 데이터를 수신할 수 있다. 파일/세그먼트 디캡슐레이션부는 오리엔테이션 정보 및/또는 뷰포트 정보에 기반하여, 모든 포인트 클라우드 데이터를 디캡슐레이션하거나 또는 오리엔테이션 정보 및/또는 뷰포트 정보가 나타내는 포인트 클라우드 데이터를 디캡슐레이션할 수 있다. 포인트 클라우드 디코딩부는 오리엔테이션 정보 및/또는 뷰포트 정보에 기반하여, 모든 포인트 클라우드 데이터를 디코딩하거나 또는 오리엔테이션 정보 및/또는 뷰포트 정보가 나타내는 포인트 클라우드 데이터를 디코딩할 수 있다.
파일/세그먼트 디캡슐레이션부(File/Segment decapsulation)는 미디어 트랙 디캡슐레이션(Media track decapsulation) 및/또는 메타데이터 트랙 디캡슐레이션(Metadata track decapsulation)을 수행한다. 디캡슐레이션 처리부(file/segment decapsulation)는 수신 처리부로부터 전달받은 파일 형태의 point cloud데이터를 디캡슐레이션할 수 있다. 디캡슐레이션 처리부는 ISOBMFF 등에 따른 파일 혹은 세그먼트들을 디캡슐레이션하여, point cloud비트스트림 내지 point cloud 관련 메타데이터(혹은 별도의 메타데이터 비트스트림)를 획득할 수 있다. 획득된 point cloud비트스트림은 point cloud디코더로, 획득된 point cloud관련 메타데이터(혹은 메타데이터 비트스트림)는 메타데이터 처리부로 전달할 수 있다. point cloud비트스트림은 메타데이터(메타데이터 비트스트림)를 포함할 수도 있다. 메타데이터 처리부는 point cloud 비디오 디코더에 포함될 수도 있고, 또는 별도의 컴포넌트/모듈로 구성될 수도 있다. 디캡슐레이션 처리부가 획득하는 point cloud관련 메타데이터는 파일 포맷 내의 박스 혹은 트랙 형태일 수 있다. 디캡슐레이션 처리부는 필요한 경우 메타데이터 처리부로부터 디캡슐레이션에 필요한 메타데이터를 전달받을 수도 있다. point cloud관련 메타데이터는 point cloud디코더에 전달되어 point cloud디코딩 절차에 사용될 수도 있고, 또는 렌더러에 전달되어 point cloud렌더링 절차에 사용될 수도 있다.
Point Cloud 디코딩부(Point Cloud Decoding)는 지오메트리 디컴프레션(Geometry decompression), 어트리뷰트 디컴프레션(Attribute decompression), Auxiliary 데이터 디컴프레션(Auxiliary data decompression) 및/또는 Mesh 데이터 디컴프레션(Mesh data decompression)을 수행한다. Point Cloud디코더는 비트스트림을 입력 받아 Point Cloud인코더의 동작에 대응하는 동작을 수행하여 데이터를 디코딩할 수 있다. 이 경우 Point Cloud디코더는 Point Cloud데이터를 후술하는 바와 같이 지오메트리 및 어트리뷰트(attribute)로 나누어 디코딩할 수 있다. 예를 들어, Point Cloud디코더는 입력 비트스트림 내 포함된 지오메트리 비트스트림으로부터 지오메트리를 복원(디코딩)할 수 있고, 입력 비트스트림 내 포함된 어트리뷰트 비트스트림 및 복원된 지오메트리를 기반으로 어트리뷰트값을 복원(디코딩)할 수 있다. 입력 비트스트림 내 포함된 메쉬 비트스트림 및 복원된 지오메트리를 기반으로 메쉬를 복원(디코딩)할 수 있다. 복원된 지오메트리에 따른 위치 정보 및 디코딩된 어트리뷰트값에 따른 (컬러) 텍스처 어트리뷰트를 기반으로 3차원의 각 포인트의 위치와 각 포인트의 어트리뷰트정보를 복원하여 point cloud을 복원할 수 있다. 포인트 클라우드 디코딩부의 각 동작은 병렬적으로 수행될 수 있다.
지오메트리 디컴프레션은 포인트 클라우드 스트림(들)으로부터 지오메트리 데이터를 디코딩한다. 어트리뷰트 디컴프레션은 포인트 클라우드 스트림(들)으로부터 어트리뷰트 데이터를 디코딩한다. Auxiliary 데이터 디컴프레션은 포인트 클라우드 스트림(들)으로부터 Auxiliary 데이터를 디코딩한다. Mesh데이터 디컴프레션은 포인트 클라우드 스트림(들) 으로부터 Mesh 데이터를 디코딩한다.
Point Cloud 렌더링부(Point Cloud Rendering)는 디코딩된 지오메트리, 어투리뷰트, auxiliary 데이터, 메쉬데이터를 기반으로 포인트 클라우드의 각 포인트의 위치 및 해당 포인트의 에트리뷰티를 복원하고 해당 포인트 클라우드 데이터를 렌더링한다. 포인트 클라우드 렌더링부는 복원된 지오메트리, 복원된어트리뷰트, 복원된Auxiliary데이터 및/또는복원된Mesh데이터에 기초하여 포인트 클라우드 간의 메쉬(연결) 데이터를 생성하고 렌더링한다. 포인트 클라우드 렌더링부는 파일/세그먼트 인캡슐레이션부 및/또는 포인트 클라우드 디코딩부로부터 메타데이터를 수신한다. 포인트 클라우드 렌더링부는 오리엔테이션 혹은 뷰포트에 따라 메타데이터에 기반하여 포인트 클라우드 데이터를 렌더링할 수 있다. 도 10에 도시되지 않았으나 도 10의 장치는 디스플레이를 포함할 수 있다. 실시예들에 따른 디스플레이는 랜더링된 결과를 디스플레이할 수 있다.
도 11은 실시예들에 따른 포인트 클라우드(point cloud) 데이터 처리 장치의 예시를 나타낸다.
도 11은 V-PCC 방식에 따른 포인트 클라우드 데이터 처리 동작을 수행하는 장치를 나타낸다. V-PCC는 HEVC, VVC등의 2D비디오 코덱(video codec)을 기반으로 포인트 클라우드 데이터를 압축하는 방법이다. 도 11에 도시된 포인트 클라우드 데이터 처리 장치는 도 1 내지 도 8에서 설명한 UE (예를 들면 도 2에서 설명한 프로세서(911) 또는 프로세서(921), 또는 도 6에서 설명한 Sink 또는 Sink에 포함된 XR Media Processing 블록 등) 또는 BS에 포함되거나 UE에 해당할 수 있다.
실시예들에 따른 Point Cloud 데이터 처리 장치는 Point Cloud 획득부(Point Cloud Acquisition), 패치 제너레이션(Patch Generation), 지오메트리 이미지 제너레이션(Geometry Image Generation), 어트리뷰트 이미지 제너레이션(Attribute Image Generation), 어큐판시 맵 제너레이션(Occupancy Map Generation), Auxiliary 데이터 제너레이션(Auxiliary Data Generation), Mesh 데이터 제너레이션(Mesh Data Generation), 비디오 인코딩(Video Encoding), 이미지 인코딩(Image Encoding), 파일/세그먼트 인캡슐레이션부(File/Segment Encapsulation),딜리버리부(Delivery)를 포함한다. 실시예들에 따라서, 패치 제너레이션, 지오메트리 이미지 제너레이션, 어트리뷰트 이미지 제너레이션, 어큐판시 맵 제너레이션, Auxiliary 데이터 제너레이션, Mesh 데이터 제너레이션은 포인트 클라우드 프리-프로세싱(Point Cloud Pre-processing), 프리-프로세서 또는 제어부라고 명명할 수 있다. 비디오 인코딩부는 지오메트리 비디오 컴프레션(Geometry video compression), 어트리뷰트 비디오 컴프레션(Attribute video compression), 어큐판시 맵 컴프레션(Occupancy map compression), Auxiliary 데이터 컴프레션(Auxiliary data compression), Mesh 데이터 컴프레션(Mesh data compression)을 포함한다. 이미지 인코딩부는 지오메트리 비디오 컴프레션(Geometry video compression), 어트리뷰트 비디오 컴프레션(Attribute video compression), 어큐판시 맵 컴프레션(Occupancy map compression), Auxiliary 데이터 컴프레션(Auxiliary data compression), Mesh 데이터 컴프레션(Mesh data compression)을 포함한다. 파일/세그먼트 인캡슐레이션부는 비디오 트랙 인캡슐레이션(Video Track Encapsulation), 메타데이터 트랙 인캡슐레이션(Metadata Track Encapsulation), 이미지 인캡슐레이션(Image Encapsulation)을 포함한다. 전송 장치의 각 구성은 모듈/유닛/컴포넌트/하드웨어/소프트웨어/프로세서 등일 수 있다.
Point cloud 의 geometry, attribute, auxiliary data, mesh data 등은 각각 별도의 스트림으로 구성되거나 혹은 파일 내 각각 다른 트랙에 저장될 수 있다. 더 나아가 별도의 세그먼트에 포함될 수 있다.
Point Cloud 획득부(Point Cloud Acquisition)은 point cloud 를 획득한다. 예를 들어 하나 이상의 카메라를 통하여 Point Cloud의 캡쳐, 합성 또는 생성 과정 등을 통한 Point Cloud 데이터를 획득할 수 있다. 이러한 획득 과정에 의해 각 포인트의 3D 위치(x, y, z 위치 값 등으로 나타낼 수 있다. 이하 이를 지오메트리라고 일컫는다), 각 포인트의 어트리뷰트 (color, reflectance, transparency 등)을 포함하는 point cloud 데이터를 획득할 수 있으며 이를 포함하는, 예를 들어, PLY(Polygon File format or the Stanford Triangle format) 파일 등으로 생성 될 수 있다. 여러 개의 프레임을 갖는 point cloud 데이터의 경우 하나 이상의 파일들이 획득될 수 있다. 이러한 과정에서 point cloud 관련 메타데이터 (예를 들어 캡처 등과 관련된 메타데이터 등)가 생성될 수 있다.
패치 제너레이션(Patch Generation) 또는 패치 제너레이터는 포인트 클라우드 데이터로부터 패치를 생성한다. 패치 제너레이터는 포인트 클라우드 데이터 또는 포인트 클라우드 비디오를 하나 이상의 픽처(picture)/프레임(frame)으로 생성한다. 픽처(picture)/프레임(frame)은 일반적으로 특정 시간대의 하나의 영상을 나타내는 단위를 의미할 수 있다. Point cloud 비디오를 구성하는 점들을 하나 이상의 패치(point cloud를 구성하는 점들의 집합으로, 같은 patch에 속하는 점들은 3차원 공간상에서 서로 인접해 있으며 2D 이미지로의 맵핑 과정에서 6면의 bounding box 평면 중 같은 방향으로 맵핑되는 점들의 집합)로 나누어2D 평면에 맵핑할 때 2D 평면의 해당 위치에 데이터가 존재하는 여부를 0 또는 1의 값으로 알려주는 2진 맵 (binary map) 인 어큐판시(occupancy) 맵 픽처/프레임을 생성할 수 있다. 그리고 Point Cloud 비디오를 이루는 각 점들의 위치 정보 (geometry)를 패치 단위로 표현하는 depth map 형태의 픽처/프레임인 지오메트리 픽처/프레임을 생성할 수 있다. Point cloud 비디오를 이루는 각 점들의 색상 정보를 패치 단위로 표현하는 픽처/프레임인 텍스처 픽처/프레임을 생성할 수 있다. 이러한 과정에서 개별 패치들로부터 point cloud를 재구성하기 위해 필요한 메타데이터가 생성될 수 있으며 이는 각 패치의2D/3D 공간에서의 위치, 크기 등 패치에 대한 정보를 포함할 수 있다. 이러한 픽처/프레임들이 시간순으로 연속적으로 생성되어 비디오 스트림 혹은 메타데이터 스트림을 구성할 수 있다.
또한, 패치는 2D 이미지 맵핑을 위해 사용될 수 있다. 예를 들어, 포인트 클라우드 데이터가 정육면체의 각 면에 프로젝션될 수 있다. 패치 제너레이션 후, 생성된 패치를 기반으로 지오메트리 이미지, 하나 또는 하나 이상의 어트리뷰트 이미지, 어큐판시 맵, Auxiliary 데이터 및/또는 Mesh 데이터 등이 생성될 수 있다.
프리-프로세서 또는 제어부(controller)에 의해 지오메트리 이미지 제너레이션(Geometry Image Generation), 어트리뷰트 이미지 제너레이션(Attribute Image Generation), 어큐판시 맵 제너레이션(Occupancy Map Generation), Auxiliary 데이터 제너레이션(Auxiliary Data Generation) 및/또는 Mesh 데이터 제너레이션(Mesh Data Generation)이 수행된다.
지오메트리 이미지 제너레이션(Geometry Image Generation)은 패치 제너레이션의 결과물에 기반하여 지오메트리 이미지를 생성한다. 지오메트리는 3차원 공간상의 포인트를 나타낸다. 패치에 기반하여 패치의 2D이미지 패킹에 관련된 정보를 포함하는 어큐판시 맵, Auxiliary 데이터(패치 데이터) 및/또는 Mesh 데이터 등을 사용하여, 지오메트리 이미지가 생성된다. 지오메트리 이미지는 패치 제너레이션 후 생성된 패치에 대한 뎁스(e.g., near, far) 등의 정보와 관련된다.
어트리뷰트 이미지 제너레이션(Attribute Image Generation)은 어트리뷰트 이미지를 생성한다. 예를 들어, 어트리뷰트는 텍스쳐(Texture)를 나타낼 수 있다. 텍스쳐는 각 포인트에 매칭되는 컬러 값일 수 있다. 실시예들에 따라서, 텍스쳐를 포함한 복수 개(N개)의 어트리뷰트(color, reflectance 등의 어트리뷰트) 이미지가 생성될 수 있다. 복수 개의 어트리뷰트는 머터리얼 (재질에 대한 정보), 리플렉턴스 등을 포함할 수 있다. 또한, 실시예들에 따라 어트리뷰트는 같은 텍스쳐라도 시각, 빛에 의해 컬러가 달라질 수 있는 정보를 추가적으로 포함할 수 있다.
어큐판시 맵 제너레이션(Occupancy Map Generation)은 패치로부터 어큐판시 맵을 생성한다. 어큐판시 맵은 해당 지오메트리 혹은 에트리뷰트 이미지 등의 픽셀에 데이터의 존재 유무를 나타내는 정보를 포함한다.
Auxiliary 데이터 제너레이션(Auxiliary Data Generation)은 패치에 대한 정보를 포함하는Auxiliary 데이터를 생성한다. 즉, Auxiliary 데이터는 Point Cloud객체의 패치에 관한 메타데이터를 나타낸다. 예를 들어, 패치에 대한 노멀(normal) 벡터 등의 정보를 나타낼 수 있다. 구체적으로, 실시예들에 따라 Auxiliary 데이터는 패치들로부터 포인트 클라우드를 재구성하기 위해서 필요한 정보를 포함할 수 있다(예를 들어, 패치의 2D/3D 공간 상 위치, 크기 등에 대한 정보, 프로젝션 평명(normal) 식별 정보, 패치 매핑 정보 등)
Mesh 데이터 제너레이션(Mesh Data Generation)은 패치로부터 Mesh 데이터를 생성한다. Mesh 는 인접한 포인트 들간의 연결정보를 나타낸다. 예를 들어, 삼각형 형태의 데이터를 나타낼 수 있다. 예를 들어, 실시예들에 따른 Mesh 데이터는 각 포인트 간의커넥티비티(connectivity) 정보를 의미한다.
포인트 클라우드 프리-프로세서 또는 제어부는 패치 제너레이션, 지오메트리 이미지 제너레이션, 어트리뷰트 이미지 제너레이션, 어큐판시 맵 제너레이션, Auxiliary 데이터 제너레이션, Mesh 데이터 제너레이션에 관련된 메타데이터(Metadata)를 생성한다.
포인트 클라우드 전송 장치는 프리-프로세서에서 생성된 결과물에 대응하여 비디오 인코딩 및/또는 이미지 인코딩을 수행한다. 포인트 클라우드 전송 장치는 포인트 클라우드 비디오 데이터뿐만 아니라 포인트 클라우드 이미지 데이터를 생성할 수 있다.실시예들에 따라 포인트 클라우드 데이터는 오직 비디오 데이터, 오직 이미지 데이터 및/또는 비디오 데이터 및 이미지 데이터 둘 다를 포함하는 경우가 있을 수 있다.
비디오 인코딩부는 지오메트리 비디오 컴프레션, 어트리뷰트 비디오 컴프레션, 어큐판시 맵 컴프레션, Auxiliary 데이터 컴프레션 및/또는 Mesh 데이터 컴프레션을 수행한다. 비디오 인코딩부는 각 인코딩된 비디오 데이터를 포함하는 비디오 스트림(들)을 생성한다.
구체적으로, 지오메트리 비디오 컴프레션은 point cloud 지오메트리 비디오 데이터를 인코딩한다. 어트리뷰트 비디오 컴프레션은 point cloud 의 어트리뷰트 비디오 데이터를 인코딩한다. Auxiliary 데이터 컴프레션은 point cloud 비디오 데이터와 연관된 Auxiliary 데이터를 인코딩한다. Mesh 데이터 컴프레션(Mesh data compression)은 Point Cloud 비디오 데이터의 Mesh 데이터를 인코딩한다. 포인트 클라우드 비디오 인코딩부의 각 동작은 병렬적으로 수행될 수 있다.
이미지 인코딩부는 지오메트리 이미지 컴프레션, 어트리뷰트 이미지 컴프레션, 어큐판시 맵 컴프레션, Auxiliary 데이터 컴프레션 및/또는 Mesh 데이터 컴프레션을 수행한다. 이미지 인코딩부는 각 인코딩된 이미지 데이터를 포함하는 이미지(들)을 생성한다.
구체적으로, 지오메트리 이미지 컴프레션은 point cloud 지오메트리 이미지 데이터를 인코딩한다. 어트리뷰트 이미지 컴프레션은 point cloud 의 어트리뷰트 이미지 데이터를 인코딩한다. Auxiliary 데이터 컴프레션은 point cloud 이미지 데이터와 연관된 Auxiliary 데이터를 인코딩한다. Mesh 데이터 컴프레션(Mesh data compression)은 point cloud 이미지 데이터와 연관된 Mesh 데이터를 인코딩한다. 포인트 클라우드 이미지 인코딩부의 각 동작은 병렬적으로 수행될 수 있다.
비디오 인코딩부 및/또는 이미지 인코딩부는 프리-프로세서로부터 메타데이터를 수신할 수 있다. 비디오 인코딩부 및/또는 이미지 인코딩부는 메타데이터에 기반하여 각 인코딩 과정을 수행할 수 있다.
파일/세그먼트 인캡슐레이션(File/Segment Encapsulation)부는 비디오 스트림(들) 및/또는 이미지(들)을 파일 및/또는 세그먼트의 형태로 인캡슐레이션한다. 파일/세그먼트 인캡슐레이션부는 비디오 트랙 인캡슐레이션, 메타데이터 트랙 인캡슐레이션 및/또는 이미지 인캡슐레이션을 수행한다.
비디오 트랙 인캡슐레이션은 하나 또는 하나 이상의 비디오 스트림을 하나 또는 하나 이상의 트랙에 인캡슐레이션할 수 있다.
메타데이터 트랙 인캡슐레이션은 비디오 스트림 및/또는 이미지에 관련된 메타데이터를 하나 또는 하나 이상의 트랙에 인캡슐레이션할 수 있다. 메타데이터는 포인트 클라우드 데이터의 컨텐츠에 관련된 데이터를 포함한다. 예를 들어, 이니셜 뷰잉 오리엔테이션 메타데이터(Initial Viewing Orientation Metadata)를 포함할 수 있다. 실시예들에 따라 메타데이터는 메타데이터 트랙에 인캡슐레이션 될 수 있고, 또는 비디오 트랙이나 이미지 트랙에 함께 인캡슐레이션될 수 있다.
이미지 인캡슐레이션은 하나 또는 하나 이상의 이미지들을 하나 또는 하나 이상의 트랙 혹은 아이템에 인캡슐레이션할 수 있다.
예를 들어, 실시예들에 따라 비디오 스트림이 4개 및 이미지가 2개를 인캡슐레이션부에 입력되는 경우, 4개의 비디오 스트림 및 2개의 이미지를 하나의 파일 안에 인캡슐레이션할 수 있다.
파일/세그먼트 인캡슐레이션부는 프리-프로세서로부터 메타데이터를 수신할 수 있다. 파일/세그먼트 인캡슐레이션부는 메타데이터에 기반하여 인캡슐레이션을 할 수 있다.
파일/세그먼트 인캡슐레이션에 의해 생성된 파일 및/또는 세그먼트는 포인트 클라우드 전송 장치 또는 전송부에 의해서 전송된다. 예를 들어, DASH 기반의 프로토콜에 기반하여 세그먼트(들)이 딜리버리(Delivery)될 수 있다.
딜리버리부(Delivery)는 point cloud 비트스트림 혹은 해당 비트스트림을 포함하는 파일/세그먼트를 디지털 저장매체 또는 네트워크를 통하여 수신 디바이스의 수신부로 전달할 수 있다. 전송을 위해 임의의 전송 프로토콜에 따른 처리가 수행될 수 있다. 전송을 위한 처리를 마친 데이터들은 방송망 및/또는 브로드밴드를 통해 전달될 수 있다. 이 데이터들은 온 디맨드(On Demand) 방식으로 수신측으로 전달될 수도 있다. 디지털 저장 매체는 USB, SD, CD, DVD, 블루레이, HDD, SSD 등 다양한 저장 매체를 포함할 수 있다. 딜리버리부는 미리 정해진 파일 포멧을 통하여 미디어 파일을 생성하기 위한 엘리먼트를 포함할 수 있고, 방송/통신 네트워크를 통한 전송을 위한 엘레멘트를 포함할 수 있다. 딜리버리부는 수신부로부터 오리엔테이션 정보 및/또는 뷰포트 정보를 수신한다. 딜리버리부는 획득한 오리엔테이션 정보 및/또는 뷰포트 정보(또는 사용자가 선택한 정보)를 프리-프로세서, 비디오 인코딩부, 이미지 인코딩부, 파일/세그먼트 인캡슐레이션부 및/또는 포인트 클라우드 인코딩부에 전달할 수 있다. 오리엔테이션 정보 및/또는 뷰포트 정보에 기반하여, 포인트 클라우드 인코딩부는 모든 포인트 클라우드 데이터를 인코딩하거나 또는 오리엔테이션 정보 및/또는 뷰포트 정보가 나타내는 포인트 클라우드 데이터를 인코딩할 수 있다. 오리엔테이션 정보 및/또는 뷰포트 정보에 기반하여, 파일/세그먼트 인캡슐레이션부는 모든 포인트 클라우드 데이터를 인캡슐레이션하거나 또는 오리엔테이션 정보 및/또는 뷰포트 정보가 나타내는 포인트 클라우드 데이터를 인캡슐레이션할 수 있다. 오리엔테이션 정보 및/또는 뷰포트 정보에 기반하여, 딜리버리부는 모든 포인트 클라우드 데이터를 딜리버리하거나 또는 오리엔테이션 정보 및/또는 뷰포트 정보가 나타내는 포인트 클라우드 데이터를 딜리버리할 수 있다.
예를 들어, 프리-프로세서는 모든 포인트 클라우드 데이터에 대해 상술한 동작을 수행하거나 또는 오리엔테이션 정보 및/또는 뷰포트 정보가 나타내는 포인트 클라우드 데이터에 대해 상술한 동작을 수행할 수 있다. 비디오 인코딩부 및/또는 이미지 인코딩부는 모든 포인트 클라우드 데이터에 대해 상술한 동작을 수행하거나 또는 오리엔테이션 정보 및/또는 뷰포트 정보가 나타내는 포인트 클라우드 데이터에 대해 상술한 동작을 수행할 수 있다. 파일/세그먼트 인캡슐레이션부는 모든 포인트 클라우드 데이터에 대해 상술한 동작을 수행하거나 또는 오리엔테이션 정보 및/또는 뷰포트 정보가 나타내는 포인트 클라우드 데이터에 대해 상술한 동작을 수행할 수 있다. 전송부는 모든 포인트 클라우드 데이터에 대해 상술한 동작을 수행하거나 또는 오리엔테이션 정보 및/또는 뷰포트 정보가 나타내는 포인트 클라우드 데이터에 대해 상술한 동작을 수행할 수 있다.
도 12는 실시예들에 따른 포인트 클라우드(point cloud) 데이터 처리 장치의 예시를 나타낸다.
도 12는 V-PCC 방식에 따라 처리된 포인트 클라우드 데이터를 수신하고 처리하는 동작을 수행하는 장치의 예시를 나타낸다. 도 12에 도시된 point cloud 데이터 처리 장치는 도 11에서 설명한 방식에 대응하는 방식으로 데이터를 처리할 수 있다. 도 12에 도시된 포인트 클라우드 데이터 처리 장치는 도 1 내지 도 8에서 설명한 UE에 해당하거나 UE에 포함될 수 있다(예를 들면 도 2에서 설명한 프로세서(911) 또는 프로세서(921), 상위 계층 데이터를 처리하는 프로세서, 또는 도 6에서 설명한 Sink 또는 Sink에 포함된 XR Media Processing 블록 등).
실시예들에 따른 Point Cloud 데이터 처리 장치는 딜리버리 클라이언트(Delivery Client), 센싱/트랙킹부(Sensing/Tracking), 파일/세그먼트 디캡슐레이션부(File/Segment decapsulation), 비디오 디코딩부(Video Decoding), 이미지 디코딩부(Image Decoding), 포인트 클라우드 프로세싱 및/또는 Point Cloud 렌더링부(Point Cloud Rendering), 디스플레이를 포함한다. 비디오 디코딩부는 지오메트리 비디오 디컴프레션(Geometry Video Decompression), 어트리뷰트 비디오 디컴프레션(Attribute Video Decompresssion), 어큐판시 맵 디컴프레션(Occupancy Map Decompression), Auxiliary 데이터 디컴프레션(Auxiliary Data Decompression) 및/또는 Mesh 데이터 디컴프레션(Mesh Data Decompression)를 포함한다. 이미지 디코딩부는 지오메트리 이미지 디컴프레션(Geometry Image Decompression), 어트리뷰트 이미지 디컴프레션(Attribute Image Decompresssion), 어큐판시 맵 디컴프레션(Occupancy Map Decompression), Auxiliary 데이터 디컴프레션(Auxiliary Data Decompression) 및/또는 Mesh 데이터 디컴프레션(Mesh Data Decompression)를 포함한다. 포인트 클라우드 프로세싱은 지오메트리 리컨스턱션(Geometry Reconstruction), 어트리뷰트 리컨스트럭션(Attribute Reconstruction)를 포함한다.
딜리버리 클라이언트(Delivery Client)는 도 13의 실시예들에 따른 point cloud 데이터 처리 장치가 전송한 point cloud 데이터, point cloud 비트스트림 혹은 해당 비트스트림을 포함하는 파일/세그먼트를 수신할 수 있다. 전송되는 채널에 따라 도 14의 장치는 방송망을 통하여 point cloud데이터를 수신할 수도 있고, 브로드밴드를 통하여 point cloud데이터를 수신할 수도 있다. 혹은 디지털 저장 매체를 통하여 point cloud 비디오 데이터를 수신할 수도 있다. 도 14의 장치는 수신한 데이터를 디코딩 하고 이를 사용자의 뷰포트 등에 따라 랜더링하는 과정을 수행할 수 있다. 도 14의 장치는 도면에 도시되지 않았으나 수신 처리부(예를 들면 도 2의 프로세서(911) 등)를 포함할 수 있다. 실시예들에 따른 수신 처리부는 수신된 point cloud데이터에 대해 전송 프로토콜에 따른 처리를 수행할 수 있다. 전송측에서 전송을 위한 처리가 수행된 것에 대응되도록, 수신 처리부는 전술한 전송 처리부의 역과정을 수행할 수 있다. 수신 처리부는 획득한 point cloud 데이터는 디캡슐레이션 처리부로 전달하고, 획득한 point cloud 관련 메타데이터는 메타데이터 파서로 전달할 수 있다.
센싱/트랙킹부(Sensing/Tracking)는 오리엔테이션 정보 및/또는 뷰포트 정보를 획득한다. 센싱/트랙킹부는 획득한 오리엔테이션 정보 및/또는 뷰포트 정보를 딜리버리 클라이언트, 파일/세그먼트 디캡슐레이션부, 포인트 클라우드 디코딩부에 전달할 수 있다.
딜리버리 클라이언트는 오리엔테이션 정보 및/또는 뷰포트 정보에 기반하여, 모든 포인트 클라우드 데이터를 수신하거나 또는 오리엔테이션 정보 및/또는 뷰포트 정보가 나타내는 포인트 클라우드 데이터를 수신할 수 있다. 파일/세그먼트 디캡슐레이션부는 오리엔테이션 정보 및/또는 뷰포트 정보에 기반하여, 모든 포인트 클라우드 데이터를 디캡슐레이션하거나 또는 오리엔테이션 정보 및/또는 뷰포트 정보가 나타내는 포인트 클라우드 데이터를 디캡슐레이션할 수 있다. 포인트 클라우드 디코딩부(비디오 디코딩부 및/또는 이미지 디코딩부)는 오리엔테이션 정보 및/또는 뷰포트 정보에 기반하여, 모든 포인트 클라우드 데이터를 디코딩하거나 또는 오리엔테이션 정보 및/또는 뷰포트 정보가 나타내는 포인트 클라우드 데이터를 디코딩할 수 있다. 포인트 클라우드 프로세싱부는 모든 포인트 클라우드 데이터를 처리하거나 또는 오리엔테이션 정보 및/또는 뷰포트 정보가 나타내는 포인트 클라우드 데이터를 처리할 수 있다.
파일/세그먼트 디캡슐레이션부(File/Segment decapsulation)는 비디오 트랙 디캡슐레이션(Video Track Decapsulation), 메타데이터 트랙 디캡슐레이션(Metadata Track Decapsulation) 및/또는 이미지 디캡슐레이션(Image Decapsulation)을 수행한다. 디캡슐레이션 처리부(file/segment decapsulation)는 수신 처리부로부터 전달받은 파일 형태의 point cloud데이터를 디캡슐레이션할 수 있다. 디캡슐레이션 처리부는 ISOBMFF 등에 따른 파일 혹은 세그먼트들을 디캡슐레이션하여, point cloud비트스트림 내지 point cloud 관련 메타데이터(혹은 별도의 메타데이터 비트스트림)를 획득할 수 있다. 획득된 point cloud비트스트림은 point cloud디코더로, 획득된 point cloud관련 메타데이터(혹은 메타데이터 비트스트림)는 메타데이터 처리부로 전달할 수 있다. point cloud비트스트림은 메타데이터(메타데이터 비트스트림)를 포함할 수도 있다. 메타데이터 처리부는 point cloud 비디오 디코더에 포함될 수도 있고, 또는 별도의 컴포넌트/모듈로 구성될 수도 있다. 디캡슐레이션 처리부가 획득하는 point cloud관련 메타데이터는 파일 포맷 내의 박스 혹은 트랙 형태일 수 있다. 디캡슐레이션 처리부는 필요한 경우 메타데이터 처리부로부터 디캡슐레이션에 필요한 메타데이터를 전달받을 수도 있다. point cloud관련 메타데이터는 point cloud디코더에 전달되어 point cloud디코딩 절차에 사용될 수도 있고, 또는 렌더러에 전달되어 point cloud렌더링 절차에 사용될 수도 있다. 파일/세그먼트 디캡슐레이션부는 포인트 클라우드 데이터에 관련된 메타데이터를 생성할 수 있다.
비디오 트랙 디캡슐레이션(Video Track Decapsulation)은 파일 및/또는 세그먼트에 포함된 비디오 트랙을 디캡슐레이션한다. 지오메트리 비디오, 어트리뷰트 비디오, 어큐판시 맵, Auxiliary 데이터 및/또는 Mesh 데이터를 포함하는 비디오 스트림(들)을 디캡슐레이션한다.
메타데이터 트랙 디캡슐레이션(Metadata Track Decapsulation)은 포인트 클라우드 데이터에 관련된 메타데이터 및/또는 부가 데이터 등을 포함하는 비트스트림을 디캡슐레이션한다.
이미지 디캡슐레이션(Image Decapsulation)은 지오메트리 이미지, 어트리뷰트 이미지, 어큐판시 맵, Auxiliary 데이터 및/또는 Mesh 데이터를 포함하는 이미지(들)을 디캡슐레이션한다.
비디오 디코딩부(Video Decoding)는 지오메트리 비디오 디컴프레션, 어트리뷰트 비디오 디컴프레션, 어큐판시 맵 디컴프레션, Auxiliary 데이터 디컴프레션 및/또는 Mesh데이터 디컴프레션을 수행한다. 비디오 디코딩부는 실시예들에 따른 포인트 클라우드 전송 장치의 비디오 인코딩부가 수행한 프로세스에 대응하여 지오메트리 비디오, 어트리뷰트 비디오, Auxiliary데이터 및/또는 Mesh데이터를 디코딩한다.
이미지 디코딩부(Image Decoding)는 지오메트리 이미지 디컴프레션, 어트리뷰트 이미지 디컴프레션, 어큐판시 맵 디컴프레션, Auxiliary 데이터 디컴프레션 및/또는 Mesh데이터 디컴프레션을 수행한다. 이미지 디코딩부는 실시예들에 따른 포인트 클라우드 전송 장치의 이미지 인코딩부가 수행한 프로세스에 대응하여 지오메트리 이미지, 어트리뷰트 이미지, Auxiliary데이터 및/또는 Mesh데이터를 디코딩한다.
비디오 디코딩부 및/또는 이미지 디코딩부는 비디오 데이터 및/또는 이미지 데이터에 관련된 메타데이터를 생성할 수 있다.
포인트 클라우드 프로세싱부(Point Cloud Processing)은 지오메트리 리컨스트럭션(Geometry Reconstruction) 및/또는 어트리뷰트 리컨스트럭션(Attribute Reconstruction)을 수행한다.
지오메트리 리컨스턱션은 디코딩된 비디오 데이터 및/또는 디코딩된 이미지 데이터로부터 어큐판시 맵, Auxiliary 데이터 및/또는 Mesh데이터에 기반하여 지오메트리 비디오 및/또는 지오메트리 이미지를 복원한다.
어트리뷰트 리컨스럭션은 디코딩된 어트리뷰트 비디오 및/또는 디코딩된 어트리뷰트 이미지로부터 어큐판시 맵, Auxiliary 데이터 및/또는 Mesh데이터에 기반하여 어트리뷰트 비디오 및/또는 어트리뷰트 이미지를 복원한다. 실시예들에 따라, 예를 들어, 어트리뷰트는 텍스쳐일 수 있다. 실시예들에 따라 어트리뷰트는 복수 개의 어트리뷰트 정보를 의미할 수 있다. 복수개의 어트리뷰트가 있는 경우, 실시예들에 따른 포인트 클라우드 프로세싱부는 복수개의 어트리뷰트 리컨스럭션을 수행한다.
포인트 클라우드 프로세싱부는 비디오 디코딩부, 이미지 디코딩부 및/또는 파일/세그먼트 디캡슐레이션부로부터 메타데이터를 수신하고, 메타데이터게 기반하여 포인트 클라우드를 처리할 수 있다.
포인트 클라우드 렌더링부(Point Cloud Rendering)는 리컨스럭션된 포인트 클라우드를 렌더링한다. 포인트 클라우드 렌더링부는 비디오 디코딩부, 이미지 디코딩부 및/또는 파일/세그먼트 디캡슐레이션부로부터 메타데이터를 수신하고, 메타데이터게 기반하여 포인트 클라우드를 렌더링할 수 있다. 도 12에 도시되지 않았으나 도 12의 장치는 디스플레이를 포함할 수 있다. 실시예들에 따른 디스플레이는 랜더링된 결과를 디스플레이할 수 있다.
도 13은 실시예들에 따른 포인트 클라우드(point cloud) 데이터 처리 장치의 예시를 나타낸다.
도 13은 도 9에서 설명한 G-PCC 방식에 따라 포인트 클라우드 데이터 처리 동작을 수행하는 장치의 예시를 나타낸다. 실시예들에 따른 point cloud 데이터 처리 장치는 데이터 입력부(12000), 양자화 처리부(12001), 복셀화 처리부(12002), 옥트리 Occupancy 코드 생성부(12003), 포면 모델 처리부(12004), 인트라/인터 코딩 처리부(12005), Arithmetic 코더(12006), 메타데이터 처리부(12007), 색상 변환 처리부(12008), 어트리뷰트 변환 처리부(12009), 예측/리프팅/RAHT 변환 처리부(12010), Arithmetic 코더(12011) 및/또는 전송 처리부(12012)를 포함할 수 있다.
실시예들에 따른 데이터 입력부(12000)는 포인트 클라우드 데이터를 수신 또는 획득한다. 데이터 입력부(12000)는 실시예들에 따른 도1의 포인트 클라우드 획득부(10001)에 대응될 수 있다.
실시예들에 따른 양자화 처리부(12001)는 포인트 클라우드 데이터의 지오메트리, 예를 들어, 포인트들의 위치값 정보를 양자화한다.
실시예들에 따른 복셀화 처리부(12002)는 양자화된 포인트들의 위치값 정보를 복셀화한다.
실시예들에 따른 옥트리 Occupancy 코드 생성부(12003)는 복셀화된 포인트들의 위치값 정보를 옥트리 어큐판시 코드에 기반하여 옥트리로 나타낼 수 있다.
실시예들에 따른 포면 모델 처리부(12004)는 포인트 클라우드의 포인트들의 위치값 정보에 대한 옥트리를 표면 모델 방식에 기반하여 표현 처리할 수 있다
실시예들에 따른 인트라/인터 코딩 처리부(12005)는 포인트 클라우드 데이터를 인트라/인터 코딩할 수 있다.
실시예들에 따른 Arithmetic 코더(12006)는 포인트 클라우드 데이터를 아리스메틱 코딩 방식에 기반하여 인코딩할 수 있다.
실시예들에 따른 메타데이터 처리부(12007)는 포인트 클라우드 데이터에 관한 메타데이터, 예를 들어 설정 값 등을 처리하여 지오메트리 인코딩 프로세스 및/또는 어트리뷰트 인코딩 프로세스 등 필요한 과정에 제공한다. 또한 실시예들에 따른 메타데이터 처리부(12007)는 지오메트리 인코딩 및/또는 어트리뷰트 인코딩과 관련된 시그널링 정보를 생성 및/또는 처리할 수 있다. 실시예들에 따른 시그널링 정보는 지오메트리 인코딩 및/또는 어트리뷰트 인코딩과 별도로 인코딩처리될 수 있다. 또한 실시예들에 따른 시그널링 정보는 인터리빙 처리 될 수도 있다.
실시예들에 따른 색상 변환 처리부(12008)는 포인트 클라우드 데이터의 어트리뷰트, 예를 들어, 포인트들의 어트리뷰트값 정보 및/또는 재구성된 위치값에 기반하여 포인트 클라우드 데이터의 컬러를 변환할 수 있다.
실시예들에 따른 어트리뷰트 변환 처리부(12009)는 포인트 클라우드 데이터의 어트리뷰트값을 변환할 수 있다.
실시예들에 따른 예측/리프팅/RAHT 변환 처리부(12010)는 포인트 클라우드 데이터를 예측 방법, 리프팅 방법 및/또는 RAHT 방법 등의 조합 등에 기반하여 어트리뷰트 코딩할 수 있다.
실시예들에 따른 Arithmetic 코더(12011)는 포인트 클라우드 데이터를 아리스메틱 코딩 방식에 기반하여 인코딩할 수 있다.
실시예들에 따른 전송 처리부(12012)는 인코딩된 지오메트리 정보 및/또는 인코딩된 어트리뷰트정보, 메타 데이터 정보를 포함하는 각 비트스트림을 전송하거나, 인코딩된 지오메트리 정보 및/또는 인코딩된 어트리뷰트 정보, 메타 데이터 정보를 하나의 비트스트림으로 구성하여 전송할 수 있다. 실시예들에 따른 인코딩된 지오메트리 정보 및/또는 인코딩된 어트리뷰트 정보, 메타 데이터 정보가 하나의 비트스트림으로 구성되는 경우, 비트스트림은 하나 또는 그 이상의 서브 비트스트림들을 포함할 수 있다. 실시예들에 따른 비트스트림은 시퀀스 레벨의 시그널링을 위한 SPS (Sequence Parameter Set), 지오메트리 정보 코딩의 시그널링을 위한 GPS(Geometry Parameter Set), 어트리뷰트 정보 코딩의 시그널링을 위한 APS(Attribute Parameter Set), 타일 레벨의 시그널링을 위한 TPS (Tile Parameter Set)를 포함하는 시그널링 정보 및 슬라이스 데이터를 포함할 수 있다. 슬라이스 데이터는 하나 또는 그 이상의 슬라이스들에 대한 정보를 포함할 수 있다. 실시예들에 따른 하나의 슬라이스는 하나의 지오메트리 비트스트림(Geom00) 및 하나 또는 그 이상의 어트리뷰트 비트스트림들(Attr00, Attr10)을 포함할 수 있다. 실시예들에 따른 TPS는 하나 또는 그 이상의 타일들에 대하여 각 타일에 관한 정보(예를 들면 bounding box의 좌표값 정보 및 높이/크기 정보 등)을 포함할 수 있다. 지오메트리 비트스트림은 헤더와 페이로드를 포함할 수 있다. 실시예들에 따른 지오메트리 비트스트림의 헤더는 GPS에 포함된 파라미터 세트의 식별 정보(geom_geom_parameter_set_id), 타일 식별자(geom_tile id), 슬라이스 식별자(geom_slice_id) 및 페이로드에 포함된 데이터에 관한 정보 등을 포함할 수 있다. 상술한 바와 같이 실시예들에 따른 메타데이터 처리부(12007)는 시그널링 정보를 생성 및/또는 처리하여 전송 처리부(12012)로 전송할 수 있다. 실시예들에 따라, 포인트들의 위치값에 대한 프로세스 및 포인트들의 어트리뷰트값에 대한 프로세스는 서로의 데이터/정보를 공유하여 각 과정을 수행할 수 있다.
도 14는 실시예들에 따른 포인트 클라우드(point cloud) 데이터 처리 장치의 예시를 나타낸다.
도 14는 도 10에서 설명한 G-PCC 방식에 따라 포인트 클라우드 데이터 처리 동작을 수행하는 장치의 예시를 나타낸다. 도 14에 도시된 포인트 클라우드 데이터 처리 장치는 도 13에서 설명한 Point Cloud 데이터 처리 장치의 역과정을 수행할 수 있다.
실시예들에 따른 point cloud 데이터 처리 장치는 수신부(13000), 수신 처리부(13001), Arithmetic 디코더(13002), Occupancy코드 기반 옥트리 재구성 처리부(13003), 표면 모델 처리부(삼각형 재구성, 업-샘플링, 복셀화)(13004), inverse 양자화 처리부(13005), 메타데이터 파서(13006), arithmetic 디코더(13007), inverse양자화 처리부(13008), 예측/리프팅/RAHT 역변환 처리부(13009), 색상 역변환 처리부(13010) 및/또는 렌더러(13011)를 포함할 수 있다.
실시예들에 따른 수신부(13000)는 포인트 클라우드 데이터를 수신한다. 실시예들에 따른 수신 처리부(13001)는 수신한 포인트 클라우드 데이터에 포함된 지오메트리 비트스트림 및/또는 어트리뷰트 비트스트림, 시그널링 정보를 포함하는 메타 데이터 등을 획득할 수 있다.
실시예들에 따른 Arithmetic 디코더(13002)는 지오메트리 비트스트림을 아리스메틱 방식에 기반하여 디코딩할 수 있다.
실시예들에 따른 Occupancy코드 기반 옥트리 재구성 처리부(13003)는 디코딩된 지오메트리를 Occupancy 코드에 기반하여 옥트리로 재구성할 수 있다.
실시예들에 따른 표면 모델 처리부(삼각형 재구성, 업-샘플링, 복셀화)(13004)는 표면 모델 방식에 기반하여 포인트 클라우드 데이터에 대해 삼각형 재구성, 업-샘플링, 복셀화 및/또는 그것들의 조합에 따른 처리를 수행할 수 있다.
실시예들에 따른 inverse 양자화 처리부(13005)는 포인트 클라우드 데이터를 인버스 양자화할 수 있다.
실시예들에 따른 메타데이터 파서(13006)는 수신한 포인트 클라우드 데이터에 포함된 메타데이터, 예를 들어 설정 값 등을 파싱할 수 있다. 메타데이터 파서(13006)는 메타데이터를 지오메트리 디코딩 프로세스 및/또는 어트리뷰트 디코딩 프로세스의 각 과정에 전달할 수 있다. 실시예들에 따른 각 프로세스는 필요한 메타데이터에 기반하여 수행될 수 있다.
실시예들에 따른 arithmetic 디코더(13007)는 포인트 클라우드 데이터의 어트리뷰트 비트스트림을 재구성된 위치값에 기반하여 아리스메틱 방식에 기반하여 디코딩할 수 있다.
실시예들에 따른 inverse양자화 처리부(13008)는 포인트 클라우드 데이터를 인버스 양자화할 수 있다.
실시예들에 따른 예측/리프팅/RAHT 역변환 처리부(13009)는 포인트 클라우드 데이터를 예측/리프팅/RAHT 방식 및/또는 그것들의 조합에 따른 방식에 기반하여 처리할 수 있다.
실시예들에 따른 색상 역변환 처리부(13010)는 포인트 클라우드 데이터의 색상 값을 역변환할 수 있다. 실시예들에 따른 렌더러(13011)는 포인트 클라우드 데이터를 렌더링할 수 있다.
도15는 실시예들에 따른 임의 방문 네트워크(Visited Network) 상 UE를 위한 전송 구조를 나타낸다.
3GPP (The 3rd Generation Partnership Project) 에서 Multimedia 분과는 미디어 코덱과 관련된 프로토콜을 정의하여 미디어를 송신 및 수신할 수 있는 표준을 제정하고 배포한다. 미디어라고 하는 정의와 전송 시나리오는 다양한 범위를 포함한다. Radio Access 그리고 Internet기반의 기술과 함께 개인 컴퓨터 또는 휴대 수신기가 이동/고정 수신을 하였을 경우를 포함한다. 3GPP에서 진행된 이러한 광범위한 표준 제정은 유비쿼터스 멀티미디어 서비스를 다양한 사용자와 Use Case를 포괄하며 언제, 어디서든 고품질 미디어를 빠르게 경험할 수 있게 하였다. 특히, 3GPP에서 미디어 서비스는 각각의 고유의 특성에 따라 분류 되며 Target Application에 따라 Conversational, Streaming, 그 외 서비스로 나뉘어 진다. Conversational Service는 Session Initiation Protocol (SIP) 기반의 전화 서비스망에서 확장 된다. 이 중 Multimedia Telephony Service for the IP Multimedia Subsystem (MTSI)는 저 지연 실시간 대화 서비스를 목표로 하고 있다. Streaming서비스는 Packet Switched Service (PSS)기반으로 실시간 또는 재 획득되는 콘텐트를 Unicast방식으로 전달한다. 3GPP는 PSS시스템 내 방송 서비스는 Multimedia Broadcast/Multicast Service (MBMS)를 통해 모바일 TV를 이용할 수 있다. 그 외 3GPP에서는 Messaging 또는 현실감 서비스를 제공한다. 앞서 설명한 3가지 기반 서비스는 가능한 고품질의 유저 경험을 만족하기 위해 표준의 개정 또는 업데이트가 지속적으로 이루어 지고 있으며 Scalability를 제공하여 가용 내 네트워크 자원 또는 기존 표준에 상호 호환이 될 수 있도록 하고 있다. 미디어는 비디오 코덱, 음성, 오디오, 이미지, 그래픽, 그리고 각각의 서비스에 해당하는 텍스트까지 포함한다.
3GPP에서는 이동형 멀티미디어 수신을 위해 규격화된 플랫폼을 구성하여 네트워크 확장 또는 이동 수신에 용이하도록 설계 하였다. IP Multimedia Subsystem (IMS)는 이러한 요구사항에 적합하도록 설계 되어 있으며 다양한 기술을 접근할 수 있거나 로밍 서비스를 가능하게 하였다. IMS는 Internet Engineering Task Force (IETF)표준을 기반으로 구성되어 있으며 IETF 표준은 인터넷 플랫폼에서 작동하기 때문에 기존 인터넷 프로토콜의 Setup, Establishment, Management기능을 단순하게 확장할 수 있다. 따라서 IMS는 SIP프로토콜이 기본 프로토콜로 사용하고 있으며 이를 통해 멀티미디어 세션을 효율적으로 관리한다.
3GPP표준 기술에서는 서비스를 모바일 플랫폼을 기반으로 하기 때문에 유저가 제 3 또는 타 지역의 모바일 네트워크 또는 플랫폼에 연결 되었을 경우 다른 네트워크로 로밍을 해야 하는 문제점이 발생 하였다. 이런 시나리오에서 클라이언트는 다수의 모바일 네트워크 망에서 세션을 유지할 수 있는 방법이 요구되었다. 또한 IP기반의 미디어 서비스 요구사항이 증가하면서 고용량의 IP기반 데이터 전송, 대화, 멀티미디어를 전송 해야 하는 요구사항이 증가하였다. 따라서 일반적인 IP 라우팅 방식이 아닌 3G, 4G, 5G 네트워크 망에서 상호 교환적인 형태로 IP패킷이 전달되어야만 했다. 혼합적인 망 환경에서 QoS를 유지하기 위해 서비스를 교환화는 과정에서 유연한 데이터 정보 교환 및 플랫폼이 필요하게 되었다. 과거 10년 이상 인터넷 망과 무선 모바일 망을 통합하기 위해 3GPP 표준에서는 IP기반의 IP Multimedia Subsystem (IMS) 표준을 제정하였으며 PS 도메인에셔 IP 음성, 비디오, 오디오, 텍스트를 전송할 수 있게 하였다. MTSI (Multimedia Telephony Service for IMS)는 IMS기반에서 Conversational Speech, Video, Text를 RTP/RTCP를 통해 전송하기 위한 표준이며 Flexible Data Channel Handling을 통해 사용자가 기존 Circuit Switched (CS)기반 Conversational Service 대비 동일 또는 고 효율 서비스를 제공하기 위해 제정되었다. MTSI는 Signalling, Transport, Jitter Buffer, Management, Packet-Loss Handling, Adaptation 뿐 아니라 Adding/Dropping Media During Call등의 포함되어 예측 가능한 미디어를 생성하고 전달하고 수신할 수 있도록 형성되어 있다. MTSI는 3GPP 망을 사용하기 때문에, NR, LTE, HSPA 등이 IMS에 연결되어 있으며 Wi-Fi, Bluetooth등과도 확장되어 연결된다. MTSI는 기존 IMS망에 데이터 협상 메시지를 송신 및 수신하게 되며 송수신이 완료되면 데이터는 유저간 전달되는 구조를 가지고 있다. 그러므로 IMS망을 동일하게 이용할 수 있으며 MTSI는 Audio Encoder/Decoder, Video Encoder/Decoder, Text, Session Setup and Control, Data Channel만을 추가적으로 정의 한다. Data Channel Capable MTSI (DCMTSC)는 미디어 전송을 지원하기 위한 가능 채널을 나타내며 Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS), Web Real-Time Communication (WebRTC)을 사용한다. SCTP를 사용하여 TCP의 Network Layer/Transport Layer간 보안 서비스를 제공한다. 기존 존재하는 플랫폼에서 확장되기 때문에 미디어를 관리하기 위한 Media Control, Media Codec 뿐만 아니라 Media Control Data를 정의하며 일반적인 컨트롤은 SIP/SDP를 통해 Media Streaming Setup을 통해 처리된다. 클라이언트 사이에 Setup/Control이 전달되기 때문에 미디어의 Adding/Dropping도 포함된다. MTSI는 Non-conversational Service인 IMS Messaging도 포함한다. 미디어는 3GPP Layer 2를 통해 전달되는데 사용 되는 것은 Packet Data Convergence Protocol (PDCP)를 사용한다. PDCP는 클라이언트에 있는 IP패킷을 Base Station까지 전달하며 일반적으로 User Plane Data, Control Plane Data, Header Compression, Ciphering/Protection을 수행한다.
도15는 UE (User Equipment) A/B가 존재할 때 콜 세션(Call Session)이 임의의 방문 네트워크 (Visited Network)에 존재하는 두 개의 UE간 전달될 수 있는 전송 구조이다. UE A/B는 오퍼레이터(Operator) A혹은 B 혹은 동일 네트워크 안에 존재할 수 있으며 MTSI의 전체 시스템을 설명하기 위해 4개의 타 네트워크가 존재한다고 가정한다. Call을 수행하기 위해서 UE A와 B는 IMS시스템 내에서 미디어를 전송하기 위한 세션 성립(Session Establishment)를 수행한다. 세션이 형성되고 나면 UE A와 B는 IP망을 통해 미디어를 전송한다. IMS 주요 기능은 Call State Control Function (CSCF)로 SIP를 사용하여 멀티미디어 세션을 관리한다. 각각의 CSCF는 서버 또는 Proxy역할을 수행하며 각각의 목적에 따라 다른 형태의 기능을 수행한다. Proxy CSCF (P-CSCF)는 SIP Proxy 서버 역할을 수행한다. IMS네트워크게 가장 먼저 접근하며 UE A와 B를 연결하는 가장 최초의 블록이다. P-CSCF는 모든 SIP 메시지를 수신하고 송신하고자 하는 UE까지 전달하기 위해서 내부적으로 SIP 메시지를 분석하고 전달하는 역할을 수행한다. P-CSCF는 자원관리를 수행할 수 있으며 네트워크의 Gateway와 밀접하게 연결되어 있다. 게이트웨이는 IP 접속 베어러인 General Packet Radio Service (GPRS)와 연결된다. GPRS는 2세대 무선 시스템이지만 PS 서비스를 지원하기 위한 기본 기능과 연결되어 있다. P-CSCF, GPRS는 같은 네트워크 안에 있어야 한다. 위 그림에서 UE A는 임의의 Visited Network에 존재하며 네트워크 내 UE A, P-CSCF가 존재한다. Serving CSCF (S-CSCF)는 SIP서버로 구독자의 홈 네트워크에 존재하며 구독자를 위한 세션 컨트롤 서비스를 제공한다. Proxy또는 Visited 네트워크가 존재하지 않는 경우 UE A 또는 B는 Operator A, B에 존재할 수 있으며 홈 네트워크 내 UE가 존재할 수 있다. IMS 시스템에서 S-CSCF는 Signalling에서 주요 기능 역할을 하며 SIP register역할을 수행한다. 따라서. 유저의 SIP IP주소를 생성하거나 현재 IP주소를 생성할 수 있다. S-CSCF는 또한 Home Subscriber Server (HSS)를 통해 인증 또는 HSS에 존재하는 다양한 유저의 프로파일을 획득할 수 있다. 수신되는 모든 SIP메시지는 S-CSCF를 거쳐야 한다. S-CSCF는 메시지를 수신하여 근처에 있는 다른 CSCF와 연결하거나 Application Server (AS)와 연결하여 다른 AS에 SIP메시지를 전달할 수 있다. Interrogating CSCF (I-CSCF)는 P-CSCF와 동일하게 Proxy서버 기능을 수행하나 외부 네트워크와 연결되어 있다. 네트워크 가용성, 네트워크 구성 형태 등을 관찰하여 SIP 메시지를 암호화 하는 과정을 수행할 수 있다. HSS는 중앙 데이터 서버로 유저와 관련된 정보를 포함한다. Subscriber Location Function (SLF)는 유저의 주소를 해당하는 HSS에 연결하는 정보 맵을 나타낸다. Multimedia Resource Function (MRF)는 홈 네트워크에서 멀티미디어 자원을 포함한다. MRF는 Multimedia Resource Function Controller (MRFC)와 Multimedia Resource Function Processor (MRFP)로 구성된다. MRFC는 MRC의 컨트롤 플레인으로 MRFP내에서 스트림 리소스를 관리하는 컨트롤 역할을 수행한다. Breakout Gateway Control Function (BGCF)는 SIP서버로 Public-Switched Telephone Network (PSTN) 또는 Communication Server (CS)와 연결되어 SIP메시지를 전달하는 게이트웨이를 나타낸다. Media Gateway Control Function (MGWF)과 Media Gateway (MGW)는 미디어를 CS네트워크로 전달하기 위한 인터페이스와 시그널링을 전달하는 역할을 한다.
도16은 실시예들에 따른 UE간 콜 연결을 나타낸다.
IMS기반 망에서는 IP연결이 가능한 환경이어야 하며 IP 연결은 Home Network 또는 Visited Network에서 수행된다. IP연결이 이루어지면 XR 세부 요소인 대화형 환경 구성이 이루어 지며 전송되는 데이터는 360 Video/G-PCC (Geometry-based Point Cloud Compression)/V-PCC (Video-based Point Cloud Compression)등의 가상 현실 데이터가 압축된 정보들이 교환되거나 데이터가 전달된다. XR의 데이터는 2가지 영역으로 세분화되어 전달될 수 있다. MTSI 표준을 기반으로 전송되는 경우 CSCF 메커니즘을 이용하여 Route Control Plane 시그널링을 통해 AS는 Call/Hold/Resume방식을 전달하고 제 3자의 Call연결을 수행한다. Call연결이 수행되면 Media전송은 단순히 UE A/B사이에 전달되며 2개의 UE가 존재하는 경우 IMS망 내에서 MTSI는 도16과 같이 작동한다.
도17은 실시예들에 따른 포인트 클라우드 데이터 송수신 장치를 나타낸다.
비디오 인코더, 오디오 인코더는 XR디바이스(100c), 도8 인코딩(S1520), 도9, 도11, 도13 포인트 클라우드 인코더 등에 대응할 수 있다.
비디오 디코더, 오디오 디코더는 XR디바이스(100c), 도8 디코딩(S1540), 도10, 도12, 도14 포인트 클라우드 디코더 등에 대응할 수 있다.
MTSI는 IMS망 내에서 Client Terminal의 관련 요소들과 연결점을 제한한다. 따라서 그 구성에 대한 Scope은 도17과 같이 정의된다.
도17에서, 스피커(Speaker), 디스플레이(Display), 유저 인터페이스(User Interface), 마이크로폰(Microphone), 카메라(Camera), 키보드(Keyboard)와 관련된 동기화의 물리적 상호 작용에 대한 결정은 MTSI에서 논의되지 않는다. 박스(170) 안에 있는 부분에서 미디어를 조절하거나 관련된 미디어를 컨트롤하는 방법에 대한 범위를 결정한다. 일반적으로 SIP를 전달하는 것은 IMS에 해당하여 구체적인 SIP를 컨트롤 하는 부분도 MTSI에 포함하지 않는다. 따라서 데이터의 구조와 전달 방식, 서비스의 정의에 따라 MTSI, IMS의 범위로 결정될 수 있다. MTSI와 같이 정의되는 경우 아래와 같은 범위의 표준으로 정의될 수 있다.
Conversational XR서비스를 지원하기 위해서는 RFC 4566 기반의 SDP와 SDP Capability Negotiation을 사용하고 이와 관련된 Streaming Setup을 사용해야 한다
Setup 및 Control을 위해서는 UE A/B의 독립적인 상호작용이 필요하며 미디어 컴포넌트는 Adding 또는 Dropping작업을 수행한다.
미디어를 전송하는 전송매개체는 Coded Media (Transport Protocol을 적용한)것 뿐만 아니라 Packet기반의 Network Interface를 준수해야 한다.
데이터를 전송하는 방법은 RFC 3550의 RTP Stream을 사용하고 Data Channel은 SCTP (RFC 4960) 또는 WebRTC Data Channel등을 사용할 수 있다.
실시예들에 따른 포인트 클라우드 데이터 송수신 장치는 휴대폰, 데스크톱, AR Glass등 장치구성이 되는 모든 기기들을 포함할 수 있다. 휴대폰이라고 가정하면 speaker, display, user interface, microphone, camera, keyboard가 존재하고 입력된 신호는 인코딩/디코딩 블록으로 전달될 수 있다.
실시예들에 따른 방법/동작은 도17의 비디오 인코더(Video Encod)에 의해 처리될 수 있다. 소프트웨어와 연동될 수 있다.
실시예들에 따른 방법/동작은 G-PCC 구조 콜 플로우(Structure call flow)는 세션 셋업 및 컨트롤(session setup & control) 부분에 포함될 수 있다.
도17의 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응할 수 있다.
IP 연결성(IP Connectivity)
실시예들에 따른 포인트 클라우드 데이터 송수신 장치는 IP 연결을 지원할 수 있다.
멀티미디어 서브시스템(Multimedia Subsystem)의 범위에서 XR 범위는 UMTS (Universal Mobile Telecommunications System) 등의 RAN (Radio Access Network)그리고 SGSN (Serving SPRC Support Node), GGSN (Gateway GPRS Support Note)등의 Visited Network에 존재한다고 가정하며 Roaming서비스등과 IP Connectivity에 대한 시나리오를 고려해야 한다. IP Connectivity를 고려해야 하는 경우 IMS 네트워크에 존재하지 않는 곳에서도 IP서비스를 제공해야 하며 GPRS (General Packet Radio Service) 로밍 역시 홈 네트워크에 연결되어야 한다. IMS기반의 네트워크를 제공하면 IP Connectivity를 유지하기 위해 End-to-End QoS (Quality of Service)를 제공해야만 한다. QoS Requirement는 일반적으로 SIP (Session Initiation Protocol)을 사용하여 세션을 정의하거나 세션을 변경하거나 세션을 종료하며 다음과 같은 정보를 전달할 수 있다: 미디어의 타입, 트래픽의 방향 (상향 또는 하향), 미디어의 비트레이트(Bitrate), 패킷 사이즈(Packet Size), 패킷 트랜스포트 프리퀀시(Packet Transport Frequency), RTP 페이로드(Payload), 밴드위스 어댑테이션(Bandwidth Adaptation).
IP 정책 컨트롤/보안 통신(IP Policy Control/Secure Communication)
실시예들에 따른 포인트 클라우드 데이터 송수신 장치는 IP 정책 컨트롤/보안 통신을 수행할 수 있다.
네고시에이션(Negotiation) 협상은 어플리케이션 레벨(Application Level)에서 수행된다. 만약 UE간의 QoS가 형성되면은 UE 또는 XR을 서비스하고자 하는 주체는 데이터를 압축하고 패킷화하여 적절한 전송 프로토콜 (RTP등)과 같은 프로토콜을 이용하여 TCP 또는 UDP의 Transport Protocol을 IP망을 통해 전달 한다. 또한 IP망을 이용하는 경우 Bearer 트래픽의 조종하고 관리해야 하며 IMS Session내에서 Access Network와 IMS사이에 다음과 같은 업무를 수행할 수 있다.
정책 제어 엘리먼트(Policy Control Element)는 SIP메시지를 통해서 미디어 트래픽에 적합한 Bearer를 활성화 할 수 있고 Operator입장에서는 Bearer 자원을 잘못 사용하지 않게 방지를 한다. 송신과 수신의 IP주소, 대역폭 또한 Bearer Level을 동일하게 조절할 수 있다.
정책 제어 엘리먼트(Policy Control Element)를 이용하여 미디어 트래픽의 시작 또는 중지 지점을 설정할 수 있으며 동기화에 관련된 문제를 해결할 수 있다.
정책 제어 엘리먼트(Policy Control Element)를 이용하여 수신 확인 메시지를 IP네트워크를 통해 전달할 수 있으며 Bearer의 서비스의 수정, 중지, 종료를 수행할 수 있다.
UE의 보안을 위해 Privacy를 요청할 수 있다.
다른 네트워크와 인터넷워킹(서비스 제어)(Internetworking with Other Networks (Service Control))
실시예들에 따른 포인트 클라우드 데이터 송수신 장치는 다른 네트워크와 연계될 수 있다.
3GPP에서 제공하는 IMS서비스는 같은 시간에 유지 관리가 되지 않기 때문에 터미널간, 네트워크 구독 연결 및 및 해지 빠르게 전달되지 않는다. 따라서 어떤 종류의 터미널이라도 IMS망은 다양한 사용자와 네트워크를 최대한 많이 연결할 수 있어야 한다. PSTN 또는 ISDN 뿐 아니라 모바일, 인터넷 유저까지 포함될 수 있다. 현재는 거의 사용하지 않는 2G망의 경우 만약 로밍을 사용 경우 Visited Network에 방문하는 Entity는 Service 및 Control정보를 유저를 위해 제공하여 인터넷 망 내에서 Registration/Session Establishment를 수행한다. 이와 같이 Visited Network에 존재하게 되는 경우 서비스 컨트롤의 제약이 발생하게 되고 다수개의 로밍 모델 시나리오에 따라 고려해야 할 점이 발생하게 된다. 또한 서비스를 제공하게 될 경우 Visited Network의 서비스 속도 등으로 품질이 저하될 수 있다. 중간에 만약 보안 또는 Charging과 같은 역할이 추가된다면 Home Network/Visited Network에 대한 서비스 컨트롤과 수행 방식의 영역에 대하여 고려해야 한다.
플레인 분리(Plane Separation)
3GPP표준은 IMS 망 내에서 Architecture를 Layer화하여 정의하고 있다. 따라서 Transport/Bearer를 구분하여 정의하고 있다. 특히 Application Plane은 일반적으로 Application Server의 범위, Control Plane은 HSS, CSCF, BGCF, MRFC, MRFP, SGW, SEG등 User Plane은 SGSN, GGSN, IM-MGW등으로 영역을 나눌 수 있다.
도18은 실시예들에 따른 5G 네트워크 상 XR 커뮤니케이션을 위한 구조를 나타낸다.
실시예들에 따른 포인트 클라우드 데이터 송수신 장치는 도18과 같이, 통신 네트워크에 기반하여 XR 커뮤니케이션을 효율적으로 수행할 수 있다.
5G네트워크를 이용하여 실시간 포인트 클라우드 양방향 대화는 3가지 방식을 이용하여 달성할 수 있다. 1) IMS 전화망을 이용한 포인트 클라우드의 데이터 교환, 2) 5GMS 미디어 망을 이용한 포인트 클라우드의 데이터 스트리밍, 3) WebRTC를 이용한 웹 기반의 미디어 전송 방식. 따라서 데이터를 전송하기 위해 XR 대화형 서비스 시나리오에 대한 정의가 필요하다. 시나리오는 다양한 형태로 전달될 수 있으며 데이터를 획득하는 과정에서부터 5G망을 이용하는 모든 end-to-end서비스에 대한 과정과 시나리오의 구성으로 나눌 수 있다.
XR Teleconference를 진행하기 위해서는 선행적으로 Application Download가 진행 되어야 한다. 5G망을 이용하여 데이터를 교환하는 경우 내장되어 있거나 또는 다운로드를 받을 수 있는 Application 프로그램이 필요하다. 이 프로그램은 5G로 전송되는 데이터의 전송 타입을 1)전화망 2)미디어 망 3)Web 망을 선택하여 전송할 수 있다. 프로그램이 설치되는 경우 일반적인 디바이스의 접근권한, 그리고 계정 개인정보 권한을 확인하여 데이터를 주고 받을 수 있는 기본 환경을 점검한다. 상대방의 데이터를 수신하기 위한 수신장치 및 송신장치를 포함하는 포인트 클라우드 장비의 캡쳐 장비, 또는 차원 데이터를 3차원으로 변환할 수 있는 변환기 또는 데이터를 3차원으로 360도로 전송 또는 변환이 가능한 모든 비디오 입력 장치를 포함한다. 음성 데이터는 마이크 또는 스피커를 내장하고 있으며 포인트 클라우드 데이터를 최소한으로 처리하기 위한 하드웨어 기능의 점검도 포함한다. 하드웨어는 Pre-Rendering 또는 Post-Rendering을 수행할 수 있는 GPU/CPU의 기능을 포함하며 처리 과정에서 수행되는 하드웨어의 용량, 메모리의 크기까지 포함될 수 있다. 개인 정보는 Application에 접근하기 위한 계정 정보, IP, 쿠키 등의 사용자의 실시간 정보를 부가적으로 전달 할 수 있는 것들을 포함하며 사전에 전송하기 위해 이용 동의를 수행하게 된다.
도19는 실시예들에 따른 XR 커뮤니케이션을 위한 구조를 나타낸다
초기 데이터를 획득할 수 있는 권한과 장치의 상태를 확인하고 난 후 사용자의 인증과 사용자를 구분할 수 있는 구분자를 생성하게 된다. 일반적으로 이메일 또는 아이디와 비밀번호를 이용하여 사용자를 구분하게 되며 인증되는 사용자의 Tag가 자체적으로 형성된다. 또한 초기 사용자가 포인트 클라우드의 데이터를 효과적으로 교환하거나 시스템을 이용할 수 있는 가이드 모드 등이 제공될 수 있다. 사용자의 장치의 상태에 따라 시야를 접근할 수 있는 방식을 결정할 수 있다. 만약 포인트 클라우드를 직접 캡쳐하거나 수신할 수 있는 장치일 경우 데이터를 그대로 송수신 할 수 있으며 만약 HMD를 이용하여 포인트 클라우드를 수신하는 경우 360 환경에 적합한 Scaling 또는 Transformation이 선행되어야 한다. 수신되는 디스플레이가 3차원 데이터를 수신하는 장비가 아닌 일반적으로 널리 사용되는 휴대폰 또는 모니터 기반의 2D디스플레이인 경우 2차원 화면 내에서 3차원을 성실하게 표현할 수 있어야 한다. 예를 들어, 손가락으로 화면을 회전하거나 확대하는 방식을 이용하여 2차원 디스플레이 내에서 3차원의 모습을 구현하거나 확인이 가능하다. 또는 자이로스코프를 이용하여 2차원 화면에서 3차원의 공간을 확인할 수 있는 방법이 있다. 사용자가 3차원 공간에서 표현하기 위해서는 아바타가 생성되어야 한다. 아바타는 Graphic에 의한 가상의 데이터가 될 수 있거나 포인트 클라우드로 직접 획득된 사람 또는 사물의 실체의 3차원 변환 형태가 될 수 있거나, 어떤 데이터도 존재하지 않는 오디오가 될 수 있다. 만약 오디오의 데이터가 입력 된다면 사용자는 존재하지 않으며 마치 음성 회의와 동일한 형태로 구성될 수 있다. 3차원으로 표현되는 아바타는 사용자의 정의 또는 선택에 의해 수정이 가능하다. 예를 들어, 사람의 경우 얼굴의 형태를 변화할 수 있거나 자신의 개성을 나타낼 수 있는 옷, 모자, 악세서리 등을 착용할 수 있으며 자신의 개성을 표현하기 위한 다양한 형태의 변환이 가능하다. 또한 사람간의 대화를 통해 감정을 표현할 수 있으며 감정은 텍스트 또는 그래픽의 얼굴 형태의 변화에 따라 조절이 가능하다.
생성된 아바타는 가상의 공간에 참여하게 된다. 만약 1:1 대화형인 경우 각각의 데이터가 상대방에 전송하게 되지만 상대방이 수신되는 공간 역시 간단하게 형성되어야 한다. 참여자가 다수인 경우 다수인 참여자가 공유할 수 있는 공간이 생성되어야 하며 이러한 공간들은 임의 그래픽으로 구성된 공간이 될 수 있거나 포인트 클라우드로 직접 획득된 데이터 공간이 될 수 있다. 만약 공유되는 데이터의 크기와 상황에 따라 데이터는 각각의 장치에 저장되어 빠르게 처리될 수 있으며, 데이터의 크기가 큰 경우 클라우드 또는 중앙 서버에 저장되어 공유될 수 있다. 사용자의 아바타는 라이브러리 등을 이용하여 사전에 생성된 아바타를 이용할 수 있다. 기본 공통 아바타는 따라서 사용자의 입장에서 새롭게 생성되거나 데이터를 캡쳐하여 전송할 필요가 없다. 마찬가지로 공간에 사용되는 다양한 오브젝트 등은 사용자 요청에 의해 추가될 수 있으며 그 데이터는 그래픽이 될 수 있거나 포인트 클라우드로 획득된 데이터 일 수 있다. 오브젝트는 일반적으로 회의장이라고 가정 하였을 경우 문서, 컵, 레이저 포인터 등의 회의실 내부에서 쉽게 접근이 가능하거나 익숙한 물건이 될 수 있다. 공간이 생성되는 경우 공간에 각각의 아바타로 구성된 사용자가 참여할 수 있으며 사용자는 생성된 공간에 나의 아바타를 이동하여 회의 장소에 참여 가능하다. 공간은 회의를 주체하는 호스트에 의해 결정되며 호스트는 공간을 선택에 의해 변경될 수 있다. 널리 익숙한 회의장을 미리 사전에 획득하면 마치 집에서 회사 회의실에 참여하는 듯한 효과를 얻을 수 있고, 해외 여행 또는 해외 유명 유적지를 획득하면 마치 집에서 그 유적지에서 만나는 듯한 효과를 얻을 수 있다. 또한 포인트 클라우드가 아닌 가상의 임의 그래픽으로 생성된 공간은 사용자의 공간을 만들어 내는 공간 구성자의 아이디어나 구현 방식에 따라 달라질 수 있다. 사용자가 공간에 참여하는 경우 사용자의 프로파일을 형성하여 입장할 수 있다. 사용자의 프로파일은 회의장 또는 공간 참여자의 리스트를 구분하기 위함이고 만약 다수의 사용자가 참여하였을 경우 대화가 가능한지, 사용자의 수신 상태가 올바르게 작동하는지 확인할 수 있다. 그리고 아바타가 존재하는 경우 사용자의 이름 또는 닉네임을 표시해야 하며, 사용자가 현재 바쁜 상태인지 Mute상태인지 표시를 할 수 있어야 한다. 공간의 제약은 호스트 또는 서버를 구성하는 Application의 활용에 따라 달라질 수 있다. 만약 자유로운 공간 이동이 제한되는 환경에서는 사용자는 위치하고 싶은 위치를 이동할 수 있어야 한다. 사용자의 프로파일뿐 아니라 공간의 프로파일도 결정 해야 한다. 회의장에서 만약 다수의 파일을 공유하고 싶을 경우 회의장 내 ppt를 표시할 수 있는 공간이 있어야 하며 마치 가상의 공간에서 프레젠테이션을 보는 효과뿐만 아니라 일반적인 오디오 회의에서 사용하는 것처럼 내가 보는 화면이 자료 공유 화면으로 대체되어 표시될 수 있다. 또한 채팅을 수행하기 위한 채팅의 공간이 마련되어야 하며 사용자가 이동한다면 이동 가능한 범위와 장소에 대한 정의도 요구된다.
도20은 실시예들에 따른 3GPP 5G 상 XR 대화형 서비스를 프로토콜 스택을 나타낸다.
5G XR미디어는 다양한 방식으로 전송될 수 있다. 1) IMS 전화망을 이용한 포인트 클라우드의 데이터 교환, 2) 5GMS 미디어 망을 이용한 포인트 클라우드의 데이터 스트리밍, 3) WebRTC를 이용한 웹 기반의 미디어 전송 방식이 있으면 WebRTC방식은 Application Level에서 두 개의 데이터가 공유된다. 그 외의 IMS와 5GMS는 각각의 전송 프로토콜이 정의되어 있으며 그 규격을 준수하여 송신과 수신을 진행 해야 한다. XR Conversational Service는 기존에 사용하는 2차원 또는 360 Video와 다르게 차원에 대한 정보, QoS를 관찰하기 위한 데이터 파라미터 들이 추가되어 전달되어야 한다. IMS망으로 전달되는 경우 실시간 전화망을 이용하여 데이터를 전달하기 때문에 빠른 데이터 처리와 저 지연 대화 서비스가 가능하다. 하지만 전송 도주에 에러를 복구하는 프로토콜이 존재하지 않기 때문에 지속적인 Feedback 정보에 의존하여 대화를 진행해야 하는 단점이 존재한다. 5GMS로 XR 대화 서비스를 수행할 경우 에러를 수정하고 점 더 대용량의 데이터를 전송할 수 있으나 반대로 오류를 제어하는 과정에서 발생하는 지연 현상이 발생할 수 있다. 현재 5G시스템에서는 두 가지 모두 기술적으로 적용 가능하며 어떤 것을 사용하는 것은 서비스를 구현하고자 하는 환경과 상황에 맞추어 달라질 수 있다.
MTSI기반 XR 대화형 회의의 유즈 케이스(Description of Use-case of MTSI-based XR Conversational Conference)
포인트 클라우드 기반 실시간 양방향 화상 대화는 단일 전화와 같이 1:1 대화 전송, 다수의 화상 회의 참여 형태로 구분할 수 있다. 하지만 두 개의 시나리오 모두 직접적으로 데이터를 전달하는 것이 아닌 미디어를 처리하는 처리기가 요구되며 가상의 회의를 할 수 있는 환경에 제공되어야 한다.
도21은 실시예들에 따른 포인트-투-포인트 XR 화상회의를 나타낸다.
포인트-투-포인트 XR 화상회의(Point to Point XR Teleconference)
대화의 기본 전화 요청은 네트워크 기능에 의해 진행되며 MTSI망을 사용하는 경우 송수신 미디어는 MRF (Media Source Function) 또는 MCU (Media Control Unit)을 이용한다. 여기서 MRF/MCU는 포인트 클라우드 압축 데이터를 수신하며 송신자가 압축 데이터 이외에 부가 정보 (시야의 화면, 카메라 정보, 시야의 방향 등)를 전송하고자 하는 경우 역시 그 데이터를 MRF/MCU에 전달한다. MRF 다수의 송신자로부터 다른 포인트 클라우드 데이터를 획득하고 난 후 내부 프로세스를 통해 하나의 비디오를 생성하며 하나의 비디오는 메인 비디오와 여러 개의 썸네일을 포함한다. 처리된 비디오는 다시 각각의 수신자에게 전달되며 Transcoding 및 Resize와 같은 처리가 발생할 수 있다. 만약 MRF가 Transcoding과 같은 프로세스를 필요로 하는 경우 처리 시간만큼의 최대 지연 시간 증가 영향을 끼질 수 있다. 또한 썸네일 데이터를 사전에 각각의 송신기 및 수신자에게 전송하여 사전처리 프로세스를 수행할 수 있다. MRF에서는 미디어의 처리 이외에 오디오 및 미디어 분석, Application Server, 과금 서버 연동, 리소스 관리 기능을 수행한다. MRF와 연결되는 AS (Application Server)는 전화 망에서 가입자의 상태 조회를 위한 HSS 연동 기능을 포함하며 MRF연결 및 부가기능을 제공한다. 부가기능은 실제 전화에서 비밀번호 통화 서비스, 레터링서비스, 통화 연결음 서비스, 착발신 금지 서비스 등을 포함한다.
일대일 포인트 클라우드의 대화 서비스는 각각의 사용자가 3차원 포인트 클라우드 캡쳐 카메라를 가지고 있어야 한다. 카메라는 사용자의 색상정보, 위치정보, 깊이정보를 포함하고 있어야 하며 깊이를 표현하지 못하는 경우 2차원 이미지를 3차원으로 표현될 수 있는 변환기를 사용할 수 있다. 사용된 캡쳐 정보는 G-PCC (Geometry-based Point Cloud Compression) 또는 V-PCC (Video-based Point Cloud Compression)된 데이터를 포함한다. 송신기는 상대방의 데이터를 수신할 수 있는 장비를 가지고 있어야 한다. 수신 장비는 일반적으로 획득된 포인트 클라우드의 데이터를 표현할 수 있는 모든 장비를 나타난대. 따라서 2차원 기반의 디스플레이가 될 수 있으며 HMD, 홀로그래픽과 같이 포인트 클라우드의 그래픽을 시각적으로 표현할 수 있는 모든 장비를 포함할 수 있다. 표현되는 데이터는 송신과 수신기의 데이터가 처리된 MRF/MCU에서 전달되는 데이터를 수신하고 수신된 데이터를 처리할 수 있어야 한다. 캡쳐된 포인트 클라우드 데이터는 MRF/MCU에 전달되고 수신된 데이터는 내부 프로세스에 의해 각각의 유저에게 데이터를 전달할 것을 생성하고 전달한다. 대화에 필요한 대화의 기본 정보, 대화가 요구되는 대화의 가상 공간 또는 상대방이 원하는 관점의 시야 정보를 전달하거나 압축된 데이터를 전달한다.
1. 보니(Bonnie) (B)와 클라이드(Clyde) (C)는 Conference call을 이용하여 접근을 한다. 접근은 평면 또는 단순한 가상의 공간에 상대방의 얼굴을 볼 수 있으며 가상의 공간 A는 B와 C가 도착한 곳에서 서로의 얼굴을 볼 수 있도록 한다.
일대일 대화에서 가상의 공간은 단순히 포인트 클라우드를 투영하여 단순화 하는 공간으로만 활용되며 투영하는 공간을 사용하지 않을 경우 단순히 카메라로 캡쳐 되는 모든 데이터가 상대방에게 전송된다.
2. B와 C는 화상회의를 운용하기 위한 Application을 필요로 한다. 해당 Application은 다음과 같은 기본 서비스 동작을 확인한다.
수신장치 확인: AR Glass, VR HMD, 2D Display, Phone Speaker, etc.
송신장치 확인: AR Glass, 360 Camera, Fisheye Camera, Phone Camera, Mic, Kinnect, LiDAR, etc.
하드웨어 성능 확인: GPU, CPU, Memory, Storage Capability
접근 권한 확인: 카메라, 오디오, 저장공간
계정 및 개인정보 권한 확인: 아이디, 이메일 계정, IP, Cookie, 개인정부 추적 동의
3. B와 C는 대화에 참여하기 이전에 포인트 클라우드 캡쳐 카메라를 이용하여 상대방에게 전송하기 위한 포인트 데이터를 획득한다. 포인트 데이터는 일반적으로 B와 C의 얼굴 또는 형체를 획득한 데이터며 각각의 고유의 장비를 통해 획득된 데이터를 출력할 수 있다.
위 시나리오는 어떤 미디어를 알고 있지 않은 환경에서 단순 전화망을 기반으로 전송 전달 구현이 가능하다. 전화망을 생성하기 전에 사전 데이터는 MRF/MCU를 통해 전달받아야 할 것이며 MRF/MCU는 B와 C로부터 전송 받는 데이터를 모두 수신한다.
두 명의 사람이 포인트 클라우드의 화상 대화 시나리오는 아래와 같이 두 가지로 구분화 된다.
시나리오 (a)의 경우 모든 데이터는 일대일 대화로 전송이 된다. B의 모든 포인트 클라우드 정보가 C에게 직접적으로 전달이 되고 C는 B의 데이터의 전부를 처리하거나 B에서 전달하는 부가 정보를 기반으로 일부 처리할 수 있다. 마찬가지로 B는 C에서 전송하는 모든 포인트 클라우드의 데이터를 수신해야 하며 C에서 전달하는 부가 정보를 기반으로 일부를 처리할 수 있다. 시나리오 (b)의 경우는 MRF/MCU가 전화망 사이에 존재하며 B와 C는 포인트 클라우드 데이터를 두 사이에 존재하는 MRF/MCU에 전달을 한다. MRF/MCU는 수신되는 데이터를 처리하며 B와 C요구하는 특정 조건에 맞추어 각각에 해당하는 데이터를 B와 C에 전달한다. 따라서 B와 C는 서로에게 전송하는 포인트 클라우드의 모든 데이터를 받지 않을 수 있다. 시나리오 (b)의 경우 다자간 화상 회의 기능도 확장될 수 있으며 추가적인 가상의 공간 A가 포함되어 B또는 C에게 전달될 수 있다. 예를 들어, 직접적 포인트 클라우드 수신이 아닌 가상의 회의 공간 내 B와 C를 배치하여 배치된 가상의 공간 전체를 B와 C에게 3인칭 또는 1인칭의 형태로 전송할 수 있다. 또한 David (D)가 참여하여 B, C, D는 A의 공간에서 서로의 대화를 자유롭게 진행할 수도 있다.
도22는 실시예들에 따른 XR 화상회의 확장을 나타낸다.
3인 이상의 가상 회의 시스템은 두 사람의 대화와는 반대로 직접적인 데이터 전송은 할 수 없게 된다. 대신 MRF/MCU는 각각의 데이터를 수신하여 하나의 데이터를 처리할 수 있으며 그 도식도는 도22와 같이 표현된다.
B와 C, D는 획득된 포인트 클라우드의 데이터를 MRF/MCU로 전달을 한다. 수신된 각각의 데이터는 Transcoding에의해 하나의 Unit Frame을 형성하고 집합화된 포인트의 데이터를 구성할 수 있는 Scene을 생성한다. Scene의 구성은 B, C, D중 호스팅을 요청한 사람에게 주어지며 일반적으로 다양한 Scene을 형성하여 포인트 공간을 생성할 수 있다. 사용자의 위치 또는 관찰하고자 하는 위치에 따라 모든 데이터가 전달될 필요는 없으며 MRF/MCU는 수신되는 데이터 정보와 B, C, D가 요청하는 카메라 Viewpoint, Viewport를 기준으로 전체 또는 일부의 포인트 클라우드 데이터를 전달할 수 있다.
도23은 실시예들에 따른 XR 화상회의 확장을 나타낸다.
두번째로 Host의 권한을 가진 B는 자신의 데이터 또는 화면을 회의 참여자에게 공유할 수 있다. 공유할 수 있는 데이터는 Overlay형태, 독립적인 화면, 데이터등의 제 3자에게 화상의 대화 이외에 전달 가능한 미디어를 포함한다. 만약 Sharing기능을 사용하게 된다면 B는 공유하고자 하는 데이터를 MRF/MCU에 전달을 하며 C와 D는 자신의 요청에 의해 공유 받는 데이터를 수신할 수 있다. 데이터를 공유하기 위해서는 SDP를 이용하여 Overlay 또는 Laying의 개수를 결정할 수 있으며 Offer/Answer과정에서 모든 데이터를 수신할 수 있는지, 그리고 전달하고자 하는 데이터를 모두 수신받을 수 있는지에 대한 Capability를 측정해야만 한다. 이 과정은 다수의 회의 참여 시작에 결정될 수 있으며 자료 공유 기능이 기본적으로 제공되어야만 할 때 전화망이 생성할 때 각각의 유저에 대한 데이터 처리 능력을 확인할 수 있다. Sharing 데이터는 일반적으로 프레젠테이션 파일, 엑셀 파일, 데스크톱의 화면 등으로 대화 중에서 Host에서 작동 중인 Application의 일부 또는 전체의 스크린을 공유하기 위해 생성된다. 생성된 데이터는 압축 또는 해상도가 전환되어 수신되고자 하는 유저에게 전달된다.
실시예들에 따르면, 본 문서는 전술한 바와 같이 실시간 및 양방향으로 사용자의 얼굴을 3차원으로 획득하고 가상의 환경에서 대화를 할 수 있는 실감형 가상 대화 및 회의 시스템의 효율적인 사람 눈을 추적하고 인식하는 방법을 기술한다. 이때, 사용자간 대화를 구현하기 위해서 다수개의 사람을 인식할 수 있는 카메라 필드 그리고 물리적으로 사용자의 형태 또는 얼굴을 획득할 수 있는 포인트 카메라, 색상 카메라, 그리고 깊이를 표현할 수 있는 카메라를 사용한다. 사람을 인식할 수 있는 환경에서 사람 또는 사물의 오브젝트를 인식하고 분류하는 방식이 중요하게 여겨진다. 대부분 3차원 기술 방식은 라이다 (LiDAR)를 이용한 센서 인식 방식을 사용하고 있으며 특히, 실시간으로 획득되는 포인트 클라우드 데이터를 동물, 사람, 자동차 등의 사물로 인식하는 방식으로 사용하고 있다.
그리고, 실시간 포인트 클라우드의 대화형 서비스를 달성하기 위해서는 서비스 망이 전제 되어야 한다. 서비스 망은 인터넷 또는 무선 망에 접속하여 양방향 사용자의 정보를 전달하고 초기 데이터를 획득한다. 획득된 데이터는 어떤 사용자인지, 사용자가 어떤 서비스를 원하는지 전반적인 정보를 획득하는 것을 모두 포함한다. 실시간 포인트 클라우드는 서비스를 획득하기 위해서 기존에 전달하고자 하는 망을 사용하여 서비스를 수행할 수 있다. 하지만 그 서비스는 단순히 서비스를 작동화 하는 것이 아닌 각 연결점에 대하여 서비스를 구현하기 위한 룰을 세부적으로 추가해야 한다. 그 규칙은 일정하게 정해져야 하며 단순히 기존 시스템의 방식을 그대로 사용하여 활용할 수는 없다.
즉, 5G 망을 이용하여 실시간 포인트 클라우드 데이터를 전송하기 위해서는 기존에 사용하는 전화망을 활용한다. 이때, 전화망은 일반적으로 대화의 목소리를 기준으로 전송을 하게 되어 있으며 대화의 목소리를 기본으로 하기 때문에 도 24 또는 도 25에서와 같이 전송하고자 하는 목소리의 교정이나 에러를 보호할 수 있는 방법을 제시하고 있지 않다. 특히, 최근 VR등과 같은 고용량 및 고화질 미디어를 전화망으로 전송하기 위한 논의가 되고 있으나 기존의 방식을 그대로 확장하여 사용하기는 어려움이 존재한다.
도 24는 1:1 대화 형성을 위해 기본 전화망을 생성하는 과정의 일 예시를 도시한 흐름도이다.
실시예들에 따라, 사용자 단말(User Equipment, UE)은 무선 접속 기술(예, 5G NR(New RAT), LTE(Long Term Evolution))을 이용하여, 기지국 및/또는 다른 사용자 단말과 통신을 수행하는 기기(예, 스마트 폰)를 의미한다.
그리고 설명의 편의를 위해, 사용자 단말(UE B)의 사용자를 유저 B라 칭하고, 사용자 단말(UE C)의 사용자를 유저 C라 칭하기로 한다. 또한, SDP(Session Description Protocol)는 단말 간의 멀티미디어 세션과 관련된 미디어 타입 및 포맷을 협상하는 프로토콜이며, 제안(offer)과 수락(answer) 모델로 동작한다.
도 24에서, UE B와 UE C 가 미디어 기반 전화를 생성하기 위해서는 기본적인 5가지 전송 과정을 수행한다.
즉, UE B는 UE C가 해당 기능을 수행할 수 있는지에 대해 알기 위해 UE C로 SDP offer 메시지를 전송한다(S50001). 전송되는 SDP offer 메시지(또는 SDP offer의 정보)는 비디오 코덱의 지원 가능 여부 또는 오디오 파라미터를 지원할 수 있는지에 대한 기본적인 내용이 포함된다.
UE C는 UE B와의 연결을 위해서 SDP offer 메시지를 파악하고 실제로 가능한 내용에 대하여 동일 또는 가능한 파라미터를 결정하고 그것을 포함하는 SDP answer 메시지를 UE B에 전달한다(S50002). 만약 이 과정에서 SDP offer와 SDP answer의 내용이 상이하지 않다면 전화망은 형성된다.
그리고, UE C는 UE B에게 미디어(예, XR 데이터)를 전송하기 위해서 전화망이 형성된 경로(flow)로 미디어를 RTP (Real Time Transport Protocol) 패킷화하여 전송한다(S50003). 이때, RTP 전송에 사용될 비디오 코덱은 일반적으로 AVC, HEVC등이 있다.
또한, RTP 패킷을 통해 전송되는 데이터는 RTCP (Real Time Transport Control Protocol)를 기반으로 선택적으로 (optional) 피드백 신호를 수신 받을 수 있다(S50004). 여기서, 피드백 신호는 정해진 주기에 의해 UE B가 UE C에게 지속적으로 전달해주는 파라미터를 말한다.
만약 단계 S50004, 즉 피드백 과정이 포함되는 경우 피드백 파라미터를 기반으로 다시 UE C는 UE B에게 미디어를 전달할 수 있다(S50005). 이때 재전송 되는 미디어는 기존의 전송하고자 하는 미디어에서 각각의 네트워크 망 또는 UE B에 적합하게 어느 정도 수정되어 최적화된 미디어일 수 있다.
도 25는 1:1 대화 형성을 위해 기본 전화망을 생성하는 과정의 다른 예시를 도시한 흐름도이다.
도 25는 MRF/MCU 등의 중계 기능이 포함되는 경우 서비스 망을 형성하기 위한 예시이다. 즉, 대화의 기본 전화 요청은 네트워크 기능에 의해 진행되며 MTSI망을 사용하는 경우 송수신 미디어는 MRF (Media Source Function) 또는 MCU (Media Control Unit)을 이용한다.
즉, UE B는 UE C에게 SDP offer메시지를 전달하지만 중간의 데이터는 IMS 망(즉, 전화망) 내에 존재하는 MCU/MRF를 거치게 된다. 다시 말해, UE B에서 제공하는 SDP offer 메시지는 MCU/MRF로 전달된다(S50011).
그리고, MCU/MRF는 수신된 SDP offer메시지를 그대로 UE C에게 전달한다(S50012).
UE C는 UE B와의 연결을 위해서 SDP offer 메시지를 파악하고 실제로 가능한 내용에 대하여 동일 또는 가능한 파라미터를 결정하고 그것을 포함하는 SDP answer 메시지를 MCU/MRF에 전달한다(S50013). UE C에서 회신하는 SDP answer메시지는 1:1 대화와 동일하게UE B와 UE C 사이에 발생하는 메시지이다.
MCU/MRF는 수신된 SDP answer 메시지를 그대로 UE B에게 전달한다(S50014). MCU/MRF는 수신되는 SDP offer 메시지/SDP answer 메시지를 통해 UE간에 전화망이 형성됨을 사전에 획득할 수 있으며, 사전 획득된 정보를 기반으로 중간에 데이터 서비스를 준비 한다.
그리고 위의 과정에서 SDP offer와 SDP answer의 내용이 상이하지 않다면 UE B와 UE C 사이에 전화망이 형성된다.
UE C는 미디어를 RTP 패킷화한 후 RTP 미디어 경로(flow)를 통해 MCU/MRF로 전송한다(S50015). MCU/MRF는 수신된 RTP 패킷을 그대로 RTP 미디어 경로(flow)를 통해 UE B로 전달한다(S50016).
또한, RTP패킷을 통해 전송되는 데이터는 RTCP를 기반으로 선택적으로 (optional) 피드백 신호를 수신 받을 수 있다(S50017). 여기서, 피드백 신호는 정해진 주기에 의해 UE B가 MCU/MRF에게 지속적으로 전달해주는 파라미터를 말한다.
만약 단계 S50017, 즉 RTCP 피드백을 수행하는 경우, UE B는 MRF/MCU에 피드백 정보를 송신한다. 송신된 피드백 정보는 MRF/MCU내에서 처리되며, 또한, MRF/MCU는 UE C로부터 받은 데이터(즉, 미디어)를 처리한다. 그리고, 처리된 미디어는 RTP 패킷 형태로 UE B로 전달된다(S50018). 이때 재전송 되는 미디어는 기존의 전송하고자 하는 미디어에서 각각의 네트워크 망 또는 UE B에 적합하게 어느 정도 수정되어 최적화된 미디어일 수 있다.
도 24 또는 도 25에서와 같이, 기존 IMS망 전달 형태는 미디어 전송을 위해 SDP 협상 메시지를 생성하여 전달한다. 하지만 기존 방식은 포인트 클라우드와 같은 고용량 미디어를 전송하기 위한 미디어 프로세스에는 적합하지 않다. 즉, 일대일 통신 같은 경우는 포인트 클라우드 데이터를 전송할 수 있으나 전화망에서 발생하는 고용량 데이터를 처리할 수 있는 처리에 대한 방법이 존재하지 않고, 또한 다수간의 유저가 포인트 클라우드 형태의 화상 회의를 할 경우 그 내용을 전달하고 처리하고자 하는 방법은 기존 방법으로 해결을 할 수 없다. 또한 고용량의 포인트 클라우드 데이터는 단일 IMS망으로 전달하는데 내부 장비의 기능이 모든 것을 수행 할 수 없다. 마지막으로 위의 기능으로는 포인트 클라우드의 데이터를 세부적인 IMS망으로 직접적인 송수신 역할에 대한 정의가 되어 있지 않다.
다음은 이러한 문제점을 해결하기 위해, 기존 망에서 포인트 클라우드 기반 대화형 서비스를 진행하기 위한 서비스 등록과 기초 데이터 교환에 대한 연결 플로우, 그리고 서비스 등록 과정에 대하여 설명한다.
본 문서는 3GPP TS 26.114의 MTSI 의 VR (Virtual Reality) 및 TR26.928의 XR (Extended Reality) 포함하며 IMS기반의 Telepresence를 논의하는 3GPP TS26.223 표준을 포함한다. 해당 표준을 통해 이동형 또는 분리형 수신기는 가상 회의에 참석하여 실감형 회의에 참여할 수 있게 된다. 대화형 데이터가 미디어 포멧으로 전달될 수 있는 경우 본 문서는 5G Media Architecture 3GPP TS26.501, TS26.512, TS26.511을 포함한다. 부가적으로 서비스의 구체화를 위해 관련 표준은 TS26.238, TS26.939, TS24.229, TS26.295, TS26.929, TS26.247이 포함될 수 있다.
도 26은 실시예들에 따른 IM subsystem의 구체적인 블록도를 나타낸 도면이다. 도 26에서, 굵은 선은 IP 멀티미디어 네트워크에 전달되는 트래픽을 나타내고 점선은 시그널링과 관련된 인터페이스가 전달되는 부분을 나타낸다. 멀티미디어는 IMS 또는 Non-IMS망 모두 상호 호환적으로 작동할 수 있으며 본 문서에서는 오직 IMS망의 경우만 다룬다.
도 26에서, IMS 주요 기능은 Call State Control Function (CSCF)로 SIP를 사용하여 멀티미디어 세션을 관리하는 것이다. 각각의 CSCF는 서버 또는 Proxy역할을 수행하며 각각의 목적에 따라 다른 형태의 기능을 수행한다.
Proxy CSCF (P-CSCF)는 SIP Proxy 서버 역할을 수행한다. P-CSCF는 모든 SIP 메시지를 수신하고 송신하고자 하는 UE까지 전달하기 위해서 내부적으로 SIP 메시지를 분석하고 전달하는 역할을 수행한다. P-CSCF는 자원관리를 수행할 수 있으며 네트워크의 Gateway와 밀접하게 연결되어 있다.
HSS는 중앙 데이터 서버로 유저와 관련된 정보를 포함한다. Multimedia Resource Function (MRF)는 홈 네트워크에서 멀티미디어 자원을 포함한다. MRF는 Multimedia Resource Function Controller (MRFC)와 Multimedia Resource Function Processor (MRFP)로 구성된다. MRFC는 MRC의 컨트롤 플레인으로 MRFP내에서 스트림 리소스를 관리하는 컨트롤 역할을 수행한다.
Breakout Gateway Control Function (BGCF)는 SIP서버로 Public-Switched Telephone Network (PSTN) 또는 Communication Server (CS)와 연결되어 SIP메시지를 전달하는 게이트웨이를 나타낸다.
IM-MGW는 미디어를 CS네트워크로 전달하기 위한 인터페이스와 시그널링을 전달하는 역할을 한다.
BGCF, MRF 에서는 일반적으로 알려진 비디오 코덱 H.264, H.265, VP8/9등의 트랜스코드(Transcode)하는 기능이 포함되어 있으며 MRF는 모든 네트워크와 어플리케이션을 통합하여 특징들을 전달하는 주요한 수행한다. MRF는 일반적으로 독립된 미디어에게 요구되는 미디어 처리 (Media Processing)부를 하나로 제어하여 다수개의 서비스, 미디어, 컨트롤 프로토콜, 코덱, 플랫폼을 제어할 수 있다.
실시예들에 따르면, 대용량 미디어 처리를 위한 전화망은 MRF를 이용하는 방법, MRF를 이용하지 않고 UE에서 클라우드 프로세스를 적용하는 방법이 있으며 그 방법에 대한 신호 전달 체계는 아래에서 설명하기로 한다.
즉, UE에서는 클라우드 서비스를 활성화 하기 위하여 내부적으로 IMS망이 아닌 클라우드 서비스에 접속한다.
그리고, 활성화된 클라우드 서비스는 2가지 방식의 사용이 가능하다. 하나의 방법은 내부 데이터 처리 방법이고, 다른 하나의 방법은 외부 데이터 처리 방법이다. 즉, 포인트 클라우드 데이터의 대용량 전송 및 수신은 MTSI에 맡겨지고 실시간으로 획득되는 데이터는 클라우드에서 처리한다. 그리고, UE에서 구동되기 위하여 SDP 협상 과정에서 클라우드에 접속해야 하며 서비스 등록 과정은 도 27 또는 도 28과 같이 진행된다. 즉, 도 27과 도 28은 UE 간에 포인트 클라우드 데이터(예를 들어, G-PCC 데이터 또는 V-PCC 데이터)를 송/수신을 위한 세션 플로우를 정의한다. 다시 말해, 도 27과 도 28은 UE B와 UE C 사이에 1:1 대화를 할 때 에지 인에이블러를 이용하여 discovery request(요청)을 하고 받는 것에 대한 절차(procedure)를 결정하는 것이다. 상기 인에이블러를 구성하는 에지 인에이블러 클라이언트와 에지 인에이블러 서버는 분산 처리를 할 때 사용되는 기능의 블록이다. 본 문서는 이 기능을 이용하여 UE B와 UE C가 1:1 XR 통신을 하도록 하는데 있다. 특히, UE B와 UE C가 서로 디코딩 능력이 없을 때(예를 들어, 2G 폰과 같이 성능이 낮은 폰), 상기 에지 인에이블러가 대신 처리할 수 있다. 그래서, 컴퓨터가 별로 좋지 않더라도 고용량 컴퓨팅을 대신할 수 있다.
MTSI는 IMS기반에서 Conversational Speech, Video, Text를 RTP/RTCP를 통해 전송하기 위한 표준이며 Flexible Data Channel Handling을 통해 사용자가 기존 Circuit Switched (CS)기반 Conversational Service 대비 동일 또는 고 효율 서비스를 제공하기 위해 제정되었다. MTSI는 Signalling, Transport, Jitter Buffer, Management, Packet-Loss Handling, Adaptation 뿐 아니라 Adding/Dropping Media During Call등의 포함되어 예측 가능한 미디어를 생성하고 전달하고 수신할 수 있도록 형성되어 있다. MTSI는 3GPP 망을 사용하기 때문에, NR, LTE, HSPA 등이 IMS에 연결되어 있으며 Wi-Fi, Bluetooth등과도 확장되어 연결된다. MTSI는 기존 IMS망에 데이터 협상 메시지를 송신 및 수신하게 되며 송수신이 완료되면 데이터는 유저간 전달되는 구조를 가지고 있다. 그러므로 IMS망을 동일하게 이용할 수 있으며 MTSI는 Audio Encoder/Decoder, Video Encoder/Decoder, Text, Session Setup and Control, Data Channel만을 추가적으로 정의 한다.
도 27은 실시예들에 따른 서비스 등록 과정의 일 예시를 도시한 흐름도이다. 서비스 등록 과정을 수행하기 위해, 시스템은 적어도 복수의 사용자 단말(UE)들, 에지 인에이블러 클라이언트(EdgeEnabler Clent), 에지 인에이블러 서버(EdgeEnabler Server)를 포함할 수 있다. 본 문서는 에지 인에이블러 클라이언트(EdgeEnabler Clent)를 에지 인에블러라 칭하기도 하고, 에지 인에이블러 클라이언트와 에지 인에이블러 서버를 포함하여 에지 인에이블러라 칭한다.
도 27에서는 UE B의 요청에 따라 UE B와 UE C가 전화망을 형성한다고 가정한다. UE B와 UE C는 전화망을 형성하기 전에 클라우드 서비스 초기화 과정을 수행한다.
즉, UE B는 UE C와 전화망을 형성하기 전에 트리거 조건(Trigger Condition)을 고려한다. 이 경우, Edge enabler존재, PDU session의 형성, 지리적 위치의 정보, 주기적인 타이밍 검사 등을 수행한다. 만약 클라우드 서비스가 가용이 가능하다면, UE B는 자신 즉, UE B에 가장 가까운 에지 인에이블러 클라이언트(Edge Enabler Client)에게 어플리케이션을 이용하여 디스커버리(Discovery) 요청을 수행한다(S50021). Discovery 수행은 사용하고자 하는 목적에 따라 데이터 연산 처리, 렌더링(Rendering) 등의 목적으로 쿼리 값을 포함하며, 전송하고자 하는 값은 어플리케이션의 태그, 위치 등에 포함된다
인에이블러(Enabler)는 Edge Enabler Client가 Edge Enabler Server에 전송하는 값의 권한에 대한 확인을 진행 할 수 있다. 수신되는 요청 값이 전송하고자 하는 요구사항에 적합한 경우 다음 단계로 진행이 가능하다. 즉, 적합성이 확인된 경우 IP주소 등의 정보를 추적하고, 위치하고 있는 Edge Data Network와 연결되어 있는지와 같은 Edge Enabler Server 관련 정보를 포함하여 Discovery 응답(Response)를 수행한다(S50022).
UE B는 Edge Enabler Server의 가용 특징을 획득하고 난 후, 요구 사항에 적합한 파라미터와 Edge 가능성, 그리고 가용 능력을 포함하여 SDP offer메시지를 삽입하고 UE C에게 전달한다. 만약 Discovery가 획득되는 경우 UE B에서 제공하는 SDP offer메시지는 Edge Enabler Server로 전달되며(S50023), Edge Enabler 서버는 수신되는 SDP offer메시지를 UE C로 전달한다(S50024).
실시예들에 따르면, UE C가 에지 컴퓨팅(Edge Computing)을 사용하고자 하는 경우, UE C는 자신 즉, UE C에 존재하는 에지 인에블러를 이용하여 Service Discovery 과정을 수행한다. 즉, UE C는 자신 즉, UE C에 가장 가까운 에지 인에이블러 클라이언트(Edge Enabler Client)에게 어플리케이션을 이용하여 디스커버리(Discovery) 요청을 수행한다(S50025). 에지 컴퓨팅은 사용자 또는 데이터 소스의 물리적인 위치나 그 근처에서 컴퓨팅을 수행하는 것을 말한다. 사용자의 단말 장치와 가까운 위치에서 컴퓨팅 서비스를 처리하면 사용자는 더 빠르고 안정적인 서비스를 제공받게 되며 기업은 유연한 하이브리드 클라우드 컴퓨팅의 이점을 얻을 수 있다. 에지 컴퓨팅은 기업이 여러 위치에서 공통의 리소스 풀을 사용하여 데이터 연산 및 처리를 분산시키는 방법 중 하나이다. 다시 말해, 에지 컴퓨팅은 클라우드에서 실행하는 프로세스를 줄이고 해당 프로세스를 사용자의 컴퓨터, IoT 장치, 에지 서버 등의 로컬 위치로 이동하는 것이다. 컴퓨팅을 네트워크의 에지로 가져오면, 클라이언트와 서버 사이에 필요한 장거리 통신의 양이 최소화된다. 본 문서는 에지 인에이블러 서버와 에지 인에이블러 클라이언트를 전화망에서 사용할 수 있도록 한다.
실시예들에 따르면, 사용자(즉, UE)의 위치에 따라 UE B와 UE C는 다른 Edge Enabler 클라이언트와 Edge Enabler 서버를 가질 수 있다. 도 27에서는 이해를 위하여 하나의 Edge Enabler 클라이언트와 Edge Enabler 서버가 존재한다고 가정한다.
Edge Enabler 서버는 UE C로부터 수신된 Edge Enabler의 Discovery 요청에 대한 Discovery 응답을 UE C에게 전달한다(S50026).
그러면, UE C는 단계 S50024에서 수신된 SDP Offer 메시지에 대한 응답으로 적절한 파라미터 또는 가능한 파라미터를 조절하고, 이 파라미터를 포함하는 SDP Answer메시지를 UE B에게 전달한다. 만일, 에지 컴퓨팅을 사용하고자 하며 그 값이 획득되는 경우, UE C는 SDP Answer 메시지를 Edge Enabler 서버로 전달하고, Edge Enabler 서버는 수신되는 SDP Answer 메시지를 그대로 UE B로 전달한다(S50028).
UE C는 전달하고자 하는 미디어를 RTP 패킷화한 후 RTP 미디어 경로(flow)를 통해 Edge Enabler 서버로 전송한다(S50029). Edge Enabler 서버는 수신된 RTP 패킷을 그대로 RTP 미디어 경로(flow)를 통해 UE B로 전달한다(S50030). 여기서, RTP 미디어 경로를 통해 전송될 3GPP 표준에서 사용되는 비디오 코덱은 일반적으로 AVC, HEVC등이 사용된다. 실시예들에 따르면, Edge Enabler 서버는 RTP 패킷 형태로 UE C로부터 수신된 미디어를 처리할지 안 할지 결정할 수 있다. Edge Enabler 서버를 이용하여 Split Rendering등의 부가 프로세스가 수행되면, 이 부가 프로세스가 수행되고 난 RTP 패킷은 UE B로 전달된다.
또한, RTP패킷을 통해 전송되는 데이터는 RTCP를 기반으로 선택적으로 (optional) 피드백 신호를 수신 받을 수 있다(S50031). 여기서, 피드백 신호는 정해진 주기에 의해 UE B가 MCU/MRF에게 지속적으로 전달해주는 파라미터를 말한다.
만약 단계 S50031, 즉 RTCP 피드백을 수행하는 경우, UE B는 Edge Enabler 서버에 피드백 정보를 송신한다. 송신된 피드백 정보는 Edge Enabler 서버 내에서 처리되며, 또한, Edge Enabler 서버는 UE C로부터 받은 데이터(즉, 미디어)를 처리한다(S50032). 즉, 피드백 과정이 포함되는 경우 피드백 파라미터를 기반으로 다시 UE C는 UE B에게 미디어 전달이 가능하다. 이때 재전송 되는 미디어는 기존의 전송하고자 하는 미디어에서 각각의 네트워크 망 또는 UE B에 적합하게 어느 정도 수정되어 최적화된 미디어일 수 있다.
도 27에서, S50021 내지 S50026을 클라우드 서비스 초기화 과정이라 칭한다. 클라우드 서비스 초기화 과정은 위 스텝들 중 일부 스텝이 생략될 수도 있고, 또는 일부 스텝이 더 포함될 수도 있다.
다른 실시예로, Edge Enabler 클라이언트는 Edge Enabler 서버를 거치지 않고 데이터 네트워크에 직접적으로 Configuration Provisioning Request를 송신할 수 있다.
도 28은 실시예들에 따른 서비스 등록 과정의 다른 예시를 도시한 흐름도이다. 서비스 등록 과정을 수행하기 위해, 시스템은 적어도 복수의 사용자 단말(UE)들, MCU/MRF, 에지 인에이블러 클라이언트(EdgeEnabler Clent), 에지 인에이블러 서버(EdgeEnabler Server)를 포함할 수 있다.
도 28에서는 UE B의 요청에 따라 UE B와 UE C가 전화망을 형성한다고 가정한다. UE B와 UE C는 전화망을 형성하기 전에 클라우드 서비스 초기화 과정을 수행한다.
먼저, UE B는 SDP offer 메시지를 MCU/MRF로 전달한다(S50041). MCU/MRF는 전달되는 SDP offer 메시지의 프로파일에 따라 클라우드 기능을 활용할지 안할지 결정한다.
MCU/MRF는 데이터 전송 용량 및 프로파일에 따라 클라우드 서비스를 사용하겠다고 결정하면, 망 내에 존재하는 Edge Enabler 클라이언트에게 Discovery 요청을 수행한다(S50042). 그러면, Edge Enabler 클라이언트는 망 내 접속되어 있는 Edge Enabler 서버에 Discovery Request를 전달한다(S50043).
이 경우, Edge Enabler 클라이언트와 Edge Enabler 서버 사이에 응답된 Discovery Response값은 Edge Enabler 클라이언트를 거쳐 MCU/MRF에게 전달된다. 즉, Edge Enabler 서버는 Discovery Request에 대한 Discovery Response를 생성하여 Edge Enabler 클라이언트로 전달하고(S50044), Edge Enabler 클라이언트는 수신된 Discovery Response를 그대로 MCU/MRF로 전달한다(S50045).
만약 수신된 Discovery Response의 값이 변동이 있거나 클라우드에 재협상이 필요하다면 SDP offer값은 변경 될 수 있다.
MCU/MRF는 클라우드 서비스에 대한 결정이 확정 되면, SDP offer메시지를 UE C로 전달한다(S50046).
그러면, UE C는 단계 S50046에서 수신된 SDP Offer 메시지를 기반으로 적절한 파라미터 또는 가능한 파라미터를 조절하고, 이 파라미터를 포함하는 SDP Answer메시지를 MCU/MRF에게 전달한다(S50047).
그리고, UE C는 전달하고자 하는 미디어를 RTP 패킷화한 후 RTP 미디어 경로(flow)를 통해 Edge Enabler 서버로 전송한다(S50048). Edge Enabler 서버는 수신된 RTP 패킷을 그대로 RTP 미디어 경로(flow)를 통해 MCU/MRF 로 전달한다(S50049).
실시예들에 따르면, 수신된 SDP Offer 메시지에서 Split Rendering등의 분산 처리가 활성화된 경우, UE C에서 패킷화된 RTP 패킷은 Edge Enabler 서버로 전송된다. 만약 에지 프로세스가 수행되지 않는다면 RTP 패킷은 MCU/MRF로 전달된다.
MCU/MRF는 수신된 RTP 패킷을 그대로 RTP 미디어 경로(flow)를 통해 UE B로 전달한다(S50050).
또한, RTP패킷을 통해 전송되는 데이터는 RTCP를 기반으로 선택적으로 (optional) 피드백 신호를 수신 받을 수 있다. 여기서, 피드백 신호는 정해진 주기에 의해 UE B가 MCU/MRF에게 지속적으로 전달해주는 파라미터를 말한다.
만약 RTCP 피드백을 수행하는 경우, UE B는 MRF/MCU에 피드백 정보를 송신한다(S50051). 송신된 피드백 정보는 MRF/MCU내에서 처리되며, 또한, MRF/MCU는 UE C로부터 받은 데이터(즉, 미디어)를 처리한다. 만일 피드백 정보가 Split Rendering 프로세스에 반영이 될 경우, MCU/MRF는 수신된 피드백 정보를 Edge Enabler 서버로 전달한다(S50052).
이 경우, UE C에서 처리된 미디어는 RTP 패킷 형태로 Edge Enabler 서버로 전달하고(S50053), Edge Enabler 서버는 수신된 RTP 패킷을 MCU/MRF로 전달한다(S50054). MCU/MRF는 수신된 RTP 패킷을 UE B로 전달한다(S50055). 즉, 클라우드 정보가 사전에 연결되어 있으면, RTP 패킷에 포함된 미디어는 클라우드 서버(즉, Edge Enabler 서버)에서 처리된 이후에 MRF/MCU로 전달되며, 전달된 미디어는 프로세스에 의해 UE B로 전송된다. 이때 재전송 되는 미디어는 기존의 전송하고자 하는 미디어에서 각각의 네트워크 망 또는 UE B에 적합하게 어느 정도 수정되어 최적화된 미디어일 수 있다. 도 28에서 설명되지 않은 부분은 도 27을 참조하기로 한다.
도 28에서, S50041 내지 S50047을 클라우드 서비스 초기화 과정이라 칭한다. 클라우드 서비스 초기화 과정은 위 스텝들 중 일부 스텝이 생략될 수도 있고, 또는 일부 스텝이 더 포함될 수도 있다.
이와 같이, 두 사용자 단말 간에 전화망을 형성하기 전에 디스커버리 요청 및 디스커버리 응답과 같은 클라우드 서비스 초기화를 수행함으로써, 다음과 같은 효과를 얻을 수 있다. 즉, 5G 전화망을 이용하여 포인트 클라우드 데이터를 전달할 수 있는 시그널 전달 방법을 제공할 수 있다. 그리고, 클라우드 망을 사용할 경우와 사용하지 않는 경우를 포함하여 전화망의 트래픽 및 데이터 처리 능력에 따라 기존 5G 전화 미디어망을 사용하거나 사용하지 않을 수 있다. 이에 더하여, 일반적인 G-PCC 또는 V-PCC에서 사용되는 지오메트리 정보와 쉽게 연동될 수 있다.
전술한 도 24 내지 도 28에서, RTP 패킷 형태로 전송되는 미디어는 XR 데이터일 수 있다. 상기 XR 데이터는 포인트 클라우드 데이터일 수 있다. 상기 포인트 클라우드 데이터는 G-PCC 기반으로 압축된 데이터(이를 G-PCC 데이터라 칭함)일 수도 있고 또는 V-PCC 기반으로 압축된 데이터(이를 V-PCC 데이터라 함)일 수도 있다.
다음은 RTP 패킷을 통해 G-PCC 데이터는 전송하는 방법에 대해 설명하기로 한다. 상기 G-PCC 데이터는 G-PCC 기반으로 압축된 지오메트리 정보 및/또는 어트리뷰트 정보를 포함할 수 있다. 상기 G-PCC 데이터는 SPS, GPS, APS와 같은 파라미터 세트를 포함할 수 있다.
즉, 다음은 실시간 및 양방향으로 사용자의 얼굴을 3차원으로 획득하고 가상의 환경에서 대화를 할 수 있는 실감형 가상 대화 및 회의 시스템에서 5G망을 이용하였을 때, G-PCC 데이터를 형성하고 전달하는 구조에 대한 설명이다. 이때, 5G망을 이용하는 서비스 시스템은 인터넷 또는 무선 망에 접속하여 양방향 사용자의 정보를 전달하고 초기 데이터를 획득한다. 획득된 데이터는 어떤 사용자인지, 사용자가 어떤 서비스를 원하는지 전반적인 정보를 획득하는 것을 모두 포함한다. 이때, 서비스를 계획하는 흐름에 따라 G-PCC 데이터는 미디어 데이터로 전송을 할 수 있거나 또는 전화망을 이용하여 전달할 수 있다.
본 문서는 5G 전화망을 이용한 실감형 포인트 클라우드 데이터(예, G-PCC 데이터)를 전송하는 전달 방법 및 구성 장치를 제안한다. 특히, 본 문서는 G-PCC 데이터를 RTP 패킷으로 전송하기 위한 RTP 패킷 구조를 제안한다.
본 문서는 G-PCC 데이터를 위해 SDP (Session Description Protocol) 기반의 RTP (Real Time Protocol) 패킷 구조를 제안함으로써, 실감형 G-PCC 데이터를 효율적으로 전송할 수 있게 한다.
전술한 바와 같이 포인트 클라우드 데이터는 압축 방식에 따라 V-PCC 데이터 또는 G-PCC 데이터로 분류된다. 본 문서는 5G 망을 이용하여 실시간 포인트 클라우드 데이터 중 특히, G-PCC 데이터를 전송하기 위한 RTP 패킷 구조를 제안한다.
실시예들에 따르면, V-PCC 방식은 일반적으로 실감형 3차원 포인트 클라우드 데이터를 2차원 형태의 비디오 이미지로 변환하여 비디오 이미지를 전송하는 방식이다. V-PCC압축 기법을 사용하였을 경우 HEVC (High Efficiency Video Coding) 비트 스트림이 형성된다. HEVC 비트스트림은 기존 RTP 프로토콜에 적합한 NAL 유닛 형태로 적용 및 확장이 가능하다. 하지만 실감형 3차원 포인트 클라우드 데이터가 G-PCC로 압축 되었을 경우, 압축된 포인트들에 대응하는 G-PCC 비트스트림을 RTP 패킷들을 통해 전달하는 것은 아래와 같은 문제가 발생한다. 본 문서에서 실감형 3차원 포인트 클라우드 데이터가 G-PCC 방식으로 압축되어 생성된 G-PCC 비트스트림은 G-PCC 데이터로 지칭될 수 있다.
즉, RTP 프로토콜은 비디오 코딩 유닛 또는 음성 데이터의 전송을 목적으로 하고 있기 때문에, G-PCC 비트스트림과 같은 3차원 가상 데이터를 전송하기 위한 구체적인 프로토콜이 구현되어 있지 않다.
그리고, RTP 헤더 확장(Header Extension)을 사용하여 정의되지 않은 데이터를 전송할 수는 있지만, 중복된 형태의 데이터가 반복적으로 전송되어 데이터 구조의 효율성에 대한 필요가 존재한다. 또한 어떤 부분을 전송해야 할 지에 대한 규약, 그리고 다수개의 헤더의 정보를 포괄하는 파라미터가 존재하지 않는다.
이에 더하여, RTP 패킷에는 G-PCC 데이터를 인식할 수 있는 인식 데이터가 존재하지 않기 때문에, 즉 G-PCC 데이터임을 나타내는 지시자가 존재하지 않기 때문에, RTP 패킷의 페이로드에 포함된 데이터가 G-PCC 데이터임을 식별할 수 없다. 또한 그 과정에 요구되는 방식 또는 파라미터에 대한 것이 정의되어 있지 않다.
즉, Time Synchronization, Encoding Type문제 때문에 G-PCC 코덱 파라미터를 RTP 프로토콜에 확장 방식으로 그대로 전송할 수 없다. 만일 임의로 RTP 패킷의 페이로드로 G-PCC데이터를 전송할 경우 데이터 세트 내 헤더 존재로 Efficiency 감소, 제 3자가 RTP 페이로드 내 컨텐트 구조 파악 불가능 등의 문제가 발생한다. 또한, 실시간 데이터 디코딩이 아닌 모든 데이터를 획득 하고 압축 해제 과정을 수행해야 한다.
그러므로, 전술한 원인을 고려하지 않는 기존 시스템을 통하여 단순히 RTP 패킷을 확장한다고 가정할 경우, 신호를 전송하고자 하는 메시지 전달 정의가 필요하다.
첫번째로 단순히 Payload Type의 명명법을 확장하여 RTP 패킷으로 G-PCC데이터를 전송하는 경우 파라미터 동기화가 이루어지지 않은 기존 시스템을 확장하거나 새로운 방식의 전달 구동 방식을 고려해야 한다. 예를 들어, 3차원 기반 비디오를 2차원 기반 비디오 이미지 내에 전송하는 경우 타임스탬프(Timestamp) 90000Hz를 기준으로 구성되어 있으며 이 방식을 사용하게 되는 경우 HDTV, NTSC등의 텔레비전 주파수율과 동기화를 쉽게 맞출 수 있다. 만약 해상도나 지터(Jitter) 등의 오류가 발생하는 경우 수신기에서는 조절이 필요하기 때문에 타임스탬프 값은 고정적으로 사용하지는 않는다. 이와 같은 형태로 현재 RTP에서 지원하는 비디오 포멧은 CelB, JPEG, H.261, H.263, H.263-1998, MPV, MP2T등과 같이 구성되어 있으며 페이로드 타입(PT) 값의 내용을 참조하여 도 29와 같이 정의된다.
도 29는 실시예들에 따른 RTP 패킷의 헤더 내 Payload Type(PT) 필드에 할당되는 페이로드 타입의 예시를 보인 도면이다. 즉, PT 필드는 해당 RTP 패킷의 페이로드에 포함되는 데이터의 타입을 지시하고 있으며, CelB, JPEG, H.261, H.263, H.263-1998, MPV, MP2T등이 페이로드에 포함될 수 있음을 지시하고 있다.
본 문서는 임의의 값(예, 72)를 할당하여, 해당 RTP 패킷의 페이로드에 포함된 데이터가 G-PCC 데이터임을 식별할 수 있다.
도 29의 테이블에서 정의된 값을 참조할 때, 할당되지 않은 번지를 이용할 경우 3차원 비디오의 전송을 가능하게 할 수 있으나 3차원 정보와 2차원 정보를 미디어 타입(Media Type), 클럭 레이트(Clock Rate) 만으로 정의할 수 없다. 따라서 독립된 또는 확장된 헤더의 정보와 구성이 요구된다.
두번째로 확장된 헤더의 규약과 메커니즘을 사용하여 전송하는 경우 새롭게 또는 독립적으로 페이로드를 삽입하여 단순 확장할 수 있다. 또한 확장 방식은 1:1 전달 방식에는 유용할 수 있으나 RTP 패킷을 다수의 사용자가 참여하고 공유하게 되는 경우 필요한 요소 기술 또는 정보를 5G네트워크 망 안에서 전달할 수 없다. 만약 일반적인 G-PCC 압축 데이터를 기존 존재하는 RTP로 전송하고 다수의 사용자가 참여하는 환경을 고려하게 될 경우, 수신기는 선행적으로 모든 데이터를 획득하고 나서 G-PCC 디코딩을 수행하거나 헤더의 정보를 선행적으로 획득하고 난 후 재 처리해야 하는 프로세스가 추가적으로 요구된다. G-PCC 스트림에 맞추어 RTP를 구조화 하고 새로운 파라미터를 설계한다면 헤더와 데이터를 분리할 수 있고 분리된 정보를 이용하여 다수개의 실감형 비디오를 필터링 할 수 있게 된다.
따라서 본 문서는 위와 같은 단순한 확장의 개념이 아닌 5G망에서 전달되는 G-PCC 데이터의 전달 구조와 SDP 협상, 및 관련 파라미터에 대하여 제안한다.
즉, RTP 포멧을 활용하여 헤더 확장 기능을 활용하는 경우, 추가 또는 사용하고자 하는 목적에 맞게 RTP 패킷의 헤더를 수정하거나 정보 전달 정의가 가능하다. 하지만 그 전달의 정의는 가변적이고 고정되지 않는 값이기 때문에 포함되는 정보와 파라미터는 재 정의해야 한다.
실시예들에 따르면, RTP 패킷의 헤더는 기본 12 바이트의 사이즈를 가지며, 이 헤더를 고정 헤더 또는 기본 헤더라 칭한다.
즉, 기본 헤더는 V(verion) 필드, P(Padding) 필드, X(Extension) 필드, CC(CSRC Count) 필드, M(Marker) 필드, PT(Payload Type) 필드, Sequence Number 필드, Timestamp 필드, SSRC(Synchronization Source) Identifier 필드를 포함한다.
상기 V (version) 필드는 2비트 길이를 가지며, RTP의 버전을 나타낸다.
상기 P (padding) 필드는 1비트 길이를 가지며, 패킷 마지막에 하나 이상의 패딩 바이트가 있는지 여부를 나타낸다.
상기 X (Extension) 필드는 1비트 또는 3비트 길이를 가지며, 기본 헤더 이후에 확장 헤더가 추가되었는지 여부를 나타낸다.
상기 CC (CSRC Count) 필드는 4비트 길이를 가지며, 12 바이트의 기본 헤더 이후에 표시되는 CSRC identifier 필드의 개수를 표시한다.
상기 M (Marker) 필드는 1 비트 길이를 가지며, 패킷 스트림 내에서 프레임 경계와 같은 중요한 이벤트들을 표시하는 데 이용된다.
상기 PT (Payload Type) 필드는 7비트 길이를 가지며, 해당 RTP 패킷의 페이로드의 타입을 나타낸다.
상기 Sequence number 필드는 16 비트 길이를 가지며, 수신측에서 패킷 손실 여부를 확인하는데 이용된다. 상기 Sequence number 필드는 보안상의 이유로 랜덤한 번호에서 시작하지만, 패킷이 증가할 때마다 1씩 증가된다.
상기 Timestamp 필드는 32비트 길이를 가지며, 해당 RTP 패킷의 첫번째 바이트의 샘플링 순간을 나타낸다.
상기 SSRC (Synchronization Source) Identifier 필드는 32비트 길이를 가지며, 동기화 소스를 나타내며, 랜덤하게 결정된다.
실시예들에 따르면, CSRC (Contributing Source) Identifiers 필드가 옵셔널하게 RTP 패킷의 기본 헤더에 추가될 수 있다.
상기 CSRC (Contributing Source) Identifiers 필드는 32 비트 길이를 가지며, 다수의 음원이 Audio Mixer를 통해 하나로 통합될 경우를 나타낸다.
그리고, RTP는 기본 헤더 이외에 추가적인 부가 정보를 전송할 수 있는 헤더 확장(header extension)을 제공한다. 본 문서는 헤더 확장을 확장 헤더라 칭하기로 한다.
이 경우, RTP 패킷은 기본 헤더, 확장 헤더, 및 페이로드로 구성될 수 있다.
이때, 확장 헤더는 2 바이트(즉, 16 비트)의 defined by profile (일종의 identification 정보) 필드, 2 바이트의 길이(length) 필드, 및 실제 데이터가 삽입되는 확장 헤더 바디(extension header body) 필드를 포함할 수 있다. 즉, RTP 패킷 별로 한 개의 헤더를 확장하고, 확장된 헤더는 16비트의 profile 필드 (즉, defined by profile 또는 Identify), 16비트의 Length 필드, 및/또는 확장 헤더 바디 필드를 포함한다.
이때, 확장 헤더의 기능 활성화를 위해서 기본 헤더에 존재하는 3비트 X 필드의 값이 1로 설정되어야 한다. 만약 1로 설정되지 않으면 RTP 패킷은 기본 헤더와 페이로드로만 구성된다. 이와 같이, RTP는 필수적으로 전송해야 하는 헤더의 구조가 고정되어 있다. 만약 추가적으로 데이터를 전송하기 위하여 헤더를 확장하려면, 위와 같은 필수 선택 규약이 존재해야 한다. 헤더 확장 값이 발현되는 경우, RTP 패킷의 헤더는 한 개 또는 두 개 이상의 구조로 확장될 수 있다.
도 30은 실시예들에 따른 G-PCC 데이터의 전송을 위한 RTP 패킷의 최소 확장 구조의 예시를 보인 도면이다. 즉, 실제 데이터가 전송되는 확장 헤더 바디 필드의 예시이다.
도 30에서, 4비트의 ID 필드는 G-PCC 비트스트림의 종류를 구분할 수 있는 ID값을 나타낸다. 예를 들어, 1-14 중 하나의 값을 취하여 G-PCC 비트스트림의 종류를 식별할 수 있다. 이때, 15의 값은 보존 형태로 보관하며 규정에 의해 사용하지 않는다. 만약 15의 값이 인식되는 경우 해당 프로세스는 더 이상 진행하지 않고 중지한다. 상기 ID 필드 다음에 오는 4비트의 길이 필드는 확장 헤더에 포함된 데이터의 길이를 바이트로 나타낸다. 예를 들어, 상기 길이 필드의 값이 0이면, 확장 헤더가 1바이트의 데이터를 포함하고, 15이면 16바이트의 데이터를 포함하는 것을 나타낸다.
도 31은 실시예들에 따른 확장을 진행하기 이전에 정의되는 프로파일과 길이 값의 예시를 보인 도면이다.
도 31의 구조에서, 2 바이트의 profile (즉, defined by profile) 필드는 고정값을 할당하는 것을 일 실시예로 한다. 본 문서에서 profile 필드는 0xBEDE의 값으로 고정되는 것을 일 실시예로 한다. 2바이트(즉, 16 비트)의 Length 필드는 실제로 발생되는 확장의 개수를 정의할 수 있다. 예를 들어, 최소 확장 구조로 데이터를 전송한다고 가정하면, 하나의 단위가 8비트로 구성된다.
도 32는 실시예들에 따른 RTP 패킷의 확장 헤더의 예시를 보인 도면이다. 즉, 도 32는 RTP 패킷의 확장 헤더의 length 필드의 값을 1로 설정하고 확장 헤더 바디 필드의 L 필드의 값을 3으로 설정하는 경우, 데이터 필드의 예시를 보인 도면이다. 상기 L 필드는 데이터 필드의 길이를 나타낸다. 상기 데이터 필드는 데이터 청크 필드라 지칭될 수 있다.
그리고, G-PCC 스트림을 보내기 위해 확장된 RTP 패킷의 헤더의 처음 데이터 (Initial Data)는 다수개의 데이터를 동기화하는 정보로 요구되는 파라미터 (또는 파라미터 정보 또는 파라미터들라 함)이다. 이때, 요구되는 파라미터는 5G망을 위해 사용되는 파라미터이며 다수개의 전송 파라미터들을 효율적으로 동기화 하고 구분하는 구분자의 역할을 수행하게 된다. G-PCC 데이터의 전송을 위해 새롭게 요구되는 파라미터들은 아래와 같다.
아래 파라미터들은 도 32의 데이터 필드에 할당되는 것을 일 실시예로 한다.
실시예들에 따르면, 파라미터들은 T (Type) 필드, F (Frame Type) 필드, H (Header/Data) 필드, HT (Header Type) 필드, SPS_Flag (5 bit) 필드 및/또는 SPS_atr_bitdepth 필드를 포함할 수 있다.
상기 T 필드는 해당 RTP 패킷(또는 RTP 패킷의 페이로드)으로 전송되는 데이터가 V-PCC 데이터(또는 V-PCC 비디오라 함)인지 또는 G-PCC 데이터(또는 G-PCC 비디오라 함)인지를 지시한다. 상기 T 필드는 동기 파라미터라 칭한다.
상기 F 필드는 프레임 타입을 결정한다. 예를 들어, 상기 F 필드의 값이 0이면 Pure 비디오 압축 스트림을 나타낸다. 즉, 다른 인캡슐레이션이 수행되지 않은 G-PCC 스트림을 나타낸다. 상기 F 필드의 값이 1이면 TLV (Type -Length-Value) 형태로 구성되어 있는 G-PCC 데이터를 나타내고, 2이면 PCC System에 결합된 ISO BMFF 형태의 스트림을 나타낸다. 3의 값은 보존 형태로 유지된다.
상기 H 필드는 헤더인지 데이터인지를 식별한다. 예를 들어, 상기 H 필드의 값이 H를 지시하면, 헤더 부분이 RTP 헤더에 결합되어 전송된다. 즉, 상기 H 필드의 값이 H(즉, 0)을 지시하면, 헤더로 인식하여 중복 형태의 전송 구조를 방지하거나 프로파일 형태의 데이터가 순차적으로 전송된다. 상기 H 필드의 값이 1이면, 헤더로 인식할 수 있는 데이터가 존재하지 않기 때문에 확장된 값은 최소한의 정보만 제공한다.
상기 HT 필드는 SPS, GPS, APS를 나타낼 수 있는 인식자를 나타낸다. 상기 HT 필드의 값은 0과 2 사이의 값으로 결정된다.
만일, 상기 H 필드의 값이 0으로 인식되는 경우 순차적으로 G-PCC 비트스트림의 주요 프로파일 값이 전달되며 SPS와 관련된 파라미터 전달 정보는 아래와 같다.
상기 SPS_Flag 필드는 5 비트 길이를 가지며, 각 비트는 플래그를 표현하는 이진 값(Binary Value)을 나타낸다.
도 33은 실시예들에 따른 SPS_Flag 필드에 할당되는 값들의 예시를 보인 도면이다.
예를 들어, 상기 SPS_Flag 필드의 값이 10000이면 해당 RTP 패킷으로 전송되는 G-PCC 데이터는 심플 모드로, 01000이면 덴스(dense 또는 밀도) 모드로, 00100이면 예측 모드로, 00010이면 메인 모드로 압축되어 전송됨을 나타낸다. 그리고, 상기 SPS_Flag 필드의 값이 00001이면 심플, 예측, 메인 모드의 조합을 나타낸다.
상기 SPS_Flag 필드는 기본 5비트로 구성되어 있지만 압축 방법에 따라 2비트로 구성될 수 있다. 만일 상기 SPS_Flag 필드가 2비트로 구성된다면, 0는 심플, 1은 덴스, 2는 예측, 3은 메인 모드(또는 프로파일 모드라 함)를 지시할 수 있다.
상기 SPS_atr_bitdepth 필드는 4 비트 길이를 가지며, attribute_bitdepth_minus1 필드의 값을 표현한다.
아래는 GPS를 전달하기 위한 파라미터들로서, HT 필드 값에 의해 결정되며 비트 결합 형태로 순차적으로 구성된다.
1비트의 Geom_tree_type 필드는 슬라이스 포인트 포지션들이 어큐판시 트리를 사용하여 코딩되었는지 또는 예측 트리를 사용하여 코딩되었는지를 지시한다.
1비트의 Inferred_direct_coding mode 필드는 direct_mode_flag 필드가 해당 지오메트리 노드 신택스에 존재하는지 여부를 나타낸다. 예를 들어, 상기 inferred_direct_coding_mode_enabled_flag필드의 값이 1이면, 상기 direct_mode_flag 필드가 해당 지오메트리 노드 신택스에 존재함을 지시한다. 예를 들어, 상기 inferred_direct_coding_mode_enabled_flag필드의 값이 0이면, 상기 direct_mode_flag 필드가 해당 지오메트리 노드 신택스에 존재하지 않음을 지시한다.
1 비트의 Bitwise_occupnacy_coding_flag 필드는 지오메트리 노드 오큐판시가 그 신택스 엘리먼트 오큐판시 맵의 비트와이즈 맥락화(bitwise contextualization)를 사용하여 인코딩되는지 여부를 나타낸다. 예를 들어, 상기 bitwise_occupancy_coding_flag 필드의 값이 1이면, 지오메트리 노드 오큐판시가 그 신택스 엘리먼트 occupancy_map의 비트와이즈 맥락화(bitwise contextualization)를 사용하여 인코딩됨을 지시한다. 예를 들어, 상기 bitwise_occupancy_coding_flag 필드의 값이 0이면, 지오메트리 노드 오큐판시가 그 디렉토리 인코드된 신택스 엘리먼트 occupancy_byte를 사용하여 인코딩됨을 지시한다.
1 비트의 Geom_tree_coded_axis_list_present_flag 필드의 값이 1이면 지오메트리 데이터 유닛(GDU) 헤더가 각 오큐판시 트리 레벨의 노드 사이즈를 유도하기 위해 사용되는 occtree_coded_axis syntax elements를 포함함을 지시한다. 상기 Geom_tree_coded_axis_list_present_flag 필드의 값이 0이면 occtree_coded_axis syntax elements는 GDU 신택스에 존재하지 않으며, 오큐판시 트리는 큐빅 볼륨을 나타낸다.
4 비트의 log2_neighbour_avail_boundary_minus1 필드는 디코딩 프로세스에서 아래와 같이 이용되는 변수(variable) NeighbAvailBoundary의 값을 나타낸다(specifies the value of the variable NeighbAvailBoundary that is used in the decoding process as follows: ).
NeighbAvailBoundary = 2log2_neighbour_avail_boundary
예를 들어, neighbour_context_restriction_flag 필드의 값이 1이면, NeighbAvailabilityMask는 1로 설정될 수 있다. 예를 들어, neighbour_context_restriction_flag 필드의 값이 0이면, NeighbAvailabilityMask는 1 << log2_neighbour_avail_boundary로 설정될 수 있다.
1 비트의 log2_intra_pred_max_node_size 필드는 오큐판시 인트라 예측 자격이 있는 옥트리 노드 사이즈를 나타낸다(specifies the octree nodesize eligible for occupancy intra prediction).
1 비트의 adjacent_child_contextualization_enabled_flag 필드는 이웃 옥트리 노드들(neighbouring octree nodes)의 인접한 자식들(adjacent children)이 비트와이즈 오큐판시 맥락화(bitwise occupancy contextualization)를 위해 사용되는지 여부를 나타낸다. 예를 들어, 상기 adjacent_child_contextualization_enabled_flag 필드의 값이 1이면, 이웃 옥트리 노드들(neighbouring octree nodes)의 인접한 자식들(adjacent children)이 비트와이즈 오큐판시 맥락화(bitwise occupancy contextualization)를 위해 사용됨을 지시한다. 예를 들어, 상기 adjacent_child_contextualization_enabled_flag 필드의 값이 0이면, 이웃 옥트리 노드들(neighbouring octree nodes)의 자식들(children)이 비트와이즈 오큐판시 맥락화(bitwise occupancy contextualization)를 위해 사용되지 않음을 지시한다.
1 비트의 geometry_planar_enabled_flag 필드의 값이 1이면 플레너 코딩 모드가 액티브됨을 지시한다. 상기 geometry_planar_enabled_flag 필드의 값이 0이면 플레너 코딩 모드가 액티브되지 않음을 지시한다.
1 비트의 geometry_angular_enabled_flag 필드는 지오메트리가 앵귤러 오리진에 위치한 빔들의 이전 셋트를 사용하여 코딩되었는지 여부를 나타낸다(whether geometry is coded using the priors of a set of beams located at, and rotating around the V-axis of, the angular origin).
실시예들에 따르면, 위에서 언급된 파라미터들 중 일부는 생략될 수도 있고, 또는 다른 필드가 새로 추가될 수도 있다.
아래는 APS를 전달하기 위한 파라미터들로서, HT 필드 값에 의해 결정되며 비트 결합 형태로 순차적으로 구성된다.
1 비트의 attr_coding_type 필드는 어트리뷰트에 대한 코딩 타입을 나타낸다. 실시예들에 따르면, 상기 attr_coding_type 필드의 값이 0이면 코딩 타입은 예측 가중치 리프팅(predicting weight lifting)를, 1이면 코딩 타입은 RAHT를, 2이면 고정 가중치 리프팅(fix weight lifting)을 지시할 수 있다.
1 비트의 num_detail_levels_minus1 필드는 어트리뷰트 코딩을 위해 LOD들의 개수를 나타낸다(specifies the number of levels of detail for the attribute coding). LOD들의 개수를 명시하기 위한 변수 LevelDetailCount는 상기 lifting_num_detail_levels_minus1 필드의 값에 1을 더하여 구할 수 있다(LevelDetailCount = lifting_num_detail_levels_minus1 + 1).
2 비트의 lod_decimation_mode 필드는 LOD들을 생성하기 위해 사용된 데시메이션 방법의 나타낸다.
1 비트의 lod_scalability_enabled_flag 필드는 어트리뷰트 디코딩 과정이 입력 지오메트리 포인트들을 위해 pruned 오큐판시 트리 디코드 결과를 허용하는지 여부를 나타낸다.
2 비트의 max_num_direct_predictors 필드는 직접 예측(direct prediction)을 위해 사용될 예측기(predictor)의 최대 개수를 나타낸다.
1 비트의 raht_prediction_enabled_flag 필드는 이웃 포인트들로부터 온 트랜스폼 웨이트 예측(transform weight prediction from the neighbour points)이 RAHT 디코딩 과정에서 인에이블되는지 여부를 나타낸다. 예를 들어, 상기 raht_prediction_enabled_flag 필드의 값이 1이면, 이웃 포인트들로부터 온 트랜스폼 웨이트 예측(transform weight prediction from the neighbour points)이 RAHT 디코딩 과정에서 인에이블되고, 0이면 디제이블됨을 나타낸다.
1 비트의 aps_coord_conv_flag 필드는 앵귤러 코디네이트 컨버전 과정이 어트리뷰트 디코딩 과정에 적용되는지 여부를 나타낸다.
상기 구조에 사용되는 기본 테이블은 G-PCC 압축 기술 표준으로 적용되고 있으나 5G망에 사용되는 값은 전부 또는 일부의 정보만 전달된다. 가용 가능한 tabular SPS, GPS, APS에 사용되는 실제 값은 아래와 같이 요약될 수 있다.
도 34는 실시예들에 따른 시퀀스 파라미터 세트(seq_parameter_set_RTP())(SPS)의 신택스 구조의 일 실시예를 보인 도면이다.
도 34에서 simple_profile_compatibility_flag 필드는 그 비트스트림이 심플 profile를 따르는지 여부를 지시한다.
dense_profile_compatibility_flag 필드는 그 비트스트림이 dense 프로파일을 따르는지 여부를 나타낸다.
predictive_profile_compatibility_flag 필드는 그 비트스트림이 예측 프로파일을 따르는지 여부를 나타낸다.
main_profile_compatibility_flag 필드는 그 비트스트림이 메인 프로파일을 따르는지 여부를 나타낸다.
slice_reordering_constraint_flag 필드는 그 비트스트림이 재정렬과 슬라이스들의 제거에 센시티브(sensitive)한지 여부를 나타낸다.
unique_point_positions_constraint_flag 필드는 각 코드된 포인트 클라우드 프레임 내 모든 포인트들이 유니크한 포지션들을 갖는지 여부를 나타낸다.
level_idc 필드는 그 비트스트림이 따르는 레벨을 나타낸다.
sps_seq_parameter_set_id 필드는 다른 신택스 엘리먼트들에 의해 참조되는 SPS에 대한 식별자를 제공한다(provides an identifier for the SPS for reference by other syntax elements).
bypass_stream_enabled_flag 필드는 바이패스 코딩 모드가 그 비트스트림을 읽는데 사용될 수 있는지 여부를 지시한다.
도 35는 실시예들에 따른 지오메트리 파라미터 세트(geometry_parameter_set_RTP())(GPS)의 신택스 구조의 일 실시예를 보인 도면이다. 도 35의 GPS에 포함되는 각 필드의 설명은 위에서 하였으므로 중복 설명을 피하기 위해 여기서는 생략한다.
도 36은 실시예들에 따른 어트리뷰트 파라미터 세트(attribute_parameter_set_RTP())(APS)의 신택스 구조의 일 실시예를 보인 도면이다.
attr_coding_type 필드는 어트리뷰트에 대한 코딩 타입을 나타낸다. 실시예들에 따르면, 상기 attr_coding_type 필드의 값이 0이면 코딩 타입은 예측 가중치 리프팅(predicting weight lifting)를, 1이면 코딩 타입은 RAHT를, 2이면 고정 가중치 리프팅(fix weight lifting)을 지시할 수 있다.
aps_slice_qp_offset_present_flag 필드는 ash_attr_qp_delta_luma and ash_attr_qp_delta_chroma 신택스 엘리먼트들이 해당 어트리뷰트 슬라이스 헤더(ASH)에 존재하는지 여부를 나타낸다.
raht_prediction_enabled_flag 필드는 이웃 포인트들로부터 온 트랜스폼 웨이트 예측(transform weight prediction from the neighbour points)이 RAHT 디코딩 과정에서 인에이블되는지 여부를 나타낸다.
last_component_prediction_enabled_flag 필드는 멀티 컴포넌트 어트리뷰트의 primary 컴포넌트가 non-primary 컴포넌트들의 reconstructed 값을 예측하기 위해 사용되는지 여부를 나타낸다.
lod_scalability_enabled_flag 필드는 어트리뷰트 디코딩 과정이 입력 지오메트리 포인트들을 위해 pruned 오큐판시 트리 디코드 결과를 허용하는지 여부를 나타낸다.
max_nn_range_minus1 필드의 값에 1을 더하여 이웃으로서 등록된 포인트의 거리를 제한하기 위해 사용된 최대 neasrest neighbor range를 나타낸다.
max_num_detail_levels_minus1 필드는 어트리뷰트 코딩을 위해 LOD들의 최대 개수를 나타낸다.
morton_sort_skip_enabled_flag 필드는 몰톤 코드 정렬 과정이 생략되었는지 여부를 나타낸다.
lod_decimation_mode 필드는 필드는 LOD들을 생성하기 위해 사용된 데시메이션 방법의 나타낸다.
lod_dist2_init 필드는 LOD 생성에서 사용된 초기 슬라이스 서브샘플링 factor를 유도하기 위해 사용된 값을 나타낸다.
aps_slice_lod_dist2_offset_present_flag 필드는 공간 서브샘플링 factor 오프셋이 어트리뷰트 데이터 유닛에 존재하는지 여부를 나타낸다.
max_num_direct_predictors 필드는 직접 예측(direct prediction)을 위해 사용될 예측기(predictor)의 최대 개수를 나타낸다.
direct_avg_predictor_disabled_flag 필드는 이웃 평균 예측이 다이렉트 예측 모드로서 선택될 수 있는지 여부를 나타낸다.
intra_lod_prediction_skip_layers 필드는 인트라 레이어 예측이 디제이블되는 디테일 레이어들의 개수를 명시한다.
lod_search_range_intra 필드는 디테일 레벨 내 예측을 위해 nearest neighbours를 결정하기 위해 사용된 서치 범위를 나타낸다.
inter_component_prediction_enabled_flag 필드는 멀티 컴포넌트 어트리뷰트의 primary 컴포넌트가 non-primary 컴포넌트들의 reconstructed 값을 예측하기 위해 사용되는지 여부를 나타낸다.
neighbour_blending_enabled_flag 필드는 예측을 위해 사용된 이웃 가중치가 그들의 관련된 공간 포지션들을 기반으로 블렌드될 수 있는지 여부를 나타낸다.
raw_attr_fixed_width_flag 필드는 raw 어트리뷰트 값들의 코딩에 사용된 비트들의 개수가 어트리뷰트 컴포넌트 비트뎁스와 같은지 여부를 나타낸다.
aps_coord_conv_flag 필드는 앵귤러 코디네이트 컨버전 과정이 어트리뷰트 디코딩 과정에 적용되는지 여부를 나타낸다.
aps_extension_flag 필드는 aps_extension_data 신택스 구조가 해당 APS 신택스 구조에 존재하는지 여부를 나타낸다.
이상에서와 같이 5G 코어로 전송 가능한 G-PCC 데이터를 위한 RTP 구조를 제안함으로써, 다음과 같은 효과가 있다.
즉, G-PCC 데이터를 RTP 스트림에 적합하게 생성하고 페이로드 유닛에 결합시킬 수 있다. 이때, RTP 패킷의 페이로드에 G-PCC데이터의 일부 또는 전부, G-PCC 데이터의 헤더 유닛 등이 분산 또는 결합되어 다중화 형태로 구성될 수 있다. 또한, RTP 포맷을 형성하기 위해, SPS, APS, GPS의 일부 또는 전부가 RTP 패킷에 포함되어 구성될 수 있다.
그리고, RTP 스트리밍 뿐 아니라 헤더 확장을 이용하여 G-PCC데이터를 전송할 수 있다. 예를 들어, G-PCC를 위한 SPS, APS, GPS를 RTP 패킷의 헤더를 통해 전송할 수 있다.
실시예들에 따르면, 실제 G-PCC 데이터(즉, 압축된 지오메트리 정보 및/또는 어트리뷰트 정보)는 RTP 패킷의 페이로드를 통해 전송하고, SPS, GPS, APS와 같은 시그널링 정보 및/또는 실제 G-PCC 데이터를 전송하는 RTP 패킷에 관련된 시그널링 정보는 해당 RTP 패킷의 확장 헤더를 통해 전송할 수 있다. 상기 G-PCC 데이터를 전송하는 RTP 패킷의 헤더(예, 확장 헤더)는 해당 RTP 패킷의 페이로드에 포함된 데이터가 G-PCC 데이터인지를 식별할 수 있는 정보를 포함한다(예, T 필드). 또한, 상기RTP 패킷의 헤더(예, 확장 헤더)는 상기 RTP를 통해 전송되는 파라미터 세트가 SPS인지, APS인지, GPS인지를 식별할 수 있는 정보를 포함한다(예, HT 필드).
이렇게 함으로써, G-PCC 데이터는 RTP 프로토콜로 전송이 가능해지며, 또한 수신기에서 RTP 패킷에 포함된 G-PCC 데이터를 식별하여 처리할 수 있다.
또한, 본 문서는 실시간 전화망을 통해 G-PCC/V-PCC XR 데이터를 송신 및 수신할 수 있다. 그리고, RTP 데이터를 통해 전화망과 외부망에 전송 가능하며 중계기 또는 클라우드 처리기는 데이터를 스케일링, 멀티플렉싱, 트랜스코딩 등을 수행할 수 있다.
다음은 5G 망을 이용하여 실시간 실감형 가상 대화 데이터 SDP/RTCP 전송 방법 및 구조에 대해 설명하기로 한다.
즉, 전술한 바와 같이 콜 플로우가 형성되고 나면, RTP패킷을 통해 데이터(예, G-PCC 데이터)를 보내기 전에 SDP 협상 과정을 수행한다. SDP 협상 과정은 전화망에 서로 연결된 송신기와 수신기(즉, UE들)가 송/수신된 데이터를 처리할 수 있는 능력이 있는지 여부를 확인하는 과정이다.
SDP 협상 과정은 UE 간에 SDP offer 메시지를 전송하고, SDP answer 메시지를 수신하는 과정이다. 그리고, UE 간 콜 연결시 RTP패킷을 통해 전송되는 데이터는 RTCP를 기반으로 선택적으로 피드백 신호를 수신 받을 수 있음을 개시하였다.
그런데, 기존에는 SDP 협상 파라미터에 G-PCC를 구성할 수 있는 값이 없었다. 따라서, G-PCC 데이터의 사전 프로파일링 값을 전송할 수 없기 때문에 UE간 비디오 데이터의 프로파일 값을 확인할 수 없는 문제가 발생한다.
본 문서는 G-PCC 데이터의 어트리뷰트 파라미터를 구성하고, 파싱 정보(예, 비디오 데이터의 프로파일 정보)를 사전에 전달함으로써 수신기에서는 전송될 데이터(예, G-PCC 데이터)가 심플, 예측, 덴스(dense), 메인 프로파일 중 어느 프로파일 모드로 압축되었는지를 사전에 확인할 수 있게 한다. 또한, 자신이 해당 프로파일로 압축된 데이터를 처리할 능력이 있는지 여부를 미리 판달할 수 있다. 다만, 제안 방식은 멀티 파라미터 또는 비디오 정보 파라미터 등 우회의 방식으로 전송 가능하므로 G-PCC 전송 콜에 제한되어 사용될 수 있다. 따라서, SDP 협상 과정에서 G-PCC를 지칭하는 파라미터를 획득할 수 있고, 사전 값이 확인되는 경우 UE는 수신 비디오의 프로파일, 프로세싱 캐퍼빌러티(Processing Capability)를 확인 할 수 있다.
실시예들에 따르면, RTCP패킷을 이용하여 역방향 (Uplink)로 전달을 쉽게 할 수 있다. 이 방식은 기존에 설정 가능한 어트리뷰트의 정의가 아닌 RTCP 패킷 안에 전달되기 때문에 네트워크 최적화 파라미터의 하나로 사용할 수 있다. 따라서 모든 데이터의 정보가 RTP로 전달될 수 있지만 RTCP에 분산되어 정보가 교환될 수 있다. RTCP는 기본적으로 일관되거나 일정한 간격으로 최초 송신자에게 보내는 피드백 정보로 활용된다. RTCP 패킷의 손실은 따라서 송신기와 수신기의 품질을 측정하거나 수신자의 상태를 주기에 해당하는 기간만큼 품질을 평가하는데 이용된다.
그리고, RTP포트가 정의되면 다음 높은 숫자의 포트 번호를 부여하며 a=<attribute>:<value>" 의 형태로 구성된다. 예를 덜어, m=audio 49170 RTP/AVP 0, a=rtcp:53020 또는 m=audio 49170 RTP/AVP 0, a=rtcp:53020 IN IP4 126.16.64.4 또는 m=audio 49170 RTP/AVP 0, a=rtcp:53020 IN IP6 2001:2345:6789:ABCD:EF01:2345:6789:ABCD과 같은 형태로 구성된다.
본 문서는 RTCP를 이용하여 G-PCC데이터를 전송하는 경우, 페이로드 타입(Payload Type)을 206으로 결정하며, 피드백 정보는 일반적으로 알려진 360 비디오 또는 실감형 비디오에 사용되는 파라미터를 이용하여 확장할 수 있다.
한편, 기존 방식을 활용하는 방식은 메타데이터의 정의와 관련된 데이터를 표현하기 위해 2차원 비디오의 전달 및 이것을 기반으로 VR 표준에 활용된 것을 참고할 수 있다. 두 가지 표준에서는 관심 있는 지역을 ROI (Region of Interest)로 정의하여 360 구 중에서 Elevation, Azimuth 범위 안에 표현된 구의 일부를 정의하는데 사용된다. ROI_ID는 ROI가 여러 개 존재할 경우 각각의 식별자를 정의하여 구분할 수 있다. ROI_ID가 정의되면 세부적으로 ROI에 해당하는 각각의 파라미터가 정의 되어야 한다. ROI_type은 초기 협상할 때 Arbitrary/Pre-Defined ROI를 정의하는데 사용된다. 만약 Arbitrary ROI로 정의되는 경우 ROI_ID는 한 개가 되기 때문에 디코더는 다수개를 처리하지 않아도 된다. 반대로 Pre-defined ROI로 정의되는 경우 다수개의 ROI_ID가 입력될 수 있다. UE 는 수신되는 ID중 선택하여 서버에 전달할 수 있으며 그 값을 초기로 데이터가 전송된다. 만약 가상의 구를 사용하게 된다면 ROI_Azimuth/ROI_Elevation값을 활용할 수 있다. Center 값은 사용자의 초점에 맞춘 점 형태의 위치가 되며 ROI의 중앙값 또는 기준점으로 사용된다. ROI_azimuth_range/ROI_elevation_range는 중앙값을 기준으로 어느 각도 만큼 허용되는지 나타낸다. 이 값이 작은 경우 ROI의 크기는 상대적으로 작은 형태로 구현이 되며 각이 큰 값으로 전달되는 경우 ROI의 크기는 상대적으로 커지게 된다. ROI_Name은 정수 형태의 식별자가 아닌 Character형태의 ROI식별자를 사용하고 싶은 경우 사용되며 필수적으로 사용하지 않아도 된다. ROI_Description은 메타데이터의 추가적인 설명이 필요한 경우 text형태의 문장 또는 문단을 전송할 수 있다. ROI_name으로 정의된 문자 식별자는 이의 일부를 사용하여 표현할 수 있고 ROI_description에서는 세부적인 내용을 설명하여 사용자가 망 안에서 서비스를 경험하고 있는 도중에 부가적인 ROI의 설명을 확인할 수 있다. ROI_expression은 ROI를 표현하기 위한 방법을 사용한다. Pre-defined ROI와 관련된 정보 수집을 위해서 수신기는 다수개의 Pre-defined ROI정보를 수집하며 그 정보는 MTSI송신기가 전송한다. SDP 협상 과정에서 결정된 ROI Index 정보는 이후 ROI정보의 Feedback정보를 주기적으로 송신기에 수신할 때 사용하게 된다. Pre-defined ROI는 양방향 또는 단방향으로 결정될 수 있으며 Arbitrary ROI는 단방향 환경에서 선택될 수 있도록 한다. 따라서 두 개의 파라미터는 같이 사용되거나 동시에 사용될 수 있지만 Pre-defined ROI가 우선 순위로 결정된다. 만약 Pre-defined ROI가 존재하지 않는다면 Arbitrary ROI 파라미터가 존재하는지 확인할 수 있다. 만약 두 개의 파라미터가 존재하지 않는다면 MTSI기반 가상 회의 송신 및 수신은 추천 또는 임의의 Viewport 기반 ROI를 결정하지 않고 모든 데이터를 전송 해야만 한다. 수신된 ROI정보를 획득하면 MTSI 송신기 또는 수신기는 ROI에 맞게 데이터를 인코딩 또는 디코딩 해야 하며 ROI에 존재하는 해상도는 주변 (background) 또는 시야각 외에 존재하는 오브젝트의 해상도보다 높게 설정되어 전송된다.
위와 같은 개념은 만약 중심 포인트가 결정되거나 선행적으로 알고 있는 G-PCC 스트림에 그대로 활용이 가능하다. 그리고, Azimuth, Elevation값을 사용하지 않더라도 특정 관심있는 지역이나 중앙값은 3차원계에서 활용 가능하다.
한편, 이러한 시스템 환경에서 Codec, Viewport Independent/Dependent 프로세싱을 원활하게 수행하기 위해서 5G망에서는 SDP 협상과정이 선행되어야 된다. 그리고, 협상이 완료 된 이후 미디어(예, G-PCC 데이터)는 RTP를 통해 전송하고 피드백이 요구되는 정보는 RTCP를 통해 전송한다. 이런 협상 과정은 3GPP TS 26.114의 MTSI 의 VR를 포함하며 IMS기반의 Telepresence를 논의하는 3GPP TS26.223 표준을 포함하고 있다. 3GPP VR Teleconference Permanent Document에 기반하여 아래와 같이 어트리뷰트가 정의된다.
3gpp_360video = "a=3gpp_video:" [SP "VDP" SP "Stereo"]
위 정의에서 SP는 ABNF문법 내에서 스페이스를 나타낸다. 만약 3gpp_360video에 정의되지 않은 어트리뷰트 및 구체적인 내용이 입력될 경우 입력된 신호는 무시한다고 가정하며 아래와 같은 형태로 협상 파라미터가 인식된다. 위 실제 예시와 같이 G-PCC기반의 비디오(또는 G-PCC 데이터)에서 그 값을 그대로 활용할 수 있으며 시스템을 파악하는 과정이 유사하게 진행 될 수 있다.
- MTSI 송신기/수신기는 SDP협상 과정에서 3gpp_360video 어트리뷰트를 파악하여 입력 신호가 5G망 내에 가상 현실 시스템임을 파악할 수 있어야 한다.
- 비디오를 위한 HEVC 코덱은 AVC, VVC코덱을 사용하거나 포함할 수 있으며 코덱 구성 요소인 NAL유닛에서는 디코더 정보를 포함하고 있거나 관련 정보를 포함할 수 있어야 한다.
- HEVC코덱을 사용하는 경우 HEVC Main 10 Profile, Main Tier, Level 5.1을 최소로 지원해야 한다. AVC코덱을 사용하는 경우 AVC Progressive High Profile, Main Tier, Level 5.1을 최소로 지원해야 한다.
- RTP 데이터를 전송하는 과정에서 RTCP 피드백을 통해 사용자의 뷰포트(Viewport) 정보를 지속적으로 전달해야 하며 Arbitrary/Pre-defined ROI와 관련된 정보도 포함된다.
- 데이터를 추가적으로 전송해야 하는 경우 RTP 헤더 확장을 통해 전달될 수 있거나 데이터 채널을 통해 관련 데이터가 전달 될 수 있다.
그리고, VDP(Video Datagram Protocol)가 전송되는 경우 VDP가 전송될 수 있는 기능과 과정에 대한 수행이 필요하며 아래와 같은 파라미터 정보가 전달된다.
(1) 서브 픽쳐 기반의 스트리밍(Sub-Picture Based Streaming): Omnidirectional 카메라로 획득된 전체 최대 해상도의 비디오가 다수개의 독립적인 서브 픽처로 구성되며 이 부분은 전체 컨텐트의 일부를 포괄한다. 사용자의 뷰포트는 한 개 또는 한 개 이상의 서브 픽쳐로 구성된 비디오를 관찰할 수 있으며 현재 사용자가 보고 있는 뷰포트에는 하이 퀄리티(High Quality) 비디오가 전송되며 그 이외의 지역에는 로우 퀄리티(Low Quality) 비디오가 전송된다. 해당 파라미터는 움직임 제한된 타일 세트(Motion-constrained tile set) 또는 sub-picture based flag를 전달하여 구현될 수 있다.
(2) Region-wise Quality Ranking: 파노라마 장면에서 특정 지역을 기반하여 지역 기반의 퀄리티를 강조하거나 해당 부분을 고화질로 인코딩할 수 있다. 그 이외의 지역은 다운스케일링(Downscaling)하여 전송할 수 있다. 예를 들어, Truncated Square Pyramid 방식과 같은 형태로 전송할 수 있다.
(3) Overlay Rendering: 전체 비디오를 낮은 화질의 로우 퀄리티 방식으로 전송을 하며 전송된 비디오는 사용자의 시청 외각의 백그라운드 형태로 이용된다. 동시에 하이 퀄리티는 RTCP정보에 기반하여 뷰포트 전송 부분이 오버레이로 전송되어 이중 형태로 전송이 된다. 오버레이로 전송되는 비디오는 한 개 또는 그 이상의 서브 픽처로 구성되어 전송될 수 있다.
실시예들에 따르면, MTSI 송신기는 SDP 협상 과정에서 3gpp_video를 포함하여 전달해야 한다. 전달 과정에서 VDP를 명시하여 전송하고자 하는 비디오의 형태가 뷰포트 종속(Viewport Dependent)임을 나타내야 한다. 만약 VDP모드가 연결 되었을 경우 맵핑 함수를 통해 해당되는 VDP의 특성이 무엇인지 선택할 수 있다. VDP 특성은 텍스트 타입(Text Type)의 구성이 될 수 있거나 하나의 변수로 지정해서 전달될 수 있다. 이와 같은 특성은 G-PCC로 확장 가능하다.
다음은 SDP 시그널링에 대해 설명하기로 한다.
SIP기반의 네트워크에서는 Network Announcement, User Interaction, Conferencing Service를 제공한다. MTSI에서 존재하는 CSCF는 SIP Proxy, 어플리케이션 서버, 미디어 게이트웨이 형태로 콜러(Caller)와 미디어 서버 사이에서 발생하며 서버가 프록시라고 가정 하였을 때 콜러는 INVITE메시지를 형성하여 SIP 프록시에 전달한다.
SIP 프록시는 100 TRYING으로 응답하고 난 후 미디어 서버에게 INVITE 메시지를 전달한다.
미디어 서버는 200 OK 메시지를 콜러에게 전달하고 콜러는 ACK메시지를 SIP 프록시에게 전달한다. ACK 메시지를 전달받은 SIP 프록시는 해당 ACK를 미디어로 전달한다. 그리고, SIP 전달 메시지를 통해 세션이 형성되며 미디어 서버는 요청된 미디어(예, G-PCC 데이터)를 RTP를 통해 전달한다. 미디어 전송이 끝나고 세션이 종료를 한다면 미디어 서버는 BYE메시지를 SIP 프록시에게 전달하고 SIP 프록시는 BYE메시지를 콜러에게 전달한다.
수신이 완료되면 역 방향으로 콜러는 200 OK 메시지를 전달한다. SIP 메시지의 송신시 SDP 메시지가 함께 포함도어 전달된다. SDP에는 미디어에 포함되는 구체적인 파라미터 어트리뷰트 값이 존재하며 SDP 협상(Negotiation)을 통해 미디어 형태를 구성하게 된다. SIP 프록시가 존재하지 않는 경우 콜러와 콜리(Callee) 사이에 SIP 메시지 송/수신 과정은 아래와 같이 단순화 할 수 있다.
도 37은 실시예들에 따른 SIP INVITE 및 응답의 실제 예시를 보인 도면이다.
도 37에서, PhoneB는 IP주소 172.20.120.30을 가지고 있으며 SIP 버전 2.0을 INVITE하는 것을 나타낸다. Via는 도중에 전달된 프록시 서버의 주소와 포트 번호를 나타내며 Phone A에서 Phone B까지 전달하는 것을 URI형태로 표현한 것이다. Contact-Length 이후 값은 SDP메시지가 삽입되어 전달된다.
도 38은 실시예들에 따른 동일한 요청에 대한 응답으로 200 OK메시지가 전달되는 예시를 나타낸 도면이다.
도 38에서 SDP 메시지는 SIP메시지에서 application/sdp로 정의하였을 경우 참조되는 메시지며 텍스트 기반의 형태로 구성되어 있다. SDP 필드의 이름과 어트리뷰트 이름은 오직 US-ASCII로만 사용하지만 어트리뷰트의 텍스트 값은 때로는 UTF-8 인코딩되어 전달할 수 있다. SDP 형태는 다수개의 타입 및 밸류(Value) 값으로 구성될 수 있으며 그 형태는 <type>=<value>로 구성된다. <type>의 경우 하나의 영문자 형태로 구성되어 있으며 <value>값은 텍스트 또는 문장으로 구성된다. 세션을 구성하기 위한 type값은 v= (protocol version), o= (originator and session identifier), s= (session name), i=* (session information), u=* (URI of description), e=* (email address), p=* (phone number), c=* (connection information -- not required if included in all media descriptions), b=* (zero or more bandwidth information lines), k=* (obsolete), a=* (zero or more session attribute lines)이 될 수 있으며 그 외로 시간을 나타내는 어트리뷰트 또는 미디어와 관련된 type은m= (media name and transport address), i=* (media title), c=* (connection information -- optional if included at session level), b=* (zero or more bandwidth information lines), k=* (obsolete), a=* (zero or more media attribute lines)가 있다.
SDP 메시지는 Offer/Answer 형태로 구성되며 두 협상이 이루어지는 메시지의 예시는 도 39(a), 도 39(b)와 같다.
도 39(a)는 실시예들에 따른 SDP offer 메시지의 예시를 보이고, 도 39(b)는 SDP answer 메시지의 예시를 보인 도면이다.
따라서 5G망에서 사용되는 미디어 교환 방식을 활용하여 G-PCC데이터를 전송하기 위해서는 사전에 사용자간 SDP 신호를 통해 인식되며 Offer/Answer방식을 통해 전달된다. 만약 SDP이용하여 전달되는 경우 어트리뷰트를 정의해야 하며 G-PCC 데이터(또는 G-PCC 비트스트림)을 수신할 수 있고, 일부 헤더의 정보가 포함될 수 있는 경우, 정보를 교환 해야 한다. 또한 미디어 세션이 형성되고 나면, 수신기는 SDP Offer 메시지에서 제시된 일부 또는 지원 가능한 파라미터를 SDP Answer 메시지 형태로 대답해야 한다.
실시예들에 따른 G-PCC 데이터와 관련된 SDP 신호의 Attribute 파라미터는 아래와 같이 정의된다.
a=3gpp_gpcc: <info1> <info2> <info3> <info4>
a=3gpp_gpcc_mtype: <header> <data> <HT>
위 정의에서, <info>에 포함되는 값은 스트림 내에 미디어 소스의 Id값이 될 수 있거나 또는 선행적으로 보낼 수 있는 파라미터가 될 수 있다. Mtype은 미디어의 헤더를 포함하는 RTP데이터가 될 수 있거나 또는 데이터 유닛만을 추출하여 전달되는 방식이 될 수 있다.
위 정의에서, <info1> <info2> <info3> <info4>는 G-PCC 에 관련된 어느 정보나 가능하다. 예를 들어, <info1>는 simple_profile_compatibility_flag, <info2>는 dense_profile_compatibility_flag, <info3>은 predictive_profile_compatibility_flag, <info4>는 main_profile_compatibility_flag에 대응될 수 있다. 이 경우를 도 40의 예시 1로 나타내었다. 즉, 본 문서에서 제시된 일부 simple, predict, dense, main 프로파일을 적용하기 위해 비디오(예, G-PCC 데이터)를 전송한다고 가정한다면 활용 가능한 예시는 도 40의 예시 1 또는 예시 2와 같다.
또한, 위 방식은 도 40과 같이 SPS, GPS, APS에 해당하는 파라미터를 RTP를 통해 전송하기 위한 전달자 역할을 한다. 따라서 부가적으로 삽입되는 파라미터는 G-PCC비디오 프로파일 또는 디코딩 수행에 요구되는 파싱 정보를 사전에 전달하는데 의의가 있다.
도 40은 실시예들에 따른 SDP offer 메시지의 일 예시를 보인 도면이다.
도 40에서, 예시 1은 <info1> <info2> <info3> <info4>를 이용하여 아래와 같이 RTP 패킷으로 전송될 데이터(예, G-PCC 데이터)가 심플 프로파일 모드로 압축되었음을 나타낸다.
a=3gpp_gpcc: simple_profile_compatibility_flag=1, dense_profile_compatibility_flag=0, predictive_profile_compatibility_flag=0, main_profile_compatibility_flag=0
도 40에서, 예시 2은 아래와 같이 텍스트 형태의 mtype을 이용하여 RTP 패킷으로 전송될 데이터(예, G-PCC 데이터)가 심플 프로파일 모드로 압축되었음을 나타낸다.
a=3gpp_gpcc: profile=[simple]
도 40은 다른 예시로서, RTP 패킷의 헤더를 통해 SPS 및/또는 GPS가 전송됨을 나타낼 수 있다.
a=3gpp_gpcc_mtype: A B HT=1 C HT = 0
a=mid:A
a=3gpp_gpcc: [header= SPS]
and/or
a=mid:B
a=3gpp_gpcc: [header= GPS]
본 문서에서 상기 SDP offer 메시지를 통해 전송되는 G-PCC 관련 정보는 어느 것이나 가능하다.
위와 같은 방법을 사용하게 된다면 데이터는 프로파일 또는 미디어 정의에 의하여 G-PCC비디오의 헤더나 데이터 유닛을 각각 분리하여 전송할 수도 있지만 데이터 유닛에 완전히 다른 일반 비디오 스트림을 삽입하여 전송할 수 있다. 또한 상기 예시에서 전달되기 위해서는 Identifier인식자를 포함하여 전달하고 각각에 해당하는 데이터와 헤더의 배열을 정렬할 수도 있다.
설명의 편의를 위하여 각 도면을 나누어 설명하였으나, 각 도면에 서술되어 있는 실시 예들을 병합하여 새로운 실시 예를 구현하도록 설계하는 것도 가능하다. 그리고, 통상의 기술자의 필요에 따라, 이전에 설명된 실시 예들을 실행하기 위한 프로그램이 기록되어 있는 컴퓨터에서 판독 가능한 기록 매체를 설계하는 것도 실시예들의 권리범위에 속한다. 실시예들에 따른 장치 및 방법은 상술한 바와 같이 설명된 실시 예들의 구성과 방법이 한정되게 적용될 수 있는 것이 아니라, 실시 예들은 다양한 변형이 이루어질 수 있도록 각 실시 예들의 전부 또는 일부가 선택적으로 조합되어 구성될 수도 있다. 실시예들의 바람직한 실시 예에 대하여 도시하고 설명하였지만, 실시예들은 상술한 특정의 실시 예에 한정되지 아니하며, 청구범위에서 청구하는 실시예들의 요지를 벗어남이 없이 당해 발명이 속하는 기술분야에서 통상의 지식을 가진 자에 의해 다양한 변형실시가 가능한 것은 물론이고, 이러한 변형실시들은 실시예들의 기술적 사상이나 전망으로부터 개별적으로 이해돼서는 안 될 것이다.
실시예들의 장치의 다양한 구성요소들은 하드웨어, 소프트웨어, 펌웨어 또는 그것들의 조합에 의해 수행될 수 있다. 실시예들의 다양한 구성요소들은 하나의 칩, 예를 들면 하나의 하드웨어 서킷으로 구현될 수 있다 실시예들에 따라, 실시예들에 따른 구성요소들은 각각 별도의 칩들로 구현될 수 있다. 실시예들에 따라, 실시예들에 따른 장치의 구성요소들 중 적어도 하나 이상은 하나 또는 그 이상의 프로그램들을 실행 할 수 있는 하나 또는 그 이상의 프로세서들로 구성될 수 있으며, 하나 또는 그 이상의 프로그램들은 실시예들에 따른 동작/방법들 중 어느 하나 또는 그 이상의 동작/방법들을 수행시키거나, 수행시키기 위한 인스트럭션들을 포함할 수 있다. 실시예들에 따른 장치의 방법/동작들을 수행하기 위한 실행 가능한 인스트럭션들은 하나 또는 그 이상의 프로세서들에 의해 실행되기 위해 구성된 일시적이지 않은 CRM 또는 다른 컴퓨터 프로그램 제품들에 저장될 수 있거나, 하나 또는 그 이상의 프로세서들에 의해 실행되기 위해 구성된 일시적인 CRM 또는 다른 컴퓨터 프로그램 제품들에 저장될 수 있다. 또한 실시예들에 따른 메모리는 휘발성 메모리(예를 들면 RAM 등)뿐 만 아니라 비휘발성 메모리, 플래쉬 메모리, PROM등을 전부 포함하는 개념으로 사용될 수 있다. 또한, 인터넷을 통한 전송 등과 같은 캐리어 웨이브의 형태로 구현되는 것도 포함될 수 있다. 또한, 프로세서가 읽을 수 있는 기록매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산방식으로 프로세서가 읽을 수 있는 코드가 저장되고 실행될 수 있다.
이 문서에서 “/”와 “,”는 “및/또는”으로 해석된다. 예를 들어, “A/B”는 “A 및/또는 B”로 해석되고, “A, B”는 “A 및/또는 B”로 해석된다. 추가적으로, “A/B/C”는 “A, B 및/또는 C 중 적어도 하나”를 의미한다. 또한, “A, B, C”도 “A, B 및/또는 C 중 적어도 하나”를 의미한다. 추가적으로, 이 문서에서 “또는”는 “및/또는”으로 해석된다. 예를 들어, “A 또는 B”은, 1) “A” 만을 의미하고, 2) “B” 만을 의미하거나, 3) “A 및 B”를 의미할 수 있다. 달리 표현하면, 본 문서의 “또는”은 “추가적으로 또는 대체적으로(additionally or alternatively)”를 의미할 수 있다.
제1, 제2 등과 같은 용어는 실시예들의 다양한 구성요소들을 설명하기 위해 사용될 수 있다. 하지만 실시예들에 따른 다양한 구성요소들은 위 용어들에 의해 해석이 제한되어서는 안된다. 이러한 용어는 하나의 구성요소를 다른 구성요소와 구별하기 위해 사욛외는 것에 불과하다. 것에 불과하다. 예를 들어, 제1 사용자 인풋 시그널은 제2사용자 인풋 시그널로 지칭될 수 있다. 이와 유사하게, 제2사용자 인풋 시그널은 제1사용자 인풋시그널로 지칭될 수 있다. 이러한 용어의 사용은 다양한 실시예들의 범위 내에서 벗어나지 않는 것으로 해석되어야만 한다. 제1사용자 인풋 시그널 및 제2사용자 인풋 시그널은 모두 사용자 인풋 시그널들이지만, 문맥 상 명확하게 나타내지 않는 한 동일한 사용자 인풋 시그널들을 의미하지 않는다.
실시예들을 설명하기 위해 사용된 용어는 특정 실시예들을 설명하기 위한 목적으로 사용되고, 실시예들을 제한하기 위해서 의도되지 않는다. 실시예들의 설명 및 청구항에서 사용된 바와 같이, 문맥 상 명확하게 지칭하지 않는 한 단수는 복수를 포함하는 것으로 의도된다. 및/또는 표현은 용어 간의 모든 가능한 결합을 포함하는 의미로 사용된다. 포함한다 표현은 특징들, 수들, 단계들, 엘리먼트들, 및/또는 컴포넌트들이 존재하는 것을 설명하고, 추가적인 특징들, 수들, 단계들, 엘리먼트들, 및/또는 컴포넌트들을 포함하지 않는 것을 의미하지 않는다. 실시예들을 설명하기 위해 사용되는, ~인 경우, ~때 등의 조건 표현은 선택적인 경우로만 제한 해석되지 않는다. 특정 조건을 만족하는 때, 특정 조건에 대응하여 관련 동작을 수행하거나, 관련 정의가 해석되도록 의도되었다.
또한, 본 문서에서 설명하는 실시예들에 따른 동작은 실시예들에 따라서 메모리 및/또는 프로세서를 포함하는 송수신 장치에 의해 수행될 수 있다. 메모리는 실시예들에 따른 동작을 처리/제어하기 위한 프로그램들을 저장할 수 있고, 프로세서는 본 문서에서 설명한 다양한 동작을 제어할 수 있다. 프로세서는 컨트롤러 등으로 지칭가능하다. 실시예들에 동작들은 펌웨어, 소프트웨어, 및/또는 그것들의 조합에 의해 수행될 수 있고, 펌웨어, 소프트웨어, 및/또는 그것들의 조합은 프로세서에 저장되거나 메모리에 저장될 수 있다.
한편, 상술한 실시예들에 따른 동작은 실시예들 따른 송신 장치 및/또는 수신 장치에 의해서 수행될 수 있다. 송수신 장치는 미디어 데이터를 송수신하는 송수신부, 실시예들에 따른 프로세스에 대한 인스트럭션(프로그램 코드, 알고리즘, flowchart 및/또는 데이터)을 저장하는 메모리, 송/수신 장치의 동작들을 제어하는 프로세서를 포함할 수 있다.
프로세서는 컨트롤러 등으로 지칭될 수 있고, 예를 들어, 하드웨어, 소프트웨어, 및/또는 그것들의 조합에 대응할 수 있다. 상술한 실시예들에 따른 동작은 프로세서에 의해 수행될 수 있다. 또한, 프로세서는 상술한 실시예들의 동작을 위한 인코더/디코더 등으로 구현될 수 있다.
상술한 바와 같이, 실시예들을 실시하기 위한 최선의 형태에서 관련 내용을 설명하였다.
상술한 바와 같이, 실시예들은 포인트 클라우드 데이터 송수신 장치 및 시스템에 전체적 또는 부분적으로 적용될 수 있다.
당업자는 실시예들의 범위 내에서 실시예들을 다양하게 변경 또는 변형할 수 있다.
실시예들은 변경/변형들을 포함할 수 있고, 변경/변형은 청구항들 및 그 와 동일한 것들의 범위를 벗어나지 않는다.

Claims (15)

  1. 제1 사용자 단말과 제2 사용자 단말간 통화를 위해 콜 연결을 수행하는 단계; 및
    상기 콜 연결이 수행되면 상기 제2 사용자 단말은 적어도 하나의 RTP(Real Time Transport Protocol) 패킷을 이용하여 포인트 클라우드 데이터를 상기 제1 사용자 단말로 전송하는 단계를 포함하며,
    상기 포인트 클라우드 데이터는 G-PCC (Geometry-based Point Cloud Compression) 기반으로 압축된 G-PCC 데이터이고,
    상기 적어도 하나의 RTP 패킷의 헤더는 상기 G-PCC 데이터를 식별하기 위한 식별 정보를 포함하는 포인트 클라우드 서비스 제공 방법.
  2. 제 1 항에 있어서,
    상기 적어도 하나의 RTP 패킷의 헤더는 상기 포인트 클라우드 데이터를 포함하는 프레임의 타입을 지시하는 정보를 더 포함하는 포인트 클라우드 서비스 제공 방법.
  3. 제 1 항에 있어서,
    상기 적어도 하나의 RTP 패킷의 헤더는 상기 포인트 클라우드 데이터의 프로파일 정보를 더 포함하는 포인트 클라우드 서비스 제공 방법.
  4. 제 1 항에 있어서, 상기 콜 연결을 수행하는 단계는
    상기 제1 사용자 단말에서 상기 제2 사용자 단말로 SDP offer 메시지를 전송하는 단계; 및
    상기 제2 사용자 단말에서 상기 제1 사용자 단말로 SDP answer 메시지를 전송하는 단계를 포함하는 포인트 클라우드 서비스 제공 방법.
  5. 제 4 항에 있어서, 상기 SDP offer 메시지는
    상기 포인트 클라우드 데이터의 프로파일 정보를 포함하는 포인트 클라우드 서비스 제공 방법.
  6. 제 1 항에 있어서,
    상기 포인트 클라우드 데이터는 V-PCC (Video-based Point Cloud Compression) 기반으로 압축된 V-PCC 데이터이며,
    상기 식별 정보는 상기 적어도 하나의 RTP 패킷에 포함된 포인트 클라우드 데이터가 상기 G-PCC 데이터인지 V-PCC 데이터인지를 식별하는 포인트 클라우드 서비스 제공 방법.
  7. 제1 사용자 단말;
    제2 사용자 단말; 및
    상기 제1 사용자 단말과 상기 제2 사용자 단말 사이에 위치하여 초기화 과정을 수행하는 적어도 하나의 에지 인에이블러를 포함하며,
    상기 제1 사용자 단말과 상기 제2 사용자 단말간 통화를 위해 콜 연결이 수행되면, 상기 제2 사용자 단말은 적어도 하나의 RTP(Real Time Transport Protocol) 패킷을 이용하여 포인트 클라우드 데이터를 상기 제1 사용자 단말로 전송하고,
    상기 포인트 클라우드 데이터는 G-PCC (Geometry-based Point Cloud Compression) 기반으로 압축된 G-PCC 데이터이고,
    상기 적어도 하나의 RTP 패킷의 헤더는 상기 G-PCC 데이터를 식별하기 위한 식별 정보를 포함하는 포인트 클라우드 서비스 제공 장치.
  8. 제 7 항에 있어서,
    상기 적어도 하나의 RTP 패킷의 헤더는 상기 포인트 클라우드 데이터를 포함하는 프레임의 타입을 지시하는 정보를 더 포함하는 포인트 클라우드 서비스 제공 장치.
  9. 제 7 항에 있어서,
    상기 적어도 하나의 RTP 패킷의 헤더는 상기 포인트 클라우드 데이터의 프로파일 정보를 더 포함하는 포인트 클라우드 서비스 제공 장치.
  10. 제 7 항에 있어서,
    상기 제1 사용자 단말과 상기 제2 사용자 단말 간의 콜 연결을 위해 상기 제1 사용자 단말에서 상기 제2 사용자 단말로 SDP offer 메시지를 전송하고, 상기 제2 사용자 단말에서 상기 제1 사용자 단말로 SDP answer 메시지를 전송하는 포인트 클라우드 서비스 제공 장치.
  11. 제 10 항에 있어서, 상기 SDP offer 메시지는
    상기 포인트 클라우드 데이터의 프로파일 정보를 포함하는 포인트 클라우드 서비스 제공 장치.
  12. 제 7 항에 있어서,
    상기 포인트 클라우드 데이터는 V-PCC (Video-based Point Cloud Compression) 기반으로 압축된 V-PCC 데이터이며,
    상기 식별 정보는 상기 적어도 하나의 RTP 패킷에 포함된 포인트 클라우드 데이터가 상기 G-PCC 데이터인지 V-PCC 데이터인지를 식별하는 포인트 클라우드 서비스 제공 장치.
  13. 제 7 항에 있어서,
    상기 제1 사용자 단말은 상기 적어도 하나의 에지 인에이블러로 디스커버리 요청을 하고, 상기 에지 인에이블러로부터 디스커버리 응답을 제공받는 초기화 과정을 수행하고,
    상기 제2 사용자 단말은 상기 적어도 하나의 에지 인에이블러로 디스커버리 요청을 하고, 상기 에지 인에이블러로부터 디스커버리 응답을 제공받는 초기화 과정을 수행하는 포인트 클라우드 서비스 제공 장치.
  14. 제 13 항에 있어서,
    상기 제1 사용자 단말과 디스커버리 요청/응답을 수행하는 에지 인에이블러와 상기 제2 사용자 단말과 디스커버리 요청/응답을 수행하는 에지 인에이블러는 서로 다른 포인트 클라우드 서비스 제공 장치.
  15. 제 13 항에 있어서,
    상기 제1 사용자 단말과 디스커버리 요청/응답을 수행하는 에지 인에이블러와 상기 제2 사용자 단말과 디스커버리 요청/응답을 수행하는 에지 인에이블러는 동일한 포인트 클라우드 서비스 제공 장치.
PCT/KR2022/011485 2021-08-03 2022-08-03 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법 WO2023014085A1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP22853461.6A EP4383735A1 (en) 2021-08-03 2022-08-03 Point cloud data transmission device, point cloud data transmission method, point cloud data reception device, and point cloud data reception method

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
KR10-2021-0101882 2021-08-03
KR20210101882 2021-08-03
KR20210115317 2021-08-31
KR10-2021-0115317 2021-08-31
KR20210115316 2021-08-31
KR10-2021-0115316 2021-08-31

Publications (1)

Publication Number Publication Date
WO2023014085A1 true WO2023014085A1 (ko) 2023-02-09

Family

ID=85155878

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2022/011485 WO2023014085A1 (ko) 2021-08-03 2022-08-03 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법

Country Status (2)

Country Link
EP (1) EP4383735A1 (ko)
WO (1) WO2023014085A1 (ko)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20200115333A (ko) * 2019-03-29 2020-10-07 삼성전자주식회사 무선 통신 시스템에서 에지 컴퓨팅 서비스를 제공하기 위한 위한 장치 및 방법
KR20200130043A (ko) * 2019-05-10 2020-11-18 삼성전자주식회사 에지 컴퓨팅 서비스에서 단말의 식별자 관리 방법 및 장치
US20210021664A1 (en) * 2019-07-16 2021-01-21 Apple Inc. Streaming of volumetric point cloud content based on session description protocols and real time protocols
KR20210041528A (ko) * 2019-10-07 2021-04-15 엘지전자 주식회사 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법
WO2021074005A1 (en) * 2019-10-14 2021-04-22 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Immersive viewport dependent multiparty video communication

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20200115333A (ko) * 2019-03-29 2020-10-07 삼성전자주식회사 무선 통신 시스템에서 에지 컴퓨팅 서비스를 제공하기 위한 위한 장치 및 방법
KR20200130043A (ko) * 2019-05-10 2020-11-18 삼성전자주식회사 에지 컴퓨팅 서비스에서 단말의 식별자 관리 방법 및 장치
US20210021664A1 (en) * 2019-07-16 2021-01-21 Apple Inc. Streaming of volumetric point cloud content based on session description protocols and real time protocols
KR20210041528A (ko) * 2019-10-07 2021-04-15 엘지전자 주식회사 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법
WO2021074005A1 (en) * 2019-10-14 2021-04-22 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Immersive viewport dependent multiparty video communication

Also Published As

Publication number Publication date
EP4383735A1 (en) 2024-06-12

Similar Documents

Publication Publication Date Title
KR102000666B1 (ko) 미디어 데이터를 송수신하기 위한 인터페이스 장치 및 방법
US11805163B2 (en) Apparatuses, methods, computer programs, and computer program products for live uplink adaptive streaming
Schierl et al. System layer integration of high efficiency video coding
WO2019151798A1 (ko) 무선 통신 시스템에서 이미지에 대한 메타데이터를 송수신하는 방법 및 장치
WO2022211476A1 (en) Method and apparatus for supporting teleconferencing and telepresence containing multiple 360 degree videos
CN110785978B (zh) 用于直播上行链路自适应流传输的设备及方法
US11039200B2 (en) System and method for operating a transmission network
Barz et al. Multimedia networks: protocols, design and applications
Adeyemi-Ejeye et al. Impact of packet loss on 4K UHD video for portable devices
EP3531700B1 (en) Image coding method, transmission method and image coding device
US20050289626A1 (en) IP based interactive multimedia communication system
WO2023014085A1 (ko) 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법
WO2023003354A1 (ko) 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법
WO2023101510A1 (ko) 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법
WO2023003349A1 (ko) 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법
US11699462B2 (en) Method, apparatus and computer program
Fitzek et al. Traffic analysis of multiple description coding of video services over IP networks
WO2024096390A1 (ko) 미디어 콜 서비스를 수행하기 위한 방법 및 장치
WO2024096562A1 (ko) 이동 통신 시스템에서 데이터 채널 응용 제공 방법 및 장치
WO2024101720A1 (en) Method and apparatus of qoe reporting for xr media services
Jiménez Herranz Design of an architecture and communication protocol for video transmission and videoconference
Hussain Performance evaluation of H. 264/AVC encoded video over TETRA enhanced data service (TEDS)
Barz PROTOCOLS, DESIGN, AND APPLICATIONS
JP2018113633A (ja) ケーブルテレビ局番組送出方法およびケーブルテレビセンター装置
Kleinschmidt Simulation of wireless networks

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: 22853461

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2022853461

Country of ref document: EP

Effective date: 20240304