Techniques for congestion detection in wireless networks

Abstract

The application relates to devices and components including apparatuses, systems, and methods for detecting congestion in a wireless network.

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 Scaled Throughput (L4S) is based on the technology standardized by the Internet Engineering Task Force (IETF). L4S provides high throughput and low latency for Internet Protocol (IP) services, which can lead to 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 Devices of a network environment according to some embodiments are illustrated.

[0005] Figure 3 Layers of a device according to some embodiments are illustrated.

[0006] Figure 4 is an operational flow / algorithm structure according to some implementation schemes.

[0007] Figure 5 is an operational flow / algorithm structure according to some implementation schemes.

[0008] Figure 6 User equipment according to some embodiments is illustrated.

[0009] Figure 7 A network node according to some embodiments is illustrated. DETAILED DESCRIPTION

[0010] 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".

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

[0012] 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.

[0013] 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.

[0014] 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.

[0015] 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.

[0016] 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.

[0017] 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.

[0018] 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.

[0019] 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.

[0020] 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.

[0021] 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.

[0022] 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.

[0023] Current L4S technology relies on a modified form of explicit congestion notification (ECN) in which congestion indications are provided in the IP header to indicate queue accumulation in intermediate routers or radio links. Upon receipt of congestion indications, congestion signals may be propagated back to the transmitter. These signals may be transmitted via a Transmit Control Protocol (TCP) ECN loopback that triggers an extensible congestion control algorithm. A TCP Congestion Window Reduction (CWR) bit may be transmitted back to acknowledge receipt of the congestion indication loopback to the receiver. Similar signaling may be supported on other Layer 4 (L4) protocols such as QUIC.

[0024] 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.

[0025] 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 IP version 4 (IPv4) or IP version 6 (IPv6) header to encode four different code points. In traditional ECN implementations, congestion marking is equivalent to packet dropping. In L4S, congestion marking is used as an indication instead of dropping packets.

[0026] L4S allows for relatively fine-grained congestion control depending 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 may allow for better spectrum utilization. A router or node using AQM may signal a congestion indication when a high latency or high buffer state is detected.

[0027] Figure 1A network environment 100 according to some embodiments is illustrated. The network environment 100 may include a UE 104 coupled to a base station (BS) 108 of a radio access network (RAN). In some embodiments, the base station 108 is a next generation node B (gNB) providing one or more 3GPP new radio (NR) cells. In other embodiments, the base station 108 is an evolved node B (eNB) providing one or more long term evolution (LTE) cells. The air interface through which the UE 104 and the base station 108 communicate may be compatible with 3GPP technical specifications, such as those defining the fifth generation (5G) NR or later system standards.

[0028] The network environment 100 also includes three end nodes, namely, end node A 112, end node B 116, and end node C 120. Figure 1 Although shown separately in FIG. 1 , end node C 120 may also be part of UE 104 .

[0029] End nodes may communicate with each other through UE 104, RAN 108, and one or more network hops 124. End nodes may host an application layer that communicates application traffic to each other through intervening network nodes. Network hops 124 may include hops in RAN, core network (CN), external data networks, etc.

[0030] In some embodiments, the equipment of BS 108 and network hop 124 may include an integrated access and backhaul (IAB) node that facilitates relaying of access traffic by sharing radio resources between access and backhaul links. Figure 2 A network environment 100 is illustrated that implements the IAB concept that may be used in some embodiments. In an IAB deployment, a network hop 124 may include an IAB donor 204 and a core network 208. The IAB donor 204 may be a RAN node that provides an interface to the core network 208 and provides wireless backhaul functionality to an IAB node. An IAB node is a RAN node that provides wireless access to a UE 104 and wirelessly backhauls access traffic to another IAB node or an IAB donor.

[0031] The base station 108 may correspond to one or more of the IAB nodes (e.g., the IAB node 212, the IAB donor 204, etc.). In some embodiments, the base station 108 may be separate from the IAB node and may be provided, for example, between the IAB node 212 and the UE 104. The network hop 124 may include additional IAB nodes between the IAB node 212 and the IAB donor 204.

[0032] The IAB donor 204 may have a distributed unit (DU) 216 and a centralized unit (CU) 220 disposed on separate devices. Generally speaking, the IAB donor CU 220 may handle higher layer protocols, such as radio resource control (RRC), packet data convergence (PDCP), and service data adaptation protocol (SDAP) layer protocols, while the IAB donor DU 216 handles lower layer protocols, such as radio link control (RLC), medium access control (MAC), and physical (PHY) layer protocols. In some embodiments, the base station 108 may provide CU and DU entities (e.g., gNB-CU and gNB-DU).

[0033] The IAB node 212 may include a mobile terminal (MT) 224 and a DU 228 coupled to the UE 104 or another IAB node. The MT 224 may be used to connect the IAB node 212 to an upstream (e.g., toward the core network 208) RAN node (e.g., an IAB donor DU 216). Generally speaking, the MT 224 may provide the IAB node 212 with access functionality similar to that of a UE. For example, the MT 224 may utilize protocols that a typical UE may utilize to connect to the RAN. For example, the MT 224 may allow the IAB node 212 to establish a signaling radio bearer (SRB) and / or a data radio bearer (DRB) with a parent node. The MT 224 may perform cell selection to identify an upstream RAN node to join, and then establish and utilize an RLC channel through a backhaul adaptation (BAP) layer that provides functionality for carrying and routing data for different UEs on different routes through the network. The MT 224 may also perform, for example, cell reselection, radio link failure, and the like. In some embodiments, the IAB node to which the MT 224 is connected, such as the IAB donor 204 as shown or another IAB node, may be considered a base station 108 .

