API-controlled PDCP deordering control and delivery for downlink traffic

Abstract

The process involves activating Out-of-Order Delivery (OOOD) on the User Equipment (UE). The Application Programming Interface (API) on the UE can set one or more configuration parameters for IP flows from the wireless network. The UE can then measure the IP flows, Traffic Flow Templates (TFTs), and / or Quality of Service Flows (QFIs) from the wireless network to identify measured IP flows from that wireless network that satisfy the one or more configuration parameters. The UE can then activate OOOD for such IP flows from the wireless network that satisfy the one or more configuration parameters.

Description

[0001] Cross-reference to related applications

[0002] This application claims priority and benefit to non-provisional patent application serial number SN17 / 383,166 filed with the U.S. Patent and Trademark Office on July 22, 2021, and provisional patent application serial number SN63 / 059,913 filed with the U.S. Patent and Trademark Office on July 31, 2020, the entire contents of which are as fully set forth below and incorporated herein for all applicable purposes. Technical Field

[0003] The techniques discussed below generally relate to wireless communication systems, and more specifically to monitoring data streams to activate out-of-order delivery (OOOD) transmissions on user equipment (UE).

[0004] introduction

[0005] Within a wireless communication network, Quality of Service (QoS) refers to the set of techniques that enable the network to meet specific performance parameters (e.g., reliability and / or target latency). These QoS techniques achieve these performance parameters by applying different treatments to different traffic flows within the network. For example, each flow can be assigned a specific QoS, with the auxiliary network determining the order in which packets from each flow are processed and the amount of bandwidth allocated to each flow. Each QoS flow can further be mapped to a Data Radio Bearer (DRB) established between the User Equipment (UE) and the base station.

[0006] A brief overview of some examples

[0007] The following provides an overview of one or more aspects of this disclosure to provide a basic understanding of these aspects. This overview is not an exhaustive summary of all conceived features of this disclosure, nor is it intended to identify key or defining elements of all aspects of this disclosure, nor to define the scope of any or all aspects of this disclosure. Its sole purpose is to provide some concepts of one or more aspects of this disclosure in one form as a prelude to the more detailed description that follows.

[0008] In some examples, a method for a user equipment (UE) to communicate with a wireless network is disclosed, wherein the method may include: executing an application programming interface (API) in the UE to set one or more configuration parameters from the wireless network, identifying data from the wireless network that matches the one or more configuration parameters via the API, and activating out-of-order delivery (OOOD) of the data from the wireless network that matches the one or more configuration parameters via the API.

[0009] In some examples, a user equipment (UE) in a wireless communication network is disclosed, wherein the UE includes a wireless transceiver, a memory, and a processor communicatively coupled to the wireless transceiver and the memory. The processor and the memory can be configured to: execute an application programming interface (API) in the UE to set one or more configuration parameters from the wireless network; identify data from the wireless network matching the one or more configuration parameters via the API; and activate out-of-order delivery (OOOD) of the data from the wireless network matching the one or more configuration parameters via the API.

[0010] In some examples, a user equipment (UE) in a wireless network is disclosed, wherein the UE may include: means for executing an application programming interface (API) in the UE to set one or more configuration parameters from the wireless network; means for identifying data from the wireless network that matches the one or more configuration parameters via the API; and means for activating out-of-order delivery (OOOD) of the data from the wireless network that matches the one or more configuration parameters via the API.

[0011] In some examples, a non-transient computer-readable medium is disclosed, storing instructions executable by one or more processors of a user equipment (UE) in a wireless communication network to: execute an application programming interface (API) in the UE to set one or more configuration parameters from the wireless network; identify data from the wireless network that matches the one or more configuration parameters via the API; and activate out-of-order delivery (OOOD) of the data from the wireless network that matches the one or more configuration parameters via the API.

[0012] These and other aspects of the invention will become more fully understood upon reading the following detailed description. Other aspects, features, and examples of the invention will become apparent to those skilled in the art after reading the following description of specific exemplary examples of the invention in conjunction with the accompanying drawings. Although features of the invention may be discussed below with respect to certain examples and drawings, all examples of the invention may include one or more of the advantageous features discussed herein. In other words, although one or more examples may be discussed having certain advantageous features, one or more such features may also be used according to the various examples of the invention discussed herein. Similarly, although exemplary examples may be discussed below as examples of devices, systems, or methods, it should be understood that such exemplary examples can be implemented in various devices, systems, and methods. Brief description of the attached diagram

[0014] Figure 1 This is a schematic illustration of a wireless communication system based on some aspects of this disclosure.

[0015] Figure 2 This is a conceptual explanation of an example of a radio access network based on some aspects of this disclosure.

[0016] Figure 3 This is a diagram illustrating an example of a radio protocol architecture for the user plane and control plane according to some aspects of this disclosure.

[0017] Figure 4 This is a diagram illustrating an exemplary Quality of Service (QoS) architecture based on some aspects of this disclosure.

[0018] Figure 5 A simplified block diagram of a wireless system for mapping low latency streams, based on some aspects of this disclosure, is described.

[0019] Figure 6 Another simplified block diagram of a wireless system for mapping low latency streams, according to some aspects of this disclosure, is illustrated.

[0020] Figure 7 Another simplified block diagram of a wireless system for mapping low latency streams, according to some aspects of this disclosure, is illustrated.

[0021] Figure 8 This is a block diagram illustrating an example of a hardware implementation of a scheduled entity employing a processing system according to some aspects of this disclosure.

[0022] Figure 9 This is a block diagram illustrating an example of a hardware implementation of a scheduling entity of a processing system according to some aspects of this disclosure.

[0023] Figure 10 The present disclosure describes methods for measuring and detecting characteristics of Transmission Control Protocol (TCP) traffic over radio bearers for implementing UE-based PDCP-OOOD control.

[0024] Figure 11 The present disclosure describes methods for enabling a UE to communicate with a wireless network, based on some aspects thereof.

[0025] Detailed description

[0026] The detailed description that follows, taken in conjunction with the accompanying drawings, is intended as a description of various configurations and is not intended to represent only the configurations in which the concepts described herein can be practiced. This detailed description includes specific details to provide a thorough understanding of the various concepts. However, it will be apparent to those skilled in the art that these concepts can be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form to avoid obscuring such concepts.

[0027] While aspects and examples are described herein by way of illustration of a few examples, those skilled in the art will understand that additional implementations and use cases may arise in many different arrangements and scenarios. The innovations described herein can be implemented across many different platform types, devices, systems, shapes, sizes, and package arrangements. For example, aspects and / or uses may arise via integrated chip examples and other devices based on non-modular components (e.g., end-user devices, vehicles, communication devices, computing devices, industrial equipment, retail / shopping devices, medical devices, AI-enabled devices, etc.). While some examples may or may not be specific to a particular use case or application, broad applicability of the described innovations can emerge. The scope of implementations can range from chip-level or modular components to non-modular, non-chip-level implementations, and further to aggregated, distributed, or OEM devices or systems incorporating one or more aspects of the described innovations. In some practical contexts, devices incorporating the described aspects and features may also necessarily include additional components and features for implementing and practicing the claimed and described examples. For example, the transmission and reception of wireless signals requires several components for analog and digital purposes (e.g., hardware components including antennas, RF chains, power amplifiers, modulators, buffers, processors, interleavers, adders / summers, etc.). The innovations described herein are intended to be implemented in a wide variety of devices, chip-level components, systems, distributed deployments, end-user devices, etc., of various sizes, shapes, and configurations.

[0028] The various concepts presented throughout this disclosure can be implemented across a wide range of telecommunications systems, network architectures, and communication standards. Now refer to... Figure 1 Various aspects of this disclosure are explained with reference to a wireless communication system 100, as illustrative examples and not limitation. The wireless communication system 100 includes three interaction domains: a core network 102, a radio access network (RAN) 104, and a user equipment (UE) 106. The wireless communication system 100 enables the UE 106 to perform data communication with an external data network 110 (such as, but not limited to, the Internet).

[0029] RAN 104 can implement any suitable one or more wireless communication technologies to provide radio access to UE 106. As an example, RAN 104 can operate according to the 3rd Generation Partnership Project (3GPP) New Radio (NR) specification (commonly referred to as 5G). As another example, RAN 104 can operate in a hybrid of 5G NR and the Evolved Universal Terrestrial Radio Access Network (eUTRAN) standard (commonly referred to as Long Term Evolution (LTE)). 3GPP refers to this hybrid RAN as Next Generation RAN, or NG-RAN. Of course, many other examples can be utilized within the scope of this disclosure.

[0030] As explained, RAN 104 includes multiple base stations 108. Broadly speaking, a base station is a network element in a radio access network responsible for radio transmissions to and from a UE in one or more cells. In different technologies, standards, or contexts, a base station may be referred to by those skilled in the art as a base transceiver station (BTS), radio base station, radio transceiver, transceiver function, basic service set (BSS), extended service set (ESS), access point (AP), B-node (NB), evolved B-node (eNB), next-generation B-node (gNB), transmit / receive point (TRP), or some other suitable term. In some examples, a base station may include two or more co-located or non-co-located TRPs. Each TRP may communicate on the same or different carrier frequencies within the same or different frequency bands. In an example where RAN 104 operates according to both LTE and 5G NR standards, one of these base stations may be an LTE base station, while the other may be a 5G NR base station.

