Latency aware scheduling of packet transmissions

Abstract

An application running on a user equipment determines a retransmission request indication for packets that are not successfully decoded based on critical or quality of service requirements from a retransmission request configuration that may correspond to traffic flows managed by the user equipment. The retransmission request indication may correspond to a standard range in a retransmission request configuration. An application at a user equipment may determine a latency criterion range for determining a retransmission request indication based on a perceived degradation of a user experience corresponding to a traffic flow. The user equipment may send a retransmission request indication to a network node, which may prioritize a schedule of retransmission of packets that fail to decode or transmission of new packets according to a priority indicated in the retransmission request indication. The combination of retransmission request indications may be indicated by a compression index determined by the user equipment.

Description

[0001] Related applications

[0002] This application claims priority to U.S. non-provisional patent application No. 18 / 073,063, filed on December 1, 2022, entitled “LATENCY-AWARE SCHEDULING OF PACKET TRANSMISSION,” the entire contents of which are incorporated herein by reference. Background Art

[0003] The term "New Radio" (NR), associated with fifth-generation mobile wireless communication systems ("5G"), refers to aspects of technology used in wireless radio access networks ("RAN") that include several Quality of Service (QoS) categories, including Ultra-Reliable Low Latency Communication ("URLLC"), enhanced Mobile Broadband ("eMBB"), and Massive Machine Type Communication ("mMTC"). The URLLC QoS category is associated with strict latency requirements (e.g., low latency or low signal / message delay) and high reliability of radio performance, while traditional eMBB use cases may be associated with high-capacity wireless communications, which may allow for less stringent latency requirements (e.g., higher latency than URLLC) and less reliable radio performance than URLLC. The performance requirements of mMTC may be lower than those of eMBB use cases. Some use case applications involving mobile devices or mobile user equipment (such as smartphones, wireless tablets, smartwatches, etc.) may impose varying loads or demands on a given RAN resource. Summary of the Invention

[0004] The following is a brief overview of the disclosed subject matter to provide a basic understanding of some of the various embodiments. This summary is not an extensive overview of the various embodiments. It is not intended to identify key elements of the various embodiments nor to delineate the scope of the various embodiments. Its sole purpose is to present some concepts of the disclosure in a concise form as a prelude to the more detailed description that will be presented later.

[0005] In an example embodiment, a method includes: receiving, by a user equipment including a processor, retransmission request configuration data representing a retransmission request configuration via a radio access network. In this example embodiment, the user equipment may receive a first portion of a traffic flow; determine that the first portion of the traffic flow includes a first error; and determine a first quality of service corresponding to the traffic flow. Determining the quality of service may be based on performance of an application using data of the traffic flow. The example method may also include: analyzing, by the user equipment, the first quality of service with respect to at least one delay function specified by the retransmission request configuration to obtain an analyzed first quality of service; determining, by the user equipment, using the retransmission request configuration, a first retransmission request indication corresponding to the analyzed first quality of service; transmitting, by the user equipment, via the radio access network, a first retransmission request indication indicating a first retransmission priority for retransmissions of the first portion of the traffic flow; and / or receiving, by the user equipment, in response to the first retransmission request indication, first retransmission data indicating a first retransmission of the first portion of the traffic flow according to the first retransmission priority. The network RAN ​​may use the retransmission request indication to determine a priority corresponding to the analyzed quality of service as determined by the user equipment to determine scheduling of the first retransmission, and may transmit scheduling information to the user equipment indicating to the user equipment a resource to monitor for retransmission of packets containing errors.

[0006] Analyzing the first quality of service includes analyzing the quality of service of an application executed on the user equipment to which the traffic flow is directed. The first retransmission request indication includes a hybrid automatic repeat request.

[0007] The retransmission request configuration may associate or map at least one retransmission request indication index value with at least one corresponding retransmission request range. The first retransmission request indication may include a retransmission request indication index value, one of the at least one retransmission request indication index values, corresponding to a retransmission request range corresponding to the analyzed first quality of service in the at least one retransmission request range. The at least one delay function may include at least one corresponding delay range criterion. The size of the retransmission request indication may correspond inversely to the number of the at least one delay function specified by the retransmission request configuration.

[0008] The example embodiment method may also include receiving, by the user device, a second portion of the traffic flow. The user device may determine that the second portion of the traffic flow includes a second error, determine a second quality of service corresponding to the second portion of the traffic flow, and analyze the second quality of service with respect to at least one delay function specified by the retransmission request configuration to obtain an analyzed second quality of service. The example method may also include determining, by the user device, a second retransmission request indication corresponding to the analyzed second quality of service based on the retransmission request configuration. Therefore, the second portion of the traffic flow may require a different delay for retransmission of the erroneous portion than the delay required for retransmission of the erroneous first portion. This difference may be determined at the user device based on a change in the user experience of processing of the traffic flow detected by the application.

[0009] The example embodiment method may further include transmitting, by the user equipment via the radio access network, a second retransmission request indication indicating a second retransmission priority for retransmission of the second portion of the traffic flow. The example embodiment method may further include receiving, by the user equipment, in response to the second retransmission request indication, second retransmission data indicating a second retransmission of the second portion of the traffic flow according to the second retransmission priority, wherein the second retransmission priority is different from the first retransmission priority.

[0010] In one embodiment, an example method may include: receiving, by a user device, a third portion of a service flow; determining, by the user device, that the third portion of the service flow includes a third error; determining, by the user device, a third quality of service corresponding to the third portion of the service flow; analyzing, by the user device, the third quality of service with respect to at least one delay function specified by a retransmission request configuration to obtain an analyzed third quality of service; determining, by the user device, a no-retransmission acknowledgment indication (e.g., ACK) corresponding to the third quality of service from the retransmission request configuration; and / or transmitting the no-retransmission acknowledgment indication via a radio access network.

[0011] In one embodiment, in the retransmission request configuration, the first retransmission priority and the second retransmission priority correspond to traffic having a first importance and a second importance according to a defined importance criterion, respectively, and wherein the first retransmission priority and the second retransmission priority are higher than a default retransmission priority associated with a default retransmission request indication. The default retransmission request indication may include a one-bit indication.

[0012] In another embodiment, the retransmission request configuration data representing the retransmission request configuration may include retransmission request indication compression configuration data representing a retransmission request indication compression configuration, wherein the retransmission request indication compression configuration associates at least one compression index with at least one corresponding combination of a determined number of retransmission request indications, the determined number of retransmission request indications corresponding to a determined number of packet receptions for which the user equipment is to send a retransmission request indication or an acknowledgment indication. The determined number of retransmission request indications may define a compression period. The determined number of packet receptions may include the compression period.

[0013] In another exemplary embodiment, a user equipment (UE) includes a processor configured to: receive a first portion of a first traffic flow via a radio access network, determine that the first portion of the first traffic flow includes a first error; receive a second portion of a second traffic flow via the radio access network, and determine that the second portion of the second traffic flow includes a second error. The UE processor may determine a first quality of service (QoS) corresponding to the first traffic flow, determine a second quality of service (QoS) corresponding to the second traffic flow, analyze the first QoS with respect to a first latency range defined by a first retransmission request configuration to obtain an analyzed first QoS, and analyze the second QoS with respect to a second latency range defined by a second retransmission request configuration to obtain an analyzed second QoS.

[0014] The user equipment processor may determine a first retransmission request indication corresponding to the analyzed first quality of service based on the first retransmission request configuration, and determine a second retransmission request indication corresponding to the analyzed second quality of service based on the second retransmission request configuration. Thus, the processor may determine different retransmission request indications using different retransmission request configurations for different corresponding service flows.

[0015] The user equipment processor may transmit, via the radio access network, a first retransmission request indication indicating a first priority associated with the first service flow, and transmit, via the radio access network, a second retransmission request indication indicating a second priority associated with the second service flow. The user equipment processor may receive, via the radio access network in response to the first retransmission request indication, a first retransmission of a first portion of the first service flow according to the first priority, and may receive, via the radio access network in response to the second retransmission request indication, a second retransmission of a second portion of the second service flow according to the second priority. Scheduling of the first and second retransmissions may be scheduled by the RAN based on the first and second priorities.

[0016] The processor may be further configured to receive, via the radio access network, a scheduling indication indicating scheduling of downlink resources to be used for receiving the first retransmission and the second retransmission, and wherein the scheduling of the downlink resources is based on the first priority and the second priority.

[0017] In one embodiment, the user equipment may also be configured to receive a third portion of the first business flow associated with a third priority, wherein the first portion of the first business flow and the second portion of the second business flow are received before the third portion of the first business flow, and wherein, based on the third priority being higher than the first priority and the second priority, the third portion of the first business flow is received before the first retransmission of the first portion of the first business flow is received and before the second retransmission of the second portion of the second business flow is received.

[0018] The first retransmission request configuration may include a first retransmission request indication index corresponding to the first delay range, wherein the second retransmission request configuration includes a second retransmission request indication index corresponding to the second delay range, and wherein each first retransmission request indication index in the first retransmission request indication index includes a first number of digits corresponding to the first priority, and each second retransmission request indication index in the second retransmission request indication index includes a second number of digits corresponding to the second priority. Corresponding to the first priority being higher than the second priority, the first number of digits is higher than the second number of digits.

[0019] In one embodiment, an exemplary non-transitory machine-readable medium may include executable instructions that, when executed by a processor of a user equipment, facilitate performing operations including: receiving a first retransmission request configuration from a network device of a radio access network; receiving a second retransmission request configuration from the network device; receiving a first portion of a first traffic flow; and receiving a second portion of a second traffic flow. The operations may include determining that the first portion of the first traffic flow includes a first error and the second portion of the second traffic flow includes a second error; and determining a first quality of service corresponding to the first portion of the first traffic flow and a second quality of service corresponding to the second portion of the second traffic flow. The operations may also include analyzing the first quality of service with respect to at least one first latency criterion of the first retransmission request configuration to obtain an analyzed first quality of service; and analyzing the second quality of service with respect to at least one second latency criterion of the second retransmission request configuration to obtain an analyzed second quality of service. The operations may also include determining, from the first retransmission request configuration, a first retransmission request corresponding to the analyzed first quality of service and having a first retransmission priority; determining, from the second retransmission request configuration, a second retransmission request corresponding to the analyzed second quality of service and having a second retransmission priority; and transmitting, to the network device, a first retransmission request indication indicating at least the first retransmission request or the second retransmission request.

[0020] In one embodiment of the non-transitory machine-readable medium, the first retransmission request may include a first first retransmission request among a plurality of first retransmission requests represented in a first retransmission request configuration, and each of the plurality of first retransmission requests may include a first number of bits corresponding to a first quality of service. The second retransmission request may include a second second retransmission request among a plurality of second retransmission requests represented in a second retransmission request configuration, and each of the plurality of second retransmission requests may include a second number of bits corresponding to a second quality of service. In this embodiment, the first number of bits and the second number of bits may correspond to different qualities of service, or different importance of a first portion of the first service flow (or the first service flow itself) and a second portion of the second service flow (or the second service flow itself).

[0021] In another embodiment of the non-transitory machine-readable medium, the operation may also include: receiving a third portion of the second business flow; determining a third quality of service corresponding to the third portion of the second business flow; analyzing the third quality of service with respect to at least one second delay standard of the second retransmission request configuration to obtain an analyzed third quality of service; determining a third retransmission request corresponding to the analyzed third quality of service from the second retransmission request configuration; and transmitting a second retransmission request indication indicating the third retransmission request to the network device.

[0022] In yet another embodiment of the example non-transitory machine-readable medium, the first retransmission request indication may include a compression index corresponding to a first retransmission request and a second retransmission request, wherein the first retransmission request includes a first number of bits and the second retransmission request includes a second number of bits, and wherein the compression index includes fewer bits than the sum of the first number of bits and the second number of bits. The compression index may be associated with a determined number of retransmission request indications or a combination of acknowledgment indications corresponding to a determined number of packet decoding instances, which may be referred to as a compression period. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 A wireless communication system environment is shown.

[0024] Figure 2 An example virtual reality device in a wireless network environment is shown.

[0025] Figure 3A An example retransmission request configuration is shown.

[0026] Figure 3B A variable-sized retransmission request indication without acknowledgment is shown, which can accommodate a different number of delay ranges, corresponding to different respective analyzed qualities of service, and can indicate the retransmission of one or more packets.

[0027] Figure 4 A timing diagram illustrating an example method embodiment for rescheduling traffic packets based on latency criteria is shown.

[0028] Figure 5 An example retransmission request indication compression configuration is shown.

[0029] Figure 6 A timing diagram illustrating an example method for compressing retransmission request indications.

[0030] Figure 7 A flow chart illustrating an example method for dynamically indicating a retransmission request or a no-acknowledgement request based on analyzed quality of service is shown.

[0031] Figure 8 A block diagram of an example method is shown.

[0032] Figure 9A block diagram of an example user device is shown.

[0033] Figure 10 A block diagram of an example non-transitory machine-readable medium is shown.

[0034] Figure 11 An example computer environment is shown.

[0035] Figure 12 A block diagram of an example wireless UE is shown. DETAILED DESCRIPTION

[0036] First, it will be readily understood by those skilled in the art that the present embodiments have broad utility and application. In addition to those described herein, many methods, embodiments, and adjustments of the present application, as well as many variations, modifications, and equivalent arrangements, will be apparent from or reasonably suggested by the essence or scope of the various embodiments of the present application.

[0037] Therefore, although the present application has been described in detail with respect to various embodiments, it should be understood that this disclosure illustrates one or more concepts expressed by various exemplary embodiments and is made only for the purpose of providing a complete and enabling disclosure. The following disclosure is not intended to limit the present application, nor should it be interpreted as excluding any such other embodiments, adjustments, variations, modifications, and equivalent arrangements, and the current embodiments described herein are limited only by the appended claims and their equivalents.