[0034] In the cellular data path architecture of the network environment 100, queuing can be applied to packets in UE 104, BS 108, or other RAN nodes. With respect to UE 104, in order to ensure that Layer 2 (L2) / MAC has enough available data, new data from the upper layer can be continuously added to the local queue. Based on the expectation of the uplink grant from BS108, the data path can be encrypted and have new packets ready to send. However, due to the highly dynamic nature of the radio link in a cellular network (such as a 5G network) at millimeter wave (mmWave) frequencies, the throughput may drop over a sustained period of time. This may occur when UE 104 has a non-line-of-sight (NLOS) connection to a frequency range 2 (FR2) tower. Additionally, due to suboptimal radio conditions, the radio link may experience retransmission of packets at several layers (such as, for example, the MAC layer or the RLC layer). In such cases, the L2 / MAC queue may experience buffer bloating. Similarly, with respect to BS108, packets may be queued and wait for scheduling opportunities, and based on bandwidth conditions, the queue may experience buffer bloating. Embodiments of the present disclosure provide for detecting congestion at a queue of a UE 104, BS 108, or other RAN node. Upon detecting a congestion event, embodiments provide for setting a Congestion Experienced (CE) indication that can be used for an application at one of the auxiliary end nodes. The CE indication can be provided via the ECN / L4S field in the IP header and elsewhere as described herein.

[0035] 5G NR and LTE support ECN at the IP layer, where the base station and UE may insert ECN code points as specified in clause 5 of IETF request for comments (RFC) 3168, "The Addition of Explicit Congestion Notification (ECN) to IP," September 2001. Specifically, the UE and base station may set the CE code point "11" in the PDCP service data unit (SDU) (in the IP packet). However, this means that ECN marking can only occur at the tail of the queue. Given that the UE's L2 buffer may be very large and there may be grant scheduling delays, the ECN / L4S marking at the end of the queue may have the disadvantage of additional delay for the ECN code point to reach its destination.

[0036] In some embodiments, the application at the end node may include an application for sending / receiving XR services of extended reality (XR) services over the network. Support of XR services requires low latency and high throughput. L4S can be used to reduce latency and congestion and guarantee the expected experience for users of XR services.

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

[0038] From a radio interface perspective, it may be advantageous to determine whether congestion exists at the radio layer or other points within the LTE / 5G system. In some embodiments, a CE bit may be used to indicate congestion at the air interface, which is communicated to the upper sublayers and converted to a corresponding representation at the IP layer. However, in order to allow support use cases where full end-to-end ECN / L4S consistency is desired, some embodiments may provide a CE indication with more than one bit (e.g., two bits). ECN, L4S, and CE may be used interchangeably throughout the specification.

[0039] Embodiments describe how a transmitter or receiver can detect congestion conditions at various radio layers (e.g., NR radio layers) of a wireless communication protocol.

[0040] Figure 3 A device 300 according to some embodiments is shown. The device 300 may be a UE 104, a base station 108 (as an IAB node or a base station different from an IAB node), or a device of a network hop 124 (e.g., an IAB node / donor). The device 300 may include multiple protocol layers, generally shown as a detection layer 304, an upper layer 308, and a lower layer 312. The detection layer 304 may be a layer at which a congestion event is detected. In various embodiments, the detection layer 304 may be an SDAP layer, a PDCP layer, an RLC layer, or a MAC layer. The upper layer 308 and the lower layer 312 may be defined relative to the detection layer 304. The detection may be performed according to any of the embodiments described herein.

[0041] In some embodiments, upon detecting a congestion event, the detection layer 304 may inform the upper layer 308. The detection layer 304 may inform the upper layer 308 of the congestion indication or event, for example, in a primitive or message. The upper layer 308 may insert a CE indication into a packet at the upper layer 308 and send the packet to a complementary upper layer in other devices.

[0042] In some embodiments, upon detecting a congestion event, the detection layer 304 may insert a CE indication into the packet at the detection layer 304. This may be used to inform complementary layers in other devices of the congestion.

[0043] In some embodiments, upon detecting a congestion event, the detection layer 304 may inform the lower layer 312. The lower layer 312 may insert a CE indication into a packet at the lower layer 312 and send the packet to a complementary lower layer in other devices.

[0044] The packet and included CE indication may be sent from any of the layers of device 300 in the same direction as the traffic flow in which the congestion was detected or in the opposite direction.

[0045] Some embodiments provide congestion detection at a receiver. The receiver may be in a UE 104, a base station 108, or one of the network hops 124. The receiver driven CE indication may be described as follows.

[0046] The receiver may be in a connection state where it is actively expecting packets from the sender. Assuming a bidirectional connection is for an interactive type of service, if the expected packet is not received, the receiver may take actions similar to those caused by congestion on the receiver path. These actions may include adjusting the codec rate, providing feedback to throttle the data rate at the transmitter, etc.

[0047] A first option for detecting congestion at the receiver may be with respect to a traffic stream having periodic traffic characteristics. The receiver may declare a congestion condition based on the (nominal) periodicity of the traffic stream. If the receiver does not receive a packet of the traffic stream within more than x times the periodicity, the receiver may declare a congestion condition. It may be noted that this assumes a pattern in which packets are always expected to be sent. For example, when uplink skipping is temporarily prohibited during a transmission period, or when it is assumed or detected that the connection is in a state of continuous transmission for a period of time, or when the receiver is able to safely identify a transmission attempt (blind decoding).

[0048] In some embodiments, a timer or counter may be specified, defined (or configured by the network) based on a multiple of the periodicity. This may be useful for XR and other types of services. The initial value of the congestion timer may be set to a multiple of the configuration grant (CG), semi-persistent scheduling (SPS) grant, or service flow periodicity. The timer or counter may be in the MAC, RLC, PDCP, or directly in a higher layer (e.g., in the IP layer).

