Radio link control layer congestion signaling techniques

Abstract

The present application relates to devices and components including apparatuses, systems, and methods for congestion signaling over a radio link control layer in a wireless network.

Description

Technical Field

[0001] The present application relates generally to communication networks, and in particular to techniques for Radio Link Control (RLC) congestion signaling in such networks. Background Art

[0002] Low Latency Loss Scaled Throughput (L4S) is a technology based on Internet Engineering Task Force (IETF) standardization. L4S provides high throughput and low latency for Internet Protocol (IP) traffic, which results in improved fast radio adaptation management and reduced 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 A network environment with integrated access and backhaul concepts according to some embodiments is illustrated.

[0005] Figure 3 An apparatus according to some embodiments is illustrated.

[0006] Figure 4 An RLC control protocol data unit (PDU) format according to some embodiments is illustrated.

[0007] Figure 5 The RLC Acknowledged Mode Data (AMD) PDU format according to some embodiments is illustrated.

[0008] Figure 6 The RLC Unacknowledged Mode Data (AMD) PDU format according to some embodiments is illustrated.

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

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

[0011] Fig. 9 User equipment according to some embodiments is illustrated.

[0012] Fig.10 A network node according to some embodiments is illustrated. DETAILED DESCRIPTION

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

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

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

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

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

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

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

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

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

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

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

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

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

[0026] Current L4S technology relies on explicit congestion notification (ECN) in the IP header to indicate queue accumulation in intermediate routers or radio links. Upon ECN reception, the congestion signal can be propagated back to the transmitter. The signal can be transmitted via a Transmit Control Protocol (TCP) ECN echo that triggers an extensible congestion control algorithm. A TCP Congestion Window Reduction (CWR) bit can be transmitted back to confirm to the receiver that the congestion indication echo was received. Similar signaling can be supported on other Layer 4 (L4) protocols such as QUIC.

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

[0028] Changing the ECN bits in the IP header when queues begin to grow to signal congestion is called marking. ECN / L4S uses the 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, not to drop packets.

[0029] L4S allows for relatively fine-grained congestion control depending on the application (e.g., using active queue management (AQM) and scalable TCP). L4S allows for improved queue utilization and better use of network resources. If applied to the 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.

[0030] Figure 1 A 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 via which the UE 104 and the base station 108 communicate may be compatible with 3GPP technical specifications, such as those defining fifth generation (5G) NR or later system standards.

[0031] The network environment 100 also includes three end nodes, 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 .

[0032] The end nodes may communicate with each other through the UE 104, the base station 108, and one or more network hops 124. The end nodes may host application layers that communicate application traffic with each other through intermediate network nodes. The network hops 124 may include hops in the RAN, a core network (CN), an external data network, etc.

[0033] In some embodiments, the equipment of BS 108 or 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 2A network environment 100 is illustrated that implements the IAB concept that can be used in some embodiments. In an IAB deployment, the 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 the 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.

[0034] The base station 108 may correspond to one or more IAB nodes (e.g., IAB node 212, IAB donor 204, etc.) in a gNB or an IAB node. In some embodiments, the base station 108 may be separate from the IAB node and may be disposed, 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.

[0035] The IAB donor 204 may have a distributed unit (DU) 216 and a centralized unit (CU) 220 placed on separate devices. Generally speaking, the IAB donor CU 220 may process 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 may process 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).

[0036] 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 functions similar to those 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 functions 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 (eg, the IAB donor 204 as shown) or another IAB node may be considered as the base station 108 .