[0038] As used in this disclosure, in some embodiments, the terms "component," "system," and the like are intended to refer to or include a computer-related entity or an entity associated with an operating device having one or more specific functions, where the entity can be hardware, a combination of hardware and software, software, or software in execution. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, an execution thread, computer-executable instructions, a program, and / or a computer. By way of illustration and not limitation, both an application running on a server and the server can be a component.

[0039] One or more components can reside within a process and / or execution thread, and a component can be located on a computer and / or distributed between two or more computers. In addition, these components can be executed from various computer-readable media having various data structures stored thereon. Components can communicate via local and / or remote processes, such as according to signals with one or more data packets (for example, data from a component interacts with another component in a local system, a distributed system via a signal, and / or interacts with other systems across a network such as the Internet). As another example, a component can be a device with a specific function provided by a mechanical component operated by an electrical or electronic circuit, which is operated by a software application or firmware application executed by a processor, wherein the processor can be located inside or outside the device and execute at least a portion of the software or firmware application. As another example, a component can be a device that provides a specific function by an electronic component without a mechanical component, in which the electronic component can include a processor to execute software or firmware that at least partially assigns the function of the electronic component. Although various components have been shown as separate components, it will be appreciated that, without departing from the exemplary embodiments, multiple components can be implemented as a single component, or a single component can be implemented as multiple components.

[0040] As used herein, the term "facilitate" is in the context of a system, device, or component "facilitating" one or more actions or operations, which is related to the nature of complex computing environments in which multiple components and / or multiple devices may be involved in some computing operations. Non-limiting examples of actions that may or may not involve multiple components and / or multiple devices include sending or receiving data, establishing a connection between devices, determining intermediate results toward obtaining a result, etc. In this regard, a computing device or component can facilitate an operation by playing any part in completing the operation. When the operation of a component is described herein, it should be understood that, where an operation is described as being facilitated by the component, the operation can optionally be completed in collaboration with one or more other computing devices or components (such as, but not limited to, sensors, antennas, audio and / or video output devices, other devices, etc.).

[0041] In addition, various embodiments can be implemented as methods, apparatuses or articles of manufacture using standard programming and / or engineering techniques to produce software, firmware, hardware, or any combination thereof to control a computer to implement the disclosed subject matter. The term "article of manufacture" as used herein is intended to encompass a computer program accessible from any computer-readable (or machine-readable) device or computer-readable (or machine-readable) storage device / communication medium. For example, a computer-readable storage medium may include, but is not limited to, magnetic storage devices (e.g., hard disks, floppy disks, magnetic strips), optical disks (e.g., compact disks (CDs), digital versatile disks (DVDs)), smart cards, and flash memory devices (e.g., cards, sticks, key drives). Of course, those skilled in the art will recognize that many modifications may be made to this configuration without departing from the scope or spirit of the various embodiments.

[0042] The 5G NR system's PDCCH can deliver downlink and uplink control information to cellular devices. Compared to the control channel design of the fourth generation (such as LTE), the 5G control channel can meet the requirements of URLLC and eMBB use cases and can provide efficient coexistence between these different QoS categories.

[0043] Unlike the fourth generation control channel, the 5G PDCCH channel can be beamformed using the preferred channel vector of each UE, in which the demodulation auxiliary reference signal ("DMRS") is embedded. The PDCCH can be modulated using a fixed QPSK modulation scheme and a conservative coding rate, such as to maximize the reliability of the PDCCH channel received at the UE device. For example, in order to meet the URLLC 10e-5 reliability level, the PDCCH channel decoding capability can be enhanced at the device end.

[0044] The resource size of each PDCCH channel, which may carry downlink control information ("DCI") for one or more UEs, may be time-varying and may be referred to as the PDCCH aggregation level. In particular, and to enhance PDCCH decoding, the network may increase the resource size of the PDCCH channel and, therefore, employ a more conservative and less resource-efficient coding rate for the PDCCH. This means that the same amount of PDCCH control information is transmitted with a stronger coding rate (i.e., more redundant bits for error detection and correction), but at the expense of consuming more channel resources to transmit the PDCCH information.

[0045] There are two types of PDCCH channels. First, UE-specific PDCCH, where a set of channel resources is periodically monitored by a single UE / device. After being configured, the device will attempt to blindly decode these candidate resources in case they may carry DCI information. This DCI information includes the configuration of the scheduled uplink or downlink grant, the transmission configuration, and information about common system signaling and updates. In addition, blind decoding is the process when the UE attempts to decode the DCI using all possible transmission configurations and aggregation levels. This means that the power consumption on the device side is large; however, this is necessary because the UE is not yet aware of the actual configuration of the PDCCH channel and the corresponding transmission. It should be clear to it after it successfully decodes the PDCCH. In active mode, the UE can monitor one or more configured PDCCH search spaces, where the search space means a set of candidate resources that can carry PDCCH / DCI information. The search space definition can be used to refer to PDCCH channels of different sizes (i.e. aggregation levels), and therefore the size of the resources required to carry the PDCCH may also vary.

[0046] A common PDCCH search space is monitored by all UEs. These common PDCCH channels typically carry DCI information relevant to all devices. Examples include system update and control information, power control information for all UEs, and general system information.

[0047] For each scheduled downlink or uplink transmission, there is typically a preceding PDCCH control transmission that informs the UE device of the resources scheduled by the network for that transmission, as well as the transmission configuration to use for transmission in the uplink or reception in the downlink. Therefore, PDCCH transmissions are considered signaling overhead that should always be minimized and are required for successful device transmission and / or reception.

[0048] As an example use case illustrating example embodiments disclosed herein, virtual reality ("VR") applications and VR variants (e.g., mixed reality and augmented reality) may perform best when using NR radio resources associated with URLLC at certain times, while lower performance levels may be sufficient at other times. Virtual reality smart glasses devices may consume NR radio resources at a given wideband data rate with more stringent radio latency and reliability standards to provide a satisfactory end-user experience.

[0049] 5G systems should support “Extended Reality” (“XR”) services. XR services may include VR applications, which are widely adopted XR applications that provide an immersive environment that stimulates the senses of an end user so that he or she can be “induced” to be in an environment that is different from the environment he or she actually is in. XR services may include augmented reality (“AR”) applications, which may enhance the real-world environment by providing additional virtual-world elements through the user’s senses that focus on real-world elements in the user’s actual surroundings. XR services may include mixed reality (MR) applications, which help to merge or integrate the virtual and real worlds so that an end user of the XR service can interact with elements of his or her real environment and the virtual environment simultaneously.

[0050] Different XR use cases can be associated with specific radio performance targets. Unlike URLLC or eMBB, XR use cases have in common that they typically require high-capacity links with stringent radio and reliability levels to achieve a satisfactory end-user experience. For example, compared to a 5Mbps URLLC link with a 1ms radio budget, some XR applications require a 100Mbps link with an allowable radio latency of several milliseconds. Therefore, 5G radio design and associated procedures can be adapted to the new XR QoS categories and associated targets.

[0051] XR services can be facilitated by traffic that has certain characteristics associated with XR services. For example, XR traffic is often periodic, with time-varying packet sizes and packet arrival rates. Furthermore, different packet traffic flows within a single XR session may impact the end-user experience differently. For example, smart glasses streaming 180-degree high-resolution frames may use a large percentage of the capacity of a broadband service to satisfy the user experience. However, frames intended for presentation to the user's gestural direction (e.g., frontal orientation) are critical to a satisfactory user experience for the end-user, while frames intended for presentation to the user's peripheral field of view have less impact on the user's experience and may therefore be associated with lower QoS requirements for transmitting traffic packets than for transmitting gestural direction traffic flows. Therefore, stream differentiation, which prioritizes some flows or packets within an XR session over other flows or packets, can facilitate efficient use of the communication system's capacity to deliver traffic. Furthermore, XR-enabled devices (e.g., smart glasses, projection-based wearables, etc.) may be more power-constrained than traditional mobile phones due to their limited form factors. Therefore, techniques for maximizing power-saving operation at XR-enabled devices are desired. Thus, for example, a user device accessing a traffic flow of an XR service or an XR session may be associated with certain QoS metrics to meet the performance targets of the XR service in terms of perceived data rate or end-to-end latency and reliability.

[0052] High-capacity demand services (such as virtual reality applications) may pose performance challenges even to 5G NR capabilities. Therefore, even though 5G NR systems can facilitate and support higher performance capabilities, the radio interface should be optimized to support the extremely high capacity and low latency requirements of XR applications and XR data services.

[0053] Hybrid Automatic Repeat Request (HARQ) can be used for packet retransmission and packet combining in the event that decoding of the first transmission of a packet fails, and generally enhances radio reliability between the RAN and the user equipment. The user equipment can send HARQ ACK / NACK feedback reports to the serving cell RAN, indicating successful or failed downlink packet reception and decoding. The RAN generally prioritizes the retransmission of packets that failed decoding over the transmission of newly arrived packets. However, for critical use cases such as VR, not all services are equally important or have the same impact on the user's quality of experience. Therefore, not all packet HARQ retransmissions should be prioritized over the transmission of newly arrived packet transmissions. For example, for smart glasses that are streaming broadband video, it is expected that the smart glasses device will receive packet retransmissions quickly, especially for packets corresponding to the posture or frontal viewing range, while the delay target for packets contributing to the periphery of the viewing range of the smart glasses device can be relaxed because the jitter associated with packets contributing to the peripheral view may not cause motion sickness or blur. Instead of prioritizing HARQ packet retransmissions over new packet transmissions regardless of the packet's importance or delay tolerance (new or already transmitted), for critical and high-capacity services that may be negatively impacted by the delay associated with the arrival of new packets due to retransmissions of non-critical packets, a delay-aware HARQ packet retransmission process is disclosed, whereby HARQ packet retransmissions are processed and dynamically prioritized based on their respective importance and scheduling delay tolerance derived from an application perspective (e.g., from the perspective of a VR application operating smart glasses). Using delay-aware retransmission indications prevents the RAN node scheduler from prioritizing many non-critical packet retransmissions at the expense of more critical new packet arrivals. The RAN scheduler can learn the packet priority based on a delay-aware retransmission request indication received from a user device that corresponds to the delay tolerance or importance of the HARQ packet retransmission. Consequently, the RAN can schedule new packets and packet retransmissions based on their respective and potentially different delay requirements, as determined by the user device or an application running on the user device.

[0054] Now go to Figure 1 , Figure 1An example of a wireless communication system 100 that supports blind decoding of PDCCH candidates or search spaces according to aspects of the present disclosure is shown. The wireless communication system 100 may include one or more base stations 105, one or more UEs 115, and a core network 130. In some examples, the wireless communication system 100 may be a Long Term Evolution (LTE) network, an LTE-Advanced (LTE-A) network, an LTE-A Pro network, or a New Radio (NR) network. In some examples, the wireless communication system 100 may support enhanced broadband communication, ultra-reliable (e.g., mission-critical) communication, low-latency communication, communication with low-cost and low-complexity devices, or any combination thereof. As shown in the figure, examples of UE 115 may include smartphones, cars or other vehicles, or drones or other aircraft. Another example of a UE may be a virtual reality device 117, such as smart glasses, a virtual reality headset, an augmented reality headset, and other similar devices that can provide images, video, audio, touch, taste, or smell to the wearer. A UE (such as VR device 117) may transmit or receive wireless signals with a RAN base station 105 via a long-range wireless link 125, or a UE / VR device may receive or transmit wireless signals via a short-range wireless link 137, which may include a wireless link with the UE device 115, such as a Bluetooth link, a Wi-Fi link, etc. A UE (such as device 117) may communicate simultaneously via multiple wireless links, such as via link 125 with the base station 105 and via a short-range wireless link. The VR device 117 may also communicate with a wireless UE via a cable or other wired connection. The RAN or its components may be implemented by one or more computer components, which may refer to Figure 12 describe.

[0055] continue Figure 1 As discussed above, base stations 105 can be dispersed throughout a geographic area to form wireless communication system 100 and can be devices of varying form factors or capabilities. Base stations 105 and UEs 115 can communicate wirelessly via one or more communication links 125. Each base station 105 can provide a coverage area 110 within which a UE 115 and base station 105 can establish one or more communication links 125. Coverage area 110 can be an example of a geographic area within which base stations 105 and UEs 115 can support communication of signals according to one or more radio access technologies.

[0056] The UEs 115 may be dispersed throughout the coverage area 110 of the wireless communication system 100, and each UE 115 may be stationary, mobile, or both at different times. The UEs 115 may be devices in different forms or with different capabilities. Figure 11. Some example UEs 115 are shown in FIG. 1. The UEs 115 described herein may be capable of communicating with various types of devices, such as other UEs 115, base stations 105, or network devices (e.g., core network nodes, relays, integrated access and backhaul (IAB) nodes, or other network devices), such as Figure 1 As shown in .

[0057] The base stations 105 can communicate with the core network 130, or with each other, or both. For example, the base stations 105 can interface with the core network 130 via one or more backhaul links 120 (e.g., via S1, N2, N3, or other interfaces). The base stations 105 can communicate with each other directly (e.g., directly between the base stations 105), indirectly (e.g., via the core network 130), or both via the backhaul links 120 (e.g., via X2, Xn, or other interfaces). In some examples, the backhaul links 120 may include one or more wireless links.

[0058] The one or more base stations 105 described herein may include or may be referred to by one of ordinary skill in the art as a base transceiver station, a radio base station, an access point, a radio transceiver, a NodeB, an eNodeB (eNB), a next generation NodeB or a giga NodeB (any of which may be referred to as a bNodeB or gNB), a Home NodeB, a Home eNodeB, or other appropriate terminology.

[0059] UE 115 may include or may be referred to as a mobile device, a wireless device, a remote device, a handheld device, or a user device, or some other suitable terminology, where "device" may also be referred to as a unit, a station, a terminal, or a client, etc. UE 115 may also include or may be referred to as a personal electronic device, such as a cellular phone, a personal digital assistant (PDA), a tablet computer, a laptop computer, a personal computer, or a router. In some examples, UE 115 may include or be referred to as a wireless local loop (WLL) station, an Internet of Things (IoT) device, an Internet of Everything (IoE) device, or a machine type communication (MTC) device, etc., which may be implemented in various objects such as home appliances, vehicles, or smart meters.

