Patent Description:
Augmented reality (AR) is a technology that superimposes a three-dimensional (or two-dimensional) virtual image on a real image or background and displays in a single image. Augmented reality technology that mixes real objects and virtual objects enables users to view objects in the real environment, thereby providing better realism and additional information.

In line with the development of communication technology, demand for providing various devices and extended reality (XR) services is increasing. "XR" may include virtual reality (VR), augmented reality (AR), or mixed reality (MR). XR services may include, for example, XR calls based on location-based service applications and three-dimensional (3D) XR objects, XR streaming, etc. XR calls indicate a service in which a function of producing and reproducing 3D objects is added to general video and voice calls, and XR streaming indicates a service in which an XR device receives XR content from a server and reproduces the same.

<CIT> discloses immersive media content presentation and interactive <NUM>° video communication.

"AR" is a technology that supplements the real world by outputting objects, which do not actually exist, to overlap the real world viewed by the eyes of the user. The object may be produced, stored, and transmitted in the form of a volumetric video. The volumetric video may utilize a higher computation capability and more network resources than a general video. Devices that process AR videos may have various form factors, such as a light glasses-type, a goggle-type, and a device equipped with a separate external computing device, and may have different computation capabilities depending on the form factor.

Embodiments of the disclosure may provide a method and an apparatus for an AR communication service between devices having different computation capabilities.

Embodiments of the disclosure may provide a method and an apparatus for dynamically controlling the quality of an AR video depending on a network situation.

Embodiments of the disclosure may provide a method and an apparatus for negotiating a compression technology for 3D videos with a peer device in providing a conversation service using augmented reality (AR) content.

Embodiments of the disclosure may provide a method and an apparatus for configuring a 2D conversion compression scheme and parameters for scene change when compressing 3D videos and negotiating the compression scheme with a peer device.

According to the disclosed embodiments, an excellent AR communication service is provided through negotiation of media parameters between terminals having different computation capabilities.

The above and other aspects, features, and advantages of the disclosure will be more apparent from the following detailed description taken in conjunction with the accompanying drawings, in which:.

<FIG> illustrates augmented reality devices and a server according to various embodiments.

Referring to <FIG>, an augmented reality device <NUM> and an augmented reality device <NUM> may be electronic devices owned by conference participants who are participating in the same conference. According to various embodiments, at least one of the augmented reality device <NUM> and the augmented reality device <NUM> may display media content shared in the conference. A server <NUM> may control communication between a plurality of augmented reality devices <NUM> and <NUM> and connect the same.

According to various embodiments, the server <NUM> may directly communicate with the augmented reality device <NUM>. According to various embodiments, the server <NUM> may communicate with the electronic device <NUM> that interacts with the augmented reality device <NUM>. According to various embodiments, the electronic device <NUM> may perform at least one operation to determine content to be displayed on the augmented reality device <NUM>. According to various embodiments, the server <NUM> may control information utilized (for example, necessary information) for communication of the augmented reality device <NUM> or receive management through the electronic device <NUM>.

According to various embodiments, the augmented reality device <NUM> may transmit data including media content to be used in a conference to the augmented reality device <NUM>, and the augmented reality device <NUM> may output (e.g., display) the media included in the received data. According to various embodiments, the augmented reality device <NUM> may display the media content and, at the same time, further display personal content of the augmented reality device <NUM>, which is not shared between conference members. According to various embodiments, the server <NUM> may transmit data including media content to be used in a conference to the augmented reality device <NUM> or the augmented reality device <NUM> through the electronic device <NUM>.

Although the embodiments mentioned in the disclosure will be described in connection with operations performed by the augmented reality device <NUM> or <NUM>, the augmented reality device <NUM> may exchange information with the server <NUM> through the electronic device <NUM>, and in this case, at least some of the operations included in the embodiments to be described below may be performed by the electronic device <NUM> or the server <NUM>, as shown in <FIG>.

