Indicating augmented reality (XR) perception and XR traffic characteristics

Abstract

The present disclosure provides methods and systems for wireless communication with traffic characteristics. A network entity (112) receives (324), from a core network (150), an indication of a parameter of a protocol data unit (PDU) session established between the network entity and a data network (160 / 170). These parameters may be specific to traffic characteristics. The parameters are in a converted format converted from an original format. The original formats of these parameters are used for traffic between the data network and the core network. The network entity updates the one or more wireless signaling configurations based on the parameters. The network entity communicates with the device using the updated one or more configurations. In some cases, the one or more configurations include a scheduling configuration for causing traffic flow to be scheduled by one or more of the following: a configured uplink grant, a semi-persistent uplink or downlink grant, and a dynamic uplink or downlink grant.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to and the benefit of U.S. Provisional Application No. 63 / 370,832, filed on August 9, 2022, entitled “INDICATING EXTENDED REALITY (XR) AWARENESS AND XR TRAFFIC CHARACTERISTICS,” under Article 8 of the Patent Cooperation Treaty (PCT), and U.S. Provisional Application No. 63 / 411,611, filed on September 29, 2022, entitled “INDICATING EXTENDED REALITY (XR) AWARENESS AND XR TRAFFIC CHARACTERISTICS,” the entire contents of which are expressly incorporated herein by reference. Technical Field

[0002] The present disclosure relates generally to wireless communications, and more particularly, to systems and methods for extended reality (XR) sensing and indicating XR traffic characteristics. Background Art

[0003] The 3rd Generation Partnership Project (3GPP) is currently in the process of specifying a new radio interface called 5G New Radio (5G NR) and the Next Generation Packet Core Network (NG-CN or NGC). The 5G NR architecture will have three components: 5G Radio Access Network (5G-RAN), 5G Core Network (5GC), and User Equipment (UE). To facilitate the implementation of different data services and requirements, 3GPP 5G NR cellular networks support network slicing, which enables virtualized and independent logical networks to be reused on the same physical network infrastructure.

[0004] Extended Reality (XR) includes various augmented reality, virtual reality, and mixed reality applications that leverage the advanced capabilities of 5G NR networks (e.g., low latency, high reliability, and high data transfer rates, etc.). XR services are characterized by strict requirements for periodicity, multiple streams, jitter avoidance, low latency, high reliability, etc. In contrast to video streaming, XR applications are real-time (or near real-time) and are expected to respond quickly to user movements and their commands and controls. XR video frames are expected to be delivered as soon as they are encoded by the codec, so XR traffic may suffer from jitter due to latency variations in encoding the video frames. The XR packet size is also variable. Therefore, given the characteristics of XR traffic, XR traffic presents a set of specific challenges for delivery over 5G NR networks. Summary of the invention

[0005] The present disclosure provides methods and techniques for implementing communication between a core network and a radio access network (RAN) with application customization such as extended reality (XR) for an application server so that the RAN can update the configured traffic characteristics of a user equipment (UE) device based on the perception of the application. The disclosed methods and techniques can be applied to fifth generation (5G) new radio (NR) network systems and later systems (e.g., 6G). For illustrative purposes, a 5G system is used as an example embodiment herein. At a high level, the present disclosure provides various techniques to convert traffic parameters (e.g., non-radio or general packet radio service (GPRS) tunneling protocol (GTP) parameters) from an application server to a core network into wireless signaling parameters from the RAN to a UE device so as to indicate application characteristics without significantly improving data transfer rates, delays, or other aspects without causing a negative impact on data transfer rates, delays, or other aspects (e.g., by supporting improved settings at RAN and UE devices).

[0006] For example, the present disclosure provides methods and techniques for converting (e.g., mapping, deriving, calculating, etc.) the original format of non-radio traffic at the core network (e.g., video applications related to cloud gaming, XR, etc.) into a new format indicating the properties of the radio traffic (e.g., congestion, fading, mobility / handover, channel quality). The new format can reuse existing fields such as Time Sensitive Communication Assistance Information (TSCAI) and / or Next Generation Application Protocol (NGAP) (e.g., control plane signaling between gNB and AMF) or add new fields to the Time Sensitive Communication Assistance Information and / or the Next Generation Application Protocol to support XR and similar applications.

[0007] XR may include augmented reality (AR), virtual reality (VR), and mixed reality (MR). VR immerses the user in a virtual environment, replacing the perception of the actual surrounding environment (e.g., the wearer of the VR device is not expected to feel the actual surrounding environment). AR provides a computer-generated overlay of the actual surrounding environment (e.g., floating graphics, signs, numbers, or text on top of objects in the actual surrounding environment), clearly indicating the virtual overlay. MR provides a realistic artificial overlay (e.g., a computer-generated item that is part of the perception of the actual surrounding environment). Therefore, XR requires instant and large amounts of data exchange between the UE device and the XR service provider.

[0008] These XR services are characterized by strict requirements for periodicity, multiple streams, jitter avoidance, low latency, high reliability, high data rates, etc. For example, cloud gaming typically uses a remote server to execute the gaming application, and therefore requires instant (e.g., real-time or near real-time) streaming of visual content, user controls, and feedback to the user. XR traffic can be quasi-periodic, with a period equal to the inverse of the frame rate. Due to the high frame rate requirements for XR applications, XR traffic may suffer from jitter due to latency variations in encoding video frames. The XR packet size is also variable. Therefore, given the XR traffic characteristics, XR traffic presents a set of specific challenges.

[0009] Various aspects of the present disclosure address the above and other deficiencies by enabling mutual awareness of the characteristics of application traffic at both the transmitting and receiving nodes. For example, mutual awareness between application functions at the 5G core and the RAN allows optimization of the end-to-end system to better support XR applications. On the application side, the application's awareness of 5G RAN radio parameters helps the application quickly adjust and adapt to RAN network conditions (e.g., congestion, switching, interference, beam blocking, etc.). Therefore, the RAN can proactively address potential degradation / changes in network conditions by, for example, adapting the codec rate of video encoding to achieve the desired quality of experience (QoE) and ensure good system capabilities. Conversely, the RAN's awareness of XR traffic characteristics (e.g., non-radio, IP packet characteristics) helps the RAN better schedule XR traffic.

[0010] According to aspects of the present disclosure, for example, a network entity such as a 5G RAN receives from a core network an indication of parameters of a protocol data unit (PDU) session established between the network entity and a data network. The parameters of the PDU session may be specific to traffic for an immersive experience (e.g., XR). The parameters are in a converted format converted from an original format. The data network and the core network use the original format of the parameters to transmit traffic between each other.

[0011] The network entity updates one or more wireless signaling configurations (e.g., updates a scheduling configuration with the UE device) based on the parameters of the PDU session. The network entity communicates with the UE device using the updated one or more configurations. In some cases, the one or more configurations include a scheduling configuration that schedules periodic and deterministic traffic flows via one or more of the following: a configured uplink grant, a semi-persistent uplink or downlink grant, and a dynamic uplink or downlink grant.

[0012] According to aspects of the present disclosure and complementary to the above, the core network receives application layer traffic in an original format from the data network. The core network converts the traffic from the original format to the converted format. The core network transmits an indication of parameters in the converted format to the RAN. The indication belongs to a PDU session established between the RAN and the data network. The indicated parameters of the PDU session include traffic for an immersive experience.

[0013] The network entity may receive an indication from one or more network functions of the core network. The one or more network functions may include an application function (AF). The AF may support XR applications. For example, the data network may be a network entity that provides a data stream encoded by a video codec to the core network through an XR server. The original format between the data network and the core network may conform to the Session Description Protocol (SDP).

[0014] The network entity may receive parameters indicating various aspects of the XR traffic and thus perceive the XR application. For example, these parameters include one or a combination of two or more of the following: periodicity of PDU sets; periodicity of video frames or slices; start time of the first PDU set, the first video frame, or the first video slice; identifier (ID) of the first PDU set, the first video frame, or the first video slice; information about the relationship of the PDUs, video frames, or video slices within the PDU set; indication of the last PDU in the PDU set; priority associated with the PDU set, video frame, or video slice; delay budget associated with the PDU set, video frame, or video slice; size of the PDU set, video frame, or video slice; and jitter statistics of the traffic.

[0015] In some cases, the converted format includes one or more fields and values ​​that are directly mapped from the fields and values ​​of the original format. In some cases, the converted format includes one or more fields and values ​​derived (e.g., calculated, transformed, or otherwise calculated) from the fields and values ​​of the original format. The converted format may include time-sensitive communication (TSC) assistance information (TSCAI) for TSC services. The traffic may be characterized by characteristics carried by the attributes of the TSCAI. TSCAI may include one or a combination of two or more of the following fields: traffic type; XR traffic flow; encryption key; group of pictures (GoP) information; synchronization information; and configuration granularity.

[0016] According to various aspects of the present disclosure, the original format between the data network and the core network includes a session description protocol (SDP), and the attributes of the TSCAI are in a mapping relationship with the attributes of the SDP. For example, the mapping relationship includes (1) one-to-one mapping, (2) many-to-one mapping, and (3) one-to-many mapping between the attributes of the SDP and the attributes of the TSCAI.