[0049] A second option for detecting congestion at the receiver may correspond to a situation where once a packet has been sent, another packet is expected in the receive direction within a specified or configured amount of time. The expected packet may be transmitted in response to a sent packet, or may represent any packet transmitted in the receive direction. This option may use UE or RAN knowledge of the inherent traffic characteristics of the flow. For example, knowledge of the expected traffic pattern may be used to anticipate the expected packets accordingly.

[0050] If a receiver (in UE 104 or BS 108) does not receive a packet for an SPS / CG configuration, a logical channel (LCH), a quality of service (QoS) flow, or a data radio bearer (DRB) within a specified or configured time, the receiver may declare a congestion condition for the entire traffic flow. The receiver's layer may provide a CE indication to a complementary layer in another device or to an upper layer based on the declared congestion condition.

[0051] If the receiver does not receive packets regarding SPS / CG configuration, LCH, QoS flow, or DRB within a predetermined amount of time (which may be based on the device implementation), the receiver declares congestion condition for the entire service flow and provides a CE indication to a complementary layer in another device or to an upper layer.

[0052] The sub-options of the second option (e.g., option 2a) may be driven by L3 / L4 related parameters or based on typical service characteristics. For example, the receiver may detect the actual receive (Rx) data rate based on the round trip time (RTT) (relative to the Tx data rate). The actual Rx data rate may then be compared with the expected Rx data rate for the service flow. If the deviation from the expected is greater than a predetermined threshold, the receiver may declare a congestion condition.

[0053] For options 2 and 2a, the access layer may receive input from higher layers (e.g., the non-access layer NAS layer or the application layer) regarding inherent traffic characteristics. This input may be used to define conditions or key performance indicators (KPIs) that will be associated with congestion conditions.

[0054] In response to a congestion condition detected by one of the above options, the detection layer can inform the upper layer. The upper layer can then react according to one or more of the following options.

[0055] In the first option, the upper layers may set the CE bit for the flow in the IP layer in the receive direction. Thus, the CE bit may provide an indication in the same direction as the traffic flow where the condition was detected. When the destination end node receives the CE indication set in the IP layer, its transport layer may respond according to existing actions supported in the corresponding transport layer protocol (e.g., TCP may respond with ECN-echo in the send direction (e.g., toward the source end node)).

[0056] In a second option, the upper layers may trigger a congestion indication directly to the lower layers to signal the congestion faster when required.The lower layers may provide the CE indication in packets transmitted in the same direction as the traffic flow or in the opposite direction.

[0057] Some embodiments provide congestion detection at the transmitter. The transmitter may be in the UE 104, the base station 108, or one of the network hops 124. The transmitter driven CE indication may be described as follows.

[0058] In a first option, congestion may be detected based on buffer status. This may be done in SDAP, PDCP, RLC, MAC based on, for example, QoS flows, DRBs, RLC channels or LCHs. This may be done for each layer individually.

[0059] In some embodiments, the network may configure the queue utilization as a threshold. The threshold may be, for example, a maximum percentage or a maximum number of bytes in an L2 buffer. A threshold may be provided for a CE set indication, which may be used to indicate that congestion exists, and another threshold may be provided for a CE clear indication, which may be used to indicate that congestion does not exist. Although many embodiments describe congestion as existing in a binary state, e.g., congestion exists or does not exist, other embodiments may provide different levels of congestion that are detected / signaled in a similar manner.

[0060] In a second option, congestion may be detected based on delay budget or packet validity time. This may be done according to one or more of the following sub-options.

[0061] In a first sub-option of the second option (e.g., option 2A), the transmitter may declare a congestion condition if the lower layers have not successfully acknowledged the transmission of the PDU after a specified or configured fraction of the packet delay budget (PDB). The PDB may define an upper limit on the time that a packet may be delayed between the UE and the N6 termination point at the user plane function (UPF) of the core network.

[0062] In a second sub-option of the second option (e.g., option 2B), the transmitter may declare a congestion condition if the lower layers have not successfully acknowledged the transmission of a PDU group (e.g., a PDU set) after a specified or configured fraction of the PDU Set Delay Budget (PSDB).

[0063] In the third sub-option of the second option (e.g., option 2C), if the lower layer has not successfully confirmed the transmission of the PDU after a specified or configured fraction of the PDCP discard timer that can be configured for each DRB, the PDCP transmitter may declare a congestion condition. When a PDCP SDU is received from an upper layer, the PDCP transmitter may start a PDCP discard timer. The PDCP transmitter may discard the PDCP SDU when the timer expires, or confirm the successful delivery of the PDCP SDU in a PDCP status report. In some embodiments, the PDCP transmitter may obtain a transmission confirmation indication from the lower layer after the packet is successfully transmitted. For example, when the PDCP layer submits a packet to the lower layer, the MAC may confirm successful transmission when a HARQ-ACK is received. A similar process may be completed at the RLC layer.

[0064] In a fourth sub-option of the second option (eg, option 2D), the PDCP transmitter may declare a congestion condition if lower layers have not successfully acknowledged transmission of a PDU group after a specified or configured fraction of a discard timer associated with the PDU set.

[0065] In a fifth sub-option of the second option (e.g., option 2E), the PDCP transmitter may declare a congestion condition when a PDCP discard timer expires. In some embodiments, a congestion condition may be declared if the PDCP discard timer expires for one SDU. In other embodiments, a congestion condition may be declared if the PDCP discard timer expires for a predetermined threshold number of SDUs within a time period. The predetermined threshold number or time period may be configured by the network.

[0066] It may be noted that one or more of options 2A to 2D may be implemented by introducing a new timer or counter. The value of the timer / counter may be configured by the network according to the characteristics of the service flow / DRB.

