Techniques for congestion indication in augmented reality signaling

Abstract

The application relates to devices and components, including apparatuses, systems, and methods for congestion indication in augmented reality signaling.

Description

Technical Field

[0001] The present application relates generally to communication networks, and in particular to techniques for congestion detection in such networks. Background Art

[0002] Low Latency Low Loss Scalable Throughput (L4S) is based on Internet Engineering Task Force (IETF) standardized technology. L4S provides high throughput and low latency for Internet Protocol (IP) services, which can result in improved fast radio adaptation management and reduce network congestion, queuing and packet loss. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] Figure 1 A network environment according to some embodiments is illustrated.

[0004] Figure 2 Data bursts are illustrated according to some embodiments.

[0005] Figure 3 The transmission and reception of PDU groups according to some embodiments is illustrated.

[0006] Figure 4 An operational flow / algorithm structure according to some embodiments is illustrated.

[0007] Figure 5 Another operational flow / algorithm structure according to some embodiments is illustrated.

[0008] Figure 6 Another operational flow / algorithm structure according to some embodiments is illustrated.

[0009] Figure 7 User equipment according to some embodiments is shown.

[0010] Figure 8 A network node according to some embodiments is illustrated. DETAILED DESCRIPTION

[0011] The following specific embodiments relate to the accompanying drawings. The same reference numerals may be used to identify the same or similar elements in different drawings. In the following description, specific details, such as specific structures, architectures, interfaces and / or technologies, are set forth for the purpose of illustration rather than limitation, so as to provide a thorough understanding of various aspects of some embodiments. However, it will be apparent to those skilled in the art who benefit from the present disclosure that various aspects of the various aspects may be practiced in other examples that depart from these specific details. In some cases, descriptions of well-known devices, circuits and methods are omitted so as not to obscure the descriptions of various aspects due to unnecessary details. For the purposes of this document, the phrase "A or B" refers to (A), (B) or (A and B); and the phrase "based on A" refers to "based at least in part on A", for example, it may be "based only on A" or it may be "based in part on A".

[0012] The following is a glossary of terms that may be used in this disclosure.

[0013] As used herein, the term "circuit" refers to, is part of, or includes a hardware component such as an electronic circuit, a logic circuit, a processor (shared, dedicated, or group) or a memory (shared, dedicated, or group) configured to provide the described functionality, an application specific integrated circuit (ASIC), a field programmable device (FPD) (e.g., a field programmable gate array (FPGA), a programmable logic device (PLD), a complex PLD (CPLD), a high capacity PLD (HCPLD), a structured ASIC, or a programmable system on chip (SoC)), and / or a digital signal processor (DSP). In some aspects, a circuit may execute one or more software or firmware programs to provide at least some of the described functionality. The term "circuit" may also refer to a combination of one or more hardware elements and a program code for performing the functions of the program code (or a combination of circuits used in an electrical or electronic system). In these aspects, the combination of hardware elements and program code may be referred to as a specific type of circuit.

[0014] As used herein, the term "processor circuit" refers to, is part of, or includes: a circuit capable of sequentially and automatically performing a series of arithmetic or logical operations; or recording, storing, or transferring digital data. The term "processor circuit" may refer to an application processor; a baseband processor; a central processing unit (CPU); a graphics processing unit; a single-core processor; a dual-core processor; a triple-core processor; a quad-core processor; or any other device capable of executing or otherwise operating computer-executable instructions (such as program code); a software module; or a functional process.

[0015] As used herein, the term "interface circuit" refers to, is a part of, or includes a circuit that enables information exchange between two or more components or devices. The term "interface circuit" may refer to one or more hardware interfaces; for example, a bus, an I / O interface, a peripheral component interface, a network interface card, etc.

[0016] As used herein, the term "user equipment" or "UE" refers to a device that has radio communication capabilities and can describe a remote user of network resources in a communication network. In addition, the terms "user equipment" or "UE" may be considered synonymous and may be referred to as a client, mobile phone, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio equipment, reconfigurable radio equipment, reconfigurable mobile device, etc. In addition, the term "user equipment" or "UE" may include any type of wireless / wired device or any computing device that includes a wireless communication interface.

[0017] As used herein, the term "computer system" refers to any type of interconnected electronic devices, computer devices, or components thereof. Additionally, the term "computer system" or "system" may refer to various components of a computer that are communicatively coupled to one another. Furthermore, the term "computer system" or "system" may refer to multiple computer devices or multiple computing systems that are communicatively coupled to one another and configured to share computing resources or networked resources.

[0018] As used herein, the term "resource" refers to a physical or virtual device, a physical or virtual component within a computing environment, or a physical or virtual component within a specific device, such as a computer device, a mechanical device, a memory space, a processor / CPU time, a processor / CPU usage, a processor and accelerator load, a hardware time or usage, a power supply, an input / output operation, a port or a network socket, a channel / link allocation, throughput, memory usage, storage, a network, a database and an application, a unit of work, etc. "Hardware resources" may refer to computer, storage or network resources provided by physical hardware elements. "Virtualized resources" may refer to computer, storage or network resources provided by a virtualized infrastructure to an application, device, system, etc. The term "network resource" or "communication resource" may refer to a resource that a computer device / system can access via a communication network. The term "system resource" may refer to any kind of shared entity that provides a service, and may include computing resources or network resources. System resources may be considered as a set of coherent functions, network data objects or services that can be accessed through a server, wherein such system resources reside on a single host or multiple hosts and can be clearly identified.

[0019] As used herein, the term "channel" refers to any tangible or intangible transmission medium for conveying data or data streams. The term "channel" may be synonymous or equivalent to "communication channel", "data communication channel", "transmission channel", "data transmission channel", "access channel", "data access channel", "link", "data link", "carrier", "radio frequency carrier" or any other similar term representing a path or medium through which data is transmitted. In addition, as used herein, the term "link" refers to a connection made between two devices for sending and receiving information.

[0020] As used herein, the terms "instantiate," "instantiate," and the like refer to the creation of an instance. "Instance" also refers to a specific occurrence of an object, which may occur, for example, during the execution of program code.

[0021] The term "connected" may mean that two or more elements at a common communication protocol layer have an established signaling relationship with each other through a communication channel, link, interface, or reference point.

[0022] As used herein, the term "network element" refers to physical or virtualized equipment or infrastructure for providing wired or wireless communication network services. The term "network element" may be considered synonymous with or referred to as a networked computer, networking hardware, network equipment, network node, virtualized network function, etc.

[0023] The term "information element" refers to a structural element that contains one or more fields. The term "field" refers to a single content of an information element or a data element that contains content. An information element may include one or more additional information elements.

[0024] Current L4S technology relies on explicit congestion notifications (ECNs) in the IP header to indicate queue buildup in intermediate routers or radio links. Upon ECN reception, congestion signals may be propagated back to the sender. These signals may be sent via a Transmit Control Protocol (TCP) ECN-echo that triggers an extensible congestion control algorithm. A TCP Congestion Window Reduction (CWR) bit may be sent back to acknowledge receipt of a congestion indication response to the receiver. Similar signaling may be supported on other Layer 4 (L4) protocols such as QUIC.