[0017] The data flow rate may be configured based on a type of video frame or a type of video slice, wherein the type of video frame includes at least one of: an I frame, a P frame, or a B frame, and wherein the type of video slice includes at least one of an I slice, a P slice, or a B slice. Fig.10 Examples related to I-frames or P-frames are briefly discussed.

[0018] According to aspects of the present disclosure, the converted format complies with the Next Generation Application Protocol (NGAP). The indication of the PDU session includes at least one of the following: a message of a PDU session resource setting request; or a message of a PDU session resource modification request. In some cases, the indication of the PDU session includes an information element (IE) of a message of a PDU session resource setting request or a message of a PDU session resource modification request. The IE may indicate one or a combination of two or more of the following: traffic periodicity; packet time; maximum packet time; burst arrival time; bandwidth; jitter statistics; encryption keys; frame duration; priority of video frames or slices; number of PDUs in a PDU set; and statistics of the size of a PDU set. Statistics of the size of a PDU set may include at least the following values: median, mean, standard deviation, maximum, and minimum measured in bits, bytes, or kilobytes.

[0019] The IE may further or alternatively indicate one or a combination of two or more of the following: statistics of video frames or slices, such as one or more of the following values: median, mean, standard deviation, maximum, and minimum measured in bits, bytes, or kilobytes; a delay budget, the delay budget including one or more of the following budgets: per application, per traffic flow, per video frame type, per video slice type, or per PDU set; group of pictures (GoP) information, the GoP information including at least one of the following: size of the GoP, start time of the GoP, time offset of the GoP, or type of video frame / slice in the GoP; and synchronization information. The synchronization information may include one or more of the following: synchronization requirements for each stream, dependencies between traffic streams, positive or negative time offsets relative to a master clock, positive or negative time offsets relative to a specific stream, and requests to adjust timing; and priorities of PDU sets.

[0020] Details of XP-aware configurations, PDU sets, NGAP IEs or groups, and various aspects of the present disclosure are discussed in detail below. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The described embodiments and their advantages may be best understood by referring to the following description taken in conjunction with the accompanying drawings, which in no way limit any changes in form and detail that may be made to the described embodiments by one skilled in the art without departing from the spirit and scope of the described embodiments.

[0022] Figure 1 is a block diagram depicting an example environment for indicating traffic characteristics between a core network 150 and a radio access network (RAN) 112 according to some embodiments;

[0023] Figure 2 is an example diagram depicting application awareness of traffic characteristics between a user equipment (UE) device 105, a RAN 112, a core network 150, and an application server 160 / 170 according to some embodiments;

[0024] Figure 3 is a signaling diagram depicting an example method of indicating traffic characteristics and updating a configuration based on the traffic characteristics according to some embodiments;

[0025] Figure 4 shows an example end-to-end application and RAN awareness between a UE device 105 and an application server 160 / 170 according to some embodiments;

[0026] Figure 5 is a flow chart depicting a method of wireless communication by a network entity indicating traffic characteristics according to some embodiments;

[0027] Figure 6 is a flow chart depicting a method of wireless communication by a core network according to some embodiments; and

[0028] Figure 7 An example table is shown that maps information from an application server to information (eg, configuration) between the RAN and a UE device in accordance with some embodiments.

[0029] Figure 8 An example table of information elements in a protocol data unit (PDU) session resource setup request is shown in accordance with some embodiments.

[0030] Fig. 9 An example table showing information elements for flow characteristics according to some embodiments.

[0031] Fig.10 Examples of video frame segmentation and data packetization for PDU sets according to some embodiments are shown. DETAILED DESCRIPTION

[0032] For ease of explanation, the following techniques are described in an example scenario in which one or more UE devices and a RAN implement one or more radio access technologies (RATs), which include at least a fifth generation (5G) new radio (NR) standard (e.g., third generation partnership project (3GPP) release 15, 3GPP release 16, etc.) (hereinafter "5GNR" or "5G NR standard"). However, the present disclosure is not limited to networks configured with 5G NR RATs, but the techniques described herein can be applied to any combination of different RATs adopted at UE devices and RANs. In addition, the present disclosure is not limited to the examples and scenarios described herein, but the techniques described herein can be applied to any network environment.

[0033] Figure 1 1 is a block diagram depicting an example environment 100 for indicating traffic characteristics between a core network 150 and a radio access network (RAN) 112 according to some embodiments. Communications between the core network 150 and the RAN 112 may include indications describing traffic characteristics of applications specific to a data network (DN), which may be a trusted DN 160 or an external DN 170 (e.g., a wired DN). For example, the indication may include parameters of a protocol data unit (PDU) session 157 established between the RAN 112 and the DN 160 or 170. The parameters for traffic between the DN 160 / 170 and the core network 150 may be in a first original format. The core network 150 may convert the parameters from the original format to a second converted format and provide the parameters in the converted format to the RAN 112. The RAN 112 may use the parameters to update configurations related to wireless communications with a user equipment (UE) device 105 based on the traffic characteristics.

[0034] In the discussion that follows, traffic characteristic specific configurations may be referred to as traffic awareness or "awareness". For example, the parameters may include attributes of time-sensitive communication assistance information (TSCAI) used to signal traffic characteristics from the DN 160 / 170 to the RAN 112. In some embodiments, the parameters may include information elements in a Next Generation Application Protocol (NGAP) message used to signal traffic characteristics. The RAN 112 may update or adjust settings such as connected mode discontinuous reception (C-DRX), semi-persistent scheduling (SPS), or cloud gaming based on the traffic characteristics.

[0035] like Figure 1 As shown, example environment 100 illustrates an example system architecture for a 5G system capable of delivering data (e.g., XR traffic) for extended reality (XR) applications. Figure 1, the relevant functions of the 5G system are shown, including the UE device 105, the RAN 112, and the core network (CN) 150. The CN 150 includes a user plane function (UPF) 155, a trusted data network (DN) 160, a policy control function (PCF) 162, and a network exposure function (NEF) 164. The XR specific functions or components may include a 5G-XR client 106 of the UE device 105, an application function (AF) 163 and an application server (AS) 166 in the trusted DN 160, and an AF 173 and an AS 176 in an external DN 170 that provides various XR applications. The external DN 170 may be a 5G-XR application provider that utilizes the functionality of the 5G system (e.g., coupled with the NEF 164 and UPF 155 of the 5G system). The UE device 105 including the 5G-XR aware application 107 may be a 5G-XR client 106 and network functions using a network interface and API.

[0036] XR may refer to a human-computer interaction experience enhanced or replaced with visual, auditory and / or tactile computer-generated objects. For example, XR may be one or more of augmented reality (AR), mixed reality (MR), virtual reality (VR), and interpolations between these XR variants. AR refers to artificially generated items or content that provide additional information to the user or are superimposed on the real surrounding environment. VR refers to a rendered version of a visual / audio scene (e.g., generated by a computer). MR refers to an advanced form of AR in which some virtual elements are inserted into a physical scene with the goal of providing the illusion that these elements are part of the real scene. In some cases, AR, MR, and VR are often referred to as immersive, which typically requires measuring the user's movements (e.g., six degrees of freedom) and providing near-instantaneous feedback to the user (e.g., via visual, audio, and tactile components).

[0037] Computer technologies (e.g., 3D graphics and measurement) and wearable technologies (e.g., motion sensors, visual and audio feedback, etc.) are enablers of XR. For example, human-machine communication and human-human communication utilize handheld and wearable end-user devices (e.g., UE devices). These technologies typically capture, generate, process, and communicate with large amounts of data in real time (or with strict low latency requirements). Figure 1As shown, the 5G-XR application 107 and the 5G-XR client 106 of the UE device 105 can capture user data and communicate user data with the RAN 112. The XR application 107 can obtain and process the user's data (e.g., via a camera, motion sensor, microphone, etc.) to upload to the DN 160 / 170 via the RAN 112 and the core network 150. The XR client 106 can process the received data and process the data from the DN 160 / 170. For example, the XR client 106 may include a modem for receiving and / or transmitting XR traffic. In some cases, the XR application 107 and the XR client 106 may be the same, or implemented in the same device, such as a modem and a VR display implemented on the same headset. For non-independent XR devices, a separate device can perform the functions of the XR application 107 and the XR client 106, such as a VR headset tethered to a mobile phone.

[0038] Cloud gaming is an example use case for XR, as cloud gaming can utilize AR, MR, or VR. Cloud gaming applications typically offload a large amount of computation from various UE devices (e.g., VR headsets, cameras, motion sensors, smartphones, etc.) to edge or remote servers. Cloud gaming and other XR use cases are typically characterized by quasi-periodic traffic (with possible jitter) and high downlink (DL) data rates (e.g., video streaming) combined with frequent uplink (UL) signaling (e.g., gesture / control updates and / or UL video streaming). In order to achieve cognitive presence and perceived presence, both DL traffic and UL traffic can be characterized by relatively strict packet delay budgets (PDBs) or threshold criteria. However, current discontinuous reception (DRX) configurations are not well suited for (i) non-integer XR traffic periodicity, (ii) variable XR data rates, and / or (iii) quasi-periodic XR periodicity. The present disclosure provides methods and techniques for meeting these XR-driven requirements.