[0067] In a third option, congestion can be detected based on RTT. For example, the transmitter can monitor the quality of the link using round-trip time measurements (e.g., based on the time between transmitting a probe and receiving a response) or quality of experience (QoE) measurements. The quality of the link can be determined on an end-to-end basis or via dedicated measurements. The transmitter can declare a congestion condition when a high RTT (e.g., above a predetermined threshold) is detected.

[0068] In a fourth option, congestion may be detected based on a maximum number of retransmissions experienced or a maximum number of missing acknowledgments (ACKs) experienced within a time period. The maximum number or time period may be configurable by the network.

[0069] In the downlink direction, if the UE 104 does not receive multiple positive acknowledgments for its PDUs transmitted in the uplink direction, the UE 104 may declare a congestion condition for the entire flow and indicate the congestion condition to upper layers.The number of positive acknowledgments may be defined for a traffic flow.

[0070] In the uplink direction, if the base station 108 does not receive multiple positive acknowledgments for its PDUs transmitted in the downlink direction, the base station may declare a congestion condition for the entire flow and indicate the congestion condition to upper layers.The number of positive acknowledgments may be defined for a traffic flow.

[0071] The number of missed ACKs (or the maximum number of retransmissions experienced) can be set based on, for example, the typical RTT. This number must be shorter than the timeout of the connection. For example, this number can be set to be shorter than the maximum number of retransmissions on a specific layer. The definition can be based on RLC or MAC.

[0072] Some embodiments provide congestion detection based on a specific threshold. These embodiments may be provided in conjunction with one or more embodiments described herein (e.g., receiver-driven detection or transmitter-driven detection). Detecting congestion and marking CE based on a specific threshold may be performed by one or more of the following options.

[0073] In a first option, congestion may be declared when the number of RLC retransmissions becomes greater than a threshold. The threshold may be referred to as an RLC retransmission threshold (RLCReTxThreshold). For example, the threshold may be configured by the network via RRC.

[0074] In the second option, the device may detect a congestion event if there is a sequence number (SN) gap in the RLC (or PDCP). For example, if a predetermined number of SNs are missing, the device may determine that the traffic flow is experiencing congestion.

[0075] In a third option, a congestion condition may be detected when a linger timer (e.g., average time spent in a queue for a flow) is greater than a predetermined threshold (which may be specified or preconfigured). The queue may be in any layer, e.g., in a detection layer or in a different layer. Additionally / alternatively, a congestion condition may be detected when an actual buffer residence time spent by a packet in an RLC or PDCP buffer exceeds a predetermined threshold (which may be specified or preconfigured).

[0076] In a fourth option, the receiver may detect congestion based on hybrid automatic repeat request (HARQ) retransmissions greater than a certain or configured threshold. In some embodiments, the threshold may be configured through RRC signaling.

[0077] The fifth option may operate according to option 2 (or 2a) of receiver-based congestion detection described above. In the fifth option, congestion may be declared based on a time window, a counter, or a watchdog timer that "fires" an alarm when a configured number of missing packets is reached. This configuration may be facilitated outside the conditions that define those options.

[0078] Some embodiments provide prediction-based congestion detection. For example, congestion can be detected and CE can be marked based on congestion prediction, which may be effective for uplink and downlink. This can be done according to one or more of the following options.

[0079] In a first option, radio quality metrics may be used to predict or detect congestion. This may be based on supervision of radio related parameters such as reference signal received power (RSRP), reference signal received quality (RSRQ), signal to interference plus noise ratio (SINR), block error rate (BLER), etc. In addition, options 1 to 4 in threshold-based congestion detection discussed above may provide input to refine the metric.

[0080] In a second option, if a prediction method is used to anticipate the quality of the link in the future, a CE may be marked before congestion reaches a level associated with a congestion event (eg, before a traffic flow experiences congestion).

[0081] In a first sub-option of the second option (eg, option 2a), the transmitter or receiver may set CE to indicate the "likelihood" that congestion will be experienced if no corrective action is taken. This may be particularly useful when using a prediction-based approach.

[0082] In a third option, the transmitter or receiver can predict congestion and set CE based on location and time. For example, if the device is in a busy urban area and the device or network has access to overload statistics (e.g., on a cell or based on an accessible database), the device can predict congestion with a relatively high level of accuracy.

[0083] In some embodiments, a packet with a CE indication may take precedence over other packets. For example, in order to provide a CE indication as quickly as possible, a packet including a CE indication may be considered a "high" priority packet and take precedence over any other service in the queue, such as TCP ACK or best effort service.

[0084] Upon detecting a congestion condition, the congestion detection layer (SDAP, PDCP, RLC or MAC) may inform the target layer handling the signaling of the CE indication to trigger the sending of the signal through the network.

[0085] The CE indication may be in a new 1-bit field in the SDAP, PDCP, RLC, or MAC layer. Additionally / alternatively, the lower layers may utilize two bits. In some embodiments, the two bits may correspond to a code point according to the ECN code point shown in Table 1 below or the L4S code point shown in Table 2 below.

[0086] Binary code point Code point name meaning 00 No ECT No ECN-supported transport 01 ECT(1) Support ECN transmission 10 ECT(0) Support ECN transmission 11 CE Experiencing congestion

[0087] Table 1

[0088] Binary code point Code point name meaning 00 No ECT No ECN-supported transport 01 ECT(1) Support L4S transmission 10 ECT(0) No L4S-supported transport 11 CE Experiencing congestion

[0089] Table 2

[0090] These code points may be similar to those described in IETF RFC 3168.

[0091] When the packet is queued after / within PDCP processing or in L2 layer, the transmitter may only need to provide CE indication. Otherwise, the transmitter may directly mark the ECN / L4S bit in the PDCP SDU or IP packet (e.g., at the end of the PDCP queue according to existing specifications).