[0025] When congestion is detected, the application server or application can adjust the application bit rate to meet the capacity of the established communication link. Therefore, L4S can deliver a seamless user experience even under variable traffic load and radio conditions.

[0026] Changing the ECN bit in the IP header to signal congestion when a queue starts to grow can be called marking. ECN / L4S uses the two least significant bits of the traffic class field in the IPv4 or IPv6 header to encode four different code points. In ECN, congestion marking is equivalent to packet dropping. In L4S, congestion marking is used as an indication instead of dropping packets.

[0027] L4S allows for relatively fine-grained congestion control based on the application (e.g., with active queue management (AQM) and scalable TCP). L4S allows for improved queue utilization and better use of network resources. If applied to radio, it can allow for better spectrum utilization. A router or node using AQM can immediately signal the EC when a high latency or high buffering state is detected.

[0028] Figure 1 A network environment 100 is illustrated according to some embodiments. The network environment 100 may provide extended reality (XR) services.

[0029] Briefly, the network environment 100 may include a user equipment (UE) 104 having an XR-aware application 108 and an XR client 112. The XR-aware application 108 (which may also be referred to as an XR application 108) may be a source or destination of XR traffic related to XR services. The XR client 112 may be an internal function of the UE 104 dedicated to XR services.

[0030] The UE 104 may be coupled to a radio access network (RAN) 116 via a Uu interface. The RAN 116 may include one or more base stations (e.g., gNBs), integrated access and backhaul (IAB) nodes, etc. that provide the UE 104 with radio access to a core network (CN) 118.

[0031] The RAN 116 may be coupled to a user plane function (UPF) 120 of the CN 118 via an N3 interface. The UPF 120 may be responsible for routing and forwarding user plane packets between the RAN 116 and one or more data networks (DNs). The UPF 120 may handle the user plane path of a protocol data unit (PDU) session.

[0032] As shown, UPF 120 may be coupled to DN 124 via an N6 interface. DN 124 may be a trusted DN or an external DN including an XR application function (AF) 128 and an XR application server (AS) 132 dedicated to XR services.

[0033] The components of the network environment can operate in a manner compatible with fifth generation (5G) or later networks. For example, unless otherwise described herein, aspects of the network environment 100 can be compatible with XR use cases and media services similar to those described in 3GPP Technical Report (TR) 26.928, v17.0.0 (2022-04-07).

[0034] The XR services supported by the network environment 100 may require deterministic behavior with a defined quality of service (QoS). This may involve multiple flows with different QoS requirements. The payload may typically be periodic.

[0035] In some embodiments, the XR-aware application 108 may operate on application data units (ADUs) (e.g., groups of PDUs), or bursts of data represented by larger chunks of data, where each "chunk" of application layer data includes a series of IP packets. Such application layer data may be delivered in bursts, often in a relatively periodic manner. A burst may include a group of ADUs, where each ADU is sent in multiple smaller data packets, such as real-time transport protocol (RTP) packets mapped to packet data convergence protocol (PDCP) service data units (SDUs).

[0036] Figure 2 204 that an XR-aware application 108 may send or receive. A data burst may be a bit stream of interrelated application data. The data may correspond to an application, such as, for example, an XR application. The bit stream may be divided into a plurality of PDU groups, which may be equivalent to ADUs in the context of XR. A PDU group may be sent in a plurality of smaller data packets (e.g., RTP packets mapped to PDCP SDUs). Although Figure 2 Each PDU group is shown to have m PDCP SDUs, but different PDU groups may have different numbers of PDCP SDUs.

[0037] As mentioned above, ECN / L4S is an end-to-end mechanism that depends on the capabilities of the transport network. It can enable faster codec rate adaptation at the endpoints and can help maintain low latency and high throughput.

[0038] From the perspective of the radio interface, it may be interesting to communicate whether there is congestion at the radio layer or even within the 5G system. In particular at the air interface, usually only one bit is sufficient. This bit can be expressed as a congestion experience (CE) bit that is transmitted to the upper layers and converted into a corresponding representation at the IP layer. ECN, L4S and CE are used interchangeably in this article.

[0039] Support for XR services can benefit from low latency and high throughput. Congestion signaling that enables the network environment 100 to be XR-aware can help reduce latency, keep throughput stable, and provide a desired user experience.

[0040] Some embodiments address situations where QoS is driven by groups of packets rather than individual packets. Specifically, embodiments describe how QoS can be driven for PDU groups such as Figure 2 The embodiments also describe how congestion indications can be used to trigger adjustments to the processing of XR traffic flows and PDU groups.

[0041] The present disclosure describes methods for a network (e.g., RAN 116 or UPF 120) or UE 104 to handle PDU groups in XR with awareness of CE indications. Aspects include CE marking of PDU groups and packets in PDU groups, actions to alleviate congestion, and application to XR traffic.

[0042] To accommodate XR traffic, the CN 118, RAN 116, and UE 104 may benefit from being able to identify: different PDU groups (e.g., to distinguish between them); PDUs belonging to each PDU group; dependencies between PDU groups; and dependencies of PDUs within a PDU group. Being able to identify these features may potentially lead to the introduction of additional L2 headers with fields for identifying PDU groups and new types of PDUs therein.

[0043] The embodiments describe enhancements to CE indication for UE 104, RAN 116, and CN 118 when PDU groups are supported.

[0044] A PDU group that has experienced congestion in the CN 118 or in the RAN 116 may be treated differently from a PDU group that has not yet experienced congestion. Congestion information may be visible from the CE bit at the radio interface in the UE 104, RAN 116, or CN 118.

[0045] The detection and indication of congestion related information for a PDU group may occur through various L2 sublayers and be transmitted to upper layers. For example, congestion may be detected / indicated based on the PDCP / Service Data Adaptation Protocol (SDAP) layer (using a separate queue), through the Radio Link Control (RLC) layer, or through the Medium Access Control (MAC) layer. Alternatively, the PDU group may carry the CE indication itself.

[0046] Generally, detection of congestion events may occur by comparing the operational status to various predetermined thresholds. The operational status may be associated with the state of a queue or buffer (e.g., fill percentage, amount of data, etc.), the number of retransmissions, the number of acknowledgments, whether a packet is determined to be successfully transmitted within a period of time (e.g., based on a delay budget or drop timer), the reception or transmission of a packet within an expected time period, sojourn time, round trip time, the size of a gap in sequence numbers, quality of service (QoS) parameters, quality of experience (QoE) parameters, etc.

[0047] Congestion may be indicated by including one or more CE bits in transmitted packets or by one or more layers providing inter-layer signaling.A CE bit may be used to provide a CE set indication (to indicate that congestion is experienced) or a CE clear indication (to indicate that congestion is not experienced).