[0060] The UE 115 can communicate with various types of devices, such as other UEs 115, which can sometimes act as relays, as well as base stations 105 and network devices, including macro eNBs or gNBs, small cell eNBs or gNBs, or relay base stations, etc. Figure 1 As shown in .

[0061] The UE 115 and the base station 105 can wirelessly communicate with each other via one or more communication links 125 on one or more carriers. The term "carrier" can refer to a set of radio frequency spectrum resources with a defined physical layer structure for supporting the communication link 125. For example, a carrier used for the communication link 125 can include a portion of a radio frequency spectrum band (e.g., a bandwidth portion (BWP)) that operates according to one or more physical layer channels of a given radio access technology (e.g., LTE, LTE-A, LTE-A Pro, NR). Each physical layer channel can carry acquisition signaling (e.g., synchronization signals, system information), control signaling to coordinate the operation of the carrier, user data, or other signaling. The wireless communication system 100 can use carrier aggregation or multi-carrier operation to support communications with the UE 115. Depending on the carrier aggregation configuration, the UE 115 can be configured with multiple downlink component carriers and one or more uplink component carriers. Carrier aggregation can be used with both frequency division duplex (FDD) and time division duplex (TDD) component carriers.

[0062] In some examples (e.g., in a carrier aggregation configuration), a carrier may also have acquisition signaling or control signaling for coordinating the operation of other carriers. A carrier may be associated with a frequency channel (e.g., an Evolved Universal Mobile Telecommunications System Terrestrial Radio Access (E-UTRA) Absolute Radio Frequency Channel Number (EARFCN)) and may be positioned according to a channel grid for discovery by a UE 115. A carrier may operate in a standalone mode, where initial acquisition and connection may be performed by a UE 115 via the carrier, or in a non-standalone mode, where a different carrier (e.g., of the same or different radio access technology) is used to anchor the connection.

[0063] The communication link 125 shown in the wireless communication system 100 may include an uplink transmission from the UE 115 to the base station 105, or a downlink transmission from the base station 105 to the UE 115. A carrier may carry downlink or uplink communications (e.g., in FDD mode) or may be configured to carry both downlink and uplink communications (e.g., in TDD mode).

[0064] A carrier can be associated with a specific bandwidth of radio frequency spectrum, and in some examples, the carrier bandwidth can be referred to as the "system bandwidth" of the carrier or wireless communication system 100. For example, the carrier bandwidth can be one of a plurality of determined bandwidths (e.g., 1.4, 3, 5, 10, 15, 20, 40, or 80 megahertz (MHz)) for a carrier for a particular radio access technology. The devices of the wireless communication system 100 (e.g., base station 105, UE 115, or both) can have a hardware configuration that supports communication on a specific carrier bandwidth, or can be configurable to support communication on one of a set of carrier bandwidths. In some examples, the wireless communication system 100 can include a base station 105 or UE 115 that supports simultaneous communication via carriers associated with multiple carrier bandwidths. In some examples, each served UE 115 can be configured to operate on a portion (e.g., subband, BWP) or all of the carrier bandwidth.

[0065] The signal waveform transmitted by the carrier may be composed of multiple subcarriers (e.g., using multi-carrier modulation (MCM) techniques such as orthogonal frequency division multiplexing (OFDM) or discrete Fourier transform spread OFDM (DFT-S-OFDM)). In a system employing MCM techniques, a resource element may be composed of one symbol period (e.g., the duration of one modulation symbol) and one subcarrier, where the symbol period and the subcarrier spacing are inversely correlated. The number of bits carried by each resource element may depend on the modulation scheme (e.g., the order of the modulation scheme, the coding rate of the modulation scheme, or both). Therefore, the more resource elements received by the UE 115 and the higher the order of the modulation scheme, the higher the data rate of the UE can be. Wireless communication resources may refer to a combination of radio frequency spectrum resources, time resources (e.g., search space), or spatial resources (e.g., spatial layers or beams), and the use of multiple spatial layers may further improve the data rate or data integrity used for communication with the UE 115.

[0066] One or more parameter sets for a carrier may be supported, where the parameter set may include subcarrier spacing (Δf) and a cyclic prefix. A carrier may be divided into one or more BWPs with the same or different parameter sets. In some examples, a UE 115 may be configured with multiple BWPs. In some examples, a single BWP for a carrier may be active at a given time, and communication by the UE 115 may be limited to the one or more active BWPs.

[0067] The time interval of the base station 105 or the UE 115 can be expressed as a multiple of a basic time unit. For example, the basic time unit can refer to a sampling period T s =1 / (Δf max ·N f ) seconds, where Δf maxIndicates the maximum supported subcarrier spacing, and N f Indicates the maximum supported discrete Fourier transform (DFT) size. Time intervals for communication resources may be organized according to radio frames, each of which has a specified duration (e.g., 10 milliseconds (ms)). Each radio frame may be identified by a system frame number (SFN) (e.g., ranging from 0 to 1023).

