Adaptive layered encoding for latency-sensitive extended reality (XR) service

Abstract

An example device for communicating extended reality (XR) media data includes: a memory configured to store media data, and a processing system implemented in circuitry and configured to: determine a quality level for at least partially rendered frames of XR media data to be communicated; and communicate one or more of the at least partially rendered frames of XR media data at the determined quality level.

Description

ADAPTIVE LAYERED ENCODING FOR LATENCY-SENSITIVE EXTENDED REALITY (XR) SERVICETECHNICAL FIELD

[0001] This disclosure relates to transport of media data, and more particularly, to transport of augmented reality media data.BACKGROUND

[0002] Digital video capabilities can be incorporated into a wide range of devices, including digital televisions, extended reality (XR) headsets (e.g., head mounted displays (HMDs) ) digital direct broadcast systems, wireless broadcast systems, personal digital assistants (PDAs) , laptop or desktop computers, digital cameras, digital recording devices, digital media players, video gaming devices, video game consoles, cellular or satellite radio telephones, video teleconferencing devices, and the like. Digital video devices implement video compression techniques, such as those described in the standards defined by MPEG-2, MPEG-4, ITU-T H. 263 or ITU-T H. 264 / MPEG-4, Part 10, Advanced Video Coding (AVC) , ITU-T H. 265 (also referred to as High Efficiency Video Coding (HEVC) ) , and extensions of such standards, to transmit and receive digital video information more efficiently.

[0003] After media data has been encoded, the media data may be packetized for transmission or storage. The video data may be assembled into a media file conforming to any of a variety of standards, such as the International Organization for Standardization (ISO) base media file format and extensions thereof.SUMMARY

[0004] In general, this disclosure describes techniques for transporting extended reality (XR) media data, such as augmented reality (AR) , mixed reality (MR) , or virtual reality (VR) . These techniques may be used when transporting partially or fully rendered XR media data. For example, these techniques may be employed by an edge server device or other network device configured to fully render frames of video data from XR data, then to transmit the rendered frames to a client device, such as a user equipment (UE) device. As another example, these techniques may be employed by an edge server device or other network device configured to partially render the frames of video data from the XR data, and then transmit the partially rendered frames to a client device, which then completes the rendering process.

[0005] In particular, the network rendering device may be configured to render video data at a variety of quality levels, such as a base level and one or more enhancement levels. The network rendering device may then determine one of the quality levels for the rendered video data to send to the client device, e.g., based on a request from the client device and / or measured network conditions, such as available bandwidth, a channel quality indicator (CQI) , a signal to interference plus noise ratio (SINR) , and / or other available communication resources. The network rendering device may then send the video data having the determined quality level to the client device.

[0006] In one example, a method of communicating extended reality (XR) media data includes: determining a quality level for at least partially rendered frames of XR media data to be communicated; and communicating one or more of the at least partially rendered frames of XR media data at the determined quality level.

[0007] In another example, a device for communicating media data includes: a memory configured to store media data; and a processing system implemented in circuitry and configured to: determine a quality level for at least partially rendered frames of XR media data to be communicated; and communicate one or more of the at least partially rendered frames of XR media data at the determined quality level.

[0008] In another example, a device for communicating media data includes: means for determining a quality level for at least partially rendered frames of XR media data to be communicated; and means for communicating one or more of the at least partially rendered frames of XR media data at the determined quality level.

[0009] The details of one or more examples are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description and drawings, and from the claims.BRIEF DESCRIPTION OF DRAWINGS

[0010] FIG. 1 is a block diagram illustrating an example network including various devices for performing the techniques of this disclosure.

[0011] FIG. 2 is a block diagram illustrating an example computing system that may perform split rendering techniques of this disclosure.

[0012] FIG. 3 is a flowchart illustrating an example method of performing split rendering according to techniques of this disclosure.

[0013] FIG. 4 is a block diagram illustrating an example XR communication system that may be configured to perform techniques of this disclosure.

[0014] FIG. 5 is a conceptual diagram illustrating transmission of XR media data in the form of packets.

[0015] FIG. 6 is a conceptual diagram illustrating formation of various quality levels of video data from a PDU set per techniques of this disclosure.

[0016] FIG. 7 is a conceptual diagram illustrating correspondence between various encoded frames of video data and various quality levels per techniques of this disclosure.DETAILED DESCRIPTION

[0017] In general, this disclosure describes techniques for communicating extended reality (XR) media data, such as augmented reality (AR) media data, mixed reality (MR) media data, and / or virtual reality (VR) media data. A rendering server device may be in communication with a client device. The rendering server device may render XR data at various quality levels. The rendering server device may then determine one of the quality levels to be sent to the client device. For example, the client device may determine (e.g., evaluate) network conditions (e.g., available network bandwidth) and request one of the available quality levels. As another example, the rendering server device may determine the network conditions and select one of the available quality levels. The various quality levels may correspond to a base layer and one or more enhancement layers. The base layer may be encoded at a base quality level, and the enhancement layers may be encoded at progressively higher quality levels than the base quality level. In this manner, the techniques of this disclosure may be used to mitigate variations in network conditions for latency-sensitive media data, such as XR media data. For example, when available network conditions are relatively good (e.g., high available bandwidth) , the rendering server device may send higher quality video data, whereas when available network conditions are relatively bad (e.g., low available bandwidth) , the rendering server device may send lower quality video data. In this manner, an experience of a user of the client device may be improved, in that latency associated with transmitting video data can be reduced.

[0018] The techniques of this disclosure may be performed in conjunction with split rendering of XR media data, such as AR, MR, or VR. A split rendering server may perform at least part of a rendering process to form rendered images, then stream the rendered images to a destination device, such as a user equipment device (UE) and / or a display device, such as XR glasses or a head mounted display (HMD) . In general, a user may wear the display device, and the display device may capture pose information, such as a user position and orientation / rotation in real world space, which may be translated to render images for a viewport in a virtual world space.