[0031] RAN 104 is further explained as supporting wireless communication for multiple mobile devices. In 3GPP standards, a mobile device may be referred to as User Equipment (UE), but may also be referred to by those skilled in the art as a Mobile Station (MS), Subscriber Station, Mobile Unit, Subscriber Unit, Radio Unit, Remote Unit, Mobile Equipment, Radio Equipment, Wireless Communication Equipment, Remote Equipment, Mobile Subscriber Station, Access Terminal (AT), Mobile Terminal, Radio Terminal, Remote Terminal, Handheld Device, Terminal, User Agent, Mobile Client, Client, or any other suitable term. A UE may be a device (e.g., a mobile device) that provides users with access to network services.

[0032] Within this disclosure, a "mobile" device does not necessarily need to be mobile and may be stationary. The term mobile device or mobile equipment refers to a wide variety of devices and technologies. A UE may include several hardware structural components that are sized, shaped, and arranged to facilitate communication; such components may include antennas, antenna arrays, RF chains, amplifiers, one or more processors, etc., electrically coupled to each other. For example, some non-limiting examples of mobile devices include mobile devices, cellular phones, smartphones, Session Initiation Protocol (SIP) phones, laptops, personal computers (PCs), notebooks, netbooks, smartbooks, tablets, personal digital assistants (PDAs), and a wide variety of embedded systems, such as those corresponding to the "Internet of Things" (IoT).

[0033] Additionally, mobile devices can be automobiles or other transportation vehicles, remote sensors or actuators, robots or robotic equipment, satellite radios, Global Positioning System (GPS) devices, object tracking devices, drones, multi-rotor aircraft, quadcopters, remote control devices, consumer and / or wearable devices (such as glasses), wearable cameras, virtual reality devices, smartwatches, health or fitness trackers, digital audio players (e.g., MP3 players), cameras, game consoles, etc. Additionally, mobile devices can be digital home or smart home devices, such as home audio, video and / or multimedia equipment, appliances, vending machines, smart lighting equipment, home security systems, smart meters, etc. Additionally, mobile devices can be smart energy devices, security devices, solar panels or solar arrays, municipal infrastructure equipment controlling electricity, lighting, water, etc. (e.g., smart grids), industrial automation and enterprise equipment, logistics controllers and / or agricultural equipment, etc. Furthermore, mobile devices can provide connected medical or telemedicine support, such as remote healthcare. Remote healthcare devices may include remote healthcare monitoring devices and remote healthcare supervision devices, whose communications may be given priority or preferential access over other types of information, for example, in the form of priority access for critical service data transmission and / or relevant QoS for critical service data transmission.

[0034] Wireless communication between RAN 104 and UE 106 can be described as utilizing an air interface. Transmissions over the air interface from a base station (e.g., base station 108) to one or more UEs (e.g., similar to UE 106) can be referred to as downlink (DL) transmissions. According to certain aspects of this disclosure, the term downlink can refer to point-to-multipoint transmissions originating at a base station (e.g., base station 108). Another way to describe this scheme is to use the term broadcast channel multiplexing. Transmissions from a UE (e.g., UE 106) to a base station (e.g., base station 108) can be referred to as uplink (UL) transmissions. According to a further aspect of this disclosure, the term uplink can refer to point-to-point transmissions originating at a UE (e.g., UE 106).

[0035] In some examples, access to the air interface can be scheduled, where a scheduling entity (e.g., base station 108) allocates resources for communication among some or all of the equipment and devices within its service area or cell. Within this disclosure, as further discussed below, the scheduling entity may be responsible for scheduling, assigning, reconfiguring, and releasing resources for one or more scheduled entities (e.g., UE 106). That is, for scheduled communication, multiple UEs 106 (which may be scheduled entities) may utilize resources allocated by scheduling entity 108.

[0036] Base station 108 is not the only entity that can be used as a scheduling entity. That is, in some examples, a UE can be used as a scheduling entity to schedule resources for one or more scheduled entities (e.g., one or more other UEs). For example, a UE can communicate directly with other UEs in a peer-to-peer or device-to-device manner and / or in a relay configuration.

[0037] like Figure 1 As explained, scheduling entity 108 may broadcast downlink traffic 112 to one or more scheduled entities (e.g., one or more UEs 106). Broadly speaking, scheduling entity 108 is a node or device responsible for scheduling traffic (including downlink traffic 112 and, in some examples, uplink traffic 116 from one or more scheduled entities (e.g., one or more UEs 106) to scheduling entity 108) in a wireless communication network. On the other hand, a scheduled entity (e.g., UE 106) is a node or device that receives downlink control information 114 (including, but not limited to, scheduling information (e.g., permission), synchronization or timing information), or other control information) from another entity in the wireless communication network (such as scheduling entity 108).

[0038] Additionally, uplink control information 118 and / or downlink control information and / or traffic information can be transmitted on a waveform that can be temporally divided into frames, subframes, time slots, and / or symbols. As used herein, a symbol may refer to a time unit in an Orthogonal Frequency Division Multiplexing (OFDM) waveform that carries one resource element (RE) per subcarrier. A time slot may carry 7 or 14 OFDM symbols. A subframe may refer to a duration of 1 ms. Multiple subframes or time slots may be grouped together to form a single frame or radio frame. Within this disclosure, a frame may refer to a predetermined duration (e.g., 10 ms) for wireless transmission, wherein each frame comprises, for example, 10 subframes, each 1 ms in length. Of course, these definitions are not required, and any suitable scheme may be used to organize the waveform, and various time divisions of the waveform may have any suitable duration.

[0039] Generally, base station 108 may include a backhaul interface for communicating with the backhaul portion 120 of wireless communication system 100. Backhaul portion 120 provides a link between base station 108 and core network 102. Furthermore, in some examples, the backhaul network provides interconnection between the respective base stations 108. Any suitable transport network can be used to employ various types of backhaul interfaces, such as direct physical connections, virtual networks, etc.

[0040] Core network 102 may be part of wireless communication system 100 and may be independent of the radio access technology used in RAN 104. In some examples, core network 102 may be configured according to 5G standards (e.g., 5GC). In other examples, core network 102 may be configured according to 4G evolved packet core (EPC), or any other suitable standard or configuration.

[0041] Now refer to Figure 2 The illustrative example, and not a limitation, of a radio access network (RAN) 200 according to some aspects of this disclosure is provided. In some examples, the RAN 200 may be associated with the RAN 200 described above and in Figure 1 The RAN104 in the Chinese explanation is the same.

[0042] The geographic area covered by RAN 200 can be divided into several cellular areas (cells), which can be uniquely identified by the user equipment (UE) based on an identifier broadcast across the geographic area from an access point or base station. Figure 2 Cells 202, 204, 206, and 208 are described, each of which may include one or more sectors (not shown). A sector is a sub-area of ​​a cell. All sectors within a cell are served by the same base station. Radio links within a sector may be identified by a single logical identifier belonging to that sector. In a cell divided into sectors, multiple sectors within the cell may be formed by an antenna array, where each antenna is responsible for communication with UEs within a portion of the cell.

[0043] It can be deployed using various base stations. For example, in Figure 2 In this example, two base stations (base station 210 and base station 212) are shown in cells 202 and 204. A third base station (base station 214) is shown as a remote radio head (RRH) 216 controlling cell 206. That is, the base station may have an integrated antenna, or it may be connected to the antenna or RRH 216 by a feed cable. In the illustrated example, cells 202, 204, and 206 may be referred to as macrocells because base stations 210, 212, and 214 support cells with large sizes. Furthermore, base station 218 is shown in cell 208, which may overlap with one or more macrocells. In this example, cell 208 may be referred to as a small cell (e.g., microcell, picocell, femtocell, home base station, home B-node, home evolved B-node, etc.) because base station 218 supports cells with relatively small sizes. Cell size settings can be determined based on system design and component constraints.

[0044] To understand, RAN 200 can include any number of radio base stations and cells. Furthermore, relay nodes can be deployed to extend the size or coverage area of ​​a given cell. Base stations 210, 212, 214, and 218 provide radio access points to the core network for any number of mobile devices. In some examples, base stations 210, 212, 214, and / or 218 can be used with those described above and in... Figure 1 The scheduling entity 108 described in the middle is the same as or similar to it.

[0045] Figure 2 This further includes an unmanned aerial vehicle (UAV) 220, which may be a drone or a quadcopter. The UAV 220 can be configured to function as a base station, or more specifically as a mobile base station. That is, in some examples, the cell may not be stationary, and the geographical area of ​​the cell may move depending on the location of the mobile base station (such as the UAV 220).