[0068] Each frame can include multiple consecutively numbered subframes or time slots, and each subframe or time slot can have the same duration. In some examples, the frame can be divided into multiple subframes (e.g., in the time domain), and each subframe can be further divided into multiple time slots. Alternatively, each frame can include a variable number of time slots, and the number of time slots can depend on the subcarrier spacing. Each time slot can include multiple symbol periods, for example, depending on the length of the cyclic prefix added to each symbol period. In some wireless communication systems 100, the time slot can be further divided into multiple mini-time slots containing one or more symbols. In addition to the cyclic prefix, each symbol period can contain one or more (e.g., N f The duration of a symbol period may depend on the subcarrier spacing or the operating band.

[0069] A subframe, slot, mini-slot, or symbol may be the smallest scheduling unit (e.g., in the time domain) of the wireless communication system 100 and may be referred to as a transmission time interval (TTI). In some examples, the TTI duration (e.g., the number of symbol periods in a TTI) may be variable. Additionally or alternatively, the smallest scheduling unit of the wireless communication system 100 may be dynamically selected (e.g., in bursts of shortened TTIs (sTTIs)).

[0070] Physical channels can be multiplexed on a carrier using various techniques. Physical control channels and physical data channels can be multiplexed on a downlink carrier, for example, using one or more of time division multiplexing (TDM), frequency division multiplexing (FDM), or hybrid TDM-FDM techniques. A control region (e.g., a control resource set (CORESET)) for a physical control channel can be defined by a number of symbol periods and can extend across the system bandwidth of a carrier or a subset of the system bandwidth. One or more control regions (e.g., CORESETs) can be configured for a set of UEs 115. For example, one or more of UEs 115 can monitor or search a control region or space for control information according to one or more search space sets, and each search space set can include one or more control channel candidates in one or more aggregation levels arranged in a cascaded manner. The aggregation level of a control channel candidate can refer to the number of control channel resources (e.g., control channel elements (CCEs)) associated with coded information of a control information format having a given payload size. Search space sets can include a common search space set for transmitting control information to multiple UEs 115 and a UE-specific search space set for transmitting control information to a specific UE 115. Other search spaces and configurations for monitoring and decoding them are disclosed herein that are novel and non-traditional.

[0071] Base station 105 may provide communication coverage via one or more cells (e.g., macro cells, small cells, hotspots, or other types of cells, or any combination thereof). The term "cell" may refer to a logical communication entity used to communicate with base station 105 (e.g., via a carrier) and may be associated with an identifier (e.g., a physical cell identifier (PCID), a virtual cell identifier (VCID), or other) used to distinguish adjacent cells. In some examples, a cell may also refer to a geographic coverage area 110 or a portion of a geographic coverage area 110 (e.g., a sector) within which a logical communication entity operates. Such cells may range from a smaller area (e.g., a structure, a subset of a structure) to a larger area, depending on various factors, such as the capabilities of base station 105. For example, a cell may be or include a building, a subset of a building, or an external space located between or overlapping geographic coverage areas 110, etc.

[0072] A macro cell typically covers a relatively large geographic area (e.g., a radius of several kilometers) and may allow unrestricted access by UEs 115 that have a service subscription with a network provider that supports the macro cell. Small cells may be associated with base stations 105 that have lower power than macro cells, and small cells may operate in the same or different (e.g., licensed or unlicensed) frequency bands as macro cells. Small cells may provide unrestricted access to UEs 115 that have a service subscription with a network provider, or may provide restricted access to UEs 115 that are associated with small cells (e.g., UEs 115 in a closed subscriber group (CSG), UEs 115 associated with users in a home or office). A base station 105 may support one or more cells and may also support communication on one or more cells using one or more component carriers.

[0073] In some examples, a carrier may support multiple cells, and different cells may be configured according to different protocol types (e.g., MTC, narrowband Internet of Things (NB-IoT), enhanced mobile broadband (eMBB)) that may provide access to different types of devices.

[0074] In some examples, base stations 105 can be mobile and, therefore, can provide communication coverage for mobile geographic coverage areas 110. In some examples, different geographic coverage areas 110 associated with different technologies can overlap, but these different geographic coverage areas 110 can be supported by the same base station 105. In other examples, overlapping geographic coverage areas 110 associated with different technologies can be supported by different base stations 105. The wireless communication system 100 can include, for example, a heterogeneous network in which different types of base stations 105 provide coverage for different geographic coverage areas 110 using the same or different radio access technologies.

[0075] The wireless communication system 100 can support synchronous or asynchronous operation. For synchronous operation, the base stations 105 can have similar frame timing, and transmissions from different base stations 105 can be approximately aligned in time. For asynchronous operation, the base stations 105 can have different frame timing, and transmissions from different base stations 105 may not be aligned in time in some examples. The techniques described herein can be used for either synchronous or asynchronous operation.

[0076] Some UEs 115, such as MTC or IoT devices, may be low-cost or low-complexity devices and may provide automated communication between machines (e.g., via machine-to-machine (M2M) communication). M2M communication or MTC may refer to data communication technology that allows devices to communicate between or with a base station 105 without human intervention. In some examples, M2M communication or MTC may include communication from devices with integrated sensors or meters that measure or capture information and relay such information to a central server or application that utilizes the information or presents it to a human interacting with the application. Some UEs 115 may be designed to collect information or enable automated behavior of machines or other devices. Examples of applications for MTC devices include smart metering, inventory monitoring, water level monitoring, equipment monitoring, healthcare monitoring, wildlife monitoring, weather and geological event monitoring, fleet management and tracking, remote security sensing, physical access control, and transaction-based billing for services.

[0077] Some UEs 115 may be configured to employ a reduced power consumption mode of operation, such as half-duplex communication (e.g., a mode that supports one-way communication via transmission or reception but does not support simultaneous transmission and reception). In some examples, half-duplex communication may be performed at a reduced peak rate. Other power conservation techniques for the UE 115 include entering a power-saving deep sleep mode when not engaged in active communications, operating over a limited bandwidth (e.g., in accordance with narrowband communications), or a combination of these techniques. For example, some UEs 115 may be configured to operate using a narrowband protocol type associated with a defined portion or range (e.g., a set of subcarriers or resource blocks (RBs)) within a carrier, within a carrier guard band, or outside a carrier.

[0078] The wireless communication system 100 can be configured to support ultra-reliable communication or low-latency communication, or various combinations thereof. For example, the wireless communication system 100 can be configured to support ultra-reliable low-latency communication (URLLC) or mission-critical communication. UE 115 can be designed to support ultra-reliable, low-latency or critical functions (e.g., mission-critical functions). Ultra-reliable communication can include private communication or group communication and can be supported by one or more mission-critical services, such as mission-critical push-to-talk (MCPTT), mission-critical video (MCVideo), or mission-critical data (MCData). Support for mission-critical functions can include priority processing of services, and mission-critical services can be used for public safety or general commercial applications. The terms ultra-reliable, low-latency, mission-critical, and ultra-reliable low-latency can be used interchangeably in this article.

[0079] In some examples, UE 115 can also communicate directly with other UEs 115 via device-to-device (D2D) communication links 135 (e.g., using peer-to-peer (P2P) or D2D protocols). Communication links 135 may include sidelink communication links. One or more UEs 115 utilizing D2D communication may be located within the geographic coverage 110 of base station 105. Other UEs 115 in such a group may be located outside the geographic coverage 110 of base station 105 or otherwise unable to receive transmissions from base station 105. In some examples, a group of UEs 115 communicating via D2D communication may utilize a one-to-many (1:M) system in which a UE transmits to each other UE in the group. In some examples, base station 105 facilitates the scheduling of resources for D2D communication. In other cases, D2D communication occurs between UEs 115 without the involvement of base station 105.

[0080] In some systems, the D2D communication link 135 can be an example of a communication channel (such as a sidelink communication channel) between vehicles (e.g., UE 115). In some examples, the vehicles can communicate using vehicle-to-everything (V2X) communication, vehicle-to-vehicle (V2V) communication, or some combination of these communication methods. The vehicles can signal information related to traffic conditions, signal scheduling, weather, safety, emergency situations, or any other information related to the V2X system. In some examples, vehicles in the V2X system can communicate with roadside infrastructure (such as roadside units) or communicate with the network via one or more RAN network nodes (e.g., base station 105) using vehicle-to-network (V2N) communication, or both.

[0081] The core network 130 may provide user authentication, access authorization, tracking, Internet Protocol (IP) connectivity, and other access, routing, or mobility functions. The core network 130 may be an evolved packet core (EPC) or a 5G core (5GC), which may include at least one control plane entity for managing access and mobility (e.g., a mobility management entity (MME), an access and mobility management function (AMF)) and at least one user plane entity for routing packets or interconnecting with external networks (e.g., a serving gateway (S-GW), a packet data network (PDN) gateway (P-GW), or a user plane function (UPF)). The control plane entity may manage non-access stratum (NAS) functions such as mobility, authentication, and bearer management for UEs 115 served by base stations 105 associated with the core network 130. User IP packets may be transmitted via the user plane entity, which may provide IP address allocation and other functions. The user plane entity may connect to IP services 150 of one or more network operators. The IP services 150 may include access to the Internet, intranet(s), IP multimedia subsystems (IMS), or packet-switched streaming services.

[0082] Some of the network devices, such as base stations 105, may include subcomponents, such as access network entities 140, which may be examples of access node controllers (ANCs). Each access network entity 140 may communicate with the UE 115 through one or more other access network transport entities 145, which may be referred to as radio heads, smart radio heads, or transmission / reception points (TRPs). Each access network transport entity 145 may include one or more antenna panels. In some configurations, the various functions of each access network entity 140 or base station 105 may be distributed across various network devices (e.g., radio heads and ANCs) or integrated into a single network device (e.g., base station 105).

[0083] The wireless communication system 100 can operate using one or more frequency bands, which are generally in the range of 300 megahertz (MHz) to 300 gigahertz (GHz). The region from 300 MHz to 3 GHz is often referred to as the ultra-high frequency (UHF) region or decimeter band because the wavelengths range in length from about one decimeter to one meter. UHF waves may be blocked or redirected by buildings and environmental features, but these waves can penetrate buildings sufficiently for a macro cell to serve a UE 115 located indoors. Transmissions using UHF waves may be associated with smaller antennas and a shorter range (e.g., less than 100 kilometers) than transmissions using smaller frequencies and longer waves in the high frequency (HF) or very high frequency (VHF) portions of the spectrum below 300 MHz.

[0084] The wireless communication system 100 may also operate in the super high frequency (SHF) region (also known as centimeter waves) using frequency bands from 3 GHz to 30 GHz or in the extremely high frequency (EHF) region of the spectrum (e.g., from 30 GHz to 300 GHz) (also known as millimeter waves). In some examples, the wireless communication system 100 may support millimeter wave (mmW) communications between user devices 115 and base stations 105, and the EHF antennas of the respective devices may be smaller and more closely spaced than UHF antennas. In some examples, this may facilitate the use of antenna arrays within the device. However, the propagation of EHF transmissions may be subject to even greater atmospheric attenuation and a shorter range than SHF or UHF transmissions. The techniques disclosed herein may be employed across transmissions using one or more different frequency ranges, and the designated use of bands across these frequency regions may vary by country or regulatory body.

[0085] The wireless communication system 100 can utilize both licensed and unlicensed radio frequency spectrum bands. For example, the wireless communication system 100 can employ licensed assisted access (LAA), LTE-unlicensed (LTE-U) radio access technology, or NR technology in an unlicensed band, such as the 5 GHz Industrial, Scientific, and Medical (ISM) band. When operating in an unlicensed radio frequency spectrum band, devices such as the base station 105 and the UE 115 can employ carrier sensing for collision detection and avoidance. In some examples, operations in the unlicensed band can be based on a carrier aggregation configuration, in combination with component carriers operating in a licensed band (e.g., LAA). Operations in the unlicensed spectrum can include downlink transmissions, uplink transmissions, P2P transmissions, or D2D transmissions, among others.

[0086] The base station 105 or UE 115 may be equipped with multiple antennas that can be used to employ techniques such as transmit diversity, receive diversity, multiple-input multiple-output (MIMO) communications, or beamforming. The antennas of the base station 105 or UE 115 may be located within one or more antenna arrays or antenna panels that can support MIMO operations or transmit or receive beamforming. For example, one or more base station antennas or antenna arrays may be co-located on an antenna assembly (such as an antenna tower). In some examples, the antennas or antenna arrays associated with the base station 105 may be located in a variety of geographic locations. The base station 105 may have an antenna array having multiple rows and columns of antenna ports that the base station 105 may use to support beamforming for communications with the UE 115. Similarly, the UE 115 may have one or more antenna arrays that can support various MIMO or beamforming operations. Additionally or alternatively, the antenna panels may support radio frequency beamforming for signals transmitted via the antenna ports.

[0087] The base station 105 or UE 115 can use MIMO communication to exploit multipath signal propagation and improve spectral efficiency by transmitting or receiving multiple signals via different spatial layers. Such techniques may be referred to as spatial multiplexing. For example, multiple signals may be transmitted by a transmitting device via different antennas or different antenna combinations. Similarly, multiple signals may be received by a receiving device via different antennas or different antenna combinations. Each of the multiple signals may be referred to as a separate spatial stream and may carry bits associated with the same data stream (e.g., the same codeword) or different data streams (e.g., different codewords). Different spatial layers may be associated with different antenna ports for channel measurement and reporting. MIMO techniques include single-user MIMO (SU-MIMO), in which multiple spatial layers are transmitted to the same receiving device, and multi-user MIMO (MU-MIMO), in which multiple spatial layers are transmitted to multiple devices.

[0088] Beamforming, which may also be referred to as spatial filtering, directional transmission, or directional reception, is a signal processing technique that can be used at a transmitting device or a receiving device (e.g., a base station 105, a UE 115) to shape or steer an antenna beam (e.g., a transmit beam, a receive beam) along a spatial path between the transmitting device and the receiving device. Beamforming can be achieved by combining signals transmitted via antenna elements of an antenna array so that some signals propagating at a particular orientation relative to the antenna array experience constructive interference, while other signals experience destructive interference. Adjustments to signals transmitted via antenna elements can include the transmitting device or the receiving device applying an amplitude shift, a phase shift, or both to signals carried via antenna elements associated with the device. The adjustments associated with each of the antenna elements can be defined by a set of beamforming weights associated with a particular orientation (e.g., relative to the antenna array of the transmitting device or the receiving device, or relative to some other orientation).

[0089] The base station 105 or the UE 115 may use beam scanning techniques as part of a beamforming operation. For example, the base station 105 may use multiple antennas or antenna arrays (e.g., antenna panels) to perform beamforming operations for directional communication with the UE 115. Some signals (e.g., synchronization signals, reference signals, beam selection signals, or other control signals) may be transmitted multiple times by the base station 105 in different directions. For example, the base station 105 may transmit signals according to different sets of beamforming weights associated with different transmission directions. The transmissions in different beam directions may be used to identify (e.g., by a transmitting device (such as the base station 105) or by a receiving device (such as the UE 115)) a beam direction for later transmission or reception by the base station 105.

[0090] Some signals, such as data signals associated with a particular receiving device, may be transmitted by base station 105 in a single beam direction (e.g., a direction associated with a receiving device, such as UE 115). In some examples, the beam direction associated with transmissions along a single beam direction may be determined based on signals transmitted in one or more beam directions. For example, UE 115 may receive one or more signals transmitted by base station 105 in different directions and may report to the base station an indication of the signal received by UE 115 having the highest signal quality or other acceptable signal quality.

[0091] In some examples, transmissions by a device (e.g., base station 105 or UE 115) can be performed using multiple beam directions, and the device can use a combination of digital precoding or radio frequency beamforming to generate a combined beam for transmission (e.g., from base station 105 to UE 115). UE 115 can report feedback indicating precoding weights for one or more beam directions, and the feedback can correspond to the number of beams configured across the system bandwidth or one or more subbands. Base station 105 can transmit reference signals (e.g., cell-specific reference signals (CRS), channel state information reference signals (CSI-RS)), which can be precoded or non-precoded. UE 115 can provide feedback for beam selection, which can be a precoding matrix indicator (PMI) or codebook-based feedback (e.g., a multi-panel type codebook, a linear combination type codebook, a port selection type codebook). Although these techniques are described with reference to signals transmitted by base station 105 in one or more directions, UE 115 may employ similar techniques for transmitting signals multiple times in different directions (e.g., for identifying a beam direction for subsequent transmission or reception by UE 115) or for transmitting signals in a single direction (e.g., for transmitting data to a receiving device).

[0092] A receiving device (e.g., UE 115) can attempt multiple reception configurations (e.g., directional listening) when receiving various signals from base station 105 (such as synchronization signals, reference signals, beam selection signals, or other control signals). For example, the receiving device can attempt multiple reception directions by: receiving via different antenna subarrays; processing received signals according to different antenna subarrays; receiving according to different receive beamforming weight sets applied to signals received at multiple antenna elements of an antenna array (e.g., different directional listening weight sets); or processing received signals according to different receive beamforming weight sets applied to signals received at multiple antenna elements of an antenna array, any of which can be referred to as "listening" according to different reception configurations or reception directions. In some examples, the receiving device can use a single reception configuration to receive along a single beam direction (e.g., when receiving data signals). The single reception configuration can be aligned on a beam direction determined based on listening according to different reception configuration directions (e.g., a beam direction determined to have the highest signal strength, highest signal-to-noise ratio (SNR), or other acceptable signal quality based on listening according to multiple beam directions).

[0093] The wireless communication system 100 can be a packet-based network that operates according to a layered protocol stack. In the user plane, communications at the bearer or packet data convergence protocol (PDCP) layer can be IP-based. The radio link control (RLC) layer can perform packet segmentation and reassembly to communicate over logical channels. The medium access control (MAC) layer can perform priority processing and multiplex logical channels into transport channels. The MAC layer can also use error detection technology, error correction technology, or both to support retransmission at the MAC layer to improve link efficiency. In the control plane, the radio resource control (RRC) protocol layer can provide the establishment, configuration, and maintenance of an RRC connection between the UE 115 and the base station 105 or the core network 130 that supports the radio bearer of the user plane data. At the physical layer, the transport channel can be mapped to the physical channel.

[0094] Hybrid Automatic Repeat Request ("HARQ").

[0095] UE 115 and base station 105 can support retransmission of data to increase the likelihood that the data is successfully received. Hybrid automatic repeat request (HARQ) feedback is a technique for increasing the likelihood of correctly receiving data over communication link 125. HARQ can include a combination of error detection (e.g., using a cyclic redundancy check (CRC)), forward error correction (FEC), and retransmission (e.g., automatic repeat request (ARQ)). HARQ can improve throughput at the MAC layer under poor radio conditions (e.g., low signal-to-noise ratio conditions). In some examples, a device can support same-slot HARQ feedback, wherein the device can provide HARQ feedback in a specific time slot for data received via the previous symbol in the time slot. In other cases, the device can provide HARQ feedback in subsequent time slots or according to some other time interval.

[0096] In the event that a user equipment device (UE) has not successfully received or decoded one or more previous transmissions of a packet, HARQ processes can be used in a cellular network to cause the RAN node 105 to retransmit the packet (possibly multiple times) to the intended receiving user equipment device 115. For each downlink transmission from the network RAN ​​105 to the user equipment device 115, the UE device transmits HARQ feedback signaling using uplink channel resources to indicate to the serving RAN whether the downlink packet has been successfully received and successfully decoded. If the UE has not successfully received or determined a packet, the RAN node can retransmit the packet that failed to be received or decoded. RAN nodes typically blindly prioritize scheduling packet retransmissions over scheduling transmissions of newly arrived packets. Therefore, HARQ processes enhance radio reliability due to packet retransmissions. At the UE 115, when a packet is not successfully decoded, the UE buffers the received payload and transmits a HARQ negative acknowledgement ("NACK") to the transmitting RAN node to indicate that the packet was not successfully received or decoded. When a user equipment device 115 receives a packet retransmission, the user equipment may combine the received packet with one or more previously received packets of the packet and attempt to decode the combined packet, resulting in better decoding capabilities due to "combining gain." The retransmitted packet may typically be retransmitted according to the same transmission configuration as one or more previous transmissions / retransmissions to facilitate combining.

[0097] One or more HARQ process identifiers can be defined and associated with downlink stream transmissions. Multiple downlink streams can be transmitted to the same receiving device without receiving HARQ feedback. The progress of a particular stream can depend on the received HARQ feedback associated with that stream and the corresponding HARQ process identifier associated with that stream. Multiple HARQ process identifiers can facilitate pipelined transmission of multiple streams without delaying the transmission of streams for which HARQ feedback has not yet been received from the device.

[0098] 5G-advanced can support services with extremely high capacity and low latency requirements, such as virtual reality, extended reality, and holographic communications. These applications or services use a relatively large amount of network resource capacity provided by the RAN serving the devices running the applications or services. However, it is desirable to optimize several radio aspects and processes to increase the radio capacity resources provided by the RAN.

[0099] As discussed above, the HARQ process may be used by the user equipment to indicate to the serving cell (e.g., a RAN node) whether a transmitted downlink packet was successfully decoded. If packet decoding fails and a HARQ NACK is received indicating this, the network RAN ​​node typically immediately and blindly prioritizes or takes precedence over the scheduling of retransmissions of the packet indicated in the HARQ NACK over the transmission of newly arrived packets for a given stream. However, for extremely capacity-demanding and latency-critical services, not all packets are considered equally important (e.g., impact the user experience unequally), and therefore not all HARQ indicated packet retransmissions are equally important. For example, packets contributing to a video stream of the pose / frontal orientation 202 of the smart glasses device 117 may be prioritized over packets transmitted on the sides or edges (e.g., for use in the face of a camera) because the pose portion is more easily observed by the human eye. Figure 2 Therefore, the extended delay of packet transmission and corresponding HARQ packet retransmission for the service flow corresponding to the posture portion 202 of the smart glasses device 117 may cause user dizziness and bring various safety risks, while similar packet delay for the flow corresponding to the peripheral portion 204 or 206 may not produce a perceptibly degraded experience for the user of the VR smart glasses device.

[0100] Therefore, blindly prioritizing HARQ packet retransmissions over new packet arrivals may ignore the importance of the new packets and the corresponding potential delay tolerance associated with each payload retransmission, and instead retransmit non-critical, less critical, or less important packet payloads corresponding to the HARQ indicated retransmission requests, with the result that new critical packet arrivals may present extended buffering delays.

[0101] The embodiments disclosed herein minimize blind prioritization of HARQ payload retransmissions over transmissions of newly arrived packets by taking into account the importance of packets or other portions of a traffic flow (e.g., taking into account the impact that delayed packets may have on the user's experience) and the scheduling delay tolerance. Thus, in the case where multiple packets are indicated for retransmission in a HARQ retransmission indication, the embodiments disclosed herein reduce the buffering delay of new critical packets arriving at the RAN for transmission to the UE. Utilizing a delay-aware HARQ feedback process as disclosed herein, the RAN node scheduler can be made aware of the delay tolerance associated with the payload retransmission of each HARQ indication, so that the RAN can avoid blind HARQ retransmission prioritization. The embodiments disclosed herein can also facilitate schemes for HARQ feedback reporting and overhead compression to dynamically weigh the consumption of uplink resources used to report HARQ feedback reports against the HARQ feedback reporting delay.

[0102] Figure 2 A virtual reality ("VR") application system 200 is shown. In system 200, a wearable VR device 117 is shown from the perspective of a wearer (or viewer). VR device 117 can include a center (or posture) visual display portion 202, a left visual display portion 204, and a right visual display portion 206, which can be used to display primary visual information, left peripheral visual information, and right peripheral visual information, respectively. As shown in the figure, portions 202, 204, and 206 are outlined by different lines, but it will be appreciated that hardware or software can facilitate a gradual transition from primary information display to peripheral information display.

[0103] As discussed above, different XR use cases may require different corresponding radio performance. In general, for XR use cases, but unlike URLLC or eMBB use cases, in order to obtain a reasonable end-user experience, a high-capacity radio link is required that carries XR data traffic (e.g., data streams including visual information) at stringent radio levels (e.g., latency) and reliability levels. For example, some XR applications require a 100Mbps link with an allowed radio latency of approximately 2ms, compared to a 5Mbps URLLC link with a 1ms radio latency budget.

[0104] Based on research, several characteristics of XR data services have been identified: (1) XR service characteristics are often periodic, with time-varying packet sizes and packet arrival rates; (2) XR-enabled devices may be more power-constrained than traditional mobile phones (e.g., smart glasses, projection-based wearable devices, etc.) due to their limited form factors; (3) Multiple data packet streams corresponding to different visual information for a given XR session are not perceived by the user as having the same impact on the end-user experience.

[0105] Therefore, in addition to the need for XR-specific power efficiency, smart glasses (such as wearable device 117) also require broadband capacity to provide an optimal user experience when streaming 180-degree high-resolution frames. However, it has been determined that data corresponding to frames carrying primary or central visual information (i.e., posture or frontal orientation) is critical to end-user satisfaction, while frames corresponding to peripheral visual information have less impact on the user's experience. Therefore, accepting higher latency for less important traffic flows so that resources originally allocated to less important traffic flows can be used for traffic flows corresponding to more important traffic flows or devices carrying more important traffic can be used to optimize the overall capacity and performance of wireless communication systems (such as 5-G communication systems using NR technology, methods, systems, or devices). For example, wireless data traffic carrying visual information for display on the center or posture visual display portion 202 can be given higher priority than wireless data traffic traffic carrying visual information for the left visual display portion 204 or for the right visual display portion 206.

[0106] The performance of a communication network in providing XR services may be determined, at least in part, by the satisfaction of users of the XR services. Each user of an XR service may be associated with certain QoS metrics to meet the user's performance goals for the service in terms of perceived data rate, end-to-end latency, and reliability.

[0107] 5G NR radio systems typically include a physical downlink control channel ("PDCCH") that can be used to deliver downlink and uplink control information to cellular devices. The 5G control channel can facilitate operation according to the requirements of URLLC and eMBB use cases and can promote efficient coexistence between such different QoS classes.

[0108] Traffic 210 directed to UE 115 for an XR session at device 117 may arrive at RAN 105 from core network 130 via radio link 125. It will be appreciated that UE 115 and device 117 may be distinct devices, or that the components comprising or forming UE 115 and device 117 may be combined into device 208, such as an XR device including components that facilitate wireless communication with RAN 105. For purposes of this discussion, UE 115 and device 117 may be referred to as separate devices. Traffic 210 may be buffered at RAN 105. Link 125 may be subject to interference or other network conditions that may result in errors in receiving any packets 212, 214, or 216 corresponding to the same or different traffic flows of portions 202, 204, and 206, respectively, of traffic 210 directed to device 117.

[0109] Due to an error caused by a transmission problem between the RAN 105 and the UE 115, the UE may determine to transmit a retransmission request indication 220 to the RAN. The retransmission request indication 220 may include a HARQ NACK message or an indication requesting a retransmission. For example, the retransmission request indication 220 may include an indication to the RAN 105 to retransmit one of the packets 212, but not a request to retransmit one or more of the packets 214 or 216, even though the packets 212, 214, and 216 may all correspond to a given traffic flow 210 directed to the UE 115 for the same VR / XR session. The determination by the UE 115 to request retransmission of some, but not all, of the packets 212, 214, or 216 may be based on a quality of service criterion (e.g., a latency criterion) corresponding to the packets 212, 214, or 216 or to one or more flows of which the packets are part. For example, because packet 212 may be intended for rendering images via gesture portion 202 of device 117, more stringent quality of service standards or tolerances (e.g., jitter tolerance, packet loss tolerance, or latency tolerance) may apply to packet 212, but different, less stringent standards or tolerances may apply to packets 214 or 216 because the wearer of device 117 is more sensitive to blur or other types of distortion that may negatively impact images rendered in gesture portion 202 compared to peripheral portions 204 or 206 of the device.

[0110] Delay-aware packet retransmission.

[0111] As discussed above, conventional HARQ retransmission processes typically support ACK or NACK as HARQ feedback, which is transmitted from the user equipment to the serving cell RAN, indicating packet decoding success or failure, respectively. Scheduling at the RAN node may blindly prioritize retransmissions of packets corresponding to NACKs over transmissions of new packets arriving at the RAN destined for the user equipment. For high-data-volume, low-latency services such as VR, not all packets are equally important, and therefore not all packet retransmissions are equally important. In situations where many non-critical packets are indicated for retransmission, network resource capacity may be consumed by retransmissions, which may effectively preempt the transmission of newly arriving packets.

[0112] The techniques and embodiments disclosed herein can configure a user equipment, or use a configuration at a user equipment, to generate and report a delay-aware HARQ NACK feedback retransmission indication that can provide a network scheduler at the RAN with information about an allowable delay budget (e.g., a delay criterion) corresponding to a traffic payload portion (such as a packet, multiple packets, data frame, etc.) requested to be retransmitted by the user equipment. Thus, at the RAN, the conventional blind prioritization of packet retransmissions over possible critical new packet arrivals can be avoided.

[0113] In one embodiment, the network RAN ​​may generate a codebook defining multiple HARQ NACK indications, where each NACK is associated with a configured delay budget (e.g., one or more delay criteria). Thus, at a user equipment (UE), upon determining that decoding of a received downlink payload has failed, the UE may determine an application-specific (e.g., a VR application running on a VR device (such as a smart glasses device)) allowable delay for packet retransmissions, so as not to impact the user experience due to blindly prioritizing packet retransmissions. Thus, the UE may select a HARQ NACK retransmission indication for packets of a stream that may have been received with errors, the indication being associated with a delay range in the configured codebook that corresponds to the allowable delay for the stream as determined by the application (e.g., the VR application running on the VR device). In the case where the UE receives multiple streams, multiple different HARQ process identifiers corresponding to one or more different traffic flows may facilitate the RAN associating reported delay-aware HARQ NACK retransmission indication feedback messages with a subset of active HARQ process identifiers or traffic flows. For delay-aware NACK indications, reporting overhead usage may increase, and the delay-aware NACK indication may include more bits than a traditional NACK (which is not delay-aware) for reporting NACK indications for critical traffic flows, but HARQ retransmissions can then be prioritized based on a true and near-real-time allowable delay budget as determined at the application layer (e.g., by the device application itself). Therefore, the network RAN ​​resource scheduler can flexibly, intelligently, and dynamically schedule old packet retransmissions (e.g., packets that have been previously transmitted one or more times) and transmissions of newly arrived packets based on receiving the delay-aware NACK retransmission request indication, without having the transmission of the new packet dominated or effectively preempted by the retransmission of the pending old non-critical packets, thereby minimizing the impact of insufficient resource capacity on the transmission of the newly arrived critical packets.

[0114] By using retransmission indications that can vary in size to accommodate different priorities for indicating traffic flows or parts of traffic flows (such as, for example, packets of an important traffic flow directed to a particular application), the radio access network RAN ​​can prioritize the scheduling of more important packets of the important flow relative to less important packets of the important flow, rather than scheduling the less important packets for retransmission first and then retransmitting or transmitting the more important packets of the flow. This can be thought of as effectively "preempting" the transmission / retransmission of the more important packets by the retransmission of the less important (but potentially still important) packets. For example, in order to process traffic to be transmitted on a VR device such as Figure 2 The business flow of the VR application of the image rendered on the device 117) shown in FIG may carry the image to be rendered on the device 117) shown in FIG. Figure 2 One or more packets, images, or frames rendered in the posture portion 202 of the VR device 117 shown in FIG may be more important than the traffic flow carrying the images or frames to be rendered in the portion 204 or 206 of the VR device. Latency-aware multi-bit HARQ feedback (which may be referred to as a retransmission indication) may be associated with one or more specific HARQ process identifiers, and this association may facilitate the RAN to absorb or weigh the additional reporting overhead used by the latency-aware retransmission indication HARQ NACK for important flows (e.g., compared to the less reporting overhead used by conventional non-latency-aware feedback) and determine a set or subset of important flows for which latency-aware multi-bit HARQ feedback is enabled.