[0019] Split rendering may enhance a user experience through providing access to advanced and sophisticated rendering that otherwise may not be possible or may place excess power and / or processing demands on XR glasses or a user equipment (UE) device. In split rendering all or parts of the 3D scene are rendered remotely on an edge application server, also referred to as a “split rendering server” in this disclosure. The results of the split rendering process are streamed down to the UE or XR glasses for display. The spectrum of split rendering operations may be wide, ranging from full pre-rendering on the edge to offloading partial, processing-extensive rendering operations to the edge.

[0020] The display device (e.g., UE / AR glasses) may stream pose predictions to the split rendering server at the edge. The display device may then receive rendered media for display from the split rendering server. The XR runtime may be configured to receive rendered data together with associated pose information (e.g., information indicating the predicted pose for which the rendered data was rendered) for proper composition and display. For instance, the XR runtime may need to perform pose correction to modify the rendered data according to an actual pose of the user at the display time. This disclosure describes techniques for conveying render pose information together with rendered images, e.g., in the form of a Real-time Transport Protocol (RTP) header extension. In this manner, the display device can accurately correct and display rendered images when the images were rendered by a separate device, e.g., for split rendering. This may allow advanced rendering techniques to be performed by the split rendering server while also presenting images that accurately reflect a user pose (e.g., position and orientation / rotation) to the user.

[0021] FIG. 1 is a block diagram illustrating an example network 10 including various devices for performing the techniques of this disclosure. In this example, network 10 includes user equipment (UE) devices 12, 14, call session control function (CSCF) 16, multimedia application server (MAS) 18, data channel signaling function (DCSF) 20, multimedia resource function (MRF) 26, and augmented reality application server (AR AS) 22. MAS 18 may correspond to a multimedia telephony application server, an IP Multimedia Subsystem (IMS) application server, or the like.

[0022] UEs 12, 14 represent examples of UEs that may participate in an XR communication session 28. XR communication session 28 may generally represent a communication session during which users of UEs 12, 14 exchange voice, video, and / or XR data (and / or other XR data) . For example, XR communication session 28 may represent a conference call during which the users of UEs 12, 14 may be virtually present in a virtual conference room, which may include a virtual table, virtual chairs, a virtual screen or white board, or other such virtual objects. The users may be represented by avatars, which may be realistic or cartoonish depictions of the users in the virtual XR scene. The users may interact with virtual objects, which may cause the virtual objects to move or trigger other behaviors in the virtual scene. Furthermore, the users may navigate through the virtual scene, and a user’s corresponding avatar may move according to the user’s movements or movement inputs. In some examples, the users’ avatars may include faces that are animated according to the facial movements of the users (e.g., to represent speech or emotions, e.g., smiling, thinking, frowning, or the like) .

[0023] UEs 12, 14 may exchange XR media data related to a virtual scene, represented by a scene description. Users of UEs 12, 14 may view the virtual scene including virtual objects, as well as user XR data, such as avatars, shadows cast by the avatars, user virtual objects, user provided documents such as slides, images, videos, or the like, or other such data. Ultimately, users of UEs 12, 14 may experience an XR call from the perspective of their corresponding avatars (in first or third person) of virtual objects and avatars in the scene.

[0024] UEs 12, 14 may collect pose data for users of UEs 12, 14, respectively. For example, UEs 12, 14 may collect pose data including a position of the users, corresponding to positions within the virtual scene, as well as an orientation of a viewport, such as a direction in which the users are looking (i.e., an orientation of UEs 12, 14 in the real world, corresponding to virtual camera orientations) . UEs 12, 14 may provide this pose data to XR AS 22 and / or to each other.

[0025] CSCF 16 may be a proxy CSCF (P-CSCF) , an interrogating CSCF (I-CSCF) , or serving CSCF (S-CSCF) . CSCF 16 may generally authenticate users of UEs 12 and / or 14, inspect signaling for proper use, provide quality of service (QoS) , provide policy enforcement, participate in session initiation protocol (SIP) communications, provide session control, direct messages to appropriate application server (s) , provide routing services, or the like. CSCF 16 may represent one or more I / S / P CSCFs.

[0026] MAS 18 represents an application server for providing voice, video, and other telephony services over a network, such as a 5G network. MAS 18 may provide telephony applications and multimedia functions to UEs 12, 14.

[0027] DCSF 20 may act as an interface between MAS 18 and MRF 26, to request data channel resources from MRF 26 and to confirm that data channel resources have been allocated. DCSF 20 may receive event reports from MAS 18 and determine whether an XR communication service is permitted to be present during a communication session (e.g., an IMS communication session) .

[0028] MRF 26 may be an enhanced MRF (eMRF) in some examples. In general, MRF 26 generates scene descriptions for each participant in an XR communication session. MRF 26 may support an XR conversational service, e.g., including providing transcoding for terminals with limited capabilities. MRF 26 may collect spatial and media descriptions from UEs 12, 14 and create scene descriptions for symmetrical XR call experiences. In some examples, rendering unit 24 may be included in MRF 26 instead of XR AS 22, such that MRF 26 may provide remote XR rendering services, as discussed in greater detail below.