In an embodiment, the key content in XR, including VR and AR, may be volumetric videos. Objects or spaces may be captured in real time and recorded into videos in three dimensions. Volumetric video may include continuous volumetric frames that change with time. Each volumetric frame may be represented as a set of points existing in a three-dimensional space at a specific time, and the points may have various attributes such as color and reflectance. The volumetric frame may be stored and transmitted in the form of 3D model media having different structures depending on the characteristics and applications of the content. In embodiments of the disclosure, an element-based 3D model structure and a scene-based 3D model media structure may be considered as the structures of the 3D model media.

<FIG> illustrates an element-based 3D model media structure. Here, the polygon (PLY) file format <NUM> (e.g., a PLY file), which is an example of the element-based 3D model media, is illustrated.

Referring to <FIG>, the PLY file format <NUM> may regard an object (e.g., a media object) existing in a three-dimensional space as a point cloud representing a set of vertices, and may express and store the object in three dimensions using elements representing the attributes of the vertices (which may include, for example, coordinates and/or colors). A vertex indicates a point in a volumetric space, and location information may be represented in terms of three axes in a coordinate system. One vertex may have one or more attributes. The PLY file format <NUM> may further include elements that provide information about an edge or a face including the points. The edge may indicate a line between two vertices. For example, a face may be a triangle or a rectangle formed by three or four vertices.

<FIG> illustrates a scene-based 3D model media structure. Here, a graphics language transmission format (gltf) format <NUM> (e.g., a gltf file), which is an example of the scene-based 3D model media, is illustrated.

Referring to <FIG>, the gltf format <NUM> may represent a scene in a three-dimensional space by spatially and logically structuring the same. More specifically, the scene may be structured as a plurality of nodes (e.g., camera nodes, mesh nodes, skin nodes, material nodes, accessor nodes, texture nodes, bufferView nodes, sampler nodes, video nodes, and/or buffer nodes) having a tree or graph structure and may be represented in the JavaScript object notation (JSON) format. Actual media data referenced by each node may be described as the above-described element-based 3D model structure (e.g., PLY file format <NUM>).

The two-dimensional vector value referenced by the <mesh> node may be related to the value of the <buffer> node. For example, the <buffer> node may have a byte unit value of "<NUM>", which may indicate <NUM> bytes of buffer data. The <bufferView> node may define a segment of buffer data specified by the <buffer> node as byteOffset=<NUM> and ByteLength=<NUM>, which may indicate buffer data of <NUM> to <NUM> bytes. The <accessor> node may include byteOffset=<NUM> as an additional offset, which may indicate buffer data of <NUM> to <NUM> bytes. As another example, the <bufferView> node may specify a stride between the elements in buffer data as byteStride=<NUM>, which may indicate a byte-distance of <NUM> to <NUM> and a byte-distance of <NUM> to <NUM>. The <accessor> node may include type="VEC2" and componentType=GL_FLOAT to define that the elements are two-dimensional plot vectors.

In an embodiment, the size of the buffer depends on the number of vertices, edges, and faces representing the 3D object, and thus, when capturing and 3D-modeling a real object, the size of the buffer is an important factor in determining the quality of the 3D model.

The gltf format <NUM> may provide an animation function in the form of transforming a specific node in a predetermined direction. For example, a human arm may be modeled as a tree including three nodes representing a hand, a forearm, and an upper arm, respectively, and the animation effect of moving the hand upwards may be implemented by moving both the forearm and upper arm using a connection relationship between the three nodes.

The diversity of the 3D model described above makes it possible for the 3D model including volumetric frames constituting the volumetric video and information corresponding to the volumetric frames to have various correlations.

<FIG> illustrates a volumetric video configured as continuous 3D models.

Referring to <FIG>, a volumetric video <NUM> configured as continuous 3D models may include <NUM> volumetric frames <NUM>, and each volumetric frame <NUM> may be related to one 3D model (e.g., the element-based 3D model in <FIG> or the scene-based 3D model in <FIG>).

<FIG> illustrates an animation-based volumetric video.

Referring to <FIG>, a volumetric video <NUM> configured as animation-based 3D models may include four volumetric frames <NUM>, and all of the four volumetric frames <NUM> may be related to one 3D model (e.g., the element-based 3D model in <FIG> or the scene-based 3D model in <FIG>) including animation information.