[0115] Now go to Figure 3A , which illustrates an example codebook 300 or mapping of HARQ NACK indications 305 to configured, application-specific allowable delay budgets 310, which may be referred to as delay criteria / delay criteria or delay functions. The codebook 300, which may include retransmission request configuration data representing a retransmission request configuration and may be referred to as a retransmission request configuration, may be "signaled" or transmitted to a user equipment (UE) via, for example, radio resource control ("RRC") signaling as part of a connection establishment procedure or as part of a dynamic configuration of downlink control information ("DCI"). Upon failure to decode a downlink received packet, the UE may formulate a delay-specific HARQ feedback report by selecting and transmitting a HARQ NACK indication 305 or sequence corresponding to a delay range or criteria 310 that satisfies the delay tolerance or requirements of an application (e.g., a VR application) running on the UE. The allowable delay or requirement may be determined from the application layer (e.g., a VR application may communicate a delay requirement for a particular quality of service), such that any delay impact on the end-user experience is mitigated by the corresponding criteria or criteria 310.

[0116] After the network RAN ​​receives HARQ NACK indications corresponding to different delay budgets, the scheduler at the RAN can dynamically schedule packet retransmissions and new packet arrivals for different devices in an efficient manner, avoiding such transmissions or retransmissions from being dominated by (e.g., essentially preempted by) retransmissions of non-critical packets, while also scheduling transmissions or retransmissions of critical / important packets with strict delay budgets to facilitate prioritizing the transmissions or retransmissions of such critical / important packets, so that they are not ignored (e.g., buffered at the RAN) in favor of less important traffic packets. As part of the codebook configuration 300, some entries of the recommended HARQ feedback listed in the codebook can be set to NULL or to an extended delay exceeding a threshold, instructing the serving cell RAN node to forgo scheduling packet retransmissions corresponding to packets associated with retransmission indications containing NULL entries. Different HARQ process identifiers 315 can be associated with different retransmission request indication configurations 300. The RAN can indicate to the user equipment which HARQ process identifiers 315 correspond to one configuration 300 or another configuration 300. This determination and instruction may be based on network conditions and may instruct the user equipment to use a configuration 300 with a smaller (e.g., fewer bits) retransmission request indicator when network conditions (particularly uplink conditions) are constrained, and may instruct the user equipment to use a configuration 300 with a larger retransmission request indicator when network conditions are less constrained. The RAN may instruct the RAN to use a default one-bit NACK based on network conditions. If more precise priority scheduling may benefit the network conditions, the RAN may instruct the user equipment to use a larger retransmission request identifier for specific services.