[0048] While many embodiments describe congestion as existing in a binary state, eg, congestion either exists or does not exist, other embodiments may provide for different levels of congestion to be detected / signaled in a similar manner.

[0049] In some embodiments, two CE bits may be used to allow support for use cases where full end-to-end ECN / L4S consistency may be desired. The two bits may correspond to code points according to the ECN code points shown in Table 1 below or the L4S code points shown in Table 2 below.

[0050] Binary code point Code point name meaning 00 Non-ECT Non-ECN capable transport 01 ECT(1) ECN-capable transport 10 ECT(0) ECN-capable transport 11 CE Congestion experience

[0051] Table 1

[0052] Binary code point Code point name meaning 00 Non-ECT Non-ECN capable transport 01 ECT(1) L4S-capable transport 10 ECT(0) Non-L4S capable transport 11 CE Congestion experience

[0053] Table 2

[0054] These code points may be similar to the code points described in IETF RFC 3168.

[0055] In some embodiments, upon identifying that a PDU group has experienced congestion, the RAN 116 or UE 104 may change the handling of the PDU group. For example, the RAN 116 or UE 104 may increase the priority level for the PDU group to ensure faster scheduling; treat the PDU group as a PDU group with higher importance; adjust the LCH priority of the DRB or QoS flow associated with the XR service flow to a higher priority level; enable PDCP duplication for the PDU group; adjust the radio resource allocation to ensure that the remaining packets in the PDU group are allocated more reliable resources; allocate additional radio resources to the UE to immediately schedule any remaining next packets; enter a survival time (e.g., enter a survival state or mode in which an application needs to receive a data burst within a set period of time in order to maintain a connection) until the congestion condition is cleared; notify the upper layer of the congestion condition; or notify the congestion condition to a subsequent network node.

[0056] In some embodiments, when the transmitter determines that congestion is being experienced, the layer 2 configuration such as the logical channel (LCH) settings (e.g., logical channel prioritization (LCP) mapping restriction rules) may be changed. For example, the PDCP layer may switch between RLC entities with different LCH configurations to process the PDCP PDUs. This may be done to select an RLC entity that can provide faster transmission of the underlying XR service.

[0057] In some embodiments, layer 1 (L1) parameters may be adjusted to facilitate the transmission of XR traffic that is experiencing congestion. For example, when the transmitter senses that a PDU group has experienced congestion, L1 parameters such as configured grant (CG) / semi-persistent scheduling (SPS) configuration, modulation and coding scheme (MCS), number of repetitions, and transmit power may be changed.

[0058] When congestion of a traffic flow or data burst is detected, the UE 104 or RAN 116 may adjust the processing of the PDU groups based on the importance associated with each PDU group. For example, some PDU groups may be considered to have relatively greater importance than other PDU groups. For example, consider a video compression standard such as H.264, in which video may be sent as an intra-coded picture (I) frame, a predicted (P) frame, or a bidirectional predicted (B) frame. I frames may serve as references for other frames and are therefore associated with higher importance than B / P frames. Therefore, if congestion is detected, some embodiments may prioritize the transmission of more important PDU groups (such as I frames) over PDU groups with lower importance (e.g., P frames). In embodiments in which prioritization has been implemented, the detected congestion may be used as a basis for increasing the relative prioritization of more important PDU groups. Additionally / alternatively, when congestion is detected, the transmitter may discard PDU groups with lower importance or apply congestion policies (regarding scheduling rules and prioritization) as defined by the network.

[0059] In some embodiments, congestion may be indicated by a CE field within a packet at various layers of the communication protocol, the CE field carrying one or more CE bits, as described elsewhere herein. The congestion indication may then trigger one or more of the above measures.

[0060] In some embodiments, congestion level information may be exposed by the UE 104 or CN 118 to the RAN 116 in a separate parameter, such as auxiliary information. The congestion level information may be provided in level (e.g., high, medium, or low congestion (or some other demarcation)) steps, or as a percentage of packets or PDU groups that have experienced congestion over a period of time. In some embodiments, exposing the congestion level information may allow for finer granularity control of scheduling policies, or may help direct any desired retransmissions of PDU groups. These functions in the UE 104, RAN 116, or CN 118 may be considered XR-aware functions.

[0061] Some embodiments may utilize a new packet header associated with a PDU group carrying XR traffic for CE indication. The packet header may be extended to allow one or more CE bits. This may be based on one or more of the following options.

[0062] Figure 3 The transmission and reception of PDU groups according to some embodiments are illustrated. At 304, two PDU groups, PDU Group #1 and PDU Group #2, may be generated at the application layer. Based on existing principles of data formatting and preparation at the transmitter, the PDU groups may be grouped into lower layer packets (e.g., Layer 2 (L2) SDUs).

[0063] The L2 SDUs may be sent by a lower layer of a transmitter at 308 and received by a lower layer of a receiver at 312. As shown, the L2 SDUs may be received at 312 in an order different from the order in which they were sent.

[0064] In some embodiments, this information may be added to the L2 SDU as a PDU group descriptor or a PDU group header. The PDU group descriptor may be the larger header of the two. One packet in each PDU group may carry a PDU group descriptor, which may indicate PDU group parameters that are common to all packets in the PDU group. For example, the PDU group parameters that may be included in the PDU group descriptor may be parameters that describe the PDU group, such as the PDU group type or importance. In some embodiments, the PDU group descriptor may be included in only one packet (e.g., the first packet) of the PDU group. As shown, the PDU group descriptors may be L2 SDU1 PDU group #1 and L2 SDU1 PDU group #2.

[0065] The PDU group header may include packet specific fields. For example, a PDU group parameter that may be included in the PDU group header may be a parameter that describes the position of a packet relative to a group of packets that convey the PDU group.

[0066] In some embodiments, instead of sending the PDU group descriptor in a packet carrying a portion of a PDU group, the UE 104 may send the PDU group descriptor using a semi-static indication, for example, via access stratum (AS) scheduling assistance information or non-access stratum (NAS) messages.

[0067] According to one or more of the options described below, the CE indication or congestion level information may be added to the header of the L2 SDU (eg, PDU group descriptor or PDU group header).

[0068] In a first option, the CE indication may be carried as a single congestion marker for the entire PDU group. For example, the CE indication may be included in a PDU group descriptor for the PDU group, or in a semi-static indication used to identify other common characteristics of the PDU group (such as PDU group size, delay budget, error rate, etc.). Since the congestion marker only exists once, the remaining PDUs in the PDU group do not need to carry a CE marker. When a CE marker is detected, the receiver may mark each packet in the PDU group with a CE indication based on a common marker for the PDU group, if required by the upper layer or if configured by the network. Alternatively, the receiver may only forward the marker for the PDU group to the next node.