<FIG> illustrates a volumetric video conversation system according to various embodiments.

Referring to <FIG>, a volumetric video conversation system may include two or more user equipments (UEs) <NUM> and <NUM> (also referred to as caller <NUM> and callee <NUM>, respectively), a service controller <NUM>, and a transmission network <NUM>. For example, the user equipment <NUM> among the user equipments <NUM> and <NUM> may include, for example, at least one of a network interface (I/F) <NUM>, a volumetric video controller <NUM>, a volumetric video decoder <NUM>, a volumetric video encoder <NUM>, a volumetric video player <NUM>, or a volumetric video generator <NUM>. Here, the network interface (I/F) <NUM> may operate as a transceiver. At least one of the volumetric video controller <NUM>, the volumetric video decoder <NUM>, the volumetric video encoder <NUM>, the volumetric video player <NUM>, and the volumetric video generator <NUM> may be included in the controller.

The transmission network <NUM> may include a media transmission path for carrying volumetric media data for volumetric video conversation between the user equipments <NUM> and <NUM>, and the service controller <NUM> may perform a series of operations necessary for exchanging actual media data for the volumetric video conversation through the media transmission path.

The operations performed by the volumetric video conversation service controller <NUM> may include recognition of a network address of a peer user equipment (e.g., the user equipment <NUM>) and negotiation of media parameters for volumetric video conversation. As an embodiment, if a <NUM> system provides an IP multimedia subsystem (IMS)-based volumetric video conversation service, the operations of the volumetric video conversation service controller <NUM> may be provided using session initiation protocol (SIP) and session description protocol (SDP). In an embodiment, media parameters for volumetric video conversation may be negotiated using SDP signaling and formats.

<FIG> illustrates a negotiation procedure for volumetric video conversation according to various embodiments. Here, SDP messages between a user equipment (e.g., the user equipment <NUM>) operating as a caller and a user equipment (e.g., the user equipment <NUM>) operating as a callee are shown.

Referring to <FIG>, in operation <NUM>, the caller <NUM> transmits, to the callee <NUM>, an SDP message including signaling information including media parameters for videos and audio to be transmitted/received using SDP. The SDP message may be, for example, "SDP offer". The media parameters may include at least one piece of information on codec of volumetric media data and a video resolution, and may include a plurality of pieces of configuration information about one medium.

In operation <NUM>, the callee <NUM> determines at least one piece of configuration information to be finally used in consideration of the processing capability of the callee <NUM>, based on a plurality of pieces of configuration information included in the media parameters received through the SDP offer message, and transmits the determined configuration information to the caller <NUM> using an SDP message. The SDP message may be "SDP answer". The SDP answer message may include configuration information, which is not included in the SDP offer.

In operation <NUM>, if the caller <NUM> agrees to the configuration information received through the SDP answer message, the caller <NUM> may initiate a call. Although not shown, if the caller <NUM> does not agree to the configuration information received through the ADP answer message, the caller <NUM> may perform operations <NUM> and <NUM> again to modify the configuration information included in the SDP answer message and to perform renegotiation.

In an embodiment, if the caller <NUM> or the callee <NUM> needs to change at least one media parameter during the call in operation <NUM>, the caller <NUM> or the callee <NUM> may perform renegotiation including operations <NUM> and <NUM> or exchange new configuration information using real-time transport control protocol (RTCP). In an embodiment, the media parameters affecting the processing capability of any one user equipment or the network capacity may be exchanged through SDP renegotiation. In an embodiment, the media parameters that do not affect the processing capability of any one user equipment or the network capacity or that are dynamically changeable may be exchanged using RTCP.

As described above, the volumetric video may have a different volumetric frame structure (e.g., <FIG> or <FIG>) depending on the used 3D model (e.g., the model structures in <FIG> or <FIG>), and a compression scheme of the volumetric video may be differently determined depending on the 3D model or frame structure.

In the case where the PLY file format (see <FIG>), which is an example of the element-based 3D model structure, is used, the volumetric video may include a series of volumetric frames <NUM> each including PLY files as shown in <FIG>. Since the volumetric frames <NUM> of the 3D model expressed as the PLY files have correlation on the time axis, video-based compression tools may be efficiently used.