[0092] In some embodiments, rules may be defined regarding which CE indication (one of the lower layers or one of the IP layers) supersedes another CE indication. The default may be that the most recent CE indication (from the RAN or from the IP layer) may overwrite / update any earlier CE settings for a traffic flow.

[0093] This rule may also apply to the case where the lower layers detect congestion early and report CE in the forward direction. In parallel with the CE reporting in the forward direction, the lower layers may inform the application layer to apply CE directly to the traffic flow. In other words, the lower layers may signal CE only for a period of time, e.g., depending on the size of the PDCP queue or until the application layer sets or detects CE itself. Embodiments may cope with synchronization of updates.

[0094] Other rules may also be defined. For example, a rule may be defined as follows: the application layer indication may only be overwritten by the lower layer if the CE bit is currently !='11' and a CE set event is newly detected, while a CE clear event may have to be approved by the application layer / IP. Depending on the network configuration or implementation, the exact behavior may be different for different applications.

[0095] Figure 4It is an operation flow / algorithm structure 400 according to some embodiments. The operation flow / algorithm structure 400 can be implemented by a receiver included in a UE (e.g., UE 104 or UE 600) or a network node (e.g., BS 108, IAB node 212, IAB donor 204, or network node 700) or a component thereof (e.g., processing circuit 604 or 704).

[0096] The operational flow / algorithm structure 400 may include establishing a connection state at 404. A connection state may be established with a transmitter via a wireless interface. A connection state may be established with a transmitter to communicate data of a service flow from a source end node to a target end node. In some embodiments, the data of the service flow may include XR data supporting an XR service. In some embodiments, the connection state may be a state in which a transmitter is actively expected to send a packet to a receiver.

[0097] The operational flow / algorithm structure 400 may also include, at 408 , detecting a congestion event at the sender.

[0098] In some embodiments, the receiver can detect a congestion event by determining that a packet of the traffic flow is not received within an expected time period. The expected time period can be based on a periodicity associated with the traffic flow. The periodicity can be defined or otherwise determined by a periodic traffic characteristic of the traffic flow. In some instances, the expected time period for detecting a congestion event can be an integer multiple of the periodicity. This can be tracked by setting a timer or counter to a value corresponding to an integer multiple of the periodicity.

[0099] In some embodiments, the expected time period for detecting a congestion event may be based on the transmission of packets. For example, a device having a receiver may expect to receive a second packet within a certain time period after transmitting a first packet. The first packet may be transmitted to a device having a transmitter or to another device.

[0100] In some embodiments, the receiver may detect a congestion event based on the traffic characteristics observed by the receiver. For example, the receiver may determine an expected data rate associated with the traffic flow and compare the expected data rate with the actual data rate observed by the receiver. If the actual data rate differs from the expected data rate by a predetermined threshold, the receiver may determine that a congestion event has occurred.

[0101] In embodiments where detection of congestion events is based on characteristics of the traffic flow, the access plane layer of the receiver may receive input regarding those characteristics from higher layers or the application layer.

[0102] In some embodiments, the receiver may detect a congestion event based on the number of HARQ retransmissions. For example, if the number of retransmissions is greater than a predetermined threshold, the receiver may determine that congestion is being experienced.

[0103] While some embodiments describe congestion events as being associated with detected congestion, other embodiments may detect congestion events that are not associated with the presence of detected congestion. Similarly, a congestion event may correspond to a change in the congestion level.

[0104] The operation flow / algorithm structure 400 may also include providing a CE indication within the L2 packet of the service flow at 412. The CE indication may be one bit or two bits. A one-bit CE indication may indicate whether congestion exists (e.g., providing a CE setting indication) or whether congestion does not exist (e.g., providing a CE clear indication). Two-bit CE indications may be used to provide the presence / absence of congestion and CE capability information, similar to what is described above with respect to Table 1 or 2. In some embodiments, two or more bits of the CE indication may be used to provide an indication of a specific congestion level that the service flow is experiencing.

[0105] In some embodiments, the L2 packet in which the CE indication is placed may correspond to the layer where the congestion is detected. In other embodiments, the layer that initially detects the congestion may be different from the layer that provides the CE indication in the L2 packet.

[0106] Figure 5 5 is an operation flow / algorithm structure 500 according to some embodiments. The operation flow / algorithm structure 500 may be implemented by a transmitter included in a UE (e.g., UE 104 or UE 600) or a network node (e.g., BS 108, IAB node 212, IAB donor 204, or network node 700) or a component thereof (e.g., processing circuit 604 or 704).

[0107] The operation flow / algorithm structure 500 may also include sending packets of the service flow at 504. A connection state with a receiver may be established via a wireless interface. A connection state with the receiver may be established to communicate data of the service flow from a source end node to a target end node. In some embodiments, the data of the service flow may include XR data supporting an XR service.

[0108] The operational flow / algorithm structure 500 may also include, at 508 , detecting a congestion event at the sender.

[0109] In some embodiments, the transmitter may detect congestion events based on the buffer status. For example, if the utilization buffer exceeds a first predetermined threshold, the transmitter may determine that congestion exists. The utilization rate may be based on the percentage of the buffer being used or the amount of data in the buffer. Conversely, if the utilization buffer is less than a second predetermined threshold, the transmitter may determine that congestion does not exist.

[0110] In some embodiments, the transmitter may detect a congestion event based on a delay budget. For example, the transmitter may detect a congestion event if it determines that the transmission of a PDU or PDU group is not confirmed to be successfully transmitted within a predetermined fraction of a packet delay budget, a PDU set delay budget, or a discard timer.