[0069] In a second option, a CE indication may be provided in the PDU group header so that it is carried in each packet of the PDU group. Even if congestion is indicated on a per-packet basis, congestion may be evaluated and detected for the PDU group as a whole. Different PDU groups may enter a congested state at different times, for example, different sojourn times or different buffer residency times may be applied. This may be based on configuration or characteristics. Providing a CE indication in the PDU group header provides the flexibility of marking a subset of packets in a PDU group or all packets in a PDU group with a CE indication. In some embodiments, even if congestion is marked only for a subset of packets in a PDU group, congestion may be identified very quickly for the remaining packets in the PDU group.

[0070] In some embodiments, the congestion level may be added to the PDU group descriptor or the PDU group header together with or instead of the CE indication.

[0071] Some embodiments may take advantage of dependencies between PDU groups. Since scheduling intent occurs on a PDU group basis, a CE indication may be provided on a per PDU group basis. Assuming that the UE 104 only needs to set one bit in one PDU group, that bit may travel all the way through to the UPF 120, which sets the CE indication for all remaining packets in that PDU group.

[0072] One option is to repeat the CE indication at least once per PDU group. For example, if congestion is detected for a traffic flow, a CE setting indication may be provided for each PDU group. For example, these CE indications may be as described above with respect to Figure 3 Any of the discussed methods is provided. As long as the same conditions apply, it may be necessary to provide a CE indication for each subsequent PDU group. If the conditions change, such as congestion is cleared, the CE indication can be updated to reflect the current congestion conditions. In some embodiments, the absence of a CE indication can be interpreted as a CE clear indication.

[0073] In another option, the CE condition set for one PDU group may be applied to one or more subsequent PDU groups. The indicated CE condition may persist until a different CE condition is indicated or a preconfigured number of PDU groups are sent / received. In this option, it may not be necessary to explicitly repeat the parameter in each PDU group. This option may be useful when congestion conditions are indicated, for example, by dedicated control PDUs. For example, a first dedicated control PDU may provide a CE setting indication, and when congestion is alleviated, a second dedicated control PDU may be sent with a CE clear indication.

[0074] In some embodiments, the CE indication provided with a first PDU group may be attached to one or more other PDU groups associated with (e.g., dependent on) the first PDU group. For example, consider a situation where there are dependencies between different PDU groups. This may occur, for example, in a group of pictures (GOP) or an I frame followed by a P frame. The CE indication provided with a first PDU group having an I frame may be carried over to a second PDU group having a P frame that depends on the I frame.

[0075] Since XR traffic is "quasi-periodic" and occurs in bursts of PDU groups with varying data sizes, the detection of congestion conditions for XR traffic flows may follow a slightly different pattern than for other traffic flows. For example, delays may be introduced by precoding, encoding of slices, packet transmission, etc. In addition, if the data bursts vary and become larger while the grant size (or bandwidth available at the intermediate nodes) remains unchanged, the queue will become longer. In accordance with the unique characteristics associated with XR traffic, various options for XR-aware congestion detection are provided below.

[0076] In a first option, the congestion detection threshold associated with the XR traffic flow may be configured independently of other traffic flows. For example, a device may be configured with a first set of parameters that it can use to detect congestion in an XR traffic flow and a second set of parameters that it can use to detect congestion in a non-XR traffic flow.

[0077] In a second option, the congestion detection threshold for XR traffic may be determined from a common congestion threshold configured to the device. For example, the UE may be configured with a first set of parameters that it will use to detect congestion in a non-XR traffic flow (e.g., for a PDU session, DRB or PDCP, RLC or MAC entity). The UE may then determine a second set of parameters that it will use to detect congestion in an XR traffic flow by applying a weighting factor to the first set of parameters. The weighting factor may help trigger congestion in the XR traffic slightly earlier or slightly later than in other traffic flows. The weighting factor may be predetermined or configured by the network.

[0078] In a third option, the amount of jitter may be used as a basis for determining congestion with respect to an XR traffic flow. A traffic flow with a large amount of jitter may correspond to a large fluctuation in congestion conditions. For example, if a packet arrives very late (due to jitter), the sender may predict that it will cause some backlog for some packets that come later, as the sender may need to process the late packet first before addressing other packets. Likewise, if a packet or group of packets arrives very late, the receiver may declare congestion, which may have an impact on traffic in the opposite direction, thus also triggering a congestion event there.

[0079] In a fourth option, a percentage of packets that are expected to be delivered within a packet delay budget (PDB) or a PDU group delay budget (PSDB) in a congested (or non-congested) scenario may be defined. It may be expected that a certain percentage of PDU groups should not experience a delay exceeding the PSDB of the 5G QoS identifier (5QI) (or QFI). If the device determines that the number of packets delivered within these constraints is less than a predetermined threshold, the device may determine that the XR service is experiencing congestion.

[0080] In a fifth option, the congestion threshold in the RAN 116 may be tuned through assistance information based on guidance from the XR-aware application 108. In some embodiments, the assistance information may include congestion levels or other attributes or capabilities determined by the UE 104. The UE 104 may provide the assistance information to the RAN 116. The RAN 116 may then configure the congestion threshold used by the RAN 116 or the UE 104 based on the assistance information.

[0081] Figure 4An operational flow / algorithm structure 400 according to some embodiments is shown. The operational flow / algorithm structure 400 may be performed by a device such as a UE 104, a device of a RAN 116 or a CN 118, a UE 700, a network node 800 or a component thereof (eg, a processing circuit 704 or 804).

[0082] The operation flow / algorithm structure 400 may include, at 404, detecting a congestion event associated with a first PDU in a PDU group. According to some embodiments, the PDU group may be part of a bit stream carrying data for an XR service. The PDU group may include a group of application layer PDUs, IP PDUs, SDAP PDUs, PDCP PDUs, RLC PDUs, or MAC PDUs.

[0083] In some embodiments, congestion events may be detected by comparing the operational status to various predetermined thresholds. The operational status may be associated with the state of a queue or buffer (e.g., fill percentage, amount of data, etc.), the number of retransmissions, the number of acknowledgments, whether a packet is determined to be successfully sent within a period of time (e.g., based on a delay budget or drop timer), the receipt or transmission of a packet within an expected time period, sojourn time, round trip time, the size of a gap in sequence numbers, QoS parameters, QoE parameters, etc.

[0084] Thresholds for detecting congestion events may be common to different types of traffic flows, or may be specific to XR traffic. If the thresholds are specific to XR traffic, they may be configured independently of the common thresholds, or they may be configured based on the common thresholds using, for example, a weighting function. In some embodiments, the XR-specific thresholds may include jitter thresholds. If the level of jitter experienced by the XR traffic is greater than or less than the jitter threshold, a congestion event may be detected. In some embodiments, the XR-specific thresholds may include a percentage of packets expected to be delivered within a delay budget.

[0085] In some embodiments, a congestion event may indicate that a traffic flow is experiencing congestion or that the traffic flow is not experiencing congestion. In other embodiments, a congestion event may indicate that a traffic flow is experiencing a specific level of congestion.