[0039] The expected set of XR and cloud gaming services exhibit a certain diversity and characteristics of data streams (e.g., video), and these services may change "on the fly" or dynamically. Additional information from higher layers about the running services (e.g., QoS flow association, frame level QoS, PDU set based QoS, XR specific QoS, etc.) may be beneficial in facilitating the RAN 112 to make an informed choice of radio parameters. Awareness of XR applications by UE devices and network entities may improve the user experience, increase NR system capabilities in supporting XR services, and reduce UE power consumption (e.g., efficient radio parameters improve energy efficiency and can improve battery life for many small UE devices).

[0040] In current practice, XR interfaces typically require wired connections supported by high-speed data transfer rates. For example, VR headsets are typically wired to computer systems with high processing power. The computer system can be connected to an XR application (e.g., a server) via a digital subscriber line (DSL) or a fiber optic line that provides high-speed Internet access. However, compared to wired communications, current wireless communication standards may be limited for XR content. For example, XR traffic is typically quasi-periodic, with a periodicity that is the inverse of the XR frame rate. When high frame rates are required (e.g., typically above 60 to 120 frames per second), XR traffic may suffer from jitter due to delay variations at the codec used to encode the video frames. Jitter has been statistically modeled in 3GPP as a truncated Gaussian distribution with a standard deviation of 2 milliseconds (ms) and a range of ±4 ms (while 1 ms is expected for XR applications). In another example, the XR packet size may be variable due to the variability of the video frame content, and has also been statistically modeled in 3GPP as a truncated Gaussian distribution, thereby limiting the XR experience.

[0041] However, wireless XR or cloud gaming interfaces may provide an improved user experience, such as freedom of movement and removal of location or behavior restrictions (e.g., not being restricted to certain rooms or facilities and allowing running, dancing, or other behaviors that may otherwise be restricted by a wired connection). In addition, wireless XR services may also provide XR applications in areas where DSL or fiber networks are not available. The present disclosure provides methods and techniques for improving wireless communications between a data network and a UE device by tailoring network traffic between a core network and a RAN for traffic characteristics (e.g., by converting the format to better represent the traffic characteristics).

[0042] For example, awareness of traffic characteristics can enable the RAN and core networks to improve wireless communications in various scenarios. One scenario includes offline sharing of 3D objects, which can include sharing 3D models or objects and 3D MR scenes between users, such as by using a smartphone equipped with a depth camera for capturing and sharing 3D objects. Another scenario includes XR conferencing, which allows people to interact in a virtual environment and present 3D objects within the virtual environment (e.g., rather than in a document or on a screen).

[0043] Traffic awareness according to the present disclosure can improve support for these XR applications. For example, mutual awareness between the application server and the RAN helps optimize the end-to-end (E2E) system to better support XR applications. Traffic awareness (e.g., for XR traffic) can include awareness at both the application side and the RAN side.

[0044] On the application side, RAN awareness means that applications can quickly adjust and adapt to RAN network conditions (congestion, switching, interference, beam blocking, etc.) or proactively respond to potential degradation and changes in network conditions. Applications can adapt codec rates to help provide the desired quality of experience (QoE) and ensure good system capabilities.

[0045] On the RAN side, the RAN's awareness of the application can help to better schedule application-specific traffic (e.g., XR traffic). Awareness of traffic characteristics (e.g., frame periodicity, jitter, burst size, frame importance, frame correlation, etc.) helps the RAN to perform better scheduling (e.g., by adjusting SPS / C-DRX configuration) and perform better prioritization and discarding (e.g., discarding PDUs with lower importance belonging to a PDU set, or discarding a PDU set when some of the PDUs in the PDU set are missing). Detailed examples are discussed further below.

[0046] The core network 150 may convert the original format from the DN 160 / 170 based on the traffic characteristics and provide the transmission in the converted format to the RAN 112. The RAN 112 may update the scheduling configuration with the UE device 105 based on the traffic characteristics. For example, Figure 2 Demonstrates traffic awareness between network entities, while Figure 3 A call flow diagram showing format conversion and flow-aware configuration.

[0047] Figure 2 2 is an example diagram 200 of application awareness of traffic characteristics between a user equipment (UE) device 105, a RAN 112, a core network 150, and an application server 160 / 170 according to some embodiments. As shown, the XR server 160 / 170 can communicate XR traffic (e.g., SDP or other non-radio parameters) in a raw format 230 with the 5G core network 150. The 5G core network 150 converts the XR traffic in the raw format 230 to a converted format 232 to enable the RAN 112 to perceive the XR traffic. For example, the converted format 232 characterizes the video-related properties of the XR traffic. The RAN 112 can then update the configuration 240 with the UE device 105 to transmit signals based on the XR traffic (e.g., application awareness). In response, the UE device 105 can transmit signals to the RAN 112 based on the XR traffic.

[0048] Figure 33 is a signaling diagram 300 depicting an example method of indicating traffic characteristics and updating configuration based on traffic characteristics according to some embodiments. In a PDU session 157 established between the RAN 112 and the DN 160 / 170, the core network 150 receives 320 traffic in a raw format. The traffic includes XR traffic and other immersive experience traffic from the XR service of the DN 160 / 170. For example, the XR traffic may come from Figure 1 In an example, DN 160 / 170 may include an XR server, or otherwise provide a data stream encoded by a video codec to the core network.

[0049] As mentioned above, XR traffic characteristics can be classified as static (out-of-band signaling) and dynamic (in-band signaling). For example, XR traffic periodicity requires out-of-band signaling because it does not change very frequently. However, marking of PDUs in a PDU set requires in-band signaling because it is more dynamic. Therefore, the two categories of traffic characteristics may require two different mechanisms to signal from the XR server or video codec to the 5G-RAN. For dynamic signaling, the Real-time Transport Protocol (RTP) header can be used to signal dynamic traffic characteristics.

[0050] To signal static XR traffic characteristics (e.g., non-radio, IP packet characteristics) from an XR server or video codec to the RAN 112, the core network 150 receives 320 XR traffic in an original format from the XR server of the DN 160 / 170, converts 322 the traffic to a converted format, and transmits 324 the signal in the converted format to the RAN 112. The original format between the DN 160 / 170 and the core network 150 may include a Session Description Protocol (SDP). The converted format between the core network 150 and the RAN 112 may include Time Sensitive Communication (TSC) or a Next Generation Application Protocol (NGAP). The core network 150 may then convert the XR traffic characteristics (e.g., non-radio, IP packet characteristics) from SDP to TSC or from SDP to NGAP.

[0051] The conversion may include mapping or deriving from a value in one or more fields in the original format to a value in one or more fields in the converted format. For example, the core network 150 may perform the conversion in two methods. In the first method, the core network 150 maps a field in the original format to another field in the converted format, such as by mapping the SDP frame rate subfield to the TSCAI periodicity field. In the second method, the core network 150 may derive a value in the converted format (e.g., TSCAI periodicity) from a value in the original format (e.g., SDP frame rate). The derivation may be a calculation or transformation, such as, for example, from an index to a value in milliseconds, or vice versa.

[0052] The converted format may allow the RAN 112 to sense various characteristics of the XR traffic. For example, the sense may include: a) PDU sets, video frame / slice periodicity, or video frame rate (e.g., 60, 90, or 120 frames per second), b) the start time of the first PDU set or video frame / slice, c) an identification of a PDU set or video frame / slice, d) relationship information between PDUs or video frames / slices within the same PDU set, e) an indication of the end of a PDU set or an indication of the last PDU in a PDU set, f) a PDU set or video frame / slice priority and / or latency budget, g) a PDU set or video frame / slice size and / or the number of PDUs in a PDU set, and h) jitter statistics, such as the mean, standard deviation, and range (minimum and maximum) of the jitter. Each of these characteristics may be useful for updating configurations at the RAN 112 and the UE device 105.

[0053] like Figure 3As shown, the RAN 112 may update 326 configurations based on the received signal in the converted format to enable the UE device 105 to perceive traffic characteristics. These configurations may include scheduling configurations for enabling periodic and deterministic traffic flows to be scheduled via one or more of: configured grants, semi-persistent grants, and dynamic grants. For example, based on the traffic characteristics, the RAN 112 may update the configuration of: a) SPS or configured granted periodicity or C-DRX cycle length based on PDU set or video frame / slice periodicity, b) offset based on the start time of the first PDU set or video frame / slice, c) prioritizing PDUs in a PDU set or video frame / slice based on the identity of the PDU set or video frame / slice, d) dropping or prioritizing PDUs based on relationship information between PDUs, e) separation between PDU sets based on an indication of the last PDU in a set, f) prioritizing PDUs or video frames / slices from a PDU set based on a delay budget, g) C-DRX inactivity timer or SPS / cloud gaming resource allocation based on the number of PDUs in a PDU set, and h) C-DRX duration based on jitter statistics. The RAN 112 transmits the updated configuration to the UE device 105. The RAN 112 and the UE device 105 may then signal 328 each other under the updated configuration.