[0111] In some embodiments, the sender may detect a congestion event based on the RTT. For example, the sender may compare the RTT associated with the traffic flow with a predetermined threshold. The congestion event may be detected based on this comparison. For example, if the RTT is greater than a predetermined threshold, the sender may determine that congestion exists. If the RTT is less than a predetermined threshold, the sender may determine that congestion does not exist.

[0112] In some embodiments, the transmitter may detect a congestion event based on the number of retransmissions or missed acknowledgments experienced.The retransmissions may be RLC or HARQ retransmissions.

[0113] The operation flow / algorithm structure 500 may also include providing a CE indication within the L2 packet of the service flow at 512. The CE indication may be one bit or two bits. A one-bit CE indication may indicate whether there is congestion (e.g., providing a CE setting indication) or whether there is no congestion (e.g., providing a CE clear indication). Two-bit CE indications may be used to provide the presence / absence of congestion and CE capability information, such as described above with respect to Table 1 or 2. In some embodiments, two or more bits of the CE indication may be used to provide an indication of a specific congestion level that the service flow is experiencing.

[0114] In some embodiments, the L2 packet in which the CE indication is placed may correspond to the layer where the congestion is detected. In other embodiments, the layer that initially detects the congestion may be different from the layer that provides the CE indication in the L2 packet.

[0115] Figure 6 UE 600 according to some embodiments is shown. UE 600 may be similar to Figure 1 UE 104 and is substantially interchangeable therewith.

[0116] UE 600 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.

[0117] UE 600 may include processor 604, RF interface circuit 608, memory / storage 612, user interface 616, sensor 620, driver circuit 622, power management integrated circuit (PMIC) 624, antenna structures 626, and battery 628. The components of UE 600 may be implemented as integrated circuits (ICs), portions of integrated circuits, discrete electronic devices or other modules, logical components, hardware, software, firmware, or a combination thereof. Figure 6 The block diagram of UE 600 is intended to show a high-level view of certain of the components of UE 600. 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.

[0118] Components of UE 600 may be coupled to various other components via one or more interconnects 632, 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.

[0119] The processor 604 may include processor circuits such as a baseband processor circuit (BB) 604A, a central processor unit circuit (CPU) 604B, and a graphics processor unit circuit (GPU) 604C. The processor 604 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 612) to cause the UE 600 to perform operations as described herein.

[0120] In some embodiments, the baseband processor circuit 604A can access the communication protocol stack 636 in the memory / storage device 612 to communicate through a 3GPP compatible network. Generally speaking, the baseband processor circuit 604A can access the communication protocol stack 636 to: 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 608.

[0121] The baseband processor circuit 604A 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.

[0122] The memory / storage 612 may include one or more non-transitory computer-readable media including instructions (e.g., the communication protocol stack 636) that may be executed by one or more processors in the processor 604 to enable the UE 600 to perform various operations described herein. The memory / storage 612 includes any type of volatile or non-volatile memory that may be distributed throughout the UE 600. In some embodiments, some of the memory / storage 612 may be located on the processor 604 itself (e.g., L1 cache and L2 cache), while other memory / storage 612 is located outside the processor 604 but can be accessed via a memory interface. The memory / storage 612 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.

[0123] The RF interface circuit 608 may include a transceiver circuit and a radio frequency front end module (RFEM) that allows the UE 600 to communicate with other devices through a radio access network. The RF interface circuit 608 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.

[0124] In the receive path, the RFEM may receive the radiated signal from the air interface via the antenna structure 626 and proceed 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 604.

[0125] 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 626.

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

[0127] Antenna 626 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 626 may have an antenna panel that is omnidirectional, directional, or a combination thereof to achieve beamforming and multiple input / multiple output communications. Antenna 626 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 626 may have one or more panels designed for a specific frequency band (including a frequency band in FR1 or FR2).

[0128] The user interface circuit 616 includes various input / output (I / O) devices designed to enable the user to interact with the UE 600. The user interface 616 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 600.

[0129] Sensor 620 may include a device, module, or subsystem that is designed 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.

[0130] The driver circuit 622 may include software elements and hardware elements that operate to control a specific device embedded in, attached to, or otherwise communicatively coupled to the UE 600. The driver circuit 622 may include separate drivers to allow other components to interact with or control various I / O devices that may be present in or connected to the UE 600. For example, the driver circuit 612 may include circuits that facilitate coupling a UICC (e.g., UICC 68) to the UE 600. For another example, the driver circuit 622 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 620 and controlling and allowing access to the sensor circuit 620, a driver for obtaining actuator positioning or control of an electromechanical component and allowing access to an electromechanical component, a camera driver for controlling and allowing access to an embedded image capture device, and an audio driver for controlling and allowing access to one or more audio devices.

[0131] The PMIC 624 may manage the power provided to various components of the UE 600. Specifically, with respect to the processor 604, the PMIC 624 may control power source selection, voltage scaling, battery charging, or DC-DC conversion.

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

[0133] The battery 628 can power the UE 600, but in some examples, the UE 600 can be installed in a fixed location and can have a power source coupled to the power grid. The battery 628 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 embodiments, such as in vehicle-based applications, the battery 628 can be a typical lead-acid car battery.

[0134] Figure 7 Illustrated is a network node 700 according to some embodiments. The network node 700 may be similar to and substantially interchangeable with the base station 108, a device implementing one of the network hops 124, a network controlled repeater, or a server in a core network or an external data network.

[0135] The network node 700 may include a processor 704 , RF interface circuitry 708 (if implemented as an access node), core network (CN) interface circuitry 712 , memory / storage circuitry 716 , and antenna structures 726 .

[0136] Components of network node 700 may be coupled to various other components via one or more interconnects 728 .