<FIG> illustrates video-based compression of a volumetric video according to various embodiments. Here, a volumetric video encoder (e.g., <NUM>) that supports ISO/IEC <NUM>-<NUM> visual volumetric video-based coding (V3C) and video-based point cloud compression (V-PCC) standards is shown as an example of video-based compression.

Referring to <FIG>, a volumetric capture module <NUM> may produce 3D model data reflecting an actual object <NUM>, a projection module <NUM> may divide the 3D model data into a plurality of (e.g., four) substreams through a projection process, the substreams may be respectively compressed by a plurality of (e.g., four) codecs <NUM>, <NUM>, <NUM>, and <NUM>, and a multiplexer <NUM> may multiplex the compressed substreams into a V3C bitstream for transmission. In an embodiment, each of the substreams may include atlas (Atl) data, occupancy (Occ) data, geometry (Geo) data, and attribute (Att) data. Here, substreams including occupancy, geometry, and attribute data may be compressed using, for example, a video codec such as high efficiency video coding (HEVC) or advanced video coding (AVC).

In the case where the scene-based 3D model structure is used, the volumetric video may have a structure in which the structures shown in <FIG> and <FIG> are mixed. As an example of the scene-based 3D model, media data in the gltf format (e.g., <FIG>) may include a JSON document indicating a scene structure and actual media data. In an embodiment, the volumetric video in <FIG> and the volumetric video in <FIG> may be implemented by updating the media data and updating the JSON document, respectively.

<FIG> illustrates scene-based compression of a volumetric video according to various embodiments. A volumetric frame generator <NUM>, a scene-based differential 3D model generator <NUM>, a scene-based 3D model buffer <NUM>, a scene structure encoder <NUM>, and a media encoder <NUM> having the configurations shown in an embodiment may be included in the volumetric video encoder <NUM> in <FIG>.

Referring to <FIG>, the volumetric frame generator <NUM> may produce a series of volumetric frames. The scene-based differential 3D model generator <NUM> may produce a scene structure in the gltf format for each volumetric frame. For example, the scene structure may be given by a hierarchy between nodes constituting the 3D scene in order to describe the entire content of the 3D scene as shown in <FIG>. The produced scene structure may be stored in the scene-based 3D model buffer <NUM> and may be input to the scene structure encoder <NUM>. The scene structure encoder <NUM> may output differential data on the scene structure in the form of a JSON patch document. The media encoder <NUM> may output media data encoded using a given video encoding technique.

The conventional video encoder outputs temporally continuous encoded data as a result of processing an input signal. In contrast, in the scene-based compression according to an embodiment of the disclosure, an input signal (e.g., the volumetric frame) at a specific time may be processed by the scene structure encoder <NUM>, the media encoder <NUM>, or both the scene structure encoder <NUM> and the media encoder <NUM> and may be output for transmission. Accordingly, outputs of the scene structure encoder <NUM> and the media encoder <NUM> may be temporally discontinuous.

When the output data of the scene structure encoder <NUM> and the media encoder <NUM> is stored and transmitted in respective streams, the scene structure information (e.g., the JSON patch document containing differential data on the scene structure) output from the scene structure encoder <NUM> may include location information for obtaining the output data of the media encoder <NUM>. For example, the location information may include at least one of a uniform resource locator (URL) of a file, a track identifier of an ISO base media file format (ISOBMFF), or information for accessing a streaming session. For example, the information for accessing a streaming session may include at least one of an IP address, a protocol identifier, or a port number, and may further include a protocol payload type depending on the protocol identifier.

<FIG> shows the structure of a volumetric video decoder according to various embodiments. In an embodiment, a scene structure updater <NUM>, a volumetric frame generator <NUM>, decoder pipelines <NUM>, and buffers <NUM> and <NUM> of the illustrated configurations may be included in the volumetric video decoder <NUM> in <FIG>. The network interface <NUM> may transmit media data of a plurality of streams received through a network <NUM> to the volumetric video decoder <NUM>, and the volumetric video decoder <NUM> may decode the media data by the configuration to be described later.