[0054] When the core network 150 converts the original format into the converted format, the original format and the converted format can be selected from a variety of formats. In one example, the converted format is in the form of TSC auxiliary information (TSCAI) with parameters configured according to information from a time-sensitive network (TSN) application function (AF). TSN allows Ethernet networks to provide quality of service (QoS) guarantees and deterministic connectivity. Both 5G ultra-reliable low-latency communication (URLLC) and TSN can implement applications with low latency and high reliability requirements. Therefore, TSCAI parameters can utilize the low latency characteristics for XR traffic. The perception of TSN traffic patterns can enable RAN 112 to efficiently schedule periodic, quasi-periodic (e.g., with jitter) and deterministic traffic flows, such as via configured grants, semi-persistent scheduling, or dynamic grants. For example, TSC traffic characteristics may include flow direction (e.g., uplink or downlink), periodicity (e.g., the time period between the start of two bursts), burst arrival time (e.g., the latest possible time that the first packet of a data burst arrives at the ingress interface of the RAN or the egress interface of the UE), and survival time (e.g., the time period that an application can survive without any data bursts).

[0055] In another example, the converted format is in the format of NGAP that allows control plane signaling between the RAN 112 and an Access and Mobility Function (AMF) of the core network 150.

[0056] In some implementations, the RAN 112 includes a central unit (CU) and a distributed unit (DU). The CU receives the converted format in the format of NGAP or TSCA from the AMF. In one implementation, the CU transmits the parameters in the converted format to the DU, for example, in the F1 application protocol (F1AP). For example, the CU may transmit a first F1AP message including these parameters to the DU. In another implementation, the CU transmits the parameters in the converted format to the DU in TSCAI. In response, the DU updates the configuration as described above and transmits a second F1AP message including the updated configuration to the CU. The CU generates an RRC message including the updated configuration and transmits a third F1AP message including the RRC message to the DU. In one example, the RRC message is an "RRCReconfiguration" message. Then, the DU transmits the RRC message to the UE device 105. In one example, the first F1AP message is a "UE Context Setup Request" or a "UE Context Modification Request" message. In one example, the second F1AP message is a "UE Context Setup Response", "UE Context Modification Response" or "UE Context Modification Required" message. In one example, the third F1AP message is a "DL RRC Message Transfer" message.

[0057] Figure 4 An example 400 of end-to-end application and RAN awareness between a UE device 105 and an application server 160 / 170 according to some embodiments is shown. Specifically, Figure 4Traffic characteristic specific communications for the user plane 431 and the control plane 432 in the core network 150 are shown. As shown, the RAN 112 can communicate with multiple UE devices 105. For example, the UE device 105 may include a VR headset, AR glasses, a smartphone, and / or a wearable device equipped with a modem or tethered to a device equipped with a modem. The RAN 112 and the core network 150 communicate in a converted format (e.g., TSCAI or NGAP) on either or both of the control plane 432 or the user plane 431. As shown, the control plane 432 may include an AMF 422, a session management function (SMF) 424, a network data analysis function (NWDAF) 426, and a PCF 162, as well as other functions not shown.

[0058] Figure 5 500 is a flowchart depicting a method of wireless communication indicating traffic characteristics by a network entity according to some embodiments. The method is performed by processing logic, which includes hardware (e.g., circuit system, dedicated logic, programmable logic, processor, processing device, central processing unit (CPU), system on chip (SoC), etc.), software (e.g., instructions and / or applications running / executing on a processing device), firmware (e.g., microcode), or a combination thereof. The method of flowchart 500 is performed by, for example, Figures 1 to 4 The network entity may include one or more radio frequency (RF) modems, a processor coupled to the one or more RF modems, and at least one non-transitory memory storing executable instructions to manipulate at least one of the processor or the RF modem to perform the method of flowchart 500.

[0059] refer to Figure 5 , the method illustrates example functionality used by various embodiments. Although specific functional blocks ("boxes") are disclosed in the method, such boxes are examples. That is, the embodiments are well suited to performing various other boxes or variations of boxes set forth in the method. It should be understood that the boxes in the method may be executed in an order different from the order presented, and not all boxes in the method may be executed.