[0086] The operational flow / algorithm structure 400 may also include adjusting transmission parameters of other PDUs in the PDU group based on detecting the congestion event at 408. In some embodiments, the adjustment of the transmission parameters may include one or more of the following: increasing the priority level or importance of the PDU group; increasing the priority level of the logical channel of the data radio bearer or quality of service flow associated with the PDU group; enabling PDCP duplication for the PDU group; adjusting the radio resource allocation for the PDU group; allocating additional radio resources for the PDU group; or entering a time to live.

[0087] In some embodiments, the adjusted transmission parameters may include layer 1 parameters, which include CG / SPS parameters, MCS, repetition number, or transmission power.

[0088] In some embodiments, the adjusted transmission parameters may include layer 2 parameters including, for example, LCH prioritization mapping rules or PDCP to RLC entity mapping.

[0089] In some embodiments, adjusting the transmission parameter may include changing the transmission parameter from a first setting to a second setting. The first / second setting may be associated with: prioritizing the transmission of a high priority PDU group over the transmission of a low priority PDU group; discarding one or more PDU groups having a priority level below a threshold level; or applying a congestion policy defined by the network.

[0090] Figure 5 An operational flow / algorithm structure 500 according to some embodiments is shown. The operational flow / algorithm structure 500 may be performed by a device such as a UE 104, a device of a RAN 116 or a CN 118, a UE 700, a network node 800 or a component thereof (eg, a processing circuit 704 or 804).

[0091] The operational flow / algorithm structure 500 may include, at 504, detecting a congestion event associated with a first PDU in a PDU group. Detecting a congestion event may be similar to the above description of Figure 4 or detecting congestion events as described elsewhere herein.

[0092] The operational flow / algorithm structure 500 may include generating a packet header associated with the PDU group at 508. The packet header may be generated using a CE indication indicating whether the traffic flow is experiencing congestion. Additionally / alternatively, the packet header may be generated using congestion level information to provide an indication of the congestion level experienced by the traffic flow.

[0093] In some embodiments, the packet header may be a PDU group descriptor associated with a plurality of L2 SDUs of the PDU group. In other embodiments, the packet header may be a PDU group header associated with a separate L2 SDU in the PDU group.

[0094] The operational flow / algorithm structure 500 may include sending a packet header at 512. The packet header may be sent along with a data bit stream including a PDU group.

[0095] Figure 6An operational flow / algorithm structure 600 according to some embodiments is illustrated. The operational flow / algorithm structure 600 may be performed by a device such as a UE 104, a device of a RAN 116 or a CN 118, a UE 700, a network node 800 or a component thereof (eg, a processing circuit 704 or 804).

[0096] The operation flow / algorithm structure 600 may include, at 604, detecting a congestion event associated with the first PDU group. Detecting the congestion event may be similar to the above description of Figure 4 or detecting congestion events as described elsewhere herein.

[0097] The operational flow / algorithm structure 600 may include, at 608, determining that a second PDU group is associated with a first PDU group. In some embodiments, the second group may be associated with the first group based on the sequence of the two PDU groups. For example, if the second group follows the first group (or immediately follows it, within a predetermined number of PDU groups, or no predefined event occurs (e.g., a change in congestion conditions)), it may be considered to be associated with the first group. In other embodiments, the association may be based on a dependency relationship between the two PDU groups. For example, if the second PDU group depends on the first PDU group, it may be considered to be associated with the first PDU group. For example, this may occur if the first PDU group provides an I frame and the second PDU group provides a P frame that depends on the I frame.

[0098] The operational flow / algorithm structure 600 may include providing a congestion indication for the second PDU group at 612. The congestion indication for the second PDU group may be based on an association between the first PDU group and the second PDU group and a detection of a congestion event with respect to the first PDU group.

[0099] Figure 7 UE 700 according to some embodiments is shown. UE 700 may be similar to Figure 1 UE 104 and is substantially interchangeable therewith.

[0100] UE 700 can be any mobile or non-mobile computing device, such as, for example, a mobile phone, a computer, a tablet, an XR device, glasses, an industrial wireless sensor (e.g., a microphone, a carbon dioxide sensor, a pressure sensor, a humidity sensor, a thermometer, a motion sensor, an accelerometer, a laser scanner, a fluid level sensor, an inventory sensor, a voltage / current meter, or an actuator), a video surveillance / monitoring device (e.g., a camera or a camcorder), a wearable device (e.g., a smart watch), or an IoT device.

[0101] UE 700 may include a processor 704, an RF interface circuit 708, a memory / storage 712, a user interface 716, a sensor 720, a driver circuit 722, a power management integrated circuit (PMIC) 724, an antenna structure 726, and a battery 728. The components of UE 700 may be implemented as an integrated circuit (IC), a portion of an integrated circuit, a discrete electronic device or other module, logic component, hardware, software, firmware, or a combination thereof. Figure 7 The block diagram of UE 700 is intended to show a high-level view of certain of the components of UE 700. However, some of the components shown may be omitted, additional components may be present, and different arrangements of the components shown may occur in other implementations.

[0102] Components of UE 700 may be coupled to various other components via one or more interconnects 732, which may represent any type of interface, input / output, bus (local, system, or extension), transmission line, trace, or optical connection that allows various circuit components (on a common or different chip or chipset) to interact with each other.

[0103] The processor 704 may include processor circuits such as a baseband processor circuit (BB) 704A, a central processor unit circuit (CPU) 704B, and a graphics processor unit circuit (GPU) 704C. The processor 704 may include any type of circuit or processor circuit that executes or otherwise operates computer-executable instructions (such as program codes, software modules, or functional processes from the memory / storage device 712) to cause the UE 700 to perform operations as described herein.

[0104] In some embodiments, the baseband processor circuit 704A can access the communication protocol stack 736 in the memory / storage device 712 to communicate through a 3GPP compatible network. Generally speaking, the baseband processor circuit 704A can access the communication protocol stack 736 to perform the following operations: perform user plane functions at the PHY layer, MAC layer, RLC sublayer, PDCP sublayer, SDAP sublayer, and upper layers; and perform control plane functions at the PHY layer, MAC layer, RLC sublayer, PDCP sublayer, RRC layer, and NAS layer. In some embodiments, the PHY layer operations can be additionally / alternatively performed by components of the RF interface circuit 708.

[0105] The baseband processor circuit 704A may generate or process baseband signals or waveforms that carry information in a 3GPP-compatible network. In some embodiments, the waveforms used for NR may be based on cyclic prefix OFDM (CP-OFDM) in the uplink or downlink, and discrete Fourier transform spread OFDM (DFT-S-OFDM) in the uplink.

[0106] The memory / storage device 712 may include one or more non-transitory computer-readable media, which include instructions (e.g., communication protocol stack 736) that can be executed by one or more processors in the processor 704 to enable the UE 700 to perform various operations described herein. The memory / storage device 712 includes any type of volatile or non-volatile memory that can be distributed throughout the UE 700. In some embodiments, some of the memory / storage devices 712 may be located on the processor 704 itself (e.g., L1 cache and L2 cache), while other memory / storage devices 712 are located outside the processor 704, but can be accessed via a memory interface. The memory / storage device 712 may include any suitable volatile or non-volatile memory, such as, but not limited to, dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid-state memory, or any other type of memory device technology.