Referring to <FIG>, the scene structure updater <NUM> may output an updated scene structure included in the data received through at least one of a plurality of streams. The decoder pipelines <NUM> may include at least one media decoder for respectively decoding media data received through the plurality of streams. Each media decoder may output updated media data corresponding to each stream to a corresponding buffer <NUM> or <NUM>. The volumetric frame generator <NUM> may configure a volumetric frame using at least one of the updated scene structure and the updated media data input from the buffers <NUM> and <NUM>.

In the volumetric video conversation system according to an embodiment, the user equipment <NUM> may negotiate media parameters with the peer user equipment <NUM> using SDP. In SDP, a session in which media data is transmitted may be described by a media(m)-line. An SDP message (e.g., the SDP offer message or the SDP answer message in <FIG>) transmitted to negotiate media parameters for at least one session may include at least one m-line and information elements corresponding to an attribute(a)-line indicating attributes for describing the characteristics of media data transmitted in the corresponding session for each m-line.

In an embodiment, the m-line may have the following format. m=<media> <port> <proto> <fmt>.

Here, the <media> field indicates a media type, and may have, for example, a value of "audio", "video", or "application".

The <port> field indicates a port through which a media stream is transmitted, and may have different meanings depending on a network and a transport protocol defined as <proto>.

The <proto> field may indicate transport protocol.

The <fmt> field may indicate a media format.

The volumetric video conversation system according to an embodiment may provide volumetric videos using a video-based compression technique. The volumetric video data may be transmitted in one or more sessions.

In an embodiment, in the case where the volumetric video data is transmitted in one session, the SDP message transmitted to negotiate configuration information of the session may be described, for example, as shown in Table <NUM> below.

In the example of the SDP message, the m-line may include fields containing information for identifying the sessions of media data (e.g., media type=video, port number=<NUM>, protocol=RTP/AVPF, and media format=<NUM> and <NUM>). The first and third attribute lines may indicate that the media data in media formats <NUM> and <NUM> transmitted to the session described as the m-line use real time protocol (RTP) connection and use a volumetric video compression scheme identified as V3C. The second and fourth attribute lines include CodecGroup1 and CodecGroup2, respectively, which indicate groups of media parameters to be used in the media formats identified as <NUM> and <NUM>, respectively. The media parameters may include at least one of the type of codec, a profile, or a level used for media compression of a corresponding stream.

In an embodiment, in the case where the volumetric video data is transmitted in two or more sessions, an SDP message (e.g., the SDP offer message or SDP answer message in <FIG>) transmitted to negotiate configuration information of the sessions may be described, for example, as shown in <Table <NUM>> below.

In the example of the SDP message, the first a-line "a=V3CGroup: Atl Occ Geo Att1 Att2" indicates that substreams of media data using a volumetric video compression scheme identified as V3C are transmitted through media sessions having mid (media id) attribute values of Atl, Occ, Geo, Att1, and Att2, respectively. Here, "Atl" may indicate atlas information, "Occ" may indicate occupancy video data, "Geo" may indicate geometry video data, and "Att1" and "Att2" may indicate attribute video data. "a=AltParam" may include parameters specific to the atlas format and media parameters for describing the entirety of the V3C bitstream. The media parameters for describing the entirety of the V3C bitstream may include, for example, at least one of CodecGroup including codec parameters used in the respective substreams, information on the bandwidth of the entirety of grouped media sessions, a limited number (for example, the maximum number) of points included in the compressed 3D model, or identifiers indicating specified attributes. In certain embodiments, the specified attributes include essential attributes, but this disclosure does not require the specified attributes to include essential attributes.

In <Table <NUM>>, "a=mid:Atl" may indicate that the media session described by the m-line in the next row carries Atl information. The m-line "m=video <NUM> RTP/AVPF <NUM><NUM>" may indicate that the media type of the media session is video, that the port number is <NUM>, that the protocol is RTP/AVPF, and that the media format is identified as <NUM> and <NUM>. The a-lines after the m-line may include media parameters related to the media session. Descriptions of "a=mid:Occ", "a=mid:Geo", "a=mid:Att1", and lines related thereto are similar to the above.

