EP4595447A1 - Split-rendering configuration for multimedia immersion and interaction data in a wireless communication system - Google Patents

Abstract

There is provided, a method for wireless communication, comprising: determining a media configuration for split-rendering of a video media flow, wherein the media configuration comprises one or more parameters indicating an encoded video stream of the video media flow comprises, as non-video coded metadata, one or more data units of multimedia immersion and interaction data; signaling the media configuration to a second apparatus; establishing, with the second apparatus, based at least in part on the media configuration, a multimedia split-rendering content delivery session comprising the video media flow; and using, for split-rendering the video media flow, the one or more data units of multimedia immersion and interaction data.

Description

SMM920220294-GR-NP SPLIT-RENDERING CONFIGURATION FOR MULTIMEDIA IMMERSION AND INTERACTION DATA IN A WIRELESS COMMUNICATION SYSTEM Field [0001] The subject matter disclosed herein relates generally to the field of implementing a split-rendering configuration for multimedia immersion and interaction data in a wireless communication system. This document defines apparatuses and methods for wireless communication in a wireless communication system. Introduction [0002] Interactive and immersive multimedia communications imply various information flows carrying potentially time-sensitive inputs from one terminal to be transported over a network to a remote terminal. Applications relying on such multimedia modes of communication become more and more popular with massive online games, cloud gaming and eXtended Reality (XR) expansion through the markets. The multimedia information flows often go beyond the traditional video and audio flows and include further formats of following categories: device capabilities, media description, and spatial interaction information, respectively. These are communicated over heterogeneous networks to or from graphic rendering engines and user devices. These media and data types are thus fundamental to the successful implementation of truly immersive and interactive applications that process user input information and return reactions based in part on the exciting user inputs under a set of delay constraints. [0003] XR is used as an umbrella term for different types of realities, according to 3GPP Technical Report TR 26.928 (v17.0.0 – Apr 2022). These types of realities include, Virtual Reality (VR), Augmented Reality (AR) and Mixed Reality (MR). [0004] VR is a rendered version of a delivered visual and audio scene. The rendering is in this case designed to mimic the visual and audio sensory stimuli of the real world as naturally as possible to an observer or user as they move within the limits defined by the application. Virtual reality usually, but not necessarily, requires a user to wear a head mounted display (HMD), to completely replace the user's field of view with a simulated visual component, and to wear headphones, to provide the user with the accompanying audio. Some form of head and motion tracking of the user in VR is usually also necessary SMM920220294-GR-NP to allow the simulated visual and audio components to be updated to ensure that, from the user's perspective, items and sound sources remain consistent with the user's movements. In some implementations additional means to interact with the virtual reality simulation may be provided but are not strictly necessary. [0005] AR is when a user is provided with additional information or artificially generated items, or content overlaid upon their current environment. Such additional information or content will usually be visual and/or audible and their observation of their current environment may be direct, with no intermediate sensing, processing, and rendering, or indirect, where their perception of their environment is relayed via sensors and may be enhanced or processed. [0006] MR is an advanced form of AR where some virtual elements are inserted into the physical scene with the intent to provide the illusion that these elements are part of the real scene. [0007] XR refers to all real-and-virtual combined environments and human-machine interactions generated by computer technology and wearables. It includes representative forms such as AR, MR and VR and the areas interpolated among them. The levels of virtuality range from partially sensory inputs to fully immersive VR. A key aspect of XR is the extension of human experiences especially relating to the senses of existence (represented by VR) and the acquisition of cognition (represented by AR). [0008] Central to the success of an immersive XR experience are the interaction and spatial computing associated with an XR application activity. This applies similarly to other mainstream interaction-driven applications, such as Cloud Gaming (CG). The interaction data and associated spatial computing determining the XR rendering engine or CG gaming engine responses to the user physical inputs, contribute thus to a cyber- physical illusion of immersiveness between the physical and virtual worlds. [0009] The data such applications carry and leverage to generate the cyber-physical immersiveness illusion has been categorized into a number of classes as set out in 3GPP Technical Document S4-221557 (Nov 2022), or alternatively, Technical Report TR 26.926 (v1.1.0 – Feb 2022). This includes a device capability class, a media description class, and an interaction and immersion metadata class. [0010] In the device capability class, the formats associated with this data class describe the physical and hardware capabilities of an end user equipment (UE) and/or glass device. Some examples in this sense are camera sub-system capabilities and camera configuration (e.g., focal length, available zoom, and depth calibration information, pose SMM920220294-GR-NP reference of the main camera etc.), projection formats (e.g., cubemap, equirectangular, fisheye, stereographic etc.). The device capability data is usually static and available before the establishment of a session, hence its transfer and transport over a network is not of high concern as it can be embedded in typical session configuration procedures and protocols, such as Session Initiation Protocol (SIP) and/or Session Description Protocol (SDP). The device capability data is as such not real-time sensitive and has no real-time transport requirements. [0011] In the media description class, the data describes the space and/or the object content of a view. For instance, this data can be a scene description used to detail the 3D composition of space anchoring 2D and 3D objects within a scene (e.g., as a tree or graph structure usually of glTF2.0 or JSON syntax). Another possible representation is of a spatial description used for spatial computing and mapping of the real-world to its virtual counterpart or vice versa. In some other examples, this data type may contain 3D model descriptors of objects and their attributes formatted for instance as meshes (i.e., sets of vertices, edges and faces), or point cloud data formatted under PoLYgon (PLY) syntax to be consumed by the visual presentation devices, i.e., the UEs. Other data types may represent dynamic world graph representations whereby selected trackables (e.g., geo-cached AR/QR codes, geo-trackables like physical objects located at a specified world position, dynamic physical objects like buses, subways, etc.) enter and leave the scene perspective of the world dynamically and need to be conveyed in real-time to an AR runtime. The media description class of data may be of large size (i.e., often even more than 10 MBytes) and it may be updated with low frequency (within 10s of seconds regime) under various event triggers (e.g., user viewport change, new object entering the scene, old object exiting the scene, scene change and/or update etc.). The media description data may be real-time sensitive as it is involved in completing the display of the virtual renderings to a presentation device such as a UE, and as a result may benefit of real-time transport over a network. [0012] In the interaction and immersion metadata class, this data type contains user spatial interaction information such as: user viewport description (i.e., an encoding of azimuth, elevation, tilt, and associated ranges of motion describing the projection of the user view to a target display); user field of view (FoV) (i.e., the extent of the visible world from the viewer perspective usually described in angular domain, e.g., radians/degrees, over vertical and horizontal planes); user pose/orientation tracking data (i.e., micro- /nanosecond timestamped 3D vector for position and quaternion representation for SMM920220294-GR-NP orientation describing up to 6DoF); user gesture tracking data (i.e., an array of hands tracked each consisting of an array of hand joint locations relative to a base space); [0013] user body tracking data (e.g., a BioVision Hierarchical BVH encoding of the body and body segments movements); user facial expression/eye movement tracking data (e.g., as an array of key points/features positions or their encoding to pre-determined facial expression classes); user actionable inputs (e.g., OpenXR actions capturing user inputs to controllers or HW command units supported by an AR/VR device); split-rendering pose and spatial information (e.g., pose information containing the pose information used by a split-rendering server to pre-render an XR scene, or alternatively, a scene projection as a video frame); application and AR anchor data and description (i.e., metadata determining the position of an object or a point in the user space as an anchor for placing virtual 2D/3D objects, such as text renderings, 2D/3D photo/video content etc.). Summary [0014] In general, the interaction and immersion class data has certain characteristics. These characteristics include: low data footprint ranging usually from 32 Bytes up to around hundreds of Bytes per message with no established codecs for compression of data sources; high sampling rates varying between the video FPS frequency, e.g., 60 Hz up to 250 Hz, and in some cases wherein sample aggregation is not performed raw sample reports may be transmitted even at 1000 Hz sampling frequency; data can trigger a response with low-latency requirements (e.g., up to 50 milliseconds end-to-end from the interaction to the response as perceived by the user); can be synchronized to other media streams (e.g., video or audio media stream); can be synchronized to other interaction data (e.g., pose information may be synchronized with user actions, or alternatively, object actions); reliability is optional as determined by individual application requirements’ (e.g., in split-rendering scenarios servers may predict future pose estimates based on available pose information and hence high reliability below 10^(-3) error rate is not necessary); data encoding follows usually proprietary/non-standardized or rapidly evolving application- and interaction-dependent formats (e.g., formats and transport containers for the plethora of metadata are not yet fully defined and/or specified); carries privacy sensitive interaction events and data such as: user pose/gaze, user inputs/actions, and or user hand gestures or body orientation. SMM920220294-GR-NP [0015] The interaction and immersion metadata class is therefore real-time sensitive and requires real-time transport over a network on par with existent solutions for established media flows pertaining to video, or alternatively, audio codecs. [0016] Furthermore, in XR multimedia information flows, the format and syntax of such information flows is often application, platform and/or HW dependent and in contradiction to well-established media formats and codecs (e.g., audio or video codecs), no mainstream encodings, syntax and semantics are well established. Furthermore, no mainstream transport specific solutions have been established yet as such information flows and associated data formats evolve rapidly. The latter fact requires fast adaptation to new versions at a higher rate than typical conventional media codecs development cycles. This motivates the search for transport solutions over a network of such information flows in a real time, flexible and encoding-/syntax-agnostic manner to provide application developers necessary modern tools for fast emerging and disruptive interactive applications. [0017] Currently, the media description and interaction data benefitting real-time transmission and synchronization may be in some implementations transmitted based on at least three different options based on existing technologies. These technologies are: WebRTC data channel based on the Stream Control Transmission Protocol (SCTP); RTP header extension embedding the metadata information in-band in the RTP transport (for example, US Patent Application #63/420,885); and new RTP payload format generically dedicated to the transport of real-time metadata (for example, US Patent Application #63/478,932). [0018] A potential solution for the first technology (discussed in 3GPP Tdoc S4-221557) comprises the SCTP data channel of the WebRTC being used to carry interaction metadata. A generic data channel payload format for timed metadata including a timestamp is added to the chunk user data section of the SCTP data channel. This is a flexible option for metadata transport since it allows carriage of metadata not directly associated to media and enables differentiation in terms of reliability, priority, and ordering requirements by setting up data channels with different properties. It relies on IETF established protocols and available technologies within the market today. On the downside, there is no inherent timing, synchronization, and jitter support and FEC mechanisms are missing in case of SCTP. [0019] In case of the second technology a potential solution (discussed in 3GPP Tdoc S4-221555, or alternatively, US Patent Application #63/420,885) comprises a RTP SMM920220294-GR-NP header extension designed to carry interaction metadata of limited size while its associated media content is carried in the RTP payload. Support for a single metadata type or multiple metadata types can be carried in the proposed header extension to allow for scalability and flexibility. This approach has the advantage that the transported metadata is time-synchronized to the media data. Moreover, all the robustness and timing mechanisms provided by RTP are included (e.g., synchronization, jitter, congestion control support, FEC mechanisms etc.). However, it only makes sense if a media stream exists, which is often the case for AR or VR specific use cases aided by split-rendering. In case no media streams are present, transmission of RTP packets with empty/dummy payloads would however be required. Another concern is the potentially large size of the RTP headers, depending on the metadata type. RTP header extensions can also be silently ignored by a receiver if the latter is unable to process them. [0020] In case of the third technology, the usage of a separate RTP stream where the interaction metadata is carried in the RTP payload is possible (as proposed in US Patent Application #63/478,932). In RTP, the details of media encoding, such as signal sampling rate, frame size and timing, are specified in RTP payload formats. Hence, sending interaction metadata in a separate RTP stream is based on defining a new RTP payload format for interaction metadata whereby a generic RTP metadata payload dedicated to the transport of different interaction and immersion metadata is formulated. The advantage of this approach is that it enables the usage of all RTP mechanisms (timing, synchronization, jitter management support as well as FEC robustness etc) while providing a generic format that can cover all types of interaction metadata. This requires carry over in IETF to become a universal transport standard. However, definition of a new payload format typically takes at least two years in IETF meaning that for 3GPP, or alike, networked systems, the developed format would at the earliest be useful at the end of the 3GPP Release 19 cycle, or alternatively, in the medium-term. [0021] Of interest therefore, are solutions for transporting multimedia interaction and immersion data, that cater for diverse multimedia data types (e.g., media description, interaction and immersion metadata classes and their subcategories), including various syntax and formats, various data sizes (e.g., from hundreds of Bytes to tens of MBytes), various timed data generation (e.g., from periodically generated with strict timing to event-based data), and real-time synchronization constraints. [0022] Furthermore, split-rendering additionally requires effective signaling functionality for the media configuration of various information flows acting as metadata for the split- SMM920220294-GR-NP rendering functionality and media display. Consequently, solutions for the media configuration signaling and interaction and immersion metadata transport as enabler to split-rendering architectures, is proposed herein. [0023] Disclosed herein are procedures for a split-rendering configuration for multimedia immersion and interaction data in a wireless communication system. Said procedures may be implemented by apparatuses and methods for wireless communication in a wireless communication system. [0024] There is provided an apparatus for wireless communication, comprising a processor; and a memory coupled with the processor, the processor configured to cause the apparatus to: determine a media configuration for split-rendering of a video media flow, wherein the media configuration comprises one or more parameters indicating an encoded video stream of the video media flow comprises, as non-video coded metadata, one or more data units of multimedia immersion and interaction data; signal the media configuration to a second apparatus; establish, with the second apparatus, based at least in part on the media configuration, a multimedia split-rendering content delivery session comprising the video media flow; and use, for split-rendering the video media flow, the one or more data units of multimedia immersion and interaction data.. [0025] There is further provided an apparatus for wireless communication, comprising a processor; and a memory coupled with the processor, the processor configured to cause the apparatus to: receive, from a first apparatus, a media configuration for split-rendering of a video media flow, wherein the media configuration comprises one or more parameters indicating an encoded video stream of the video media flow comprises, as non-video coded metadata, one or more data units of multimedia immersion and interaction data; configure the apparatus, using the media configuration, to receive the video media flow; decode the encoded video stream of the video media flow, wherein the decoding comprises extracting the non-video coded metadata; and consume, from the non-video coded metadata, the one or more data units of multimedia immersion and interaction data. [0026] There is further provided a method of wireless communication, comprising: determining a media configuration for split-rendering of a video media flow, wherein the media configuration comprises one or more parameters indicating an encoded video stream of the video media flow comprises, as non-video coded metadata, one or more data units of multimedia immersion and interaction data; signaling the media configuration to a second apparatus; establishing, with the second apparatus, based at SMM920220294-GR-NP least in part on the media configuration, a multimedia split-rendering content delivery session comprising the video media flow; and using, for split-rendering the video media flow, the one or more data units of multimedia immersion and interaction data.. There is further provided a method for wireless communication comprising: receiving, from a first apparatus, a media configuration for split-rendering of a video media flow, wherein the media configuration comprises one or more parameters indicating an encoded video stream of the video media flow comprises, as non-video coded metadata, one or more data units of multimedia immersion and interaction data; configuring the apparatus, using the media configuration, to receive the video media flow; decoding the encoded video stream of the video media flow, wherein the decoding comprises extracting the non-video coded metadata; and consuming, from the non-video coded metadata, the one or more data units of multimedia immersion and interaction data.. Brief description of the drawings [0027] In order to describe the manner in which advantages and features of the disclosure can be obtained, a description of the disclosure is rendered by reference to certain apparatus and methods which are illustrated in the appended drawings. Each of these drawings depict only certain aspects of the disclosure and are not therefore to be considered to be limiting of its scope. The drawings may have been simplified for clarity and are not necessarily drawn to scale. [0028] Methods and apparatus for a split-rendering configuration for multimedia immersion and interaction data in a wireless communication system, will now be described, by way of example only, with reference to the accompanying drawings, in which: Figure 1 illustrates an embodiment of a wireless communication system; Figure 2 illustrates an embodiment of a user equipment apparatus; Figure 3 illustrates an embodiment of a network node; Figure 4 illustrates an RTP and RTCP protocol stack over IP networks; Figure 5 illustrates a WebRTC (SRTP) protocol stack over IP networks; Figure 6 illustrates an RTP packet format and header information; Figure 7 illustrates an SRTP packet format and header information; Figure 8 illustrates an RTP/SRTP header extension format and syntax; Figure 9 illustrates a simplified block diagram of a generic video codec performing spatial and temporal compression of a video source; SMM920220294-GR-NP Figure 10 illustrates a video coded elementary stream and corresponding plurality of NAL units; Figure 11 illustrates an embodiment of a method of wireless communication in a wireless communication system; Figure 12 illustrates an alternative embodiment of a method of wireless communication in a wireless communication system; Figure 13a illustrates an embodiment of a split-rendering architecture for interactive and immersive multimedia applications; Figure 13b illustrates an embodiment of high-level split rendering flows; Figure 14 illustrates a representation of multimedia interaction and immersion user data as metadata within a video coded elementary stream for MPEG H-26x family of video codecs; and Figure 15 illustrates a representation of multimedia interaction and immersion user data as metadata within a video coded elementary stream for the AV1 video codec. Detailed description [0029] As will be appreciated by one skilled in the art, aspects of this disclosure may be embodied as a system, apparatus, method, or program product. Accordingly, arrangements described herein may be implemented in an entirely hardware form, an entirely software form (including firmware, resident software, micro-code, etc.) or a form combining software and hardware aspects. [0030] For example, the disclosed methods and apparatus may be implemented as a hardware circuit comprising custom very-large-scale integration (“VLSI”) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. The disclosed methods and apparatus may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, or the like. As another example, the disclosed methods and apparatus may include one or more physical or logical blocks of executable code which may, for instance, be organized as an object, procedure, or function. [0031] Furthermore, the methods and apparatus may take the form of a program product embodied in one or more computer readable storage devices storing machine readable code, computer readable code, and/or program code, referred hereafter as code. The storage devices may be tangible, non-transitory, and/or non-transmission. The SMM920220294-GR-NP storage devices may not embody signals. In certain arrangements, the storage devices only employ signals for accessing code. [0032] Any combination of one or more computer readable medium may be utilized. The computer readable medium may be a computer readable storage medium. The computer readable storage medium may be a storage device storing the code. The storage device may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. [0033] More specific examples (a non-exhaustive list) of the storage device would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random-access memory (“RAM”), a read-only memory (“ROM”), an erasable programmable read-only memory (“EPROM” or Flash memory), a portable compact disc read-only memory (“CD-ROM”), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store, a program for use by or in connection with an instruction execution system, apparatus, or device. [0034] Reference throughout this specification to an example of a particular method or apparatus, or similar language, means that a particular feature, structure, or characteristic described in connection with that example is included in at least one implementation of the method and apparatus described herein. Thus, reference to features of an example of a particular method or apparatus, or similar language, may, but do not necessarily, all refer to the same example, but mean “one or more but not all examples” unless expressly specified otherwise. The terms “including”, “comprising”, “having”, and variations thereof, mean “including but not limited to”, unless expressly specified otherwise. An enumerated listing of items does not imply that any or all of the items are mutually exclusive, unless expressly specified otherwise. The terms “a”, “an”, and “the” also refer to “one or more”, unless expressly specified otherwise. [0035] As used herein, a list with a conjunction of “and/or” includes any single item in the list or a combination of items in the list. For example, a list of A, B and/or C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C or a combination of A, B and C. As used herein, a list using the terminology “one or more of” includes any single item in the list or a combination of items in the list. For example, one or more of A, B and C includes only A, only B, only SMM920220294-GR-NP C, a combination of A and B, a combination of B and C, a combination of A and C or a combination of A, B and C. As used herein, a list using the terminology “one of” includes one, and only one, of any single item in the list. For example, “one of A, B and C” includes only A, only B or only C and excludes combinations of A, B and C. As used herein, “a member selected from the group consisting of A, B, and C” includes one and only one of A, B, or C, and excludes combinations of A, B, and C.” As used herein, “a member selected from the group consisting of A, B, and C and combinations thereof” includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C or a combination of A, B and C. [0036] Furthermore, the described features, structures, or characteristics described herein may be combined in any suitable manner. In the following description, numerous specific details are provided, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of the disclosure. One skilled in the relevant art will recognize, however, that the disclosed methods and apparatus may be practiced without one or more of the specific details, or with other methods, components, materials, and so forth. In other instances, well- known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the disclosure. [0037] Aspects of the disclosed method and apparatus are described below with reference to schematic flowchart diagrams and/or schematic block diagrams of methods, apparatuses, systems, and program products. It will be understood that each block of the schematic flowchart diagrams and/or schematic block diagrams, and combinations of blocks in the schematic flowchart diagrams and/or schematic block diagrams, can be implemented by code. This code may be provided to a processor of a general-purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the schematic flowchart diagrams and/or schematic block diagrams. [0038] The code may also be stored in a storage device that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the storage device produce an article of SMM920220294-GR-NP manufacture including instructions which implement the function/act specified in the schematic flowchart diagrams and/or schematic block diagrams. [0039] The code may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other devices to produce a computer implemented process such that the code which executes on the computer or other programmable apparatus provides processes for implementing the functions/acts specified in the schematic flowchart diagrams and/or schematic block diagram. [0040] The schematic flowchart diagrams and/or schematic block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of apparatuses, systems, methods, and program products. In this regard, each block in the schematic flowchart diagrams and/or schematic block diagrams may represent a module, segment, or portion of code, which includes one or more executable instructions of the code for implementing the specified logical function(s). [0041] It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. Other steps and methods may be conceived that are equivalent in function, logic, or effect to one or more blocks, or portions thereof, of the illustrated Figures. [0042] The description of elements in each figure may refer to elements of proceeding Figures. Like numbers refer to like elements in all Figures. [0043] Figure 1 depicts an embodiment of a wireless communication system 100 for a split-rendering configuration for multimedia immersion and interaction data in a wireless communication system. In one embodiment, the wireless communication system 100 includes remote units 102 and network units 104. Even though a specific number of remote units 102 and network units 104 are depicted in Figure 1, one of skill in the art will recognize that any number of remote units 102 and network units 104 may be included in the wireless communication system 100. The wireless communication system may comprise a wireless communication network and at least one wireless communication device. The wireless communication device is typically a 3GPP User Equipment (UE). The wireless communication network may comprise at least one network node. The network node may be a network unit. SMM920220294-GR-NP [0044] In one embodiment, the remote units 102 may include computing devices, such as desktop computers, laptop computers, personal digital assistants (“PDAs”), tablet computers, smart phones, smart televisions (e.g., televisions connected to the Internet), set-top boxes, game consoles, security systems (including security cameras), vehicle on- board computers, network devices (e.g., routers, switches, modems), aerial vehicles, drones, or the like. In some embodiments, the remote units 102 include wearable devices, such as smart watches, fitness bands, optical head-mounted displays, or the like. Moreover, the remote units 102 may be referred to as subscriber units, mobiles, mobile stations, users, terminals, mobile terminals, fixed terminals, subscriber stations, UE, user terminals, a device, or by other terminology used in the art. The remote units 102 may communicate directly with one or more of the network units 104 via UL communication signals. In certain embodiments, the remote units 102 may communicate directly with other remote units 102 via sidelink communication. [0045] The network units 104 may be distributed over a geographic region. In certain embodiments, a network unit 104 may also be referred to as an access point, an access terminal, a base, a base station, a Node-B, an eNB, a gNB, a Home Node-B, a relay node, a device, a core network, an aerial server, a radio access node, an AP, NR, a network entity, an Access and Mobility Management Function (“AMF”), a Unified Data Management Function (“UDM”), a Unified Data Repository (“UDR”), a UDM/UDR, a Policy Control Function (“PCF”), a Radio Access Network (“RAN”), an Network Slice Selection Function (“NSSF”), an operations, administration, and management (“OAM”), a session management function (“SMF”), a user plane function (“UPF”), an application function, an authentication server function (“AUSF”), security anchor functionality (“SEAF”), trusted non-3GPP gateway function (“TNGF”), an application function, a service enabler architecture layer (“SEAL”) function, a vertical application enabler server, an edge enabler server, an edge configuration server, a mobile edge computing platform function, a mobile edge computing application, an application data analytics enabler server, a SEAL data delivery server, a middleware entity, a network slice capability management server, or by any other terminology used in the art. The network units 104 are generally part of a radio access network that includes one or more controllers communicably coupled to one or more corresponding network units 104. The radio access network is generally communicably coupled to one or more core networks, which may be coupled to other networks, like the Internet and public switched telephone networks, among other networks. These and other elements of radio access and core SMM920220294-GR-NP networks are not illustrated but are well known generally by those having ordinary skill in the art. [0046] In one implementation, the wireless communication system 100 is compliant with New Radio (NR) protocols standardized in 3GPP, wherein the network unit 104 transmits using an Orthogonal Frequency Division Multiplexing (“OFDM”) modulation scheme on the downlink (DL) and the remote units 102 transmit on the uplink (UL) using a Single Carrier Frequency Division Multiple Access (“SC-FDMA”) scheme or an OFDM scheme. More generally, however, the wireless communication system 100 may implement some other open or proprietary communication protocol, for example, WiMAX, IEEE 802.11 variants, GSM, GPRS, UMTS, LTE variants, CDMA2000, Bluetooth®, ZigBee, Sigfox, LoraWAN among other protocols. The present disclosure is not intended to be limited to the implementation of any particular wireless communication system architecture or protocol. [0047] The network units 104 may serve a number of remote units 102 within a serving area, for example, a cell or a cell sector via a wireless communication link. The network units 104 transmit DL communication signals to serve the remote units 102 in the time, frequency, and/or spatial domain. [0048] Figure 2 depicts a user equipment apparatus 200 that may be used for implementing the methods described herein. The user equipment apparatus 200 is used to implement one or more of the solutions described herein. The user equipment apparatus 200 is in accordance with one or more of the user equipment apparatuses described in embodiments herein. In particular, the user equipment apparatus 200 may comprise a UE 102 or a UE 1310 of Figure 13a, comprising application client 1311, MSH 1312, split rendering client 1313, for instance. The user equipment apparatus 200 includes a processor 205, a memory 210, an input device 215, an output device 220, and a transceiver 225. [0049] The input device 215 and the output device 220 may be combined into a single device, such as a touchscreen. In some implementations, the user equipment apparatus 200 does not include any input device 215 and/or output device 220. The user equipment apparatus 200 may include one or more of: the processor 205, the memory 210, and the transceiver 225, and may not include the input device 215 and/or the output device 220. [0050] As depicted, the transceiver 225 includes at least one transmitter 230 and at least one receiver 235. The transceiver 225 may communicate with one or more cells (or SMM920220294-GR-NP wireless coverage areas) supported by one or more base units. The transceiver 225 may be operable on unlicensed spectrum. Moreover, the transceiver 225 may include multiple UE panels supporting one or more beams. Additionally, the transceiver 225 may support at least one network interface 240 and/or application interface 245. The application interface(s) 245 may support one or more APIs. The network interface(s) 240 may support 3GPP reference points, such as Uu, N1, PC5, etc. Other network interfaces 240 may be supported, as understood by one of ordinary skill in the art. [0051] The processor 205 may include any known controller capable of executing computer-readable instructions and/or capable of performing logical operations. For example, the processor 205 may be a microcontroller, a microprocessor, a central processing unit (“CPU”), a graphics processing unit (“GPU”), an auxiliary processing unit, a field programmable gate array (“FPGA”), or similar programmable controller. The processor 205 may execute instructions stored in the memory 210 to perform the methods and routines described herein. The processor 205 is communicatively coupled to the memory 210, the input device 215, the output device 220, and the transceiver 225. [0052] The processor 205 may control the user equipment apparatus 200 to implement the user equipment apparatus behaviors described herein. The processor 205 may include an application processor (also known as “main processor”) which manages application-domain and operating system (“OS”) functions and a baseband processor (also known as “baseband radio processor”) which manages radio functions. [0053] The memory 210 may be a computer readable storage medium. The memory 210 may include volatile computer storage media. For example, the memory 210 may include a RAM, including dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and/or static RAM (“SRAM”). The memory 210 may include non-volatile computer storage media. For example, the memory 210 may include a hard disk drive, a flash memory, or any other suitable non-volatile computer storage device. The memory 210 may include both volatile and non-volatile computer storage media. [0054] The memory 210 may store data related to implement a traffic category field as described herein. The memory 210 may also store program code and related data, such as an operating system or other controller algorithms operating on the apparatus 200. [0055] The input device 215 may include any known computer input device including a touch panel, a button, a keyboard, a stylus, a microphone, or the like. The input device 215 may be integrated with the output device 220, for example, as a touchscreen or similar touch-sensitive display. The input device 215 may include a touchscreen such SMM920220294-GR-NP that text may be input using a virtual keyboard displayed on the touchscreen and/or by handwriting on the touchscreen. The input device 215 may include two or more different devices, such as a keyboard and a touch panel. [0056] The output device 220 may be designed to output visual, audible, and/or haptic signals. The output device 220 may include an electronically controllable display or display device capable of outputting visual data to a user. For example, the output device 220 may include, but is not limited to, a Liquid Crystal Display (“LCD”), a Light- Emitting Diode (“LED”) display, an Organic LED (“OLED”) display, a projector, or similar display device capable of outputting images, text, or the like to a user. As another, non-limiting, example, the output device 220 may include a wearable display separate from, but communicatively coupled to, the rest of the user equipment apparatus 200, such as a smart watch, smart glasses, a heads-up display, or the like. Further, the output device 220 may be a component of a smart phone, a personal digital assistant, a television, a table computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, or the like. [0057] The output device 220 may include one or more speakers for producing sound. For example, the output device 220 may produce an audible alert or notification (e.g., a beep or chime). The output device 220 may include one or more haptic devices for producing vibrations, motion, or other haptic feedback. All, or portions, of the output device 220 may be integrated with the input device 215. For example, the input device 215 and output device 220 may form a touchscreen or similar touch-sensitive display. The output device 220 may be located near the input device 215. [0058] The transceiver 225 communicates with one or more network functions of a mobile communication network via one or more access networks. The transceiver 225 operates under the control of the processor 205 to transmit messages, data, and other signals and also to receive messages, data, and other signals. For example, the processor 205 may selectively activate the transceiver 225 (or portions thereof) at particular times in order to send and receive messages. [0059] The transceiver 225 includes at least one transmitter 230 and at least one receiver 235. The one or more transmitters 230 may be used to provide uplink communication signals to a base unit of a wireless communication network. Similarly, the one or more receivers 235 may be used to receive downlink communication signals from the base unit. Although only one transmitter 230 and one receiver 235 are illustrated, the user equipment apparatus 200 may have any suitable number of transmitters 230 and receivers SMM920220294-GR-NP 235. Further, the transmitter(s) 230 and the receiver(s) 235 may be any suitable type of transmitters and receivers. The transceiver 225 may include a first transmitter/receiver pair used to communicate with a mobile communication network over licensed radio spectrum and a second transmitter/receiver pair used to communicate with a mobile communication network over unlicensed radio spectrum. [0060] The first transmitter/receiver pair may be used to communicate with a mobile communication network over licensed radio spectrum and the second transmitter/receiver pair used to communicate with a mobile communication network over unlicensed radio spectrum may be combined into a single transceiver unit, for example a single chip performing functions for use with both licensed and unlicensed radio spectrum. The first transmitter/receiver pair and the second transmitter/receiver pair may share one or more hardware components. For example, certain transceivers 225, transmitters 230, and receivers 235 may be implemented as physically separate components that access a shared hardware resource and/or software resource, such as for example, the network interface 240. [0061] One or more transmitters 230 and/or one or more receivers 235 may be implemented and/or integrated into a single hardware component, such as a multi- transceiver chip, a system-on-a-chip, an Application-Specific Integrated Circuit (“ASIC”), or other type of hardware component. One or more transmitters 230 and/or one or more receivers 235 may be implemented and/or integrated into a multi-chip module. Other components such as the network interface 240 or other hardware components/circuits may be integrated with any number of transmitters 230 and/or receivers 235 into a single chip. The transmitters 230 and receivers 235 may be logically configured as a transceiver 225 that uses one more common control signals or as modular transmitters 230 and receivers 235 implemented in the same hardware chip or in a multi-chip module. [0062] Figure 3 depicts further details of the network node 300 that may be used for implementing the methods described herein. The network node 300 may be one implementation of an entity in the wireless communication network, e.g. in one or more of the wireless communication networks described herein. The network node 300 may comprise a network node such as a node of the edge network 1320 in Figure 13a (for instance the SRAF 1321 and configuration function 1321a and provisioning function 1322b; the RTC AS 1322 and signaling server 1322a and SRS 1322b) or may be a node of SMM920220294-GR-NP the data network 1330 such as ASP 1331. The network node 300 includes a processor 305, a memory 310, an input device 315, an output device 320, and a transceiver 325. [0063] The input device 315 and the output device 320 may be combined into a single device, such as a touchscreen. In some implementations, the network node 300 does not include any input device 315 and/or output device 320. The network node 300 may include one or more of: the processor 305, the memory 310, and the transceiver 325, and may not include the input device 315 and/or the output device 320. [0064] As depicted, the transceiver 325 includes at least one transmitter 330 and at least one receiver 335. Here, the transceiver 325 communicates with one or more remote units 200. Additionally, the transceiver 325 may support at least one network interface 340 and/or application interface 345. The application interface(s) 345 may support one or more APIs. The network interface(s) 340 may support 3GPP reference points, such as Uu, N1, N2 and N3. Other network interfaces 340 may be supported, as understood by one of ordinary skill in the art. [0065] The processor 305 may include any known controller capable of executing computer-readable instructions and/or capable of performing logical operations. For example, the processor 305 may be a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or similar programmable controller. The processor 305 may execute instructions stored in the memory 310 to perform the methods and routines described herein. The processor 305 is communicatively coupled to the memory 310, the input device 315, the output device 320, and the transceiver 325. [0066] The memory 310 may be a computer readable storage medium. The memory 310 may include volatile computer storage media. For example, the memory 310 may include a RAM, including dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and/or static RAM (“SRAM”). The memory 310 may include non-volatile computer storage media. For example, the memory 310 may include a hard disk drive, a flash memory, or any other suitable non-volatile computer storage device. The memory 310 may include both volatile and non-volatile computer storage media. [0067] The memory 310 may store data related to establishing a multipath unicast link and/or mobile operation. For example, the memory 310 may store parameters, configurations, resource assignments, policies, and the like, as described herein. The memory 310 may also store program code and related data, such as an operating system or other controller algorithms operating on the network node 300. SMM920220294-GR-NP [0068] The input device 315 may include any known computer input device including a touch panel, a button, a keyboard, a stylus, a microphone, or the like. The input device 315 may be integrated with the output device 320, for example, as a touchscreen or similar touch-sensitive display. The input device 315 may include a touchscreen such that text may be input using a virtual keyboard displayed on the touchscreen and/or by handwriting on the touchscreen. The input device 315 may include two or more different devices, such as a keyboard and a touch panel. [0069] The output device 320 may be designed to output visual, audible, and/or haptic signals. The output device 320 may include an electronically controllable display or display device capable of outputting visual data to a user. For example, the output device 320 may include, but is not limited to, an LCD display, an LED display, an OLED display, a projector, or similar display device capable of outputting images, text, or the like to a user. As another, non-limiting, example, the output device 320 may include a wearable display separate from, but communicatively coupled to, the rest of the network node 300, such as a smart watch, smart glasses, a heads-up display, or the like. Further, the output device 320 may be a component of a smart phone, a personal digital assistant, a television, a table computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, or the like. [0070] The output device 320 may include one or more speakers for producing sound. For example, the output device 320 may produce an audible alert or notification (e.g., a beep or chime). The output device 320 may include one or more haptic devices for producing vibrations, motion, or other haptic feedback. All, or portions, of the output device 320 may be integrated with the input device 315. For example, the input device 315 and output device 320 may form a touchscreen or similar touch-sensitive display. The output device 320 may be located near the input device 315. [0071] The transceiver 325 includes at least one transmitter 330 and at least one receiver 335. The one or more transmitters 330 may be used to communicate with the UE, as described herein. Similarly, the one or more receivers 335 may be used to communicate with network functions in the PLMN and/or RAN, as described herein. Although only one transmitter 330 and one receiver 335 are illustrated, the network node 300 may have any suitable number of transmitters 330 and receivers 335. Further, the transmitter(s) 330 and the receiver(s) 335 may be any suitable type of transmitters and receivers. [0072] There exists certain standardized real-time suited transport architectures and protocols such as the Real-time Transport Protocol (RTP), defined in IETF standard SMM920220294-GR-NP RFC 3550 titled “RTP: A Transport Protocol for Real-Time Applications”, its securely provisioned Secure Real-time Transport Protocol (SRTP) defined in IETF standard RFC 3711 titled “The Secure Real-time Transport Protocol (SRTP)” , and its web-targeted stack Web Real-Time Communications WebRTC defined in the W3C standard recommendation dated 06 March 2023 titled “WebRTC: Real-Time Communication in Browsers” , respectively. [0073] RTP is a media codec agnostic network protocol with application-layer framing used to deliver multimedia (e.g., audio, video etc.) data in real-time over IP networks. It is used in conjunction with a sister protocol for control, i.e., Real-time Transport Control Protocol (RTCP), to provide end-to-end features such as jitter compensation, packet loss and out-of-order delivery detection, synchronization and source streams multiplexing. Figure 4 illustrates an overview of the RTP and RTCP protocol stack. An IP layer 405 carries signaling from the media session data plane 410 and from the media session control plane 450. The data plane 410 stack comprises functions for a User Datagram Protocol (UDP) 412, RTP 416, RTCP 414, Media codecs 420 and quality control 422. The control plane 450 stack comprises functions for UDP 452, Transmission Control Protocol (TCP) 454, Session Initiation Protocol (SIP) 462 and Session Description Protocol (SDP) 464. [0074] SRTP is a secured version of RTP, providing encryption (mainly by means of payload confidentiality), message authentication and integrity protection (by means of PDU, i.e., headers and payload, signing), as well as replay attack protection. Similarly to RTP, the SRTP sister protocol is SRTCP. This provides the same functions to its RTCP counterpart. As such, in vanilla SRTP versions, the RTP header information is still accessible but non-modifiable, whereas the payload is encrypted. These security provisions are illustrated in Figure 7. Furthermore, the key exchange and additional security parameters necessary to use SRTP are based upon the Datagram Transport Layer Security (DTLS) key exchange procedure. SRTP is used for these reasons as the transport protocol for media in the WebRTC stack which ensures secure RTC multimedia communications over web browser interfaces. [0075] Figure 5 illustrates a overview of a WebRTC (i.e., based on SRTP) protocol stack. As illustrated, an IP layer 505 carries signaling from the data plane 510 and the control plane 550. The data plane 510 stack comprises functions for UDP 512, Interactive Connectivity Establishment (ICE) 524, Datagram Transport Layer Security (DTLS) 526, SRTP 517, SRTCP 515, media codecs 520, Quality Control 522 and SCTP 528. ICE 574 SMM920220294-GR-NP may use the Session Traversal Utilities for NAT (STUN) protocol and Traversal Using Relays around NAT (TURN) to address real-time media content delivery across heterogeneous networks and NAT rules and firewalls. The SCTP 528 data plane is mainly dedicated as an application data channel and may be non-time critical, whereas the SRTP 517 based stack including elements of control, i.e., SRTCP 515, encoding, i.e., media codecs 520, and Quality of Service (QoS), i.e., Quality Control 522, is dedicated to time-critical transport. The control plane 550 is shown as comprising TCP 554, TLS 556, HTTP 558, SSE/XHR/other 568, XMPP/other 570, SDP 564, and SIP 562. [0076] The RTP and SRTP header information share the same format as illustrated, respectively, in Figures 6 and 7. Figure 6 illustrates an RTP packet 630, whereas Figure 7 illustrates an SRTP packet 760. A brief summary of the fixed header information of packets 630 and 760 will now be provided. [0077] ‘V’ 641, 761 is 2 bits indicating the protocol version used. [0078] ‘P’- 643, 763 is a 1 bit field indicating that one or more zero-padded octets at the end of the payload are present, whereby, among others, the padding may be necessary for fixed-sized encrypted blocks or for carrying multiple RTP/SRTP packets over lower layer protocols. [0079] ‘X’ 634, 764 is 1 bit indicating that the standard fixed RTP/SRTP header will be followed by an RTP header extension usually associated with a particular data/profile that will carry more information about the data (e.g., the frame marking RTP header extension for video data, as described in the IETF working draft dated November 2021 titled “Frame Marking RTP Header Extension”, or generic RTP header extensions such as the RTP/SRTP extended protocol, as described in IETF standard RFC 6904 titled “Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)”.) [0080] ‘CC’ 636, 766, is 4 bits indicating number of contributing media sources (CSRC) that follow the fixed header. [0081] ‘M’ 638, 768 is 1 bit intended to mark information frame boundaries in the packet stream, whose behaviour is exactly specified by RTP profiles (e.g., H.264, H.265, H.266, AV1 etc.). [0082] ‘PT’ 640, 770 is 7 bits indicating the payload type, which in case of audio and video codec profiles may be dynamic and negotiated by means of SDP (e.g., 96 for H.264, 97 for H.265, 98 for AV1 etc.). The payload profiles are registered with IANA and rely on IETF profiles describing how the transmission of data is enclosed within the payload of an RTP PDU. Current IANA registered payload profiles, as specified for SMM920220294-GR-NP example in ITU-T standard H.265 V8 (08/2021), describe audio/video codecs and application-based forward-error correction (FEC) coded media content, yet none cater for uncoded non audio-visual data formats. [0083] ‘Sequence number’ 642, 772 is 16 bits indicating the sequence number which increments by one with each RTP data packet sent over a session. [0084] ‘Timestamp’ 644, 774 is 32 bits indicating timestamp in ticks of the payload type clock reflecting the sampling instant of the first octet of the RTP data packet (associated for video stream with a video frame), whereas the first timestamp of the first RTP packet is selected at random. [0085] ‘Synchronization Source (SSRC) identifier’ 646, 776 is 32 bits field indicating a random identifier for the source of a stream of RTP packets forming a part of the same timing and sequence number space, such that a receiver may group packets based on synchronization source for playback. [0086] ‘Contributing Source (CSRC) identifier’ 648, 778 list of up to 16 CSRC items of 32 bits each given the amount of CSRC mixed by RTP mixers within the current payload as signalled by the CC bits. The list identifies the contributing sources for the payload contained in this packet given the SSRC identifiers of the contributing sources. [0087] A brief summary of remaining aspects of the complete header information of packets 630 and 760 will now be described. [0088] ‘RTP header extension’ 650, 780 is a variable length field present if the X bit 634, 764 is marked. The header extension is appended to the RTP fixed header information after the CSRC list 648, 778 if present. The RTP header extension 650, 780 is 32-bit aligned and formed of the following fields: A 16-bit extension identifier defined by a profile and usually negotiated and determined via the Session Description Protocol (SDP) signaling mechanism; a 16-bit length field describing the extension header length in 32-bits multiples excluding the first 32 bits corresponding to the 16 bits extension identifier and the 16 bits length fields itself; and a 32-bit aligned header extension raw data field formatted according to some RTP header extension identifier specified format. [0089] The RTP header extension 650, 780 format and syntax are like the ones of SRTP. The format 800 and syntax is illustrated in Figure 8. In addition, in both RTP and SRTP only one RTP extension header 650, 780 may be appended to the fixed header information, as described in IETF standard RFC 3550 titled “RTP: A Transport Protocol for Real-Time Applications”. However, for both RTP and SRTP, extensions to the base protocols exist to allow for multiple RTP header extensions 650, 780 of predetermined SMM920220294-GR-NP types to be appended to the fixed header information of the protocols, as per IETF standard RFC: 8285 titled “A General Mechanism for RTP Header Extensions”. [0090] In some embodiments, RTP header extensions produced at the source may be ignored by the destination endpoints that do not have the knowledge to interpret and process the RTP header extensions transmitted by the source endpoint. [0091] Video coding domain and metadata support will now be briefly described, beginning with modern hybrid video coding. [0092] The interactivity and immersiveness of modern and future multimedia XR applications requires guarantees in terms of meeting packet error rate (PER) and packet delay budget (PDB) for the QoE. The video source jitter and wireless channel stochastic characteristics of mobile communications systems make the former challenging to meet especially for high-rate specific digital video transmissions, e.g., 4K, 3D video, 2x2K eye- buffered video etc. [0093] The current video source information is encoded based on 2D, 2D+Depth, or alternatively, 3D representations of video content. The encoded elementary stream video content is generally, regardless of the source encoder, organized into two abstraction layers meant to separate the storage and video coding domains, i.e., the network transport packetization and format, and respectively, the video coding related syntax and associated semantics of a codec. The first determines the bitstream format, whereas the latter specifies the contents of the video coded bitstream. [0094] In one example, MPEG video codec families (e.g., H.264, H.265, H.266) rely on network abstraction layer (NAL) units to packetize and store bitstreams to a byte-aligned format for transport or storage over various mediums (including networks). The NAL units (NALUs) may enclose both video coding layer (VCL) information, i.e., video coded content (e.g., frames, slices, tiles etc.) NALUs, and respectively, non-VCL information, i.e., parameter sets, supplemental enhancement information (SEI) messages etc.. The NAL syntax encapsulates thus VCL and non-VCL information and provides abstract containerization mechanisms for in-transit coded streams, i.e., for disk storage/caching/transmission and parsing/decoding. [0095] In another example, open-source video codec alternatives (e.g., VP8/VP9, or similarly, AV1) take a similar approach as MPEG video codecs for packetization, storage and communication over various media. For example, the AV1 bitstream is comprised of Open Bitstream Units (OBUs) and each OBU may contain one or more video coded SMM920220294-GR-NP frames, video coded tiles, non-video coded padding and non-video coded metadata as OBU_METADATA. [0096] Based on the above, the NALUs, or alternatively, OBUs provide mechanisms that can be exploited towards the transport of metadata which is not relevant to the video coded bitstream chroma and luminance representation. [0097] On the other hand, the VCL, or alternatively, the video coded information, encapsulates the video coding procedures of an encoder and compresses the source encoded video information based on some entropy coding method, e.g., context-adaptive binary arithmetic encoding (CABAC), context-adaptive variable-length coding (CAVLC) etc. [0098] A simplified description of the VCL procedures to generically encode video content will now be described. A picture in a video sequence is partitioned into coding units (e.g., macroblocks, coding tree units, blocks, or variations thereof) of a configured size. The coding units may be subsequently split under some tree partitioning structures, or alike hierarchical structures, as described in ITU-T standard H.264 V8 (08/2021), ITU-T standard H.265 V8 (08/2021), ITU-T standard H.266 V4 (04/2022). For instance, such tree partitioning structures may comprise binary/ternary/quaternary trees, or under some predetermined geometrically motivated 2D segmentation patterns as described by de Rivaz, p & Haughton, (2018) in the paper titled “AV1 Bitstream & Decoding Process Specification” from the Alliance for Open Media, 182, e.g., the 10-way split. [0099] Encoders use visual references among such coding units to encode picture content in a differential manner based on residuals. The residuals are determined given the prediction modes associated with the reconstruction of information. Two modes of prediction are universally available as intra-prediction (shortly referred to as intra as well) or inter-prediction (or inter in short form). The intra mode is based on deriving and predicting residuals based on other coding units’ contents within the current picture, i.e., by computing residuals of current coding units given their adjacent coding units coded content. The inter mode is based, on the other hand, on deriving and predicting residuals based on coding units’ contents from other pictures, i.e., by computing residuals of current coding units given their adjacent coded pictures content. [0100] The residuals are then further transformed for compression using some multi- dimensional (2D/3D) spatial multimodal transform, e.g., frequency-based (i.e., Discrete Cosine Transform, or alike), or wavelet-based linear transform (e.g., Walsh Hadamard SMM920220294-GR-NP Transform, or equivalently, Discrete Wavelet Transform), to extract the most prominent frequency components of the coding units’ residuals. The insignificant high-frequency contributions of residuals are dropped, and the floating-point transformed representation of remaining residuals is further quantized based on some parametric quantization procedure down to a selected number of bits per sample, e.g., 8/10/12 bits. Lastly, the transformed and quantized residuals and their associated motion vectors to their prediction references either in intra or inter mode are encoded using an entropy encoding mechanism to compress the information based on the stochastic distribution of the source bit content. The output of this operation is a bitstream of the coded residual content of the VCL. [0101] A simplified generic diagram of the blocks of a modern hybrid (applying both temporal and spatial compression via intra-/inter-prediction) video codec is illustrated in Figure 9.. [0102] Figure 9 illustrates a simplified block diagram 900 of a generic video codec performing both spatial and temporal (motion) compression of a video source. The encoder blocks are captured within the “Encoder” tagged domain 910. The decoder blocks are captured within the “Decoder” tagged domain 920. One skilled in the art may associate the generic diagram from above describing a hybrid codec with a plethora of state-of-the-art video codecs, such as, but not limited to H.264, H.265, H.266 (generically referred to as H.26x) or VP8/VP9/AV1. As such, the concepts hereby utilized shall be considered in general sense, unless otherwise specifically clarified and reduced in scope to some codec embodiment hereafter. [0103] The block diagram 900 shows a raw input video frame (picture) 901 being input to a picture block partitioning function block 911 of encoder 910. A subsequent functional block 912 is illustrated as ‘spatial transform’. A subsequent functional block 913 is illustrated as ‘quantization’. A subsequent functional block 914 is illustrated as ‘entropy coding’. This functional block 914 outputs to video coded bitstream 902 but also to motion estimation 915 of the encoder 910. The motion estimation 915 outputs to inter prediction block 921 of decoder 920. This block 921 outputs to buffer 920, which itself outputs to recovered video frame video (picture) 903. Inter prediction block 921 may be switched to connect with a sum junction feeding into spatial transform 912. Further, it is illustrated in the block diagram 900 that quantization block 913 may output to an inverse quantization block 926 of decoder 920. The inverse quantization block 926 illustrated as receiving entropy decoding 927 of video coded bitstream 902. The inverse SMM920220294-GR-NP quantization block 926 outputs to inverse spatial transform block 925 which, via a sum junction, feeds into a loop & visual filtering block 923, itself feeding into buffer 922. As hereinbefore described, the block diagram 900 is illustrated by way of example, to convey the various functional blocks of a modern hybrid video codec from the perspective of both encoder and decoder operations. [0104] The coded residual bitstream 902 is thus encapsulated into an elementary stream as NAL units, or equivalently, as OBUs ready for storage or transmission over a network. The NAL units, or alternatively, OBUs are the main syntax elements of a video codec, and these may encapsulate encoded video parameters (e.g., video/sequence/picture parameter set (VPS/SPS/PPS)), one or more supplemental enhancement information (SEI) messages, or alternatively OBU metadata payloads, and encoded video headers and residuals data, (e.g., slices as partitions of a picture, or equivalently, a video frame or video tile). The encapsulation general syntax carries information described by codec specific semantics meant to determine the usage of metadata, non-video coded data and video encoded data and aid the decoding process. [0105] Within one example referencing the MPEG video codec family (e.g., H.264, H.265, H.266), the NAL units encapsulation syntax is composed of a header portion determining the beginning of a NAL unit and the type thereof, and a raw byte payload sequence containing the NAL unit relevant information. The NAL unit payload may subsequently be formed of a payload syntax or a payload specific header and an associated payload specific syntax. A critical subset of NAL units is formed of parameter sets, e.g., VPS, SPS, PPS, SEI messages and configuration NAL units (also known generically as non-VCL NAL units), and picture slice NAL units containing video encoded data (e.g., entropy-based arithmetic encoding) as VCL information. These concepts are illustrated in Figure 10for the context of an elementary stream applicable generically to the H.264, H.265, H.266 MPEG family of video codecs. [0106] Figure 10 illustrates a video coded elementary stream and its corresponding plurality of NAL units 1000. The NAL units 1000 are formed of a header 1010 and a payload 1020. The header 1010 contains information about the type, size, and video coding attributes and parameters of the NAL unit data enclosed information. The NAL unit data may be non-VCL NAL comprising video/sequence/picture parameters payload 1021, and supplemental enhancement information payload 1022, or VCL NAL comprising a frame/picture/slice payload 1023 having header 1023a and video coded payload 1023b. The non-VCL NALUs may include in a supplemental enhancement SMM920220294-GR-NP information payload 1022 one or more SEI messages 1022a. The NAL header 1010 is illustrated as comprising a NAL unit type, NAL unit byte length, video coding layer ID and temporal video coding layer ID. [0107] Consequently, a decoder implementation may implement a bitstream parser extracting the necessary metadata information and VCL associated metadata from the NAL unit sequence 1000; decode the VCL residual coded data sequence to its transformed and quantized values; apply the inverse linear transform and recover the residual significant content; perform intra or inter prediction to reconstruct each coding unit luminance and chromatic representation; apply additional filtering and error concealment procedures; reproduce the raw picture sequence representation as video playback. [0108] These operations and procedures may happen successively, as listed, or in parallel depending on a decoder specific implementation. One skilled in the art should recognize that similar high-level operations are applicable to other family of video codecs, such as for instance AV1 codec. [0109] To aid the disclosure herein, metadata support in video codecs will now be briefly described. [0110] Modern video codecs, e.g., H.264, H.265, AV1, or alternatively, H.266, provide byte-aligned transport mechanisms for metadata within the video coded elementary stream, or alternatively, bitstream. Such non-video coded data is alternatively referred to in a video coding context as metadata since the comprised information is not related to alter the luma or chroma of the decoded frame, or alternatively, picture. This metadata is encapsulated as well into NALUs as SEI messages for H.26x MPEG family of codecs and in OBUs as OBU metadata for AV1. [0111] In case of each codec the metadata may have different types associated with different syntax and semantics specified additionally in the codec specifications, e.g., (ITU-T standard H.264 (08/2021), ITU-T standard H.265 V8 (08/2021), ITU-T standard H.266 V4 (04/2022), Rivaz, p & Haughton, (2018) in the paper titled “AV1 Bitstream & Decoding Process Specification” from the Alliance for Open Media, 182), or alternatively, in ITU specifications of metadata types such as for instance in ITU-T Series H specification V8 (08/2020) titled “Series H: Audiovisual and Multimedia Systems, Infrastructure of audiovisual services – coding of moving video: versatile supplemental enhancement information messages for coded video bitstreams”, or ITU-T Recommendation T.35, titled “Terminal provider codes notification form: available SMM920220294-GR-NP information regarding the identification of national authorities for the assignment of ITU-T recommendation T.35 terminal provider codes”. Nevertheless, in none of the specifications the user data SEI message, or alternatively, OBU metadata user private data format is specified. Furthermore, all the herein discussed video codecs and their associated encoders and decoders allow the exposure via dedicated interfaces of the user data metadata type to the application layer by passthrough of either NALUs SEI messages, or alternatively, OBUs carrying OBU metadata to the application layer. [0112] In current WebRTC specification the supported and mandatory video media codecs are AVC/H.264 with its constrained baseline profile and VP8, with additional optional support for VP9. Given the increasing support of AV1 and H.265 in the main browser engines (e.g., Chromium as used by Google Chrome and Microsoft Edge, or alternatively, Mozilla as used by Mozilla Firefox), it is expected that WebRTC specification will soon evolve to additionally include AV1 support, and potentially also optional support for a restrained profile of H.265. On the other hand, in 3GPP up to Release 18, H.264 and H.265 are the default video codecs specified and supported, whereas support for H.266 and AV1 is considered for further study for the next releases. [0113] This disclosure leverages these facts regarding user data metadata and video codecs support to the benefit of proposing a new real-time, in-band transport mechanism for interaction and immersion metadata associated with XR applications and their video streams, that is relevant to split-rendering. [0114] Split rendering and split rendering architectures are studied in 3GPP, e.g., 3GPP Technical Specification TS 26.565 v0.3.0 titled “Split Rendering Media Service Enabler”, and 3GPP Technical Specification 26.506 v1.1.0 titled “5G Real-time Media Communication Architecture”. Split rendering has the benefit enabling energy savings and high performance, in addition to interactive and immersive XR applications. Split rendering allows for the enhancement of the user experience by providing access to advanced and sophisticated rendering which would be otherwise not possible, or alternatively, require very high energy consumption on the AR/VR glasses, or alternatively, a 5G tethered UE. [0115] In split rendering all or parts of the 3D scene are rendered remotely on an Edge Application Server (EAS), or alternatively, a Split Rendering Server (SRS) placed within the Edge Data Network (EDN). The results of the split rendering process are streamed down to the 5G UE (if tethered AR architecture is considered) or to XR glasses for display. The spectrum of split rendering operations may be wide, ranging from full pre- SMM920220294-GR-NP rendering on the edge to offloading partial, processing-extensive rendering operations to the edge. This variety is ranging from frames corresponding to 2D with single eye buffer rendering, 2D with dual eye buffers rendering, 2D with depth information rendering, and 3D scene rendering. [0116] In case of 2D with single eye buffer renderings, the edge application server would produce a single 2D video rendering of the visual scene. Depending on the configuration of the UE, a 2D rendering with two eye buffers and an appropriate projection (e.g., equirectangular) may be needed. Other supporting streams encoding additional information, such as depth or transparency may be added too to the 2D rendering. On the UE a scene compositor layers the available streams and composes a primitive image buffer which exchanged with the XR runtime over swapchains for display on the AR glasses. On the other hand, in case of 3D content partial rendering offloading would delegate some rendering operations to the EAS, while still receiving a 3D scene at the UE. An example would be to offload light baking of the scene textures to the edge, which may be performed with techniques like ray tracing. [0117] In terms of traffic, the split-rendering UL traffic pattern can be summarized as: the UE, or alternatively, the AR glasses stream the pose predictions to the SRS at the EDN. This traffic may additionally contain an associated AR UL video stream depending on the type of applications (e.g., multi-party AR conferencing, interactive and immersive classroom AR etc.) [0118] In term of traffic, the split-rendering DL traffic pattern can be summarized as: the UE, or alternatively, the AR glasses receive in return the rendered video media for the display. [0119] Typically, the XR runtime benefits from the rendered media to be passed together with the associated pose used for rendering to perform proper scene composition and display. For instance, the XR runtime may need to perform pose correction based on late stage reprojection, or alternatively, asynchronous time warping to match the current display time. Additional information may be needed by the XR runtime, e.g., XR space handles or references and XR timestamps associated with the SRS rendering operations, for spatial and temporal synchronization. [0120] As such, the determination of split-rendering transport and signaling mechanisms are important for XR interactive and immersive applications and these are treated herein. [0121] The solution treats the usage of a user data SEI message (e.g., H.264, H.265, H.266), or alternatively, OBU metadata (e.g., AV1) for the transport of interaction and SMM920220294-GR-NP immersion metadata associated with an XR application in either UL or DL. The format used for the payload of such user data is generic and may comprise of at least two fields. The first field is an identifier determining the syntax and semantics of the user data format, and the second field contains the user data information as a payload encoded according to the format identified by the first field. The first field is in some embodiments a UUID which needs to be signaled by a source sender to a corresponding remote receiver to allow the receiver to parse and process the user data information. This disclosure particularly specifies three signaling mechanisms which enable the usage of such user data over SEI messages, or alternatively, OBU metadata for interactive and immersive applications backed by split-rendering at the edge. The proposed signaling mechanism for the user data identifier, e.g., UUID, are: application-based signaling over application plane; network-supported signaling via network application function over control plane; and SDP attribute based in-band signaling over user plane. [0122] The user data identifier, e.g., UUID, may be in some embodiments dependent on at least one of the media capabilities of a sender, a receiver, and a split-rendering EAS, and as such its negotiation and signaling is performed per media session of an interactive and immersive application during session initialization, or alternatively, during session update. [0123] The disclosure herein provides an apparatus for wireless communication, comprising a processor; and a memory coupled with the processor, the processor configured to cause the apparatus to: determine a media configuration for split-rendering of a video media flow, wherein the media configuration comprises one or more parameters indicating an encoded video stream of the video media flow comprises, as non-video coded metadata, one or more data units of multimedia immersion and interaction data; signal the media configuration to a second apparatus; establish, with the second apparatus, based at least in part on the media configuration, a multimedia split- rendering content delivery session comprising the video media flow; and use, for split- rendering the video media flow, the one or more data units of multimedia immersion and interaction data. [0124] In some embodiments, the non-video coded metadata comprises: a first field comprising an identifier for a syntax and semantics representation format of the one or more data units of multimedia immersion and interaction data; and a second field comprising the one or more data units of multimedia immersion and interaction data, SMM920220294-GR-NP encoded according to the syntax and semantics representation format corresponding to the identifier of the first field. [0125] In some embodiments, the identifier is a universally unique identifier ‘UUID’ indication. [0126] In some embodiments, the UUID is unique to a specific application or session, or the UUID is globally unique. The UUID may be compliant with the ISO-IEC-11578 ANNEX A format and ISO-IEC 9834-8 Version 4 UUID, i.e., randomly generated UUID, or alike. The term ‘session’ comprises of a temporary and interactive, i.e., updatable, set of configurations and rules, e.g., media formats and codecs, network configuration, determining the exchange of information, including media content, between two or more endpoints connected over a network. [0127] In some embodiments, the processor is configured to cause the apparatus to determine the media configuration by causing the apparatus to: determine the media configuration for a plurality of video media flows having respective encoded video streams and respective non-video coded metadata, wherein the one or more parameters of the media configuration map the identifiers of the first fields of the respective non- video coded metadata, to their respective video media flows. [0128] In some embodiments, the one or more parameters of the media configuration map the first fields of the respective non-video coded metadata, to their respective video media flows, based on at least one of: an application specific stream mapping; a 5-tuple indication; and a media flow description attribute. For instance, a 5-tuple may describe an IP flow comprising of IP source address, IP destination address, source port, destination port, protocol identifier. A media description under SDP, may be a media flow association to one or more UUIDs as provided in the SDP defined media description attribute. [0129] In some embodiments, the processor is configured to cause the apparatus to signal the media configuration over at least one of: an application interface (which may preferably be between an application service provider ‘ASP’ of the apparatus, and a split- rendering aware application of the second apparatus); a control plane interface (preferably between a real-time communications application function ‘RTC AF’ of the apparatus, and a media session handler ‘MSH’ of the second apparatus); and a user plane interface (preferably between a split-rendering server ‘SRS’ of the apparatus, and a split- rendering client ‘SRC’ of the second apparatus). The control plane interface may be a SMM920220294-GR-NP RTC-5 reference interface in 5GS; user plane interface may be SR-4, RTC-4, or may use SR-4m media centric interfacing. [0130] In some embodiments, the encoded video stream is encoded/decoded using at least one video codec selected from the list of video codecs consisting of: H.264 video codec specification; H.265 video codec specification; H.266 video codec specification; and AV1 video codec specification. Other video codecs specification relying in part of said specification may also apply, e.g., OMAF, V-PCC or alike. OMAF encodes omnidirectional video content and it comprises at least one video stream encoded with AVC and HEVC, V-PCC encodes 2D projected 3D video and it comprises a video stream encoding the projected 2D flat frames by means of AVC and HEVC. [0131] In some embodiments, the video codec comprises the H.264, H.265, or H.266 codecs, and the non-video coded metadata is encapsulated as a payload of user data in one or more supplemental enhancement information ‘SEI’ messages of the type ‘user data unregistered’; and/or the video codec comprises the AV1 codec, and the non-video coded metadata is encapsulated as a payload of user data in one or more metadata open bitstream units ‘OBUs’ of type ‘unregistered user private data’. For SEI messages the payload type may equal 5, furthermore the SEI message may be prefixed or suffixed to a NALU. For OBUS, the OBU metadata_type may be ‘X’, where X can be any of 6-31. [0132] In some embodiments, the one or more data units of multimedia immersion and interaction data comprise immersion and interaction data selected from the list consisting of: a user viewpoint data; a user field of view data; a user pose/orientation data; a user gesture tracking data; a user body tracking data; a user facial feature tracking data; a user action and/or user input data; a split rendering pose and spatial information; and an augmented reality object representation, comprising of at least one of a graphical description of an object and an object positional anchor. [0133] In some embodiments, the one or more data units of multimedia immersion and interaction data comprises extended reality ‘XR’ multimedia immersion and interaction data. [0134] In some embodiments, the one or more data units of multimedia immersion and interaction data are from one or more media sources selected from the list of media sources consisting of: one or more physical dedicated controllers; one or more red green blue ‘RGB’ cameras; one or more RGB-depth ‘RGBD’ cameras; one or more infrared ‘IR’ cameras; one or more microphones; and one or more haptic transducers. SMM920220294-GR-NP [0135] In some embodiments the processor is configured to cause the apparatus to use, for split-rendering the video media flow, the one or more data units of multimedia immersion and interaction data, for the purposes of: a late stage reprojection at a split- rendering client ‘SRC’ for displaying one or more rendered frames matching, a latest user pose or orientation information; a partial or full pre-rendering of one or more frames at a split-rendering server ‘SRS’; and/or an estimate, at a SRS, of a most probable user pose and orientation, associated with an expected display time for the one or more frames being partially or fully pre-rendered. [0136] In some embodiments, the processor is configured to cause the apparatus to signal the media configuration upon initiation of the multimedia split-rendering content delivery session and/or when updating the multimedia split-rendering content delivery session. [0137] In some embodiments, the processor is further configured to cause the apparatus to determine the media configuration based on at least one of: an application configuration of an application hosted on the second apparatus, wherein the application configuration comprises one or more media capabilities of the second apparatus; and/or an application service provider ‘ASP’ configuration, provisioned to at least one of: a real- time communications application function ‘RTC AF’; a provisioning function; a split- rendering application function ‘SR AF’; and/or a configuration function; [0138] In some embodiments the application configuration may be preconfigured with supported UUIDs; and/or transport may be automatically enabled if a UUID is received. [0139] In some embodiments, the apparatus is a network entity/node, whereas the second apparatus is a UE. [0140] Figure 11 illustrates an embodiment 1100 of a method of wireless communication in a wireless communication system. [0141] A first step 1110 comprises, determining a media configuration for split- rendering of a video media flow, wherein the media configuration comprises one or more parameters indicating an encoded video stream of the video media flow comprises, as non-video coded metadata, one or more data units of multimedia immersion and interaction data. [0142] A further step 1120 comprises, signaling the media configuration to a second apparatus. SMM920220294-GR-NP [0143] A further step 1130 comprises establishing, with the second apparatus, based at least in part on the media configuration, a multimedia split-rendering content delivery session comprising the video media flow. [0144] A further step 1140 comprises using, for split-rendering the video media flow, the one or more data units of multimedia immersion and interaction data. [0145] In certain embodiments, the method 1100 may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like. [0146] In some embodiments, the non-video coded metadata comprises: a first field comprising an identifier for a syntax and semantics representation format of the one or more data units of multimedia immersion and interaction data; and a second field comprising the one or more data units of multimedia immersion and interaction data, encoded according to the syntax and semantics representation format corresponding to the identifier of the first field. [0147] In some embodiments, the identifier is a universally unique identifier ‘UUID’ indication. [0148] In some embodiments, the UUID is unique to a specific application or session, or the UUID is globally unique. The UUID may be compliant with ISO-IEC-11578 ANNEX A format and ISO-IEC 9834-8 Version 4 UUID, i.e., randomly generated UUID, or alike. A ‘session’ comprises of a temporary and interactive, i.e., updatable, set of configurations and rules, e.g., media formats and codecs, network configuration, determining the exchange of information, including media content, between two or more endpoints connected over a network. [0149] In some embodiments, the determining the media configuration, comprises: determining the media configuration for a plurality of video media flows comprising respective encoded video streams and respective non-video coded metadata, wherein the one or more parameters of the media configuration map the identifiers of the first fields of the respective non-video coded metadata, to their respective video media flows. [0150] In some embodiments, the one or more parameters of the media configuration map the first fields of the respective non-video coded metadata, to their respective video media flows, based on at least one of: an application specific stream mapping; a 5-tuple indication; and a media flow description attribute. A 5-tuple may describe an IP flow comprising of IP source address, IP destination address, source port, destination port, protocol identifier, for instance. A media description under SDP may comprise a media SMM920220294-GR-NP flow association to one or more UUIDs as provided in the SDP media description attribute etc. [0151] In some embodiments, the signaling the media configuration comprises signaling over at least one of: an application interface (preferably between an application service provider ‘ASP’ of the apparatus, and a split-rendering aware application of the second apparatus); a control plane interface (preferably between a real-time communications application function ‘RTC AF’ of the apparatus, and a media session handler ‘MSH’ of the second apparatus); and a user plane interface (preferably between a split-rendering server ‘SRS’ of the apparatus, and a split-rendering client ‘SRC’ of the second apparatus). The control plane interface may be RTC-5 reference interface in 5GS; user plane interface may be SR-4, RTC-4, or may use SR-4m media centric interfacing. [0152] In some embodiments, the encoded video stream is encoded/decoded using at least one video codec selected from the list of video codecs consisting of: H.264 video codec specification; H.265 video codec specification; H.266 video codec specification; and AV1 video codec specification. Other video codecs specification relying in part of said specification may also apply, e.g., OMAF, V-PCC or alike. OMAF encodes omnidirectional video content and it comprises at least one video stream encoded with AVC and HEVC, V-PCC encodes 2D projected 3D video and it comprises a video stream encoding the projected 2D flat frames by means of AVC and HEVC. [0153] In some embodiments, the video codec comprises the H.264, H.265, or H.266 codecs, and the non-video coded metadata is encapsulated as a payload of user data in one or more supplemental enhancement information ‘SEI’ messages of the type ‘user data unregistered’; and/or the video codec comprises the AV1 codec, and the non-video coded metadata is encapsulated as a payload of user data in one or more metadata open bitstream units ‘OBUs’ of type ‘unregistered user private data’. For SEI messaging, the payload type may be 5, furthermore the SEI message may be prefixed or suffixed to a NALU. For OBUs, the OBU metadata_type may be ’X’, where X can be any of 6-31. [0154] In some embodiments, the one or more data units of multimedia immersion and interaction data comprise immersion and interaction data selected from the list consisting of: a user viewpoint data; a user field of view data; a user pose/orientation data; a user gesture tracking data; a user body tracking data; a user facial feature tracking data; a user action and/or user input data; a split rendering pose and spatial information; and an augmented reality object representation, comprising of at least one of a graphical description of an object and an object positional anchor. SMM920220294-GR-NP [0155] In some embodiments, the one or more data units of multimedia immersion and interaction data comprise extended reality ‘XR’ multimedia immersion and interaction data. [0156] In some embodiments the one or more data units of multimedia immersion and interaction data are from one or more media sources selected from the list of media sources consisting of: one or more physical dedicated controllers; one or more red green blue ‘RGB’ cameras; one or more RGB-depth ‘RGBD’ cameras; one or more infrared ‘IR’ cameras; one or more microphones; and one or more haptic transducers. [0157] Some embodiments comprise using, for split-rendering the video media flow, the one or more data units of multimedia immersion and interaction data, for the purposes of: a late stage reprojection at a split-rendering client ‘SRC’ for displaying one or more rendered frames matching, a latest user pose or orientation information; a partial or full pre-rendering of one or more frames at a split-rendering server ‘SRS’; and/or an estimate, at a SRS, of a most probable user pose and orientation, associated with an expected display time for the one or more frames being partially or fully pre-rendered. [0158] Some embodiments comprise signaling the media configuration upon initiation of the multimedia split-rendering content delivery session and/or when updating the multimedia split-rendering content delivery session. [0159] In some embodiments, the determining the media configuration comprises determining the media configuration based on at least one of: an application configuration of an application hosted on the second apparatus, wherein the application configuration comprises one or more media capabilities of second apparatus; and/or an application service provider ‘ASP’ configuration, provisioned to at least one of a real- time communications application function ‘RTC AF’; a provisioning function; a split- rendering application function ‘SR AF’; and/or a configuration function; The application configuration may be preconfigured with supported UUIDs and/or transport may be automatically enabled if a UUID is received. [0160] In some embodiments, the method is performed by a network entity/node, and the second apparatus is a UE. [0161] The disclosure herein further provides an apparatus for wireless communication in a wireless communication system, comprising a processor; and a memory coupled with the processor, the processor configured to cause the apparatus to: receive, from a first apparatus, a media configuration for split-rendering of a video media flow, wherein the media configuration comprises one or more parameters indicating an encoded video SMM920220294-GR-NP stream of the video media flow comprises, as non-video coded metadata, one or more data units of multimedia immersion and interaction data; configure the apparatus, using the media configuration, to receive the video media flow; decode the encoded video stream of the video media flow, wherein the decoding comprises extracting the non- video coded metadata; and consume, from the non-video coded metadata, the one or more data units of multimedia immersion and interaction data. [0162] In some embodiments the non-video coded metadata comprises: a first field comprising an identifier for a syntax and semantics representation format of the one or more data units of multimedia immersion and interaction data; and a second field comprising the one or more data units of multimedia immersion and interaction data, encoded according to the syntax and semantics representation format corresponding to the identifier of the first field. [0163] In some embodiments the identifier is a universally unique identifier ‘UUID’ indication. [0164] In some embodiments the UUID is unique to a specific application or session, or the UUID is globally unique. The UUID may be compliant with ISO-IEC-11578 ANNEX A format and ISO-IEC 9834-8 Version 4 UUID, i.e., randomly generated UUID, or alike. A ‘session’ comprises of a temporary and interactive, i.e., updatable, set of configurations and rules, e.g., media formats and codecs, network configuration, determining the exchange of information, including media content, between two or more endpoints connected over a network. [0165] In some embodiments the media configuration is for a plurality of video media flows comprising respective encoded video streams and respective non-video coded metadata, wherein the one or more parameters of the media configuration map the identifiers of the first fields of the respective non-video coded metadata, to their respective video media flows. [0166] In some embodiments the one or more parameters of the media configuration map the first fields of the respective non-video coded metadata, to their respective video media flows, based on at least one of: an application specific stream mapping; a 5-tuple indication; and a media flow description attribute. A 5-tuple may describe an IP flow comprising of IP source address, IP destination address, source port, destination port, protocol identifier. A media description under SDP may be a media flow association to one or more UUIDs as provided in the SDP media description attribute etc. SMM920220294-GR-NP [0167] In some embodiments, the processor is configured to cause the apparatus to receive the media configuration over at least one of: an application interface (preferably between an application service provider ‘ASP’ of the apparatus, and a split-rendering aware application of the second apparatus); a control plane interface (preferably between a real-time communications application function ‘RTC AF’ of the apparatus, and a media session handler ‘MSH’ of the second apparatus); and a user plane interface (preferably between a split-rendering server ‘SRS’ of the apparatus, and a split-rendering client ‘SRC’ of the second apparatus). The control plane interface may be a RTC-5 reference interface in 5GS. The user plane interface may be SR-4, RTC-4, or may use SR-4m media centric interfacing. [0168] In some embodiments, the encoded video stream is encoded/decoded using at least one video codec selected from the list of video codecs consisting of: H.264 video codec specification; H.265 video codec specification; H.266 video codec specification; and AV1 video codec specification. Other video codecs specification relying in part of said specification may also apply, e.g., OMAF, V-PCC or alike. OMAF encodes omnidirectional video content and it comprises at least one video stream encoded with AVC and HEVC, V-PCC encodes 2D projected 3D video and it comprises a video stream encoding the projected 2D flat frames by means of AVC and HEVC. [0169] In some embodiments, the video codec comprises the H.264, H.265, or H.266 codecs, and the non-video coded metadata is encapsulated as a payload of user data in one or more supplemental enhancement information ‘SEI’ messages of the type ‘user data unregistered’; and/or the video codec comprises the AV1 codec, and the non-video coded metadata is encapsulated as a payload of user data in one or more metadata open bitstream units ‘OBUs’ of type ‘unregistered user private data’. For SEI messaging, the payload type may be 5, furthermore the SEI message may be prefixed or suffixed to a NALU. For OBU, the OBU metadata_type may be X, where X can be any of 6-31. [0170] In some embodiments, the one or more data units of multimedia immersion and interaction data comprise immersion and interaction data selected from the list consisting of: a user viewpoint data; a user field of view data; a user pose/orientation data; a user gesture tracking data; a user body tracking data; a user facial feature tracking data; a user action and/or user input data; a split rendering pose and spatial information; and an augmented reality object representation, comprising of at least one of a graphical description of an object and an object positional anchor. SMM920220294-GR-NP [0171] In some embodiments, the one or more data units of multimedia immersion and interaction data comprise extended reality ‘XR’ multimedia immersion and interaction data. [0172] In some embodiments, the one or more data units of multimedia immersion and interaction data are from one or more media sources selected from the list of media sources consisting of: one or more physical dedicated controllers; one or more red green blue ‘RGB’ cameras; one or more RGB-depth ‘RGBD’ cameras; one or more infrared ‘IR’ cameras; one or more microphones; and one or more haptic transducers. [0173] In some embodiments, the processor is configured to cause the apparatus to use, for split-rendering the video media flow, the one or more data units of multimedia immersion and interaction data, for the purposes of: a late stage reprojection at a split- rendering client ‘SRC’ for displaying one or more rendered frames matching, a latest user pose or orientation information. [0174] In some embodiments, the processor is configured to cause the apparatus to receive the media configuration upon initiation of the multimedia split-rendering content delivery session and/or when updating the multimedia split-rendering content delivery session. [0175] In some embodiments, the media configuration is based on at least one of: an application configuration of an application hosted on the apparatus, wherein the application configuration comprises one or more media capabilities of the apparatus; and/or an application service provider ‘ASP’ configuration, provisioned to at least one of: a real-time communications application function ‘RTC AF’; a provisioning function; [0176] a split-rendering application function ‘SR AF’; and/or a configuration function. The application configuration may be preconfigured with supported UUIDs and/or transport may be automatically enabled if a UUID is received. [0177] In some embodiments, the first apparatus is a network entity/node, whereas the apparatus is a UE. [0178] Figure 12 illustrates an embodiment of a method 1200 for wireless communication. [0179] A first step 1210 comprises receiving, from a first apparatus, a media configuration for split-rendering of a video media flow, wherein the media configuration comprises one or more parameters indicating an encoded video stream of the video media flow comprises, as non-video coded metadata, one or more data units of multimedia immersion and interaction data. SMM920220294-GR-NP [0180] A further step 1220 comprises configuring the apparatus, using the media configuration, to receive the video media flow. [0181] A further step 1230 comprises decoding the encoded video stream of the video media flow, wherein the decoding comprises extracting the non-video coded metadata. [0182] A further step 1240 comprises consuming, from the non-video coded metadata, the one or more data units of multimedia immersion and interaction data. [0183] In certain embodiments, the method 1200 may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like. [0184] In some embodiments, the non-video coded metadata comprises: a first field comprising an identifier for a syntax and semantics representation format of the one or more data units of multimedia immersion and interaction data; and a second field comprising the one or more data units of multimedia immersion and interaction data, encoded according to the syntax and semantics representation format corresponding to the identifier of the first field. [0185] In some embodiments, the identifier is a universally unique identifier ‘UUID’ indication. [0186] In some embodiments, the UUID is unique to a specific application or session, or the UUID is globally unique. [0187] The UUID may be compliant with the ISO-IEC-11578 ANNEX A format and ISO-IEC 9834-8 Version 4 UUID, i.e., randomly generated UUID, or alike. A ‘session’ comprises of a temporary and interactive, i.e., updatable, set of configurations and rules, e.g., media formats and codecs, network configuration, determining the exchange of information, including media content, between two or more endpoints connected over a network. [0188] In some embodiment, the media configuration is for a plurality of video media flows comprising respective encoded video streams and respective non-video coded metadata, wherein the one or more parameters of the media configuration map the identifiers of the first fields of the respective non-video coded metadata, to their respective video media flows. [0189] In some embodiments the one or more parameters of the media configuration map the first fields of the respective non-video coded metadata, to their respective video media flows, based on at least one of: an application specific stream mapping; a 5-tuple indication; and a media flow description attribute. SMM920220294-GR-NP [0190] A 5-tuple may describe an IP flow comprising of IP source address, IP destination address, source port, destination port, protocol identifier. A media description under SDP may comprise a media flow association to a description attribute as provided in the SDP media description attribute etc. [0191] In some embodiments, the receiving the media configuration comprises receiving over at least one of: an application interface (preferably between an application service provider ‘ASP’ of the apparatus, and a split-rendering aware application of the second apparatus); a control plane interface (preferably between a real-time communications application function ‘RTC AF’ of the apparatus, and a media session handler ‘MSH’ of the second apparatus); and a user plane interface (preferably between a split-rendering server ‘SRS’ of the apparatus, and a split-rendering client ‘SRC’ of the second apparatus). [0192] In some embodiments, the control plane interface may be RTC-5 reference interface in 5GS. The user plane interface may be SR-4, RTC-4, or may use SR-4m media centric interfacing. [0193] In some embodiments, the decoding uses at least one video codec selected from the list of video codecs consisting of: H.264 video codec specification; H.265 video codec specification; H.266 video codec specification; and AV1 video codec specification. Some other video codecs’ specification relying in part of said specification may also apply, e.g., OMAF, V-PCC or alike. OMAF encodes omnidirectional video content and it comprises at least one video stream encoded with AVC and HEVC, V-PCC encodes 2D projected 3D video and it comprises a video stream encoding the projected 2D flat frames by means of AVC and HEVC. [0194] In some embodiments, the video codec comprises the H.264, H.265, or H.266 codecs, and the non-video coded metadata is encapsulated as a payload of user data in one or more supplemental enhancement information ‘SEI’ messages of the type ‘user data unregistered’; and/or the video codec comprises the AV1 codec, and the non-video coded metadata is encapsulated as a payload of user data in one or more metadata open bitstream units ‘OBUs’ of type ‘unregistered user private data’. For SEI messaging the payload type may be 5, furthermore the SEI message may be prefixed or suffixed to a NALU. For OBU, the OBU metadata_type may be ‘X’, where X can be any of 6-31. [0195] In some embodiments, the one or more data units of multimedia immersion and interaction data comprise immersion and interaction data selected from the list consisting of: a user viewpoint data; a user field of view data; a user pose/orientation data; a user SMM920220294-GR-NP gesture tracking data; a user body tracking data; a user facial feature tracking data; a user action and/or user input data; a split rendering pose and spatial information; and an augmented reality object representation, comprising of at least one of a graphical description of an object and an object positional anchor. [0196] In some embodiments, the one or more data units of multimedia immersion and interaction data comprise extended reality ‘XR’ multimedia immersion and interaction data. [0197] In some embodiments, the one or more data units of multimedia immersion and interaction data are from one or more media sources selected from the list of media sources consisting of: one or more physical dedicated controllers; one or more red green blue ‘RGB’ cameras; one or more RGB-depth ‘RGBD’ cameras; one or more infrared ‘IR’ cameras; one or more microphones; and one or more haptic transducers. [0198] Some embodiments comprise using, for split-rendering the video media flow, the one or more data units of multimedia immersion and interaction data, for the purposes of: a late stage reprojection at a split-rendering client ‘SRC’ for displaying one or more rendered frames matching, a latest user pose or orientation information. [0199] Some embodiments comprising receiving the media configuration upon initiation of the multimedia split-rendering content delivery session and/or when updating the multimedia split-rendering content delivery session. [0200] In some embodiments, the media configuration is based on at least one of: an application configuration of an application hosted on the apparatus, wherein the application configuration comprises one or more media capabilities of the apparatus; and/or an application service provider ‘ASP’ configuration, provisioned to at least one of a real-time communications application function ‘RTC AF’; a provisioning function; a split-rendering application function ‘SR AF’; and/or a configuration function. [0201] In some embodiments the application configuration may be preconfigured with supported UUIDs and/or transport may be automatically enabled if a UUID is received. [0202] In some embodiments the first apparatus is a network entity/node, whereas the apparatus is a UE. [0203] Aspects of embodiments of interaction and immersion user data transport over a video elementary stream as non-video coded metadata, will now be described in greater detail, with reference to a video source of an XR application. In the sequel, the terms interaction and immersion user data, interaction and immersion metadata, non-video SMM920220294-GR-NP coded user data, non-video coded embedded user data, non-video coded embedded metadata, or simply metadata are used to this end interchangeably. [0204] Figure 13a provides an illustration of an embodiment 1300 of a split-rendering architecture for interactive and immersive multimedia applications, that is supported by split-rendering at the edge. The embodiment 1300 shows a UE 1310, an EN 1320 and a DN 1330 interfacing over various interfaces. [0205] The UE 1310 is illustrated as comprising a split-rendering-aware application client 1311,an MSH 1312 which may comprise an EEC 1312a, a split-rendering client (SRC) 1313, and an XR runtime 1314. The split-rendering-aware application client 1311 interfaces with XR runtime 1314. The split-rendering-aware application client 1311 interfaces with SRC 1313 over, for instance, SR-7. The split-rendering-aware application client 1311 interfaces with MSH 1312 over, for instance, SR-6, and may interface with EEC 1312a over EDGE-5. The MSH 1312 interfaces with SRC 1313 over, for instance, SR-7 and SR-6. The SRC 1313 interfaces with XR runtime 1314. [0206] The EN 1320 is illustrated as comprising a SR AF 1321 comprising a configuration function 1321a, a provisioning function 1321b, and an EES 1321c. The EES may be distributed over multiple instances 1321c which interface with each other over EDGE-9, for instance. The EN 1320 is further illustrated as comprising an RTC AS 1322, comprising a signaling server 1322a, and an SRS 1322b which may comprise EAS. The SR AF 1321 interfaces with RTC AS 1322 over, for instance, SR-3. The EES 1321c of SR AF 1321 interfaces with SRS 1322b comprising EAS over EDGE-3. [0207] The DN 1330 is illustrated as comprising an ASP 1331. The ASP 1331 interfaces with provisioning function 1321b of SR AF 1321 over SR-1. The ASP 1331 interfaces with SRS 1322b comprising EAS over, for instance, SR-2. [0208] The split-rendering-aware application client 1311 of UE 1310 interfaces with ASP 1331 of DN 1330 over, for instance, SR-8. The MSH 1312 of UE 1310 interfaces with SR AF 1321 of EN 1320 over, for instance, SR-5. The EEC 1312a of MSH 1312 may further interface with EES 1321c of SR AF 1321 over EDGE 1 and/or EDGE 4 (for instance via an ECS). The SRC 1313 of UE 1310 interfaces with the SRS 1322b and signaling server 1322a of RTC AS 1322 in EN 1320, over, for instance, SR-4 (comprised of SR-4m, SR-4s, for instance). [0209] The embodiment 1300 if Figure 13 is a split-rendering architecture for interactive and immersive multimedia application, showing the architecture, functions and SMM920220294-GR-NP interfaces. The related split-rendering flows (e.g., provisioning, split management and media delivery) will now be described in relation to Figure 13b. [0210] Figure 13b provides an illustration of the high-level split-rendering flows in an embodiment. Illustrated in the figure are the split-rendering-aware application 1311, MSH 1312, SRC 1313 (illustrated as comprising a scene manager, XR source manager and media access function), SRS 1322b, SR AF 1321, application service provider 1331, and XR runtime 1314. [0211] The main steps for split-rendering and associated interfaces are described below, whereby the split-rendering application function (SR AF) is in some embodiments an instantiation of the generic real-time communications application function (RTC AF) cf. 3GPP Technical Specification 26.506 v1.1.0 titled “5G Real-time Media Communication Architecture. [0212] In a first step 1301, the ASP 1331 provisions the SR AF 1321 via a provisioning request for a split-rendering management session. The provisioning may be performed in some embodiments over the SR-1 reference point, or alternatively, SR-1 APIs. The SR AF- 1321 determines a split-rendering configuration based in part on the information received from the ASP 1331. In some embodiments, an edge enabled SR AF 1321 may support additionally Edge Enabler Server (EES). In some implementations the EES logic may be distributed over multiple edge DNs, whereby the context and coordination of the distributed EES instances is coordinated over the EDGE-9 interface. The EES may further communicate with and register EAS split-rendering functionality. In some embodiments, the split-rendering server 1322b may represent an instantiation of the EAS for split-rendering and may communicate with the SR AF 1321 over the EDGE-3 interface. This may imply for example registration/deregistration of EAS instances, access network capabilities exposure, QoS management notifications and reports (e.g., bitrate adaptation notifications etc.). This step 1301 is illustrated as “split rendering provisioning”. [0213] In a further step 1302, the split-rendering-aware application 1311 acquires the Service Access Information (SAI) from the ASP 1331. The SAI is a set of parameters and addresses that are needed by a client to activate the reception of one or more DL/UL media sessions, perform dynamic policy invocation, consumption/metrics reporting, and request SR AF 1321 assistance. The acquisition of SAI may be performed in some applications by means of control plane signaling over SR-5 (or alike RTC-5) from the SR AF 1321 to the MSH 1312 followed by exposure of the acquired SAI by the MSH 1312 SMM920220294-GR-NP to the application 1311 over SR-6 (or alike RTC-6) interface. The SR-5 interface may in some embodiments comprise EDGE-1 functionality aiding an Edge Enabler Client instantiated by the MSH 1312 with the registration to the EES at the SR AF 1321, and respectively, EDGE-4 functionality enabling the EEC to access configuration of edge resources (e.g., EAS configuration information) from an Edge Configuration Server (ECS). In other embodiments, the SAI may be exposed directly by the ASP 1331 (as acquired after the SR-1 provisioning invocation) over the application specific SR-8 (or similar RTC-8) interface. This step 1302 is illustrated as “service access information (SAI) acquisition”. [0214] Next follows the split management procedure. This can be triggered in some embodiments by the client as illustrated in step 1303a, i.e., by the split-rendering-aware application 1311, and in some other embodiments by the ASP 1331 as illustrated in step 1303b. [0215] In a first embodiment where the split management is triggered by the client, the step 1303a proceeds with the application 1311 requesting the split-rendering assistance to the UE SRC 1313 over the SR-7 API. The SRC 1313 communicates with the MSH 1312 over the SR-6 API to determine the client media capabilities and functions (e.g., XR runtime API, XR runtime rendering capabilities etc.), as well as available SRS instances as per the SAI configuration. The SRC 1313 then negotiates the media-centric split configuration with the SRS 1322b at the edge. This may imply in some embodiments the split management negotiation via SDP procedures or dedicated split-rendering management signaling (e.g., as add-on to WebRTC specific signaling etc.). For instance, in case of SDP based signaling the split is negotiated between the SRC 1313 and SRS 1322b based on the SDP protocol, whereby the SDP offer/answer procedures are used to determine the media streams, media formats and multiplexing supported by the SRC 1313 and SRS 1322b during the split-rendering session. Post negotiation of the split management, the SRS 1322b acknowledges to the SRC 1313 split configuration over the user plane interface SR-4 (or alike RTC-4), and the split-rendering media delivery session is ready to start. As a result, the SRC 1313 completes the application request for split- rendering over the SR-7 interface. In this first embodiment, the step 1303a is illustrated as “client-driven split management”. [0216] In a second embodiment where the split management is triggered by the SRS 1322b, the step 1303b proceeds with the SRS 1322b requesting the SRC 1313 for a split- rendering session over the SR-4 (or alike RTC-4) interface. In some embodiments, this SMM920220294-GR-NP may be in part achieved over a signaling server functionality (i.e., implemented by a dedicated signaling server or alike), whereas in other embodiments this may be left to an SDP media session negotiation based on offer/answer procedure. Upon receiving the request, the SRC 1313 queries the MSH 1312 about the UE media capabilities given the provisioned split-rendering configuration and available SAI. The MSH 1312 replies to the SRC 1313 over the SR-6 with the available media capabilities and information. The SRC 1313 replies to the SRS 1322b request over the SR-4 (or alike RTC-4) interface, and negotiates the media-centric split management. Once the negotiation concludes, the determined media configuration, media formats and multiplexing associated with the split configuration profile is returned to the SRS 1322b as the acknowledged split-rendering configuration. The SRC 1313 in turn notifies over SR-7 interface (e.g., by a WebSocket or alike asynchronous mechanism) the split-rendering-aware application of the split- rendering configuration and of the fact that the split-rendering session is ready to start. In this second embodiment, the step 1303b is illustrated as “network-driven split management”. [0217] A further step 1304, comprises the media delivery. In some embodiments this includes the establishment of a media delivery split-rendering session by the SRC 1313. In such cases the SRC 1313 may request the SRS 1322b to create a split rendering session given the determined split-rendering configuration profile from the previous step. In some embodiments, the SRC 1313 is formed of at least a scene manager shim functionality, an XR source manager and a media access function. Such an SRC 1313 may thus trigger by means of the scene manager functionality, or alternatively, by means of the MAF functionality the request to the SRS 1322b to create the split rendering session. The SRS 1322b responds to acknowledge the request with a split-rendering description of the split-rendering configuration profile for the session. The SRC 1313 establishes connection to the SRS 1322b and the split-rendering sessions is initiated. In some embodiments, this may apply additional media-centric signaling given a signaling server (e.g., WebRTC over WebSockets or other signaling mechanisms) over SR-4s, as a signaling subinterface of SR-4. Once the session has been established media is served as configured between the SRC 1313 and SRS 1322b over the SR-4 over both UL and DL directions. This step 1304 is illustrated as “media delivery setup”. [0218] A further step 1305 following with a rendering loop. A typical description of the rendering loop for split-rendering includes in some embodiments the SRC 1313 receiving, or alternatively acquiring, from the XR runtime pose information and user SMM920220294-GR-NP actions. In other embodiments, the latter information is complemented by an UL video and/or audio stream (e.g., as for AR conferencing or AR immersive and interactive applications). The pose, user action and any media streams are transmitted in UL to the SRS 1322b over SR-4m (i.e., the user plane media-centric subinterface of SR-4). The SRS 1322b processes the received information, the information in its own service buffer and renders at least in part the contents of the next one or more frames for the split- rendering-aware application. In one embodiment, the SRS 1322b may fuse together one or more pose and user actions to estimate the pose information as close as possible to the expected display time of the frame. In such an embodiment this estimate is used to render, or alternatively, pre-render the next frame. In other embodiments, the SRS 1322b may select the most recent pose information to expected display time of the next frame for the rendering/pre-rendering operation. Next, the SRS 1322b transmits the rendered frames to the SRC 1313 over the SR-4m. In some embodiments, the rendered frames may include additionally interaction and immersion metadata (e.g., pose information, user actions/gestures) that were used by the SRS 1322b to render the frames. This data is sent together with the video encoded rendered frames as parts of a video elementary stream associated of the split-rendering session. In one embodiment, this interaction and immersion metadata may be embedded in the video elementary stream as a user specific metadata, e.g., as SEI messages for H.264, H.265, H.266, or alternatively, as OBU metadata for AV1. The media streams are then transmitted by the SRS 1322b to the SRC 1313. The MAF functions and video codecs decode the media streams and expose the user data embedded into the elementary streams further to the XR runtime 1314, or alternatively, to the split-rendering-aware application 1311 over the SR-7 interface. In an embodiment, the XR runtime 1314 displays the rendered frames and uses the embedded interaction and immersion metadata for late stage reprojection and asynchronous time- warping in correcting any errors between the current pose information to the XR runtime 1314 at the display time, and the SRS 1322b estimated/used pose and user action information during the rendering operation. [0219] In some embodiments, the payload of interaction and immersion metadata being communicated may contain at least two fields. In a first embodiment, the first field acts as a unique type identifier, i.e., a UUID, determining the syntax and semantics of the corresponding information payload located in a second field. In a second embodiment, the second field carries the interaction and immersion data, data embedded as metadata into the video coded elementary stream. In a further embodiment, the second field SMM920220294-GR-NP syntax and semantics may be determined at least in part based on the first field. This may imply an indexed search (e.g., in a list of supported formats for interaction and immersion metadata by a particular communication endpoint, like an UE, or alternatively, an AS), a data repository, or alternatively, registry search (e.g., a query against an Internet based registry of one or more formats for interaction and immersion metadata), or a selection of pre-configured resources (e.g., a selection of an application determined format for interaction and immersion metadata). [0220] An example realization of interaction and immersion metadata for various video codecs (e.g., H.264/H.265/H.266) elementary streams is outlined at a high-level in Figures 14 and 15. [0221] Figure 14 illustrates a representation 1400 of multimedia interaction and immersion user data as metadata within a video coded elementary stream for MPEG H- 26x family of video codecs. Illustrated for a given NAL unit 1410 is a NAL header 1411 and a NAL payload (Raw Bytes) 1412. The NAL payload 1412 comprises a NAL SEI Raw Byte Sequence Payload 1413 which itself comprises first and second SEI messages 1413a and 1413b. The first SEI message 1413a is illustrated as, “UUID = 76994094- c7bd-436b-ac8e-c5205da905cc” and “SEI Message” and “Interaction and Immersion Data”. The second SEI message 1413b is illustrated as, “UUID = 8b6d5df6-be48-40f1- 814d-20ae061d078d” and “SEI Message” and “Interaction and Immersion Data”. [0222] Figure 15 illustrates a representation 1500 of multimedia interaction and immersion user data as metadata within a video coded elementary stream for the AV1 video codec. Illustrated for a given OBU 1510 as a metadata OBU is an OBU header 1511 and OBU payload 1512, the OBU payload 1512 comprising a UUID illustrated as “UUID = 76994094-c7bd-436b-ac8e-c5205da905cc” and further illustrated as “Interaction and Immersion Data”. [0223] In some embodiments the video decoder, e.g., of a MAF within an SRC placed at the UE for DL split-rendering traffic, or alternatively, of an ASP placed at the SRS for UL split-rendering traffic, may passthrough the user data metadata (comprising the interaction an immersion data) embedded into the video elementary stream (e.g., H.264, H.265, H.266, AV1 or alike). In a further embodiment, the video decoder may expose the user data to other functional blocks (e.g., XR runtime, split-rendering-aware application, SRS). This may be in one embodiment implemented based on functional hooks, handlers or callbacks, or alternatively other dedicated interfaces (e.g., raw buffers, event busses etc.) which expose the interaction and immersion metadata payloads based SMM920220294-GR-NP in part on a set of configured UUID filters extracting the relevant payload information. In one example, an SRC is configured for a split-rendering session with media formats over H.264 video elementary streams containing interaction and immersion data of type UUID = 76994094-c7bd-436b-ac8e-c5205da905cc. This SRC will filter and expose the corresponding user data SEI messages passed through by the MAF H.264 decoding instance. In an example this may be done by the SRC over the SR-7 interface, or alternatively, API for any registered consumers, e.g., the split-rendering-aware application, or alternatively, the XR runtime. This may happen in some embodiments once at least one of the one or more UUID have been configured, and the feature of interaction and immersion metadata transport over video coded elementary streams has been enabled. [0224] To enable the filtering and output of interaction and immersion user data corresponding to metadata from video elementary streams, the signaling of UUIDs and associated metadata formats used by split-rendering and carried over the media-centric user plane is therefore necessary. [0225] UUIDs may generically stand as reference to an identifier pertaining to the determination of an interaction and immersion user data type and payload format. If not explicitly specified by examples, a UUID shall be treated herein as a generic identifier. [0226] Certain embodiments will now be described with reference to the signaling utilized. In particular, application-based; network-supported; and SDP-based signaling embodiments will be described. Application-based signaling will be described in the first instance. [0227] In an embodiment, the ASP may signal to a split-rendering-aware application the transport enablement of interaction and immersion user data as metadata over one or more video elementary stream. The media streams are part of the user plane media- centric traffic associated with the DL split-rendering video traffic (e.g., split-rendered video streams comprising single or dual eye buffered of an XR application), or alternatively, with the UL video traffic (e.g., the UL one or more video streams associated with an AR interactive and immersive application). [0228] In one example, an application may activate this feature based on some application specific configuration (e.g., a JSON/YAML/XML media format description and configuration) which is shared between the server, i.e., the ASP application infrastructure, and the client, the split-rendering-aware application. In one example, such a configuration may contain an option equivalent to interaction-metadata-over-video-es= true, SMM920220294-GR-NP to mark the enablement state of the transport of interaction and immersion user data as metadata over the video coded elementary stream. Furthermore, the interface used to convey this configuration may comprise in some examples a proprietary implementation or signaling protocol served over reliable communication channel, such as an SR-8 interface as outlined in Figures 13a and 13b. Some example implementations may use WebSockets, HTTP methods, SCTP or other reliable and acknowledged messaging protocols to communicate this information. [0229] In another embodiment, the configuration may further contain a list of one or more UUIDs supported by the application each corresponding to an interaction and immersion user data payload format. In some embodiments, these formats may be dependent on the XR runtime used by the UE i.e., corresponding to the SRC in the split- rendering setup. For example, this would be the case between an OpenXR hand tracking extension format, and a Microsoft ® HoloLens2 specific hand tracking format. In other embodiments, the formats may be commonly encoded to correspond to one or more XR runtimes, e.g., a set of OpenXR abstract formats valid for one or more devices. In other embodiments, the UUIDs may be corresponding to one or more types of interaction and immersion user data payloads. For instance, a UUID may correspond in some examples to vanilla pose information, e.g., OpenXR’s XrPosef, corresponding to user head tracking, and another UUID may correspond to a set of multiplex poses, locations, and velocities, each corresponding to a hand joint associated with user hand tracking, e.g., OpenXR’s XR_EXT_hand_tracking. [0230] In other embodiments, the application logic may be static with respect to the supported UUIDs and XR runtimes by an application. In such embodiments, the split- rendering-aware application is configured with a static configuration of the supported list of UUIDs. [0231] Furthermore, in another embodiment, the feature of transporting the interaction and immersion user data of a split-rendering application as metadata over video coded elementary streams is automatically enabled when at least one UUID is provided for filtering. [0232] A split-rendering-aware application enabled and configured with the interaction and immersion user data UUIDs may further share its configuration in some embodiments to the SRC. In turn the SRC may apply the received configuration to filter by UUID the corresponding payloads of interaction and immersion user data post video decoding. These data payloads may further be exposed via other interfaces. In one SMM920220294-GR-NP example, the application may use the SR-7 API to configure the SRC with the appropriate configuration on the interaction and immersion user data UUIDs, or alternatively identifiers. [0233] In another embodiment pertaining to UL AR split-rendering traffic, an SRS may request from the SR AF, which may be directly indicated by the ASP, e.g., over SR-1 interface, the configuration information regarding the transport enablement of interaction and immersion user data as metadata over video elementary streams, and the corresponding UUIDs of such metadata types and payloads. [0234] In one embodiment the ASP signaling to application of the configuration information regarding the transport enablement of interaction and immersion user data as metadata over video elementary streams, and the corresponding UUIDs of such metadata types and payloads may additionally comprise the mapping of the UUIDs to video elementary streams. In one example this may be performed by means of an application-specific stream mapping (e.g., based on application media flow identifiers), whereas in another example this may be performed by means of 5-tuple information (src addr, dst addr, srd port, dst port, protocol identifier) of the available media flows. [0235] Embodiments pertaining to network-supported signaling will now be described. In an embodiment, one or more application functions may signal to the application the transport enablement of interaction and immersion user data as metadata over one or more video elementary streams. In a further embodiment the signaling of this configuration may comprise additionally of UUIDs determining the type and payload format of the interaction and immersion user data to be embedded as metadata over the video elementary stream. In some embodiments the configuration shall be carried over a container comprising at least the following information: a boolean flag indicating the transport enablement of interaction and immersion user data as metadata over one or more video elementary streams (e.g.: interaction-metadata-over-video-es= true indicates that the feature is enabled and interaction-metadata-over-video-es= false indicates the feature is disabled); a list of one or more UUIDs, or alternatively identifiers, determining the type and format of the payloads of the interaction and immersion user data to be carried over the video coded elementary streams (e.g.: UUID = [ea17c3e6-9be4-4d8d-98bf- b5772b273307, afcd396b-9c96-4c8c-b453-85200febfc09, c32dfb22-86fa-46b5-a584- 6603a2d7a556] corresponding for example to viewport pose tracking information (e.g., in radians with respect to horizontal and vertical axes as FoV), user pose information (e.g., floating point representation of a 3D vector and floating point representation of 4D SMM920220294-GR-NP quaternion for orientation) and user hand tracking information (e.g., an object representing two hands and a set of corresponding hand joints locations, velocities vectors); whereby each information additionally comprises their corresponding XR spaces references and timestamps to aid with XR space and time synchronization with the XR runtime. [0236] In one example implementation such a container may be indicated by an SR AF from the split-rendering edge DN to the MSH on a UE by means of interface SR-5. In such a case this information is used to indicate in part the media configuration (e.g., used video codecs, interaction and immersion types and formats of the metadata embedded in the video coded elementary streams). In another example, the SR-5 may comprise functionality specific to UL or DL media streaming corresponding to M5d or M5u interfaces of 5GMS architecture, whereas in other examples, the SR-5 may comprise functionality specific to RTC-5 interface corresponding to the 5GS real-time communications (RTC) architecture. [0237] In one embodiment, the MSH containing the configuration information regarding the transport enablement of interaction and immersion user data as metadata over one or more video elementary streams, and the corresponding UUIDs of such metadata, may expose via an interface this configuration to the SRC. The SRC may request in turn this information upon starting or updating a split-rendering media delivery session to appropriately handle, and further expose the interaction and immersion user data to other functional blocks. In one example, this communication may happen over the SR-6 APIs exposing the MSH configuration information regarding interaction and immersion metadata transport and formats to the SRC. Such an interface may be implemented in some examples by typical HTTP methods, e.g., GET, or any other request-response based protocols. [0238] In another embodiment pertaining to UL AR split-rendering traffic, an SRS may request from the SR AF via an available API, e.g., SR-3, the configuration information regarding the transport enablement of interaction and immersion user data as metadata over video elementary streams, and the corresponding UUIDs of such metadata types and payloads. [0239] In one embodiment the SR AF signaling to the MSH of the configuration information regarding the transport enablement of interaction and immersion user data as metadata over video elementary streams, and the corresponding UUIDs of such metadata types and payloads, may additionally comprise the mapping of the UUIDs to SMM920220294-GR-NP video elementary streams. In one example this may be performed by means of 5-tuple information (src addr, dst addr, srd port, dst port, protocol identifier) of the available media flows. [0240] Embodiments pertaining to SDP-based signaling will now be described. [0241] In an embodiment, the split-rendering server may signal to the application a list of one or more UUIDs corresponding to the transport enablement of one or more types and formats of the interaction and immersion user data as metadata over one or more video elementary streams. The split-rendering server signals to this end this configuration information per each video elementary stream, thus indicating which UUIDs are supported by each video coded elementary stream. Furthermore, the split-rendering server signals the latter in-band over the media-centric user plane to its corresponding split-rendering client. [0242] In one embodiment, the protocol used to signal this configuration is SDP and the signaling and media negotiation of supported UUIDs between the server and the client is based on the SDP offer/answer procedure. The SDP offer/answer is performed before the split-rendering content delivery media session establishment, or alternatively, update. In some embodiments the SRS provides an SDP offer to the SRC. The SRC parses the offer, identifies the SDP attributes associated with the interaction and immersion user data and determines based on the parsed value whether the latter are supported or not. This may be based in part on information acquired from the MSH prior to media session establishment regarding the UE media capabilities, and/or split-rendering-aware application media capabilities and configuration. To confirm support, the SRC copies in the SDP answer to the SRS the supported UUIDs configuration corresponding to the interaction and immersion user data types and formats. This configuration is consequently applied to the DL traffic of a split-rendering content delivery session. [0243] In some other embodiments, whereby UL split-rendering traffic may comprise additionally a video stream (e.g., an AR application), the SDP offer/answer procedure is reciprocated. To this end, the SRC provides an SDP offer to the SRS with supported UUIDs for the video elementary stream embedded interaction and immersion metadata. The SRS processes the SDP offer and provides in turn its response in an SDP answer. If the SRS accepts the SDP UUIDs attributes offer, it copies these to the corresponding SDP answer which is sent back to the SRC. The split-rendering media delivery session starts with the determined SDP offer/answer negotiation outcome and the supported SMM920220294-GR-NP UUIDs types and corresponding payloads are embedded as interaction and immersion metadata to the video coded elementary stream in UL. [0244] In one example, the SDP offer/answer procedure in DL, or alternatively, UL between the SRC and the SRS is performed over the SR-4, or alternatively RTC-4, user plane interface. In another example, the SDP offer/answer procedure in DL, or alternatively, UL between the SRC and the SRS is performed over the SR-4m media- centric user plane interface over a 5GS. In other examples, the SDP offer/answer procedure in DL, or alternatively, UL between the SRC and a dedicated signaling server interfacing with the SRS is performed over the SR-4s signaling-centric user plane interface over a 5GS. [0245] In one embodiment, a 3GPP specific SDP attribute may be utilized over a 5GS implementation to convey the UUIDs determining the type and format of interaction and immersion metadata payloads over a video elementary stream as SDP attributes. To this end, one or more SDP attributes may be used to list one or more UUIDs for a video stream. In an example a UUID may be assigned to more than one video media stream. In one example, the SDP attributed marking of such an UUID is listed in augmented Backus-Naur form (ABNF) format as per RFC 4122, repeated for completeness below: interaction-metadata-uuid = “a=3gpp-interaction-metadata-uuid:” uuid CRLF uuid = field-1 "-" field-2 "-" field-3 "-" field-4 "-" field-5 field-1 = 4hexOctet field-2 = 2hexOctet field-3 = 2hexOctet field-4 = 2hexOctet field-5 = 6hexOctet hexOctet = hexDigit hexDigit hexDigit ="0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" / "a" / "b" / "c" / "d" / "e" / "f" / "A" / "B" / "C" / "D" / "E" / "F" [0246] The SDP attributed marking of such an UUID as illustrated above, may correspond, for example, to SDP attributes of form “a=3gpp-interaction-metadata- uuid:20354d7a-e4fe-47af-8ff6-187bca92f3f9”. As such, the UUID format may be compliant in some implementations with the ISO-IEC-11578 ANNEX A, or SMM920220294-GR-NP alternatively, with the ISO-IEC 9834-8 format. The fields of the UUID listed in the ABNF description above may be thus derived in an example as Version 4 UUID of ISO- IEC 9834-8, i.e., at random. [0247] In another example, a valid SDP listing corresponding to any of an SDP offer or answer is provided below: m=video 49230 RTP/AVP 96 a=rtpmap:96 H.264/90000 a=3gpp-interaction-metadata-uuid: ea17c3e6-9be4-4d8d-98bf-b5772b273307 // viewport a=3gpp-interaction-metadata-uuid: afcd396b-9c96-4c8c-b453-85200febfc09 // user pose a=3gpp-interaction-metadata-uuid: c32dfb22-86fa-46b5-a584-6603a2d7a556 // hand tracking m=video 49231 RTP/AVP 97 a=rtpmap:97 H.265/90000 a=3gpp-interaction-metadata-uuid: ea17c3e6-9be4-4d8d-98bf-b5772b273307 // viewport a=3gpp-interaction-metadata-uuid: afcd396b-9c96-4c8c-b453-85200febfc09 // user pose [0248] In the above example the indicated UUIDs are determined per media stream. As such the H.264 media stream on port 49230 embeds in the video elementary stream UUIDs for viewport pose tracking information, user pose information and user hand tracking information, whereby the H.265 media stream on port 49231 embeds in the video elementary stream UUIDs for viewport pose tracking information and user pose information only. [0249] In an embodiment, once the SDP offer/answer configuration has determined the UUIDs and associated interaction and immersion metadata types and formats for a media stream, the SRC, or alternatively, the SRS handle the user data post-decoding and expose it further to other functional blocks (e.g., XR runtime, split-rendering-aware application, SRS media processing functionality). [0250] This disclosure herein proposes the necessary configuration signaling to enable XR applications split rendering, with transport of interaction and immersion user data over video elementary streams, as SEI messages (H.264, H.265, H.266) or alternatively OBU metadata (AV1). The solution supports multiple types of metadata based on a UUID identifying the type and format of each metadata payload to be carried over the video elementary stream. The proposed signaling mechanisms for the media SMM920220294-GR-NP configuration is based on three methods: application-layer signaling from the ASP to the application followed by update of the media configuration to the split-rendering client for the split-rendering media delivery session; control-plane signaling using the split- rendering application function to indicate the media session handler the media configuration followed by an update of the media configuration to the split-rendering client for the split-rendering media delivery session; user-plane signaling by SDP upon split-rendering media delivery session establishment based on a new SDP attribute; the new SDP attribute can configure for each video media flow a list of UUIDs identifying the carried metadata on the video elementary stream. [0251] The problem solved by this disclosure is the media configuration signaling for real-time transport of interaction and immersion multimedia data for split-rendering interactive and immersive XR applications. The user interaction and immersion data (e.g., pose information, FoV tracking, user actions) acts as inputs to the split-rendering. Yet, for an efficient display processing at the UE, the XR runtime needs metadata information about the user pose and inputs that were used by the split-rendering server to render the frames. These are needed for late stage reprojection. To this end, real-time transport mechanisms for rendered interaction and immersion metadata and media configuration signaling are necessary for efficient display of split-rendered frames. [0252] The invention solves the problem by utilizing SEI messages and OBU metadata as transport mechanism for the interaction and immersion metadata of a split-rendering architecture. The transport relies on video coded elementary streams, thus grouping the rendered frames with their associated pose information that was used for rendering at the edge. To aid a split rendering client the media configuration needs to include signaling that identifies the type of metadata carried over the video elementary streams, as well as its mapping to a video media flow (e.g., a 5-tuple). Three methods are proposed for the signaling: i). the application signaling path, ii). the control plane signaling path of a real- time communications system AF and iii). the user plane signaling based on SDP offer/answer upon RTP session establishment. [0253] The proposed solution is superior to the data channel approach using WebRTC SCTP stack as it benefits of the advantages of RTP/SRTP, i.e., timing, synchronization, jitter management, and reliability based on FEC. Furthermore, the proposed method inherently synchronizes the interaction and immersion metadata with the one or more video streams that are used for piggybacking. Any kind of signaling is out of scope of WebRTC. SMM920220294-GR-NP [0254] The proposed solution is better than the RTP header extension approach as it does not limit the maximum payload size for an interaction and immersion multimedia data type. Furthermore, the proposed solution is transported as part of the RTP payload and thus benefits of RTP synchronization, jitter management and reliability by means of FEC. RTP header extension signaling relies exclusively on SDP offer/answer procedure. SDP is a candidate signaling in the proposed disclosure, yet a new SDP attribute is introduced which is orthogonal to any RTP header extensions related signaling solutions. [0255] The proposed solution is a trade-off with respect to the approach of defining a new IETF RTP payload for interaction and immersion multimedia data. The trade-off is mainly targeted at circumventing the need of providing a full RTP payload type specification. [0256] In particular, the disclosure provides an embodiment that utilizes application- based signaling. The signaling of the renderer interaction and immersion metadata and subsequent mapping to the video media flows is performed by the application service provider which informs the application client of the media configuration. The application client then modifies the split rendering client and the media session handler media configuration accordingly over the 5GS exposed APIs of the latter two functional blocks. [0257] A further embodiment utilizes network-supported signaling. The signaling of the renderer interaction and immersion metadata and subsequent mapping to the video media flows is performed by the split rendering AF which informs the media session handler of the media configuration. The media session handler exposes this configuration over its APIs to the application client but also to the split-rendering client. [0258] A further embodiment utilizes SDP-based signaling. The signaling of the renderer interaction and immersion metadata and subsequent mapping to the video media flows is performed by means of the SDP offer/answer procedure just before the establishment of the media session. A new media description attribute a=3gpp-interaction-metadata- uuid:<UUID> is proposed to map a metadata type (identified by an UUID) to one or more RTP media streams. [0259] Provided by the disclosure herein is, from a split-rendering server perspective, a method for configuration of a multimedia split-rendering content delivery session over a network, the method comprising of: determining a media configuration comprising a mapping of one or more interaction and immersion multimedia data types to one or more video media flows, whereby the one or more interaction and immersion multimedia data types contain non-video coded data from one or more media sources; signaling the SMM920220294-GR-NP determined media configuration to a remote endpoint; establishing in part based on the signaled media configuration a multimedia split-rendering content delivery session configuration including at least one video media flow of at least one video coded elementary stream comprising the one or more mapped interaction and immersion multimedia data as non-video coded metadata payloads; utilizing the non-video coded metadata payloads corresponding to the one or more interaction and immersion multimedia data comprised by the least one video coded elementary stream for split- rendering associated with the at least one video media flow of the at least one video coded elementary stream. [0260] In some embodiments, the non-video coded metadata payload comprises at least two fields. [0261] In some embodiments, a first field indicates a syntax and semantics identifier representation format of an interaction and immersion multimedia data type, and a second field encodes the interaction and immersion multimedia data according to the identifier representation format determined by the first field. [0262] In some embodiments, the first field comprises a universally unique identifier (UUID) indication. [0263] Some embodiments further comprise the configuration mapping matching one or more identifier representation formats corresponding to one or more interaction and immersion multimedia data types to one or more video media flows. [0264] Some embodiments further comprise the signaling of the media configuration being performed based on at least one of: a signaling performed by an Application Service Provider (ASP) to a split-rendering-aware application over an application interface; a signaling between a real-time communications application function (RTC AF) and a Media Session Handler over a control plane interface (e.g., RTC-5 reference interface in a 5GS between the RTC AF and the MSH); and a signaling between a split- rendering server (SRS) and a split-rendering client (SRC) over a user plane interface (e.g., SR-4, or alternatively, RTC-4 reference interface in a 5GS between a SRS and a SRC). [0265] Some embodiments further comprise the determination of the media configuration based in part on at least one of: an Application Service Provider (ASP) configuration provisioning to at least one of a real-time communications application function (RTC AF), a provisioning function, a split-rendering application function (SR AF) and a configuration function; and an application configuration of media capabilities SMM920220294-GR-NP determined semi-statically based partly on hardware capabilities of a corresponding device processing the logic of the application. [0266] In some embodiments, the at least one video coded elementary stream is determined according to at least one of: H.264 video codec specification; H.265 video codec specification; H.266 video codec specification; and AV1 video codec specification. [0267] In some embodiments, the non-video coded metadata payloads comprised in the at least one video coded elementary stream include at least one of: a supplemental enhancement information (SEI) message of type user data unregistered; and a metadata open bitstream unit (OBU) of type unregistered user private data. [0268] In some embodiments, the interaction and immersion multimedia data types comprise one of: a user pose data representation (as for instance a timestamped 3D positional vector and quaternion representation of an XR space describing a pose object orientation up to 6DoF. Such a pose object may correspond to a user body component or segment, such as head, joints, hands or a combination thereof); a user gesture tracking data representation (i.e., an array of one or more hands tracked according to their pose, each hand tracking additionally consisting of an array of hand joint locations and velocities relative to a base XR space and XR runtime timestamp, for example, as per OpenXR OpenXR_EXT_hand_tracking API specification); a user body tracking data representation (e.g., a BioVision Hierarchical (BVH) encoding of the body and body segments movements and associated pose object); a user facial features tracking data representation (e.g., as an array of key points/features positions, pose, or their encoding to pre-determined facial expression classes); a set of one or more user actions (i.e., user actions and inputs to physical controllers or logic controllers defined within an XR space, for example as per OpenXR XrAction handle capturing diverse user inputs to controllers or HW command units supported by an AR/VR device compliant with OpenXR); and a set of one or more augmented reality (AR) object representations, each object comprising of at least one of a graphical description and an associated positional anchor (i.e., metadata determining the position of an object or a point in the XR space as an anchor for placing virtual 2D/3D objects, such as text renderings, static video content, 2D/3D video content etc.). [0269] Some embodiments further comprise the split-rendering utilization of the interaction and immersion data for at least one of: a late stage reprojection at a split- rendering client (SRC) for displaying one or more rendered frames matching latest user pose and orientation information; a partial or full pre-rendering of next one or more SMM920220294-GR-NP frames at a split-rendering server (SRS); and an estimation of at a split-rendering server (SRS) of the most probable user pose and orientation associated with the expected display time of the next one or more frames to be partially or fully pre-rendered. [0270] In some embodiments, the mapping of the interaction and immersion multimedia data types to the media flows is based on at least one of a 5-tuple indication (e.g., as a 5- tuple describing an IP flow comprising of (IP source address, IP destination address, source port, destination port, protocol identifier)), and a media flow identifier (e.g., a media description under SDP, a media flow unique name as provided in the SDP media description attribute etc.). [0271] The disclosure herein also provides, from a split-rendering client perspective, a method for configuration of a multimedia split-rendering content delivery session over a network, the method comprising of: receiving over the network a media configuration comprising a mapping of one or more interaction and immersion multimedia data types to one or more video media flows, whereby the one or more interaction and immersion multimedia data types contain non-video coded data from one or more media sources; controlling a video decoder to generate a set of one or more information payloads corresponding to the non-video coded payloads, whereby each of non-video coded payloads comprises of at least two fields; processing the one or more information payloads as one or more samples of interaction and immersion multimedia data generated by one or more media sources. [0272] In some embodiments, the non-video coded metadata payload comprises at least two fields. [0273] In some embodiments, a first field indicates a syntax and semantics identifier representation format of an interaction and immersion multimedia data type, and a second field encodes the interaction and immersion multimedia data according to the identifier representation format determined by the first field. [0274] In some embodiments, the first field comprises a universally unique identifier (UUID) indication. [0275] Some embodiments further comprise the configuration mapping matching one or more identifier representation formats corresponding to one or more interaction and immersion multimedia data types to one or more video media flows. [0276] Some embodiments further comprise the receiving of the media configuration being performed based on at least one of: a signaling performed by an Application Service Provider (ASP) to a split-rendering-aware application over an application SMM920220294-GR-NP interface; a signaling between a real-time communications application function (RTC AF) and a Media Session Handler over a control plane interface (e.g., RTC-5 reference interface in a 5GS between the RTC AF and the MSH); and a signaling between a split- rendering server (SRS) and a split-rendering client (SRC) over a user plane interface (e.g., SR-4, or alternatively, RTC-4 reference interface in a 5GS between a SRS and a SRC). [0277] Some embodiments further comprise the media configuration being based in part on at least one of: an Application Service Provider (ASP) configuration provisioning to at least one of a real-time communications application function (RTC AF), a provisioning function, a split-rendering application function (SR AF) and a configuration function; and an application configuration of media capabilities determined semi-statically based partly on hardware capabilities of a corresponding device processing the logic of the application. [0278] In some embodiments, the at least one video coded elementary stream is determined according to at least one of: H.264 video codec specification; H.265 video codec specification; H.266 video codec specification; and AV1 video codec specification. [0279] In some embodiments, the non-video coded metadata payloads comprised in the at least one video coded elementary stream include at least one of: a supplemental enhancement information (SEI) message of type user data unregistered; and a metadata open bitstream unit (OBU) of type unregistered user private data. [0280] In some embodiments, the interaction and immersion multimedia data types comprise one of: a user pose data representation (as for instance a timestamped 3D positional vector and quaternion representation of an XR space describing a pose object orientation up to 6DoF. Such a pose object may correspond to a user body component or segment, such as head, joints, hands or a combination thereof); a user gesture tracking data representation (i.e., an array of one or more hands tracked according to their pose, each hand tracking additionally consisting of an array of hand joint locations and velocities relative to a base XR space and XR runtime timestamp, for example, as per OpenXR OpenXR_EXT_hand_tracking API specification); a user body tracking data representation (e.g., a BioVision Hierarchical (BVH) encoding of the body and body segments movements and associated pose object); a user facial features tracking data representation (e.g., as an array of key points/features positions, pose, or their encoding to pre-determined facial expression classes); a set of one or more user actions (i.e., user actions and inputs to physical controllers or logic controllers defined within an XR space, for example as per OpenXR XrAction handle capturing diverse user inputs to controllers SMM920220294-GR-NP or HW command units supported by an AR/VR device compliant with OpenXR); and a set of one or more augmented reality (AR) object representations, each object comprising of at least one of a graphical description and an associated positional anchor (i.e., metadata determining the position of an object or a point in the XR space as an anchor for placing virtual 2D/3D objects, such as text renderings, static video content, 2D/3D video content etc.). [0281] Some embodiments further comprise the split-rendering utilization of the interaction and immersion data for at least one of: a late stage reprojection at a split- rendering client (SRC) for displaying one or more rendered frames matching latest user pose and orientation information; a partial or full pre-rendering of next one or more frames at a split-rendering server (SRS); and an estimation of at a split-rendering server (SRS) of the most probable user pose and orientation associated with the expected display time of the next one or more frames to be partially or fully pre-rendered. [0282] In some embodiments, the mapping of the interaction and immersion multimedia data types to the media flows is based on at least one of a 5-tuple indication (e.g., as a 5- tuple describing an IP flow comprising of (IP source address, IP destination address, source port, destination port, protocol identifier)), and a media flow identifier (e.g., a media description under SDP, a media flow unique name as provided in the SDP media description attribute etc.). [0283] The contents of this disclosure are related to using SEI messages/OBU metadata for transport of interaction and immersion metadata associated with XR applications supported by split-rendering and the signaling required to enable such applications over the 5GS. [0284] It should be noted that the above-mentioned methods and apparatus illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative arrangements without departing from the scope of the appended claims. The word “comprising” does not exclude the presence of elements or steps other than those listed in a claim, “a” or “an” does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims. Any reference signs in the claims shall not be construed so as to limit their scope. [0285] Further, while examples have been given in the context of particular communication standards, these examples are not intended to be the limit of the communication standards to which the disclosed method and apparatus may be applied. For example, while specific examples have been given in the context of 3GPP, the SMM920220294-GR-NP principles disclosed herein can also be applied to another wireless communication system, and indeed any communication system which uses routing rules. [0286] The method may also be embodied in a set of instructions, stored on a computer readable medium, which when loaded into a computer processor, Digital Signal Processor (DSP) or similar, causes the processor to carry out the hereinbefore described methods. [0287] Where referred to, the OpenXR specification is described in git reference release 1.0.26, RTP payload format media types are available in IANA standard RFC4855, and an SDP offer/answer model is described in RFC standard 3264 titled “An offer/answer model with the Session Description Protocol (SDP)”. Furthermore, the following 3GPP Technical Specification Tdocs are relevant to the disclosure herein: S4aR220052 titled “Real-time metadata transport over RTP; S4aR220053 titled “Real-time metadata transport over data channel”; S4-221557 titled “Real-time metadata transport over data channel”; S4-221555 titled “Real-time metadata transport over RTP”; and S4-230359 titled “Signaling the render pose and other related information”. [0288] The described methods and apparatus may be practiced in other specific forms. The described methods and apparatus are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope. [0289] The following abbreviations are relevant in the field addressed by this document: 3GPP, 3rd generation partnership project; 5G, fifth generation; 5GS, 5G System; 5QI, 5G QoS Identifier; AF, application function; AMF, access and mobility function; AR, augmented reality; DL, downlink; DTLS, datagram transport layer security; NAL, network abstraction layer; NALU, NAL unit; OBU, open bitstream unit; PCF, policy control function; PDU, packet data unit; PPS, picture parameter set; QoE, quality of experience; QoS, quality of service; RAN, radio access network; RTCP, real-time control protocol; RTP, real-time protocol; SDAP, service data adaptation protocol; SEI, supplemental enhancement information; SMF, session management function; SRTCP, secure real-time control protocol; SRTP, secure real-time protocol; SR AF, split- rendering AF; SRC, split-rendering client; SRS, split-rendering server; TLS, transport layer security; UE, user equipment; UL, uplink; UPF, user plane function; VCL, video coding layer; VMAF, video multi-method assessment function; VPS, video parameter set; SMM920220294-GR-NP VR, virtual reality; WebRTC, web real-time communications; XR, extended reality; XR AS, XR application server; and XRM, XR media.