[0107] The RF interface circuit 708 may include a transceiver circuit and a radio frequency front end module (RFEM), which allows the UE 700 to communicate with other devices through a radio access network. The RF interface circuit 708 may include various elements arranged in a transmit path or a receive path. These elements may include, for example, switches, mixers, amplifiers, filters, synthesizer circuits, and control circuits.

[0108] In the receive path, the RFEM may receive the radiated signal from the air interface via the antenna structure 726 and continue to filter and amplify the signal (using a low noise amplifier). The signal may be provided to the transceiver's receiver, which down-converts the RF signal to a baseband signal that is provided to the baseband processor of the processor 704.

[0109] In the transmit path, the transmitter of the transceiver up-converts the baseband signal received from the baseband processor and provides the RF signal to the RFEM. The RFEM may amplify the RF signal through a power amplifier before the signal is radiated across the air interface via the antenna 726.

[0110] In various embodiments, the RF interface circuit 708 may be configured to send / receive signals in a manner compatible with NR access technology.

[0111] Antenna 726 may include antenna elements to convert electrical signals into radio waves to travel through the air and convert received radio waves into electrical signals. These antenna elements may be arranged into one or more antenna panels. Antenna 726 may have an antenna panel that is omnidirectional, directional, or a combination thereof to achieve beamforming and multiple input / multiple output communications. Antenna 726 may include a microstrip antenna, a printed antenna manufactured on the surface of one or more printed circuit boards, a patch antenna, or a phased array antenna. Antenna 726 may have one or more panels designed for a specific frequency band (including a frequency band in FR1 or FR2).

[0112] The user interface circuit 716 includes various input / output (I / O) devices designed to enable the user to interact with the UE 700. The user interface 716 includes input device circuits and output device circuits. The input device circuit includes any physical or virtual components for accepting input, especially including one or more physical or virtual buttons (e.g., reset button), physical keyboard, keypad, mouse, touch pad, touch screen, microphone, scanner, headset, etc. The output device circuit includes any physical or virtual components for displaying information or otherwise conveying information (such as sensor readings, actuator positions, or other similar information). The output device circuit may include any number or combination of audio or visual displays, especially including one or more simple visual outputs / indicators (e.g., binary state indicators (such as light emitting diodes (LEDs)) and multi-character visual outputs), or more complex outputs, such as display devices or touch screens (e.g., liquid crystal displays (LCDs), LED displays, quantum dot displays, and projectors), where the output of characters, graphics, multimedia objects, etc. is generated or produced by the operation of the UE 700.

[0113] Sensor 720 may include a device, module, or subsystem that is intended to detect events or changes in its environment and send information about the detected events (sensor data) to some other device, module, or subsystem. Examples of such sensors include: an inertial measurement unit including an accelerometer, gyroscope, or magnetometer; a microelectromechanical system or nanoelectromechanical system including a three-axis accelerometer, a three-axis gyroscope, or a magnetometer; a liquid level sensor; a flow sensor; a temperature sensor (e.g., a thermistor); a pressure sensor; a barometric pressure sensor; a gravity meter; an altimeter; an image capture device (e.g., a camera or a lensless aperture); a light detection and ranging sensor; a proximity sensor (e.g., an infrared radiation detector, etc.); a depth sensor; an ambient light sensor; an ultrasonic transceiver; and a microphone or other similar audio capture device.

[0114] The driver circuit 722 may include software elements and hardware elements for controlling a specific device embedded in, attached to, or otherwise communicatively coupled to the UE 700. The driver circuit 722 may include various drivers, thereby allowing other components to interact with or control various I / O devices that may be present in or connected to the UE 700. For example, the driver circuit 712 may include circuits that facilitate coupling a UICC (e.g., UICC 78) to the UE 700. For additional examples, the driver circuit 722 may include: a display driver for controlling and allowing access to a display device, a touch screen driver for controlling and allowing access to a touch screen interface, a sensor driver for obtaining sensor readings of the sensor circuit 720 and controlling and allowing access to the sensor circuit 720, a driver for obtaining an actuator position of an electromechanical component or controlling and allowing access to an electromechanical component, a camera driver for controlling and allowing access to an embedded image capture device, or an audio driver for controlling and allowing access to one or more audio devices.

[0115] The PMIC 724 may manage the power provided to various components of the UE 700. Specifically, with respect to the processor 704, the PMIC 724 may control power source selection, voltage scaling, battery charging, or DC-DC conversion.

[0116] In some embodiments, the PMIC 724 may control or otherwise be a part of various power saving mechanisms of the UE 700, including DRX, as discussed herein.

[0117] The battery 728 can power the UE 700, but in some examples, the UE 700 can be installed in a fixed location and can have a power source coupled to the power grid. The battery 728 can be a lithium-ion battery, a metal-air battery such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, etc. In some specific implementations, such as in vehicle-based applications, the battery 728 can be a typical lead-acid automobile battery.

[0118] Figure 8 The network node 800 according to some embodiments is illustrated. The network node 800 may be a device of the RAN 116 or the CN 118.

[0119] The network node 800 may include a processor 804 , RF interface circuitry 808 (if implemented as an access node), core network (CN) interface circuitry 812 , memory / storage circuitry 816 , and antenna structures 826 .

[0120] Components of network node 800 may be coupled to various other components via one or more interconnects 828 .

[0121] The processor 804, RF interface circuit 808, memory / storage circuit 816 (including communication protocol stack 810), antenna structure 826 and interconnect 828 may be similar to those described with respect to Figure 7 Like named elements are shown and described.

[0122] The CN interface circuit 812 may provide connectivity to a core network (e.g., a 5GC using a 5th Generation Core Network (5GC) compatible network interface protocol such as a Carrier Ethernet protocol or some other suitable protocol). Network connectivity may be provided to / from the network node 800 via optical fiber or wireless backhaul. The CN interface circuit 812 may include one or more dedicated processors or FPGAs for communicating using one or more of the aforementioned protocols. In some implementations, the CN interface circuit 812 may include multiple controllers for providing connectivity to other networks using the same or different protocols.

[0123] In some embodiments, the network node 800 may be coupled to a transmit receive point (TRP) using an antenna structure 826, a CN interface circuit, or other interface circuits.

[0124] It is understood that the use of personally identifiable information should be subject to privacy policies and practices that are generally recognized to meet or exceed industry or government requirements for maintaining user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of the authorized use should be clearly stated to users.

[0125] For one or more aspects, at least one of the components shown in one or more of the foregoing figures may be configured to perform one or more operations, techniques, processes, or methods described in the following embodiments section. For example, the baseband circuit described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the examples described below. For another example, the circuits associated with the UE, base station, network element, etc. described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the examples described below in the examples section.