[0117] Now go to Figure 3B, two different HARQ feedback reports may be transmitted from the user equipment. A fixed-size ACK report 325 corresponding to a particular packet, code block, code block group, or complete transport block may be transmitted to indicate that the user equipment transmitting the ACK report successfully received and decoded the packet, code block, code block group, or complete transport block. The ACK report 325 may include a size of 1 bit. Due to the dynamic configuration of the HARQ NACK level in the configured HARQ NACK codebook 300, the HARQ NACK report (which may be referred to herein as a retransmission request indication) may have a variable size. The NACK feedback report 330 may include a retransmission request indication 305. Depending on the number of different functions, ranges, or criteria 310 configured in the codebook 300 (e.g., the number of An rows), the size of the retransmission request indication 305 may include different bits. For example, if the codebook 300 includes four different configured delay functions, ranges, or criteria 310, the NACK feedback report 330 may include two bits; if the codebook includes sixteen rows corresponding to sixteen different delay functions / ranges / criteria, the NACK feedback report 330 may include four bits to represent the different ranges 310. In one embodiment, for a serving cell RAN node, when targeting higher delay accuracy for one or more HARQ processes, the RAN node may configure a user equipment device with a plurality of levels (e.g., Figure 3A 3. The HARQ NACK codebook 300 includes a large number of rows A–n in the codebook 300, wherein the delay criteria associated with each HARQ NACK indication can span a decreasing range, thereby increasing the number of HARQ NACK indications 305 associated with a flow (and improving the accuracy of quality of service and priority). The more ranges 310 there are in the codebook 300 (e.g., the more rows An), the correspondingly increased number of bits (overhead) used for the indications 305 in the HARQ NACK report, and vice versa (a smaller number of ranges 310 results in fewer bits used for the indications 305, but also lower accuracy of the priority / quality of service corresponding to the flow conveyed to the RAN by the indications 305). Uplink control channel resources (which can carry uplink HARQ feedback from the user equipment) can be dynamically allocated from the RAN node to accommodate the HARQ NACK report configuration size of the user equipment for the indications 305. (Suitability can be based on the quality of service required by a particular application running or executing on the user equipment).

[0118] Now go to Figure 4, which shows a timing diagram 400 illustrating the operation of a UE 115 using a retransmission request configuration to indicate to the RAN 105 the scheduling priority of traffic packets that may not have been correctly received at the UE. At act 405, the RAN 105 transmits and the UE 115 receives a delay-aware retransmission request configuration including a delay-aware hybrid automatic repeat request (HARQ) feedback indication (which may be referred to as a retransmission transmission request indication). The retransmission request configuration may include a list or codebook of HARQ priority indications and their corresponding respective latency criteria or ranges. The UE 115 may use the codebook to determine a retransmission request indication associated with a HARQ process identifier for a traffic flow that activates transmission and reporting of the HARQ priority indication. Such activation may be determined by an application running on the UE 115 (e.g., a VR application that facilitates the use of a VR device). At act 410, the UE / WTRU 115 receives and blindly decodes downlink control information and determines the scheduled downlink resource allocation and the associated HARQ process ID for the traffic flow. In the event that transmission and reporting of a HARQ priority indication using a codebook is activated for the determined current HARQ process ID and the UE fails to decode the payload (e.g., packet, codeblock, or transport block), the UE / WTRU determines, at action 415, an acceptable application-specific latency for HARQ retransmissions that the VR application can tolerate before the device-specific quality of experience is affected. At action 420, the UE / WTRU determines, from the configured HARQ priority list or codebook, a HARQ priority indication that corresponds to an acceptable latency range that meets or matches the determined application-specific retransmission latency requirement. At action 425, the UE / WTRU 115 transmits the determined HARQ priority / delay retransmission request indication to the RAN node 105 in a HARQ NACK report, which may include a latency corresponding to the application-specific retransmission latency requirement as described above with reference to FIG. Figure 3A The number of bits of precision indicated by the described retransmission request.

[0119] Delay-driven HARQ feedback reporting and feedback overhead compression.

[0120] Because HARQ feedback is frequently transmitted on each device and to maximize radio reliability for critical services, the HARQ feedback indication transmitted from the user equipment device to the serving cell RAN can indicate uplink control usage and corresponding capacity. HARQ feedback semi-static and dynamic codebooks can be used to aggregate HARQ feedback across several downlink payload reception times, i.e., reporting aggregated HARQ feedback for multiple received packets, rather than transmitting dedicated HARQ feedback for each received downlink packet. Conventional methods do not implement the novel latency-aware HARQ feedback embodiments disclosed herein.

[0121] A UE device may be configured by a serving cell RAN with a list or map of HARQ feedback combinations, with a configuration length corresponding to the combination, which may be dynamically configured. The HARQ feedback combination may include HARQ ACK and NACK sequences determined over a specific number of previous packet reception instances, wherein the HARQ NACK indication is a latency-aware indication and is associated with a maximum allowable latency for such packet retransmissions as disclosed above. The UE device may select and report only index values ​​corresponding to combinations in the list, where the list includes the determined HARQ combinations within a configured reporting period (e.g., a determined or configured number of packet reception instances).

[0122] The HARQ feedback reports may consume a significant amount of uplink channel resource capacity because the HARQ feedback may be frequent for a given UE device and a single HARQ process ID or traffic flow. Adding delay-aware information to the HARQ NACK report may expand the size of the corresponding HARQ report, as described above (e.g., more than one bit for a delay-aware retransmission request indication). Therefore, a delay-aware HARQ NACK report overhead compression embodiment may be used. In one embodiment, the HARQ reporting period may be defined such that the device transmits only a single HARQ feedback report indicating multiple feedback indications during each configured period. Therefore, a compressed delay-aware HARQ report may correspond to several delay-aware indications (ACK or NACK indications) of packets received during the configured period. Therefore, as Figure 5 As shown in , a retransmission request indication compression configuration for HARQ feedback combinations, such as codebook 500, may associate a compression index 510 with a plurality of HARQ retransmission request indications 515, 520, and 525. (It will be appreciated that some combinations of indices 515, 520, and 525 may include one or more ACK indications indicating that a packet at the corresponding packet instance was successfully received and decoded.) A reporting period may span packet instances or time slots n, n-1, n-2, and so on, where time instant n may also be a reporting instance, and where time instants n-1 and n-2 indicate time slots during which packets were received before a packet was received at time slot n. As shown in codebook 500, row An of the codebook corresponds to a configured HARQ feedback reporting sequence of ACKs and NACKs for a configured HARQ reporting period (which may be referred to as a compressed reporting period, or simply a compressed period). Figure 5 As depicted in , an example of configuring a HARQ reporting period of three slots, where each row of the codebook indicates a specific HARQ combination of ACK and delay-aware NACK within a reporting period of three slots.

[0123] If the UE device is not scheduled during any time slot in the three time slot cycle, the UE device may be configured to report a predefined compression index corresponding to the three time slots or time instants, such that the size of the HARQ report compression index is fixed to facilitate decoding at the serving RAN side without the need for blind decoding. Figure 5 At each of the time instants n) shown in , the UE device may transmit a single HARQ report compression index 510 or HARQ indication preamble that corresponds to a combination of HARQ ACKs and delay-aware NACKs 515, 520, and 525 (e.g., a row in the configured HARQ report codebook 500) within the compressed reporting period. HARQ reports using compressed indices, which may include preamble or sequence transmissions rather than bit-by-bit indications for each received packet, may be more robust against channel errors (which may flip an indication into what appears to be another erroneous indication) and may therefore enhance the reliability of the HARQ reports.

[0124] Now go to Figure 6 , which shows that UE 115 uses a compressed retransmission request indication (such as reference Figure 5 A timing diagram of an embodiment method 600 for a compressed index as described herein. Figure 6As described above, at act 605, the UE / WTRU 115 receives a configuration for dynamic reporting of latency-aware HARQ priority indications from the serving RAN node 105, which may include an indication compression codebook having one or more entries or rows, wherein each entry includes a combination of HARQ NACK priority indications or HARQ ACK indications within a configured compression period (e.g., a configured packet reception instance), the configured compression period starting before and ending at a configured HARQ feedback reporting instant (e.g., when a HARQ feedback report is transmitted and indicates a compression index corresponding to each HARQ indication of a packet transmission received during the compression period). At act 610, the UE / WTRU 115 receives and blindly decodes the downlink control information and determines downlink resources to be allocated or already allocated for receiving a scheduled downlink traffic flow and determines one or more HARQ process identifiers to be used in conjunction with reporting the HARQ indications. At act 615, with the transmission and dynamic reporting of the HARQ priority indication for the determined current HARQ process identifier activated within the configured HARQ compressed reporting period, the UE / WTRU 115 collects and determines individual delay-aware HARQ NACK priority indications and HARQ ACK indications for downlink packet transmissions received within the configured HARQ compressed reporting period. At act 620, the UE / WTRU 115 determines and selects from the HARQ compressed feedback codebook a compression index corresponding to a combination of individual HARQ feedback indicators that matches the actual ACK or NACK indication that would have been reported individually for packet reception during the configured HARQ compressed reporting period. At act 625, the UE / WTRU transmits the compression index of the selected HARQ feedback codebook row determined at act 620 during a scheduled HARQ feedback control opportunity.

[0125] Now go to Figure 7This figure illustrates a flow chart of an embodiment method 700 for configuring a UE with a retransmission request configuration for use by the UE to determine a retransmission request indication to be used by the RAN to prioritize packets for retransmission to the UE. Method 700 begins at act 705. At act 710, a RAN node device transmits one or more retransmission request configurations to one or more user equipment. The RAN may transmit the retransmission request configurations via RRC signaling. At act 715, the user equipment receives the retransmission request configurations that may have been transmitted at act 710. At act 720, the user equipment receives a packet of a traffic flow at a previously scheduled time for receiving traffic payload packet data. At act 725, the user equipment attempts to decode the packet received at act 720. At act 730, the user equipment determines whether the attempt to decode the packet at act 725 was successful. If it is determined that decoding the packet at act 725 was successful, method 700 proceeds to act 745.

[0126] Returning to the description of act 730, if the user device determines at act 725 that the attempt to decode the packet received at act 720 was unsuccessful, method 700 proceeds to act 735. At act 735, the user device determines the quality of service associated with the traffic flow of which the packet received at decode 720 is a part. The determination at act 735 may be performed by an application (e.g., a VR application) running on the user device. The application may be managing multiple streams supporting a VR session. The stream of which the packet received at act 720 is a part may be one of the multiple streams being managed by the VR application, and the quality of service associated with the stream may be different from another stream that the application is also managing for the VR session. It will be appreciated that the packet received at act 720 and the quality of service associated therewith may correspond to a traffic flow, a quality of service requirement (e.g., a latency requirement), and an identifier associated with the traffic flow. At act 740, the user device determines a retransmission request indication using the retransmission request configuration received at act 715. Determining the retransmission request indication may be based on the quality of service determined at act 735. Determining the retransmission request indication at act 740 can be based on an analysis of the quality of service determined at act 735 with respect to a latency criterion, multiple latency criteria, or latency range corresponding to the indication determined at act 740. An application at the user device, such as a VR application, can determine a latency criterion range for determining the retransmission request indication based on a sensed degradation in the user experience corresponding to the traffic flow. For example, if the VR application detects that the performance of the VR session in the gestural portion of the VR device is within an acceptable performance range (which can correspond to, but may not necessarily be, the same criterion or range in the retransmission request configuration), the VR application can cause the user device to select a range and corresponding retransmission request indication in the retransmission request configuration corresponding to a first priority level. However, if the user's performance has degraded such that the traffic facilitating vision in the gestural portion of the VR application is causing visual distortion, the user device can determine that the traffic flow requires a higher quality of service and, therefore, can select a retransmission request indication with a higher priority level from the retransmission request configuration.

[0127] After determining the retransmission request indication at act 740, method 700 proceeds to act 745 and determines whether the user equipment has been configured to use compression of the retransmission request. The configuration received at act 715 may include a compression configuration that associates a determined combination of a retransmission request indication or an acknowledgment indication indicating successful decoding of the received packet with a compression index. The combination of an acknowledgment indication (e.g., ACK) or a retransmission request indication (e.g., delay-aware NACK) may include a determined number or value corresponding to a determined number of packet instances of the packet received at act 720 that are attempted to be decoded at act 725. The determined number of packet instances may be referred to as a compression period.

[0128] If, at act 745, it is determined that the UE is configured to perform compression of retransmission request indications, method 700 proceeds to act 770. At act 770, the user equipment may determine that a compression period has not yet run (e.g., the configured number of attempts to decode the packet at act 725 have not yet been performed), in which case method 700 returns to act 720. If, at act 770, it is determined that the determined or configured number of attempts to decode the packet at act 725 have already been performed, method 700 proceeds to act 775 and transmits a compression index. For example, if the configured compression period includes a configured number of five retransmission request indications or acknowledgment indications, and the user equipment determines at act 745 that compression of the retransmission request indication is to be performed, five iterations of acts 720 through 745 may be performed. After determining at act 770 that the compression period (or the number of iterations of attempts to decode the packet) has not expired, method 700 returns to act 720. If, at act 730, the number of attempts to decode the packet equals the number of packet instances determined within the configured compression period, method 700 proceeds to act 775. At action 775, the user equipment transmits a compression index corresponding to the configured combination of the retransmission request indication or the acknowledgement indication associated with the compression index.

[0129] Returning to the discussion of act 745, if the user equipment determines not to use compression, method 700 proceeds to act 750. At act 750, if the decoding attempt at act 725 is successful, the user equipment transmits a retransmission request indication, or if the decoding performed at act 725 is successful, the user equipment transmits an acknowledgment indication. The retransmission request or acknowledgment indication may be transmitted to the RAN, which transmitted the configuration to the user equipment at act 710. At act 755, the user equipment receives a schedule for packet retransmission instances and a schedule for transmission of new packet instances (e.g., whether the new packet is a packet not yet received at act 720 or a packet not yet attempted to be decoded at act 725), based on the priority indicated in the retransmission request indication transmitted at act 750 or based on the number of retransmission indication requests indicated by the compression index transmitted at act 775. At act 760, the user equipment receives the retransmitted packet or the new packet according to the priority of the schedule received at act 755. Method 700 proceeds to act 765 and ends.

[0130] Now go to Figure 8, which shows an example embodiment method 800, including, at block 805, receiving, by a user equipment including a processor, retransmission request configuration data representing a retransmission request configuration via a radio access network; at block 810, receiving, by the user equipment, a first portion of a service flow; at block 815, determining, by the user equipment, that the first portion of the service flow includes a first error; at block 820, determining, by the user equipment, a first quality of service corresponding to the service flow; at block 825, analyzing, by the user equipment, the first quality of service with respect to at least one delay function specified by the retransmission request configuration to obtain an analyzed first quality of service; at block 830, determining, by the user equipment, using the retransmission request configuration, a first retransmission request indication corresponding to the analyzed first quality of service; at block 835, transmitting, by the user equipment, via the radio access network, a first retransmission request indication indicating a first retransmission priority for retransmission of the first portion of the service flow; and at block 840, receiving, by the user equipment, in response to the first retransmission request indication, first retransmission data representing a first retransmission of the first portion of the service flow according to the first retransmission priority.

[0131] Now go to Figure 9 , the figure shows an example user equipment 900, which includes a processor configured to: at block 905, receive a first portion of a first service flow via a radio access network; at block 910, determine that the first portion of the first service flow includes a first error; at block 915, receive a second portion of a second service flow via the radio access network; at block 920, determine that the second portion of the second service flow includes a second error; at block 925, determine a first quality of service corresponding to the first service flow; at block 930, determine a second quality of service corresponding to the second service flow; at block 935, analyze the first quality of service with respect to a first delay range defined by a first retransmission request configuration to obtain an analyzed first quality of service; at block 940, analyze the second quality of service with respect to a second delay range defined by a second retransmission request configuration to obtain an analyzed second quality of service amount; at block 945, determining a first retransmission request indication corresponding to the analyzed first quality of service according to the first retransmission request configuration; at block 950, determining a second retransmission request indication corresponding to the analyzed second quality of service according to the second retransmission request configuration; at block 955, transmitting via the radio access network a first retransmission request indication indicating a first priority associated with the first business flow; at block 960, transmitting via the radio access network a second retransmission request indication indicating a second priority associated with the second business flow; at block 965, receiving, via the radio access network, in response to the first retransmission request indication, a first retransmission of the first part of the first business flow according to the first priority; and at block 970, receiving, via the radio access network, in response to the second retransmission request indication, a second retransmission of the second part of the second business flow according to the second priority.

[0132] Now go to Figure 10 , the figure shows a non-transitory machine-readable medium 1000, which includes a non-transitory machine-readable medium, the non-transitory machine-readable medium including executable instructions that, when executed by a processor of a user equipment, facilitates the performance of operations, the operations including: at block 1005, receiving a first retransmission request configuration from a network device of a radio access network; at block 1010, receiving a second retransmission request configuration from the network device; at block 1015, receiving a first portion of a first traffic flow; at block 1020, receiving a second portion of a second traffic flow; at block 1025, determining that the first portion of the first traffic flow includes a first error and the second portion of the second traffic flow includes a second error; at block 1030, determining a first quality of service corresponding to the first portion of the first traffic flow and a second quality of service corresponding to the second traffic flow a second quality of service for a second portion of the stream; at block 1035, analyzing the first quality of service with respect to at least one first delay criterion of the first retransmission request configuration to obtain an analyzed first quality of service; at block 1040, analyzing the second quality of service with respect to at least one second delay criterion of the second retransmission request configuration to obtain an analyzed second quality of service; at block 1045, determining a first retransmission request corresponding to the analyzed first quality of service and having a first retransmission priority based on the first retransmission request configuration; at block 1050, determining a second retransmission request corresponding to the analyzed second quality of service and having a second retransmission priority based on the second retransmission request configuration; and at block 1055, transmitting a first retransmission request indication indicating at least the first retransmission request or the second retransmission request to the network device.

[0133] To provide additional context for the various embodiments described herein, Figure 11 The following discussion is intended to provide a brief, general description of a suitable computing environment 1100 in which various of the embodiments described herein may be implemented. Although the embodiments have been described above in the general context of computer-executable instructions that may be executed on one or more computers, those skilled in the art will recognize that the embodiments may also be implemented in combination with other program modules and / or as a combination of hardware and software.

[0134] Generally, program modules include routines, programs, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that these methods can be practiced in other computer system configurations, including single-processor or multi-processor computer systems, minicomputers, mainframe computers, Internet of Things devices, distributed computing systems, as well as personal computers, handheld computing devices, microprocessor-based or programmable consumer electronics, etc., each of which can be operably coupled to one or more associated devices.

[0135] The embodiments described herein can also be practiced in distributed computing environments where certain tasks are performed by remote processing devices that are linked through a communications network.In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

[0136] Computing devices typically include various media, which may include computer-readable storage media, machine-readable storage media, and / or communication media, the two terms being used differently herein as follows. A computer-readable storage medium or machine-readable storage medium can be any available storage medium that can be accessed by a computer, and includes both volatile and non-volatile media, and both removable and non-removable media. For example, but not limited to, a computer-readable storage medium or machine-readable storage medium can be implemented in conjunction with any method or technology for storing information, such as computer-readable or machine-readable instructions, program modules, structured data, or unstructured data.

[0137] Computer-readable storage media may include, but are not limited to, random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CDROM), digital versatile disk (DVD), Blu-ray disk (BD) or other optical disk storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices, solid-state drives or other solid-state storage devices, or other tangible and / or non-transitory media that can be used to store the desired information. The terms "tangible" or "non-transitory" as applied to storage devices, memories, or computer-readable media herein should be understood as modifiers to exclude only those that propagate transient signals themselves, and do not disclaim all standard storage devices, memories, or computer-readable media that do not propagate only transient signals themselves.