[0029] MRF 26 may request data from UEs 12, 14 to create a symmetric experience for users of UEs 12, 14. The requested data may include, for example, a spatial description of a space around UEs 12, 14; media properties representing XR media that each of UEs 12, 14 will be sending to be incorporated into the scene; receiving media capabilities of UEs 12, 14 (e.g., decoding and rendering / hardware capabilities, such as a display resolution) ; and information based on detecting location, orientation, and capabilities of physical world devices that may be used in an audio-visual communication sessions. Based on this data, MRF 26 may create a scene that defines placement of each user and XR media in the scene (e.g., position, size, depth from the user, anchor type, and recommended resolution / quality) ; and specific rendering properties for XR media data (e.g., if 2D media should be rendered with a “billboarding” effect such that the 2D media is always facing the user) . MRF 26 may send the scene data to each of UEs 12, 14 using a supported scene description format.

[0030] AR AS 22 may participate in XR communication session 28. For example, XR AS 22 may provide XR service control related to XR communication session 28. XR service control may include XR session media control and XR media capability negotiation between UEs 12, 14 and rendering unit 24.

[0031] AR AS 22 also includes rendering unit 24, in this example. Rendering unit 24 may perform split rendering on behalf of at least one of UEs 12, 14. In some examples, two different rendering units may be provided. In general, rendering unit 24 may perform a first set of rendering tasks for, e.g., UE 14, and UE 14 may complete the rendering process, which may include warping rendered viewport data to correspond to a current view of a user of UE 14. For example, UE 14 may send a predicted pose (position and orientation) of the user to rendering unit 24, and rendering unit 24 may render a viewport according to the predicted pose. However, if the actual pose is different than the predicted pose at the time video data is to be presented to a user of UE 14, UE 14 may warp the rendered data to represent the actual pose (e.g., if the user has suddenly changed movement direction or turned their head) .

[0032] While only a single rendering unit is shown in the example of FIG. 1, in other examples, each of UEs 12, 14 may be associated with a corresponding rendering unit. Rendering unit 24 as shown in the example of FIG. 1 is included in XR AS 22, which may be an edge server at an edge of a communication network. However, in other examples, rendering unit 24 may be included in a local network of, e.g., UE 12 or UE 14. For example, rendering unit 24 may be included in a PC, laptop, tablet, or cellular phone of a user, and UE 14 may correspond to a wireless display device, e.g., XR glasses or a head mounted display (HMD) . Although two UEs are shown in the example of FIG. 1, in general, multi-participant XR calls are also possible.

[0033] UEs 12, 14, and XR AS 22 may communicate XR data using a network communication protocol, such as Real-time Transport Protocol (RTP) , which is standardized in Request for Comment (RFC) 3550 by the Internet Engineering Task Force (IETF) . These and other devices involved in RTP communications may also implement protocols related to RTP, such as RTP Control Protocol (RTCP) , Real-time Streaming Protocol (RTSP) , Session Initiation Protocol (SIP) , and / or Session Description Protocol (SDP) .

[0034] In general, an RTP session may be established as follows. UE 12, for example, may receive an RTSP describe request from, e.g., UE 14. The RTSP describe request may include data indicating what types of data are supported by UE 14. UE 12 may respond to UE 14 with data indicating media streams that can be sent to UE 14, along with a corresponding network location identifier, such as a uniform resource locator (URL) or uniform resource name (URN) .

[0035] UE 12 may then receive an RTSP setup request from UE 14. The RTSP setup request may generally indicate how a media stream is to be transported. The RTSP setup request may contain the network location identifier for the requested media data (e.g., media content 64) and a transport specifier, such as local ports for receiving RTP data and control data (e.g., RTCP data) on UE 14. UE 12 may reply to the RTSP setup request with a confirmation and data representing ports of UE 12 by which the RTP data and control data will be sent. UE 12 may then receive an RTSP play request, to cause the media stream to be “played, ” i.e., sent to UE 14. UE 12 may also receive an RTSP teardown request to end the streaming session, in response to which, UE 12 may stop sending media data to UE 14 for the corresponding session.

[0036] UE 14, likewise, may initiate a media stream by initially sending an RTSP describe request to UE 12. The RTSP describe request may indicate types of data supported by UE 14. UE 14 may then receive a reply from UE 12 specifying available media streams, such as media content 64, that can be sent to UE 14, along with a corresponding network location identifier, such as a uniform resource locator (URL) or uniform resource name (URN) .

[0037] UE 14 may then generate an RTSP setup request and send the RTSP setup request to UE 12. As noted above, the RTSP setup request may contain the network location identifier for the requested media data (e.g., media content 64) and a transport specifier, such as local ports for receiving RTP data and control data (e.g., RTCP data) on UE 14. In response, UE 14 may receive a confirmation from UE 12, including ports of UE 12 that UE 12 will use to send media data and control data.

[0038] After establishing a media streaming session (e.g., XR communication session 28) between UE 12 and UE 14, UE 12 exchange media data (e.g., packets of media data) with UE 14 according to the media streaming session. UE 12 and UE 14 may exchange control data (e.g., RTCP data) indicating, for example, reception statistics by UE 14, such that UEs 12, 14 can perform congestion control or otherwise diagnose and address transmission faults.

[0039] FIG. 2 is a block diagram illustrating an example computing system 100 that may perform split rendering techniques of this disclosure. In this example, computing system 100 includes extended reality (XR) server device 110, network 130, XR client device 140, and display device 150. XR server device 110 includes XR scene generation unit 112, XR viewport pre-rendering rasterization unit 114, 2D media encoding unit 116, XR media content delivery unit 118, and 5G System (5GS) delivery unit 120.

[0040] Network 130 may correspond to any network of computing devices that communicate according to one or more network protocols, such as the Internet. In particular, network 130 may include a 5G radio access network (RAN) including an access device to which XR client device 140 connects to access network 130 and XR server device 110. In other examples, other types of networks, such as other types of RANs, may be used. For example, network 130 may represent a wireless or wired local network. In other examples, XR client device 140 and XR server device 110 may communicate via other mechanisms, such as Bluetooth, a wired universal serial bus (USB) connection, or the like. XR client device 140 includes 5GS delivery unit 141, tracking / XR sensors 146, XR viewport rendering unit 142, 2D media decoder 144, and XR media content delivery unit 148. XR client device 140 also interfaces with display device 150 to present XR media data to a user (not shown) .