[0060] like Figure 5 As shown, the method includes block 524: receiving from the core network an indication of parameters of a protocol data unit (PDU) session established between a network entity and a data network (eg, Figure 3Operation 324 of . The parameters are in a converted format converted from an original format. The data network sends the parameters in the original format to the core network. For example, the network entity includes a RAN (e.g., RAN 112) that receives a service data unit (SDU) from one or more network functions of the core network. The one or more network functions may include an AF. The immersive experience may include an XR application.

[0061] The SDU received from one or more network functions of the core network may include at least one of the following: periodicity of PDU sets; periodicity of video frames or slices; start time of the first PDU set, the first video frame, or the first video slice; an identifier (ID) of the first PDU set, the first video frame, or the first video slice; information about the relationship of PDUs, video frames, or video slices within the PDU set; an indication of the last PDU in the PDU set; a priority associated with the PDU set, video frame, or video slice; a delay budget associated with the PDU set, video frame, or video slice; the size of the PDU set, video frame, or video slice; and jitter statistics for the traffic.

[0062] The method includes block 526 of updating, at a network entity, one or more wireless signaling configurations (eg, Figure 3 Operation 326 of ). These configurations may include scheduling configurations for causing periodic and deterministic traffic flows to be scheduled via one or more of: configured grants, semi-persistent grants, and dynamic grants.

[0063] The method includes block 528 of communicating with a UE device using the updated one or more configurations (eg, Figure 3 Operation 328). For example, the updated one or more configurations may include at least one of: a connected mode discontinuous reception (C-DRX) cycle for data traffic of XR media based on a periodicity attribute of the TSCAI; a C-DRX start offset for data traffic of XR media based on a burst arrival time attribute of the TSCAI; a C-DRX inactivity timer for data traffic of XR media based on a frame duration attribute of the TSCAI; or a C-DRX enablement duration for data traffic of XR media based on a jitter or jitter statistics attribute of the TSCAI.

[0064] Figure 6600 is a flowchart depicting a method of wireless communication by a network entity according to some embodiments. The method is performed by processing logic, which includes hardware (e.g., circuit system, dedicated logic, programmable logic, processor, processing device, central processing unit (CPU), system on chip (SoC), etc.), software (e.g., instructions and / or applications running / executing on a processing device), firmware (e.g., microcode), or a combination thereof. The method of flowchart 600 is complementary to the method of flowchart 500 and is performed by, for example, Figures 1 to 4 The core network 150 of the core network is executed. The core network may include one or more radio frequency (RF) modems, a processor coupled to the one or more RF modems, and at least one non-transitory memory storing executable instructions to manipulate at least one of the processor or the RF modem to perform the method of flowchart 600.

[0065] like Figure 6 As shown, the method includes block 620: receiving traffic in a raw format (eg, Figure 3 The method includes block 622: converting, by the network entity, the traffic from an original format to a converted format (e.g., Figure 3 The method includes block 624 of transmitting parameters in the converted format to the RAN, the parameters characterizing the PDU session established between the RAN and the data network (e.g., Figure 3 Operation 324). The parameters of the PDU session may include traffic received from the wired data network.

[0066] Referring to both methods of flowcharts 500 and 600, in some embodiments, the converted format includes one or more fields and values ​​directly mapped from the fields and values ​​of the original format. The converted format includes one or more fields and values ​​derived from the fields and values ​​of the original format.

[0067] When the converted format includes TSC assistance information (TSCAI) for a time sensitive communication (TSC) service, the traffic is characterized by characteristics carried by attributes of the TSCAI. For example, the converted format may include at least one of the following fields: traffic type, XR traffic flow, encryption key, group of pictures (GoP) information, synchronization information; or configuration granularity.

[0068] In some cases, the original format between the data network and the core network conforms to SDP, and the attributes of TSCAI are in a mapping relationship with the attributes of SDP. The mapping relationship may include (1) one-to-one mapping, (2) many-to-one mapping, and / or (3) one-to-many mapping between the attributes of SDP and the attributes of TSCAI.

[0069] In various aspects, the parameters of the PDU session include one of the following signals or a combination of two or more of the following signals. For example, the parameters include a signal of a video frame or slice priority for data traffic of XR media based on one of the attributes of the TSCAI. The parameters include a signal of the number of PDUs in a PDU set for data traffic of XR media based on one of the attributes of the TSCAI. The parameters include a signal of statistics of the size of the PDU set for data traffic of XR media based on one of the attributes of the TSCAI, wherein the statistics of the size of the PDU set include at least the following values: median, mean, standard deviation, maximum and minimum values ​​measured in bits, bytes or kilobytes.

[0070] The parameters may include signals of statistics of video frames or slices for data traffic of XR media based on one of the attributes of the TSCAI, wherein the statistics of the PDU set size include at least the following values: median, mean, standard deviation, maximum, and minimum measured in bits, bytes, or kilobytes. The parameters include signals of a delay budget based on one of the attributes of the TSCAI, wherein the delay budget includes one or more of the following budgets: per application, per traffic flow, per video frame type, per video slice type, or per PDU set. The parameters include signals of group of pictures (GoP) information based on one of the TSCAI attributes. The GoP information includes at least one of the following: the size of the GoP, the start time of the GoP, the time offset of the GoP, or the type of video frame / slice in the GoP.

[0071] The parameters may include a signal of synchronization information based on one of the attributes of the TSCAI, wherein the synchronization information includes one or more of: synchronization requirements for each flow, dependencies between traffic flows, positive or negative time offsets relative to a master clock, positive or negative time offsets relative to a specific flow, and requests to adjust timing. Examples of parameters of the attributes of the TSCAI are described in Figure 7 0 and described below.

[0072] In various aspects, the RAN may update one or more configurations by configuring a first set of characteristics for traffic according to a quality of service (QoS) flow; or configuring a second set of characteristics for traffic according to a type of video frame or a type of video slice. The type of video frame may include at least one of an I frame, a P frame, or a B frame, and the type of video slice may include at least one of an I slice, a P slice, or a B slice. Reference Fig.10 The video frame example is briefly discussed.

[0073] In various aspects, the wired data network configures traffic based on the type of video frame and / or the type of video slice. The type of video frame may include at least one of the following: I frame, P frame, or B frame. The type of video slice may include at least one of I slice, P slice, or B slice. Examples of video frames or slices are described in Fig.10 and are further described below.

[0074] When the converted format includes NGAP, the indication of the parameters of the PDU session may include: a message of a PDU session resource setting request; or a message of a PDU session resource modification request. For example, the indication of the parameter may include an information element (IE) in the message. The IE may indicate one or a combination of two or more of the following: traffic periodicity; packetization time; maximum packetization time; burst arrival time; bandwidth; jitter statistics; encryption key; frame duration; priority of a video frame or slice; and the number of PDUs in a PDU set.

[0075] The IE may also indicate statistics of the PDU set size. The statistics of the PDU set size include at least the following values: median, mean, standard deviation, maximum and minimum values ​​measured in bits, bytes or kilobytes. The IE may also indicate statistics of video frames or slices, which include at least the following values: median, mean, standard deviation, maximum and minimum values ​​measured in bits, bytes or kilobytes.

[0076] The IE may also indicate a delay budget including one or more of the following budgets: per application, per traffic flow, per video frame type, per video slice type, or per PDU set. The IE may also indicate group of pictures (GoP) information including at least one of the following: the size of the GoP, the start time of the GoP, the time offset of the GoP, or the type of video frame / slice in the GoP. The IE may indicate synchronization information including one or more of the following: synchronization requirements for each stream, dependencies between traffic flows, positive or negative time offsets relative to a master clock, positive or negative time offsets relative to a specific stream, and requests to adjust timing. The IE may also indicate the priority of the PDU set.

[0077] A PDU set may include at least one of: an identifier (ID) of the PDU set; a tag; a timestamp; a sequence number; a delay budget; a reliability requirement; the number of PDUs in the PDU set; the codec layer associated with the PDU set; information about necessary PDUs; or the start and end of the PDU set; a priority of the PDU set. A PDU set may also include an indication of whether the PDU set is associated with at least one of the following: an I-frame, a P-frame, a B-frame, an I-slice, a P-slice, or a B-slice. A PDU set may include an indication of whether the PDU set is associated with at least one of the following: field of view (FoV), non-FoV, a baseline layer, an enhancement layer, virtual reality (VR) traffic, media traffic, or haptic traffic. A PDU set may include an indication of correlation or dependency with other PDU sets.

[0078] In some cases, the PDU set is signaled in a field of a general packet radio service (GPRS) tunneling protocol (GTP) user data (GTP-U) header, wherein the field is specific to traffic for the immersive experience. The PDU set may be signaled in a field of a PDU session container of the GTP-U header, wherein the field is specific to traffic for the immersive experience. In some cases, at least a portion of the PDU set is mapped from a differentiated services code point (DSCP) to the GTP-U header.

[0079] Figure 7 An example table 700 is shown for mapping information from an application server to information (e.g., configuration) between the RAN and the UE device according to some embodiments. When the converted format is TSCAI, the core network 150 can map to existing attributes (e.g., Figure 7 "0" in the "New Fields in TSCAI" column of the TSC stream) or adding new attributes to the TSCAI of the TSC stream (for example, Figure 7 12) to signal the traffic specific information to the RAN 112. Table 700 lists the TSCAI (“Assistance Information”) with the expected mapping to the 5G-RAN configuration for XR traffic (“Mapping to 5G-RAN configuration for XR traffic”).

[0080] The mapping may use the SDP protocol, which is a format used by entities to agree on compatible media types and parameters for interactions such as voice and video. Mapping of some SDP attributes to some TSC existing or new attributes may be used to signal traffic characteristics to the RAN 112. For example, in the existing fields, the TSCAI "periodicity" attribute is mapped to XR / cloud gaming and / or media traffic periodicity, which may be useful for configuring C-DRX cycles, SPS periodicity, and configured grant periodicity. To obtain periodicity information, the SDP frame rate attribute (a=framerate:) may be mapped to the TSCAI "periodicity".

[0081] Sometimes a conversion other than mapping may be required. For example, in TSCAI, the periodicity is at the packet level, whereas for XR traffic, the periodicity is at the "PDU set" and / or video slice / frame level. Therefore, the RAN 112 may interpret the TSCAI "periodicity" attribute differently depending on whether the TSCAI periodicity is for XR and media services or for any other service (e.g., URLLC). To clarify this potential ambiguity, a new TSCAI attribute may be added, such as Figure 7 As shown, the new attribute can be used to indicate the service or signal different attributes. For example, the new attribute can signal whether the periodicity is at the packet level or at the "PDU set" or video frame / slice level. The interpretation of "periodicity" may depend on whether other attributes (such as jitter attributes or "PDU set" priority attributes) have been enabled to provide context to avoid different interpretations.

[0082] For example, a new TSCAI attribute may be specified to signal the video frame size or video frame duration (e.g., in ms). This size / duration information may be useful for 5G RAN configurations such as the DRX inactivity timer.

[0083] During conversion, TSCAI attributes may be mapped from SDP packet time attributes. For example, the maximum packet time (e.g., a=maxptime:<maximum packet time> ) can be used to indicate the maximum amount of media / duration that can be encapsulated in each packet, expressed as a time in milliseconds. Packet time a=ptime:<packet time> Defined as the length of time in milliseconds represented by the media in the packet.

[0084] The TSCAI may indicate to the RAN 112 the start time of a particular flow to help improve scheduling by configuring, for example, the C-DRX periodicity start offset. For example, the existing TSN attribute "burst arrival time" may be used to indicate this information to the RAN 112. The TSN attribute "burst arrival time" may be derived from the SDP attribute "t= <starttime>"Sure.

[0085] The TSCAI may indicate the bandwidth to the RAN 112 to help improve scheduling by better planning resource allocation. The RAN 112 may use the information of the bandwidth that the application is planning to allocate for the service / flow to decide and report whether the RAN 112 can meet the required bandwidth. As shown in Table 700, a new TSCAI attribute (e.g., bandwidth) may be used to signal the bandwidth to the 5G RAN. The TSCAI attribute may be derived from the SDP attribute "bandwidth" that specifies the bandwidth to be used by the session or media. The unit of bandwidth may be Kbps or Mbps.

[0086] The TSCAI may indicate jitter statistics, which are estimated and signaled to the RAN 112 at the codec level or at the 5G AF 163 / 173. As shown in Table 700, new TSC attributes (e.g., jitter average, STD, maximum, minimum) may be added to signal jitter statistics to the RAN 112. The core network 150 may use an algorithm to estimate jitter and derive jitter statistics at the 5G AF 163 / 173 or at the codec level (using filtering / averaging methods). Jitter statistics may be signaled per media stream (audio, video, etc.) or / and per video frame / slice type.

[0087] The TSCAI may indicate an encryption key, as shown in Table 7. If delivered over a secure and trusted path, an encryption key for deep packet inspection of information that may be encrypted at the codec or application layer is indicated to the RAN 112. The RAN 112 may use the encryption key to retrieve information that may be useful for optimizing scheduling and QoE. For example, the TSCAI encryption key attribute may be derived from the SDP attribute "Encryption Key" that specifies the encryption key for all media in the session.

[0088] Table 700 provides descriptions and mappings of various TSCAI fields or entries that are not discussed in detail herein. Table 700 may further include other fields not shown or listed. A person of ordinary skill in the art may use the information in Table 700 and add additional fields of a similar nature (e.g., for characterizing various aspects of a particular traffic from a data network) to implement the example conversions provided herein. Although Table 700 uses 5G RAN and XR traffic as examples, the mapping or conversion techniques may be applicable to other wireless communication systems and other traffic types.

[0089] Figure 8 An example table 800 of information elements in a protocol data unit (PDU) session resource setup request according to some embodiments is shown. As discussed above, the converted format may include an NGAP message. New information elements (IEs) may be included in an NGAP message (e.g., a PDU session resource setup request or a PDU session resource modification request message) to describe traffic characteristics, as shown in Table 800 (and Fig. 9 As shown in Table 900 of . For NGAP, a "PDU session resource setup request" can be used. The AMF (e.g., AMF 422) can send a PDU session resource setup request to request the RAN 112 to assign resources for one or more PDU session resources (e.g., PDU session 157) on Uu and NG-U. A "PDU session resource modification request message" can also be used. For example, the AMF 422 can send this message to request the RAN 112 to enable modification of established PDU session resources for a given UE device 105. As shown in Table 800, the PDU session resource setup request list and items can indicate traffic characteristics. In addition, Table 800 may include a new "XR traffic characteristics" field for further XR traffic indication. Fig. 9 The corresponding example for IE is discussed in .

[0090] Fig. 9 An example table 900 of IEs for traffic characteristics according to some embodiments is shown. As shown in table 900, an example IE or IE group may be limited / assigned to a "PDU Session Resource Setup Request" and / or a "PDU Session Resource Modification Request message". An example IE may be added to specifically signal traffic periodicity. Alternatively, "periodicity" may be part of an information element that identifies some traffic characteristics.

[0091] An example IE or IE group may be defined / assigned to a "PDU session resource setup request" and / or a "PDU session resource modification request message". An example IE may be added to specifically signal a "packet time" or a "maximum packet time". Alternatively, the "packet time" or the "maximum packet time" may be part of an IE that identifies some traffic characteristics. An example IE or IE group may be defined / assigned to a "PDU session resource setup request" and / or a "PDU session resource modification request message". An example IE may be added to specifically signal a "burst arrival time". Alternatively, the "burst arrival time" may be part of an information element that identifies some traffic characteristics.

[0092] An example IE or IE group may be limited / assigned to a "PDU session resource setup request" and / or a "PDU session resource modification request message". An example IE may be added to specifically signal "bandwidth". Alternatively, "bandwidth" may be part of an information element identifying some traffic characteristics. An example IE or IE group may be limited / assigned to a "PDU session resource setup request" and / or a "PDU session resource modification request message". An example IE may be added to specifically signal "jitter statistics". Alternatively, "jitter statistics" may be part of an information element identifying some traffic characteristics.

[0093] An example IE or group of IEs may be defined / assigned to a "PDU Session Resource Setup Request" and / or a "PDU Session Resource Modification Request message". An example IE may be added to specifically signal an "encryption key". Alternatively, the "encryption key" may be part of an information element that identifies some traffic characteristics.

[0094] Table 900 may include fields of a General Packet Radio Service (GPRS) Tunneling Protocol (GTP) User Data (GTP-U) header. This field may be specific to the traffic of the immersive experience. The PDU set may be signaled in a field of the PDU session container of the GTP-U header, where the field is specific to the traffic of the immersive experience. In some cases, at least a portion of the PDU set is mapped from a Differentiated Services Code Point (DSCP) to the GTP-U header. The UPF of the 5G core network uses the GTP-U header to transfer data to the RAN. The PDU session container is included in the GTP-U header to identify the QoS flow. The GTP-U header may be used to carry information about a "PDU set".

[0095] Fig.10 An example 1000 of video frame segmentation and data packetization into a PDU set according to some embodiments is shown. Example 1000 provides an example IP packetization into a PDU set with core network delay information and jitter information. The illustration of the IP packet is in the context of gradual decoding refresh (GDR), but can also be applied to instantaneous decoder refresh (IDR). GDR allows random access and stable data rates, and is therefore more suitable for network transmission. In the illustration, the video frame for the right eye and the video frame for the left eye are aggregated in a single video frame. The video frame for the left eye and the video frame for the right eye can be interlaced or aligned. In the GDR model, a video frame consists of multiple video slices (e.g., 4 slices, 8 slices, ...). One of the slices is an I slice for refreshing the image, and the remaining slices are P slices. The transformation from video trace (V-trace) to slice trace (S-trace) consists of concatenated video slices. The transformation from slice tracking (S-trace) to packet tracking (P-trace) consists of packetization (e.g., based on Ethernet maximum transmission unit (MTU)). The PDU set in the figure consists of a group of PDUs sharing the same QoS requirements.

[0096] GDR is used for ultra-low latency applications such as XR traffic. During operation, if the decoder starts decoding in the middle of the encoded stream and follows the above signaling, the decoder can obtain a fully updated reconstructed frame when the indicated gradual decoder refresh conditions are met. For example, a p-frame (e.g., a change from a reference i-frame representing a complete image) can reconstruct the frame with low latency. As shown in example 1000, packets can be streamed in a sequence of p-frames and i-frames for each eye (e.g., for a VR headset as a UE device 105). In contrast, an IDR is a header that the encoder writes to the data stream to signal the decoder to reset the reference.

[0097] During operation, reference frames are stored in a buffer for use in recovering subsequent frames (e.g., by including changes from the reference frame). However, when an IDR is received, the decoder can reset the reference frame and start the decoding process without a reference. This happens when the reference frame is no longer needed for further decoding (e.g., when the user rewinds the video stream to another timestamp). For example, the decoder seeks the beginning of a GOP, decodes an i-frame and resets the old reference frame. When an IDR is present, the decoder may fill the buffer with a new reference frame. An IDR can be placed on an i-frame. Not all i-frames include an IDR. Therefore, i-frames and p-frames have significantly different sizes in transmission, resulting in volume fluctuations. In GDR, fluctuations are suppressed by having an i-frame in each of the transmission slices (e.g., one i-frame with multiple p-frames).

[0098] As shown in example 1000, a PDU set may include a grouping of slices from multiple frames from each eye. As discussed above, the converted format of the parameters indicating traffic characteristics (e.g., specific to XR traffic) may indicate PDU and PDU set information (e.g., relationship, priority, budget, discard, etc.). Although a PDU set may take other content or formats, example 1000 provides an example implementation of a PDU set.

[0099] Unless otherwise specifically indicated, terms such as "establishing", "receiving", "transmitting" or others refer to actions and processes performed or implemented by a computing device that manipulate data represented as physical (electronic) quantities within registers and memories of the computing device into other data similarly represented as physical quantities within the computing device memory or registers or other such information storage, transmission or display devices. In addition, the terms "first", "second", "third", "fourth", etc. as used herein are intended as labels to distinguish different elements and may not necessarily have ordinal meanings according to their numerical designations.

[0100] The examples described herein also relate to an apparatus for performing the operations described herein. The apparatus may be specially constructed for the desired purpose, or the apparatus may include a general-purpose computing device selectively programmed by a computer program stored in the computing device. Such a computer program may be stored in a computer-readable non-transitory storage medium.

[0101] The methods and illustrative examples described herein are not inherently related to any particular computer or other device. Various general purpose systems may be used according to the teachings described herein, or more specialized devices may be conveniently constructed to perform the required method steps. The required structures of a variety of these systems will be presented as described above.

[0102] The above description is intended to be illustrative rather than restrictive. Although the present disclosure has been described with reference to specific illustrative examples, it will be appreciated that the present disclosure is not limited to the described examples. The scope of the present disclosure should be determined with reference to the following claims and the full scope of equivalents to which the claims are authorized.

[0103] As used herein, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should be further understood that the terms "include", "comprises", and / or "contains" when used herein specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. Therefore, the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting.

[0104] It should also be noted that in some alternative implementations, the functions / actions noted may not occur in the order noted in the figures. For example, two figures shown in succession may actually be performed substantially simultaneously or may sometimes be performed in reverse order, depending on the functionality / actions involved.

[0105] Although the method operations are described in a particular order, it should be understood that other operations may be performed between the described operations, that the described operations may be adjusted so that they occur at slightly different times, or that the described operations may be distributed in a system that allows the processing operations to occur at various intervals associated with the process.

[0106] Various units, circuits, or other components may be described or claimed as being "configured to" or "configurable to" perform one or more tasks. In such contexts, the phrases "configured to" or "configurable to" are used to represent a structure by indicating that a unit / circuit / component includes a structure (e.g., a circuit system) that performs one or more tasks during operation. Thus, even if a specified unit / circuit / component is not currently operating (e.g., not turned on), it can be said that the unit / circuit / component is configured to perform a task, or is configurable to perform a task. Units / circuits / components used with the "configured to" or "configurable to" language include hardware, such as circuits, memories storing program instructions executable to implement operations, and the like. The recitation that a unit / circuit / component is "configured to" perform one or more tasks, or is "configurable to" perform one or more tasks is expressly intended not to invoke the sixth paragraph of 35 USC §112 with respect to that unit / circuit / component. Additionally, "configured to" or "configurable to" may include general purpose structures (e.g., general purpose circuitry) manipulated by software and / or firmware (e.g., an FPGA or a general purpose processor executing software) to operate in a manner capable of performing the tasks in question. "Configured to" may also include adjusting a manufacturing process (e.g., a semiconductor manufacturing facility) to manufacture a device (e.g., an integrated circuit) adapted to implement or perform one or more tasks. "Configurable to" is expressly intended not to apply to blank media, an unprogrammed processor or unprogrammed general purpose computer, or an unprogrammed programmable logic device, programmable gate array, or other unprogrammed device, unless accompanied by a programming medium that imparts to the unprogrammed device the ability to be configured to perform the disclosed functionality.

[0107] For the purpose of explanation, the above description has been described with reference to specific embodiments. However, the above illustrative discussion is not intended to be exhaustive or to limit the disclosure to the precise form disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments are selected and described in order to best explain the principles of the embodiments and their practical application, so that those skilled in the art can best utilize the embodiments and various modifications that may be suitable for the intended specific use. Therefore, the present embodiments are to be regarded as illustrative and not restrictive, and the disclosure is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims. Example aspects

[0108] Example 1 is a method of wireless communication performed by a network entity, the method comprising: receiving, from a core network, an indication of a parameter of a protocol data unit (PDU) session established between the network entity and a data network, wherein the parameter is in a converted format converted from an original format, the original format of the parameter being used for traffic between the data network and the core network; updating, at the network entity, one or more radio signaling configurations based on the parameters of the PDU session; and Communicating with a user equipment (UE) device using the updated one or more configurations.

[0109] Example 2 is a method according to Example 1, wherein the one or more configurations include a scheduling configuration for a traffic flow scheduled via one or more of: the configured permissions; semi-permanent permission; and Dynamic grant for downlink or uplink transmission.

[0110] Example 3 is a method according to Example 1, wherein: The network entity comprises a radio access network (RAN) that receives a service data unit (SDU) from one or more network functions of the core network, wherein the one or more network functions comprises an application function (AF); Immersive experiences include extended reality (XR) applications; or The native format between the data network and the core network includes a Session Description Protocol (SDP).

[0111] Example 4 is a method according to any one of Examples 1 to 3, wherein the data network includes an XR server, or wherein the data network provides a data stream encoded by a video codec to the core network.

[0112] Example 5 is a method according to any one of Examples 1 to 4, wherein the SDU includes one or a combination of two or more of the following: The periodicity of the PDU set; The periodicity of video frames or slices; A start time of a first PDU set, a first video frame, or a first video slice; an identifier (ID) of the first PDU set, the first video frame, or the first video slice; information about a relationship between the PDUs in the PDU set, the video frames or the video slices; an indication of the last PDU in the PDU set; a priority associated with the PDU set, the video frame or the video slice; a delay budget associated with the PDU set, the video frame, or the video slice; The size of the PDU set, the video frame or the video slice; and Jitter statistics of the traffic.

[0113] Example 6 is a method according to Example 1 or 3, wherein the converted format includes one or more fields and values ​​directly mapped from the fields and values ​​of the original format.

[0114] Example 7 is a method according to example 1 or 3, wherein the converted format includes one or more fields and values ​​derived from the fields and the values ​​of the original format.

[0115] Example 8 is a method according to Example 6 or 7, wherein the converted format includes TSC assistance information (TSCAI) of a time sensitive communication (TSC) service, and wherein the traffic is characterized by characteristics carried by attributes of the TSCAI.

[0116] Example 9 is the method of Example 8, wherein the converted format includes one or a combination of two or more of the following fields: Traffic type; XR traffic flow; Encryption keys; Group of Pictures (GoP) information; Synchronize information; and Configuration granularity.

[0117] Example 10 is a method according to Example 8, wherein the original format between the data network and the core network complies with the Session Description Protocol (SDP), and the attributes of the TSCAI are mapped to the attributes of the SDP.

[0118] Example 11 is a method according to Example 10, wherein the mapping relationship includes (1) one-to-one mapping, (2) many-to-one mapping, and (3) one-to-many mapping between the attributes of the SDP and the attributes of the TSCAI.

[0119] Example 12 is a method according to Example 1, wherein the traffic is configured based on the type of video frame or the type of video slice, wherein the type of video frame includes at least one of the following: I frame, P frame or B frame, and wherein the type of video slice includes at least one of the following: I slice, P slice or B slice.

[0120] Example 13 is the method of Example 8, wherein updating the one or more configurations at the network entity comprises one or a combination of two or more of the following: configuring a connected mode discontinuous reception (C-DRX) period for data traffic of the XR media based on the periodic attribute of the TSCAI; configuring a C-DRX start offset of the data traffic of the XR media based on a burst arrival time attribute of the TSCAI; configuring a C-DRX inactivity timer for the data traffic of XR media based on a frame duration attribute of the TSCAI; and A C-DRX enablement duration of the data traffic of XR media is configured based on the jitter or jitter statistical attributes of the TSCAI.

[0121] Example 14 is a method according to Example 8, wherein the parameters of the PDU session include one or a combination of two or more of the following: signaling of a video frame or slice priority for the data traffic of XR media based on one of the attributes of the TSCAI; a signal of a number of PDUs in the PDU set for the data traffic of XR media based on one of the attributes of the TSCAI; a signal of statistics of PDU set sizes for the data traffic of XR media based on one of the attributes of the TSCAI, wherein the statistics of PDU set sizes include at least the following values: median, mean, standard deviation, maximum, and minimum measured in bits, bytes, or kilobytes; a signal of statistics of video frames or slices of the data traffic for XR media based on one of the attributes of the TSCAI, wherein the statistics of the PDU set size include at least the following values: median, mean, standard deviation, maximum, and minimum measured in bits, bytes, or kilobytes; a signal of a delay budget based on one of the attributes of the TSCAI, wherein the delay budget comprises one or more of the following budgets: per application, per traffic flow, per video frame type, per video slice type, or per PDU set; a signal of group of pictures (GoP) information based on one of the attributes of the TSCAI, wherein the GoP information includes at least one of: a size of the GoP, a start time of the GoP, a time offset of the GoP, or a type of video frame / slice in the GoP; and A signal of synchronization information based on one of the attributes of the TSCAI, wherein the synchronization information includes one or more of: synchronization requirements for each flow, dependencies between traffic flows, positive or negative time offsets relative to a master clock, positive or negative time offsets relative to a specific flow, and a request to adjust timing.

[0122] Example 15 is the method of Example 1, wherein updating the one or more configurations at the network entity comprises at least one of: configuring a first set of characteristics for the traffic according to a Quality of Service (QoS) flow; or A second characteristic set of the traffic is configured according to a type of video frame or a type of video slice, wherein the type of video frame includes at least one of an I frame, a P frame, or a B frame, and the type of video slice includes at least one of an I slice, a P slice, or a B slice.

[0123] Example 16 is a method according to Example 6 or 7, wherein the converted format includes a next generation application protocol (NGAP).

[0124] Example 17 is the method of Example 16, wherein the indication of the parameter of the PDU session comprises at least one of: PDU Session Resource Setup Request message; or PDU session resource modification request message.

[0125] Example 18 is a method according to Example 17, wherein the indication of the parameter of the PDU session comprises an information element (IE) of the message of the PDU session resource setup request or the message of the PDU session resource modification request, the IE indicating one or a combination of two or more of the following: Traffic periodicity; Grouping time; Maximum grouping time; Burst arrival time; bandwidth; Jitter statistics; Encryption keys; Frame duration; The priority of the video frame or slice; The number of PDUs in the PDU set; Statistics of PDU set sizes, wherein the statistics of PDU set sizes include at least the following values: median, mean, standard deviation, maximum and minimum values ​​measured in bits, bytes or kilobytes; Statistics of a video frame or slice, the statistics including at least the following values: median, mean, standard deviation, maximum and minimum values ​​measured in bits, bytes or kilobytes; a delay budget, the delay budget comprising one or more of the following budgets: per application, per traffic flow, per video frame type, per video slice type, or per PDU set; Group of pictures (GoP) information, the group of pictures information comprising at least one of: a size of the GoP, a start time of the GoP, a time offset of the GoP, or a type of video frame / slice in the GoP; synchronization information, the synchronization information including one or more of: synchronization requirements for each flow, dependencies between traffic flows, positive or negative time offsets relative to a master clock, positive or negative time offsets relative to a specific flow, and requests to adjust timing; and The priority of the PDU set.

[0126] Example 19 is the method of Example 5, wherein the PDU set includes one or a combination of two or more of the following: The ID of the PDU set; Label; Timestamp; Serial number; Delayed budget; Reliability requirements; The number of PDUs in the PDU set; a codec layer associated with the PDU set; Information about basic PDUs; The start and end of the PDU set; The priority of the PDU set; an indication of whether the PDU set is associated with at least one of: an I frame, a P frame, a B frame, an I slice, a P slice, or a B slice; an indication of whether the PDU set is associated with at least one of: field of view (FoV), non-FoV, baseline layer, enhancement layer, virtual reality (VR) traffic, media traffic, or haptic traffic; and Correlations or dependencies with other PDU sets.

[0127] Example 20 is a method according to Example 19, wherein the PDU set is signaled in a field of a general packet radio service (GPRS) tunneling protocol (GTP) user data (GTP-U) header, wherein the field is specific to the traffic of the immersive experience.

[0128] Example 21 is a method according to Example 20, wherein the PDU set is signaled in a field of a PDU session container of the GTP-U header, wherein the field is specific to the traffic of the immersive experience.

[0129] Example 22 is the method of Example 20, wherein at least a portion of the PDU set is mapped from a Differentiated Services Code Point (DSCP) to the GTP-U header.

[0130] Example 23 is a method of wireless communication performed by a network entity, the method comprising: receiving traffic in a raw format from a wired data network; converting, by the network entity, the traffic from the original format to a converted format, wherein the converted format characterizes a video-related property of the traffic; and Parameters in the converted format are transmitted to a radio access network (RAN), the parameters characterizing a protocol data unit (PDU) session established between the RAN and the data network, wherein the parameters of the PDU session include the traffic received from the wired data network.

[0131] Example 24 is a method according to Example 23, wherein the network entity includes a core network that transmits a service data unit (SDU) to the RAN, the core network including one or more network functions having at least one application function (AF); and The traffic includes traffic for immersive experience of extended reality (XR) applications.

[0132] Example 25 is the method of Example 23, wherein the original format between the data network and the network entity comprises a Session Description Protocol (SDP).

[0133] Example 26 is a method according to any one of Examples 23 to 25, wherein the data network includes an XR server, or wherein the data network provides a data stream encoded by a video codec to the network entity.

[0134] Example 27 is a method according to any one of Examples 23 to 26, wherein the SDU includes one or a combination of two or more of the following: The periodicity of the PDU set; The periodicity of video frames or slices; A start time of a first PDU set, a first video frame, or a first video slice; an identifier (ID) of the first PDU set, the first video frame, or the first video slice; information about a relationship between the PDUs in the PDU set, the video frames or the video slices; an indication of the last PDU in the PDU set; a priority associated with the PDU set, the video frame or the video slice; a delay budget associated with the PDU set, the video frame, or the video slice; The size of the PDU set, the video frame or the video slice; and Jitter statistics of the traffic.

[0135] Example 28 is a method according to Example 23 or 25, wherein the converted format includes one or more fields and values ​​directly mapped from the fields and values ​​of the original format.

[0136] Example 29 is a method according to Example 23 or 25, wherein the converted format includes one or more fields and values ​​derived from the fields and values ​​of the original format.

[0137] Example 30 is a method according to Example 28 or 29, wherein the converted format includes TSC assistance information (TSCAI) of a time sensitive communication (TSC) service, and wherein the traffic is characterized by characteristics carried by attributes of the TSCAI.

[0138] Example 31 is a method according to Example 30, wherein the converted format includes one or a combination of two or more of the following fields: Traffic type; XR traffic flow; Encryption keys; Group of Pictures (GoP) information; Synchronize information; and Configuration granularity.

[0139] Example 32 is a method according to Example 30, wherein the original format between the data network and the core network complies with the Session Description Protocol (SDP), and the attributes of the TSCAI are mapped to the attributes of the SDP.

[0140] Example 33 is a method according to Example 32, wherein the mapping relationship includes (1) one-to-one mapping, (2) many-to-one mapping, and (3) one-to-many mapping between the attributes of the SDP and the attributes of the TSCAI.

[0141] Example 34 is a method according to Example 23, wherein the traffic is configured based on the type of video frame or the type of video slice, wherein the type of video frame includes at least one of the following: I frame, P frame or B frame, and wherein the type of video slice includes at least one of the following: I slice, P slice or B slice.

[0142] Example 35 is a network entity comprising: one or more radio frequency (RF) modems; a processor coupled to the one or more RF modems; and At least one memory storing executable instructions for manipulating the processor or at least one of the one or more RF modems to perform a method according to any one of Examples 1 to 22.

[0143] Example 36 is a network entity, the network entity comprising: one or more radio frequency (RF) modems; a processor coupled to the one or more RF modems; and At least one memory storing executable instructions for manipulating the processor or at least one of the one or more RF modems to perform a method according to any one of Examples 23 to 34.< / starttime>

Claims

1. A method of wireless communication performed by a network entity (112), the method comprising: receiving (324) from a core network (150) an indication of parameters of a protocol data unit (PDU) session established between the network entity and a data network (160), wherein the parameters are in a converted format converted from an original format, the original format of the parameters being used for traffic (320) between the data network and the core network; updating (326) a wireless signaling configuration at the network entity based on the parameters of the PDU session; and The updated configuration is used to communicate with the user equipment (UE) device (328).

2. The method of claim 1, wherein: The configuration includes a scheduling configuration for a traffic flow scheduled via at least one of: the configured permissions; a semi-permanent grant; or Dynamic grant for downlink or uplink transmission.

3. The method of claim 1, wherein: The network entity comprises a radio access network RAN ​​(424) receiving a service data unit SDU from a network function of the core network, wherein: The network functions include application functions AF; Immersive experiences include applications of extended reality (XR); or The original format between the data network and the core network includes a Session Description Protocol SDP.

4. The method according to any one of claims 1 to 3, wherein: The data network includes an XR server, or wherein the data network provides a data stream encoded by a video codec to the core network.

5. The method according to any one of claims 1 to 4, wherein: The SDU includes at least one of the following: The periodicity of the PDU set; The periodicity of video frames or slices; A start time of a first PDU set, a first video frame, or a first video slice; an identifier ID of the first PDU set, the first video frame, or the first video slice; information about a relationship between the PDUs in the PDU set, the video frames or the video slices; an indication of the last PDU in the PDU set; a priority associated with the PDU set, the video frame or the video slice; a delay budget associated with the PDU set, the video frame, or the video slice; The size of the PDU set, the video frame or the video slice; or Jitter statistics of the traffic.

6. The method according to claim 1 or 3, wherein: The converted format includes one or more fields and values ​​that are directly mapped from the fields and values ​​of the original format.

7. The method according to claim 1 or 3, wherein: The converted format includes one or more fields and values ​​derived from the fields and values ​​of the original format.

8. The method according to claim 6 or 7, wherein: The converted format includes TSC assistance information TSCAI of a time sensitive communication TSC service, and wherein the traffic is characterized by characteristics carried by attributes of the TSCAI, and wherein the converted format includes one or a combination of two or more of the following fields: Traffic type; XR traffic flow; Encryption keys; Picture group GoP information; Synchronize information; and Configuration granularity.

9. The method according to any one of claims 1 to 8, wherein: The traffic is configured based on a type of video frame or a type of video slice, wherein the type of video frame includes at least one of the following: I frame, P frame or B frame, and wherein the type of video slice includes at least one of the following: I slice, P slice or B slice.

10. The method of claim 1, wherein: Updating the configuration at the network entity comprises at least one of: Configuring a first set of characteristics for the traffic according to a Quality of Service (QoS) flow; or A second characteristic set of the traffic is configured according to a type of video frame or a type of video slice, wherein the type of video frame includes at least one of an I frame, a P frame, or a B frame, and the type of video slice includes at least one of an I slice, a P slice, or a B slice.

11. The method according to claim 6 or 7, wherein: The converted format comprises a new generation application protocol (NGAP), and wherein the indication of the parameter of the PDU session comprises at least one of: PDU Session Resource Setup Request message; or PDU session resource modification request message.

12. The method of claim 11, wherein: The indication of the parameter of the PDU session includes an information element IE of the message of the PDU session resource setting request or the message of the PDU session resource modification request, the IE indicating one or a combination of two or more of the following: Traffic periodicity; Grouping time; Maximum grouping time; Burst arrival time; bandwidth; Jitter statistics; Encryption keys; Frame duration; The priority of the video frame or slice; The number of PDUs in the PDU set; Statistics of PDU set sizes, wherein the statistics of PDU set sizes include at least the following values: median, mean, standard deviation, maximum and minimum values ​​measured in bits, bytes or kilobytes; Statistics of a video frame or slice, the statistics including at least the following values: median, mean, standard deviation, maximum and minimum values ​​measured in bits, bytes or kilobytes; a delay budget, the delay budget comprising one or more of the following budgets: per application, per traffic flow, per video frame type, per video slice type, or per PDU set; Group of pictures (GoP) information, the GoP information including at least one of: a size of the GoP, a start time of the GoP, a time offset of the GoP, or a type of video frame / slice in the GoP; synchronization information, the synchronization information comprising one or more of: synchronization requirements for each flow, dependencies between traffic flows, positive or negative time offsets relative to a master clock, positive or negative time offsets relative to a specific flow, or requests to adjust timing; and The priority of the PDU set.

13. A method of wireless communication performed by a network entity (150), the method comprising: receiving (320) traffic in a raw format from a wired data network (160); converting (322), by the network entity, the traffic from the original format to a converted format, wherein the converted format characterizes a video-related property of the traffic; as well as Parameters in the converted format are transmitted (324) to a radio access network RAN ​​(112), the parameters characterizing a protocol data unit (PDU) session established between the RAN and the data network, wherein the parameters of the PDU session include the traffic received from the wired data network.

14. The method of claim 13, wherein: The network entity comprises a core network that transmits a service data unit SDU to the RAN, the core network comprising a network function including at least one application function AF; and The traffic includes traffic for immersive experience of extended reality (XR) applications.

15. The method of claim 13, wherein: The original format between the data network and the network entity includes a Session Description Protocol SDP.

16. The method according to any one of claims 13 to 15, wherein: The SDU includes at least one of the following: The periodicity of the PDU set; The periodicity of video frames or slices; A start time of a first PDU set, a first video frame, or a first video slice; an identifier ID of the first PDU set, the first video frame, or the first video slice; information about a relationship between the PDUs in the PDU set, the video frames or the video slices; an indication of the last PDU in the PDU set; a priority associated with the PDU set, the video frame or the video slice; a delay budget associated with the PDU set, the video frame, or the video slice; The size of the PDU set, the video frame or the video slice; or Jitter statistics of the traffic.

17. The method of claim 13, wherein: The traffic is configured based on a type of video frame or a type of video slice, wherein the type of video frame includes at least one of the following: an I frame, a P frame, or a B frame, and wherein the type of video slice includes at least one of the following: an I slice, a P slice, or a B slice.

18. A network entity, comprising: one or more radio frequency (RF) modems; a processor coupled to the one or more RF modems; as well as At least one memory storing executable instructions for manipulating at least one of the processor or the one or more RF modems to perform the method according to any one of claims 1 to 17.

Images