The volumetric video conversation system according to an embodiment may provide volumetric videos using a scene-based compression technique. An SDP message for configuring sessions in which volumetric video data obtained through the scene-based compression technique is transmitted may include, for example, information elements shown in Table <NUM> below.

In the example of the SDP message, the first a-line "a=SDGroup: SD M1 M2" indicates that media data using a volumetric video compression scheme identified by scene description (SD) is transmitted through media sessions having mid attribute values of SD and M1, respectively. "a=SDParam" may include parameters specific to the SD format. The parameters specific to the SD format may include, for example, multipurpose internet mail extensions (MIME)-type parameters.

In <Table <NUM>>, "a=mid:SD" may indicate that the media session described by the m-line in the next row carries media data in the SD format. The m-line "video <NUM> RTP/AVPF <NUM><NUM>" may indicate that the media type of the media session is video, that the port number is <NUM>, that the protocol is RTP/AVPF, and that media format is identified as <NUM> and <NUM>. The a-lines after the m-line may include media parameters related to the media session. The descriptions of "a=mid:M1" and lines related thereto are similar to the above.

In the example of the SDP message, parameters M1 and M2 in "a=mid:M1" and "a=mid:M2" may be used as identifiers to refer to media streams transmitted through "m=video <NUM> RTP/AVPF" and "m= video <NUM> RTP/AVPF" in a 3D model having the SD format. In an embodiment, the identifiers of the media streams used in the 3D model are separate attribute values such as "a=label: medial" and "a=label: media2", which may be included in the SDP message.

In an embodiment, the above-described parameters may be included in an RTCP feedback message or a command of a hypertext transfer protocol (HTTP) restful application program interface (API) and may be transmitted during a call.

In an embodiment, the user equipment may transmit media data of a static 3D model to the peer user equipment using a data channel and negotiate media parameters to be used in transmission of a scene-based-compressed volumetric video using SDP re-invite. If the negotiation is successful, data produced based on the negotiated media parameters may be transmitted to the peer user equipment. In other words, the media data of the static 3D model is initially transmitted using a data channel, and media data transmission parameters for updating the 3D model may be transmitted to the peer user equipment through a data channel, or may be transmitted to the peer user equipment through a message including a separate m-line for negotiation. Depending on capabilities of the user equipment, embodiments of this disclosure enable the user equipment to use media data of the static 3D model and voice data while transmitting using the media data of the static 3D model, instead of performing the negotiation procedure using SDP re-invite.

A method for transmitting a volumetric video for a volumetric video communication service in a mobile communication system according to an embodiment may include: determining a volumetric video compression scheme for the volumetric video; transmitting a first message including first media parameters for the determined volumetric video compression scheme to a peer device; receiving a second message including second media parameters from the peer device in response to the transmission of the first message; and transmitting a volumetric video compressed according to the second media parameters to the peer device.

In an embodiment, at least one of the first or second messages may include first attribute line information indicating that media data of the volumetric video produced using the volumetric video compression scheme is transmitted through a plurality of media sessions, second attribute line information including media parameters describing the entirety of the plurality of media sessions, third attribute line information indicating a media attribute value of a first media session among the plurality of media sessions, first media line information describing a media type, a port number, protocol, and a media format of the first media session related to the third attribute line information, and at least one piece of fourth attribute line information including media parameters of the first media session related to the first media line information.

In an embodiment, the first attribute line information may indicate that the media data of the volumetric video is transmitted through the plurality of media sessions having media attribute values of atlas information, occupancy video data, geometry video data, and at least one piece of attribute video data, respectively.

In an embodiment, the second attribute line information may include at least one of a group of codec parameters used in substreams carried through the plurality of media sessions, information on a bandwidth of the entirety of grouped media sessions, a limited number (for example, the maximum number) of points included in the compressed three-dimensional (3D) model, or specified attributes.

In an embodiment, the first attribute line information may indicate that the media data of the volumetric video is produced using the volumetric video compression scheme identified as SD (scene description) and is transmitted through the plurality of media sessions having media attribute values of SD and M1, respectively, and the second attribute line information may include at least one media parameter specific to an SD format.