[0126] Example

[0127] In the following sections, additional exemplary aspects are provided.

[0128] Embodiment 1 includes a method of operating a device, the method comprising: detecting a congestion event associated with a first PDU in a protocol data unit (PDU) group; and adjusting transmission parameters of other PDUs in the PDU group based on detecting the congestion event.

[0129] Embodiment 2 includes a method according to embodiment 1 or some other embodiment of the present invention, wherein the PDU group is a group of application layer PDUs, Internet Protocol (IP) PDUs, Service Data Adaptation Protocol (SDAP) PDUs, Packet Data Convergence Protocol (PDCP) PDUs, Radio Link Control (RLC) PDUs or Medium Access Control (MAC) PDUs.

[0130] Embodiment 3 includes a method according to embodiment 1 or some other embodiment herein, wherein adjusting the transmission parameters includes increasing the priority level or importance of the PDU group.

[0131] Embodiment 4 includes a method according to embodiment 1 or some other embodiment of the present invention, wherein adjusting the transmission parameters includes: increasing the priority level of the logical channel of the data radio bearer or service quality flow associated with the PDU group; enabling packet data convergence protocol (PDCP) replication for the PDU group; adjusting the radio resource allocation for the PDU group; allocating additional radio resources to the PDU group; or entering a lifetime.

[0132] Embodiment 5 includes a method according to embodiment 4 or some other embodiment of the present invention, wherein the sending parameters include layer 2 parameters, and the layer 2 parameters include: logical channel prioritization mapping rules; or packet data convergence protocol (PDCP) to radio link control (RLC) entity mapping.

[0133] Embodiment 6 includes a method according to embodiment 1 or some other embodiment of the present invention, wherein the transmission parameters include layer 1 parameters, and the layer 1 parameters include configured authorization or semi-persistent scheduling parameters, modulation and decoding schemes, repetition times or transmission power.

[0134] Embodiment 7 includes a method according to embodiment 1 or some other embodiment of the present invention, wherein the congestion event is a first congestion event indicating that the PDU group is experiencing congestion, adjusting the sending parameter includes changing the sending parameter from a first setting to a second setting, and the method further includes: sending the PDU group based on the second setting until a second congestion event is detected indicating that another PDU group is not experiencing congestion.

[0135] Embodiment 8 includes a method according to embodiment 7 or some other embodiment herein, wherein operations according to the second setting include: giving priority to the sending of high priority PDU groups over low priority PDU groups; discarding one or more PDU groups having a priority level below a threshold level; or applying a congestion policy defined by the network.

[0136] Embodiment 9 includes the method of embodiment 1 or some other embodiment herein, further comprising providing assistance information including an indication of a congestion level to the radio access network.

[0137] Embodiment 10 includes the method of embodiment 9 or some other embodiment herein, wherein the congestion level provides an indication of a predetermined level of congestion or a percentage of packets or PDU groups that have experienced congestion over a period of time.

[0138] Embodiment 11 comprises a method according to embodiment 1 or some other embodiment herein, wherein the PDU group is associated with an extended reality (XR) service flow, and the detecting the congestion event comprises: identifying a congestion detection threshold corresponding to the XR service flow; and detecting the congestion event based on the congestion detection threshold.

[0139] Embodiment 12 includes a method according to embodiment 11 or some other embodiment of the present invention, wherein the congestion detection threshold is a first congestion detection threshold, and the identifying the first congestion detection threshold includes: identifying a second congestion detection threshold corresponding to non-XR business; and applying a weighting factor to the second congestion detection threshold to obtain the first congestion detection threshold.

[0140] Embodiment 13 includes a method according to embodiment 11 or some other embodiment of the present invention, wherein the congestion detection threshold includes a jitter threshold, and the method further includes: determining that the jitter level experienced by the XR business is greater than the jitter threshold; and detecting the congestion event based on the determination that the jitter level experienced by the XR business is greater than the jitter threshold.

[0141] Embodiment 14 includes a method as in embodiment 11 or some other embodiment herein, wherein the congestion detection threshold comprises a percentage of packets expected to be delivered within a delay budget.

[0142] Embodiment 15 includes a method as in embodiment 11 or any other embodiment herein, wherein the congestion detection threshold is based on user equipment (UE) assistance information.

[0143] Embodiment 16 includes a method comprising: detecting a congestion event associated with a protocol data unit (PDU) group; generating a packet header associated with the PDU group, the packet header being configured to include one or more bits, the one or more bits being set to provide a congestion experienced (CE) indication based on the detection of the congestion event; and sending the packet header.

[0144] Embodiment 17 includes the method of embodiment 16 or some other embodiment herein, wherein the one or more bits in the packet header are in a common parameter field that applies to all packets of the PDU group.

[0145] Embodiment 18 includes a method according to embodiment 16 or some other embodiment herein, wherein the one or more bits in the packet header are in a packet-specific field applied to a packet having the packet header, and the method further includes: generating a packet header in each packet of the PDU group to include the one or more bits set to provide the CE indication.

[0146] Embodiment 19 includes a method according to embodiment 16 or some other embodiment herein, wherein the PDU group is associated with an extended reality (XR) service flow, and detecting the congestion event includes: identifying a congestion detection threshold corresponding to the XR service flow; and detecting the congestion event based on the congestion detection threshold.

[0147] Embodiment 20 includes a method comprising: detecting a congestion event associated with a first protocol data unit (PDU) group; determining an association between a second PDU and the first PDU group; and providing a congestion indication for the second PDU group based on detecting the congestion event and determining that the second PDU group is associated with the first PDU group.

[0148] Embodiment 21 includes the method of embodiment 20 or some other embodiment herein, wherein the association is based on the second PDU group immediately following the first PDU group.

[0149] Embodiment 22 includes a method according to embodiment 20 or some other embodiment herein, wherein the association is a dependency association.

[0150] Embodiment 23 includes a method according to embodiment 22 or some other embodiment herein, wherein the first PDU group is associated with an intra-coded picture (I) frame and the second PDU group is associated with a predicted (P) frame that depends on the I frame.

[0151] Embodiment 24 comprises a method according to embodiment 20 or some other embodiment herein, wherein the PDU group is associated with an extended reality (XR) service flow, and the detecting the congestion event comprises: identifying a congestion detection threshold corresponding to the XR service flow; and detecting the congestion event based on the congestion detection threshold.

[0152] Another embodiment may include one or more non-transitory computer-readable media, which include instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform one or more elements of a method described in or related to any of Embodiments 1 to 24 or any other method or process described herein.

[0153] Another embodiment may include an apparatus comprising logic components, modules, or circuits for performing one or more elements of the method described in accordance with or related to any of Embodiments 1 to 24, or any other method or process described herein.

[0154] Another embodiment may include a method, technique or process described or related to any one of embodiments 1 to 24 or a portion or component thereof.