[0046] Within RAN 200, a cell may include UEs capable of communicating with one or more sectors of each cell. Furthermore, each base station 210, 212, 214, 218, and 220 may be configured to provide all UEs in the respective cell to the core network 102 (see [link to core network 102]). Figure 1 Access points. For example, UEs 222 and 224 may communicate with base station 210; UEs 226 and 228 may communicate with base station 212; UEs 230 and 232 may communicate with base station 214 via RRH 216; UE 234 may communicate with base station 218; and UE 236 may communicate with mobile base station 220. In some examples, UEs 222, 224, 226, 228, 230, 232, 234, 236, 238, 240 and / or 242 may communicate with the access points described above and in... Figure 1 The UE / scheduled entity 106 described in the text is the same as or similar to the UE. In some examples, the UAV 220 (e.g., a quadcopter) can be a mobile network node and can be configured to act as a UE. For example, the UAV 220 can operate within cell 202 by communicating with base station 210.

[0047] In a further aspect of RAN 200, sidelink signaling can be used between UEs without relying on scheduling or control information from the base station. Sidelink communication can be used in, for example, device-to-device (D2D) networks, peer-to-peer (P2P) networks, vehicle-to-vehicle (V2V) networks, vehicle-to-everything (V2X) networks, and / or other suitable sidelink networks. For example, two or more UEs (e.g., UEs 238, 240, and 242) can communicate with each other using sidelink signal 237 without relaying the communication through the base station. In some examples, UEs 238, 240, and 242 can each act as a scheduling entity or transmitting sidelink device and / or via a scheduling entity or receiving sidelink device to schedule resources and communicate sidelink signal 237 therebetween without relying on scheduling or control information from the base station. In other examples, two or more UEs (e.g., UEs 226 and 228) within the coverage area of ​​a base station (e.g., base station 212) may also communicate sidelink signal 227 on a direct link (sidelink) without needing to communicate through base station 212. In this example, base station 212 may allocate resources to UEs 226 and 228 for sidelink communication.

[0048] To achieve a low block error rate (BLER) while still maintaining a very high data rate over the air interface, channel decoding can be used. That is, wireless communication typically utilizes appropriate error-correcting block codes. In a typical block code, an information message or sequence is broken down into code blocks (CBs), and an encoder (e.g., a CODEC) at the transmitting device then mathematically adds redundancy to the information message. Utilizing this redundancy in the encoded information message improves message reliability, thereby enabling the correction of any bit errors that may occur due to noise.

[0049] Data decoding can be implemented in several ways. In earlier 5G NR specifications, user data was encoded using quasi-cyclic low-density parity-check (LDPC) with two different base maps: one base map was used for large code blocks and / or high code rates, while the other base map was used for other cases. Polarity decoding is used based on nested sequences to decode control information and the Physical Broadcast Channel (PBCH). For these channels, puncturing, shortening, and repetition are used for rate matching.

[0050] Various aspects of this disclosure can be implemented using any suitable channel code. Various implementations of the base station and UE may include suitable hardware and capabilities (e.g., encoders, decoders, and / or CODECs) to utilize one or more of these channel codes for wireless communication.

[0051] In RAN 200, the ability of a UE to communicate independently of its location while on the move is referred to as mobility. The various physical channels between the UE and RAN 200 are generally established, maintained, and released under the control of the Access and Mobility Management Function (AMF). In some scenarios, the AMF may include a Security Context Management Function (SCMF) and a Security Anchor Function (SEAF) that performs authentication. The SCMF can manage the security context of both the control plane and user plane functionalities, either entirely or partially.