In an embodiment, at least one of the first or second messages may be an SDP offer message, an SDP answer message, an RTCP feedback message, or a command of HTTP restful API.

A method for receiving a volumetric video for a volumetric video communication service in a mobile communication system according to an embodiment may include: receiving a first message including first media parameters for a video compression scheme of the volumetric video from a peer device; transmitting a second message including second media parameters to the peer device in response to the reception of the first message; and receiving a volumetric video compressed according to the second media parameters from the peer device.

An apparatus for transmitting a volumetric video for a volumetric video communication service in a mobile communication system according to an embodiment may include a transceiver and a controller functionally connected to the transceiver, wherein the controller may be configured to determine a volumetric video compression scheme for the volumetric video, transmit a first message including first media parameters for the determined volumetric video compression scheme to a peer device, receive a second message including second media parameters from the p7eer device in response to the transmission of the first message, and transmit a volumetric video compressed according to the second media parameters to the peer device.

An apparatus for receiving a volumetric video for a volumetric video communication service in a mobile communication system according to an embodiment may include a transceiver and a controller functionally connected to the transceiver, wherein the controller may be configured to receive a first message including first media parameters for a video compression scheme of the volumetric video from the peer device, transmit a second message including second media parameters to the peer device in response to the reception of the first message, and receive a volumetric video compressed according to the second media parameters from the peer device.

The electronic device performing, managing, and implementing various embodiments may be one of various types of electronic devices.

As used herein, each of such phrases as "A or B", "at least one of A and B", "at least one of A or B", "A, B, or C", "at least one of A, B, and C", and "at least one of A, B, or C", may include any one of, or all possible combinations of the items enumerated together in a corresponding one of the phrases. As used herein, such terms as "<NUM>st" and "<NUM>nd", or "first" and "second" may be used to simply distinguish a corresponding component from another, and does not limit the components in other aspect (e.g., importance or order). It is to be understood that if an element (e.g., a first element) is referred to, with or without the term "operatively" or "communicatively", as "coupled with", "coupled to", "connected with", or "connected to" another element (e.g., a second element), it means that the element may be coupled with the other element directly (e.g., wiredly), wirelessly, or via a third element.

As used in connection with various embodiments of the disclosure, the term "module" may include a unit implemented in hardware, software, or firmware, and may interchangeably be used with other terms, for example, "logic", "logic block", "part", or "circuitry".

Various embodiments as set forth herein may be implemented as software (e.g., the program) including one or more instructions that are stored in a storage medium (e.g., internal memory <NUM> or external memory <NUM>) that is readable by a machine (e.g., the electronic device <NUM>). For example, a processor (e.g., the processor <NUM>) of the machine (e.g., the electronic device <NUM>) may invoke at least one of the one or more instructions stored in the storage medium, and execute it.

According to various embodiments, one or more of the above-described components or operations may be omitted, or one or more other components or operations may be added. In such a case, the integrated component may still perform one or more functions of each of the plurality of components in the same or similar manner as they are performed by a corresponding one of the plurality of components before the integration.

Claim 1:
A method, performed by a caller peer device, comprising:
determining a volumetric video compression scheme for a volumetric video to be transmitted for a volumetric video communication service in a mobile communication system;
transmitting (<NUM>) a first message comprising first media parameters for the determined volumetric video compression scheme to a callee peer device;
receiving (<NUM>) a second message comprising second media parameters from the callee peer device in response to the transmission of the first message; and
transmitting (<NUM>) a compressed volumetric video that is compressed according to the second media parameters to the callee peer device,
characterized in that at least one of the first or second message comprises:
first attribute line information indicating that media data of the volumetric video is produced using the volumetric video compression scheme and is transmitted through a plurality of media sessions,
second attribute line information comprising media parameters describing an entirety of the plurality of media sessions;
third attribute line information indicating a media attribute value of a first media session among the plurality of media sessions;
first media line information describing a media type, a port number, protocol, and a media format of the first media session related to the third attribute line information; and
at least one piece of fourth attribute line information comprising media parameters of the first media session related to the first media line information.