[0155] Another embodiment may include a device comprising: one or more processors and one or more computer-readable media, wherein the one or more computer-readable media include instructions that, when executed by the one or more processors, cause the one or more processors to perform methods, techniques, or processes described in or related to any one of embodiments 1 to 24 or portions thereof.

[0156] Another embodiment comprises a signal as described or relating to any one of embodiments 1 to 24, or parts or components thereof.

[0157] Another embodiment may include a datagram, information element, packet, frame, segment, PDU or message as described or related to any one of embodiments 1 to 24 or parts or components thereof or otherwise described in the present disclosure.

[0158] Another embodiment may include a signal encoded with data as described or associated with any one of embodiments 1 to 24, or parts or components thereof, or otherwise described in this disclosure.

[0159] Another embodiment may include a signal encoded with a datagram, IE, packet, frame, segment, PDU or message as described or related to any one of embodiments 1 to 24 or parts or components thereof or otherwise described in the present disclosure.

[0160] Another embodiment may include an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors will cause the one or more processors to perform a method, technique, or process described in or related to any one or part of embodiments 1 to 24.

[0161] Another embodiment may include a computer program comprising instructions, wherein execution of the program by a processing element causes the processing element to perform a method, technique, or process described or related to any one or part of embodiments 1 to 24.

[0162] Another embodiment may include a signal in a wireless network as shown and described herein.

[0163]

[0013] Another embodiment may include a method of communicating in a wireless network as shown and described herein.

[0164]

[0013] Another embodiment may include a system for providing wireless communications as shown and described herein.

[0165]

[0013] Another embodiment may include an apparatus for providing wireless communications as shown and described herein.

[0166] Unless explicitly stated otherwise, any of the above embodiments may be combined with any other embodiment (or combination of embodiments). The foregoing description of one or more specific implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of the various aspects to the precise form disclosed. In view of the above teachings, modifications and variations are possible or can be obtained from the practice of various aspects.

[0167] Although the above aspects have been described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to include all such variations and modifications.

Claims

1. A method of operating a device, the method comprising: detecting a congestion event associated with a first protocol data unit (PDU) in a group of PDUs; as well as Transmission parameters of other PDUs in the PDU group are adjusted based on detecting the congestion event.

2. The method of claim 1, wherein the PDU group is a group of application layer PDUs, Internet Protocol (IP) PDUs, Service Data Adaptation Protocol (SDAP) PDUs, Packet Data Convergence Protocol (PDCP) PDUs, Radio Link Control (RLC) PDUs, or Medium Access Control (MAC) PDUs.

3. The method of claim 1 , wherein adjusting the transmission parameters comprises: Increase the priority level or importance of the PDU group.

4. The method of claim 1 , wherein adjusting the transmission parameters comprises: increasing the priority level of a logical channel of a data radio bearer or quality of service flow associated with the PDU group; enabling packet data convergence protocol (PDCP) duplication for the PDU group; adjusting radio resource allocation for the PDU group; allocating additional radio resources for the PDU group; or Enter the time to live.

5. The method of claim 1 , wherein the transmission parameters include layer 2 parameters, the layer 2 parameters including: Logical channel prioritization mapping rules; or Packet Data Convergence Protocol (PDCP) to Radio Link Control (RLC) entity mapping.

6. The method of claim 1, wherein the transmission parameters include layer 1 parameters, the layer 1 parameters including configured grant or semi-persistent scheduling parameters, modulation and coding scheme, repetition number or transmission power.

7. The method of claim 1 , wherein the congestion event is a first congestion event indicating that the PDU group is experiencing congestion, adjusting the transmission parameter comprises changing the transmission parameter from a first setting to a second setting, and the method further comprises: The PDU group is transmitted based on the second setting until a second congestion event is detected indicating that another PDU group is not experiencing congestion.

8. The method of claim 7, wherein the operation according to the second setting comprises: Prioritize the transmission of high priority PDU groups over low priority PDU groups; discarding one or more PDU groups having a priority level below a threshold level; Or apply a network-defined congestion policy.

9. The method according to claim 1, further comprising: Auxiliary information including an indication of a congestion level is provided to the radio access network.

10. The method of claim 9, wherein the congestion level provides an indication of a predetermined level of congestion or a percentage of packets or PDU groups that have experienced congestion over a period of time.

11. The method of claim 1 , wherein the PDU group is associated with an extended reality (XR) traffic flow, and the detecting the congestion event comprises: Identifying a congestion detection threshold corresponding to the XR service flow; as well as The congestion event is detected based on the congestion detection threshold.

12. The method of claim 11, wherein the congestion detection threshold is a first congestion detection threshold, and the identifying the first congestion detection threshold comprises: Identifying a second congestion detection threshold corresponding to non-XR traffic; as well as A weighting factor is applied to the second congestion detection threshold to obtain the first congestion detection threshold.

13. The method of claim 11, wherein the congestion detection threshold comprises a jitter threshold, and the method further comprises: determining that a jitter level experienced by the XR service is greater than the jitter threshold; as well as The congestion event is detected based on the determination that the jitter level experienced by the XR traffic is greater than the jitter threshold.

14. The method of claim 11, wherein the congestion detection threshold comprises a percentage of packets expected to be delivered within a delay budget.

15. The method of claim 11, wherein the congestion detection threshold is based on user equipment (UE) assistance information.

16. A method comprising: detecting congestion events associated with a group of protocol data units (PDUs); generating a packet header associated with the PDU group, the packet header to include one or more bits, the one or more bits being set to provide a congestion experienced (CE) indication based on detecting the congestion event; and The packet header is transmitted.

17. The method of claim 16, wherein the one or more bits in the packet header are in a common parameter field that applies to all packets of the PDU group.

18. The method of claim 16, wherein the one or more bits in the packet header are in a packet specific field that applies to packets having the packet header, and the method further comprises: A packet header is generated in each packet of the PDU group to include the one or more bits set to provide the CE indication.

19. The method of claim 16, wherein the PDU group is associated with an extended reality (XR) traffic flow, and the detecting the congestion event comprises: Identifying a congestion detection threshold corresponding to the XR service flow; as well as The congestion event is detected based on the congestion detection threshold.

20. A method comprising: detecting a congestion event associated with a first group of protocol data units (PDUs); determining an association between a second PDU and the first PDU group; as well as A congestion indication for the second PDU group is provided based on detecting the congestion event and determining that the second PDU group is associated with the first PDU group.

21. The method of claim 20, wherein the association is based on the second PDU group immediately following the first PDU group.

22. The method of claim 20, wherein the association is a dependency association.

23. The method of claim 22, wherein the first PDU group is associated with an intra-coded picture (I) frame and the second PDU group is associated with a predicted (P) frame that depends on the I frame.

24. The method of claim 20, wherein the PDU group is associated with an extended reality (XR) traffic flow, and the detecting the congestion event comprises: Identifying a congestion detection threshold corresponding to the XR service flow; as well as The congestion event is detected based on the congestion detection threshold.

Images