Claims

SMM920220294-GR-NP Claims 1. An apparatus for wireless communication, comprising: a processor; and a memory coupled with the processor, the processor configured to cause the apparatus to: determine a media configuration for split-rendering of a video media flow, wherein the media configuration comprises one or more parameters indicating an encoded video stream of the video media flow comprises, as non-video coded metadata, one or more data units of multimedia immersion and interaction data; signal the media configuration to a second apparatus; establish, with the second apparatus, based at least in part on the media configuration, a multimedia split-rendering content delivery session comprising the video media flow; and use, for split-rendering the video media flow, the one or more data units of multimedia immersion and interaction data. 2. The apparatus of claim 1, wherein the non-video coded metadata comprises: a first field comprising an identifier for a syntax and semantics representation format of the one or more data units of multimedia immersion and interaction data; and a second field comprising the one or more data units of multimedia immersion and interaction data, encoded according to the syntax and semantics representation format corresponding to the identifier of the first field. 3. The apparatus of claim 2, wherein the identifier is a universally unique identifier ‘UUID’ indication. 4. The apparatus of claim 3, wherein the UUID is unique to a specific application or session, or the UUID is globally unique. 5. The apparatus of any one of claims 2-4, wherein the processor is configured to cause the apparatus to determine the media configuration by causing the apparatus to: determine the media configuration for a plurality of video media flows having respective encoded video streams and respective non-video coded metadata, wherein the SMM920220294-GR-NP one or more parameters of the media configuration map the identifiers of the first fields of the respective non-video coded metadata, to their respective video media flows. 6. The apparatus of claim 5, wherein the one or more parameters of the media configuration map the first fields of the respective non-video coded metadata, to their respective video media flows, based on at least one of: an application specific stream mapping; a 5-tuple indication; and a media flow description attribute. 7. The apparatus of any preceding claim, wherein the processor is configured to cause the apparatus to signal the media configuration over at least one of: an application interface; a control plane interface; and a user plane interface. 8. The apparatus of any preceding claim, wherein the encoded video stream is encoded/decoded using at least one video codec selected from the list of video codecs consisting of: H.264 video codec specification; H.265 video codec specification; H.266 video codec specification; and AV1 video codec specification. 9. The apparatus of claim 8, wherein: the video codec comprises the H.264, H.265, or H.266 codecs, and the non-video coded metadata is encapsulated as a payload of user data in one or more supplemental enhancement information ‘SEI’ messages of the type ‘user data unregistered’; and/or the video codec comprises the AV1 codec, and the non-video coded metadata is encapsulated as a payload of user data in one or more metadata open bitstream units ‘OBUs’ of type ‘unregistered user private data’. SMM920220294-GR-NP 10. The apparatus of any preceding claim, wherein the one or more data units of multimedia immersion and interaction data comprise immersion and interaction data selected from the list consisting of: a user viewpoint data; a user field of view data; a user pose/orientation data; a user gesture tracking data; a user body tracking data; a user facial feature tracking data; a user action and/or user input data; a split rendering pose and spatial information; and an augmented reality object representation, comprising of at least one of a graphical description of an object and an object positional anchor. 11. The apparatus of any preceding claim, wherein the processor is further configured to cause the apparatus to determine the media configuration based on at least one of: an application configuration of an application hosted on the second apparatus, wherein the application configuration comprises one or more media capabilities of the second apparatus; and/or an application service provider ‘ASP’ configuration, provisioned to at least one of: a real-time communications application function ‘RTC AF’; a provisioning function; a split-rendering application function ‘SR AF’; and/or a configuration function; 12. An apparatus for wireless communication, comprising: a processor; and a memory coupled with the processor, the processor configured to cause the apparatus to: receive, from a first apparatus, a media configuration for split-rendering of a video media flow, wherein the media configuration comprises one or more parameters SMM920220294-GR-NP indicating an encoded video stream of the video media flow comprises, as non-video coded metadata, one or more data units of multimedia immersion and interaction data; configure the apparatus, using the media configuration, to receive the video media flow; decode the encoded video stream of the video media flow, wherein the decoding comprises extracting the non-video coded metadata; and consume, from the non-video coded metadata, the one or more data units of multimedia immersion and interaction data. 13. The apparatus of claim 12, wherein the non-video coded metadata comprises: a first field comprising an identifier for a syntax and semantics representation format of the one or more data units of multimedia immersion and interaction data; and a second field comprising the one or more data units of multimedia immersion and interaction data, encoded according to the syntax and semantics representation format corresponding to the identifier of the first field. 14. The apparatus of claim 13, wherein the identifier is a universally unique identifier ‘UUID’ indication. 15. The apparatus of claim 14, wherein the UUID is unique to a specific application or session, or the UUID is globally unique. 16. The apparatus of any one of claims 13-15, wherein the media configuration is for a plurality of video media flows comprising respective encoded video streams and respective non-video coded metadata, wherein the one or more parameters of the media configuration map the identifiers of the first fields of the respective non-video coded metadata, to their respective video media flows. 17. The apparatus of claim 16, wherein the one or more parameters of the media configuration map the first fields of the respective non-video coded metadata, to their respective video media flows, based on at least one of: an application specific stream mapping; a 5-tuple indication; and a media flow description attribute. SMM920220294-GR-NP 18. The apparatus of any one of claims 12-17, wherein the processor is configured to cause the apparatus to receive the media configuration over at least one of: an application interface; a control plane interface; and a user plane interface. 19. The apparatus of any one of claims 12-18, wherein the encoded video stream is encoded/decoded using at least one video codec selected from the list of video codecs consisting of: H.264 video codec specification; H.265 video codec specification; H.266 video codec specification; and AV1 video codec specification. 20. The apparatus of claim 19, wherein: the video codec comprises the H.264, H.265, or H.266 codecs, and the non-video coded metadata is encapsulated as a payload of user data in one or more supplemental enhancement information ‘SEI’ messages of the type ‘user data unregistered’; and/or the video codec comprises the AV1 codec, and the non-video coded metadata is encapsulated as a payload of user data in one or more metadata open bitstream units ‘OBUs’ of type ‘unregistered user private data’. 21. The apparatus of any one of claims 12-20, wherein the one or more data units of multimedia immersion and interaction data comprise immersion and interaction data selected from the list consisting of: a user viewpoint data; a user field of view data; a user pose/orientation data; a user gesture tracking data; a user body tracking data; a user facial feature tracking data; a user action and/or user input data; a split rendering pose and spatial information; and SMM920220294-GR-NP an augmented reality object representation, comprising of at least one of a graphical description of an object and an object positional anchor. 22. The apparatus of any one of claims 12-21, wherein the media configuration is based on at least one of: an application configuration of an application hosted on the second apparatus, wherein the application configuration comprises one or more media capabilities of second apparatus; and/or an application service provider ‘ASP’ configuration, provisioned to at least one of: a real-time communications application function ‘RTC AF’; a provisioning function; a split-rendering application function ‘SR AF’; and/or a configuration function. 23. A method for wireless communication, comprising: determining a media configuration for split-rendering of a video media flow, wherein the media configuration comprises one or more parameters indicating an encoded video stream of the video media flow comprises, as non-video coded metadata, one or more data units of multimedia immersion and interaction data; signaling the media configuration to a second apparatus; establishing, with the second apparatus, based at least in part on the media configuration, a multimedia split-rendering content delivery session comprising the video media flow; and using, for split-rendering the video media flow, the one or more data units of multimedia immersion and interaction data. 24. The method of claim 23, wherein the non-video coded metadata comprises: a first field comprising an identifier for a syntax and semantics representation format of the one or more data units of multimedia immersion and interaction data; and a second field comprising the one or more data units of multimedia immersion and interaction data, encoded according to the syntax and semantics representation format corresponding to the identifier of the first field. SMM920220294-GR-NP 25. The method of claim 24, wherein the identifier is a universally unique identifier ‘UUID’ indication. 26 The method of claim 25, wherein the UUID is unique to a specific application or session, or the UUID is globally unique. 27. The method of any one of claims 24-26, wherein the determining the media configuration, comprises: determining the media configuration for a plurality of video media flows comprising respective encoded video streams and respective non-video coded metadata, wherein the one or more parameters of the media configuration map the identifiers of the first fields of the respective non-video coded metadata, to their respective video media flows. 28. The method of claim 27, wherein the one or more parameters of the media configuration map the first fields of the respective non-video coded metadata, to their respective video media flows, based on at least one of: an application specific stream mapping; a 5-tuple indication; and a media flow description attribute. 29. The method of any one of claims 23-28, wherein the signaling the media configuration comprises signaling over at least one of: an application interface; a control plane interface; and a user plane interface. 30. The method of any one of claims 23-29, wherein the encoded video stream is encoded/decoded using at least one video codec selected from the list of video codecs consisting of: H.264 video codec specification; H.265 video codec specification; H.266 video codec specification; and AV1 video codec specification. SMM920220294-GR-NP 31. The method of claim 30, wherein: the video codec comprises the H.264, H.265, or H.266 codecs, and the non-video coded metadata is encapsulated as a payload of user data in one or more supplemental enhancement information ‘SEI’ messages of the type ‘user data unregistered’; and/or the video codec comprises the AV1 codec, and the non-video coded metadata is encapsulated as a payload of user data in one or more metadata open bitstream units ‘OBUs’ of type ‘unregistered user private data’. 32. The method of any one of claims 23-31, wherein the one or more data units of multimedia immersion and interaction data comprise immersion and interaction data selected from the list consisting of: a user viewpoint data; a user field of view data; a user pose/orientation data; a user gesture tracking data; a user body tracking data; a user facial feature tracking data; a user action and/or user input data; a split rendering pose and spatial information; and an augmented reality object representation, comprising of at least one of a graphical description of an object and an object positional anchor. 33. The method of any one of claims 23-32, wherein the determining the media configuration comprises determining the media configuration based on at least one of: an application configuration of an application hosted on the second apparatus, wherein the application configuration comprises one or more media capabilities of second apparatus; and/or an application service provider ‘ASP’ configuration, provisioned to at least one of a real-time communications application function ‘RTC AF’; a provisioning function; a split-rendering application function ‘SR AF’; and/or a configuration function. SMM920220294-GR-NP 34. A method for wireless communication, comprising: receiving, from a first apparatus, a media configuration for split-rendering of a video media flow, wherein the media configuration comprises one or more parameters indicating an encoded video stream of the video media flow comprises, as non-video coded metadata, one or more data units of multimedia immersion and interaction data; configuring the apparatus, using the media configuration, to receive the video media flow; decoding the encoded video stream of the video media flow, wherein the decoding comprises extracting the non-video coded metadata; and consuming, from the non-video coded metadata, the one or more data units of multimedia immersion and interaction data. 35. The method of claim 34, wherein the non-video coded metadata comprises: a first field comprising an identifier for a syntax and semantics representation format of the one or more data units of multimedia immersion and interaction data; and a second field comprising the one or more data units of multimedia immersion and interaction data, encoded according to the syntax and semantics representation format corresponding to the identifier of the first field.