[0138] Computer-readable storage media can be accessed by one or more local or remote computing devices, eg, via access requests, queries, or other data retrieval protocols, to perform various operations with respect to the information stored by the media.

[0139] Communication media typically embodies computer-readable instructions, data structures, program modules, or other structured or unstructured data in a data signal (such as a modulated data signal, such as a carrier wave or other transport mechanism), and includes any information delivery or transmission media. The term "modulated data signal" or signal refers to a signal whose one or more characteristics are set or changed in such a way as to encode information in one or more signals. For example, but not limited to, communication media include wired media (such as a wired network or a direct-wired connection) and wireless media (such as acoustic, RF, infrared, and other wireless media).

[0140] Reference again Figure 11, an example environment 1100 for implementing various embodiments of the aspects described herein includes a computer 1102 that includes a processing unit 1104, a system memory 1106, and a system bus 1108. The system bus 1108 connects system components (including, but not limited to, the system memory 1106) to the processing unit 1104. The processing unit 1104 can be any of a variety of commercially available processors and can include cache memory. Dual microprocessors and other multi-processor architectures can also be used as the processing unit 1104.

[0141] The system bus 1108 can be any of several types of bus structures that can also interconnect with a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures. The system memory 1106 includes ROM 1110 and RAM 1112. A basic input / output system (BIOS) containing the basic routines that help transfer information between elements within the computer 1102, such as during startup, can be stored in a nonvolatile memory such as ROM, erasable programmable read-only memory (EPROM), or EEPROM. RAM 1112 can also include high-speed RAM, such as static RAM for caching data.

[0142] The computer 1102 also includes an internal hard disk drive (HDD) 1114 (e.g., EIDE, SATA), one or more external storage devices 1116 (e.g., a floppy disk drive (FDD) 1116, a memory stick or flash drive reader, a memory card reader, etc.), and an optical drive 1120 (e.g., which can read or write from a CD-ROM, DVD, BD, etc.). Although the internal HDD 1114 is shown as being located within the computer 1102, the internal HDD 1114 can also be configured for external use in a suitable chassis (not shown). In addition, although not shown in the environment 1100, a solid-state drive (SSD) can be used in addition to or instead of the HDD 1114. The HDD 1114, the external storage device(s) 1116, and the optical drive 1120 can be connected to the system bus 1108 via an HDD interface 1124, an external storage interface 1126, and an optical drive interface 1128, respectively. The interface 1124 for external drive implementations may include at least one or both of Universal Serial Bus (USB) and Institute of Electrical and Electronics Engineers (IEEE) 1194 interface technologies.Other external drive connection technologies are within the contemplation of the embodiments described herein.

[0143] The drives and their associated computer-readable storage media provide non-volatile storage of data, data structures, computer-executable instructions, and the like. For computer 1102, the drives and storage media can be adapted to store any data in a suitable digital format. Although the above description of computer-readable storage media refers to corresponding types of storage devices, those skilled in the art will appreciate that other types of computer-readable storage media (whether currently available or developed in the future) can also be used in the example operating environment, and further, any such storage media can contain computer-executable instructions for performing the methods described herein.

[0144] A number of program modules may be stored in the drives and RAM 1112, including an operating system 1130, one or more application programs 1132, other program modules 1134, and program data 1136. All or portions of the operating system, applications, modules, and / or data may also be cached in RAM 1112. The systems and methods described herein may be implemented with various commercially available operating systems or combinations of operating systems.

[0145] Computer 1102 may optionally include emulation technology. For example, a virtual machine manager (not shown) or other intermediary may emulate the hardware environment of operating system 1130, and the emulated hardware may optionally communicate with the operating system 1130. Figure 11 1102. In such an embodiment, the operating system 1130 may include one of multiple virtual machines (VMs) hosted at the computer 1102. In addition, the operating system 1130 may provide a runtime environment, such as a Java runtime environment or a .NET framework, for the application 1132. The runtime environment is a consistent execution environment that allows the application 1132 to run on any operating system that includes a runtime environment. Similarly, the operating system 1130 may support containers, and the application 1132 may take the form of a container, which is a lightweight, independent, executable software package that includes, for example, the application's code, runtime, system tools, system libraries, and settings.

[0146] In addition, the computer 1102 may include a security module, such as a Trusted Processing Module (TPM). For example, using a TPM, the boot component hashes the next boot component in time and waits for the result to match a guaranteed value before loading the next boot component. This process can be performed at any layer in the code execution stack of the computer 1102, for example, at the application execution level or at the operating system (OS) kernel level, thereby achieving security at any code execution level.

[0147] A user can enter commands and information into the computer 1102 through one or more wired / wireless input devices, such as a keyboard 1138, a touch screen 1140, and a pointing device such as a mouse 1142. Other input devices (not shown) may include a microphone, an infrared (IR) remote control, a radio frequency (RF) remote control, or other remote control, a joystick, a virtual reality controller and / or a virtual reality headset, a game pad, a stylus, an image input device (e.g., camera(s)), a gesture sensor input device, a visual movement sensor input device, an emotion or facial detection device, a biometric input device (e.g., a fingerprint or iris scanner), and the like. These and other input devices are typically connected to the processing unit 1104 through an input device interface 1144, which may be coupled to the system bus 1108, but may be connected through other interfaces, such as a parallel port, an IEEE 1194 serial port, a game port, a USB port, an infrared port, a fingerprint scanner, or the like. Interface, etc., connection.

[0148] A monitor 1146 or other type of display device may also be connected to the system bus 1108 via an interface, such as a video adapter 1148. In addition to the monitor 1146, computers typically include other peripheral output devices (not shown), such as speakers, printers, and the like.

[0149] Computer 1102 can operate in a networked environment, using logical connections to one or more remote computers, such as remote computer(s) 1150, via wired and / or wireless communications. Remote computer(s) 1150 can be workstations, server computers, routers, personal computers, portable computers, microprocessor-based entertainment devices, peer devices, or other common network nodes, and typically include many or all of the elements described with respect to computer 1102, but for simplicity, only memory / storage device 1152 is shown. The depicted logical connections include wired / wireless connectivity to a local area network (LAN) 1154 and / or a larger network, such as a wide area network (WAN) 1156. Such LAN and WAN networking environments are common in offices and companies and facilitate enterprise-wide computer networks, such as intranets, all of which can be connected to a global communication network, such as the Internet.

[0150] When used in a LAN networking environment, the computer 1102 can be connected to the local network 1154 through a wired and / or wireless communication network interface or adapter 1158. The adapter 1158 can facilitate wired or wireless communication with the LAN 1154, which can also include a wireless access point (AP) provided thereon for communicating with the adapter 1158 in a wireless mode.

[0151] When used in a WAN networking environment, the computer 1102 may include a modem 1160, or may be connected to a communications server on the WAN 1156 via other means, such as through the Internet, to establish communications over the WAN 1156. The modem 1160, which may be internal or external and a wired or wireless device, may be connected to the system bus 1108 via the input device interface 1144. In a networked environment, program modules related to the computer 1102, or portions thereof, may be stored in the remote memory / storage device 1152. It will be appreciated that the network connections shown are examples and that other means of establishing a communications link between the computers may be used.

[0152] When used in a LAN or WAN network environment, computer 1102 can access a cloud storage system or other network-based storage system in addition to or in lieu of the external storage device 1116 described above. Typically, the connection between computer 1102 and the cloud storage system can be established via LAN 1154 or WAN 1156, for example, via adapter 1158 or modem 1160, respectively. After computer 1102 is connected to the associated cloud storage system, external storage interface 1126 can manage the storage provided by the cloud storage system, similar to other types of external storage, with the aid of adapter 1158 and / or modem 1160. For example, external storage interface 1126 can be configured to provide access to cloud storage sources as if those sources were physically connected to computer 1102.

[0153] The computer 1102 may be operable to communicate with any wireless device or entity operatively arranged for wireless communication, such as printers, scanners, desktop and / or portable computers, portable data assistants, communication satellites, any device or location associated with a wirelessly detectable tag (e.g., a kiosk, newsstand, store shelf, etc.), and telephones. This may include Wireless Fidelity (Wi-Fi) and Wireless technology. Therefore, the communication can be a predefined structure like a traditional network or just an ad hoc communication between at least two devices.

[0154] Go to Figure 12, which shows a block diagram of an example UE 1260. The UE 1260 may include a smartphone, a wireless tablet, a laptop computer with wireless capabilities, a wearable device, a machine device that can facilitate vehicle telematics, a tracking device, a remote sensing device, etc. The UE 1260 includes a first processor 1230, a second processor 1232, and a shared memory 1234. The UE 1260 includes a radio front-end circuit 1262, which may be referred to herein as a transceiver, but which is understood to generally include transceiver circuitry, separate filters, and a separate antenna for communicating via a wireless link (such as a Figure 1 135 and 137). In addition, transceiver 1262 may include multiple sets of circuits or may be tunable to accommodate different frequency ranges, different modulation schemes, or different communication protocols to facilitate long-range wireless links (such as link 130), device-to-device links (such as link 135), and short-range wireless links (such as link 137).