[0137] The processor 704, RF interface circuit 708, memory / storage circuit 716 (including communication protocol stack 710), antenna structure 726 and interconnect 728 may be similar to those of reference Figure 6 Like named elements are shown and described.

[0138] The CN interface circuit 712 may provide a connection 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 700 via optical fiber or wireless backhaul. The CN interface circuit 712 may include one or more dedicated processors or FPGAs for communicating using one or more of the aforementioned protocols. In some embodiments, the CN interface circuit 712 may include multiple controllers for providing connections to other networks using the same or different protocols.

[0139] In some embodiments, the network node 700 may use the antenna structure 726, CN interface circuitry, or other interface circuitry to couple to a transmit receive point (TRP).

[0140] 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.

[0141] 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.

[0142] Example

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

[0144] Embodiment 1 includes a method of operating a first device, the method comprising: establishing a connection state in which packets of a service flow are expected to be received from a second device over a wireless interface; detecting a congestion event based on the service flow; providing a congestion experienced (CE) indication within a layer 2 (L2) packet of the service flow based on detecting the congestion event. The device may be a UE, a base station, a network hop device (e.g., IAB-DU, IAB-MT, a network controlled repeater, IAB-CU, gNB-DU, gNB-CU), a server, etc.

[0145] Embodiment 2 includes a method according to embodiment 1 or some other embodiment herein, wherein detecting the congestion event comprises determining that packets of the traffic flow are not received within an expected time period.

[0146] Embodiment 3 includes a method according to embodiment 2 or some other embodiment of the present invention, wherein the service flow is associated with a periodic service characteristic, and the method further includes: determining a periodicity associated with the service flow based on the periodic service characteristic; and determining the expected time period based on the periodicity.

[0147] Embodiment 4 includes the method of embodiment 3 or some other embodiment herein, wherein the expected time period is an integer multiple of the periodicity.

[0148] Embodiment 5 includes the method according to embodiment 3 or some other embodiment herein, further comprising: setting a timer or a counter based on the periodicity; and detecting the congestion event based on the value of the timer or the counter.

[0149] Embodiment 6 includes a method according to embodiment 3 or some other embodiment herein, wherein the periodic service characteristic is defined based on a configured grant or a semi-persistent scheduling of the service flow.

[0150] Embodiment 7 includes the method according to embodiment 2 or some other embodiment herein, further comprising: sending a packet to the second device, wherein the expected time period is based on sending the packet to the second device.

[0151] Embodiment 8 includes a method according to embodiment 7 or some other embodiment herein, wherein the expected time period is predefined, configured by a base station, or based on a user equipment implementation.

[0152] Embodiment 9 includes the method according to embodiment 1 or some other embodiment of the present invention, and also includes: determining an expected data rate associated with the service flow; determining that the actual data rate is less than the expected data rate by a first threshold; and detecting the congestion event based on determining that the actual data rate is less than the expected data rate by the first threshold.

[0153] Embodiment 10 includes the method according to embodiment 1 or some other embodiment herein, further comprising: receiving an indication of a service characteristic associated with the service flow at an access plane layer; and detecting the congestion event based on the service characteristic.

[0154] Embodiment 11 includes the method according to embodiment 1 or some other embodiment herein, further comprising: detecting the congestion event at a first layer of the first device; notifying a second layer of the congestion event; and providing the CE indication to the second layer.

[0155] Embodiment 12 includes the method according to embodiment 1 or some other embodiment herein, further comprising: sending a congestion indication to the transmitter based on detecting the congestion event, wherein the congestion indication is transmitted with a higher priority than other services to be transmitted to the transmitter.

[0156] Embodiment 13 includes a method for operating a first device, the method comprising: sending packets of a service flow to a second device via a wireless interface; detecting a congestion event based on the service flow; and setting a congestion experienced (CE) bit within an L2 packet of the service flow based on detecting the congestion event.

[0157] Embodiment 14 includes the method according to embodiment 13 or some other embodiment herein, further comprising: detecting the congestion event based on a delay budget associated with the traffic flow.

[0158] Embodiment 15 includes a method according to embodiment 14 or some other embodiment herein, further comprising: detecting the congestion event based on a determination that the transmission of a protocol data unit (PDU) or a PDU group was not confirmed as being successfully transmitted within a predetermined portion of a packet delay budget, a PDU set delay budget, or a discard timer.

[0159] Embodiment 16 includes the method according to embodiment 13 or some other embodiment of the present invention, and also includes: determining that the round-trip time (RTT) associated with the service flow is higher than a predetermined threshold; and detecting the congestion event based on determining that the RTT is higher than the predetermined threshold.

[0160] Embodiment 17 includes the method according to embodiment 13 or some other embodiment 13 herein, further comprising: detecting the congestion event based on a number of missing acknowledgments associated with the traffic flow being greater than a predetermined threshold.

[0161] Embodiment 18 includes the method according to embodiment 13 or some other embodiment herein, further comprising: detecting the congestion event based on the number of radio link control (RLC) or hybrid automatic repeat request (HARQ) retransmissions being greater than a predetermined threshold.

[0162] Embodiment 19 includes a method according to embodiment 13 or some other embodiment herein, further comprising: detecting a gap having a sequence number greater than a predetermined threshold in a radio link control (RLC) layer or a packet data convergence protocol (PDCP) layer; and detecting the congestion event based on detecting the gap.

[0163] Embodiment 20 includes the method according to embodiment 13 or some other embodiment of the present invention, further comprising: detecting that the buffer residence time associated with one or more packets of the service flow is greater than a predetermined threshold; and detecting the congestion event based on detecting that the buffer residence time is greater than the predetermined threshold.