[0041] In some examples, XR scene generation unit 112 may correspond to an interactive media entertainment application, such as a video game, which may be executed by one or more processors implemented in circuitry of XR server device 110. XR viewport pre-rendering rasterization unit 114 may format scene data generated by XR scene generation unit 112 as pre-rendered two-dimensional (2D) media data (e.g., video data) for a viewport of a user of XR client device 140.2D media encoding unit 116 may encode formatted scene data from XR viewport pre-rendering rasterization unit 114, e.g., using a video encoding standard, such as ITU-T H. 264 / Advanced Video Coding (AVC) , ITU-T H. 265 / High Efficiency Video Coding (HEVC) , ITU-T H. 266 Versatile Video Coding (VVC) , or the like. XR media content delivery unit 118 represents a content delivery sender, in this example. In this example, XR media content delivery unit 148 represents a content delivery receiver, and 2D media decoder 144 may perform error handling.

[0042] In general, XR client device 140 may determine a user’s viewport, e.g., a direction in which a user is looking and a physical location of the user, which may correspond to an orientation of XR client device 140 and a geographic position of XR client device 140. Tracking / XR sensors 146 may determine such location and orientation data, e.g., using cameras, accelerometers, magnetometers, gyroscopes, or the like. Tracking / XR sensors 146 provide location and orientation data to XR viewport rendering unit 142 and 5GS delivery unit 141. XR client device 140 provides tracking and sensor information 132 to XR server device 110 via network 130. XR server device 110, in turn, receives tracking and sensor information 132 and provides this information to XR scene generation unit 112 and XR viewport pre-rendering rasterization unit 114. In this manner, XR scene generation unit 112 can generate scene data for the user’s viewport and location, and then pre-render 2D media data for the user’s viewport using XR viewport pre-rendering rasterization unit 114. XR server device 110 may therefore deliver encoded, pre-rendered 2D media data 134 to XR client device 140 via network 130, e.g., using a 5G radio configuration.

