Radio access network (RAN) enhancements for uplink protocol data unit (PDU) sets
By adjusting the uplink packet configuration by receiving delay reports, the transmission of PDU sets in the wireless communication system is optimized, the problems of high delay and error rates in the prior art are solved, and the system efficiency and reliability are improved.
Patent Information
- Application Number
- CN202380090442.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2023-11-16
- Filing Date
- 2023-11-17
- Publication Date
- 2025-08-08
AI Technical Summary
When existing wireless communication systems deal with the uplink protocol data unit (PDU) set, it is difficult to effectively adjust the configuration to reduce delay, packet discarding, and transmission errors, especially to achieve optimization between PDU sets with different QoS attributes.
By receiving a delay report, indicating the delay value and number of lost packets associated with the uplink packet of the MAC TB, the configuration of the uplink packet is adjusted to optimize the transmission of the PDU set.
It realizes the reduction of delay, packet discarding and transmission errors, and improves the efficiency and reliability of wireless communication systems.
Smart Images

Figure CN120457730A_ABST
Abstract
Description
[0001] CROSS-REFERENCE TO RELATED APPLICATIONS
[0002] This application claims priority to U.S. patent application Ser. No. 18 / 511,900, filed on November 16, 2023, entitled “RADIO ACCESS NETWORK (RAN) ENHANCEMENTS FOR UPLINK PROTOCOL DATA UNIT (PDU) SETS,” which claims the benefit of U.S. Provisional Patent Application Ser. No. 63 / 438,210, filed on January 10, 2023, entitled “RADIO ACCESS NETWORK (RAN) ENHANCEMENTS FOR UPLINK PROTOCOL DATA UNIT (PDU) SETS,” the disclosures of which are expressly incorporated by reference in their entireties. Technical Field
[0003] The present disclosure relates generally to wireless communications, and more particularly to radio access network (RAN) enhancements for uplink protocol data unit (PDU) aggregation. Background Art
[0004] Wireless communication systems are widely deployed to provide a variety of telecommunication services such as telephony, video, data, messaging, and broadcasting. Typical wireless communication systems may employ multiple access technologies that can support communication with multiple users by sharing available system resources (e.g., bandwidth, transmit power, etc.). Examples of such multiple access technologies include code division multiple access (CDMA) systems, time division multiple access (TDMA) systems, frequency division multiple access (FDMA) systems, orthogonal frequency division multiple access (OFDMA) systems, single carrier frequency division multiple access (SC-FDMA) systems, time division synchronous code division multiple access (TD-SCDMA) systems, and long term evolution (LTE). LTE / LTE-Advanced is a set of enhancements to the Universal Mobile Telecommunications System (UMTS) mobile standard released by the Third Generation Partnership Project (3GPP). Narrowband (NB) Internet of Things (IoT) and enhanced machine type communications (eMTC) are a set of enhancements to LTE for machine type communications.
[0005] A wireless communication network may include multiple base stations (BSs) that may support communication for multiple user equipment (UEs). User equipment (UEs) may communicate with a base station (BS) via a downlink and an uplink. A downlink (or forward link) refers to a communication link from a BS to a UE, and an uplink (or reverse link) refers to a communication link from a UE to a BS. As will be described in more detail, a BS may be referred to as a Node B, an evolved Node B (eNB), a gNB, an access point (AP), a radio head, a transmit and receive point (TRP), a new radio (NR) BS, a 5G Node B, etc.
[0006] The above multiple access technologies have been adopted in various telecommunication standards to provide a common protocol that enables different user equipment to communicate at the city, country, region, and even global levels. New Radio (NR) (which may also be referred to as 5G) is an enhancement set of the LTE mobile standard released by the Third Generation Partnership Project (3GPP). NR is designed to better integrate with other open standards by improving spectrum efficiency, reducing costs, improving services, utilizing new spectrum, and using orthogonal frequency division multiplexing (OFDM) (CP-OFDM) with a cyclic prefix (CP) on the downlink (DL), and using CP-OFDM and / or SC-FDM (e.g., also known as discrete Fourier transform spread OFDM (DFT-s-OFDM)) on the uplink (UL), as well as supporting beamforming, multiple-input multiple-output (MIMO) antenna technology, and carrier aggregation, thereby better supporting mobile broadband Internet access.
[0007] Protocol Data Unit (PDU) Sets may be specified for wireless services such as extended reality (XR) services. A PDU Set is a collection of PDUs that may be delivered to a receiver as an integrated unit. For example, a PDU Set may be associated with a video frame or a slice within a video frame. In some examples, all PDUs in the same PDU Set share common Quality of Service (QoS) attributes such as, for example, a PDU Set Delay Budget (PSDB) or a PDU Set Error Rate (PSER). A PDU Set may have different decoding criteria (e.g., a PDU Set Content Criteria (PSCC)), which may depend on the specific implementation of a given application. A PDU Set may be a downlink PDU Set or an uplink PDU Set. Summary of the Invention
[0008] In various aspects of the present disclosure, a method for wireless communication includes receiving a latency report from a second wireless communication device, the latency report indicating a first latency value associated with a first uplink packet in a first set of uplink packets associated with a MAC TB, a second latency value associated with a second uplink packet in the first set of uplink packets, and a number of lost uplink packets in the first set of uplink packets. The method also includes adjusting a configuration of a second set of uplink packets based on receiving the latency report. The method also includes transmitting the second set of uplink packets based on adjusting the configuration.
[0009] Other aspects of the present disclosure relate to an apparatus comprising means for receiving a latency report from a second wireless communication device, the latency report indicating a first latency value associated with a first uplink packet in a first set of uplink packets associated with a MAC TB, a second latency value associated with a second uplink packet in the first set of uplink packets, and a number of lost uplink packets in the first set of uplink packets. The apparatus further comprises means for adjusting a configuration of a second set of uplink packets based on receiving the latency report. The apparatus further comprises means for transmitting the second set of uplink packets based on adjusting the configuration.
[0010] In other aspects of the present disclosure, a non-transitory computer-readable medium having non-transitory program code recorded thereon is disclosed. The program code is executed by a processor and includes program code for receiving a latency report from a second wireless communication device, the latency report indicating a first latency value associated with a first uplink packet in a first set of uplink packets associated with a MAC TB, a second latency value associated with a second uplink packet in the first set of uplink packets, and the number of uplink packets lost in the first set of uplink packets. The program code also includes program code for adjusting a configuration of a second set of uplink packets based on receiving the latency report. The program code also includes program code for sending the second set of uplink packets based on adjusting the configuration.
[0011] Other aspects of the present disclosure relate to an apparatus having: one or more processors; and one or more memories coupled to the one or more processors and storing instructions that, when executed by the one or more processors, are operable to cause the apparatus to receive a latency report from a second wireless communication device, the latency report indicating a first latency value associated with a first uplink packet in a first set of uplink packets associated with a MAC TB, a second latency value associated with a second uplink packet in the first set of uplink packets, and a number of lost uplink packets in the first set of uplink packets. Execution of the instructions further causes the apparatus to adjust a configuration of a second set of uplink packets based on receiving the latency report. Execution of the instructions further causes the apparatus to transmit the second set of uplink packets based on adjusting the configuration.
[0012] Aspects generally include methods, apparatus, systems, computer program products, non-transitory computer-readable media, user equipment, base stations, wireless communication devices, and processing systems substantially as described with reference to and as illustrated in the accompanying drawings and description.
[0013] The features and technical advantages of the examples according to the present disclosure have been outlined quite broadly above so that the following detailed description may be better understood. Additional features and advantages will be described. The concepts and specific examples disclosed may be readily used as a basis for modifying or designing other structures for achieving the same purposes of the present disclosure. Such equivalent constructions do not depart from the scope of the appended claims. The characteristics of the disclosed concepts, both in their organization and method of operation, and the associated advantages will be better understood by considering the following description in conjunction with the accompanying drawings. Each of the figures in the drawings is provided for the purpose of illustration and description and not as a definition of limitations to the claims. BRIEF DESCRIPTION OF THE DRAWINGS
[0014] In order that the features of the present disclosure may be understood in detail, a more particular description may be given with reference to various aspects, some of which are illustrated in the accompanying drawings. It should be noted, however, that the drawings illustrate only certain aspects of the present disclosure and are not to be considered limiting of its scope, as the description may admit to other equally effective aspects. The same reference numerals in different drawings may identify the same or similar elements.
[0015] Figure 1 is a block diagram conceptually illustrating an example of a wireless communication network in accordance with various aspects of the present disclosure.
[0016] Figure 2 is a block diagram conceptually illustrating an example of a base station communicating with a user equipment (UE) in a wireless communication network according to various aspects of the present disclosure.
[0017] Figure 3is a block diagram illustrating an example decomposed base station architecture in accordance with various aspects of the present disclosure.
[0018] Figure 4A 、 Figure 4B 、 Figure 4C 、 Figure 4D and Figure 4E is a block diagram illustrating examples of different architectures for processing different sets of protocol data units (PDUs) at a UE in accordance with various aspects of the present disclosure.
[0019] Figure 4F is a block diagram illustrating an example of a conventional architecture for processing different sets of protocol data units (PDUs) at a UE.
[0020] Figure 5 is a block diagram illustrating an example of a Service Data Adaptation Protocol (SDAP) packet in accordance with various aspects of the present disclosure.
[0021] Figure 6A is a block diagram illustrating an example uplink medium access control (MAC) protocol data unit (PDU).
[0022] Figure 6B is a block diagram illustrating an example uplink medium access control (MAC) transport block (TB) in accordance with various aspects of the present disclosure.
[0023] Figure 7A is a block diagram illustrating an example of a Packet Data Convergence Protocol (PDCP) control PDU associated with latency reporting according to various aspects of the present disclosure.
[0024] Figure 7B is a block diagram illustrating an example of a radio link control (RLC) control PDU associated with latency reporting according to various aspects of the present disclosure.
[0025] Figure 7C is a block diagram illustrating an example of a MAC control element (MAC-CE) associated with latency reporting according to various aspects of the present disclosure.
[0026] Figure 8 is a block diagram illustrating an example wireless communication device that supports receiving latency reports associated with one or more PDU sets in accordance with some aspects of the present disclosure.
[0027] Figure 9 is a flow chart illustrating an example process performed by a wireless communication device in accordance with some aspects of the present disclosure. DETAILED DESCRIPTION
[0028] The various aspects of the present disclosure are described more fully below with reference to the accompanying drawings. However, the present disclosure can be embodied in many different forms and should not be construed as limited to any specific structure or function presented throughout the present disclosure. Rather, these aspects are provided so that the present disclosure will be thorough and complete, and will fully convey the scope of protection of the present disclosure to those skilled in the art. Based on the teachings, those skilled in the art should recognize that the scope of the present disclosure is intended to cover any aspect of the present disclosure, whether that aspect is implemented independently of any other aspect of the present disclosure or implemented in combination with any other aspect. For example, a device or method may be implemented using any number of the aspects set forth. In addition, the scope of the present disclosure is intended to cover such devices or methods that are practiced using other structures, functionality, or structure and functionality as a supplement to the various aspects of the present disclosure set forth or in addition. It should be understood that any aspect of the present disclosure disclosed may be embodied by one or more elements of the claims.
[0029] Several aspects of telecommunications systems will now be presented with reference to various devices and techniques. These devices and techniques will be described in the following detailed description and illustrated in the accompanying drawings by various blocks, modules, components, circuits, steps, processes, algorithms, etc. (collectively, "elements"). These elements can be implemented using hardware, software, or a combination thereof. Whether these elements are implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system.
[0030] It should be noted that although various aspects may be described using terms typically associated with 5G and later generation wireless technologies, various aspects of the present disclosure may be applied in communication systems based on other generations, such as and including 3G and / or 4G technologies.
[0031] Protocol data unit (PDU) sets may be specified for wireless services such as extended reality (XR) services. A PDU set is a collection of PDUs that can be delivered to a receiver as an integrated unit. For example, a PDU set may be associated with a video frame or a slice within a video frame. In some examples, all PDUs in the same PDU set share common quality of service (QoS) attributes, such as, for example, a PDU set delay budget (PSDB) or a PDU set error rate (PSER).
[0032] However, in some examples, one or more QoS attributes may differ between PDU sets. In some such examples, PDU sets may have different decoding criteria (e.g., PDU Set Content Criteria (PSCC)), which may depend on the specific implementation of a given application. In a service data stream, different types of data may be present, such as video frame data or audio data. Different decoding criteria may be specified for different types of data. For example, some PDU sets may be associated with an all-or-nothing decoding criterion, where if a receiver fails to decode a PDU in the PDU set, the PDU set may be outdated. As another example, some other PDU sets may be associated with a valid-until-first-loss decoding criterion, where all received PDUs are valid until the first loss occurs. In yet another example, some other PDU sets may be associated with an application-layer forward error correction (AL-FEC) decoding criterion, where the PDUs in the PDU set are encoded using AL-FEC. In some cases, based on the FEC redundancy ratio, only a subset of the PDUs in the PDU set may be used to decode the PDU set.
[0033] In some examples, one or more PDUs in a PDU set may be discarded by a user equipment (UE) or a radio access network (RAN). In some such examples, one or more PDUs may be discarded when a delay budget has been exhausted. Alternatively, the one or more PDUs may be discarded if an associated layer 2 timer has expired. The layer 2 timer may be a packet data convergence protocol (PDCP) discard timer, a radio link control (RLC) reassembly timer, an RLC discard timer, or a PDCP reordering timer. In some other examples, PDUs may be discarded based on decoding criteria associated with the PDU set being met (e.g., content criteria) or if the decoding criteria are no longer met. In some such examples, the decoding criteria may no longer be met if the receiver fails to decode a PDU in the PDU set, and the decoding criteria may be: an all-or-nothing decoding criteria, or a decoding criteria that is valid until the first loss occurs. In other such examples, if one or more PDUs in the PDU set have been successfully decoded, the decoding criteria may have been met, such that additional PDUs in the PDU set are no longer required.
[0034] As discussed, the PDU set may be a downlink PDU set or an uplink PDU set. Both the uplink PDU set and the downlink PDU set may include PDU sets with different QoS attributes. Various aspects of the present disclosure relate to providing an architecture at a UE that supports PDU sets with different QoS attributes. In some examples, one or more data radio bearers (DRBs) may be established between the UE and the network node. Additionally, one or more quality of service (QoS) flows may be mapped to each of the one or more DRBs. Each QoS flow in the one or more QoS flows is associated with a PDU set type in a set of PDU set types or a subgroup of PDU set types in a set of PDU set types. The UE may send one or more PDUs associated with one or more PDU sets. Each PDU set may be associated with a sub-QoS flow or a QoS flow.
[0035] Various aspects of the present disclosure relate to indicating the delay and number of lost packets for a set of packets transmitted, wherein each packet in the set of packets is associated with a set of PDUs. In some examples, a wireless device (such as a network node) may receive a latency report that indicates a first latency value associated with an initial uplink packet in a first set of uplink packets associated with a given medium access control (MAC) transport block (TB), a second latency value associated with a final uplink packet in the first set of uplink packets, and the number of lost uplink packets in the first set of uplink packets. For example, the network node may grant an uplink (UL) MAC TB. In response, the UE may transmit packets in the MAC TB. The UE may indicate the delay associated with the first packet and / or the delay associated with the last packet. These packets may be for the absolute first and last packets in the MAC TB, or they may be the first and last packets of a specific flow in the MAC TB. Additionally, the number of lost uplink packets may be across bearers or specific to a flow configured by the network node. The network node may adjust a configuration of the second set of uplink packets based on receiving the latency report.The network node may also send the second set of uplink packets based on the adjusted configuration.
[0036] Certain aspects of the subject matter described in this disclosure can be implemented to achieve one or more of the following potential advantages: In some examples, the described techniques (such as indicating the delay associated with the initial PDCP packet, the delay associated with the final PDCP packet, and the number of lost packets) can enable a network node to reconfigure one or more of the grant size, grant periodicity, or grant timing to reduce latency, packet drop losses, and / or transmission errors.
[0037] Figure 1is a diagram illustrating a network 100 in which various aspects of the present disclosure may be practiced. Network 100 may be a 5G or NR network, or some other wireless network (such as an LTE network). Wireless network 100 may include multiple base stations (BSs) 110 (shown as BSs 110a, 110b, 110c, and 110d) and other network entities. A BS is an entity that communicates with user equipment (UE) and may also be referred to as a base station, NR BS, Node B, gNB, 5G Node B, access point, transmit and receive point (TRP), network node, network entity, etc. A base station may be implemented as a converged base station, a decomposed base station, an integrated access and backhaul (IAB) node, a relay node, a sidelink node, etc. A base station may be implemented in a converged or monolithic base station architecture, or alternatively, in a decomposed base station architecture, and may include one or more of a central unit (CU), a distributed unit (DU), a radio unit (RU), a near real-time (near-RT) RAN intelligent controller (RIC), or a non-real-time (non-RT) RIC.
[0038] Each BS can provide communication coverage for a specific geographical area. In 3GPP, the term "cell" can refer to the coverage area of a BS and / or a BS subsystem serving the coverage area, depending on the context in which the term is used.
[0039] A BS may provide communication coverage for a macro cell, a pico cell, a femto cell, and / or another type of cell. A macro cell may cover a relatively large geographic area (e.g., a radius of several kilometers) and may allow unrestricted access by UEs with service subscriptions. A pico cell may cover a relatively small geographic area and may allow unrestricted access by UEs with service subscriptions. A femto cell may cover a relatively small geographic area (e.g., a home) and may allow restricted access by UEs associated with the femto cell (e.g., UEs in a closed subscriber group (CSG)). A BS for a macro cell may be referred to as a macro BS. A BS for a pico cell may be referred to as a pico BS. A BS for a femto cell may be referred to as a femto BS or a home BS. In Figure 1 In the example shown in FIG, BS 110a may be a macro BS for macrocell 102a, BS 110b may be a pico BS for picocell 102b, and BS 110c may be a femto BS for femtocell 102c. A BS may support one or more (e.g., three) cells. The terms "eNB," "base station," "NR BS," "gNB," "AP," "Node B," "5G NB," "TRP," and "cell" may be used interchangeably.
[0040] In some aspects, the cells need not be stationary, and the geographic area of the cells may move depending on the location of the mobile BS. In some aspects, the BSs may interconnect with each other and / or with one or more other BSs or network nodes (not shown) in the wireless network 100 via various types of backhaul interfaces (e.g., direct physical connections, virtual networks, etc.) using any suitable transport network.
[0041] The wireless network 100 may also include a relay station. A relay station is an entity that can receive data transmissions from an upstream station (e.g., a BS or a UE) and transmit the data transmissions to a downstream station (e.g., a UE or a BS). A relay station may also be a UE that can relay transmissions for other UEs. Figure 1 In the example shown in , a relay station 110d may communicate with a macro BS 110a and a UE 120d to facilitate communication between the BS 110a and the UE 120d. A relay station may also be referred to as a relay BS, a relay base station, a relay, or the like.
[0042] The wireless network 100 may be a heterogeneous network including different types of BSs (e.g., macro BSs, pico BSs, femto BSs, relay BSs, etc.). These different types of BSs may have different transmit power levels, different coverage areas, and different impacts on interference in the wireless network 100. For example, a macro BS may have a high transmit power level (e.g., 5 watts to 40 watts), while a pico BS, a femto BS, and a relay BS may have a lower transmit power level (e.g., 0.1 watt to 2 watts).
[0043] For example, BSs 110 (shown as BS 110a, BS 110b, BS 110c, and BS 110d) and core network 130 may exchange communications via backhaul links 132 (e.g., S1, etc.). Base stations 110 may communicate with each other directly or indirectly (e.g., through core network 130) via other backhaul links (e.g., X2, etc.).
[0044] The core network 130 may be an evolved packet core (EPC), which may include at least one mobility management entity (MME), at least one serving gateway (S-GW), and at least one packet data network (PDN) gateway (P-GW). The MME may be a control node that handles signaling between the UE 120 and the EPC. All user IP packets may be transmitted through the S-GW, which itself may be connected to the P-GW. The P-GW may provide IP address allocation and other functions. The P-GW may be connected to the network operator's IP services. The operator's IP services may include the Internet, the intranet, the IP multimedia subsystem (IMS), and packet switched (PS) streaming services.
[0045] The core network 130 may provide user authentication, access authorization, tracking, IP connectivity, and other access, routing, or mobility functions. One or more of the base stations 110 or access node controllers (ANCs) may interface with the core network 130 via a backhaul link 132 (e.g., S1, S2, etc.) and may perform radio configuration and scheduling for communications with the UE 120. In some configurations, the various functions of each access network entity or base station 110 may be distributed across various network devices (e.g., radio heads and access network controllers) or consolidated into a single network device (e.g., base station 110).
[0046] UEs 120 (e.g., 120a, 120b, 120c) may be dispersed throughout the wireless network 100, and each UE may be stationary or mobile. A UE may also be referred to as an access terminal, terminal, mobile station, subscriber unit, station, etc. A UE may be a cellular phone (e.g., a smartphone), a personal digital assistant (PDA), a wireless modem, a wireless communication device, a handheld device, a laptop computer, a cordless phone, a wireless local loop (WLL) station, a tablet device, a camera, a gaming device, a netbook, a smartbook, an ultrabook, a medical device or equipment, a biometric sensor / device, a wearable device (e.g., a smart watch, smart clothing, smart glasses, a smart wristband, smart jewelry (e.g., a smart ring, a smart bracelet)), an entertainment device (e.g., a music or video device, or a satellite radio), an in-vehicle component or sensor, a smart meter / sensor, industrial manufacturing equipment, a global positioning system device, or any other suitable device configured to communicate via a wireless or wired medium.
[0047] One or more UEs 120 may establish a protocol data unit (PDU) session for a network slice. In some cases, the UE 120 may select a network slice based on an application or subscription service. By having different network slices serve different applications or subscriptions, the UE 120 may improve its resource utilization in the wireless network 100 while also meeting the performance specifications of the respective applications of the UE 120. In some cases, the network slice used by the UE 120 may be managed by an AMF (Automatic Mobile Module) associated with one or both of the base station 110 or the core network 130. Figure 1 In addition, session management of the network slice can be performed by the Access and Mobility Management Function (AMF).
[0048] The UE 120 may include a delay reporting module 140. For simplicity, only one UE 120d is shown as including the delay reporting module 140. Additionally or alternatively, the base station 110 may include a delay reporting module 142. The delay reporting modules 140 and 142 may implement reference Figure 9One or more steps of process 900 are described.
[0049] Some UEs may be considered machine type communication (MTC) or evolved or enhanced machine type communication (eMTC) UEs. For example, MTC and eMTC UEs include robots, drones, remote devices, sensors, meters, monitors, location tags, etc. that can communicate with a base station, another device (e.g., a remote device), or some other entity. A wireless node may provide, for example, a connection to or to a network (e.g., a wide area network such as the Internet or a cellular network) via a wired or wireless communication link. Some UEs may be considered Internet of Things (IoT) devices and / or may be implemented as NB-IoT (narrowband Internet of Things) devices. Some UEs may be considered customer premises equipment (CPE). UE 120 may be included in a housing that houses components of UE 120 (such as a processor component, a memory component, etc.).
[0050] Generally speaking, any number of wireless networks can be deployed in a given geographic area. Each wireless network can support a specific radio access technology (RAT) and can operate on one or more frequencies. RAT can also be referred to as radio technology, air interface, etc. Frequency can also be referred to as carrier, frequency channel, etc. In a given geographic area, each frequency can support a single RAT to avoid interference between wireless networks of different RATs. In some cases, NR or 5G RAT networks can be deployed.
[0051] In some aspects, two or more UEs 120 (e.g., shown as UE 120a and UE 120e) may communicate directly (e.g., without using base station 110 as an intermediary) using one or more sidelink channels. For example, UE 120 may communicate using peer-to-peer (P2P) communication, device-to-device (D2D) communication, vehicle-to-everything (V2X) protocols (e.g., which may include vehicle-to-vehicle (V2V) protocols, vehicle-to-infrastructure (V2I) protocols, etc.), mesh networks, etc. In this case, UE 120 may perform scheduling operations, resource selection operations, and / or other operations described elsewhere herein performed by base station 110. For example, base station 110 may configure UE 120 via downlink control information (DCI), radio resource control (RRC) signaling, medium access control-control element (MAC-CE), or via system information (e.g., system information block (SIB)).
[0052] As indicated above, Figure 1 These are provided as examples only. Other examples may be found in relation to Figure 1 The examples described are different.
[0053] Figure 2 A block diagram shows a design 200 of a base station 110 and a UE 120, which may be Figure 1 One of the base stations in the UE and the UE may be Figure 1 Base station 110 may be equipped with T antennas 234a through 234t, and UE 120 may be equipped with R antennas 252a through 252r, where in general T≧1 and R≧1.
[0054] At the base station 110, the transmit processor 220 may receive data for one or more UEs from a data source 212, select one or more modulation and coding schemes (MCS) for each UE based at least in part on a channel quality indicator (CQI) received from the UE, process (e.g., encode and modulate) the data for each UE based at least in part on the MCS selected for the UE, and provide data symbols for all UEs. Reducing the MCS reduces throughput but increases transmission reliability. The transmit processor 220 may also process system information (e.g., for semi-static resource allocation information (SRPI) and control information (e.g., CQI requests, grants, upper layer signaling, etc.) and provide overhead symbols and control symbols. The transmit processor 220 may also generate reference symbols for reference signals (e.g., cell-specific reference signals (CRS)) and synchronization signals (e.g., primary synchronization signals (PSS) and secondary synchronization signals (SSS)). The transmit (TX) multiple-input multiple-output (MIMO) processor 230 may perform spatial processing (e.g., pre-decoding) on data symbols, control symbols, overhead symbols, and / or reference symbols, where applicable, and may provide T output symbol streams to T modulators (MODs) 232a through 232t. Each modulator 232 may process a corresponding output symbol stream (e.g., for orthogonal frequency division multiplexing (OFDM) or the like) to obtain an output sample stream. Each modulator 232 may further process (e.g., convert to analog, amplify, filter, and up-convert) the output sample stream to obtain a downlink signal. The T downlink signals from modulators 232a through 232t may be transmitted via T antennas 234a through 234t, respectively. According to various aspects described in greater detail below, position coding may be utilized to generate synchronization signals to convey additional information.
[0055] At UE 120, antennas 252a through 252r may receive downlink signals from base station 110 and / or other base stations and may provide received signals to demodulators (DEMODs) 254a through 254r, respectively. Each demodulator 254 may condition (e.g., filter, amplify, downconvert, and digitize) the received signal to obtain input samples. Each demodulator 254 may further process the input samples (e.g., for OFDM, etc.) to obtain received symbols. A MIMO detector 256 may obtain received symbols from all R demodulators 254a through 254r, perform MIMO detection on the received symbols (if applicable), and provide detected symbols. A receive processor 258 may process (e.g., demodulate and decode) the detected symbols, provide decoded data for UE 120 to a data sink 260, and provide decoded control information and system information to a controller / processor 280. The channel processor may determine reference signal received power (RSRP), received signal strength indicator (RSSI), reference signal received quality (RSRQ), channel quality indicator (CQI), etc. In some aspects, one or more components of UE 120 may be included in a housing.
[0056] On the uplink, at UE 120, a transmit processor 264 may receive data from a data source 262 and control information (e.g., for reports including RSRP, RSSI, RSRQ, CQI, etc.) from a controller / processor 280 and process the data and control information. The transmit processor 264 may also generate reference symbols for one or more reference signals. The symbols from the transmit processor 264 may be pre-decoded by a TX MIMO processor 266, if applicable, further processed by modulators 254a through 254r (e.g., for discrete Fourier transform spread OFDM (DFT-s-OFDM), CP-OFDM, etc.), and transmitted to the base station 110. At the base station 110, uplink signals from UE 120 and other UEs may be received by antennas 234, processed by demodulators 254, detected by MIMO detector 236 (if applicable), and further processed by receive processor 238 to obtain decoded data and control information transmitted by UE 120. The receive processor 238 may provide the decoded data to a data sink 239 and may provide the decoded control information to a controller / processor 240. The base station 110 may include a communication unit 244 and communicate with the core network 130 via the communication unit 244. The core network 130 may include a communication unit 294, a controller / processor 290, and a memory 292.
[0057] The controller / processor 240 of the base station 110, the controller / processor 280 of the UE 120, and / or Figure 2 Any other components of the UE 120 may perform one or more techniques associated with supporting PDU aggregation, as described in greater detail elsewhere. For example, the controller / processor 240 of the base station 110, the controller / processor 280 of the UE 120, and / or Figure 2 Any other component of the may perform or direct e.g. Figure 9 1 and / or other processes as described herein. Memory 242 and memory 282 may store data and program codes for base station 110 and UE 120, respectively. Scheduler 246 may schedule UEs for data transmission on the downlink and / or uplink.
[0058] The deployment of a communication system (such as a 5G New Radio (NR) system) can be arranged in a variety of ways with various components or constituent parts. In a 5G NR system or network, a network node, a network entity, a mobility element of the network, a radio access network (RAN) node, a core network node, a network element or network equipment (such as a base station (BS)) or one or more units (or one or more components) that perform base station functionality can be implemented in a converged or decomposed architecture. For example, a BS (such as a Node B (NB), an evolved NB (eNB), an NR BS, a 5G NB, an access point (AP), a transmit and receive point (TRP) or a cell, etc.) can be implemented as a converged base station (also known as a standalone BS or a monolithic BS) or a decomposed base station.
[0059] A converged base station may be configured to utilize a radio protocol stack that is physically or logically integrated within a single RAN node. A decomposed base station may be configured to utilize a protocol stack that is physically or logically distributed between two or more units, such as one or more central or centralized units (CUs), one or more distributed units (DUs), or one or more radio units (RUs). In some aspects, a CU may be implemented within a RAN node, and one or more DUs may be co-located with the CU, or alternatively, may be geographically or virtually distributed across one or more other RAN nodes. A DU may be implemented to communicate with one or more RUs. Each of the CU, DU, and RU may also be implemented as a virtual unit, such as a virtual central unit (VCU), a virtual distributed unit (VDU), or a virtual radio unit (VRU).
[0060] Base station type operation or network design can take into account the aggregated nature of base station functionality. For example, a disaggregated base station can be used in an integrated access backhaul (IAB) network, an open radio access network (O-RAN (a network configuration such as that initiated by the O-RAN Alliance)), or a virtualized radio access network (vRAN, also known as a cloud radio access network (C-RAN)). Decomposition can include distributing functionality across two or more units at various physical locations, as well as virtually distributing functionality of at least one unit, which can enable flexibility in network design. Various units of a disaggregated base station or disaggregated RAN architecture can be configured for wired or wireless communication with at least one other unit.
[0061] In some cases, different types of devices supporting different types of applications and / or services may coexist in a cell. Examples of different types of devices include UE phones, user premises equipment (CPE), vehicles, Internet of Things (IoT) devices, etc. Examples of different types of applications include ultra-reliable low-latency communications (URLLC) applications, massive machine-type communications (mMTC) applications, enhanced mobile broadband (eMBB) applications, and vehicle-to-everything (V2X) applications. In addition, in some cases, a single device may support different applications or services simultaneously.
[0062] Figure 3 A diagram illustrating an example decomposed base station 300 architecture is shown. The decomposed base station 300 architecture may include one or more central units (CUs) 310, which may communicate directly with a core network 320 via a backhaul link, or indirectly with the core network 320 through one or more decomposed base station units, such as a near real-time (near-RT) RAN intelligent controller (RIC) 325 via an E2 link, or a non-real-time (non-RT) RIC 315 associated with a service management and orchestration (SMO) framework 305, or both. The CU 310 may communicate with one or more distributed units (DUs) 330 via corresponding midhaul links, such as the F1 interface. The DU 330 may communicate with one or more radio units (RUs) 340 via corresponding fronthaul links. The RU 340 may communicate with corresponding UEs 120 via one or more radio frequency (RF) access links. In some implementations, a UE 120 may be served simultaneously by multiple RUs 340.
[0063] Each of these units (e.g., CU 310, DU 330, RU 340, and near-RT RIC 325, non-RTRIC 315, and SMO framework 305) may include one or more interfaces, or may be coupled to one or more interfaces configured to receive or transmit signals, data, or information (collectively, signals) via a wired or wireless transmission medium. Each of the units, or an associated processor or controller that provides instructions to the communication interface of these units, may be configured to communicate with one or more of the other units via the transmission medium. For example, these units may include a wired interface that is configured to receive or transmit signals to one or more of the other units via a wired transmission medium. Additionally, these units may include a wireless interface that may include a receiver, transmitter, or transceiver (such as a radio frequency (RF) transceiver) that is configured to receive or transmit signals, or both, to one or more of the other units on a wireless transmission medium.
[0064] In some aspects, the CU 310 may host one or more higher layer control functions. Such control functions may include radio resource control (RRC), packet data convergence protocol (PDCP), service data adaptation protocol (SDAP), etc. Each control function may be implemented using an interface that is configured to communicate signals with other control functions hosted by the CU 310. The CU 310 may be configured to handle user plane functionality (e.g., central unit-user plane (CU-UP)), control plane functionality (e.g., central unit-control plane (CU-CP)), or a combination thereof. In some implementations, the CU 310 may be logically divided into one or more CU-UP units and one or more CU-CP units. When implemented in an O-RAN configuration, the CU-UP unit may communicate bidirectionally with the CU-CP unit via an interface such as an E1 interface. As needed, the CU 310 may be implemented to communicate with the DU 330 for network control and signaling.
[0065] The DU 330 may correspond to a logical unit that includes one or more base station functions for controlling the operation of one or more RUs 340. In some aspects, the DU 330 may host one or more of a radio link control (RLC) layer, a medium access control (MAC) layer, and one or more higher physical (PHY) layers (such as modules for forward error correction (FEC) encoding and decoding, scrambling, modulation and demodulation, etc.), depending at least in part on a functional partitioning (such as that defined by the Third Generation Partnership Project (3GPP)). In some aspects, the DU 330 may also host one or more lower PHY layers. Each layer (or module) may be implemented using an interface configured to communicate signals with other layers (and modules) hosted by the DU 330 or with control functions hosted by the CU 310.
[0066] Lower layer functionality may be implemented by one or more RUs 340. In some deployments, a RU 340 controlled by a DU 330 may correspond to a logical node that hosts RF processing functionality or low PHY layer functionality (such as performing Fast Fourier Transform (FFT), Inverse FFT (iFFT), digital beamforming, Physical Random Access Channel (PRACH) extraction and filtering, etc.), or both, based at least in part on a functional split (such as a lower layer functional split). In such an architecture, the RU 340 may be implemented to handle over-the-air (OTA) communications with one or more UEs 120. In some implementations, real-time and non-real-time aspects of control and user plane communications with the RU 340 may be controlled by the corresponding DU 330. In some scenarios, this configuration may enable the implementation of the DU 330 and CU 310 in a cloud-based RAN architecture (such as a vRAN architecture).
[0067] The SMO framework 305 can be configured to support RAN deployment and provisioning of both non-virtualized and virtualized network elements. For non-virtualized network elements, the SMO framework 305 can be configured to support the deployment of dedicated physical resources for RAN coverage requirements, which can be managed via an operations and maintenance interface (such as the O1 interface). For virtualized network elements, the SMO framework 305 can be configured to interact with a cloud computing platform (such as Open Cloud (O-cloud) 390) to perform network element lifecycle management (such as instantiating virtualized network elements) via a cloud computing platform interface (such as the O2 interface). Such virtualized network elements may include, but are not limited to, CU 310, DU 330, RU 340, and near-RT RIC 325. In some implementations, the SMO framework 305 can communicate with hardware aspects of the 4G RAN, such as Open eNB (O-eNB) 311, via the O1 interface. Additionally, in some implementations, the SMO framework 305 can communicate directly with one or more RUs 340 via the O1 interface. The SMO framework 305 may also include a non-RT RIC 315 configured to support the functionality of the SMO framework 305 .
[0068] The non-RT RIC 315 can be configured to include logic functions that enable non-real-time control and optimization of RAN elements and resources, artificial intelligence / machine learning (AI / ML) workflows including model training and updating, or policy-based guidance of applications / features in the near-RT RIC 325. The non-RT RIC 315 can be coupled to or in communication with the near-RT RIC 325 (such as via an A1 interface). The near-RT RIC 325 can be configured to include logic functions that enable near-real-time control and optimization of RAN elements and resources via data collection and actions over an interface (such as via an E2 interface) that connects one or more CUs 310, one or more DUs 330, or both, and the O-eNB 311 with the near-RT RIC 325.
[0069] In some implementations, the non-RT RIC 315 can receive parameters or external enrichment information from an external server to generate an AI / ML model to be deployed in the near-RT RIC 325. Such information can be utilized by the near-RT RIC 325 and can be received from non-network data sources or from network functions at the SMO framework 305 or the non-RT RIC 315. In some examples, the non-RT RIC 315 or the near-RT RIC 325 can be configured to tune RAN behavior or performance. For example, the non-RT RIC 315 can monitor long-term trends and patterns in performance and employ AI / ML models to perform corrective actions through the SMO framework 305 (such as via reconfiguration of O1) or via the creation of RAN management policies (such as A1 policies).
[0070] The communication protocol stack may be implemented by a device operating in a wireless communication system such as a 5G system, a 6G system, or another type of wireless communication system. The communication protocol stack includes a radio resource control (RRC) layer, a packet data convergence protocol (PDCP) layer, a radio link control (RLC) layer, a medium access control (MAC) layer, and a physical (PHY) layer. In various examples, these layers of the protocol stack may be implemented as separate software modules, as part of a processor or ASIC, as part of non-co-located devices connected by a communication link, or various combinations thereof.
[0071] As discussed, a protocol data unit (PDU) set may be specified for wireless services such as extended reality (XR) services. A PDU set is a collection of PDUs that can be delivered to a receiver as an integrated unit. For example, a PDU set may be associated with a video frame or a slice within a video frame. In some examples, all PDUs in the same PDU set share common quality of service (QoS) attributes, such as, for example, a PDU set delay budget (PSDB) or a PDU set error rate (PSER).
[0072] In some examples, PDU sets may have different decoding criteria (e.g., PDU set content criteria (PSCC)), which may depend on the specific implementation of a given application. For example, some PDU sets may be associated with an "all or nothing" decoding criterion, where if a receiver fails to decode a PDU in the PDU set, the PDU set may be out of date. As another example, some other PDU sets may be associated with a "good until first loss" decoding criterion, where all received PDUs are valid until the first loss occurs. In yet another example, some other PDU sets may be associated with an application layer forward error correction (AL-FEC) decoding criterion, where the PDUs in the PDU set are encoded using AL-FEC. In some cases, based on the FEC redundancy ratio, only a subset of the PDUs in the PDU set may be used to decode the PDU set.
[0073] In some examples, one or more PDUs may be discarded by a user equipment (UE) or a radio access network (RAN). In some such examples, the PDU may be discarded when the delay budget has been exhausted. Alternatively, the PDU may be discarded if an associated layer 2 timer has expired. The layer 2 timer may be a PDCP discard timer, an RLC reassembly timer, an RLC discard timer, or a PDCP reordering timer. In some other examples, the PDU may be discarded based on a decoding criterion associated with the PDU set being met (e.g., a content criterion) or if the decoding criterion is no longer met. In some such examples, if the receiver fails to decode a PDU in the PDU set, the decoding criterion may no longer be met, and the decoding criterion is: an all-or-nothing decoding criterion, or a decoding criterion that is valid until the first loss occurs. In other such examples, if one or more PDUs in the PDU set have been successfully decoded, the decoding criterion may have been met such that additional PDUs in the PDU set are no longer required.
[0074] In some examples, the PDU set may be a downlink PDU set or an uplink PDU set. Various aspects of the present disclosure relate to supporting one or more uplink PDU sets at a UE. The uplink PDU set may share one or more features with the downlink PDU set. In some examples, a packet filter for downlink PDU set marking may be used for uplink packet filtering. For example, uplink packet filtering may match a real-time transport protocol (RTP) or secure RTP (SRTP) header and payload. Additionally, each uplink PDU set may be associated with one or more QoS attributes, such as one or both of PSDB or PSER. PSDB may be an upper bound on the delay between the time when the last PDU in the uplink PDU set is received at the SDAP service access point of the UE and the time when the uplink PDU set is successfully received at the receiver (e.g., a network node). PSER may be an upper bound on the ratio between the number of uplink PDU sets that were not successfully decoded (e.g., received) and the total number of uplink PDU sets transmitted within a measurement window.
[0075] In some examples, an uplink PDU set may include one or more information elements. The one or more information elements may include a PDU set identifier (e.g., a sequence number), an indication of the boundaries of the uplink PDU set (e.g., the start and end of the PDU set), or a service parameter (e.g., periodicity). Additionally, the one or more information elements may include one or more optional elements, such as the PDU set size expressed in bytes or the number of PDUs in the PDU set, the importance of the PDU set, or whether in-sequence delivery of the PDUs in the PDU set is specified.
[0076] In some examples, PDU set importance is associated with each PDU set rather than a QoS flow. That is, each PDU set can be assigned its own importance level. However, regardless of the importance level, each PDU set with the same QoS Flow ID (QFI) can be associated with the same QoS flow. Additionally, in some examples, the PSDB and PSER can be configured for a QoS flow. The PSDB can be common to all PDU sets associated with a QoS flow. In contrast, the PSER can be measured based on a set of PDU sets transmitted within a time window. Therefore, if a UE selectively discards PDU sets, the PSER of a PDU set with high importance can be lower than that of other PDU sets while still meeting the PSER requirement for the overall error rate. Therefore, the importance of a PDU set can be independent of the PSDB associated with that PDU set. Additionally, the importance of a PDU set can be related to the differentiated reliability of decoding the PDU sets (e.g., error / loss rate). In some examples, PDU sets associated with high importance can be more protected than other PDU sets. For example, high-importance PDU sets can be selectively replicated. Additionally or alternatively, a high importance PDU set may be prioritized for scheduling during uplink congestion to reduce the likelihood that PDUs in the high importance PDU set are discarded due to a delay greater than the PSDB.
[0077] Various aspects of this disclosure discuss sub-QoS flows and QoS flows. A sub-QoS flow can be associated with PDUs of the same importance level or associated with the same PDU set type. A QoS flow can be a regular QoS flow. Each QoS flow can be associated with a set of sub-QoS flows.
[0078] Figure 4A An example 400 of an architecture for processing a PDU set at a UE 120 in accordance with various aspects of the present disclosure is illustrated. Figure 4A In example 400, two PDU set types (PDU set type 1 and PDU set type 2) may be associated with the same QoS flow (QoS flow 1). Aspects of the present disclosure are not limited to two PDU set types. Additional PDU set types may be associated with a QoS flow. The QoS flow may be mapped to a data radio bearer (DRB) (DRB 1), and the DRB may be associated with a radio link control (RLC) entity (RLC 1). Additionally, the RLC entity may be associated with a logical channel (LCH) (LCH 1). The RLC entity may also be referred to as an RLC layer.
[0079] Figure 4B An example 410 of an architecture for processing a PDU set at a UE 120 in accordance with various aspects of the present disclosure is illustrated. Figure 4BIn example 410, two PDU set types (PDU set type 1 and PDU set type 2) may be associated with the same QoS flow (QoS flow 1). The QoS flow may be mapped to one DRB (DRB 1), and the DRB may be associated with two radio link control (RLC) entities (RLC 1 and RLC 2). Additionally, each RLC entity may be associated with an LCH (LCH 1 and LCH 2). Aspects of the present disclosure are not limited to two RLC entities. Additional RLC entities may be associated with a DRB.
[0080] Figure 4C An example 420 of an architecture for processing a PDU set at a UE 120 in accordance with various aspects of the present disclosure is illustrated. Figure 4C In example 420, two PDU set types (PDU set type 1 and PDU set type 2) may be associated with the same QoS flow (QoS flow 1). The QoS flow may be mapped to two different DRBs (DRB 1 and DRB 2). Aspects of the present disclosure are not limited to two DRBs. Additional DRB entities may be associated with a QoS flow. Each DRB may be associated with a different radio link control (RLC) entity (RLC 1 and RLC 2). Additionally, each RLC entity may be associated with an LCH (LCH 1 and LCH 2).
[0081] Figure 4D An example 430 of an architecture for processing a PDU set at a UE 120 in accordance with various aspects of the present disclosure is illustrated. Figure 4D In example 430, each PDU set type (PDU set type 1 and PDU set type 2) can be associated with a different QoS flow (QoS flow 1 and QoS flow 2). The QoS flows can be mapped to the same DRB (DRB 1). The DRB can be associated with a single radio link control (RLC) entity (RLC 1). Additionally, the RLC entity can be associated with an LCH (LCH 1).
[0082] Figure 4E An example 440 of an architecture for processing a PDU set at a UE 120 in accordance with various aspects of the present disclosure is illustrated. Figure 4E In example 440, each PDU set type (PDU set type 1 and PDU set type 2) can be associated with a different QoS flow (QoS flow 1 and QoS flow 2). The QoS flows can be mapped to the same DRB (DRB 1). The DRB can be associated with two radio link control (RLC) entities (RLC 1 and RLC 2). Additionally, each RLC entity can be associated with an LCH (LCH 1 and LCH 2).
[0083] Figure 4FAn example 450 of a general architecture for processing PDU aggregation at UE 120 is illustrated. Figure 4F In example 450, each PDU set type (PDU set type 1 and PDU set type 2) can be associated with a different QoS flow (QoS flow 1 and QoS flow 2). The QoS flows can be mapped to different DRBs (DRB 1 and DRB 2). Each DRB can be associated with a different radio link control (RLC) entity (RLC 1 and RLC 2). Additionally, each RLC entity can be associated with an LCH (LCH 1 and LCH 2).
[0084] Figure 4A 、 Figure 4B 、 Figure 4C 、 Figure 4D and Figure 4E Examples of different architectures for processing different PDU sets at a UE according to various aspects of the present disclosure are illustrated. If multiple PDU set types are multiplexed into a common QoS flow, the multiple PDU set types may share the same QoS attributes, such as the same PSDB, PSER, Prioritized Bit Rate (PBR), Bucket Size Duration (BSD), and Maximum Data Burst Size (MDBV). If multiple types of PDU set types are multiplexed into different QoS flows (see Figure 4D and Figure 4E ), each QoS flow can be associated with its own QoS attributes, even if each PDU set type is associated with the same service flow.
[0085] Different enhancements can be specified for different architectures. For example, see Figure 4A and Figure 4B The described architecture examples 400 and 410 may use the PDU aggregate type field in the SDAP header associated with the PDU. In some examples, when a PDU arrives at an SDAP service access point (SAP), the UE may identify the sub-QoS flow or QoS flow associated with the PDU based on the SDAP header.
[0086] Figure 5 is a block diagram illustrating an example of a Service Data Adaptation Protocol (SDAP) packet 500 according to various aspects of the present disclosure. Figure 5As shown in the example of , the SDAP packet 500 may include a PDU set type field 502 indicating a PDU set type associated with the PDU. In some examples, if the PDU set type is included with the data packet, the UE may include the PDU set type in the PDU set type field 502 of the SDAP packet 500 associated with the PDU. Additionally or alternatively, a PDU set type indicator (PSTI) field 504 may be included in the header to indicate the presence of a value indicating the PDU set type in the PDU set type field 502. Alternatively, if the data packet does not include the PDU set type, the UE may include a QoS flow ID (QFI) in the QFI field 506 of the SDAP packet 500. The SDAP packet 500 may also include a data / control (D / C) bit 510. The D / C bit 510 may indicate whether the PDU is a data PDU or a control PDU. The SDAP packet 500 may also include one or more data fields 512.
[0087] If reference Figure 4A and Figure 4D As shown in the examples 400 and 430, the DRBs may be served by a common RLC entity and a common LCH. Figure 4A In the example 400 described, different sub-QoS flows can be served by a common RLC entity and a common LCH. Figure 4D In the example 430 described, different QoS flows may be served by a common RLC entity and a common LCH. Although different sub-QoS flows or different QoS flows may be served by a common RLC entity and a common LCH, PDUs may be processed differently based on one or more parameters associated with the corresponding PDU type (e.g., PDU set). Figure 4A and Figure 4D In the examples 400 and 430 described above, each PDU may be associated with a PDU type. The UE may identify the PDU type based on the PDU set type or the QFI included in the SDAP header of the PDU.
[0088] There may be multiple possible configurations between PDU sets, QoS flows, DRB entities, and logical channels. When the UE receives a grant for uplink traffic from the network node, the UE may prepare one or more PDUs belonging to different PDU sets as part of a MAC transport block based on the Logical Channel Prioritization (LCP) and / or other rules associated with a given logical channel.
[0089] Figure 6A6 is a block diagram illustrating an example of an uplink (UL) MAC PDU 600. The UL MAC PDU may include one or more MAC sub-PDUs. Each MAC sub-PDU includes one of the following: a MAC sub-header only (including padding); a MAC sub-header and a MAC service data unit (SDU); a MAC sub-header and a MAC-CE; or a MAC sub-header and padding. The MAC SDU may have a variable size. Each MAC sub-header corresponds to a MAC SDU, a MAC-CE, or padding.
[0090] In some examples, one or more conditions associated with a PDU set, such as a latency condition or a block error rate (BLER) condition, may not be met. In such examples, the application layer may know that the one or more conditions are not met. However, in such examples, the network node (e.g., radio access network (RAN)) may not be aware that the one or more conditions are not met. Specifically, knowledge of the PDU set may be limited to the application, such that the radio network controller (RNC), MAC, L1, network node and / or UE may only know the PDCP sequence number, RNC sequence number and / or other information associated with the PDU set. Therefore, the radio entity (e.g., network node or UE) may not have information indicating the start and end of a video frame. Therefore, during uplink transmission, it may not be obvious to the radio entity whether a PDU is lost at the UE uplink waiting to be transmitted at the PDCP level. For example, the radio entity may not know that an SDU that has not been constructed as a PDCP PDU is discarded based on a timer discard. The discarded SDU may only be known at the application layer. In one example, a modem at a UE may receive 1000 packets from an application layer and may discard 100 packets based on a timer drop. The UE may then send 900 packets in response to receiving an uplink grant. However, the loss of 100 packets may only be known at the application layer because, from a radio perspective, the sequence number (SN) space may be zero to 899, and the network node may determine that 900 packets were received without error. It may be desirable to know whether some packets were lost and / or the delay associated with one or more packets to satisfy a QoS flow. In some examples, each PDU set may be associated with a video frame. In such examples, satisfying the QoS flow may enable video or other multimedia to be displayed correctly (e.g., smoothly).
[0091] Additionally or alternatively, in some examples, the PDU may experience a delay between its arrival time at the UE or transmitting node and its over-the-air (OTA) transmission. For example, in a given MAC transport block (TB), a network node may receive a sequence of ten PDCP PDUs, four of which are associated with a first PDU set and another four of which are associated with a second PDU set. In this example, at the RAN level, the network node may not know the delay (e.g., latency) associated with the initial packet in the MAC TB (e.g., the first PDCP PDU) or the delay associated with the final packet in the MAC TB (e.g., the last PDCP PDU). Each QoS flow may be associated with a delay condition for each PDU set. However, the RAN may only use delay conditions (e.g., delay requirements) for downlink scheduling. The RAN at the network node may not use delay conditions for uplink scheduling. The delay associated with the initial PDCP PDU may be referred to as the first sequence number (SN) delay, and the delay associated with the final PDCP PDU may be referred to as the last SN delay.
[0092] Figure 6B 6 is a block diagram illustrating an example of a MAC TB 650. The MAC TB 650 is associated with the transmission of eight packets every 80 milliseconds (ms). Figure 6B In the example of FIG, every 10 ms, a PDU is received at the PDCP layer of a transmitter (e.g., a UE). In this example, four PDCP PDUs are associated with a first PDU set, and another four PDCP PDUs are associated with a second PDU set. For ease of explanation, Figure 6B The SDAP and RLC layers are not shown in the example. Figure 6B The MAC header is omitted in the example. Figure 6BAs shown in the example of , a grant may be received at 80ms. A MAC TB 650 may be sent to the network node in response to receiving the grant. In this example, the First SN Delay associated with the first MAC SDU 652 may be 80ms, and the Last SN Delay associated with the last MAC SDU 654 may be 0ms, and some PDUs may be lost due to timer discards. In this example, the average latency is 40ms. However, the network node does not know the First SN Delay and the Last SN Delay. If the network node knew the First SN Delay and the Last SN Delay, the network node could have adjusted the uplink grant to reduce the average latency. For example, instead of granting all eight PDCP PDUs, the network could grant two packets every 20ms, such that the first packet would have a latency of 10ms and the second packet would have no latency, such that the average latency would be 10ms. As another example, the network node could adjust the periodicity of the grants so that grants are sent every 40ms instead of every 80ms. In this example, the average latency could be reduced to 20ms.
[0093] As another example, the MAC TB sends eight packets, four PDCP PDUs are associated with a first PDU set, and another four PDCP PDUs are associated with a second PDU set. In this example, the eight packets associated with the first PDU set and the second PDU set arrive at the PDCP layer of the transmitter (e.g., UE) at the same time. In this example, the grant may arrive every 40ms, so that the initial PDU experiences a 40ms delay, the final PDU experiences a 40ms delay, and no packets are lost due to timer drops. In this example, the average delay is 40ms. Similar to the previous example, the network node does not know the first SN delay and the last SN delay. If the network node knows the first SN delay and the last SN delay, the network node may have adjusted the uplink grant to reduce the average delay. As an example, the network node can adjust the offset of the delay by adjusting the timing of the grant. For example, the network node may send the grant 30ms in advance to reduce the average delay to 10ms.
[0094] Various aspects of the present disclosure relate to sending a latency report that includes a first SN latency, a last SN latency, and the number of lost PDCP SDUs. The first SN latency, the last SN latency, and the number of lost PDCP SDUs may improve the scheduling mechanism at a network node. In some examples, the latency report may be sent via a control packet (such as a PDCP control PDU, an RLC control PDU, or a MAC-CE). In some implementations, the network node receives the latency report and adjusts one or more of the grant size, the periodicity of the MACTB, or the timing of the grant. For example, adjusting the grant size may adjust the size of the MAC TB to accommodate more PDUs, thereby reducing the number of lost packets and / or reducing the average latency. As another example, adjusting the periodicity of the grant size may reduce the size of the MAC TB while providing the same effective OTA data rate and reducing the average latency. As previously described, in one example, the grant may be sent every 40ms instead of every 80ms. As another example, adjusting the timing of the grant may reduce the average latency. For example, grants may be sent at times t+30ms, t+70ms, and t+110ms, while data may be received at the PDCP layer at times t, t+40ms, and t+80ms, resulting in an average latency of 30ms. In this example, if the timing of the grants is reduced by 20ms, the latency can be reduced so that grants are received at times t+10ms, t+50ms, and t+90ms. In such an example, the average latency can be reduced from 30ms to 10ms.
[0095] In some examples, the periodicity of a latency report (e.g., a PDCP latency report) may be configured via an RRC message, QoS configuration, or other control signaling. The latency report sent periodically may be associated with a time period such as a previous time period (e.g., the previous 100 ms) or a time period since the previous latency report was sent. The time period may be configured by the network node. In such examples, the latency report may include the average first SN latency associated with the time period, the average last SN latency associated with the time period, and the packet loss associated with the time period. The latency report may be sent periodically via a control packet, a PDCP layer (e.g., a PDCP control PDU), a MAC layer (e.g., a MAC-CE), an RLC layer (e.g., an RLC control PDU), or another mechanism (such as an SDAP control PDU or an RRC message). Measurement reports, latency reports, or UE assistance information (UAI) are examples of RRC messages.
[0096] In some other examples, a latency report may be sent on demand in response to a request. The request for an on-demand latency report may be received via a PDCP, RLC, or MAC mechanism. The on-demand latency report may include the current packet loss, first SN latency, and last SN latency in a given MAC TB.
[0097] Figure 7A is a block diagram illustrating an example of a PDCP control PDU 700 associated with a latency report according to various aspects of the present disclosure. As discussed, the aspects of the present disclosure are not limited to transmitting latency reports via the PDCP control PDU 700, and other types of messages (such as RLC control PDUs or MAC-CEs) may be used to transmit latency reports. Figure 7A In an example, the header may include a D / C bit, one or more PDU type field bits indicating PDU characteristics (such as periodic or on-demand), an R1 bit indicating the presence of PDU loss, an R2 bit indicating the presence of first SN delay, an R3 bit indicating the presence of last SN delay, and an R4 bit indicating the presence of average delay. The PDCP control PDU 700 may also indicate PDU loss, first SN delay, last SN delay, and average SN delay. One or more additional bits may be defined in the PDCP control PDU 700 to indicate other parameters, such as PDU set-specific parameters.
[0098] Figure 7B is a block diagram illustrating an example of an RLC control PDU 720 associated with a delay report according to various aspects of the present disclosure. Figure 7B In the example of FIG, the header may include a D / C bit, one or more control PDU type (CPT) field bits indicating the type of the RLC control PDU, an R1 bit indicating the presence of a PDU loss, an R2 bit indicating the presence of a first SN delay, an R3 bit indicating the presence of a last SN delay, and an R4 bit indicating the presence of an average delay. The PDCP control PDU 700 may also indicate PDU loss, first SN delay, last SN delay, and average SN delay. One or more additional bits may be defined in the RLC control PDU 720 to indicate other parameters.
[0099] Figure 7C is a block diagram illustrating an example of a MAC-CE 750 associated with latency reporting according to various aspects of the present disclosure. Figure 7C In the example of , the MAC-CE may indicate PDU loss, first SN delay, last SN delay, and average SN delay. One or more additional bits may be defined in the RLC control PDU 720 to indicate other parameters. Additionally, the subheader may include a bit or bits associated with a logical channel identifier (LCID), length (L), format (F), or reserved (R).
[0100] In addition to or in lieu of packet loss, a latency report may indicate various values associated with the First SN Latency and the Last SN Latency. In some examples, the latency report may indicate the First SN Latency of the first PDU and the Last SN Latency of the last PDU within a MAC TB, regardless of the associated radio bearer or logical channel. In some other examples, the latency report may indicate the First SN Latency of the first PDU and the Last SN Latency of the last PDU within a MAC TB for a given FLOW. In some other examples, the latency report may indicate the First SN Latency of the first PDU and the Last SN Latency of the last PDU within a MAC TB for a given PDU set priority or PDU set type. In some other examples, the latency report may indicate the average First SN Latency of the first PDU and the average Last SN Latency of the last PDU within a MAC TB. The average First SN Latency and the average Last SN Latency may be from a previously reported time. In some other examples, the latency report may indicate the First SN Latency of the first PDU and the Last SN Latency of the last PDU within a MAC TB, where the First SN Latency and the Last SN Latency are averaged over a specific time period.
[0101] In some examples, flow-specific latency reporting can be configured for a given QoS flow, or for all QoS flows associated with a network node at the bearer level. In some examples, a QoS Flow ID (QFI) in a latency report (e.g., a PDCP control PDU) indicates that the latency report is a QFI-specific report. As an example, the QFI can be included in the header of the PDCP control PDU. In such examples, the UE can include the QFI to enable the network node or UE to reconfigure a specific QFI to a different radio bearer or a different logical channel within a DRB via an RRC procedure, a Reflected QoS (RQoS) procedure, or another signaling mechanism.
[0102] In some examples, the network node can configure latency reporting for a specific radio bearer, a specific logical channel, a specific flow, or a specific PDU set type. In some other examples, the network node can configure latency reporting for a specific leg in dual connectivity to understand the latency between the primary cell group and / or the secondary cell group. Additionally or alternatively, the latency reporting for a specific leg can be used to change the mapping configuration from radio bearer to carrier group, or to enable / disable PDCP duplication across RLC legs.
[0103] In some examples, the network node may use the latency report to adjust radio resource management (RRM) aspects in terms of grant management, periodicity, switching from configured grant to dynamic grant, or switching from dynamic grant to configured grant. Additionally or alternatively, based on receiving the latency report, the network node may adjust one or more logical channel (LC) attributes at the RRM in terms of grant management, for example, the network node may adjust the periodicity of the grant, switch between configured grant (CG) and dynamic grant (DG) or vice versa, and / or change the LC configuration, such as logical channel priority (LCP), packet size and / or other attributes at the MAC and PHY levels. Additionally or alternatively, based on the latency report, the network node may adjust one or more network configurations, MAC layer configurations, or PHY layer configurations.
[0104] In some examples, based on receiving a latency report, the network node may dynamically enable / disable various component carriers to meet QoS criteria. In some other examples, based on receiving a latency report, the network node may use the latency report to remap flows to radio bearer mappings using a non-access stratum or access stratum resource quality objective (RQOS) mechanism and a mapping procedure based on RRC level reconfiguration. In some examples, based on receiving a latency report, the network node may use the latency report to adapt RAN resources for on-demand PDU sessions or update UE routing policy (URSP) rules for a slice to improve user experience in terms of PSDB and / or PSER. Additionally or alternatively, based on receiving a latency report, the network node may indicate QoS characteristics to a session management function (SMF) so that the SMF may review and / or reconfigure one or more QoS characteristics. For example, the SMF may adjust the codec rate. That is, the latency report may be used for RAN-assisted codec adaptation. In some examples, based on receiving a latency report, the network node may update URSP rules for a given slice to meet QoS requirements. In some other examples, based on receiving a latency report, the network node may move entirely to a different slice to meet QoS requirements. In some other examples, based on receiving a latency report, the network node may change.
[0105] Figure 8 is a block diagram illustrating an example wireless communication device 800 that supports receiving a PDU group associated with one or more PDU sets. The wireless communication device 800 may be as described with reference to Figure 1 and Figure 2 The base station 110, as shown in FIG. Figure 3The wireless communication device 800 may include a receiver 810, a communication manager 815, a latency reporting component 830, a granting component 840, and a transmitter 820 that can communicate with each other (e.g., via one or more buses). In some examples, the wireless communication device 800 is configured to perform operations, including the following reference Figure 9 The operations of process 900 are described.
[0106] In some examples, the wireless communication device 800 may include a chip, a system on a chip (SOC), a chipset, a package, or a device that includes at least one processor and at least one modem (e.g., a 5G modem or other cellular modem). In some examples, the communication manager 815 or its subcomponents may be separate and distinct components. In some examples, at least some components of the communication manager 815 are at least partially implemented as software stored in a memory. For example, portions of one or more of these components of the communication manager 815 may be implemented as non-transitory code that can be executed by a processor to perform the functions or operations of the corresponding component.
[0107] The receiver 810 may receive one or more reference signals (e.g., a periodically configured channel state information reference signal (CSI-RS), an aperiodically configured CSI-RS, or a multi-beam specific reference signal), synchronization signals (e.g., synchronization signal blocks (SSBs)), control information, or data information (such as in the form of packets) from one or more other wireless communication devices via various channels including a control channel (e.g., a physical uplink control channel (PUCCH) or a physical sidelink control channel (PSCCH)) and a data channel (e.g., a physical uplink shared channel (PUSCH) or a physical sidelink shared channel (PSSCH)). The other wireless communication devices may include, but are not limited to, reference signals. Figure 1 、 Figure 2 and Figure 3 The UE 120.
[0108] The received information may be passed to other components of the wireless communication device 800. The receiver 810 may be a reference Figure 2 Receiver 810 may include an example of various aspects of the receive processor 238. The receiver 810 may include a signal coupled to or otherwise utilizing a set of antennas (eg, the set of antennas may be a reference signal). Figure 2 A set of radio frequency (RF) chains (examples of various aspects of the antenna 234) are provided.
[0109] The transmitter 820 may transmit signals generated by the communication manager 815 or other components of the wireless communication device 800. In some examples, the transmitter 820 may be co-located with the receiver 810 in a transceiver module. The transmitter 820 may be a reference Figure 2 Examples of aspects of the transmit processor 220 are described. The transmitter 820 can be coupled to or otherwise utilize a set of antennas (e.g., which can be examples of aspects of antenna 234), which can be antenna elements shared with the receiver 810. In some examples, the transmitter 820 is configured to transmit control information in a physical downlink control channel (PDCCH) or PSCCH and to transmit data in a physical downlink shared channel (PDSCH) or PSSCH.
[0110] The communication manager 815 may be a reference Figure 2 Examples of various aspects of the controller / processor 240 described herein. The communication manager 815 includes a latency reporting component 830 and a granting component 840. In some examples, working in conjunction with the receiver 810, the latency reporting component 830 receives a latency report from the second wireless communication device, the latency report indicating a first latency value associated with a first uplink packet in a first set of uplink packets associated with a MAC TB, a second latency value associated with a second uplink packet in the first set of uplink packets, and a number of uplink packets lost in the first set of uplink packets. Additionally, working in conjunction with the transmitter 820, the granting component 840 adjusts the configuration of the second set of uplink packets based on receiving the latency report. In addition, the transmitter 820 may send the second set of uplink packets based on the configuration adjusted by the granting component 840.
[0111] Figure 9 9 is a flow chart illustrating an example process 900 performed by a network node according to some aspects of the present disclosure. Example process 900 is an example of receiving a latency report. Figure 9 As shown, process 900 begins at block 902 by receiving a latency report from a second wireless communication device, the latency report indicating a first latency value associated with a first uplink packet in a first set of uplink packets associated with a MAC TB, a second latency value associated with a second uplink packet in the first set of uplink packets, and a number of lost uplink packets in the first set of uplink packets. At block 904, process 900 adjusts a configuration of a second set of uplink packets based on receiving the latency report. At block 906, process 900 transmits the second set of uplink packets based on the adjusted configuration.
[0112] Specific implementation examples are described in the following numbered clauses:
[0113] Clause 1. A method for wireless communication by a first wireless communication device, the method comprising: receiving a latency report from a second wireless communication device, the latency report indicating a first latency value associated with a first uplink packet in a first set of uplink packets associated with a medium access control (MAC) transport block (TB), a second latency value associated with a second uplink packet in the first set of uplink packets, and a number of lost uplink packets in the first set of uplink packets; adjusting a configuration of a second set of uplink packets based on receiving the latency report; and sending the second set of uplink packets based on the adjusted configuration.
[0114] Clause 2. The method of clause 1, wherein the first wireless communication device is a network node and the second wireless communication device is a user equipment (UE).
[0115] Clause 3. The method according to clause 2, further comprising: sending a message indicating a latency report configuration, wherein: the latency report is received based on sending the message.
[0116] Clause 4. The method of clause 3, wherein: the latency reporting configuration indicates a periodicity of the latency reporting; and the latency reporting configuration is included in a radio resource control (RRC) message or a quality of service (QoS) configuration message.
[0117] Clause 5. A method according to clause 4, wherein: the first delay value is a first average delay associated with a group of initial uplink packets in a previous time period; and the second delay value is a second average delay associated with a group of last uplink packets in the previous time period.
[0118] Clause 6. The method of any one of clauses 3, wherein the latency reporting configuration is an on-demand request for the latency reporting.
[0119] Clause 7. A method according to any one of clauses 2 to 6, wherein adjusting the configuration of the second set of uplink packets includes: adjusting one or more grant sizes of the grant sizes of the second set of uplink packets; adjusting the periodicity of the second set of uplink packets; adjusting the timing of the second set of uplink packets; adjusting the grant associated with the second set of uplink packets from a configured grant to a dynamic grant; or adjusting the logical channel configuration.
[0120] Clause 8. The method according to any one of clauses 2 to 6, further comprising: sending a message requesting an update of QoS characteristics to a session management function (SMF) based on receiving the delay report.
[0121] Clause 9. A method according to any one of clauses 2 to 8, the method further comprising: based on receiving the latency report: adjusting the QoS codec, dynamically enabling and / or disabling one or more component carriers, adjusting radio bearer mapping, adapting radio access network (RAN) resources, enabling or disabling packet data convergence protocol (PDCP) duplication, adjusting carrier group mapping, moving quality of service (QoS) flows to different slices, updating a UE routing policy (URSP), and / or updating the URSP for one slice in a group of slices.
[0122] Clause 10. A method according to any one of clauses 1 to 9, wherein the latency report is received in a packet data convergence protocol (PDCP) control protocol data unit (PDU), a radio link control (RLC) PDU, a radio resource configuration (RRC) message, a service data adaptation protocol (SDAP) control PDU, or a medium access control (MAC) control element (CE) (MAC-CE).
[0123] Clause 11. A method according to any one of clauses 1 to 10, wherein the latency report is associated with: the QoS flow or a group of QoS flows at the bearer level, a specific radio bearer, a specific logical channel and / or a set of protocol data units (PDU) types.
[0124] Clause 12. The method of any one of clauses 1 to 11, wherein the latency report includes a QoS Flow Identifier (QFI).
[0125] Clause 13. The method of any one of clauses 1 to 12, wherein the latency report comprises one or more bit-indicated parameters associated with the first set of packets.
[0126] Clause 14. The method of any one of clauses 1 or 10 to 13, wherein the first wireless communication device is a user equipment (UE) and the second wireless communication device is a network node.
[0127] Clause 15. The method of clause 14, wherein adjusting the configuration of the second set of uplink packets comprises adjusting the timing of the second set of uplink packets.
[0128] Clause 16. The method of any of clauses 1 to 15, wherein the first set of packets and the second set of packets are protocol data unit (PDU) packets or belong to a specific PDU set.
[0129] Clause 17. A method according to any one of clauses 1 to 16, wherein: the first uplink packet is an initial packet in the MAC TB, and the second uplink packet is a final packet in the MAC TB or a QoS flow among multiple quality of service (QoS) flows associated with the MAC TB.
[0130] Clause 18. A device comprising: at least one processor; at least one memory coupled to the at least one processor; and instructions stored in the at least one memory and operable, when executed by the at least one processor, to cause the device to perform any one of clauses 1 to 17.
[0131] Clause 19. An apparatus comprising at least one means for performing any of clauses 1 to 17.
[0132] Clause 20. A computer program comprising code for causing an apparatus to perform any one of clauses 1 to 17.
[0133] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the aspects to the precise forms disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of these aspects.
[0134] As used, the term "component" is intended to be broadly interpreted as hardware, firmware, and / or a combination of hardware and software. As used, a processor is implemented using hardware, firmware, and / or a combination of hardware and software.
[0135] Some aspects are described in conjunction with thresholds. As used, satisfying a threshold can mean a value is greater than a threshold, greater than or equal to a threshold, less than a threshold, less than or equal to a threshold, equal to a threshold, not equal to a threshold, etc., depending on the context.
[0136] It will be apparent that the described systems and / or methods can be implemented in various forms of hardware, firmware, and / or a combination of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods does not limit the aspects. Therefore, the operation and performance of these systems and / or methods are described without reference to specific software code, and it should be understood that software and hardware used to implement these systems and / or methods can be designed based at least in part on these descriptions.
[0137] Although specific combinations of features are set forth in the claims and / or disclosed in the specification, these combinations are not intended to limit the disclosure of the various aspects. In fact, many of these features can be combined in a manner that is not specifically set forth in the claims and / or not disclosed in the specification. Although each dependent claim listed below may directly depend on only one claim, the disclosure of the various aspects includes each dependent claim in combination with each other claim in the claim set. The phrase "at least one" mentioned in the list of items refers to any combination of those items, including single members. For example, "at least one of a, b or c" is intended to cover a, b, c, ab, ac, bc and abc, and any combination with multiple identical elements (for example, aa, aaa, aab, aac, abb, acc, bb, bbb, bbc, cc and ccc, or any other arrangement of a, b and c).
[0138] The elements, actions or instructions used should not be interpreted as critical or essential unless expressly described as such. In addition, as used, the articles "a" and "an" are intended to include one or more items and can be used interchangeably with "one or more". In addition, as used, the terms "set" and "group" are intended to include one or more items (e.g., related items, unrelated items, combinations of related items and unrelated items, etc.) and can be used interchangeably with "one or more". If only one item is intended to be referred to, the phrase "only one" or similar terms are used. In addition, as used, the terms "having" and the like are intended to be open terms. In addition, the phrase "based on" is intended to mean "based at least in part on", unless explicitly stated otherwise.
Claims
1. A method for wireless communication by a first wireless communication device, the method comprising: receiving a latency report from a second wireless communication device, the latency report indicating a first latency value associated with a first uplink packet in a first set of uplink packets associated with a medium access control (MAC) transport block (TB), a second latency value associated with a second uplink packet in the first set of uplink packets, and a number of lost uplink packets in the first set of uplink packets; adjusting a configuration of a second set of uplink packets based on receiving the latency report; as well as The second set of uplink packets is sent in accordance with adjusting the configuration. 2 . The method of claim 1 , wherein the first wireless communication device is a network node and the second wireless communication device is a user equipment (UE).
3. The method according to claim 2, further comprising: A message is sent indicating a latency report configuration, wherein the latency report is received based on sending the message.
4. The method according to claim 3, wherein: The latency reporting configuration indicates the periodicity of the latency reporting; and The latency reporting configuration is included in a radio resource control (RRC) message or a quality of service (QoS) configuration message.
5. The method according to claim 4, wherein: The first delay value is a first average delay associated with a group of initial uplink packets over a previous time period; and The second latency value is a second average latency associated with a group of last uplink packets within the previous time period. The method according to claim 3 , wherein the latency report configuration is an on-demand request for the latency report.
7. The method of claim 2, wherein adjusting the configuration of the second set of uplink packets comprises: adjusting one or more grant sizes of the second set of grant sizes for uplink packets; adjusting a periodicity of the second set of uplink packets; adjusting the timing of the second set of uplink packets; adjusting a grant associated with the second set of uplink packets from a configured grant to a dynamic grant; or Adjust the logical channel configuration.
8. The method according to claim 2, further comprising: Upon receipt of the delay report, a message requesting to update QoS characteristics is sent to a session management function (SMF).
9. The method according to claim 2, further comprising: Based on receiving the latency report: adjusting the QoS codec, dynamically enabling and / or disabling one or more component carriers, adjusting radio bearer mapping, adapting radio access network (RAN) resources, enabling or disabling packet data convergence protocol (PDCP) duplication, adjusting carrier group mapping, moving quality of service (QoS) flows to different slices, updating a UE routing policy (URSP), and / or updating the URSP for one slice in a group of slices.
10. The method of claim 1 , wherein the latency report is received in a Packet Data Convergence Protocol (PDCP) control protocol data unit (PDU), a Radio Link Control (RLC) PDU, a Radio Resource Configuration (RRC) message, a Service Data Adaptation Protocol (SDAP) control PDU, or a Medium Access Control (MAC) Control Element (CE) (MAC-CE).
11. The method of claim 1 , wherein the latency report is associated with the QoS flow or a group of QoS flows at a bearer level, a specific radio bearer, a specific logical channel and / or a set of protocol data unit (PDU) types.
12. The method of claim 1, wherein the latency report includes a QoS Flow Identifier (QFI).
13. The method of claim 1, wherein the latency report comprises one or more bit-indicated parameters associated with the first set of packets.
14. The method of claim 1, wherein the first wireless communication device is a user equipment (UE) and the second wireless communication device is a network node.
15. The method of claim 14, wherein adjusting the configuration of the second set of uplink packets comprises: The timing of the second set of uplink packets is adjusted.
16. The method of claim 1, wherein the first set of packets and the second set of packets are protocol data unit (PDU) packets or belong to a specific PDU set.
17. The method of claim 1, wherein: The first uplink packet is an initial packet in the MAC TB, and the second uplink packet is a final packet in the MAC TB or a Quality of Service (QoS) flow among a plurality of QoS flows associated with the MAC TB.
18. An apparatus for wireless communication by a first wireless communication device, the apparatus comprising: at least one processor; and at least one memory coupled to the at least one processor and storing instructions that, when executed by the at least one processor, are operable to cause the apparatus to: receiving a latency report from a second wireless communication device, the latency report indicating a first latency value associated with a first uplink packet in a first set of uplink packets associated with a medium access control (MAC) transport block (TB), a second latency value associated with a second uplink packet in the first set of uplink packets, and a number of lost uplink packets in the first set of uplink packets; adjusting a configuration of a second set of uplink packets based on receiving the latency report; as well as The second set of uplink packets is sent in accordance with adjusting the configuration.
19. The apparatus of claim 18, wherein the first wireless communication device is a network node and the second wireless communication device is a user equipment (UE).
20. The apparatus of claim 19, wherein: Execution of the instructions further causes the apparatus to send a message indicating a latency reporting configuration; The delay report is received based on sending the message; The latency reporting configuration indicates the periodicity of the latency reporting; and The latency reporting configuration is included in a radio resource control (RRC) message or a quality of service (QoS) configuration message.
21. The apparatus of claim 19, wherein execution of the instructions that cause the apparatus to adjust the configuration of the second set of uplink packets further causes the apparatus to: adjusting one or more grant sizes of the second set of grant sizes for uplink packets; adjusting a periodicity of the second set of uplink packets; adjusting the timing of the second set of uplink packets; adjusting a grant associated with the second set of uplink packets from a configured grant to a dynamic grant; or Adjust the logical channel configuration.
22. The apparatus of claim 19, wherein execution of the instructions further causes the apparatus to: send a message requesting an update of QoS characteristics to a session management function (SMF) based on receiving the latency report.
23. The apparatus of claim 19, wherein execution of the instructions further causes the apparatus to: based on receiving the latency report: adjust a QoS codec, dynamically enable and / or disable one or more component carriers, adjust radio bearer mapping, adapt radio access network (RAN) resources, enable or disable packet data convergence protocol (PDCP) duplication, adjust carrier group mapping, move a quality of service (QoS) flow to a different slice, update a UE routing policy (URSP), and / or update the URSP for one slice in a group of slices.
24. The apparatus of claim 18, wherein the latency report is received in a Packet Data Convergence Protocol (PDCP) control protocol data unit (PDU), a Radio Link Control (RLC) PDU, a Radio Resource Configuration (RRC) message, a Service Data Adaptation Protocol (SDAP) control PDU, or a Medium Access Control (MAC) Control Element (CE) (MAC-CE).
25. The apparatus of claim 18, wherein the latency report is associated with the QoS flow or a group of QoS flows at a bearer level, a specific radio bearer, a specific logical channel, and / or a set of protocol data unit (PDU) types.
26. The apparatus of claim 18, wherein the latency report comprises one or more bit-indicated parameters associated with the first set of packets.
27. The apparatus of claim 18, wherein the first wireless communication device is a user equipment (UE) and the second wireless communication device is a network node.
28. The apparatus of claim 27, wherein execution of the instructions that cause the apparatus to adjust the configuration of the second set of uplink packets further causes the apparatus to adjust the timing of the second set of uplink packets.
29. A non-transitory computer-readable medium having recorded thereon program code for wireless communication at a user equipment (UE), the program code being executed by at least one processor and comprising: program code for receiving a latency report from a second wireless communication device, the latency report indicating a first latency value associated with a first uplink packet in a first set of uplink packets associated with a medium access control (MAC) transport block (TB), a second latency value associated with a second uplink packet in the first set of uplink packets, and a number of lost uplink packets in the first set of uplink packets; program code for adjusting a configuration of a second set of uplink packets based on receiving the latency report; and Program code is provided for sending the second set of uplink packets in accordance with adjusting the configuration.
30. An apparatus for wireless communication by a first wireless communication device, the apparatus comprising: means for receiving a latency report from a second wireless communication device, the latency report indicating a first latency value associated with a first uplink packet in a first set of uplink packets associated with a medium access control (MAC) transport block (TB), a second latency value associated with a second uplink packet in the first set of uplink packets, and a number of lost uplink packets in the first set of uplink packets; means for adjusting a configuration of a second set of uplink packets based on receiving the latency report; and Means for sending the second set of uplink packets in accordance with adjusting the configuration.