[0164] Embodiment 21 includes the method according to embodiment 13 or some other embodiment herein, further comprising: determining that a radio quality metric is below a predetermined threshold; and detecting the congestion event based on determining that the radio quality metric is below the predetermined threshold.

[0165] Embodiment 22 includes the method according to embodiment 13 or some other embodiment of the present invention, and also includes: predicting that the quality of the link of the business flow will be lower than a predetermined threshold; and detecting the congestion event based on predicting that the quality of the link will be lower than the predetermined threshold.

[0166] Embodiment 23 includes the method according to embodiment 13 or some other embodiment of the present invention, and also includes: determining that the first device is at a predetermined location for a predetermined time period; and detecting the congestion event based on determining that the first device is at the predetermined location for the predetermined time period.

[0167] 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 23 or any other method or process described herein.

[0168] 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 23, or any other method or process described herein.

[0169] Another embodiment may include a method, technique or process according to any one of embodiments 1 to 23 or a portion or part thereof or related thereto.

[0170] 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 a method, technique, or process according to any one of embodiments 1 to 23, or a portion thereof, or related thereto.

[0171] Another embodiment comprises a signal according to any one of embodiments 1 to 23 or a portion or part thereof or related thereto.

[0172] 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 23 or parts or components thereof or otherwise described in the present disclosure.

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

[0174] 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 23 or parts or components thereof or otherwise described in the present disclosure.

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

[0176] 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 of embodiments 1 to 23 or a portion thereof.

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

[0178]

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

[0179]

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

[0180]

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

[0181] 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 embodiments 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.

[0182] 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 for operating a first device, the method comprising: establishing a connection state in which packets of a traffic flow are expected to be received from a second device via a wireless interface; detecting a congestion event based on the traffic flow; as well as A congestion experienced (CE) indication is provided within a layer 2 (L2) packet of the traffic flow based on detecting the congestion event.

2. The method of claim 1 , wherein detecting the congestion event comprises: It is determined that packets of the traffic flow have not been received within an expected period of time.

3. The method according to claim 2, wherein the traffic flow is associated with a periodic traffic characteristic, and the method further comprises: determining a periodicity associated with the traffic flow based on the periodic traffic characteristic; as well as The expected time period is determined based on the periodicity. The method according to claim 3 , wherein the expected time period is an integer multiple of the periodicity.

5. The method according to claim 3, further comprising: setting a timer or counter based on the periodicity; as well as The congestion event is detected based on the value of the timer or counter. 6 . The method according to claim 3 , wherein the periodic service characteristic is defined based on a configuration authorization or a semi-persistent scheduling of the service flow.

7. The method of claim 2, wherein the L2 packet is a first packet, and the method further comprises: sending a second packet to the second device, Wherein the expected time period is based on sending the second packet to the second device.

8. The method of claim 7, wherein the expected time period is predefined, configured by a base station, or based on a user equipment implementation.

9. The method according to claim 1, further comprising: determining an expected data rate associated with the traffic flow; Determining that an actual data rate is less than the expected data rate by a first threshold; as well as The congestion event is detected based on determining that the actual data rate is less than the expected data rate by the first threshold.

10. The method according to claim 1, further comprising: receiving, at an access plane layer, an indication of a service characteristic associated with the service flow; as well as The congestion event is detected based on the traffic characteristics.

11. The method according to claim 1, further comprising: detecting the congestion event at a first layer of the first device; Notifying the second layer of the congestion event; as well as The CE indication is provided to the second layer.

12. The method according to claim 1, further comprising: The L2 packet is sent from the first queue with a higher priority than other L2 packets in the first queue.

13. A method of operating a first device, the method comprising: Sending packets of the service flow to the second device via the wireless interface; detecting a congestion event based on the traffic flow; as well as One or more congestion experienced (CE) bits are set within layer 2 (L2) packets of the traffic flow based on detecting the congestion event.

14. The method according to claim 13, further comprising: The congestion event is detected based on a delay budget associated with the traffic flow.

15. The method according to claim 14, further comprising: The congestion event is detected based on a determination that transmission of a protocol data unit (PDU) or a group of PDUs was not confirmed as successfully transmitted within a predetermined portion of a packet delay budget, a PDU set delay budget, or a discard timer.

16. The method according to claim 13, further comprising: comparing a round trip time (RTT) associated with the traffic flow to a predetermined threshold; as well as The congestion event is detected based on comparing the RTT to the predetermined threshold.

17. The method according to claim 13, further comprising: The congestion event is detected based on a number of missing acknowledgments associated with the traffic flow being greater than a predetermined threshold.

18. The method according to claim 13, further comprising: The congestion event is detected based on a number of Radio Link Control (RLC) or Hybrid Automatic Repeat Request (HARQ) retransmissions being greater than a predetermined threshold.

19. The method according to claim 13, further comprising: detecting a gap in a radio link control (RLC) layer or a packet data convergence protocol (PDCP) layer having a sequence number greater than a predetermined threshold; as well as The congestion event is detected based on detecting the gap.

20. The method according to claim 13, further comprising: detecting that a buffer residence time associated with one or more packets of the traffic flow is greater than a predetermined threshold; as well as The congestion event is detected based on detecting that the buffer residence time is greater than the predetermined threshold.

21. The method according to claim 13, further comprising: determining that a radio quality metric is below a predetermined threshold; as well as The congestion event is detected based on determining that the radio quality metric is below the predetermined threshold.

22. The method according to claim 13, further comprising: Predicting that the quality of the link of the service flow will be lower than a predetermined threshold; as well as The congestion event is detected based on predicting that the quality of the link will fall below the predetermined threshold.

23. The method according to claim 13, further comprising: determining that the first device is at a predetermined location for a predetermined period of time; as well as The congestion event is detected based on determining that the first device is at the predetermined location for the predetermined time period.

Images