[0155] continue Figure 12 As described above, UE 1260 may also include a SIM 1264 or SIM profile, which may include information stored in memory (memory 34 or a separate memory portion) to facilitate communication with Figure 1 The RAN 105 or core network 130 shown in FIG. 1 performs wireless communications. Figure 12 SIM 1264 is shown as a single component having the shape of a traditional SIM card, but it will be appreciated that SIM 1264 may represent multiple SIM cards, multiple SIM profiles, or multiple eSIMs, some or all of which may be implemented in hardware or software. It will be appreciated that a SIM profile may include information such as security credentials (e.g., encryption keys, values ​​that may be used to generate encryption keys, or information about the connection between SIM 1264 and another device (which may be a Figure 1 105 or components of the core network 130 shown in FIG). The SIM profile 1264 may also include identification information unique to the SIM or SIM profile, such as, for example, an International Mobile Subscriber Identity (“IMSI”) or information that may constitute an IMSI.

[0156] SIM 1264 is shown coupled to both first processor portion 1230 and second processor portion 1232. This implementation may provide an advantage in that first processor portion 1230 may not need to request or receive information or data from SIM 1264 that second processor 1232 may request, thereby eliminating the need for the first processor to act as a "middleman" when the second processor uses information from the SIM in performing its functions and executing applications. First processor 1230 (which may be a modem processor or baseband processor) is shown as smaller than processor 1232 (which may be a more complex application processor) to visually indicate the relative levels of complexity (i.e., processing power and performance) between the two processor portions, as well as the corresponding relative levels of operating power consumption. The advantage of keeping the second processor portion 1232 in a sleep / inactive / low power state when the UE 1260 does not need the second processor portion 1232 to execute applications and process data related to the applications is that power consumption is reduced when the UE only needs to use the first processor portion 1230 while in listening mode to monitor conventionally configured bearer management and mobility management / maintenance procedures or monitor search spaces that the UE has been configured to monitor while the second processor portion remains inactive / sleep.

[0157] The UE 1260 may also include sensors 1266, such as, for example, a temperature sensor, an accelerometer, a gyroscope, a barometer, a humidity sensor, etc., which may provide signals to the first processor 1230 or the second processor 1232. The output device 1268 may include, for example, one or more visual displays (e.g., a computer monitor, a VR device, etc.), an acoustic transducer (such as a speaker or microphone), a vibration component, etc. The output device 1268 may include software for interfacing with an output device external to the UE 1260 (e.g., a visual display, a speaker, a microphone, a tactile device, an olfactory or taste device, etc.).

[0158] The following glossary of terms, given in Table 1, may be applicable to one or more descriptions of the embodiments disclosed herein.

[0159]

[0160]

[0161] Table 1

[0162] The above description includes non-limiting examples of various embodiments. Of course, for purposes of describing the disclosed subject matter, it is not possible to describe every conceivable combination of components or methods, and those skilled in the art will recognize that further combinations and permutations of the various embodiments are possible. The disclosed subject matter is intended to embrace all such alterations, modifications, and variations as fall within the spirit and scope of the appended claims.

[0163] With respect to the various functions performed by the aforementioned components, devices, circuits, systems, etc., terms used to describe such components (including references to "means") are intended to also include any(s) structure(s) (e.g., functional equivalents) that perform the specified functions of the described components, even if not structurally equivalent to the disclosed structures. Furthermore, although a particular feature of the disclosed subject matter may have been disclosed with respect to only one of several implementations, such feature may be combined with one or more other features of the other implementations as may be desired and advantageous for any given or particular application.

[0164] As may be used herein, "exemplary" and / or "illustrative" or variations thereof are intended to mean serving as examples, instances, or illustrations. For the avoidance of doubt, the subject matter disclosed herein is not limited by such examples. Furthermore, any aspect or design described herein as "exemplary" and / or "illustrative" should not necessarily be construed as preferred or advantageous over other aspects or designs, nor is it intended to preclude equivalent structures and techniques known to those skilled in the art. Furthermore, when the terms "including," "having," "comprising," and other similar words are used in the detailed description or claims, such terms are intended to be inclusive—in a manner similar to the term "comprising" as an open transition word—and do not exclude any additional or other elements.

[0165] As used herein, the term "or" is intended to mean an inclusive "or" rather than an exclusive "or." For example, the phrase "A or B" is intended to include instances of A, B, and both A and B. Furthermore, the words "a" and "an" as used in this application and the appended claims should generally be construed to mean "one or more" unless otherwise specified or clear from context to be directed to a singular form.

[0166] As used herein, the term "set" does not include an empty set, i.e., a set having no elements. Thus, a "set" in this disclosure includes one or more elements or entities. Similarly, as used herein, the term "group" refers to a collection of one or more entities.

[0167] As used in the claims, the terms "first," "second," "third," etc., are used for clarity only and do not otherwise indicate or imply any temporal order, unless otherwise clear from the context. For example, "a first determination," "a second determination," and "a third determination" do not indicate or imply that the first determination must be performed before the second determination, or vice versa, etc.

[0168] The description of the illustrated embodiments of the present disclosure as provided herein, including what is described in the abstract, is not intended to be exhaustive or to limit the disclosed embodiments to the precise forms disclosed. Although specific embodiments and examples are described herein for illustrative purposes, as will be appreciated by those skilled in the art, modifications that are considered to be within the scope of these embodiments and examples may be made. In this regard, although the subject matter has been described herein in conjunction with various embodiments and corresponding drawings (where applicable), it should be understood that other similar embodiments may be used, or that the described embodiments may be modified and added to perform the same, similar, alternative or replacement functions as the disclosed subject matter without departing from the disclosed subject matter. Therefore, the disclosed subject matter should not be limited to any single embodiment described herein, but should be interpreted in the breadth and scope according to the appended claims.

Claims

1. A method comprising: receiving, by a user equipment comprising a processor via a radio access network, retransmission request configuration data representing a retransmission request configuration; Receiving, by the user equipment, a first part of a traffic flow; determining, by the user equipment, that the first portion of the traffic flow includes a first error; Determining, by the user equipment, a first quality of service corresponding to the service flow; analyzing, by the user equipment, the first quality of service with respect to at least one delay function specified by the retransmission request configuration to obtain an analyzed first quality of service; determining, by the user equipment, a first retransmission request indication corresponding to the analyzed first quality of service using the retransmission request configuration; transmitting, by the user equipment via the radio access network, a first retransmission request indication for indicating a first retransmission priority for retransmission of the first part of the traffic flow; as well as First retransmission data is received by the user equipment in response to the first retransmission request indication, where the first retransmission data represents a first retransmission of the first part of the service flow according to the first retransmission priority. 2 . The method according to claim 1 , wherein analyzing the first quality of service comprises analyzing the quality of service of an application executed on the user equipment to which the traffic flow is directed. The method of claim 1 , wherein the first retransmission request indication comprises a hybrid automatic repeat request.

4. The method of claim 1 , wherein the retransmission request configuration associates at least one retransmission request indication index value with a corresponding at least one retransmission request range, and wherein the first retransmission request indication includes a retransmission request indication index value in the at least one retransmission request indication index value corresponding to a retransmission request range in the at least one retransmission request range corresponding to the analyzed first quality of service. The method according to claim 1 , wherein the at least one delay function comprises at least one corresponding delay range criterion.

6. The method of claim 1, wherein a size of the retransmission request indication corresponds inversely to a quantity of the at least one delay function specified by the retransmission request configuration.

7. The method according to claim 1, further comprising: Receiving, by the user equipment, a second portion of the traffic flow; determining, by the user equipment, that the second portion of the traffic flow includes a second error; determining, by the user equipment, a second quality of service corresponding to the second portion of the traffic flow; analyzing, by the user equipment, the second quality of service with respect to the at least one delay function specified by the retransmission request configuration to obtain an analyzed second quality of service; determining, by the user equipment, a second retransmission request indication corresponding to the analyzed second quality of service from the retransmission request configuration; transmitting, by the user equipment via the radio access network, a second retransmission request indication for indicating a second retransmission priority for retransmission of the second part of the traffic flow; as well as Second retransmission data is received by the user equipment in response to the second retransmission request indication, the second retransmission data representing a second retransmission of the second part of the service flow according to the second retransmission priority, wherein the second retransmission priority is different from the first retransmission priority.

8. The method according to claim 7, further comprising: Receiving, by the user equipment, a third portion of the service flow; determining, by the user equipment, that the third portion of the traffic flow includes a third error; determining, by the user equipment, a third quality of service corresponding to the third portion of the traffic flow; analyzing, by the user equipment, the third quality of service with respect to the at least one delay function specified by the retransmission request configuration to obtain an analyzed third quality of service; determining, by the user equipment, a no retransmission confirmation indication corresponding to the third quality of service from the retransmission request configuration; as well as The no retransmission acknowledgment indication is transmitted via the radio access network.

9. The method according to claim 7, wherein: In the retransmission request configuration, the first retransmission priority and the second retransmission priority correspond to services of first importance and second importance, respectively, according to a defined importance criterion, and wherein the first retransmission priority and the second retransmission priority are higher than a default retransmission priority associated with a default retransmission request indication.

10. The method of claim 9, wherein the default retransmission request indication comprises a one-bit indication.

11. The method of claim 1 , wherein the retransmission request configuration data representing the retransmission request configuration comprises retransmission request indication compression configuration data representing a retransmission request indication compression configuration, and wherein the retransmission request indication compression configuration associates at least one compression index with at least one respective combination of a determined number of retransmission request indications corresponding to a determined number of packet receptions of retransmission request indications or acknowledgment indications to be transmitted by the user equipment.

12. A user equipment, comprising: A processor configured to: receiving a first portion of a first traffic flow via a radio access network; determining that the first portion of the first traffic flow includes a first error; receiving a second portion of a second traffic flow via the radio access network; determining that the second portion of the second traffic flow includes a second error; determining a first quality of service corresponding to the first service flow; determining a second quality of service corresponding to the second service flow; With respect to a first delay range defined by a first retransmission request configuration, analyzing the first quality of service to obtain an analyzed first quality of service; With respect to a second delay range defined by a second retransmission request configuration, analyzing the second quality of service to obtain an analyzed second quality of service; determining a first retransmission request indication corresponding to the analyzed first quality of service from the first retransmission request configuration; determining a second retransmission request indication corresponding to the analyzed second quality of service from the second retransmission request configuration; transmitting, via the radio access network, the first retransmission request indication indicating a first priority associated with the first traffic flow; transmitting, via the radio access network, a second retransmission request indication indicating a second priority associated with the second traffic flow; receiving, in response to the first retransmission request indication, via the radio access network, a first retransmission of the first portion of the first traffic flow according to the first priority; as well as In response to the second retransmission request indication, a second retransmission of the second portion of the second traffic flow according to the second priority is received via the radio access network.

13. The user equipment of claim 12 , wherein the processor is further configured to receive, via the radio access network, a scheduling indication for indicating scheduling of downlink resources to be used for receiving the first retransmission and the second retransmission, and wherein the scheduling of downlink resources is based on the first priority and the second priority.

14. The user equipment according to claim 12, wherein the processor is further configured to: receiving a third portion of the first traffic flow associated with a third priority, wherein the first portion of the first traffic flow and the second portion of the second traffic flow are received before the third portion of the first traffic flow, and wherein, Based on the third priority being higher than the first priority and the second priority, the third part of the first business flow is received before the first retransmission of the first part of the first business flow is received and before the second retransmission of the second part of the second business flow is received.

15. The user equipment according to claim 12, wherein the first retransmission request configuration includes a first retransmission request indication index corresponding to the first delay range, wherein the second retransmission request configuration includes a second retransmission request indication index corresponding to the second delay range, and wherein each first retransmission request indication index in the first retransmission request indication index includes a first number of bits corresponding to the first priority, and each second retransmission request indication index in the second retransmission request indication index includes a second number of bits corresponding to the second priority. 16 . The user equipment according to claim 15 , wherein corresponding to the first priority being higher than the second priority, the first digit number is higher than the second digit number.

17. A non-transitory machine-readable medium comprising executable instructions that, when executed by a processor of a user device, facilitate performance of operations comprising: receiving a first retransmission request configuration from a network device of the radio access network; receiving a second retransmission request configuration from the network device; receiving a first portion of a first service flow; receiving a second portion of a second traffic flow; determining that the first portion of the first traffic flow includes a first error and the second portion of the second traffic flow includes a second error; determining a first quality of service corresponding to the first portion of the first traffic flow and a second quality of service corresponding to the second portion of the second traffic flow; analyzing the first quality of service with respect to at least one first delay criterion configured for the first retransmission request to obtain an analyzed first quality of service; analyzing the second quality of service with respect to at least one second delay criterion configured for the second retransmission request to obtain an analyzed second quality of service; determining, from the first retransmission request configuration, a first retransmission request corresponding to the analyzed first quality of service and having a first retransmission priority; determining, from the second retransmission request configuration, a second retransmission request corresponding to the analyzed second quality of service and having a second retransmission priority; as well as A first retransmission request indication indicating at least the first retransmission request or the second retransmission request is transmitted to the network device.

18. The non-transitory machine-readable medium of claim 17, wherein the first retransmission request is a first first retransmission request among a plurality of first retransmission requests represented in the first retransmission request configuration, wherein each of the plurality of first retransmission requests comprises a first bit number corresponding to the first quality of service, wherein the second retransmission request is the second second retransmission request among the plurality of second retransmission requests represented in the second retransmission request configuration, wherein each of the plurality of second retransmission requests comprises a second bit number corresponding to the second quality of service, and The first digit and the second digit are different.

19. The non-transitory machine-readable medium of claim 17, the operations further comprising: receiving a third portion of the second service flow; determining a third quality of service corresponding to the third portion of the second traffic flow; With respect to the at least one second delay criterion configured for the second retransmission request, analyzing the third quality of service to obtain an analyzed third quality of service; determining a third retransmission request corresponding to the analyzed third quality of service from the second retransmission request configuration; as well as A second retransmission request indication indicating the third retransmission request is transmitted to the network device.

20. The non-transitory machine-readable medium of claim 17, wherein the first retransmission request indication comprises a compressed index corresponding to the first retransmission request and the second retransmission request, wherein the first retransmission request comprises a first number of bits and the second retransmission request comprises a second number of bits, and wherein the compressed index comprises fewer bits than the sum of the first number of bits and the second number of bits.

Images