[0037] In the cellular data path architecture included in the network environment 100, queuing can be applied to packets in the UE 104 and the BS 108. For the UE 104, in order to ensure that the 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 prediction of the uplink grant from the BS 108, the data path can be encrypted and have new packets ready to send. However, due to the highly dynamic nature of the wireless link at the millimeter wave (mmWave) frequency in the cellular network (such as the 5G network), the throughput may drop for a sustained period of time. This may occur when the UE 104 has a non-line of sight (NLOS) connection with the frequency range 2 (FR2) tower. In addition, due to suboptimal radio conditions, the wireless link may experience retransmission of packets at several layers (such as, for example, the MAC layer or the radio link control (RLC) layer). In such cases, the L2 / MAC queue may experience buffer expansion. Similarly, for the BS 108, packets can be queued for scheduling opportunities, and based on bandwidth conditions, the queue may experience buffer expansion. Embodiments of the present disclosure provide for detecting congestion at queues such as UE 104 and BS 108. Upon detecting a congestion event, embodiments provide for setting a congestion experience (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.

[0038] 5G NR and LTE support ECN at the IP layer, where base stations and UEs can insert ECN code points as specified in Section 5 of IETF Request for Comments (RFC) 3168, September 2001, "Adding Explicit Congestion Notification (ECN) to IP". Specifically, the UE and base station can set the CE code point "11" in the Packet Data Convergence Protocol (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 can 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 CE endpoint to reach its destination. The embodiments described herein provide for inserting a CE code point at the head of an RLC queue, for example, for transmission over an air interface.

[0039] Support for extended reality (XR) services requires low latency and high throughput. L4S can be used to reduce latency and congestion and provide users of XR services with the desired experience.

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

[0041] From the perspective of the wireless interface, it may be advantageous to determine whether congestion exists at the radio layer or other points within the 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 for supporting use cases where full end-to-end ECN / L4S consistency is desired, some embodiments may provide more than one bit (e.g., two bits) for the CE indication. ECN, L4S, and CE may be used interchangeably throughout this specification.

[0042] Embodiments describe how the RLC layer can support an early CE indication mechanism that allows an indication packet to be inserted at the head of a queue. Embodiments include providing CE indication at layer 2 on the RLC. Some aspects include including a CE code point on the RLC entity, an RLC control / data PDU header format, a method for early signaling of CE indication, and aspects of populating CE information to upper layers.

[0043] As described below, some embodiments provide CE indication at the RLC layer.

[0044] As mentioned earlier, 5G NR currently relies on ECN marking starting from the tail of the PDCP queue (i.e., from the head of the IP queue), which is slow considering the large capacity of the L2 buffer. On the other hand, XR services require lower latency and high throughput. Inserting ECN / CE marking at the head of a normal PDCP DRB is quite difficult because PDCP performs encryption and integrity protection. Therefore, the PDU at the head of the PDCP queue cannot be easily modified by directly inserting the ECN / CE marking.

[0045] Some embodiments provide for inserting a CE indication at the head of the RLC queue of the RLC entity in a new RLC header field. This can be enabled to a certain extent because the RLC header is not encrypted.

[0046] Figure 3 A device 300 is shown according to some embodiments. The device 300 can be a UE 104, a base station 108 (as an IAB node or different therefrom), or a device of a network hop 124 (e.g., an IAB node / donor). The device 300 can include multiple protocol layers, collectively shown as an indication layer 304, an upper layer 308, and a lower layer 312. The indication layer 304 can be an RLC layer that provides an indication of a congestion event. The upper layer 308 and the lower layer 312 can be defined with respect to the indication layer 304.

[0047] In various embodiments, congestion events may be detected at the indication layer 304, the upper layer 308, or the lower layer 312. If a congestion event is detected in the upper layer 308 or the lower layer 312, the detection layer may notify the indication layer 304 of the congestion indication or event, for example, in a primitive or message.

[0048] After detecting a congestion event directly or from inter-layer signaling, the indication layer 304 may initiate the generation of RLC packets including CE indications, which may be referred to as CE packets. These CE packets may be sent from the indication layer 304 in the same direction as the traffic flow where the congestion was detected or in the opposite direction.

[0049] Although the embodiment describes that the indication layer 304 provides a CE indication in an RLC packet sent in an uplink or downlink, it can be noted that the indication layer 304 can also notify the upper layer 308 or the lower layer 312 of congestion. For example, if the indication layer 304 detects congestion, or receives a congestion indication from the lower layer 312, the indication layer can generate / transmit a CE packet and can also provide a congestion indication to the upper layer 308. For another example, if the indication layer 304 detects congestion, or receives a congestion indication from the upper layer 308, the indication layer can generate / transmit a CE packet and can also provide a congestion indication to the lower layer 312.

[0050] The RLC layer of the device can transfer upper layer PDUs in confirmed mode (AM), unconfirmed mode (UM), or transparent mode (TM). The RLC layer can manage RLC service data units (SDUs) and PDUs separately for each of these modes to provide error detection and recovery. RLC can provide error correction through automatic repeat request (ARQ) for AM data transfer, and can perform concatenation, segmentation, and reassembly of RLC SDUs for UM and AM data transfer. RLC can also provide various other operations, including, for example, re-segmenting RLC data PDUs for AM data transfer, reordering RLC data PDUs for UM and AM data transfer, detecting duplicate data for UM and AM digital transfer, discarding RLC SDUs for UM and AM data transfer, detecting protocol errors for AM data transfer, and performing RLC re-establishment.

[0051] AM RLC can use state variables to assist its functions on the transmit side. These state variables may include: a transmit state variable having a sequence number (SN) to be assigned to the next AMD PDU to be generated; an acknowledgement state variable having the SN of the next RLC SDU to be received in sequence for positive acknowledgement; and a set polling transmit state variable having the highest SN of the AMD PDU submitted to the lower layer with the variable.

[0052] With respect to RLC state variables, dynamically inserting a complete RLC data PDU (e.g., at the head of a queue) can be complex because it can involve updating RLC state variables. Embodiments of the present disclosure can provide RLC congestion signaling in a manner that avoids complicating RLC state variables. For example, embodiments can utilize unused bits in the RLC header of the RLC data PDU, or add new header fields for the purpose of CE indication. These header fields can be dynamically updated just before transmission.

[0053] With respect to RLC segmentation, the CE indication may only need to be inserted in the first or last segment. Alternatively, the CE indication may be included in any segment (or all segments) to improve reliability and allow faster processing without waiting for the remaining segments.

[0054] In some cases, PDCP duplication may be used where one PDCP entity is associated with multiple RLC entities. If PDCP duplication is enabled in an implementation, consideration may be given to selecting an appropriate RLC entity and reducing the need to transmit the same CE indication at other RLC entities. For example, with PDCP duplication, a delayed update of the RLC header may quickly become complex if it is to be done across four RLC entities. Similarly, if the DRB is configured as a split bearer, the CE indication may be made at any RLC entity, most likely selecting the RLC entity with the smallest delay.

[0055] In some embodiments where there are multiple RLC entities, a master RLC entity may be selected to signal the CE indication. However, in other embodiments, other RLC entities may be selected.

[0056] In some embodiments, only when the IP flow or DRB supports ECN / L4S, it is necessary to perform the RLC CE indication operation. To achieve this, the RLC can be configured by the RRC to enable / disable the ECN / L4S (CE) indication. For example, in some embodiments, the RLC layer can ensure that the CE indication is enabled for the IP flow or DRB before the CE indication is signaled. In addition / alternatively, the upper layer can check the content of the IP header (e.g., the ECN bit for each data packet). The upper layer can provide the RLC with an indication of whether the IP flow or DRB supports ECN / L4S. If supported, the RLC can perform the CE indication operation.

[0057] As will be discussed in further detail herein, the RLC transmitter may add a CE indication in the RLC header of an RLC control PDU or an RLC data PDU. The CE indication may support both RLC UM and RLC AM.

[0058] In some embodiments, the RLC transmitter may be allowed to update the RLC header fields of multiple RLC PDUs with the same content. This may be used to improve the reliability of the CE indication information in the event that the RLC PDU is lost in the air. Additionally / alternatively, this may be used to relax restrictions on device implementations at, for example, UE 104, IAB-MT 224, or BS 108, since these devices may mark CE packets in an asynchronous manner.

[0059] Figure 4The RLC control PDU format 400 for CE indication according to some embodiments is illustrated. Specifically, the format 400 may include a format 404, which is an RLC control PDU format without SN for CE indication; a format 408, which is an RLC control PDU format with 18-bit SN for CE indication; and a format 412, which is an RLC control PDU format with 12-bit SN for CE indication. The format 400 may also include formats 416, 420, and 424, which represent three options for the RLC control PDU format with 6-bit SN for CE indication. Format 416 corresponds to the first option, in which the two reserved bits marked as "R" are located in the first octet, and the SN is distributed in the first octet and the second octet. Format 420 corresponds to the second option, in which the reserved bits are used in the second octet, and the SN is distributed in the first octet and the second octet. Format 424 corresponds to the third option, in which the four reserved bits are in the first octet, and the SN is in the second octet. The RLC entity may use one or both of the reserved bits to provide a CE indication.

[0060] The transmitter may insert one or more RLC control PDUs based on any of these formats to indicate the congestion status of the RLC entity. The control PDU may be inserted at the head (first position) of the RLC queue, or its transmission may take precedence over other PDUs in the queue.

[0061] If one bit is used to provide a CE indication in the RLC control PDU format, the CE indication may be a CE set indication or a CE clear indication. A CE set indication may indicate that a traffic flow is experiencing congestion. A CE clear indication may indicate that a traffic flow is not experiencing congestion. While many embodiments describe congestion as existing in a binary state, e.g., congestion is present or not present, other embodiments may provide for detecting / signaling different levels of congestion in similar situations.

[0062] If two bits are used to provide the CE indication, 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.

[0063] Binary code point Code point name meaning 00 Does not support ECT Does not support ECN transfers 01 ECT(1) Support ECN transmission 10 ECT(0) Support ECN transmission 11 CE Congestion experience

[0064] Table 1

[0065] Binary code point Code point name meaning 00 Does not support ECT Does not support ECN transfers 01 ECT(1) Support L4S transmission 10 ECT(0) Does not support L4S transmission 11 CE Congestion experience

[0066] Table 2

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

[0068] In some embodiments, upon receiving an RLC control PDU with a CE indication but no SN, the receiver may associate the congestion indication with the first SN currently in the queue. For example, this may be the next SN passed to upper layers.

[0069] In some embodiments, upon receiving an RLC control PDU with a CE indication and an SN, the receiver may associate a congestion indication with the indicated SN. The receiver may also associate congestion indications for all subsequent SNs starting from that SN until a different congestion indication is received.

[0070] As briefly discussed above, for a PDCP entity associated with multiple RLC entities, a CE indication may be transmitted on one or more RLC entities. One of the multiple RLC entities associated with the PDCP entity may be selected to provide a CE indication. An entity may be a primary RLC entity, a network configured RLC entity, or any other RLC entity that may be specifically implemented by a device or selected based on queue size / status, for example. In some embodiments, more than one RLC entity may be used to provide a CE indication, including, for example, all RLC entities.

[0071] Table 3 below illustrates code point values ​​for a Control PDU Type (CPT) field that may be set in one of the formats 400 according to some embodiments.

[0072]

[0073] Table 3

[0074] The CPT field may be a 3-bit field indicating the type of the RLC control PDU.

[0075] Some embodiments may provide a CE indication via an RLC data PDU. These PDUs may be RLC AM data (AMD) PDUs or RLC UM data (UMD) PDUs. The PDU header may contain a segment offset (SO) field only if the data field consists of an RLC SDU segment that is not the first segment. Therefore, if the CE indication is only contained in the first segment, only the UMD / AMD PDU format without the SO field needs to be considered. Otherwise, the remaining RLC PDU formats need to be updated in a similar manner.

[0076] Figure 5 The RLC AMD PDU 500 according to some embodiments is illustrated. Specifically, Figure 5 Format 504 and format 508 are illustrated.

[0077] Format 504 is an AMD PDU format with a 12-bit SN and no SO with a CE indication. A conventional AMD PDU format with a 12-bit SN and no SO may not have available reserved bits. Therefore, in format 504, an extra byte is added after the second octet so that one or more reserved bits can be used for a CE bit, which is used for a CE indication.

[0078] Format 508 is an AMD PDU format with an 18-bit SN and no SO for CE indication. Format 508 contains two reserved bits in the first octet. One or more of these bits may be used as the CE bit for CE indication.

[0079] Figure 6 An RLC UMD PDU 600 according to some embodiments is illustrated. Specifically, Figure 6 Format 604, format 608, and format 612 are illustrated.

[0080] Format 604 is a UMD PDU format with a 12-bit SN and a complete RLC SDU with a CE indication. Format 604 contains six reserved bits in the first octet. One or more of these bits may be used as a CE bit for a CE indication.

[0081] Format 608 is a UMD PDU format with a 12-bit SN and no SO with a CE indication. Format 608 contains two reserved bits in the first octet. One or more of these bits may be used as a CE bit for a CE indication.

[0082] Format 612 is a UMD PDU format with a 6-bit SN and no SO with a CE indication. The conventional UMD PDU format with a 6-bit SN and no SO may not have available reserved bits. Therefore, in format 612, an extra byte is added in the second octet so that one or more reserved bits can be used for the CE bit, which is used for the CE indication.

[0083] Assuming that the CE indication is only used for DRBs mapped to IP flows supporting ECN / L4S, only one CE bit may be needed to set or clear the congestion indication.The use of congestion indication by the RLC entity may be enabled / disabled based on the RRC configuration.

[0084] When the receiving side of the RLC entity receives a PDU with a congestion indication, and if the same PDU has been received multiple times (e.g., repeated reception), congestion marking can be considered only on one RLC entity. However, in any case, the RLC receiver of the RLCAM discards the duplicate PDU.

[0085] For some embodiments, operations performed by an RLC entity receiving a PDU with a congestion indication may be described as follows.

[0086] Upon receiving an RLC PDU with a CE indication, the RLC receiver may perform one or more of the following options.

[0087] In a first option, if the RLC header contains a CE flag indicating that the traffic flow is experiencing congestion (e.g., one CE bit is set to "1" or two CE bits are set to "11"), the RLC receiver may pass the congestion flag to an upper layer (e.g., a PDCP layer or a backhaul adaptation protocol (BAP) layer). The RLC layer may provide congestion indication to the upper layer in a primitive, event, or message designed for inter-layer signaling. The inter-layer signaling may be applied to this option / implementation and other options / implementations described herein.

[0088] In a second option, if the RLC header contains a CE indication indicating that the traffic flow has not experienced congestion (e.g., one CE bit is set to "0" or two CE bits are set to "00", "01", or "10"), but the last CE indication indicates that congestion has been experienced, the RLC receiver may pass the congestion marking to an upper layer (e.g., a PDCP layer or a BAP layer).

[0089] In a third option, the RLC receiver may transparently forward the content of the CE bit to upper layers (eg, PDCP or BAP) for each PDU.

[0090] In a fourth option, the RLC receiver may forward the content of the CE bit to upper layers (eg, PDCP or BAP) only if the content of the CE bit has changed compared to the previous PDU.

[0091] These options may involve the RLC receiver checking the CE bit on each RLC data PDU. However, in some embodiments, RLC control PDUs with a CE indication may be transmitted only if the congestion status has changed, to reduce overhead.

[0092] When two CE bits are supported, the RLC entity may check the indication information / pass the indication information to the upper layer only when the transport layer indicates that ECN / L4S is enabled (eg, supports transmission of ECN / L4S).

[0093] The sequence numbering aspects may be handled at the receiver according to one or more of the following options.

[0094] In a first option, the RLC receiver may indicate a congestion indication to an upper layer (e.g., a PDCP layer or a BAP layer) starting from the earliest possible SN. The congestion indication may be valid for all subsequent SNs until a new congestion indication associated with a different congestion condition is received, in which case the new congestion indication may be transmitted to the upper layer. For example, if the RLC receiver receives a CE set indication associated with SN 15. The receiver may provide a congestion indication to the upper layer to indicate that SN 15 is experiencing congestion. It may be assumed that all SNs after SN 15 are also experiencing congestion. If the RLC receiver receives a CE clear indication associated with SN 23, the receiver may provide a different congestion indication to the upper layer to indicate that SN 23 is not experiencing congestion.

[0095] In the second option, the RLC receiver may provide a congestion indication to an upper layer (e.g., a PDCP layer or a BAP layer) from the next SN delivered. For example, if the CE indication is received with or after SN 15, the RLC receiver may provide a congestion indication for SN 16 to the upper layer if SN 16 is the next SN eligible to be delivered to the upper layer. This indication may be valid for all subsequent SNs until the congestion condition changes, in which case another indication may be transmitted to the upper layer.

[0096] In a third option, the RLC receiver may provide a congestion indication to an upper layer (e.g., a PDCP layer or a BAP layer) starting from an optional SN indicated in the RLC PDU. The optional SN may correspond to an SN provided to indicate a position in a queue to which a CE indication is to be applied, or a second SN in an RLC data PDU. The indication may be valid for all subsequent SNs until the congestion condition changes, in which case another indication may be transmitted to the upper layer.

[0097] In a fourth option, the RLC receiver may forward the content of the CE bit to an upper layer (eg, PDCP layer or BAP layer) for each PDU. In this case, the RLC receiver may not need to track the existing congestion situation, as the indication may be forwarded transparently.

[0098] In a fifth option, the RLC receiver may forward the contents of the CE bits to upper layers for any PDU where the CE indication indicates that congestion is being experienced (eg, one CE bit is set to "1" or both CE bits are set to "11").

[0099] In the sixth option, the RLC receiver may provide a congestion indication to an upper layer (e.g., a PDCP layer or a BAP layer) only for a specific SN. For example, if the RLC layer receives a CE setting indication for SN 15, the RLC layer may provide a congestion indication to the upper layer for SN 15 instead of for subsequent SNs.

[0100] According to some embodiments, the RLC transmitter may operate as follows.

[0101] When a one-bit CE indication is used, when congestion is detected (e.g., the traffic flow is experiencing congestion), the transmitter may set the CE bit to indicate a CE set condition (e.g., setting the CE bit to "1"). When congestion is not detected (e.g., the traffic flow is not experiencing congestion), the RLC transmitter may set the CE bit to indicate a CE clear condition (e.g., setting the CE bit to "0"). The CE clear condition may correspond to a default value.

[0102] When both CE bits are supported, the RLC transmitter can provide a CE indication only when the transport layer indicates ECN / L4S as enabled (e.g., the device has a transport that supports ECN / L4S). The CE bit can be set to "11" to indicate that the traffic flow has experienced congestion, and can be set to a default value for the connection when no congestion is detected. The default value for the connection can be configured by upper layers, or can be detected based on the contents of the IP header for the PDU (e.g., from the IP payload), which can be signaled from upper layers to the RLC layer.

[0103] In another aspect, the RLC transmitter operations may reflect the same type of operations as indicated at the RLC receiver, but in the opposite direction.

[0104] Upon detecting the presence or absence of congestion, the RLC transmitter may set the CE bit in the RLC PDU according to one or more of the following options.

[0105] In a first option, if congestion is detected in the RLC, or if other layers indicate that congestion exists, the RLC transmitter may set or update the CE flag to provide a CE setting indication in the RLC header (e.g., one CE bit set to "1" or two CE bits set to "11").

[0106] In a second option, if no congestion is detected in the RLC, or if other layers indicate that there is no congestion, the RLC transmitter may set the CE flag to provide a CL clear indication in the RLC header (e.g., one CE bit is set to "1" or two CE bits are set to "00", "01", or "10").

[0107] In a third option, the RLC transmitter may transparently reflect the content of the CE bit received from other layers in the RLC header for each PDU. For example, the RLC transmitter may receive inter-layer signaling of a congestion indication and may set the CE bit in the RLC header based on the congestion indication.

[0108] In a fourth option, the RLC transmitter may update the content of the CE bit in the RLC header only if the content of the CE bit has changed compared to the previous PDU.

[0109] These options may include the RLC sender checking whether the traffic flow supports ECN / L4S or CE bit.In some embodiments, RLC control PDUs with CE indication may be transmitted only if the congestion status has changed to reduce overhead.

[0110] In some embodiments, when two CE bits are supported, the RLC entity may insert the two CE bits in the RLC header only if the transport layer indicates that ECN / L4S is enabled, for example, only if the device has support for ECN / L4S transport.

[0111] The sequence numbering aspects may be handled at the RLC transmitter according to one or more of the following options.

[0112] In the first option, the RLC transmitter may provide a CE indication in the RLC header starting from the earliest possible SN. The CE indication may be valid for all subsequent SNs (and included in the corresponding RLC headers) until the underlying congestion condition changes, in which case the CE indication in the RLC header may be changed appropriately.

[0113] In a second option, the sender may provide a CE indication in the RLC header from the next SN delivered. The indication may be valid for all subsequent SNs (and included in the corresponding RLC headers) until the underlying congestion conditions change, in which case the CE indication within the RLC header may be changed appropriately.

[0114] In a third option, the transmitter may indicate a congestion experience indication and its optional SN in the RLC control PDU header. The indication may be valid for all subsequent SNs (and included in the corresponding RLC header) until the underlying congestion condition changes, in which case the CE indication in the RLC header may be changed appropriately.

[0115] In a fourth option, the RLC transmitter may insert the content of the CE bit received from the upper layer into the RLC header each time. In this embodiment, the RLC transmitter may transparently update the RLC header based on the congestion indication provided to the RLC layer from other layers.

[0116] In a fifth option, the transmitter may provide congestion indication in the RLC header only for specific SNs. For example, if congestion is detected with respect to SN 15, the RLC transmitter may provide setting the CE bit in the RLC header associated with SN 15 in a manner indicating congestion. RLC headers associated with subsequent SNs may not be set based on the detected congestion.

[0117] In some implementations, the congestion status may be updated indirectly based on the RLC status reports.

[0118] Setting the congestion indication in RLC using the RLC status report can be performed as follows. One of the R bits of the RLC status report can be used for the CE bit to indicate the CE setting status or the CE clearing status. The first SN to which the congestion indication is applied can be identified from ACK_SN / NACK_SN (whichever is lower). The method can work in the direction from the receiver to the transmitter. For example, when a congestion event is detected, the base station 108 (DU or CU) can transmit an RLC status report with a CE indication to the UE 104 in the downlink. The base station 108 can also insert the CE bit in the forward direction toward the UPF. The RLC receiver at the UE 104 can provide a congestion indication to its IP layer (starting from the indicated SN or immediately) to signal the L4S in the uplink. In addition, in some cases, the CE indication provided in the RLC status report can be used as a prompt to the lower layer of the UE to schedule less data on the RLC queue if it is optional to do so.

[0119] According to some embodiments, the network layer impact may be described as follows.

[0120] Since RLC may be supported only between the UE (or IAB-MT) and the gNB-DU, the IAB node or base station 108 may extract the CE information from the RLC header and pass it to the upper layers, forward it to the next hop, signal congestion using a flow control mechanism (available on the RAN3 interface), or forward the L4S feedback to the upper layers, which further forward the feedback indication (e.g., at the gNB-CU). Forwarding the CE indication to the upper layers may be performed by: forwarding to the UPF via GTP, and then the UPF updates the IP header; the BS 108 updates the IP header in the PDCP SDU; or the BS 108 forwards the L4S information to and from the IP layer. The final destination of the CE indication may be the application layer. Therefore, the UPF may need to further forward / apply the CE indication.

[0121] The same process can be applied in the opposite direction.

[0122] Advantages of RLC-based CE indication may include finer granularity in terms of SN, since very late updates (just before delivery to MAC) are possible. Thus, CE indication becomes very fast. Furthermore, the option of having RLC control PDUs may be less complex. However, some implementation-specific complexities may need to be addressed, and other network entities may need to carry along L4S information.

[0123] Figure 7It is an operation flow / algorithm structure 700 according to some embodiments. The operation flow / algorithm structure 700 may be implemented by an RLC transmitter included in a UE (e.g., UE 104 or UE 900), or a network node (e.g., BS 108, IAB node 212, IAB donor 204, or network node 1000) or a component thereof (e.g., processing circuit 904 or 1004).

[0124] The operational flow / algorithm structure 700 may include, at 704, detecting a congestion event associated with the first traffic flow. In some embodiments, the RLC layer may detect the congestion event based on inter-layer signaling. For example, the RLC layer may detect the congestion event based on a congestion indication received from an upper layer or a lower layer of a device implementing the RLC layer. In some embodiments, the RLC layer may detect the congestion event based on inter-device signaling. For example, the RLC layer may receive RLC feedback or an RLC status report from another device.

[0125] The operational flow / algorithm structure 700 may also include generating an RLC PDU with a CE indication at 708. The CE indication may be provided by one or more CE bits set to provide a CE set indication to indicate that the traffic flow is experiencing congestion, or it may be a CE clear indication to indicate that the traffic flow is not experiencing congestion. In other embodiments, the CE indication may be set to provide an indication of the degree of congestion experienced by the traffic flow.

[0126] In some embodiments, the RLC PDU may be an RLC control PDU, which may be sent in priority over other PDUs in the queue. The RLC control PDU may include no sequence number and one octet; an 18-bit sequence number; a 12-bit sequence number; a 6-bit sequence number in the first of two octets of the RLC control PDU; a 6-bit sequence number in the second of two octets of the RLC control PDU; or a 6-bit sequence number distributed in the first and second octets of two octets of the RLC control PDU.

[0127] In some embodiments, the RLC PDU may be an RLC data PDU. The RLC data PDU may include a complete RLC SDU, or may include an RLC SDU segment with the lowest segment index number among multiple RLC SDU segments (thus, the RLC data PDU may not include the SO field). The RLC data PDU may include an AMD format or a UMD format. In some embodiments, if the RLC data PDU has an AMD format, it may include an 18-bit sequence number and one or more bits of an octet with the lowest octet index number among multiple octets of the RLC data PDU to carry a CE indication. In some embodiments, if the RLC data PDU has an AMD format, it may include a 12-bit sequence number and one or more bits of an octet with an octet index number greater than two to carry a CE indication.

[0128] The operational flow / algorithm structure 700 may also include sending an RLC PDU at 712. The RLC PDU may be sent in the direction of the traffic flow associated with the congestion event or in the opposite direction.

[0129] Figure 8 It is an operation flow / algorithm structure 800 according to some embodiments. The operation flow / algorithm structure 800 may be implemented by an RLC receiver included in a UE (e.g., UE 104 or UE 900), or a network node (e.g., BS 108, IAB node 212, IAB donor 204, or network node 1000) or a component thereof (e.g., processing circuit 904 or 1004).

[0130] The operational flow / algorithm structure 700 may include receiving an RLC PDU with a CE indication at 704. The RLC PDU may be associated with a traffic flow to or from another device. The RLC may have a CE indication corresponding to the traffic flow. The CE indication may be a CE set indication to indicate that the traffic flow is experiencing congestion, or may be a CE clear indication to indicate that the traffic flow is not experiencing congestion. The RLC PDU may have a CE indication similar to that described above with respect to Figure 7 or the format described elsewhere in this document.

[0131] At 708, the operation flow / algorithm structure 700 may also include providing a signal to an upper layer of a device implementing the RLC transmitter. The signal may be an inter-layer signal, such as a primitive, an event, or a message. The signal may provide a congestion indication associated with the traffic flow.

[0132] In some embodiments, the RLC transmitter may also provide an inter-device signal to provide a CE indication to the RLC layer of another device based on the CE indication of the RLC PDU.

[0133] Fig. 9UE 900 according to some embodiments is illustrated. UE 900 may be similar to Figure 1 UE 104 and is substantially interchangeable therewith.

[0134] UE 900 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.

[0135] UE 900 may include a processor 904, RF interface circuitry 908, memory / storage 912, a user interface 916, a sensor 920, a driver circuit 922, a power management integrated circuit (PMIC) 924, antenna structures 926, and a battery 928. The components of UE 900 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. Fig. 9 The block diagram of UE 900 is intended to show a high-level view of certain of the components of UE 900. 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.

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

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

[0138] In some embodiments, the baseband processor circuit 904A can access the communication protocol stack 936 in the memory / storage device 912 to communicate through a 3GPP compatible network. Generally speaking, the baseband processor circuit 904A can access the communication protocol stack 936 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 908.

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

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

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

[0142] In the receive path, the RFEM may receive the radiated signal from the air interface via the antenna structure 926 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 904.

[0143] 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 926.

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

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

[0146] The user interface circuit 916 includes various input / output (I / O) devices designed to enable a user to interact with the UE 900. The user interface 916 includes input device circuits and output device circuits. The input device circuit includes any physical or virtual components for accepting input, including in particular 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, including in particular 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 900.

[0147] Sensors 920 may include devices, modules, or subsystems that are designed to detect events or changes in their environment and transmit 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.

[0148] The driver circuit 922 may include software elements and hardware elements for controlling a specific device embedded in the UE 900, attached to the UE 900, or otherwise communicatively coupled to the UE 900. The driver circuit 922 may include separate drivers, thereby allowing other components to interact with or control various I / O devices that may be present in the UE 900 or connected to the UE. For example, the driver circuit 912 may include circuits that facilitate coupling a UICC (e.g., UICC 98) to the UE 900. For another example, the driver circuit 922 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 920 and controlling and allowing access to the sensor circuit 920, a driver for obtaining actuator positioning 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, and an audio driver for controlling and allowing access to one or more audio devices.

[0149] The PMIC 924 may manage power provided to various components of the UE 900. Specifically, with respect to the processor 904, the PMIC 924 may control power source selection, voltage scaling, battery charging, or DC-DC conversion.

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

[0151] The battery 928 can power the UE 900, but in some examples, the UE 900 can be installed in a fixed location and can have a power source coupled to the power grid. The battery 928 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 928 can be a typical lead-acid car battery.

[0152] Fig.10 Illustrated is a network node 1000 according to some embodiments. The network node 1000 may be similar to, and substantially interchangeable with, a 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.

[0153] The network node 1000 may include a processor 1004 , RF interface circuitry 1008 (if implemented as an access node), core network (CN) interface circuitry 1012 , memory / storage circuitry 1016 , and antenna structures 1026 .

[0154] Components of network node 1000 may be coupled to various other components via one or more interconnects 1028 .

[0155] The processor 1004, RF interface circuit 1008, memory / storage circuit 1016 (including communication protocol stack 1010), antenna structure 1026 and interconnect 1028 may be similar to those described with reference to Fig. 9 Like named elements are shown and described.

[0156] The CN interface circuit 1012 may provide connectivity for 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 1000 via optical fiber or wireless backhaul. The CN interface circuit 1012 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 1012 may include multiple controllers for providing connectivity to other networks using the same or different protocols.

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

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

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

[0160] Example

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

[0162] Embodiment 1 includes a method of operating a first device, the method comprising: detecting a congestion event associated with a traffic flow; generating a radio link control (RLC) protocol data unit (PDU) with a congestion experienced (CE) indication; and sending the RLC PDU to a second device.

[0163] Embodiment 2 includes a method according to embodiment 1 or some other embodiment herein, wherein the RLC PDU is an RLC control PDU, and the method further comprises: placing the RLC control PDU in a queue, wherein the RLC control PDU is sent in priority to other PDUs in the queue.

[0164] Embodiment 3 includes a method according to embodiment 1 or some other embodiment herein, wherein the RLC PDU is an RLC control PDU, and the RLC control PDU includes: no sequence number and one octet; an 18-bit sequence number; a 12-bit sequence number; a 6-bit sequence number in the first octet of the two octets of the RLC control PDU; a 6-bit sequence number in the second octet of the two octets of the RLC control PDU; or a six-bit sequence number distributed in the first octet and the second octet of the two octets of the RLC control PDU.

[0165] Embodiment 4 includes a method according to embodiment 1 or some other embodiment herein, wherein the RLC PDU is an RLC control PDU, and the RLC control PDU includes a field for indicating that the RLC control PDU has no sequence number, has an 18-bit sequence number, has a 12-bit sequence number, or has a 6-bit sequence number.

[0166] Embodiment 5 includes a method according to embodiment 1 or some other embodiment herein, wherein the RLC PDU is an RLC data PDU having a data field, wherein the data field includes a complete RLC service data unit (SDU) or includes an RLC SDU segment having the lowest segment index number among multiple RLC service data unit (SDU) segments.

[0167] Embodiment 6 includes a method according to embodiment 5 or some other embodiment herein, wherein the RLC data PDU includes: an acknowledgement mode data (AMD) format; an 18-bit sequence number; and one or more bits of an octet with a lowest octet index number among multiple octets of the RLC data PDU to carry a CE indication.

[0168] Embodiment 7 comprises a method according to embodiment 5 or some other embodiment herein, wherein the RLC data PDU comprises: an acknowledgement mode data (AMD) format; a 12-bit sequence number; and one or more bits of an octet having an octet index number greater than two to carry a CE indication.

[0169] Embodiment 8 includes a method according to embodiment 1 or some other embodiment herein, wherein the RLC data PDU includes: an unacknowledged mode data (UMD) format; a complete RLC SDU or a 12-bit sequence number; and one or more bits of an octet with a lowest octet index number among multiple octets of the RLC data PDU to carry a CE indication.

[0170] Embodiment 9 includes a method according to embodiment 1 or some other embodiment herein, wherein the RLC data PDU comprises: an unacknowledged mode data (UMD) format; a 6-bit sequence number; and one or more bits of an octet with an octet index number of two or greater to carry a CE indication.

[0171] Embodiment 10 includes the method according to embodiment 1 or some other embodiment herein, further comprising: detecting, by the RLC layer, a congestion event based on RLC feedback, an RLC status report, or a congestion indication provided by another layer.

[0172] Embodiment 11 includes a method according to embodiment 1 or some other embodiment herein, wherein the RLC PDU is a first RLC PDU, the congestion event is a first congestion event associated with the first RLC PDU, and the method further includes: detecting a second congestion event associated with a second RLC PDU of the traffic flow; and generating multiple RLC PDUs with a CE indication based on detecting the first congestion event, the multiple RLC PDUs including the first RLC PDU and all RLC PDUs generated before the second RLC PDU.

[0173] Embodiment 12 includes a method of operating a first device, the method comprising: receiving, at a radio link control (RLC) layer, an RLC protocol data unit (PDU) having a congestion experience (CE) indication, the RLC PDU being associated with a traffic flow to and from a second device; and providing a signal to an upper layer of the first device based on the CE indication.

[0174] Embodiment 13 includes a method according to embodiment 12 or some other embodiment herein, wherein the CE indication is a CE set indication to indicate that the traffic flow is experiencing congestion, or a CE clear indication to indicate that the traffic flow is not experiencing congestion.

[0175] Embodiment 14 includes the method according to embodiment 12 or some other embodiment herein, the method further comprising: determining that the CE indication has changed from a previous CE indication; and providing a signal to an upper layer of the first device based on the determination that the CE indication has changed from the previous CE indication.

[0176] Embodiment 15 includes a method according to embodiment 12 or some other embodiment herein, wherein the CE indication is a first CE indication associated with a first sequence number of a traffic flow, and the method further includes: receiving a second CE indication associated with a second sequence number; determining that the first CE indication is applicable to a traffic flow having a sequence number between the first sequence number and the second sequence number.

[0177] Embodiment 16 includes a method according to embodiment 15 or some other embodiment herein, wherein the traffic flow has multiple PDUs, the multiple PDUs have sequence numbers between a first sequence number and a second sequence number, and the method further includes: providing a signal to an upper layer for each PDU in the multiple PDUs.

[0178] Embodiment 17 includes a method according to embodiment 12 or some other embodiment herein, wherein the first device is a base station distributed unit, the second device is a user equipment or an integrated access and backhaul mobile terminal, and the method further includes: generating a packet including a CE indication by an upper layer; and sending the packet to the corresponding upper layer of the base station centralized unit.

[0179] Embodiment 18 includes the method of embodiment 17 or some other embodiment herein, wherein the upper layer is an Internet protocol (IP) layer.

[0180] Embodiment 19 includes a method according to embodiment 12 or some other embodiment herein, wherein the signal is a first signal, the first device is an integrated access and backhaul (IAB)-mobile terminal (MT) or an IAB distributed unit (DU), and the method further includes: providing a second signal to the RLC layer of a third device based on a CE indication.

[0181] Embodiment 20 includes the method of embodiment 19 or some other embodiment herein, wherein the third device is an IAB distributed unit or another IAB-MT.

[0182] 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 one or more processors to perform one or more elements of a method described or related to any of Embodiments 1 to 20 or any other method or process described herein.

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

[0184] Another embodiment may include a method, technique or process described or related to any one of Embodiments 1 to 20, or a portion or part thereof.

[0185] Another embodiment may include a device comprising: one or more processors and one or more computer-readable media, the one or more computer-readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform a method, technique, or process, or portion thereof, described or related to any one of Embodiments 1 to 20.

[0186] Another embodiment comprises a signal as described or associated with any one of embodiments 1 to 20, or a portion or part thereof.

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

[0188] Another embodiment may include a signal encoded with data as described or related to any one of embodiments 1 to 20, or a portion or part thereof, or described in other ways in this disclosure.

[0189] Another embodiment may include a signal encoded with a datagram, IE, packet, frame, segment, PDU or message as described or associated with any of Embodiments 1 to 20, or a portion or part thereof, or otherwise described in the present disclosure.

[0190] 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, or portion thereof, described or related to any one of Embodiments 1 to 20.

[0191] 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 20, or a portion thereof.

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

[0193]

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

[0194]

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

[0195]

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

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

[0197] 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: detecting congestion events associated with traffic flows; generating a radio link control (RLC) protocol data unit (PDU) with a congestion experienced (CE) indication; as well as The RLC PDU is sent to a second device.

2. The method according to claim 1, wherein the RLC PDU is an RLC control PDU, and the method further comprises: The RLC control PDU is placed in a queue, wherein the RLC control PDU is sent in priority to other PDUs in the queue.

3. The method according to claim 1, wherein the RLC PDU is an RLC control PDU, and the RLC control PDU comprises: No sequence number and one octet; 18-digit serial number; 12-bit sequence number; 6-bit sequence number in the first octet of the two octets of the RLC control PDU; 6-bit sequence number in the second octet of the two octets of the RLC control PDU; or 6-bit sequence number distributed in the first octet and the second octet of the two octets of the RLC control PDU.

4. The method according to claim 1, wherein the RLC PDU is an RLC control PDU, and the RLC control PDU includes a field for indicating that the RLC control PDU has no sequence number, has an 18-bit sequence number, has a 12-bit sequence number, or has a 6-bit sequence number.

5. The method of claim 1, wherein the RLC PDU is an RLC data PDU having a data field, wherein the data field includes a complete RLC service data unit (SDU) or includes an RLC SDU segment having a lowest segment index number among a plurality of RLC service data unit (SDU) segments.

6. The method according to claim 5, wherein the RLC data PDU comprises: Confirmation mode data (AMD) format; 18-digit serial number; and one or more bits of an octet with a lowest octet index number among a plurality of octets of the RLC data PDU to carry the CE indication.

7. The method according to claim 5, wherein the RLC data PDU comprises: Confirmation mode data (AMD) format; A 12-bit sequence number; and one or more bits of an octet with an octet index number greater than two to carry the CE indication.

8. The method of claim 1, wherein the RLC data PDU comprises: Unacknowledged Mode Data (UMD) format; a complete RLC SDU or a 12-bit sequence number; and one or more bits of an octet with a lowest octet index number among a plurality of octets of the RLC data PDU to carry the CE indication.

9. The method of claim 1, wherein the RLC data PDU comprises: Unacknowledged Mode Data (UMD) format; a 6-bit sequence number; and one or more bits of an octet with an octet index number of two or greater to carry the CE indication.

10. The method according to claim 1, further comprising: The congestion event is detected by the RLC layer based on RLC feedback or RLC status report.

11. The method according to claim 1, further comprising: The congestion event is detected by the RLC layer based on a congestion indication provided by another layer.

12. The method of claim 1, wherein the RLC PDU is a first RLC PDU, the congestion event is a first congestion event associated with the first RLC PDU, and the method further comprises: detecting a second congestion event associated with a second RLC PDU of the traffic flow; as well as A plurality of RLC PDUs with the CE indication are generated based on detecting the first congestion event, the plurality of RLC PDUs including the first RLC PDU and all RLC PDUs generated before the second RLC PDU.

13. A method of operating a first device, the method comprising: receiving, at a radio link control (RLC) layer, an RLC protocol data unit (PDU) having a congestion experienced (CE) indication, the RLC PDU being associated with a traffic flow to or from a second device; as well as A signal is provided to an upper layer of the first device based on the CE indication.

14. The method of claim 13, wherein the CE indication is a CE set indication to indicate that the traffic flow is experiencing congestion, or a CE clear indication to indicate that the traffic flow is not experiencing congestion.

15. The method according to claim 13, further comprising: determining that the CE indication has changed from a previous CE indication; as well as Based on the determining that the CE indication has changed from the previous CE indication, providing the signal to an upper layer of the first device.

16. The method of claim 13, wherein the CE indication is a first CE indication associated with a first sequence number of the traffic flow, and the method further comprises: receiving a second CE indication associated with a second sequence number; as well as It is determined that the first CE indication is applicable to a traffic flow having a sequence number between the first sequence number and the second sequence number.

17. The method of claim 16, wherein the traffic flow has a plurality of PDUs having sequence numbers between the first sequence number and the second sequence number, and the method further comprises: A signal is provided to the upper layer for each PDU in the plurality of PDUs.

18. The method according to claim 13, wherein the first device is a base station distributed unit, the second device is a user equipment or an integrated access and backhaul mobile terminal, and the method further comprises: Generating, by the upper layer, a packet including the CE indication; as well as The packet is sent to a corresponding upper layer of the base station centralized unit.

19. The method of claim 18, wherein the upper layer is an Internet Protocol (IP) layer.

20. The method of claim 13, wherein the signal is a first signal, the first device is an integrated access and backhaul (IAB)-mobile terminal (MT) or an IAB distributed unit (DU), and the method further comprises: A second signal is provided to an RLC layer of a third device based on the CE indication, wherein the third device is an IAB distributed unit or another IAB-MT.

Images