[0043] XR scene generation unit 112 may receive data representing a type of multimedia application (e.g., a type of video game) , a state of the application, multiple user actions, or the like. XR viewport pre-rendering rasterization unit 114 may format a rasterized video signal. 2D media encoding unit 116 may be configured with a particular `er / decoder (codec) , bitrate for media encoding, a rate control algorithm and corresponding parameters, data for forming slices of pictures of the video data, low latency encoding parameters, error resilience parameters, intra-prediction parameters, or the like. XR media content delivery unit 118 may be configured with real-time transport protocol (RTP) parameters, rate control parameters, error resilience information, and the like. XR media content delivery unit 148 may be configured with feedback parameters, error concealment algorithms and parameters, post correction algorithms and parameters, and the like.

[0044] Raster-based split rendering refers to the case where XR server device 110 runs an XR engine (e.g., XR scene generation unit 112) to generate an XR scene based on information coming from an XR device, e.g., XR client device 140 and tracking and sensor information 132. XR server device 110 may rasterize an XR viewport and perform XR pre-rendering using XR viewport pre-rendering rasterization unit 114.

[0045] In the example of FIG. 2, the viewport is predominantly rendered in XR server device 110, but XR client device 140 is able to do latest pose correction, for example, using asynchronuous time-warping or other XR pose correction to address changes in the pose. XR graphics workload may be split into rendering workload on a powerful XR server device 110 (in the cloud or the edge) and pose correction (such as asynchronous timewarp (ATW) ) on XR client device 140. Low motion-to-photon latency is preserved via on-device Asynchronous Time Warping (ATW) or other pose correction methods performed by XR client device 140.

[0046] The various components of XR server device 110, XR client device 140, and display device 150 may be implemented using one or more processors implemented in circuitry, such as one or more digital signal processors (DSPs) , general purpose microprocessors, application specific integrated circuits (ASICs) , field programmable logic arrays (FPGAs) , or other equivalent integrated or discrete logic circuitry. The functions attributed to these various components may be implemented in hardware, software, or firmware. When implemented in software or firmware, it should be understood that instructions for the software or firmware may be stored on a computer-readable medium and executed by requisite hardware.

[0047] FIG. 3 is a flowchart illustrating an example method of performing split rendering according to techniques of this disclosure. The method of FIG. 3 may be performed by a split rendering client device, such as XR client device 140 of FIG. 2, in conjunction with a split rendering server device, such as XR server device 110 of FIG. 2.

[0048] Initially, the split rendering client device creates an XR split rendering session (200) . Creating the XR split rendering session may include any or all of steps 200–208 of FIG. 5, and / or steps 220 and 224 of FIG. 6. As discussed above, creating the XR split rendering session may include, for example, sending device information and capabilities, such as supported decoders, viewport information (e.g., resolution, size, etc. ) , or the like. The split rendering server device sets up an XR split rendering session (202) , which may include setting up encoders corresponding to the decoders and renderers corresponding to the viewport supported by the split rendering client device.

[0049] The split rendering client device may then receive current pose and action information (204) . For example, the split rendering client device may collect XR pose and movement information from tracking / XR sensors (e.g., tracking / XR sensors 146 of FIG. 2) . The split rendering client device may then predict a user pose (e.g., position and orientation) at a future time (206) . The split rendering client device may predict the user pose according to a current position and orientation, velocity, and / or angular velocity of the user / ahead mounted display (HMD) worn by the user. The predicted pose may include a position in an XR scene, which may be represented as an {X, Y, Z} triplet value, and an orientation / rotation, which may be represented as an {RX, RY, RZ, RW}quaternion value. The split rendering client device may send the predicted pose information, (optionally) along with any actions performed by the user to the split rendering server device (208) . For example, the split rendering client device may form a message according to the format shown in FIG. 8 to indicate the position, rotation, timestamp (indicative of a time for which the pose information was predicted) , and optional action information, and send the message to the split rendering server device.

[0050] The split rendering server device may receive the predicted pose information (210) from the split rendering client device. The split rendering server device may then render a frame at various quality levels for the future time based on the predicted pose at that future time (212) . For example, the split rendering server device may execute a game engine that uses the predicted pose at the future time to render an image for the corresponding viewport, e.g., based on positions of virtual objects in the XR scene relative to the position and orientation of the user’s pose at the future time. The split rendering server device may then determine a quality level to be sent to the split rendering client device (214) . For example, the split rendering server device may determine the quality level based on available network bandwidth, a channel quality indicator (CQI) , signal to interference plus noise ratio (SINR) , or other available communication resources. As another example, the split rendering server device may receive a request from the split rendering client device for one of the quality levels. The split rendering server device may then send a rendered frame at the determined quality level to the split rendering client device (216) .

[0051] The split rendering client device may then receive the rendered frame (218) and present the rendered frame at the future time (220) . For example, the split rendering client device may receive a stream of rendered frames and store the received rendered frames to a frame buffer. At a current display time, the split rendering client device may determine the current display time and then retrieve one of the rendered frames from the buffer having a presentation time that is closest to the current display time. In the event that the frame is partially rendered, the split rendering client device may complete the rendering, e.g., warping the frame based on a difference between the predicted pose and an actual pose at the presentation time.

[0052] FIG. 4 is a block diagram illustrating an example XR communication system that may be configured to perform techniques of this disclosure. In this example, the XR communication system includes edge server device 250 including XR rendering unit 252, base station 260, UE 262, and XR headset 264. Edge server device 250 may be an edge application server (EAS) . XR rendering unit 252 may be a game engine or other unit configured to render AR / XR data into frames of video data. Edge server device 250 may further include one or more video encoders (not shown) for encoding the frames of video data. Base station 260 may be, for example, a gNodeB or other base station of a radio access network (RAN) . UE 262 may be a cellular phone that communicates via base station 260 over the RAN. XR headset 264 may be XR glasses, a VR head-mounted display (HMD) , or the like.

[0053] RANs, such as 5G and 5G-A, are expected to provide high-speed, low-latency, and high-reliability wireless connectivity, which can enable immersive XR multimedia and cloud computing services. For example, RANs may be used to deliver XR multimedia for AR, cloud gaming, cloud AI, or the like. These advanced applications may satisfy strict system requirements on data rate, latency, and power consumption. In general, RANs are expected to provide low-latency and high reliability. For example, there may be an expectation that 99%or 99.9%of packets of XR traffic are to be delivered within a packet delay budget (PDB) requirement (e.g., 10ms or less) . Failure to meet the required reliability, PDB, or data rate may lead to video lag, a black screen, and / or asynchrony among multiple-modal traffic, which negatively impacts user experience.

[0054] Thus, per the techniques of this disclosure, edge server device 250 may render (partially or fully) video frames and encode the video frames at various quality levels. Edge server device 250 or UE 262 may select one of the quality levels, and edge server device 250 may send the video frames of the selected quality level to UE 262. Edge server device 250 may correspond to, for example, XR AS 22 of FIG. 1 or XR server device 110 of FIG. 2. UE 262 may correspond to, e.g., UE 14 of FIG. 1 or XR client device 140 of FIG. 2.

[0055] The quality levels may include a base level and one or more enhancement levels. In some examples, different encoding schemes may be used to form the base level and the enhancement levels. For example, different bit budgets or quantization parameter (QP) values may be used when encoding the video frames to form the various quality levels. In some examples, the base layer and one or more of the enhancement layers may be combined. For example, a full resolution video frame may be downsampled to form the base layer, and the one or more enhancement layers may include upsampling data to upsample the base layer to a higher resolution.

[0056] FIG. 5 is a conceptual diagram illustrating transmission of XR media data in the form of packets. In particular, FIG. 5 depicts protocol data unit (PDU) set 280, including multiple PDUs. Each PDU may correspond to a video frame. PDU set 280 may be packetized to form packets 282A–282C (packets 282) .

[0057] XR and cloud gaming is sensitive to radio quality and resource congestion due to specific metrics. For example, when radio quality turns poor suddenly, more resources and latency are required to transmit high-resolution video data, because of degraded modulation and coding scheme (MCS) , lower rank, and / or higher block error rate (BLER) . This becomes more important as UEs approach cell-edge areas or blind spots, especially for frequency range 2 (FR2) of 5G NR, for example. Likewise, when available resources may become congested such that multiple XR / cloud gaming UEs cannot be supported.

[0058] From a traffic perspective, one frame of application layer data may be segmented into multiple packets of lower network layers, as shown in FIG. 5. If the network encounters one of the congestion or diminished quality scenarios described above, packets belonging to a frame may not complete transmission in the required PDB and reliability. This may severely impact playback video at the receiver, leading to a blank screen, buffering, and / or video lag.

[0059] When resources are congested, transfer delay of XR packets may soar compared to the case when there is no congestion. Congestion is realized by adjusting the available bandwidth. From a systematic performance perspective, congestion leads to traffic packets of UEs that exceed required PDB and further decrease satisfaction ratios of XR UEs.

[0060] Video fluency for XR / cloud gaming is better than nothing, e.g., a black screen, video lag, or buffering. Thus, this disclosure describes techniques that may be used to prioritize video fluency at the cost of video quality / resolution, e.g., in cases where wireless radio quality is poor or there are not ample resources to support a current number of terminals. Multiple layered encoding candidates, which may have different resolutions, may be selected adaptively, e.g., based on radio quality and / or resource state.

[0061] FIG. 6 is a conceptual diagram illustrating formation of various quality levels of video data from a PDU set per techniques of this disclosure. In general, to reduce the negative impacts associated with poor radio quality and / or increased congestion, video content may be divided into two categories of layers intentionally: a basic layer and enhanced layers. In the basic layer, traffic may be encoded with low-quality, which has a low resolution and small volume of data to transmit. In the enhanced layers, traffic may be encoded at one or more higher qualities (relative to the quality at which the basic layer was encoded) , which may have higher resolutions than the base layer resolution, such that the enhanced layers include more data to transmit. The basic layer may be prioritized for transmission over the enhanced layer (s) to guarantee video fluency, at the cost of video resolution, e.g., when the network suddenly encounters poor radio quality or congestion. If there are extra resources or the radio quality turns out to be better, the enhanced layers may be transmitted to improve the video quality / resolution relative to the basic layer. Thus, as shown in FIG. 6, PDU Set 300 may be encoded using various encoding schemes to form base layer 302 (an example basic layer) and enhancement layers 304A–304N (example enhanced layers) .

[0062] Multiple layers may be encoded at the transmitter. These layers may have different resolutions. The transmitter (e.g., edge server device 250 of FIG. 4) may select a suitable layer for transmission, e.g., according to instant radio quality and resource conditions. Base layer 302 may be sent for the poorest radio quality case and / or most congested case. The transmitter may send one of progressively higher quality enhancement layers 304 for progressively higher radio quality and / or less congestion cases. Each layer may include all video content but at a unique resolution  / data volume for the given video. The transmitter may select a suitable layer to transmit based on, e.g., a channel quality indicator (CQI) , signal to interference plus noise ratio (SINR) , or available communication resources.

[0063] In another example, a network device may control content layer selection / switching and indicates the layer to the client device / UE (e.g., an XR  / cloud gaming UE) . The network device may preconfigure the UE with data representing the multiple encoding schemes using radio resource control (RRC) or media access control (MAC) Control Element (CE) communications. The network device may also preconfigure the UE with data mapping the various encoding schemes to different video resolutions having different data volumes. For an uplink, the network device may determine the radio quality according to UE reports and available resources, so the network device may select the suitable layer and indicate this layer to the UE using downlink control information (DCI) or MAC CE. The indication may be delivered together with parameters such as modulation and coding scheme (MCS) , new data indicator (NDI) , hybrid automatic repeat request (HARQ) , or the like. The indication may be delivered with specific a field in non-scheduling DCI.

[0064] For a downlink, the network device may select the suitable layer and indicate the selection to the UE using scheduling DCI. The indication may be delivered together with other downlink scheduling parameters in DCI, e.g., 1_0, 1_1, or 1_2. The UE may then decode the upcoming traffic with a corresponding decoding scheme in response to receiving the indication.

[0065] In some examples, the UE may autonomously select a suitable content layer and indicate the selection to the network device using MAC CE or uplink control information (UCI) . With downlink and uplink channel reciprocity, the UE may acquire the radio quality of the uplink channel with channel start information reference signal (CSI-RS) or downlink demodulation reference signal (DMRS) . The UE may predict and autonomously select a suitable content layer based on the downlink channel estimation and then indicate the selection to the network device for better decoding. The UE may indicate, to the network device, the selection using UCI or uplink MAC CE data.

[0066] In some examples, the various quality layers may be represented using codepoints for better indication in the downlink or uplink. For example, if there are two content layers, one bit may be used to represent the codepoint. If there are four content layers, two bits may be used to represent the codepoint. The application layer may mark the different encoded layers indexes (basic and enhanced layers) in the PDU Set metadata, e.g., in an enhanced real-time transport protocol (RTP) header extension. An application server may mark for the downlink channel, and the application client may mark for the uplink channel. The two endpoints may negotiate the RTP header extension, e.g., in a session description protocol (SDP) offer or answer signaling. Encoded layer information may be carried in the RTP header extension and may be shared with the network (base station, gNB, or user plane function (UPF) ) via control plane signaling. For example, an application function (AF) may signal the selected layer to a policy and control function (PCF) , which may signal to a session management function (SMF) , which may signal to the UPF. The AF may alternatively signal the selected layer to the PCF, which may signal to the SMF, which may signal to an access and mobility management function (AMF) , which may signal the base station / gNB.

[0067] In some examples, the media data (e.g., packets) may be encapsulated into GPRS tunneling protocol-user (GTP-U) tunneled packets. Thus, the packets may be encapsulated into GTP-U tunneled packets and delivered from the network (e.g., an edge server device, such as edge server device 250 of FIG. 4) to base station 260 of FIG. 4. The layer indication may be included in a GTP-U header, such that base station 260 may allocate appropriate resources for handling the media data, e.g., for smart scheduling priority determination.

[0068] FIG. 7 is a conceptual diagram illustrating correspondence between various encoded frames of video data and various quality levels per techniques of this disclosure. In this example, FIG. 7 depicts intra-prediction encoded frame (I-frame) 310, uni-directional inter-prediction encoded frame (P-frame) 312, and bi-directional inter-prediction encoded frame (B-frame) 314, as well as base layer 320 and enhancement layers 322A–322N.

[0069] In some examples, various layers may be encoded with different schemes according to the importance of certain frames. For example, I-frame 310 may be considered more important than P-frame 312 and B-frame 314, since I-frame 310 may have an attribute of being self-decodable, whereas P-frame 312 and B-frame 314 are coded relative to other frames (including successful decoding of P-frame 312) . When radio quality turns out to be poor or the network resources are insufficient to support a current number of UEs, I-frame 310 may be guaranteed for transmission, even at a lower resolution format. Thus, I-frame 310 may be the default to be encoded into each of base layer 320 and enhancement layers 322. When facing extreme conditions of radio quality or congestion, I-frame 310 may be prioritized for transmission for base layer 320. Otherwise, enhanced versions of I-frame 310 may be transmitted adaptively. P-frame 312 and B-frame 314 may not be forced to be encoded at base layer 320 or enhancement layers 322 to save overhead.

[0070] In some examples, layers may be encoded with different encoding schemes according to importance of PDU Sets. If a PDU Set is important, a basic layer version may exist, since the basic layer has the smallest volume of data to transmit, and has the respectively highest probability to transmit in PDB when facing poor radio quality / network congestion. Enhanced versions for the PUD set may co-exist with the basic version. The enhanced versions may be transmitted when the radio stays in good condition and there is not network congestion. For other PDU Sets, the basic layer is an option, which is not forced, to configure for saving redundant overhead. Layer switching may be indicated by the network or selected by the UE, as discussed above.

[0071] Multiple description coding (MDC) is another example for ensuring XR performance. If the receiver receives a first description, the receiver may get low-quality video. However, if the receiver receives more descriptions, the receiver may combine the descriptions to decode and get high quality video. In the case of MDC, there need be no priority between descriptions. When the radio condition is poor, the network or the UE can prioritize the transmission of a single description. When the radio condition improves, the network or the UE may prioritize the transmission of multiple descriptions.

[0072] Various examples of the techniques of this disclosure are summarized in the following clauses:

[0073] Clause 1: A method of communicating augmented reality (AR) media data, the method comprising: determining a quality level for at least partially rendered frames of XR media data to be communicated; and communicating one or more of the at least partially rendered frames of XR media data at the determined quality level.

[0074] Clause 2: The method of clause 1, wherein the at least partially rendered frames of XR media data include a base layer quality and one or more enhancement layer qualities.

[0075] Clause 3: The method of any of clauses 1 and 2, wherein communicating the one or more of the at least partially rendered frames comprises sending the one or more of the at least partially rendered frames.

[0076] Clause 4: The method of any of clauses 1 and 2, wherein communicating the one or more of the at least partially rendered frames comprises retrieving the at least partially rendered frames, the method further comprising completing rendering of the at least partially rendered frames.

[0077] Clause 5: The method of any of clauses 1–4, wherein determining the quality level comprises determining the quality level based on one or more of a channel quality indicator (CQI) , signal to interference plus noise ratio (SINR) , or available communication resources.

[0078] Clause 6: The method of any of clauses 1–5, wherein determining comprises determining by a transmitter.

[0079] Clause 7: The method of any of clauses 1–5, wherein determining comprises determining by a network device separate from a receiving device.

[0080] Clause 8: The method of any of clauses 1–5, wherein determining comprises determining by a receiving device.

[0081] Clause 9: The method of any of clauses 1–8, wherein the quality level is selected from a plurality of quality levels, each of the quality levels being associated with a respective codepoint.

[0082] Clause 10: The method of clause 9, further comprising requesting the quality level using a request that specifies the respective codepoint for the determined quality level.

[0083] Clause 11: The method of any of clauses 1–10, wherein communicating the at least partially rendered frames comprises communicating protocol data units (PDUs) of one or more PDU Sets, the method further comprising communicating PDU Set metadata for the PDU Sets including data representing the determined quality level.

[0084] Clause 12: The method of clause 11, wherein the data representing the determined quality level is included in a Real-time Transport Protocol (RTP) Header Extension of an RTP packet that encapsulates one or more of the PDUs.

[0085] Clause 13: The method of clause 12, further comprising communicating the RTP Header Extension in a Session Description Protocol (SDP) message.

[0086] Clause 14: The method of clause 13, wherein the SDP message comprises one of an SDP offer or an SDP answer.

[0087] Clause 15: The method of any of clauses 1–14, wherein the at least partially rendered frames include an intra-prediction encoded frame (I-frame) that is common to all available quality levels, and different inter-prediction encoded frames for each of the available quality levels.

[0088] Clause 16: A device for communication media data, the device comprising one or more means for performing the method of any of clauses 1–15.

[0089] Clause 17: The device of clause 16, wherein the one or more means comprise a processing system comprising one or more processors implemented in circuitry, and a memory configured to store XR media data.

[0090] Clause 18: A device for communicating media data, the device comprising: means for determining a quality level for at least partially rendered frames of XR media data to be communicated; and communicating one or more of the at least partially rendered frames of XR media data at the determined quality level.

[0091] In one or more examples, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium and executed by a hardware-based processing unit. Computer-readable media may include computer-readable storage media, which corresponds to a tangible medium such as data storage media, or communication media including any medium that facilitates transfer of a computer program from one place to another, e.g., according to a communication protocol. In this manner, computer-readable media generally may correspond to (1) tangible computer-readable storage media which is non-transitory or (2) a communication medium such as a signal or carrier wave. Data storage media may be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code, and / or data structures for implementation of the techniques described in this disclosure. A computer program product may include a computer-readable medium.

[0092] By way of example, and not limitation, such computer-readable storage media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage, or other magnetic storage devices, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL) , or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. It should be understood, however, that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transitory media, but are instead directed to non-transitory, tangible storage media. Disk and disc, as used herein, includes compact disc (CD) , laser disc, optical disc, digital versatile disc (DVD) , floppy disk and Blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

[0093] Instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs) , general purpose microprocessors, application specific integrated circuits (ASICs) , field programmable logic arrays (FPGAs) , or other equivalent integrated or discrete logic circuitry. Accordingly, the term “processor, ” as used herein may refer to any of the foregoing structure or any other structure suitable for implementation of the techniques described herein. In addition, in some aspects, the functionality described herein may be provided within dedicated hardware and / or software modules configured for encoding and decoding, or incorporated in a combined codec. Also, the techniques could be fully implemented in one or more circuits or logic elements.

[0094] The techniques of this disclosure may be implemented in a wide variety of devices or apparatuses, including a wireless handset, an integrated circuit (IC) or a set of ICs (e.g., a chip set) . Various components, modules, or units are described in this disclosure to emphasize functional aspects of devices configured to perform the disclosed techniques, but do not necessarily require realization by different hardware units. Rather, as described above, various units may be combined in a codec hardware unit or provided by a collection of interoperative hardware units, including one or more processors as described above, in conjunction with suitable software and / or firmware.

[0095] Various examples have been described. These and other examples are within the scope of the following claims.

Claims

1.A method of communicating extended reality (XR) media data, the method comprising:determining a quality level for at least partially rendered frames of XR media data to be communicated; andcommunicating one or more of the at least partially rendered frames of XR media data at the determined quality level.2.The method of claim 1, wherein the at least partially rendered frames of XR media data include a base layer quality and one or more enhancement layer qualities.3.The method of any of claims 1 and 2, wherein communicating the one or more of the at least partially rendered frames comprises sending the one or more of the at least partially rendered frames.4.The method of any of claims 1 and 2, wherein communicating the one or more of the at least partially rendered frames comprises retrieving the at least partially rendered frames, the method further comprising completing rendering of the at least partially rendered frames.5.The method of any of claims 1–4, wherein determining the quality level comprises determining the quality level based on one or more of a channel quality indicator (CQI) , signal to interference plus noise ratio (SINR) , or available communication resources.6.The method of any of claims 1–5, wherein determining comprises determining by a transmitter.7.The method of any of claims 1–5, wherein determining comprises determining by a network device separate from a receiving device.8.The method of any of claims 1–5, wherein determining comprises determining by a receiving device.9.The method of any of claims 1–8, wherein the quality level is selected from a plurality of quality levels, each of the quality levels being associated with a respective codepoint.10.The method of claim 9, further comprising requesting the quality level using a request that specifies the respective codepoint for the determined quality level.11.The method of any of claims 1–10, wherein communicating the at least partially rendered frames comprises communicating protocol data units (PDUs) of one or more PDU Sets, the method further comprising communicating PDU Set metadata for the PDU Sets including data representing the determined quality level.12.The method of claim 11, wherein the data representing the determined quality level is included in a Real-time Transport Protocol (RTP) Header Extension of an RTP packet that encapsulates one or more of the PDUs.13.The method of claim 12, further comprising communicating the RTP Header Extension in a Session Description Protocol (SDP) message.14.The method of claim 13, wherein the SDP message comprises one of an SDP offer or an SDP answer.15.The method of any of claims 1–14, wherein the at least partially rendered frames include an intra-prediction encoded frame (I-frame) that is common to all available quality levels, and different inter-prediction encoded frames for each of the available quality levels.16.A device for communicating media data, the device comprising:a memory configured to store media data; anda processing system implemented in circuitry and configured to:determine a quality level for at least partially rendered frames of XR media data to be communicated; andcommunicate one or more of the at least partially rendered frames of XR media data at the determined quality level.17.The device of claim 16, wherein the at least partially rendered frames of AR media data include a base layer quality and one or more enhancement layer qualities.18.The device of any of claims 16 and 17, wherein to communicate the one or more of the at least partially rendered frames, the processing system is configured to send the one or more of the at least partially rendered frames.19.The device of any of claims 16 and 17, wherein to communicate the one or more of the at least partially rendered frames, the processing system is configured to retrieve the at least partially rendered frames, and wherein the processing system is further configured to complete rendering of the at least partially rendered frames.20.The device of any of claims 16–20, wherein the processing system is configured to determine the quality level based on one or more of a channel quality indicator (CQI) , signal to interference plus noise ratio (SINR) , or available communication resources.21.The device of any of claims 16–21, wherein the processing system includes a transmitter configured to determine the quality level.22.The device of any of claims 16–21, wherein the device comprises a network device that is separate from a receiving device.23.The device of any of claims 1–22, wherein the quality level is selected from a plurality of quality levels, each of the quality levels being associated with a respective codepoint.24.The device of claim 23, wherein the processing system is further configured to request the quality level using a request that specifies the respective codepoint for the determined quality level.25.The device of any of claims 16–24, wherein the processing system is configured to communicate protocol data units (PDUs) of one or more PDU Sets and to communicate PDU Set metadata for the PDU Sets including data representing the determined quality level.26.The device of claim 25, wherein the data representing the determined quality level is included in a Real-time Transport Protocol (RTP) Header Extension of an RTP packet that encapsulates one or more of the PDUs.27.The device of claim 26, wherein the processing system is further configured to communicate the RTP Header Extension in a Session Description Protocol (SDP) message.28.The device of claim 27, wherein the SDP message comprises one of an SDP offer or an SDP answer.29.The device of any of claims 16–28, wherein the at least partially rendered frames include an intra-prediction encoded frame (I-frame) that is common to all available quality levels, and different inter-prediction encoded frames for each of the available quality levels.30.A device for communicating media data, the device comprising:means for determining a quality level for at least partially rendered frames of XR media data to be communicated; andmeans for communicating one or more of the at least partially rendered frames of XR media data at the determined quality level.

Images