[0052] In various aspects of this disclosure, RAN 200 may utilize DL-based mobility or UL-based mobility to achieve mobility and handover (i.e., the UE's connection is transferred from one radio channel to another). In a network configured for DL-based mobility, during a call with a scheduling entity, or at any other time, the UE may monitor various parameters of the signal from its serving cell and various parameters of neighboring cells. Depending on the quality of these parameters, the UE may maintain communication with one or more neighboring cells. During this time, if the UE moves from one cell to another, or if the signal quality from a neighboring cell exceeds the signal quality from the serving cell for a given amount of time, the UE may perform a handover or handover from the serving cell to a neighboring (target) cell. For example, UE 224 may move from a geographic area corresponding to its serving cell 202 to a geographic area corresponding to a neighboring cell 206. When the signal strength or quality from the neighboring cell 206 exceeds the signal strength or quality from its serving cell 202 for a given amount of time, UE 224 may transmit a report message indicating this condition to its serving base station 210. In response, UE 224 may receive a handover command and may undergo a handover to cell 206.

[0053] In a network configured for UL-based mobility, the UL reference signal from each UE can be used by the network to select a serving cell for each UE. In some examples, base stations 210, 212, and 214 / 216 can broadcast unified synchronization signals (e.g., unified primary synchronization signal (PSS), unified secondary synchronization signal (SSS), and unified physical broadcast channel (PBCH)). UEs 222, 224, 226, 228, 230, and 232 can receive the unified synchronization signals, derive carrier frequencies and time slot timings from these synchronization signals, and transmit uplink pilots or reference signals in response to the derived timings. The uplink pilot signal transmitted by a UE (e.g., UE 224) can be received concurrently by two or more cells (e.g., base stations 210 and 214 / 216) within RAN 200. Each of these cells can measure the strength of the pilot signal, and the radio access network (e.g., one or more of base stations 210 and 214 / 216 and / or a central node within the core network) can determine the serving cell for UE 224. As UE 224 moves within RAN 200, RAN 200 can continue to monitor the uplink pilot signal transmitted by UE 224. When the signal strength or quality of the pilot signal measured by a neighboring cell exceeds the signal strength or quality measured by the serving cell, RAN 200 can, with or without notification to UE 224, switch UE 224 from the serving cell to that neighboring cell.

[0054] Although the synchronization signal transmitted by base stations 210, 212, and 214 / 216 can be uniform, it may not identify a specific cell, but rather a zoning that includes multiple cells operating on the same frequency and / or having the same timing. Using zoning in 5G networks or other next-generation communication networks enables uplink-based mobility frameworks and improves the efficiency of both the UE and the network because the number of mobility messages that need to be exchanged between the UE and the network can be reduced.

[0055] In various implementations, the air interface in the radio access network 200 may utilize licensed spectrum, unlicensed spectrum, or shared spectrum. Licensed spectrum typically provides exclusive use of a portion of the spectrum by a mobile network operator purchasing a license from a government regulatory agency. Unlicensed spectrum provides shared use of a portion of the spectrum without a government-granted license. While some technical rules generally still need to be followed to access unlicensed spectrum, access can be obtained by any operator or device. Shared spectrum may fall between licensed and unlicensed spectrum, where technical rules or restrictions may be required to access the spectrum, but the spectrum may still be shared by multiple operators and / or multiple RATs. For example, a licensee of a portion of licensed spectrum may provide Licensed Shared Access (LSA) to share that spectrum with other parties, for example, by utilizing conditions determined by the appropriate licensee.

[0056] Devices communicating in the radio access network 200 can utilize one or more multiplexing techniques and multiple access algorithms to achieve simultaneous communication between the devices. For example, the 5G NR specification utilizes Orthogonal Frequency Division Multiplexing (OFDM) with a cyclic prefix (CP) to provide multiple access for UL transmissions from UEs 222 and 224 to base station 210, and to provide multiplexing for DL ​​transmissions from base station 210 to one or more UEs 222 and 224. Additionally, for UL transmissions, the 5G NR specification provides support for Discrete Fourier Transform Extended OFDM (DFT-s-OFDM) with CP (also known as Single-Carrier FDMA (SC-FDMA)). However, within the scope of this disclosure, multiplexing and multiple access are not limited to the above schemes and can be provided using Time Division Multiple Access (TDMA), Code Division Multiple Access (CDMA), Frequency Division Multiple Access (FDMA), Sparse Code Multiple Access (SCMA), Resource Extended Multiple Access (RSMA), or other suitable multiple access schemes. In addition, multiplexing of DL transmissions from base station 210 to UEs 222 and 224 can be provided using time division multiplexing (TDM), code division multiplexing (CDM), frequency division multiplexing (FDM), orthogonal frequency division multiplexing (OFDM), sparse code multiplexing (SCM), or other suitable multiplexing schemes.

[0057] Devices in the radio access network 200 can also utilize one or more duplex algorithms. Duplex refers to a point-to-point communication link where both endpoints can communicate with each other in both directions. Full-duplex means that both endpoints can communicate with each other simultaneously. Half-duplex means that only one endpoint can send information to the other endpoint at a time. Half-duplex simulation is typically implemented for wireless links using Time Division Duplex (TDD). In TDD, transmissions in different directions on a given channel are separated using time division multiplexing. That is, in some scenarios, the channel is dedicated to transmission in one direction, while at other times, the channel is dedicated to transmission in the other direction, where the direction can change very rapidly, for example, several times per time slot. In wireless links, full-duplex channels generally rely on physical isolation between the transmitter and receiver, and appropriate interference cancellation techniques. Full-duplex simulation is typically implemented for wireless links using Frequency Division Duplex (FDD) or Space Division Duplex (SDD). In FDD, transmissions in different directions can operate at different carrier frequencies (e.g., within paired spectrum). In SDD, transmissions in different directions on a given channel are separated from each other using spatial division multiplexing (SDM). In other examples, full-duplex communication can be implemented within unpaired spectrum (e.g., within a single carrier bandwidth), where transmissions in different directions occur within different subbands of the carrier bandwidth. This type of full-duplex communication may be referred to herein as Subband Full-Duplex (SBFD), also known as flexible duplex.

[0058] For RAN (such as Figure 2 The radio protocol architecture shown in RAN 200 can take various forms depending on the specific application. Figure 3 Examples of radio protocol architectures used for the user plane and control plane are explained.

[0059] like Figure 3 The radio protocol architecture for UE and base station, as explained in the document, consists of three layers: Layer 1 (L1), Layer 2 (L2), and Layer 3 (L3). L1 is the lowest layer and implements various physical layer signal processing functions. L1 will be referred to as physical layer 306 in this document. L2 308 is above physical layer 306 and is responsible for the link between UE and base station above physical layer 306.

[0060] In the user plane, L2 layer 308 includes a Media Access Control (MAC) layer 310, a Radio Link Control (RLC) layer 312, a Packet Data Convergence Protocol (PDCP) layer 314, and a Serving Data Adaptation Protocol (SDAP) layer 316, which terminate at the base station on the network side. Although not shown, the UE may have several upper layers above L2 layer 308, including at least one network layer (e.g., IP layer and User Data Protocol (UDP) layer) and one or more application layers that terminate at the User Plane Function (UPF) on the network side.

[0061] SDAP layer 316 provides mapping between 5G core (5GC) Quality of Service (QoS) streams and data radio bearers, and performs QoS stream ID marking on both downlink and uplink packets. PDCP layer 314 provides packet sequence numbering, ordered packet delivery, retransmission of PDCP Protocol Data Units (PDUs), and the transfer of upper-layer data packets to lower layers. PDUs can include, for example, Internet Protocol (IP) packets, Ethernet frames, and other unstructured data (i.e., Machine Type Communication (MTC), hereinafter collectively referred to as "packets"). PDCP layer 314 also provides header compression of upper-layer data packets to reduce radio transmission overhead, security through packet cryptography, and integrity protection for data packets. RLC layer 312 provides segmentation and reassembly of upper-layer data packets, error correction via Automatic Repeat Request (ARQ), and sequence numbering independent of PDCP sequence numbering. MAC layer 310 provides multiplexing between logical channels and transport channels. The MAC layer 310 is also responsible for allocating various radio resources (e.g., resource blocks) within a cell among the UEs and for HARQ operations. The physical layer 306 is responsible for transmitting and receiving data on physical channels (e.g., within time slots).

[0062] In the control plane, the radio protocol architecture for the UE and base station is essentially the same for L1 306 and L2 308, except that the SDAP layer and header compression functionality are absent in the control plane. The control plane also includes the Radio Resource Control (RRC) layer 318 in L3 and the higher Non-Access Stratum (NAS) layer 320. The RRC layer 318 is responsible for establishing and configuring the Signaling Radio Bearer (SRB) and Data Radio Bearer (DRB) between the base station and the UE, paging initiated by 5GC or NG-RAN, and broadcasting system information related to the Access Stratum (AS) and Non-Access Stratum (NAS). The RRC layer 318 further manages QoS, mobility management (e.g., handover, cell selection, inter-RAT mobility), UE measurement and reporting, and security functions. The NAS layer 320 terminates at the AMF in the core network and performs various functions such as authentication, registration management, and connection management.

[0063] Reference Figure 4This document provides illustrations of an exemplary QoS architecture 400 that facilitates the aspects disclosed herein. In some examples, the QoS architecture 400 is implemented within a next-generation RAN (e.g., NG-RAN) 402 for both a new radio (NR) for connecting to a 5G core network (5GC) 404 and an E-UTRA for connecting to that 5GC. The NG-RAN 402 includes user equipment (UE) 406 and B-nodes (e.g., next-generation (ng) eNB or gNB) 408, while the 5GC includes user plane functions (UPF) 410. The 5GC 404 may further include other core network nodes (not shown), such as core access and mobility management functions (AMF), session management functions (SMF), and policy control functions (PCF).

[0064] For each UE (e.g., UE 406), 5GC 404 establishes one or more PDU sessions 412. Each PDU session 412 may include one or more data streams 418a-418c (e.g., IP, Ethernet, and / or unstructured data streams), each data stream being associated with one or more application sets. 5GC 404 may further select the QoS to associate with each of the data streams 418a-418c within the PDU session 412. At the NAS level, the QoS stream is the finest granularity with QoS differentiation within the PDU session and is characterized by both the QoS profile provided by 5GC 404 to NB 408 and the QoS rules provided by 5GC 404 to UE 406. The QoS profile is used by NB 408 to determine processing on the radio interface, while the QoS rules specify the mapping between uplink user plane traffic and QoS streams 418a–418c for UE 406.

[0065] A QoS profile may include one or more QoS parameters. For example, a QoS profile may include an Allocation and Retention Priority (ARP), which indicates the priority level for allocation and retention of data radio bearers, and a 5G QoS Identifier (5QI), which is associated with a specific 5G QoS feature. Examples of 5G QoS features may include resource type (e.g., Guaranteed Bit Rate (GBR), Delay-Critical GBR, or non-GBR), priority level, packet delay budget, packet error rate, average window, and minimum data burst size. For GBR QoS flows, the QoS profile may further specify the Guaranteed Stream Bit Rate (GFBR) for both uplink and downlink, the Maximum Stream Bit Rate (MFBR) for both uplink and downlink, and the Maximum Packet Loss Rate for both uplink and downlink. For non-GBR QoS flows, the QoS profile may include a Reflective QoS Attribute (RQA). When an RQA is included, it indicates that some (not necessarily all) of the traffic carried on this QoS flow undergoes Reflective QoS (RQoS) at the NAS layer. Standardized or pre-configured 5G QoS features are derived from 5QI values ​​and are not explicitly signaled. Signaled QoS features are included as part of the QoS profile.

[0066] Furthermore, the aggregated maximum bit rate is associated with each PDU session 412 (Session-AMBR) and each UE 406 (UE-AMBR). The Session-AMBR limit is the expected aggregated bit rate to be provided across all non-GBR QoS flows used for a specific PDU session 412. The UE-AMBR limit is the expected aggregated bit rate to be provided across all non-GBR QoS flows used for a UE.

[0067] NB 408 establishes one or more Data Radio Bearers (DRBs) 414a and 414b per PDU session 412. NB 408 further maps packets belonging to different PDU sessions 412 to different DRBs. Here, NB 408 establishes at least one default DRB (e.g., DRB 414a) for each PDU session 412. At the Access Layer (AS) level, DRBs define packet processing on the radio interface (Uu). DRBs serve each packet with the same packet forwarding processing. Separate DRBs can be established for QoS flows requiring different packet forwarding processing, or several QoS flows belonging to the same PDU session can be multiplexed within the same DRB. Within each PDU session 412, NB 408 determines how to map multiple QoS flows to DRBs. For example, NB 408 can map GBR flows and non-GBR flows, or more than one GBR flow, to the same DRB. For QoS flows configured during PDU session establishment, the timing of establishing non-default DRBs (e.g., DRB 414b) between NB408 and UE 406 may differ from the time the PDU session is established.

[0068] NG-RAN 402 and 5GC 404 ensure quality of service (e.g., reliability and target latency) by mapping packets to the appropriate QoS flows 418a-418c and DRBs 414a and 414b. The NAS layer performs packet filtering in both UE 406 and 5GC 404 to associate uplink (UL) and downlink (DL) packets with QoS flows 418a-419c. The AS layer, which is the functional layer between UE 406 and NB 408, implements mapping rules in UE 406 and NB 408 to associate UL and DL QoS flows 418a-418c with DRBs 414a and 414b. Therefore, there is a two-step mapping: IP flow to QoS flow (in NAS) and from QoS flow to DRB (in AS). Figure 4 In the example shown, QoS flows 418a and 418b are mapped to DRB 414a, while QoS flow 418c is mapped to DRB 414b.

[0069] Each QoS flow 418a-418c is identified within PDU session 412 by a QoS flow ID (QFI) carried in the packet header on the next-generation tunnel (NG-U tunnel) 416 provided on the interface between NB 408 and UPF 410 (NG-U). The QoS flow to DRB mapping performed by NB 408 is based on the QFI and the associated QoS profile (i.e., QoS parameters and QoS characteristics). For example, in the uplink, NB 408 can use reflection mapping or explicit configuration to control the mapping of QoS flows 418a-418c to DRBs 414a and 414b. In reflection mapping, for each DRB 414a and 414b, UE 406 monitors the QFIs of downlink packets and applies the same mapping in the uplink. That is, for a DRB (e.g., DRB 414a), UE 406 maps to uplink packets corresponding to the QoS flows 418a and 418b of QFI and PDU session 412 observed in the downlink packets used for that DRB 414a. To implement this reflection mapping, NB 408 marks downlink packets on the radio interface (Uu) via QFI. In explicit configuration, NB 408 can configure the mapping of uplink QoS flows to the DRB via RRC. UE 406 can apply the latest update to the mapping rules regardless of whether the update is performed via reflection mapping or explicit configuration.

[0070] In the downlink, for RQoS purposes, the QFI is signaled by the NB 408 on the radio interface (Uu), and if neither the NB 408 nor the NAS (as indicated by the RQA) is intended to use the reflection mapping for the QoS flows carried in the DRB, no QFI is signaled on the Uu for use with that DRB. However, the NB 408 can configure the UE 406 to still signal the QFI on the Uu. As indicated above, a default DRB (e.g., DRB414a) is configured for each PDU session 412. If an incoming UL packet does not match the mapping from the RRC-configured and reflection-configured QoS flow IDs to the DRB, the UE 406 can map the UL packet to the default DRB 414a for PDU session 412.

[0071] Upon establishing a PDU session, the UE may be configured (e.g., using control messages from the NB) to map a first QoS flow to a first DRB (e.g., 414a). The UE may be further configured to map a second QoS flow to a second DRB (414b). The NAS layer may then perform packet filtering to associate UL packets with QoS flows. For example, the NAS layer may associate packets from a Serving Data Flow (SDF) to the first QoS flow and packets from other SDFs to corresponding other QoS flows.

[0072] As discussed herein, wireless networks (e.g., 5G NR) can be configured to implement packet reordering functionality at the PDCP layer to alleviate packet transmission problems, but this can potentially introduce undesirable delays in delivering downlink packets to the access point. During wireless communication, packets can be received at nodes (such as at user equipment (UE)) out of order (“out-of-order delivery” or OOOD). Accordingly, packet reordering functionality can be performed at the PDCP layer. Because packet reordering is implemented at this layer, Radio Link Control (RLC) Downlink (DL) Service Data Units (SDUs) can be delivered to the PDCP layer even when gaps exist in the received packets. Additionally, to allow the network stack of the network access point (AP) to receive retransmitted packets, a PDCP reordering timer can be used, whereby, upon the expiration of the timer, DL packets are delivered to the AP, even if there are lost packets preceding packets delivered in the expected packet order.

[0073] These mechanisms mitigate DL packet transmission problems to some extent due to packet drop in the radio link to the access point. However, the PDCP reordering timer is configured for each network cell and is fixed relative to variable factors such as the distance between the UE and the corresponding base station, and the traffic congestion state of that base station. Therefore, even when packets are successfully received at the baseband processor, the PDCP reordering timer may introduce undesirable delays for transmitting downlink packets to the AP.

[0074] In low latency applications (e.g., cloud gaming, extended reality (XR, AR, VR)), the low latency streams in the network can be configured differently. Figure 5 A simplified block diagram of a wireless system 500 for mapping low latency streams according to some aspects of this disclosure is illustrated. The diagram illustrates an application processor 502 (e.g., 804) that can be configured with an application client for a UE 504 communicating via a modem with a RAN 506 and a core network 508, in conjunction with the above. Figure 1This will be discussed in more detail. In low latency applications, traffic flow template (TFT) filtering can be performed in 510. The traffic flow template information element can be used to specify TFT parameters and operations for the Packet Data Protocol (PDP) context. Additionally, this information element can be used to pass additional parameters (e.g., authorization tokens) to the network. The TFT can contain packet filters for downlink direction, uplink direction, or packet filters applied for both directions. Packet filters determine the traffic mapped to the PDP context. Downlink packet filters can be applied by the network and uplink packet filters can be applied by the UE. Packet filters applied for both directions can be applied by the network as downlink packet filters and by the UE as uplink filters.

[0075] Payload data can be transmitted between the core network 508 User Plane Function (UPF) and the gNB Distributed Unit (gNB-DU) and vice versa. For transmissions on the RAN 506 front-end (e.g., implemented as an Enhanced Common Radio Interface (eCPRI)) and across radio interfaces, the Dedicated Radio Bearer (DRB) for user plane transmissions can be configured by the control plane RAN506 gNB Central Unit (gNB-CU CP). The RRC protocol can be used to establish this DRB. Using virtualization, different protocol layers for the air interface can be distributed, and the gNB-DU controls lower-layer PHY / RLC / MAC parameters (e.g., c-RNTI), while the gNB-CU CP assigns higher-layer parameters for PDCP and RRC, such as DRB-ID. Since the gNB-CU CP can send downlink RRC messages to the UE, lower-layer parameters from the DU can be sent to the gNB-CU CP first in the uplink direction. Figure 5 In the example, a low latency stream can be mapped to a QFI stream 512 and a DRB, where the QFI stream and DRB are shared with other traffic, as shown in box 514.

[0076] Figure 6 Another simplified block diagram of a wireless system 600 for mapping low latency streams, according to some aspects of this disclosure, is illustrated. The wireless system 600 is similar to the combination described above. Figure 5 The wireless system 500 under discussion includes an application processor 602, a UE 604, a RAN 606, and a core network 608. In this example, low latency TFT filtering is performed in 610, and all low latency streams are mapped to one or more disparate QFI streams 614; however, with... Figure 5 Unlike the example in 612, the QFI stream in 612 is mapped to a single DRB, which is shared with other traffic.

[0077] Figure 7Another simplified block diagram of a wireless system 700 for mapping low latency streams, according to some aspects of this disclosure, is illustrated. The wireless system 700 is also similar to the combination described above. Figure 5 The wireless system 500 under discussion includes an application processor 702, a UE 704, a RAN 706, and a core network 708. In this example, low latency TFT filtering is performed in 710, and the low latency stream can be mapped to a QFI stream 714 and a DRB 712; however, this QFI stream and DRB are not shared with other traffic, such as... Figure 5 As shown in the figure.

[0078] Since PDCP-OOOD can lead to poor performance of non-latency traffic (e.g., TCP), performance mitigation can be achieved by subjecting only low-latency traffic to PDCP-OOOD. In some examples, PDCP-OOOD can be activated / deactivated for downlink traffic between the UE PDCP and the application layer, regardless of how low-latency traffic is mapped. The application client can be configured to allow the UE (e.g., 502, 602, 702) to determine whether the PDCP layer can deliver packets out of order, without direct control from the RAN (e.g., 506, 606, 706).

[0079] Figure 8 This is a block diagram illustrating an example of a hardware implementation of a scheduled entity 800 using a processing system 814. For example, the scheduled entity 800 may be as disclosed herein. Figure 1 , 2 User equipment (UE) explained in any one or more of 4.

[0080] The scheduled entity 800 may be implemented using a processing system 814 (or “processing device”) including one or more processors 804. Examples of processors 804 include microprocessors, microcontrollers, digital signal processors (DSPs), field-programmable gate arrays (FPGAs), programmable logic devices (PLDs), state machines, gated logic, discrete hardware circuits, and other suitable hardware configured to perform the various functionalities described throughout this disclosure. In various examples, the scheduled entity 800 may be configured to perform any or more of the functions described herein. That is, the processor 804 utilized in the scheduled entity 800 may be used to implement any or more of the processes and procedures described below. In some instances, the processor 804 may be implemented via a baseband or modem chip, while in other implementations, the processor 804 itself may include several devices that are different from and distinct from the baseband or modem chip (e.g., in such scenarios they may work together to achieve the examples discussed herein). Furthermore, as mentioned above, various hardware arrangements and components other than the baseband modem processor can be used in the implementation, including RF chains, power amplifiers, modulators, buffers 815, interleavers, adders / summers, etc.

[0081] In this example, the processing system 814 can be implemented using a bus architecture generally represented by bus 802. Depending on the specific application and overall design constraints of the processing system 814, bus 802 may include any number of interconnect buses and bridges. Bus 802 communicatively couples together various circuits including one or more processors (generally represented by processor 804), memory 805, and computer-readable media (generally represented by computer-readable media 806). Bus 802 may also link various other circuits, such as timing sources, peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further. Bus interface 808 provides an interface between bus 802 and transceiver 810. Transceiver 810 provides a communication interface or means for communicating with various other devices over a transmission medium. Depending on the characteristics of the device, a user interface 812 (e.g., keypad, display, speaker, microphone, joystick) may also be optionally provided.

[0082] Processor 804 is responsible for managing bus 802 and general processing, including the execution of software stored on computer-readable medium 806. When executed by processor 804, the software causes processing system 814 to perform various functions described below for any particular device. Computer-readable medium 806 and memory 805 may also be used to store data manipulated by processor 804 during software execution.

[0083] One or more processors 804 in the processing system can execute software. Software should be broadly interpreted as instructions, instruction sets, code, code segments, program code, programs, subroutines, software modules, applications, software applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description languages, or other terms. Software may reside on a computer-readable medium 806.

[0084] Computer-readable medium 806 may be a non-transitory computer-readable medium. As examples, non-transitory computer-readable media include magnetic storage devices (e.g., hard disks, floppy disks, magnetic tapes), optical disks (e.g., compact discs (CDs) or digital multi-purpose discs (DVDs)), smart cards, flash memory devices (e.g., cards, sticks, or key-type drives), random access memory (RAM), read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), registers, removable disks, and any other suitable medium for storing software and / or instructions accessible and readable by a computer. As examples, computer-readable media may also include carrier waves, transmission lines, and any other suitable medium for transmitting software and / or instructions accessible and readable by a computer. Computer-readable medium 806 may reside in processing system 814, be external to processing system 814, or be distributed across multiple entities including processing system 814. Computer-readable medium 806 may be implemented in a computer program product. In some examples, computer-readable medium 806 may be part of memory 805. As an example, a computer program product may include a computer-readable medium within encapsulated material. Those skilled in the art will recognize how the functionality described throughout this disclosure can be optimally implemented, depending on the specific application and the overall design constraints imposed on the system as a whole.

[0085] In some aspects of this disclosure, processor 804 may include circuitry configured for various functions. For example, processor 804 may include a communication and processing circuitry system 841 configured to communicate with a base station (e.g., a gNB or eNB) via a Uu link. In some examples, communication and processing circuitry system 841 may include one or more hardware components providing a physical structure for performing processes related to wireless communication (e.g., signal reception and / or signal transmission) and signal processing (e.g., processing received signals and / or processing signals for transmission). For example, communication and processing circuitry system 841 may include one or more transmit / receive chains.

[0086] In some implementations where communication involves receiving information, communication and processing circuitry system 841 may obtain information from components of a wireless communication device (e.g., a transceiver 810 that receives information via radio frequency signaling or some other type of signaling suitable for the applicable communication medium), process (e.g., decode) the information, and output the processed information. For example, communication and processing circuitry system 841 may output information to another component of processor 804, to memory 805, or to bus interface 808. In some examples, communication and processing circuitry system 841 may receive one or more of signals, messages, other information, or any combination thereof. In some examples, communication and processing circuitry system 841 may receive information via one or more channels. In some examples, communication and processing circuitry system 841 may include the functionality of means for receiving. In some examples, communication and processing circuitry system 841 may include the functionality of means for processing, including means for demodulation, means for decoding, etc.

[0087] In some implementations where communication involves sending (e.g., transmitting) information, communication and processing circuitry system 841 may (e.g., from another component among processor 804, memory 805, or bus interface 808) obtain information, process (e.g., modulate, encode, etc.) the information, and output the processed information. For example, communication and processing circuitry system 841 may output information to transceiver 810 (e.g., to transmit information via radio frequency signaling or some other type of signaling suitable for the applicable communication medium). In some examples, communication and processing circuitry system 841 may send one or more of signals, messages, other information, or any combination thereof. In some examples, communication and processing circuitry system 841 may send information via one or more channels. In some examples, communication and processing circuitry system 841 may include the functionality of means for sending (e.g., means for transmitting). In some examples, communication and processing circuitry system 841 may include the functionality of means for generating, including means for modulation, means for encoding, etc.

[0088] In some examples, the communication and processing circuitry 841 may be configured to transmit (e.g., transmit / receive) beamformed signals at millimeter-wave frequencies or sub-6 GHz frequencies via a transceiver 810 and an antenna array (not shown). The communication and processing circuitry 841 may be further configured to execute communication and processing instructions (software) 851 stored in a computer-readable medium 806 to perform one or more of the functions described herein.

[0089] In some aspects of this disclosure, processor 804 may also include additional circuitry configured for various functions. For example, processor 804 may include flow management circuitry 842, which may operate independently or in conjunction with communication and processing circuitry 841 to establish one or more PDU sessions comprising one or more data flows associated with one or more application sets, according to QoS profiles and rules. As discussed above, QoS profiles may include one or more QoS parameters specifying QoS characteristics. Flow management circuitry 842 may also be configured with application clients to process and map low latency flows and perform TFT filtering and packet filtering, as described above. Traffic flow template information elements may be used by flow management circuitry 842 to specify TFT parameters and operations for the PDP context, and the information elements may be used to pass additional parameters to the network. Flow management circuitry 842 may be further configured to perform flow management (software) 852 stored in computer-readable medium 806 to implement one or more of the functions described herein.

[0090] Figure 9 This is a conceptual diagram illustrating an example hardware implementation of an exemplary scheduling entity 900 employing a processing system 914. According to various aspects of this disclosure, elements, any part of elements, or any combination of elements can be implemented using a processing system 914 including one or more processors 904. For example, the scheduling entity 900 can be as follows: Figure 1 , 2 The base station explained in any one or more of 4-7.

[0091] Processing system 914 can be with Figure 9 The processing system 914 described above is essentially the same, including a bus interface 908, a bus 902, a memory 905, a processor 904, and a computer-readable medium 906. Furthermore, the scheduling entity 900 may include components similar to those described above. Figure 8 The user interfaces and transceivers described herein are substantially similar to those of optional user interface 912 and transceiver 910. That is, processor 904, as utilized in scheduling entity 900, can be used to implement any one or more of the processes described herein.

[0092] In some aspects, processor 904 may include communication and processing circuitry 941, which may be combined with the above. Figure 8 The described circuit system 841 is similarly configured. The communication and processing circuit system 941 may be further configured to execute communication and processing instructions (software) 951 stored in the computer-readable medium 906 to implement one or more of the functions described herein.

[0093] In some aspects of this disclosure, processor 904 may also include additional circuitry configured for various functions. For example, processor 904 may include flow management circuitry 942, which may operate independently or in conjunction with communication and processing circuitry 941 to establish one or more PDU sessions comprising one or more data flows according to QoS profiles and rules. As discussed above, QoS profiles may include one or more QoS parameters specifying QoS characteristics. Flow management circuitry 942 may also handle traffic mapping and packet filtering, and may further communicate payload data to scheduled entities, other scheduled entities, and / or the core network. Low latency flows may also be mapped to QFI flows and DRBs. Flow management circuitry 942 may be further configured to perform flow management (software) 952 stored in computer-readable medium 906 to implement one or more of the functions described herein.

[0094] Figure 10 A method 1000 for activating PDCP-OOOD for a UE according to some aspects of the present invention is described. In block 1002, the UE can execute an API whose operation is to classify and / or designate one or more IP flows as one or more sets of PDCP-OOOD flows. For example, the above combined... Figure 8 The communication and processing circuitry system 841 and the flow management circuitry system 842 shown and described provide means for setting one or more configuration parameters from a wireless network and for classifying and / or designating one or more IP flows as one or more sets of PDCP-OOOD flows.

[0095] In box 1004, this API determines the IP flow associated with the default radio bearer or a dedicated radio bearer provided by the application. For example, the above combined Figure 8 The communication and processing circuitry 841 and the flow management circuitry 842 shown and described provide means for determining IP flows associated with a default radio bearer or a dedicated radio bearer provided by an application.

[0096] In box 1006, the API may alternatively or additionally determine the IP flow associated with the TFT provided by the application. For example, the above combination Figure 8 The communication and processing circuitry system 841 and the flow management circuitry system 842 shown and described provide means for determining the IP flow associated with the TFT provided by the application.

[0097] In box 1008, this API can alternatively or additionally determine the IP flow associated with the QFI provided by the application on the default RB or dedicated RB. For example, the above combined Figure 8The communication and processing circuitry system 841 and the flow management circuitry system 842 shown and described provide means for determining the IP flow associated with the QFI provided by the application on the default RB or the dedicated RB.

[0098] The API can then determine one or more configuration parameters for each set of PDCP-OOOD flows. These parameters indicate whether to enable PDCP-OOOD using a network-configured flag via RRC or using UE-side PDCP-OOOD configuration. Under these configurations, the UE API can selectively configure PDCP-OOOD for activation based on API determination using any or all of the configuration parameters for the PDCP-OOOD flow. For example, the above combination Figure 8 The communication and processing circuitry 841 and the flow management circuitry 842 shown and described may provide means for determining one or more configuration parameters for each set of PDCP-OOOD flows, the one or more configuration parameters indicating whether to enable the use of network-configured RRC flags for PDCP-OOOD or to use UE-side PDCP-OOOD configuration.

[0099] Once PDCP-OOOD is activated, the UE can continue to monitor data via API to determine whether PDCP-OOOD is affecting transmission performance, and if so, disable or deactivate PDCP-OOOD. Figure 11 Method 1100 for measuring and detecting TCP traffic characteristics on the DRB according to some aspects of this disclosure for implementing UE-based PDCP-OOOD control is described. In block 1102, the API detects TCP traffic on the DRM and in block 1104 measures whether the downlink TCP throughput on the DRB is higher or lower than a configured threshold. For example, the above combined Figure 8 The communication and processing circuitry system 841 and the flow management circuitry system 842 shown and described provide means for detecting TCP traffic on the DRM and measuring whether the downlink TCP throughput on the DRB is above or below a configured threshold.

[0100] Alternatively or additionally, the API may measure the number (proportion) of duplicate TCP data acknowledgments (ACKs) in box 1106 and determine whether the number of duplicate ACKs is higher or lower than a configured threshold. In box 1108, if either or both of TCP throughput and / or duplicate TCP ACKs exceed their respective configured thresholds, the UE API disables PDCP-OOOD. Accordingly, in cases where TCP exists on a bearer mapped to out-of-order delivery, the UE modem and API will utilize throughput and duplicate TCP ACK measurements to determine whether to enable out-of-order delivery. Such configuration can mitigate or avoid TCP performance degradation through out-of-order data delivery. For example, the above combined... Figure 8 The communication and processing circuitry 841 and the flow management circuitry 842 shown and described provide means for measuring duplicate TCP data ACKs and determining whether the number of duplicates is higher or lower than a configured threshold, and for disabling PDCP-OOOD if either or both of TCP throughput and duplicate TCP ACKs are higher than their respective configured thresholds(s).

[0101] Figure 11 A method 1100 for a UE to communicate with a wireless network according to some aspects of this disclosure is described. In block 1102, the UE can execute an API to set one or more configuration parameters from the wireless network. For example, in combination with the above... Figure 8 The communication and processing circuitry 841 and the flow management circuitry 842 shown and described provide means for executing APIs to set one or more configuration parameters from a wireless network.

[0102] In box 1104, the UE may identify data from the wireless network matching the one or more configuration parameters via the API. In some examples, identifying data from the wireless network may include identifying one or more Internet Protocol (IP) flows from the wireless network matching the one or more configuration parameters. Identifying one or more IP flows may include measuring one or more IP flows from a default resource bearer provided by the wireless network. In some examples, identifying one or more IP flows may include identifying all IP flows sharing a resource bearer provided by the API among the one or more IP flows. In some examples, identifying one or more IP flows may include measuring one or more IP flows associated with a traffic flow template (TFT) provided by one or more APIs. In some examples, identifying one or more IP flows may include measuring one or more IP flows associated with a Quality of Service Flow Indicator (QFI) provided by one or more APIs on either a default resource bearer provided by the wireless network or a resource bearer provided by the API. For example, the above combined Figure 8The communication and processing circuitry 841 and the flow management circuitry 842 shown and described provide means for identifying data from a wireless network that matches one or more configuration parameters via an API.

[0103] In box 1106, the UE can activate out-of-order delivery (OOOD) for data from the wireless network that matches one or more configuration parameters via the API. In some examples, activating out-of-order delivery for data may include activating Packet Data Convergence Protocol (PDCP) OOOD. In some examples, activating out-of-order delivery for data may include using a first flag indicating that OOOD activation conforms to the wireless network configuration, and / or using a second flag indicating that OOOD activation conforms to the configuration provided by the API. In some examples, OOOD may be deactivated in response to downlink transmission control protocol (TCP) throughput on the bearer meeting or exceeding a configured threshold and / or in response to the number of repeated downlink transmission control protocol (TCP) acknowledgments (ACKs) meeting or exceeding a configured threshold. For example, the above combined Figure 8 The communication and processing circuitry 841 and the flow management circuitry 842 shown and described provide means for activating and / or deactivating OOOD for data matching one or more configuration parameters from a wireless network via an API.

[0104] Of course, in the above examples, the circuitry included in processor 804 is merely provided as an example, and other means for performing the described functions may be included within various aspects of this disclosure, including but not limited to instructions stored in computer-readable storage medium 806, or... Figure 1 , 2 Described in any of 4-7 and / or 9 and using, for example, the text concerning... Figure 10-11 Any other suitable equipment or apparatus for the described process and / or algorithm.

[0105] Figure 10 and 11 The processes shown may include additional aspects, such as any single aspect or any combination of aspects described below and / or in conjunction with one or more other processes described elsewhere in this document.

[0106] Aspect 1: A method for a user equipment (UE) to communicate with a wireless network, comprising: executing an application programming interface (API) in the UE to set one or more configuration parameters from the wireless network; identifying data from the wireless network matching the one or more configuration parameters via the API; and activating out-of-order delivery (OOOD) of the data from the wireless network matching the one or more configuration parameters via the API.

[0107] Aspect 2: The method of aspect 1, wherein identifying data from the wireless network includes identifying one or more Internet Protocol (IP) flows from the wireless network that match the one or more configuration parameters.

[0108] Aspect 3: The method of Aspect 1 and / or 2, wherein identifying the one or more IP flows includes measuring one or more IP flows carried by the default resources provided by the wireless network.

[0109] Aspect 4: The method of any of Aspects 1, 2 and / or 3, wherein identifying the one or more IP flows includes identifying all IP flows carried by resources provided by a shared API in the one or more IP flows.

[0110] Aspect 5: The method of any of Aspects 1-3 and / or 4, wherein identifying the one or more IP flows includes measuring one or more IP flows associated with a traffic flow template (TFT) provided by one or more APIs.

[0111] Aspect 6: The method of any of Aspects 1-4 and / or 5, wherein identifying the one or more IP flows includes measuring one or more IP flows associated with one or more Quality of Service Flow Indicators (QFIs) provided by one or more APIs on one of the default resource bearers provided by the wireless network or the resource bearers provided by the API.

[0112] Aspect 7: The method of any of Aspects 1-5 and / or 6, wherein activating the out-of-order delivery of the data includes activating the Packet Data Convergence Protocol (PDCP) OOOD.

[0113] Aspect 8: The method of any of Aspects 1-6 and / or 7, wherein activating out-of-order delivery of the data includes using a first flag indicating that OOOD activates in accordance with the wireless network configuration.

[0114] Aspect 9: The method of any of Aspects 1-7 and / or 8, wherein activating the out-of-order delivery of the data includes using a second flag indicating that OOOD activation follows the configuration provided by the API.

[0115] Aspect 10: The method of any of Aspects 1-8 and / or 9 further includes disabling OOOD in response to downlink transmission control protocol (TCP) throughput on the bearer meeting or exceeding a configured threshold.

[0116] Aspect 11: The method of any of Aspects 1-9 and / or 10 further includes disabling OOOD in response to the number of repeated downlink transmission control protocol (TCP) acknowledgments (ACKs) meeting or exceeding a configured threshold.

[0117] Aspect 12: A user equipment (UE) in a wireless network, comprising: a transceiver, a memory, and a processor coupled to the transceiver and the memory, the processor and the memory being configured to perform a method as described in any of Aspects 1 to 11.

[0118] Aspect 13: A user equipment (UE) in a wireless network, comprising: means for executing an application programming interface (API) in the UE to set one or more configuration parameters from the wireless network; means for identifying data from the wireless network matching the one or more configuration parameters via the API; and means for activating out-of-order delivery (OOOD) of the data from the wireless network matching the one or more configuration parameters via the API.

[0119] Aspect 14: The UE of aspect 13, wherein the means for identifying data from the wireless network includes means for identifying one or more Internet Protocol (IP) flows from the wireless network that match the one or more configuration parameters.

[0120] Aspect 15: The UE of aspects 13 and / or 14, wherein the means for identifying the IP flow includes one of the following: means for measuring one or more IP flows from a default resource bearer provided by the wireless network, means for identifying all IP flows of the one or more IP flows that share a resource bearer provided by an API, or means for measuring one or more IP flows associated with a traffic flow template (TFT) provided by one or more APIs.

[0121] Aspect 16: UE of any of Aspects 13, 14 and / or 15, wherein the means for identifying the one or more IP flows includes means for measuring one or more IP flows associated with one or more Quality of Service Flow Indicators (QFIs) provided by one or more APIs on one of the default resource bearers provided by the wireless network or the resource bearers provided by the API.

[0122] Aspect 17: UE of any of Aspects 13-15 and / or 16, wherein means for activating out-of-order delivery of data includes means for activating Packet Data Convergence Protocol (PDCP) OOOD.

[0123] Aspect 18: For any of Aspects 13-16 and / or 17, the means for activating out-of-order delivery of data includes one of the following: means for activating a first flag indicating OOOD to comply with the wireless network configuration, or means for activating a second flag indicating OOOD to comply with the configuration provided by the API.

[0124] Aspect 19: The UE of any of Aspects 13-17 and / or 18 further includes means for disabling OOOD in response to downlink transmission control protocol (TCP) throughput on the bearer meeting or exceeding a configured threshold.

[0125] Aspect 20: A non-transient computer-readable medium storing instructions that can be executed by one or more processors of a user equipment (UE) in a wireless communication network to perform any of the methods of aspects 1 to 11.

[0126] Several aspects of wireless communication networks have been described with reference to exemplary implementations. As will be readily apparent to those skilled in the art, the various aspects described herein can be extended to other telecommunications systems, network architectures, and communication standards.

[0127] As examples, various aspects can be implemented within other systems defined by 3GPP, such as Long Term Evolution (LTE), Evolved Packet System (EPS), Universal Mobile Telecommunications System (UMTS), and / or Global System for Mobile Communications (GSM). These aspects can also be extended to systems defined by 3GPP2 (3GPP2), such as CDMA2000 and / or Evolved Data Optimized (EV-DO). Other examples can be implemented within systems employing IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Ultra Wideband (UWB), Bluetooth, and / or other suitable systems. The actual telecommunications standards, network architecture, and / or communication standards employed will depend on the specific application and the overall design constraints imposed on the system.

[0128] Within this disclosure, the term "exemplary" is used to mean "serving as an example, instance, or illustration." Any implementation or aspect described herein as "exemplary" need not be construed as superior to or better than other aspects of this disclosure. Similarly, the term "aspect" does not require that all aspects of this disclosure include the features, advantages, or modes of operation discussed. The term "coupling" is used herein to refer to direct or indirect coupling between two objects. For example, if object A physically contacts object B, and object B contacts object C, then objects A and C can still be considered coupled to each other—even if they are not in direct physical contact. For example, a first object can be coupled to a second object, even if the first object never directly contacts the second object. The terms "circuit" and "circuit system" are used broadly and are intended to include both hardware implementations of electronic devices and conductors, and software implementations of information and instructions, which, when connected and configured, enable the performance of the functions described in this disclosure, without limitation on the type of electronic circuit, and which, when executed by a processor, enable the performance of the functions described in this disclosure.

[0129] Figure 1-11 One or more of the components, steps, features, and / or functions described herein may be rearranged and / or combined into a single component, step, feature, or function, or may be implemented in several components, steps, or functions. Additional elements, components, steps, and / or functions may also be added without departing from the novel features disclosed herein. Figure 1 , 2 The apparatus, devices, and / or components described in 4-9 may be configured to perform one or more of the methods, features, or steps described herein. The novel algorithms described herein may also be efficiently implemented in software and / or embedded in hardware.

[0130] It should be understood that the specific order or hierarchy of the steps in the disclosed methods is an illustration of an exemplary process. Based on design preferences, it will be understood that the specific order or hierarchy of the steps in these methods can be rearranged. The appended method claims present the elements of various steps in a sample order and are not intended to be limited to the specific order or hierarchy presented, unless specifically stated herein.

[0131] The preceding description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will readily be understood by those skilled in the art, and the universal principles defined herein may be applied to other aspects. Therefore, the claims are not intended to be limited to the aspects shown herein, but are to be granted the full scope consistent with the language of the claims, wherein references to the singular form of an element are not intended to mean “one and only one”—unless specifically stated otherwise—but are intended to mean “one or more.” Unless specifically stated otherwise, the term “some / a” refers to one or more. The phrase “at least one of” referring to a list of items refers to any combination of these items, including a single member. As an example, “at least one of a, b, or c” is intended to cover: a; b; c; a and b; a and c; b and c; and a, b, and c. All structural and functional equivalents of the aspects described throughout this disclosure that are currently or hereafter known to a person skilled in the art are expressly incorporated herein by reference and are intended to be covered by the claims. Furthermore, nothing disclosed herein is intended to be donated to the public, whether or not such disclosure is expressly stated in the claims.

Claims

1. A method for user equipment (UE) to communicate with a wireless network, comprising: The UE executes an application programming interface (API) to set one or more configuration parameters for data received from the wireless network; The data received from the wireless network that matches one or more configuration parameters set via the API; as well as Selectively activate out-of-order delivery (OOOD) of data received from the wireless network that matches one or more configuration parameters set via the API to the upper layer.

2. The method of claim 1, wherein identifying the data received from the wireless network includes: Identify one or more Internet Protocol (IP) flows from the wireless network that match one or more configuration parameters.

3. The method of claim 2, wherein identifying the one or more IP flows includes measuring one or more IP flows originating from a default resource bearer provided by the wireless network.

4. The method of claim 2, wherein identifying the one or more IP flows includes identifying all IP flows carrying resources provided by a shared API within the one or more IP flows.

5. The method of claim 2, wherein identifying the one or more IP flows includes measuring one or more IP flows associated with a traffic flow template (TFT) provided by one or more APIs.

6. The method of claim 2, wherein identifying the one or more IP flows includes measuring one or more IP flows associated with one or more Quality of Service Flow Indicators (QFIs) provided by one or more APIs on either a default resource bearer provided by the wireless network or a resource bearer provided by an API.

7. The method of claim 1, wherein activating out-of-order delivery of the data comprises activating Packet Data Convergence Protocol (PDCP) OOOD.

8. The method of claim 1, wherein activating out-of-order delivery of the data includes using a first flag indicating that OOOD activates in accordance with the wireless network configuration.

9. The method of claim 1, wherein activating out-of-order delivery of the data includes using a second flag indicating that OOOD activation follows a configuration provided by the API.

10. The method of claim 1, further comprising disabling OOOD in response to downlink transmission control protocol (TCP) throughput on the bearer meeting or exceeding a configured threshold.

11. The method of claim 1, further comprising disabling OOOD in response to the number of repeated downlink transmission control protocol (TCP) acknowledgments (ACKs) meeting or exceeding a configured threshold.

12. The method of claim 1, wherein the one or more configuration parameters indicate whether to use radio network out-of-order delivery (OOOD) configuration or UE-side OOOD configuration; and Selectively activating OOOD to the upper layer includes using either the wireless network OOOD configuration or the UE-side OOOD configuration.

13. A user equipment (UE) in a wireless communication network, comprising: Wireless transceiver; Memory; as well as A processor communicatively coupled to the wireless transceiver and the memory, wherein the processor and the memory are configured to: The UE executes an application programming interface (API) to set one or more configuration parameters for data received from the wireless network; The data received from the wireless network that matches one or more configuration parameters set via the API; as well as Selectively activate out-of-order delivery (OOOD) of data received from the wireless network that matches one or more configuration parameters set via the API to the upper layer.

14. The UE of claim 13, wherein the processor and the memory are further configured to: identify one or more Internet Protocol (IP) flows from the wireless network that match the one or more configuration parameters.

15. The UE of claim 14, wherein the processor and the memory are configured to: identify that the one or more IP flows include measurements of one or more IP flows derived from a default resource bearer provided by the wireless network.

16. The UE of claim 14, wherein the processor and the memory are configured to: identify the one or more IP flows by identifying all IP flows carried by resources provided by a shared API in the one or more IP flows.

17. The UE of claim 14, wherein the processor and the memory are configured to identify the one or more IP flows by measuring one or more IP flows associated with a traffic flow template (TFT) provided by one or more APIs.

18. The UE of claim 14, wherein the processor and the memory are configured to identify the one or more IP flows by measuring one or more IP flows associated with one or more Quality of Service Flow Indicators (QFIs) provided by one or more APIs on one of the default resource bearers provided by the wireless network or resource bearers provided by APIs.

19. The UE of claim 13, wherein the processor and the memory are configured to activate out-of-order delivery of data by activating Packet Data Convergence Protocol (PDCP) OOOD.

20. The UE of claim 13, wherein the processor and the memory are configured to activate out-of-order delivery of data by using a first flag indicating that OOOD activation follows the wireless network configuration.

21. The UE of claim 13, wherein the processor and the memory are configured to activate out-of-order delivery of data by using a second flag indicating that OOOD activation follows the configuration provided by the API.

22. The UE of claim 13, wherein the processor and the memory are configured to: determine whether the number of duplicate TCPACKs meets or exceeds a configured threshold.

23. The UE of claim 13, wherein the processor and the memory are configured to disable OOOD in response to the number of repeated downlink transmission control protocol (TCP) acknowledgments (ACKs) meeting or exceeding a configured threshold.

24. A user equipment (UE) in a wireless network, comprising: A means for executing an application programming interface (API) in the UE to set one or more configuration parameters for data received from the wireless network; A means for identifying data received from the wireless network that matches one or more configuration parameters set via the API; as well as A means for selectively activating out-of-order delivery (OOOD) of data received from the wireless network that matches one or more configuration parameters set via the API to an upper layer.

25. The UE of claim 24, wherein the means for identifying the data received from the wireless network comprises: A means for identifying one or more Internet Protocol (IP) flows from the wireless network that match one or more configuration parameters.

26. The UE of claim 25, wherein the means for identifying the IP flow comprises one of the following: A means for measuring one or more IP streams from the default resource bearer provided by the wireless network. A means for identifying all IP flows carried by resources provided by a shared API in one or more IP flows, or A means for measuring one or more IP flows associated with a traffic flow template (TFT) provided by one or more APIs.

27. The UE of claim 25, wherein the means for identifying the one or more IP flows includes means for measuring one or more IP flows associated with one or more Quality of Service Flow Indicators (QFIs) provided by one or more APIs on one of a default resource bearer provided by the wireless network or a resource bearer provided by an API.

28. The UE of claim 24, wherein the means for activating out-of-order delivery of data includes means for activating Packet Data Convergence Protocol (PDCP) OOOD.

29. The UE of claim 24, wherein the means for activating out-of-order delivery of data comprises one of the following: A device for activating a first flag that follows the wireless network configuration using an indication OOOD; or A means for using an instruction OOOD to activate a second flag that follows the configuration provided by the API.

30. The UE of claim 24, further comprising means for disabling OOOD in response to downlink transmission control protocol (TCP) throughput on the bearer meeting or exceeding a configured threshold.

31. The UE of claim 24, wherein the one or more configuration parameters indicate whether to use radio network out-of-order delivery (OOOD) configuration or UE-side OOOD configuration; and The means for selectively activating OOOD to the upper layer includes means for using either the wireless network OOOD configuration or the UE-side OOOD configuration.

32. A non-transitory computer-readable medium storing instructions executable by one or more processors of a user equipment (UE) in a wireless communication network to perform the following operations: The UE executes an application programming interface (API) to set one or more configuration parameters for data received from the wireless network; The data received from the wireless network that matches one or more configuration parameters set via the API; as well as Selectively activate out-of-order delivery (OOOD) of data received from the wireless network that matches one or more configuration parameters set via the API to the upper layer.

Images