Dynamic packet reordering, discarding, and flow exchange

Abstract

The radio access network node transmits a packet drop indication to configure the user equipment using an indication that the node may drop packets corresponding to the indicated flow or corresponding to a flow received via the indicated resource. Upon receiving an out-of-order packet corresponding to the indicated flow, the packet drop indication configures the user equipment to not transmit a negative acknowledgement that the packet is not received via the indicated flow. The packet drop indication may configure the user equipment to decode a packet dropped from a stream indicated to enable drop via indicated resources of an alternative target stream, which may have a different quality of service, latency, or reliability than the stream to which the dropped packet belongs. The node may offload a transmission of packets dropped from the drop enabled stream to a stream indicated as an alternative target stream that is designated for offloading in the packet drop indication.

Description

[0001] Cross-reference to related applications

[0002] This application claims priority to U.S. nonprovisional patent application No. 18 / 183,617, filed March 14, 2023, entitled “DYNAMICPACKET RE-ORDERING, DISCARDING, AND FLOW SWITCHING”, the entire contents of which are incorporated herein by reference. Background Technology

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

[0004] The following is a simplified overview of the disclosed subject matter to provide a basic understanding of some embodiments across the various examples. This overview is not a comprehensive summary of the various embodiments. It is neither intended to identify key or essential elements of the various embodiments nor to depict the scope of the various embodiments. Its sole purpose is to present some concepts of the invention in a streamlined manner as a prelude to the more detailed description that follows.

[0005] In an embodiment, an example method may include: establishing a communication session by a radio access network node including a processor having a user equipment, comprising a first traffic stream associated with quality of service; and transmitting a packet drop indication corresponding to the first traffic stream to the user equipment by the radio access network node, wherein the packet drop indication indicates to the user equipment that out-of-order packets of the first traffic stream will indicate that the radio access network node will drop packets of the first traffic stream. The method may further include: receiving at least one packet in a buffer by the radio access network node, the at least one packet to be transmitted to the user equipment via the first traffic stream; determining a buffering time for the at least one packet in the buffer by the radio access network node to obtain a determined buffering time; and analyzing the determined buffering time by the radio access network node relative to a delay criterion corresponding to the first quality of service to obtain an analyzed determined buffering time. Based on the determined buffering time being determined to meet the delay criterion, the method may further include the radio access network node dropping the at least one packet.

[0006] Establishing a communication session may include transmitting a radio resource control configuration message that includes a packet drop indication and associates the packet drop indication with a first traffic flow identifier corresponding to a first traffic flow. The packet drop indication may include an indication in RRC format. The packet drop indication may include information used by the user equipment in conjunction with the RRC format to determine whether to enable dropping. Establishing a communication session includes transmitting a radio resource control message that includes a packet drop indication and associates the packet drop indication with a protocol data element set identifier corresponding to the first traffic flow. Establishing a communication session includes transmitting a radio resource control message including a packet drop indication, wherein the packet drop indication is used to indicate the association of the packet drop indication with a category quality identifier corresponding to the quality of service.

[0007] In one embodiment, establishing a communication session may include transmitting a radio resource control flow message including a packet drop indication, wherein the packet drop indication includes the allocation of resources to be used for transmitting a first traffic stream from a radio access network node to a user equipment. The packet drop indication may include a flow resource indication that instructs the user equipment that packet drop is enabled by the radio access network node for the first traffic stream transmitted by the radio access network node to the user equipment via resources.

[0008] In one embodiment, a communication session may include a second traffic stream, wherein establishing the communication session includes transmitting a radio resource control flow message or other RRC message including a packet drop indication, and wherein the packet drop indication includes a packet offload indication that instructs the user equipment that out-of-order packets of the first traffic stream be transmitted to the user equipment by the radio access network node via a resource set allocated to the second traffic stream and using a corresponding second stream transport configuration. The first traffic stream is associated with a first priority, wherein the second traffic stream is associated with a second priority, and wherein the second priority is lower than the first priority. The first traffic stream corresponds to data directed to the central portion of the virtual reality device, and wherein the second traffic stream corresponds to data directed to the peripheral portion of the virtual reality device.

[0009] In one embodiment, establishing a communication session may include transmitting a radio resource control flow message including a packet drop indication, wherein the packet drop indication includes an allocation of a first resource to be used to transmit a first traffic flow from a radio access network node to a user equipment. The packet drop indication may include a flow resource indication that instructs the user equipment that packet drop is enabled by the radio access network node for the first traffic flow. The communication session may include a second traffic flow. The packet drop indication includes an allocation of a second resource to be used to transmit the second traffic flow from the radio access network node to the user equipment. The packet drop indication may include a packet offload indication that instructs the user equipment that out-of-order packets of the first traffic flow are to be transmitted by the radio access network node to the user equipment via the second resource. The packet drop indication may include, or the offload indication may include, an out-of-order packet indication that instructs the user equipment that out-of-order packets of the first traffic flow are to be transmitted by the radio access network node via a second resource corresponding to the second traffic flow.

[0010] In another example embodiment, the first communication device may include a processor configured to establish a communication session with a second communication device comprising at least a first traffic stream. The first communication device may be a radio access network node or a user equipment. The second communication device may also be a radio access network node or a user equipment. The processor of the first communication device may further be configured to receive at least one packet of the first traffic stream into a buffer corresponding to the first communication device, the at least one packet being transmitted to the second communication device corresponding to the first traffic stream. The buffer may include a scheduling buffer. The first communication process may further be configured to: determine the buffering time of at least one packet of the first traffic stream in the buffer to obtain a determined buffering time (e.g., the amount of time at least one packet has been in the buffer); analyze the determined buffering time relative to a first delay criterion corresponding to the first traffic stream to obtain an analyzed determined buffering time; and based on the analyzed determined buffering time satisfying the first delay criterion, discard at least one packet of the first traffic stream according to a packet discarding indication. For example, if a packet corresponds to a stream with a standard having very low latency, the processor of the first communication device can be configured to discard the packet; and if the second communication device does not receive the discarded packet, the second communication device can be configured not to transmit a negative acknowledgment upon receiving an out-of-order packet, either in DCI format or as a packet discard indication. Establishing a communication session may include transmitting a packet discard indication corresponding to the first traffic stream, wherein the packet discard indication is used to indicate that out-of-order packets in the first traffic stream indicate that packets in the first traffic stream have been discarded.

[0011] In one embodiment, the radio resource control flow message may include a packet drop indication, and the packet drop indication may be associated with a category quality identifier corresponding to a first delay criterion. Therefore, the second communication may be configured to determine, based on the packet drop indication, that the out-of-order packet corresponding to the category quality identifier indicates that the lost packet corresponding to the out-of-order packet has been dropped by the first communication device.

[0012] In another embodiment, the communication session may include a second traffic stream. A packet drop instruction may include an allocation of a first resource to be used for transmitting the first traffic stream. A packet drop instruction may also include an allocation of a second resource to be used for transmitting the second traffic stream. A radio resource control format may include a packet drop instruction. The packet drop instruction may include a packet offload instruction that indicates to the second communication device that out-of-order packets of the first traffic stream are to be transmitted by the first communication device to the second communication device via the second resource. The first traffic stream may be associated with a first priority, wherein the second traffic stream is associated with a second priority, and wherein the second priority is lower than the first priority. The processor of the first communication device may also be configured to transmit packets dropped from the first traffic stream to the second communication device via the second traffic stream or a resource corresponding to the second stream.

[0013] In another embodiment, an example transient machine-readable medium includes executable instructions that, when executed by a processor of a radio access network node, facilitate the execution of operations including establishing a communication session with a user equipment including a first traffic stream associated with a first maximum delay. Based on the first maximum delay, the operations may further include enabling packet dropping for the first traffic stream. For example, the radio access network node enables packet dropping for the first traffic stream if an application executing on the user equipment requires a tight latency budget. The operations may further include transmitting a packet dropping indication to the user equipment indicating that out-of-order packets of the first traffic stream indicate that the radio access network node has dropped at least one packet of the first traffic stream. The operations may further include receiving packets of the first traffic stream into a buffer, determining the time the packets have been in the buffer to obtain a determined buffer time, and analyzing the determined buffer time relative to the first maximum delay to obtain an analyzed determined buffer time. Based on the analyzed determined buffer time exceeding the first maximum delay, the operations may further include dropping the packets to obtain the dropped packets.

[0014] In one embodiment, the communication session may include a second traffic stream, and the operation may further include transmitting dropped packets to the user equipment via the second traffic stream.

[0015] In one embodiment, the communication session may include a second traffic stream. The packet drop indication may include: a first resource indication, a second resource indication, and a resource selection indication, wherein the first resource indication associates a first resource with the first traffic stream, the second resource indication associates a second resource with the second traffic stream, and the resource selection indication indicates to the user equipment that out-of-order packets from the first traffic stream should be transmitted by the radio access network node according to the second resource. Operation also includes transmitting the dropped packets to the user equipment via the second resource.

[0016] In one embodiment, a first flow stream may be associated with a first reliability, a second flow stream may be associated with a second reliability, and the second reliability may be lower than the first reliability.

[0017] In one embodiment, a packet drop indication may include an acknowledgment suppression indication that instructs the user equipment to suppress the transmission of a negative acknowledgment message corresponding to an out-of-order packet received from a radio access network node to the radio access network node. For example, the acknowledgment suppression indication may instruct the user equipment that an out-of-order packet corresponding to the flow indicated in the packet drop indication should not be followed by a NACK, thereby starting a wait timer to determine whether it is a lost packet corresponding to that packet (e.g., the lost packet should have a lower sequence number than the received out-of-order packet).

[0018] In another example embodiment, an example method includes establishing a communication session comprising a first traffic stream by a user equipment including a processor having a radio access network node to facilitate the execution of an application by the user equipment. The method may further include the user equipment receiving a packet drop indication corresponding to the first traffic stream from the radio access network node. The receipt of the packet drop indication corresponding to the first traffic stream may be part of the communication session establishment or may be facilitated by separate message transmissions established with the radio access network node. The example method may further include the user equipment receiving a first out-of-order packet corresponding to the first traffic stream. Based on the packet drop indication, the method may further include: the user equipment suppressing the transmission of a negative acknowledgment (NACK) corresponding to the first out-of-order packet to the radio access network node; and the user equipment using the first out-of-order packet to execute an application. Therefore, based on the packet drop indication, the user equipment may be configured to recognize that the receipt of the first out-of-order packet indicates that the radio access network node has dropped one or more packets of the first traffic stream, and therefore the user equipment does not transmit a NACK, and assumes that the radio access network node has dropped one or more packets with a lower or earlier sequence number than the first out-of-order packet, which might otherwise have been received by the user equipment.

[0019] In one embodiment, the communication session may include a second traffic stream, and the method may further include receiving a second out-of-order packet corresponding to the second traffic stream by a user equipment. The method may further include: transmitting a negative acknowledgment (NA) corresponding to the second out-of-order packet to a radio access network node by the user equipment; receiving a lost packet corresponding to the second traffic stream based on the transmission of the NAF; and using the lost packet by the user equipment to perform an application. In this case, the user equipment may not be configured to enable processing of out-of-order packets of the second traffic stream for packet discarding, but rather configured to enable processing of out-of-order packets of the second traffic stream for radio access network nodes. Therefore, the user equipment may initiate a delay when a wait timer expires and the user equipment has not received a lost packet, and the user equipment may transmit a NACK based on the receipt of the second out-of-order packet to request retransmission of one or more lost packets.

[0020] In one embodiment, a packet drop indication may include a first flow identifier corresponding to a first traffic flow. The first flow identifier may indicate the activation of packet drop by a radio access network node, which is to be applied to packets constituting the first traffic flow. The user equipment's suppression of the transmission of negative acknowledgments corresponding to the first out-of-order packet to the radio access network node may be based on the first out-of-order packet corresponding to the first flow identifier.

[0021] The example method may also include a user equipment determining a delay corresponding to the first traffic stream, wherein the application corresponds to an application type, and wherein the delay is determined based on the application type. A delay criterion may correspond to the first traffic stream. Establishing a communication session may include transmitting a radio control message indicating the delay criterion, and packet dropping may be applied to one or more packets of the first traffic stream whose delay is stored in a buffer in a radio access network node and is longer than the delay criterion.

[0022] In an embodiment of the example method, the packet drop indication may include a first flow identifier corresponding to a first traffic flow. The packet drop indication may include a first resource associated with the first flow identifier. The first flow identifier associated with the first resource indicates that packet drop is enabled by a radio access network node, and this packet drop is to be applied to packets constituting a first traffic flow transmitted via the first resource. The user equipment's suppression of transmission of negative acknowledgments corresponding to out-of-order packets may be based on the correspondence between the first out-of-order packets and the first flow identifier, and on the fact that the first time-ordered packets are received via the first resource.

[0023] In another embodiment of the example method, the packet drop indication may include a first flow identifier corresponding to a first traffic stream, wherein the packet drop indication includes a first resource associated with the first flow identifier or an indication to the first resource. The communication session may include a second traffic stream, and the packet drop indication may include a second flow identifier corresponding to the second traffic stream, wherein the packet drop indication includes a second resource associated with the second flow identifier. Furthermore, the packet drop indication may include a packet offload indication for instructing out-of-order packets of the first traffic stream to be transmitted to the user equipment via the second resource by a radio access network node. The method may further include: receiving lost packets of the first traffic stream corresponding to the first out-of-order packets via the second resource by the user equipment based on the packet offload indication; and using the lost packets to perform an application by the user equipment. The first traffic stream may be associated with a first priority, wherein the second traffic stream is associated with a second priority, and wherein the second priority is lower than the first priority. Therefore, packets of the first traffic stream can be offloaded for reception by the user equipment using resources corresponding to the second traffic stream, which may have a lower priority than the first traffic stream. In one embodiment, the first traffic flow may correspond to data directed to the central portion of the virtual reality device, and the second traffic flow may correspond to data directed to the peripheral portion of the virtual reality device (e.g., data directed to the peripheral portion may have a lower priority than data directed to the central portion). This application can be any real-world application managing a virtual reality device that is communicatively coupled to a user device.

[0024] In one embodiment, establishing a communication session may include receiving a radio resource control message, the radio resource control message including a packet drop indication and being associated with a first flow identifier corresponding to a first flow flow.

[0025] In one embodiment, establishing a communication session may include receiving a radio resource control message that includes a packet drop indication and associates the packet drop indication with a protocol data unit set identifier corresponding to a first traffic stream.

[0026] In one embodiment, establishing a communication session may include receiving a radio resource control message including a packet drop indication, wherein the packet drop indication is used to indicate the association between the packet drop indication and a category quality identifier corresponding to a first traffic stream.

[0027] In another example embodiment, the first communication device may include a processor configured to establish a communication session with the second communication device comprising at least a first traffic stream. Establishing the communication session may include receiving a packet drop indication corresponding to the first traffic stream, wherein the packet drop indication includes a first stream identifier corresponding to the first traffic stream, and wherein the packet drop indication is used to indicate that an out-of-order packet including the first stream identifier indicates that a packet of the first traffic stream has been dropped by the second communication device. The processor of the first communication device may also be configured to receive a first packet including the first stream identifier from the second communication device and a second packet including the first stream identifier from the second communication device. The processor may also be configured to determine that the second packet is out of order relative to the first packet to obtain a determined out-of-order packet. Based on the determined out-of-order packet indicating that at least a third packet of the first traffic stream has been dropped by the second communication device, the processor may also be configured to suppress the transmission of a negative acknowledgment corresponding to the third packet.

[0028] In one embodiment, the communication session may include a second traffic stream. The packet drop indication may include a first resource indication and a second resource indication, the first resource indication indicating a first resource to be used for transmitting the first traffic stream, and the second resource indication indicating a second resource to be used for transmitting the second traffic stream. The packet drop indication may include an offload indication indicating dropped packets of the first traffic stream that can be transmitted by the second communication device via the second resource, and the processor may also be configured to receive a third packet via the second resource based on the offload indication. The first traffic stream may correspond to a first reliability, the second traffic stream may correspond to a second reliability, and the second reliability may be lower than the first reliability.

[0029] In another embodiment, an example non-transient machine-readable medium may include executable instructions that, when executed by a processor of a user equipment, facilitate the execution of operations including receiving a radio resource control message from a radio access network node by the user equipment. The radio resource control message includes a downlink control information format indication indicating a downlink control information format, wherein the downlink control information format includes a protocol data unit (DAC) discard indication corresponding to a communication session between the user equipment and the radio access network node. The communication session may include at least a first set of DACs, and the DAC discard indication may indicate that out-of-order data units of the first set of DACs indicate that data units of the first set of DACs are discarded by the radio access network node. The operations may further include: receiving out-of-order data units corresponding to the first set of DACs from the radio access network node to obtain received out-of-order data units; and, based on the receipt of the received out-of-order data units, determining, according to the DAC discard indication, to suppress the transmission of a negative acknowledgment corresponding to the out-of-order data units to the radio access network node.

[0030] In an embodiment of an example non-transient machine-readable medium, a protocol data unit (TCP) discard indication may include a first TCP set identifier corresponding to a first TCP set. Received out-of-order data units may include the first TCP set identifier. The user equipment's decision to suppress the transmission of a negative acknowledgment corresponding to an out-of-order data unit to a radio access network node may be based on the fact that the received out-of-order data unit includes or contains the first TCP set identifier.

[0031] In another embodiment of the example non-transient machine-readable medium, the downlink control information format may indicate resources to be used by the radio access network node for transmission of a first set of protocol data units to the user equipment. A protocol data unit drop indication may include a first protocol data unit set identifier corresponding to the first protocol data unit set. The protocol data unit drop indication may indicate that out-of-order data units received via the resource, including the first protocol data unit set identifier, are to indicate data units in the first protocol data unit set that have been dropped by the radio access network node. Received out-of-order data units may include the first protocol data unit set identifier and may be received via the resource. Therefore, the user equipment may be configured to receive out-of-order data units based on the resources indicated in the protocol data unit drop indication, assuming that the data unit set corresponding to the out-of-order indication may include lost packets.

[0032] In another embodiment of the example non-transient machine-readable medium, the communication session may include a second set of protocol data units. The downlink control information format may indicate a first resource to be used by the radio access network node for transmission of the first set of protocol data units to the user equipment. The downlink control information format may indicate a second resource to be used by the radio access network node for transmission of the second set of protocol data units to the user equipment. A protocol data unit discard indication may include a first protocol data unit set identifier corresponding to the first set of protocol data units. A protocol data unit discard indication may include a second protocol data unit set identifier corresponding to the second set of protocol data units. A protocol data unit discard indication may include an offload indication for indicating that data units in the first set of protocol data units to be discarded by the radio access network node are to be offloaded from the first set of protocol data units for transmission by the radio access network node to the user equipment via the second resource. A protocol data unit discard indication may indicate out-of-order data units, including a first protocol data unit set identifier received via the first resource indicating that data units in the first set of protocol data units that have been discarded by the radio access network node are discarded data units. Received out-of-order data units may include the first protocol data unit set identifier, and received out-of-order data units may be received via the first resource. The operation may further include: receiving at least one discarded data unit from the first protocol data unit set that was discarded by the radio access network node, based on the received out-of-order data unit including a first protocol data unit set identifier and received via a first resource, via a second resource. Attached Figure Description

[0033] Figure 1 The wireless communication system environment is shown.

[0034] Figure 2 An example virtual reality device is shown.

[0035] Figure 3A An example environment is shown with user equipment configured to receive traffic corresponding to a communication session from a radio access network node.

[0036] Figure 3B An example environment is shown with user equipment configured to receive traffic packets corresponding to a communication session from a radio access network node.

[0037] Figure 3C An example environment is shown where radio access network nodes drop traffic packets corresponding to communication sessions due to network congestion and violations of latency budgets.

[0038] Figure 3DAn example environment is shown where a user equipment receives out-of-order traffic packets corresponding to a communication session from a radio access network node.

[0039] Figure 4 An example environment is shown with user equipment configured to receive streams of communication sessions from radio access network nodes.

[0040] Figure 5 The processing of out-of-order grouping of traffic flows is shown.

[0041] Figure 6A An example downlink control information message is shown, which includes an automatic packet drop instruction to indicate the specific flow to which automatic packet drop can be applied.

[0042] Figure 6B An example downlink control information message is shown, which includes an automatic packet drop indication used to indicate a specific resource associated with a specific flow to which automatic packet drop can be applied.

[0043] Figure 6C An example downlink control information message is shown, which includes an automatic packet drop instruction to indicate the specific flow to which automatic packet drop should be applied, and to indicate the specific flow through which the transmission of dropped packets can be attempted.

[0044] Figure 7 A timing diagram is shown for an example method of dropping packets of a traffic stream at the receiving device without triggering negative acknowledgment message transmission due to out-of-order packets.

[0045] Figure 8 A timing diagram is shown for an example method of offloading dropped packets to an alternative traffic stream.

[0046] Figure 9 A flowchart illustrating an example method for discarding packets of a traffic stream at the receiving device without triggering negative acknowledgment message transmission due to out-of-order packets is shown.

[0047] Figure 10 A block diagram of an example method is shown.

[0048] Figure 11 A block diagram of an example communication device is shown.

[0049] Figure 12 A block diagram of an example non-transient machine-readable medium is shown.

[0050] Figure 13 A block diagram of another example method is shown.

[0051] Figure 14 A block diagram of an example user device is shown.

[0052] Figure 15 A block diagram of another example of a non-transient machine-readable medium is shown.

[0053] Figure 16 An example computer environment is shown.

[0054] Figure 17 A block diagram of an example wireless UE is shown. Detailed Implementation

[0055] As will be readily understood by those skilled in the art as a preliminary issue, this embodiment allows for a wide range of uses and applications. Many methods, embodiments, and modifications of this application, as well as many variations, modifications, and equivalent arrangements, will be apparent or reasonably suggested based on the spirit or scope of the various embodiments of this application.

[0056] Therefore, although this application has been described in detail herein with respect to various embodiments, it will be understood that this disclosure is an illustration of one or more concepts expressed by various exemplary embodiments and is made solely for the purpose of providing a complete and enabled disclosure. The following disclosure is not intended and will not be construed as limiting this application or otherwise excluding any such other embodiments, changes, variations, modifications, and equivalent arrangements, and the embodiments described herein are defined only by the claims appended herein and their equivalents.

[0057] As used in this disclosure, in some embodiments, the terms "component," "system," etc., are intended to refer to or include computer-related entities or entities related to operating means having one or more specific functions, wherein the entity may be hardware, a combination of hardware and software, software, or software in execution. As an example, a component may be, but is not limited to, a process running on a processor, a processor, an object, an executable thread of execution, 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 itself can be components.

[0058] One or more components may reside within a process and / or execution thread, and the components may be located on a single computer and / or distributed across two or more computers. Furthermore, these components may execute on various computer-readable media having various data structures stored thereon. These components may communicate via local and / or remote processes, such as according to signals having one or more data packets (e.g., data from one component interacting with another component in a local system, a distributed system, and / or interacting with other systems across a network such as the Internet via the signal). As another example, a component may be a device having a specific function provided by mechanical parts operated by electrical or electronic circuitry, which is operated by a software application or firmware application executed by a processor, wherein the processor may be internal or external to the device and execute at least a portion of the software or firmware application. As yet another example, a component may be a device providing a specific function through an electronic component without mechanical parts, wherein a processor therein executes software or firmware that at least partially imparts the functionality to the electronic component. Although the various components have been shown as separate components, it will be understood that, without departing from the example embodiments, multiple components may be implemented as a single component, or a single component may be implemented as multiple components.

[0059] As used herein, the term "facilitate" is used in the context of a system, device, or component "facilitating" one or more actions or operations, taking into account the nature of the computational environment in which multiple components and / or devices are involved in some computational operations, which can complicate the computational environment. Non-limiting examples of actions that may or may not involve multiple components and / or devices include transmitting or receiving data, establishing connections 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 role in implementing the operation. When the operation of a component is described herein, it will therefore be understood that, where the operation is described as being facilitated by a component, the operation may optionally be accomplished through the cooperation of one or more other computing devices or components, such as, but not limited to, sensors, antennas, audio and / or visual output devices, other devices, etc.

[0060] Furthermore, standard programming and / or engineering techniques can be used to implement various embodiments as methods, apparatuses, or articles of art to produce software, firmware, hardware, or any combination thereof to control a computer to achieve the disclosed subject matter. The term "article of art" as used herein is intended to cover a computer program accessible from any computer-readable (or machine-readable) device or computer-readable (or machine-readable) storage / communication medium. For example, computer-readable storage media may include, but are not limited to, magnetic storage devices (e.g., hard disks, floppy disks, magnetic stripes), optical discs (e.g., optical discs (CDs), digital versatile discs (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 can be made to this configuration without departing from the scope or spirit of the various embodiments.

[0061] The PDCCH of a 5G NR system can deliver downlink and uplink control information to cellular devices. Compared to the control channel design of fourth-generation (e.g., LTE) systems, the 5G control channel can match the requirements of URLLC and eMBB usage scenarios and can provide effective coexistence between those different QoS categories.

[0062] Unlike fourth-generation control channels, 5G PDCCH channels can be beamformed using each UE's preferred channel vector along with an embedded demodulation-aided demodulation reference signal (“DMRS”). PDCCHs can be modulated using a fixed QPSK modulation scheme and employ a conservative coding rate, for example, to maximize the reliability of PDCCH channel reception at the UE. For instance, to meet URLLC 10e-5 reliability levels, PDCCH channel decoding capabilities can be enhanced at the device end.

[0063] The resource size of each PDCCH channel, which can carry downlink control information (“DCI”) for one or more UEs, can be time-varying and can be referred to as a PDCCH aggregation level. Specifically, to enhance PDCCH decoding, the network can increase the resource size of the PDCCH channel and thus adopt a more conservative and resource-inefficient coding rate for PDCCH. This means transmitting the same amount of PDCCH control information at a higher coding rate (i.e., more redundant bits for error detection and correction) at the cost of consuming more channel resources for transmitting PDCCH information.

[0064] There are two types of PDCCH channels. First, there are UE-specific PDCCHs, where the channel resources are periodically monitored by a single UE / device. After configuration, the device will attempt to blindly decode these candidate resources, which may potentially carry DCI information. This DCI information includes configurations regarding scheduled uplink or downlink permissions, transport configurations, and information about common system signaling and updates. Furthermore, blind decoding is the process when the UE attempts to decode a DCI with all possible transport configurations and aggregation levels. This means significant power consumption on the device side; however, it is necessary because the UE is unaware of the actual configuration of the PDCCH channel and the corresponding transport. It should know this after successfully decoding the PDCCH. In active mode, the UE can monitor one or more configured PDCCH search spaces, where a search space represents a set of candidate resources that can carry PDCCH / DCI information. The search space definition can be used to refer to variations in the size of the PDCCH channel (i.e., the aggregation level), and therefore, the amount of resources required to carry the PDCCH can vary.

[0065] The public PDCCH search space is monitored by all UEs. These public PDCCH channels typically carry DCI information relevant to all devices. Examples include system update and control information, full UE power control information, and general system information.

[0066] For each scheduled downlink or uplink transmission, there is typically a preceding PDCCH control transmission that informs the UE about the resources scheduled by the network for transmission and the transmission configuration for transmission in the uplink or reception in the downlink. Therefore, PDCCH transmission is considered signaling overhead, which should always be minimized and is necessary for successful device transmission and / or reception.

[0067] As an example use case illustrating the exemplary embodiments disclosed herein, when using with

[0068] When URLLC-associated NR radio resources are used, virtual reality (“VR”) applications and VR variants (e.g., mixed and augmented reality) may perform optimally at some times, while lower performance levels may be sufficient at others. Virtual reality smart glasses devices can consume NR radio resources at a given broadband data rate with more stringent radio latency and reliability standards to provide a satisfactory end-user experience.

[0069] 5G systems should support "Anything Reality" ("XR") services. XR services can include VR applications, a widely adopted type of XR application, which provide immersive environments that stimulate the end-user's senses, allowing him or her to "trick" themselves into feeling like they are in an environment different from their actual surroundings. XR services can include augmented reality ("AR") applications, which enhance the real-world environment by providing additional virtual-world elements through the user's senses focused on real-world elements in the user's actual surroundings. XR services can include mixed reality ("MR") applications, which help merge or combine the virtual and real worlds, allowing the end-user of the XR service to interact with elements of both their real and virtual environments simultaneously.

[0070] Different XR use cases can be associated with certain radio performance objectives. Common in XR scenarios, and unlike URLLC or eMBB, a satisfactory end-user experience typically requires a high-capacity link with stringent radio and reliability levels. For example, some XR applications require a 100Mbps link with allowable radio latency of a few milliseconds, compared to a 5Mbps URLLC link with a 1ms radio budget. Therefore, the processes involved in 5G radio design and association can be applied to new XR QoS categories and associated performance objectives.

[0071] XR services can be facilitated by traffic with certain characteristics associated with XR services. For example, XR traffic can often be periodic, with packet sizes and arrival rates varying over time. Furthermore, different packet traffic flows within a single XR communication session can differently impact the end-user experience. For instance, smart glasses streaming 180-degree high-resolution frames can utilize a large percentage of broadband service capacity to achieve a satisfactory user experience. However, frames presenting the user's directional orientation (e.g., forward direction) are most critical for a satisfactory end-user experience, while frames presenting the user's peripheral vision have a smaller impact on the user experience and are therefore associated with lower QoS requirements for packet traffic compared to QoS requirements for directional traffic flows. Therefore, prioritizing certain flows or packets within an XR session over others can help efficiently utilize the communication system's capacity for traffic delivery. Additionally, due to the limited form factor of devices, XR-capable devices (e.g., smart glasses, projection wearables, etc.) may be more power-constrained than traditional mobile handheld devices. Therefore, techniques that maximize power-saving operations at XR-capable devices are needed. Therefore, user equipment devices that access XR services or XR sessions can associate certain QoS metrics to meet the performance targets of XR services, such as perceived data rate or end-to-end latency and reliability.

[0072] 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 traffic.

[0073] Now turn to the attached diagram. Figure 1 Examples of a wireless communication system 100 supporting blind decoding of PDCCH candidate or search space according to various aspects of this disclosure are 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 Advanced LTE (LTE-A) network, an LTE-APro 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 figures, examples of UE 115 may include smartphones, automobiles, and other vehicles, or drones or other aircraft. Another example of a UE may be a virtual reality device 117, such as smart glasses, virtual reality headsets, augmented reality headsets, and other similar devices that can provide the wearer with images, video, audio, touch, taste, or smell. A UE, such as VR device 117, can transmit or receive wireless signals with RAN base station 105 via long-range wireless link 125, or the UE / VR device can receive or transmit wireless signals via short-range wireless link 137, which may include a wireless link with UE device 115, such as a Bluetooth link, Wi-Fi link, etc. A UE, such as device 117, can communicate simultaneously via multiple wireless links, such as via link 125 with base station 105 and via short-range wireless links. VR device 117 can also communicate with the wireless UE via cable or other wired connection. RAN or its components may be referenced. Figure 12 And implemented by one or more computer components described.

[0074] Continue the discussion Figure 1Base stations 105 can be distributed throughout a geographical area to form a wireless communication system 100, and can be devices of different forms or with different capabilities. Base stations 105 and UE 115 can communicate wirelessly via one or more communication links 125. Each base station 105 can provide a coverage area 110, on which UE 115 and base station 105 can establish one or more communication links 125. Coverage area 110 can be an example of a geographical area, on which base stations 105 and UE 115 can support signal communication according to one or more radio access technologies.

[0075] UE 115 can be distributed throughout the coverage area 110 of the wireless communication system 100, and each UE 115 can be fixed, mobile, or both fixed and mobile at different times. UE 115 can be devices of different forms or with different capabilities. Figure 1 Some example UE 115s are shown in the document. The UE 115 described herein can communicate with various types of devices, such as other UE 115s, base station 105, or network devices (e.g., core network nodes, relay devices, integrated access and backhaul (IAB) nodes, or other network devices), such as... Figure 1 As shown in the image.

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

[0077] One or more base stations 105 described herein may include, or may be referred to by those skilled in the art as, base station, radio base station, access point, radio transceiver, Node B, eNodeB (eNB), next-generation Node B or giant Node B (any of which may be referred to as bNodeB or gNB), home Node B, home eNodeB, or other suitable terms.

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

[0079] UE 115 can communicate with various types of devices, such as other UE 115s that sometimes act as relays, as well as base station 105 and network devices, including macro eNBs or gNBs, smaller cell eNBs or gNBs, or relay base stations, such as... Figure 1 As shown in the image.

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

[0081] In some examples (e.g., in a carrier aggregation configuration), the carrier may also have acquisition signaling or control signaling to coordinate the operation of other carriers. The 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 can be located based on the channel grating used for discovery by UE 115. The carrier can operate in standalone mode, where initial acquisition and connection can be performed by UE 115 via the carrier, or the carrier can operate in non-standalone mode, where different carriers (e.g., with the same or different radio access technologies) are used to anchor the connection.

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

[0083] A carrier can be associated with a specific bandwidth of the radio spectrum, and in some examples, the carrier bandwidth can be referred to as the carrier or the "system bandwidth" of the wireless communication system 100. For example, the carrier bandwidth can be one of a plurality of defined bandwidths of a carrier used for a particular radio access technology (e.g., 1.4, 3, 5, 10, 15, 20, 40, or 80 MHz). 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 configured to support communication on one of a group of carrier bandwidths. In some examples, the wireless communication system 100 may 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 the entire carrier bandwidth.

[0084] The signal waveform transmitted on a carrier can consist of multiple subcarriers (e.g., using multicarrier modulation (MCM) techniques such as Orthogonal Frequency Division Multiplexing (OFDM) or Discrete Fourier Transform Extended OFDM (DFT-S-OFDM). In a system employing MCM, a resource element can consist of one symbol period (e.g., the duration of a modulation symbol) and one subcarrier, where the symbol period and subcarrier spacing are inversely related. The number of bits carried by each resource element can depend on the modulation scheme (e.g., the coding rate of the modulation scheme, or both). Therefore, the more resource elements the UE 115 receives and the higher the order of the modulation scheme, the higher the data rate of the UE. Wireless communication resources can refer to a combination of radio spectrum resources, temporal resources (e.g., search space), or spatial resources (e.g., spatial layers or beams), and the use of multiple spatial layers can further increase the data rate or data integrity used for communication with the UE 115.

[0085] One or more digitization schemes for a carrier can be supported, where the digitization schemes may include subcarrier spacing (Δf) and a cyclic prefix. A carrier can be divided into one or more BWPs with the same or different digitization schemes. In some examples, the UE 115 can be configured to have multiple BWPs. In some examples, a single BWP for a carrier can be active at a given time, and the communication of the UE 115 can be restricted to one or more active BWPs.

[0086] The time interval of base station 105 or UE 115 can be expressed as a multiple of a basic time unit, such as T. s =1 / (Δf) max ·N f The sampling period is ) seconds, where Δf max This can represent the maximum supported subcarrier spacing, and N f This can represent the maximum supported Discrete Fourier Transform (DFT) size. The time interval of the communication resources can be organized according to radio frames, each with a specified duration (e.g., 10 milliseconds (ms)). Each radio frame can be identified by a System Frame Number (SFN) (e.g., ranging from 0 to 1023).

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

[0088] Subframe slots, microslots, or symbols can be the smallest scheduling unit of the wireless communication system 100 (e.g., in the time domain) and can be referred to as transmission time intervals (TTIs). In some examples, the duration of a TTI (e.g., the number of symbol cycles in a TTI) can be variable. Additionally or alternatively, the smallest scheduling unit of the wireless communication system 100 can be dynamically selected (e.g., in a burst of shortened TTIs (sTTIs)).

[0089] 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 using, for example, one or more of Time Division Multiplexing (TDM), Frequency Division Multiplexing (FDM), or hybrid TDM-FDM techniques. The control region (e.g., a control resource set (CORESET)) of a physical control channel can be defined by multiple symbol periods and can extend across the system bandwidth or a subset of the system bandwidth of the carrier. One or more control regions (e.g., CORESETs) can be configured for a set of UEs 115. For example, one or more UEs in UE 115 can monitor or search control regions or spaces for control information based on 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 control channel candidates 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. The search space set may include a common search space set configured for sending control information to multiple UEs 115 and a UE-specific search space set for sending control information to a specific UE 115. Novel, rather than conventional, additional search spaces and configurations for monitoring and decoding them are disclosed herein.

[0090] Base station 105 may provide communication coverage via one or more cells, such as 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 used to distinguish adjacent cells (e.g., Physical Cell Identifier (PCID), Virtual Cell Identifier (VCID), or others). In some examples, a cell may also refer to a geographic coverage area 110 or a portion (e.g., a sector) of geographic coverage area 110 on which the logical communication entity operates. Depending on various factors such as the capabilities of base station 105, the range of such cells can range from small areas (e.g., structures, subsets of structures) to large areas. For example, a cell may be or include buildings, subsets of buildings, or areas between geographic coverage areas 110, or external space overlapping with geographic coverage areas 110.

[0091] Macro cells typically cover a relatively large geographic area (e.g., a radius of several kilometers) and allow UE 115 with a service subscription to unrestricted access to network providers that support macro cells. In contrast, small cells can be associated with low-power base stations 105 and can operate in the same or different (e.g., licensed or unlicensed) frequency bands as macro cells. Small cells can utilize service subscriptions with network providers to provide access to...

[0092] Unrestricted access to UE 115, or restricted access to UE 115 associated with small cells (e.g., UE 115 in a closed subscriber group (CSG), or UE 115 associated with a user in a home or office). 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.

[0093] In some examples, a carrier can support multiple cells and can be configured with different cells depending on the different protocol types that provide access, such as MTC, narrowband (NB-IoT), and enhanced mobile broadband (eMBB) that may be different types of devices.

[0094] In some examples, base station 105 may be mobile, thus providing communication coverage for mobile geographic coverage areas 110. In some examples, different geographic coverage areas 110 associated with different technologies may overlap, but different geographic coverage areas 110 may be supported by the same base station 105. In other examples, overlapping geographic coverage areas 110 associated with different technologies may be supported by different base stations 105. Wireless communication system 100 may include, for example, a heterogeneous network, in which different types of base stations 105 use the same or different radio access technologies to provide coverage for various geographic coverage areas 110.

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

[0096] Some UE 115s (e.g., MTC or IoT devices) can be low-cost or low-complexity devices and can provide automated communication between machines (e.g., via machine-to-machine (M2M) communication). M2M communication or MTC can refer to data communication technologies that allow devices to communicate with each other or with base station 105 without human intervention. In some examples, M2M communication or MTC can include communication from devices that integrate sensors or meters to measure or capture information and relay such information to a central server or application that uses the information or presents it to people interacting with the application. Some UE 115s can 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, health monitoring, wildlife monitoring, weather and geological event monitoring, fleet management and tracking, remote security sensing, physical access control, and transaction-based traffic metering.

[0097] Some UE 115s can be configured to operate in a power-saving mode, such as half-duplex communication (e.g., a mode that supports unidirectional communication via transmission or reception but not both transmission and reception simultaneously). In some examples, half-duplex communication can be performed at a reduced peak rate. Other power-saving techniques for UE 115 include entering a power-saving deep sleep mode when not engaged in active communication, operating on limited bandwidth (e.g., according to narrowband communication), or a combination of these techniques. For example, some UE 115s can 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 the carrier, within the carrier's guard band, or outside the carrier.

[0098] Wireless communication system 100 can be configured to support ultra-reliable communication, low-latency communication, or various combinations thereof. For example, 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 mission-critical functions (e.g., mission-critical functions). Ultra-reliable communication may include dedicated communication or group communication and may 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 may include service prioritization, which may be used for public safety or general business applications. The terms “ultra-reliable,” “low-latency,” “mission-critical,” and “ultra-reliable low-latency” are used interchangeably herein.

[0099] In some examples, UE 115 may also be able to communicate directly with other UE 115 via device-to-device (D2D) communication link 135 (e.g., using peer-to-peer (P2P) or D2D protocols). Communication link 135 may include a sidelink communication link. One or more UEs 115 utilizing D2D communication may be within the geographic coverage area 110 of base station 105. Other UEs 115 in the group may be outside the geographic coverage area 110 of base station 105 or may not be able to receive transmissions from base station 105. In some examples, the group of UEs 115 communicating via D2D communication may utilize a one-to-many (1:M) system, where a UE transmits to each other UE in the group. In some examples, base station 105 facilitates resource scheduling for D2D communication. In other cases, D2D communication is performed between UEs 115 without involving base station 105.

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

[0101] Core network 130 can provide user authentication, access authorization tracking, Internet Protocol (IP) connectivity, and other access, routing, or mobility functions. Core network 130 can be an evolved packet core (EPC) or a 5G core (5GC), and can include at least one control plane entity (e.g., a mobility management entity (MME), access, and mobility management functions (AMF)) managing access and mobility, and at least one user plane entity (e.g., a serving gateway (S-GW), packet data network (PDN) gateway (P-GW), or user plane function (UPF)) routing packets or interconnections to external networks. The control plane entity can manage non-access stratum (NAS) functions, such as mobility, authentication, and bearer management of UE 115 served by base station 105 associated with core network 130. User IP packets can be transmitted through the user plane entity, which can provide IP address allocation and other functions. The user plane entity can be connected to one or more network operator IP services 150. IP services 150 can include access to the Internet, intranets, IP Multimedia Subsystem (IMS), or packet-switched streaming services.

[0102] Some network devices (such as base station 105) may include sub-components, such as access network entity 140, which may be an example of an access node controller (ANC). Each access network entity 140 may communicate with UE 115 through one or more other access network transport entities 145, which may be referred to as a radio headend, smart radio headend, or transmit / receive point (TRP). 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 headends and ANCs) or combined into a single network device (e.g., base station 105).

[0103] Wireless communication system 100 can operate using one or more frequency bands typically in the range of 300 MHz to 300 GHz. The region from 300 MHz to 3 GHz is generally referred to as the Ultra High Frequency (UHF) region or decimeter band because the wavelength ranges from approximately 1 decimeter to 1 meter. UHF waves can be blocked or redirected by buildings and environmental features, but the waves can penetrate sufficiently into the structure used for macrocells to provide service to UE 115 located indoors. Compared to transmissions using smaller frequencies and longer waves in the High Frequency (HF) or Very High Frequency (VHF) portions of the spectrum below 300 MHz, UHF wave transmission can be associated with smaller antennas and shorter ranges (e.g., less than 100 km).

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

[0105] Wireless communication system 100 can use licensed and unlicensed radio spectrum bands. For example, wireless communication system 100 can employ Licensed Assisted Access (LAA), LTE-Unlicensed (LTE-U) radio access technology, or NR technology in unlicensed bands such as the 5 GHz Industrial, Scientific, and Medical (ISM) band. When operating in unlicensed radio spectrum bands, devices such as base station 105 and UE 115 can employ carrier sensing for collision detection and avoidance. In some examples, operation in unlicensed bands can be based on carrier aggregation configurations that combine component carriers operating in licensed bands (e.g., LAA). Operation in unlicensed spectrum can include downlink transmission, uplink transmission, P2P transmission, or D2D transmission, etc.

[0106] Base station 105 or UE 115 may be equipped with multiple antennas, which can be used to employ techniques such as transmit diversity, receive diversity, multiple-input multiple-output (MIMO) communication, or beamforming. The antennas of base station 105 or UE 115 may be located within one or more antenna arrays or antenna panels, which can support MIMO-operated transmit or receive beamforming. For example, one or more base station antennas or antenna arrays may be located together at an antenna assembly such as an antenna tower. In some examples, the antennas or antenna arrays associated with base station 105 may be located in different geographical locations. Base station 105 may have an antenna array with antenna ports having multiple rows and columns, which base station 105 can use to support beamforming for communication with UE 115. Similarly, UE 115 may have one or more antenna arrays capable of supporting various MIMO or beamforming operations. Additionally or alternatively, antenna panels may support radio beamforming of signals transmitted via antenna ports.

[0107] Base station 105 or UE 115 can use MIMO communication to utilize multipath signal propagation and improve spectral efficiency by transmitting or receiving multiple signals via different spatial layers. This technique can be called spatial multiplexing. For example, multiple signals can be transmitted by a transmitting device via different antennas or different combinations of antennas. Similarly, a receiving device can receive multiple signals via different antennas or different combinations of antennas. Each of the multiple signals can be referred to as a separate spatial stream and can carry bits associated with the same data stream (e.g., the same codeword) or different data streams (e.g., different codewords). Different spatial layers can be associated with different antenna ports used for channel measurement and reporting. MIMO technology includes single-user MIMO (SU-MIMO) and multi-user MIMO (MU-MIMO). In single-user MIMO, multiple spatial layers are transmitted to the same receiving device, while in multi-user MIMO, multiple spatial layers are transmitted to multiple devices.

[0108] Beamforming (also known as spatial filtering, directional transmission, or directional reception) is a signal processing technique used at a transmitting or receiving device (e.g., base station 105, UE 115) to shape or manipulate antenna beams (e.g., transmit beams, receive beams) along a spatial path between the transmitting and receiving devices. Beamforming can be achieved by combining signals transmitted via antenna elements of an antenna array, such that some signals propagating in a particular orientation relative to the antenna array experience constructive interference, while other signals experience destructive interference. Adjustments to the signals transmitted via the antenna elements can include the transmitting or receiving device applying amplitude offsets, phase offsets, or both to the signals transmitted via the antenna elements associated with that device. The adjustments associated with each antenna element can be defined by a beamforming weight set associated with a specific direction (e.g., relative to the antenna array of the transmitting or receiving device, or relative to some other direction).

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

[0110] Base station 105 may transmit signals (e.g., data signals associated with a specific receiving device) in a single beam direction (e.g., the direction associated with a receiving device (e.g., UE 115)). In some examples, the beam direction associated with transmission along a single beam direction may be determined based on the 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 with the highest signal quality or otherwise acceptable signal quality.

[0111] In some examples, transmission by a device (e.g., base station 105 or UE 115) may be performed using multiple beam directions, and the device may use a combination of digital precoding or radio beamforming to generate a combined beam for transmission (e.g., from base station 105 to UE 115). UE 115 may report feedback indicating precoding weights for one or more beam directions, and the feedback may correspond to the system bandwidth or the configured number of beams on one or more subbands. Base station 105 may transmit reference signals (e.g., cell-specific reference signals (CRS), channel state information reference signals (CSI-RS)), which may be precoded or unprecoded. UE 115 may provide feedback for beam selection, which may be a precoding matrix indicator (PMI) or codebook-based feedback (e.g., multi-panel type codebook, linear combination type codebook, 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 to transmit signals multiple times in different directions (e.g., to identify the beam direction that UE 115 subsequently transmits or receives) or to transmit signals in a single direction (e.g., to transmit data to a receiving device).

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

[0113] Wireless communication system 100 can be a packet-based network operating according to a layered protocol stack. In the user plane, communication 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 for communication on logical channels. The Media Access Control (MAC) layer can perform priority processing and multiplexing from logical channels to transport channels. The MAC layer can also use error detection, error correction, or both to support retransmissions 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 RRC connections between UE 115 and base station 105 or the core network 130 supporting radio bearers for user plane data. At the physical layer, transport channels can be mapped to physical channels.

[0114] UE 115 and base station 105 can support data retransmission to increase the likelihood of successful data reception. Hybrid Automatic Repeat Request (HARQ) feedback is a technique used to increase the likelihood of correct data reception by communication link 125. HARQ can include a combination of error detection (e.g., using Cyclic Redundancy Check (CRC)), forward error correction (FEC), and retransmission (e.g., Automatic Repeat Request (ARQ)). HARQ can improve MAC layer throughput under poor radio conditions (e.g., low signal-to-noise ratio conditions). In some examples, the device can support HARQ feedback within the same time slot, where the device can provide HARQ feedback in a specific time slot for data received in a previous symbol within that time slot. In other cases, the device can provide HARQ feedback in subsequent time slots or according to some other time interval.

[0115] Now go to Figure 2 The accompanying figure illustrates a virtual reality (“VR”) application system 200. In system 200, a wearable VR device 117 is displayed from the perspective of a wearer or viewer. The VR device 117 may include a central or gestural 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 depicted with different lines; however, it will be understood that hardware or software can facilitate a gradual transition from primary information display to peripheral information display.

[0116] As discussed above, different XR use cases may require different corresponding radio performance. Typically, for XR use cases, but unlike URLLC or eMBB use cases, a high-capacity radio link is needed to carry XR data traffic (e.g., data streams including visual information) with strict radio class (e.g., latency) and reliability levels for a reasonable end-user experience. For example, some XR applications require a 100Mbps link with an allowable radio latency of approximately 2ms, compared to a 5Mbps URLLC link with a 1ms radio latency budget.

[0117] From the study, several characteristics of XR data traffic have been identified: (1) XR traffic is generally periodic, with packet size and packet arrival rate varying over time; (2) XR-enabled devices may be more power-constrained than traditional mobile phones (e.g., smart glasses, projection wearables, etc.) due to the limited form factor of the devices; (3) Multiple data packet streams corresponding to different visual information in a given XR session will not be perceived by the user as having the same impact on the end-user experience.

[0118] Therefore, in addition to requiring XR-specific power efficiency, smart glasses such as wearable device 117 require bandwidth capacity to stream 180-degree high-resolution frames to provide the best user experience. However, it has been determined that data corresponding to frames carrying primary or central visual information (i.e., posture or frontal orientation) is most important for end-user satisfaction, while frames corresponding to peripheral visual information have less impact on user experience. Therefore, accepting higher latency for less important traffic streams allows resources that would otherwise be allocated to less important traffic streams to be used for traffic streams corresponding to more important traffic, or for devices carrying more important traffic, which can be used to optimize the overall capacity and performance of wireless communication systems (e.g., 5G communication systems using NR technologies, methods, systems, or devices). For example, wireless data traffic streams carrying visual information for display on the central or posture visual display portion 202 can be prioritized over wireless data traffic streams carrying visual information for the left visual display portion 204 or for the right visual display portion 206.

[0119] The performance of a communication network in providing XR services can be determined, at least in part, based on user satisfaction with the XR services. Each XR service user equipment can be associated with certain QoS metrics to meet the user service performance objectives in terms of perceived data rate, end-to-end latency, and reliability.

[0120] 5G NR radio systems typically include a physical downlink control channel.

[0121] The 5G control channel (PDCCH) can be used to deliver downlink and uplink control information to cellular devices. It facilitates operation based on URLLC and eMBB usage requirements and promotes effective coexistence between these different QoS categories.

[0122] Grouping and sorting.

[0123] Packet sequencing is a radio function in cellular telephone systems, and packet sequencing refers to a communication device, such as a user equipment (or a computing device at a RAN node), that receives an incoming transport block comprising sequentially numbered packets (e.g., each packet is temporarily numbered using an incrementing next number as it is transmitted). At a communication device, such as a RAN node (or a user equipment) transmitting a traffic stream, the first sequence number of the first packet in the traffic stream can be a random number. For example, the next sequence number of the next packet corresponding to a temporary transmission of the traffic stream can be the initial sequence number plus 1, or the next sequence number can be a number relative to the initial number or an offset relative to the initial number (e.g., the initial sequence number plus a number corresponding to the size of the first packet in bytes). Similarly, the third sequence number of the third packet corresponding to the traffic stream can be the initial sequence number plus 2, or an offset relative to the second sequence number, and so on. For the purposes of this discussion, the sequence number can refer to a sequentially incrementing number, but it will be understood that the sequence number can be based on the packet size (in bytes) of the previous packet in the traffic stream and the sequence number of the previous packet. The receiving device of a traffic stream "expects" to receive packets of the traffic stream in sequence (e.g., in the order in which the packets were transmitted). Packet ordering enables several radio performance advantages, such as allowing transmitting devices, like radio access network nodes, to transmit multiple packets from multiple traffic streams without losing lost packets and tracking correctly decoded packets based on their order numbers. The reliability of radio transmissions can be enhanced by retransmitting packets that may have been lost based on the sequence number corresponding to the lost packet.

[0124] If a communication device receives an out-of-order packet (e.g., a gap exists between the sequence numbers of the most recently received packet and the second most recently received packet), the receiving communication device can identify the packet sequence number corresponding to the sequence number between the sequence numbers of the second most recently received packet and the most recently received packet. The communication device receiving the out-of-order sequence packet can indicate to the communication device transmitting the packet stream that no packet corresponding to the sequence number between the two most recently received packets has been received. The communication device receiving the packet stream can start a wait timer to allow time for the out-of-order packet to arrive before sending an indication to the communication device transmitting the packet stream that no packet corresponding to the lost sequence number has been received. The receiving communication device can continue receiving packets while waiting for a possible packet to be received. The wait timer can be used to account for packets that may have a longer transmission time than other packets in a given traffic stream due to, for example, a longer or different channel path than other packets, and therefore may eventually arrive at the receiving communication device out of order. When the wait timer expires, the receiving communication device can trigger the transmission of a negative acknowledgment (“NACK”) indication for the dropped packet. When a communication device (e.g., a RAN node) receiving one or more NACKs from a packet transport flow, the transport device may trigger a retransmission of the packet corresponding to the sequence number indicated in the NACK. Therefore, the default behavior of the communication device could be to assume that, after a timer expires, a packet corresponding to the lost sequence number that was not received has been dropped due to channel fading, congestion, or interference, and thus a retransmission of the unreceived packet should be performed.

[0125] Packet "dropping" refers to a transmitting communication device determining to exclude the transmission of one or more packets from a flow of traffic destined for a receiving communication device. Dropping is the opposite of abandoning, because abandoned packets are those transmitted by the transmitting communication device but dropped during transmission, or packets that arrive after a waiting timer at the receiving device may have expired, while dropped packets are never transmitted by the transmitting device. Packet dropping can be attributed to packets in a buffered flow of traffic at the transmitting device that, due to network conditions (e.g., longer than the maximum allowable delay corresponding to the flow), are deemed useless for receiving communication and are therefore dropped from the buffer without being transmitted. Consequently, the transmitting communication device continues to transmit packets (e.g., packets with higher sequence numbers than the dropped packets).

[0126] At the receiving device, receiving a packet with an out-of-order packet number, and therefore, the packet recovery process triggered by receiving the out-of-order sequence number, can impose processing load and signaling overhead on both the receiving and transmitting devices to accommodate the receiving device's transmission of retransmission requests in the uplink direction, and the transmitting device's reception of retransmission requests in the uplink direction. In the case of deliberate / intentional packet dropping, the packet recovery process is unnecessary because the packet is dropped not due to poor radio conditions, but because it arrives at the receiving device too late to be usable. When such long-term dropping of packets held in buffers is rare, the device processing and packet recovery signaling overhead may not be a problem. However, for actual services or service classes that characterize extended multi-purpose, multi-priority traffic flows, deliberate / intentional packet dropping at the transmitting device (e.g., RAN node) side may occur frequently enough to negatively impact network performance and the transmission performance of traffic flows corresponding to dropped packets. Some traffic flows may have strict delay targets or delay budgets. Delay budgets or targets can be referred to as criteria, such as thresholds or limits. When a packet is already in a buffer corresponding to a transmission longer than allowed by the configured latency standard due to scheduling delays caused by limited network resource availability, the packet may be intentionally dropped. Traditionally, receiving devices such as user equipment units can be configured to treat packets with out-of-order numbers as indicating dropped packets, thereby triggering unnecessary processing and overhead packet recovery procedures.

[0127] Therefore, the embodiments disclosed herein facilitate device-aware packet drop and packet offloading, which can increase the efficient use of processing and network resources. As discussed above, existing communication devices can be unaware of packet drop (e.g., the receiving device is unaware of intentional drop by the transmitting device), which may cause the receiving device to constantly trigger inefficient packet recovery processes with low processing, latency, and signaling overhead, which is unnecessary for intentional packet drop compared to dropping packets due to poor communication channel conditions. For multi-priority, multi-purpose traffic flows (e.g., for XR services), intentional packet drop often occurs frequently, leading to the triggering of packet recovery processes. The embodiments disclosed herein minimize the inefficient triggering of unnecessary packet recovery processes by implementing device-aware packet drop or packet offloading.

[0128] Dynamic grouping, reordering, discarding, and stream offloading.

[0129] The embodiments disclosed herein facilitate receiving communication devices, such as user equipment, to trigger only a processing-intensive and costly packet recovery process for, for example, unintentionally dropped packets due to poor channel conditions, corresponding to traffic flows configured for high reliability. For purposes of description and example, RAN node may refer to a transmitting communication device, and user equipment such as a mobile smartphone may refer to a receiving communication device; however, it will be understood that user equipment may be a transmitting device, and RAN node may be a receiving device.

[0130] For multi-purpose, multi-priority traffic flow sessions, such as those facilitating XR traffic, the RAN node can configure the user equipment (UE) using traffic flow identifiers corresponding to the traffic flow of the session as part of establishing the communication session. Some traffic flows corresponding to the session can be used to deliver traffic for which packet drop is acceptable, while other traffic flows can be used to deliver traffic for which packet drop is unacceptable. Session configuration information received from the RAN node can indicate via packet drop indications in the configuration corresponding to the session including the traffic flow: if packet drop is considered acceptable for the traffic flow (e.g., based on the application at the UE), the traffic flow is susceptible to intentionally dropped packets corresponding to it. Therefore, for traffic flows indicated by packet drop indications as configured for default packet drop or automatic drop, the UE receiving packets of the indicated traffic flow can avoid triggering or prevent triggering packet recovery procedures (e.g., waiting for a timer to start or for a NACK message to be sent) even when receiving out-of-order packets corresponding to the indicated flow identifier or to a protocol data unit (“PDU”) set identifier (e.g., a set of protocol data units or a flow identifier, such as a packet, segment, datagram, etc.).

[0131] Instead of performing a packet recovery procedure when receiving out-of-order packets of a given traffic stream, the receiving user equipment can treat packets with missing or lost sequence numbers corresponding to skipped packets of the stream as intentionally discarded by the transmitting RAN node, and therefore does not request retransmission of lost packets of the traffic stream.

[0132] For PDU set identifiers or flow identifiers that are not configured for default packet drop, the user equipment can trigger a packet recovery procedure upon receiving out-of-order packets. These flow identifiers are typically associated with reliability-critical flows for which PDUs must be received and for which dropping is unacceptable. Even if a packet / PCU is about to violate strict latency requirements, the packet may still be useful at the receiving communication device, and therefore, even after the packet latency budget has been exceeded, packet drop at the transport RAN node is not triggered for flow streams not configured according to packet drop instructions, because by default, such flow streams are sensitive to intentional packet drop.

[0133] In this scenario, where the traffic stream is not configured to be used for packet dropping by default (which may be referred to as auto-drop), but the buffer latency per packet is generally large, this can lead to a violation of the latency budget for some upcoming packets. This is likely because the RAN node's communication network is experiencing resource starvation, such as due to resource congestion. Therefore, the embodiment also enables the RAN node to dynamically switch the transmission of packets that are about to violate their corresponding latency budget from the original or first traffic stream to a different or second traffic stream, for example, to a traffic stream corresponding to a Data Radio Bearer (“DRB”) that has been configured for high capacity but can be configured for lower reliability than the first traffic stream. This dynamic, specific packet stream switching facilitates the transmission of packets by the RAN node that must be transmitted via another active traffic stream in a faster manner, which may have lower reliability performance, but results in reduced use of scheduled resources and makes the packet more likely to be received by the user equipment than if it were dropped without attempting to transmit the packet via a different traffic stream.

[0134] At the receiving user equipment, flow switching information can be dynamically indicated as "in operation." This dynamic flow switching indication helps the user equipment determine which packets will be transmitted via which flow / DRB, and thus determine whether to employ a flow-specific or DRB-specific receive configuration for receiving dropped packets via different traffic flows. Therefore, even under severe resource congestion, the transmission of reliability-critical packets can be dynamically switched to different traffic flows, albeit to flows with potentially lower reliability, thereby clearing reliability-critical packets from the RAN node's scheduling buffer as an alternative to keeping packets in the buffer for an indeterminate period. Using the dynamic packet switching embodiments disclosed herein, packets can be dynamically switched to less congested active traffic flows, thus allowing for faster packet scheduling and transmission compared to holding packets in the scheduling buffer until network conditions improve, but with a slight trade-off in flow reliability. The embodiments disclosed herein can be implemented using novel control channel signaling.

[0135] Figure 3A An example environment 300 is shown with user equipment 115A having traffic flows configured to receive communication sessions from radio access network node 105. As an example, RAN 105 can receive traffic directed to UE 115A from core network 130 or from another user equipment UE 115B. RAN 105 and UE 115A can establish a communication session 310 comprising multiple traffic flows. Session 310 can facilitate, for example, XR sessions with different traffic flows associated with different corresponding quality of service. For example, a traffic flow contributing to the central portion of a smart glasses device can correspond to a different quality of service than a traffic flow contributing to the peripheral portion of the smart glasses device. Traffic flows 330 and 331 are... Figure 3A The overlapping flows are shown to indicate that these flows typically originate from the same device and will therefore be received by RAN 105 from UE 115B or core network 130. However, flows 330 or 331 may originate from different devices and may be received by RAN 105 from different sources (e.g., network 130 or UE 115B).

[0136] During the establishment of communication session 310, radio access network node 105 may transmit to user equipment 115A a packet drop indication 315 corresponding to one of traffic flows 330 or 331, the indicated traffic flow being referred to as the first traffic flow. For example, traffic flow 330 may be configured to deliver packets corresponding to use with a strict or stringent delay budget (e.g., low latency tolerance). In embodiments, packet drop indication 315 may include information to be used in conjunction with new information elements that may be part of a downlink control information format, which may include information elements relating to user equipment functionality other than packet drop. In another embodiment, radio access network node may transmit to user equipment a novel downlink control channel format that can transmit packet drop indication 315. In other embodiments, packet drop indication 315 may be transmitted via a non-DCI message.

[0137] Packet drop indication 315 can be transmitted to UE 115A, and can indicate to the UE that out-of-order packets received via traffic stream 330 should not trigger a wait timer.

[0138] NACK, or other procedures corresponding to the retransmission of lost packets. The delay budget is determined by Standard 320 and... Figure 3A The middle arrow pointing to the corresponding box 335 indicates that box 335 represents the scheduling buffer of radio access network node 105. For example... Figure 3A As shown, at least one packet of traffic flow 330 is in buffer 335 for approximately the same length as allowed by the corresponding delay budget criterion 320. It should be understood that delay criterion 320 may correspond to traffic flow 330, but not necessarily to traffic flow 331.

[0139] like Figure 3B As shown, packet 330-1 of traffic flow 330 did not exceed the delay standard 320 because the packet was not stored in buffer 335 for longer than the time allowed by the delay budget 320 corresponding to traffic flow 330. RAN 105 removes packet 330-1 from the buffer and transmits the packet to UE 115A. However, as Figure 3C As shown, over time, due to network congestion 340 preventing RAN 105 from successfully transmitting packet 330-2, packet 330-2 has been stored in buffer 335 for longer than the delay standard 320. Therefore, RAN 105 discards packet 330-2 from buffer 335 and does not transmit packet 330-2 to UE 115A. Figure 3D As shown, network congestion 340 has been alleviated, and because packet 330-3 has not been in buffer 335 for longer than the time allowed by standard 320, RAN 105 transmits packet 330-3 to UE 115A.

[0140] UE 115A receives packet 330-3 and determines that the most recently received packet 330-3 is out of order because packet 330-1 is the second most recently received packet, and the user equipment has not received a packet with sequence number 330-2. However, based on the already received packet drop indication 315, as... Figure 3A As shown, a wait timer is initiated on behalf of user equipment 115A, and a NACK is transmitted to radio access network node 105 after the wait timer expires, as follows. Figure 3D As shown, UE 115A places packets of traffic flow 330 in the order that packet 330-3 immediately follows packet 330-1, and continues processing traffic flow 330 without processing packet 330-2. Therefore, based on the received packet drop indication 315, UE 115A does not consume processing resources or network resources used to request retransmission of packet 330-2. Furthermore, UE 115A does not spend time buffering packet 330-3 while waiting to receive packet 330-2.

[0141] Figure 4An example environment 400 with User Equipment 115A is illustrated, which is configured to receive one or more traffic streams 430 and 431 of a communication session 410 from Radio Access Network Node 105. RAN 105 can transmit a packet drop instruction 415 to UE 115A, which can configure, for example, traffic stream 430 to be dropped by the RAN as the default packet handling protocol for traffic stream 430. Traffic stream 430 can be configured to carry packets destined for UE 115A to be displayed on the central portion 202 of smart glasses device 117. Traffic stream 431 can be configured to carry packets destined for UE 115A to be displayed on the peripheral portion 204 of smart glasses device 117. When packets corresponding to traffic streams 430 and 431 are received at Radio Access Network Node 105 for transmission to UE 115A, the Radio Access Network Node can store the packets of the traffic streams in a scheduling buffer 445. If a packet remains in buffer 445 for longer than the time allowed by delay criterion 420, the packet corresponding to traffic flow 430 may be dropped by radio access network node 105. Packet drop indication 415 can configure UE 115A to recognize that a packet in traffic flow 430 has been dropped, such that if the UE or an application running on it determines that a packet is lost based on receiving out-of-order packets from traffic flow 430, the UE does not request packet retransmission. Configuring traffic flow 430 for packets dropped by radio access network node 105 may be desirable for traffic directed to the central portion 202 of smart glasses device 117, because the user's perception of the smart glasses device may be negatively affected by the delay of waiting for out-of-order packets to be received compared to the central portion which does not present information that may have been included in the dropped packets.

[0142] However, while the delay in receiving packets that may violate latency standards might be more problematic for the user of smart glasses device 117 than not receiving packets at all, allowing later packets of the flow to be received without violating the configured latency budget, packet reception by UE 115A may still be desirable. Therefore, radio access network node 105 can determine to transmit packets of flow 430 via flow 431 instead of flow 430, thereby offloading the transmission of otherwise discarded packets to resource sets allocated to different flow flows. Figure 4As shown, packet 430-4 from flow stream 430 has been held in buffer 445 for longer than allowed by delay standard 420, as packet 430-5 itself will violate the delay standard. For illustrative purposes, it is assumed that packets 430-1 through 430-3 have been transmitted, dropped, or offloaded. RAN 105 drops packet 430-4 from flow stream 430 but continues to transmit packet 430-4 via flow stream 431 instead. Therefore, when viewing the information displayed by central section 202, the user of device 117 may not experience a negative impact because packets with higher sequence numbers than 430-4 can be transmitted via flow stream 430 with minimal delay (due to not requesting and waiting for retransmission of packet 430-4 from RAN 105), while packet 430-4 can still be transmitted via flow stream 431. UE 115A can determine when and whether packet 430-4 was received via flow stream 431 and whether to use the packet.

[0143] Figure 5 The processing of out-of-order packets in traffic flow session 500 is shown. Figure 5 An example of the overall behavior of a receiving communication device according to a dynamic packet dropping embodiment is shown, which receives packets from stream 510 and compares them with requests for lost packet retransmission from stream 505. At action 20, the receiving device typically monitors and attempts to blindly decode the configured control channel and extracts the PDU set identifier, stream identifier, or QCI identifier of the granted resource. The receiving device can then, based on indications, such as referring to... Figure 3A or Figure 4 The described packet drop instruction 315 or 415 determines whether automatic packet drop is allowed as a default for one or more identifiers retrieved from control channel signaling. This instruction can be received from the serving RAN node via an RRC message. The packet drop instruction can indicate a PDU set identifier, a flow identifier, or a QCI identifier, where the QCI identifier corresponds to a flow specified by the RAN for or subject to intentional packet drop.

[0144] For example, in action 21, the receiving device may detect and decode out-of-order packets during active resource granting (e.g., the receiving device receives packet PKT 4 after PKT 2, but PKT 3 is lost from stream 505 (e.g., receiving PKT 4 after PKT 2 without receiving PKT 3, or receiving PKT 4 before receiving PKT 3)). In this example, the receiving device is configured not to indicate that packets in stream 505 are designated for packet drop (e.g., the receiving device does not receive a packet drop indication indicating the stream identifier, PDU identifier, or QCI identifier corresponding to stream 505 designated for packet drop). After the wait timer expires, the receiving device triggers a packet recovery procedure and requests retransmission of the lost PKT 3, for example, via uplink control channel resources.

[0145] Conversely, for stream 510, the receiving device receives out-of-order PKT 10 after receiving PKT 6, but the drop indication has configured the receiving communication device to receive stream 510, where it is "assumed" that packets of stream 510 will be transmitted in the event of packet drop, for example, by default or automatically. Therefore, the receiving device effectively processes the received packets as if they were transmitted according to a best-effort protocol and continues to receive packets of stream 510 without triggering a packet recovery mechanism, for example, without requesting retransmission of lost packets via NACK.

[0146] PKT7, PKT8, or PKT9.

[0147] exist Figure 6AIn the example embodiment shown, the RAN node can configure the user equipment apparatus via a downlink control indication message (“DCI”) 605 having an identifier 610 corresponding to a specific flow or PDU set. One or more identifiers can constitute an automatic packet drop indication 615. The packet drop indication 615 may include a PDU set identifier, a flow identifier, or a DRB identifier associated with intentional packet drop of the RAN for the flow identified by identifier 610. The PDU set identifier, flow identifier, or DRB identifier may be associated in indication 615 with packet drop as a default protocol because it corresponds to a flow that typically has strict latency requirements but may have relaxed reliability requirements, which can simply be referred to as relaxed reliability. In other words, latency may be critical for a given flow, but packets may occasionally be lost from the flow at the communication device receiving the flow. Therefore, packet drop indication 615 helps the transmission device (e.g., a network node) drop packets that violate the strict delay budget corresponding to the traffic flow designated for packet drop, without the user equipment (UE) receiving the traffic flow that triggered the packet recovery process (e.g., the indication 615 for dropping packets of a flow with strict delay requirements via the RAN node to inform the UE, and thus not transmitting a NACK message to request retransmission of the lost traffic packets from the RAN to the UE). As a result of using indication 615 for RAN to indicate to the UE one or more flows corresponding to identifier 610, the UE device can avoid transmitting a negative ACK indication for packets with lost sequence numbers after receiving out-of-order packets of the flow identified by identifier 610, where packet drop can be implemented for identifier 610. Thus, network and device power savings are achieved while reducing the use of control channel overhead. When the UE requests certain traffic flows from the RAN, PDU set identifier 610 or other identifiers corresponding to the flow can be exchanged via message 605 during radio resource control connection establishment signaling.

[0148] In another embodiment, the radio resource control message 650 may include a packet drop indication 655, which may indicate to the communication device that one or more flow identifiers or PDU sets 660 have been granted certain resources. The receiving communication device may use the indication 655 to determine whether the flow traffic is associated with automatic packet drop. Figure 6BAs shown, the format of downlink control information 650 may include conventional DCI information elements, such as permitted resources and corresponding transport configurations. However, DCI 650 may include new identifier information 660, such as an indication that traffic from one or more PDU sets, streams, or QCIs is designated for packet drop (if transmitted via a specified authorized resource 664). Therefore, a receiving communication device can be configured to determine that an out-of-order packet received via the configured resource 664 may indicate that the traffic stream including the out-of-order packet is affected by packet drop in the transport communication carrying the out-of-order packet. Thus, the resource 664 indicated by indication 655 of DCI 650 may indicate that packet drop is enabled for the stream received via resource 664, regardless of the traffic stream transmitted on the permitted resource indicated in the same DCI. Using packet drop indication 655 to enable a receiving communication device (e.g., a user equipment) to avoid transmitting NACK in response to lost packets may result in less signaling overhead because only a small indication (e.g., a single bit in DCI 650) is added to indicate packet drop corresponding to the resource, rather than indicating as in the referenced... Figure 6A The aforementioned full-stream or PDU set identifier information.

[0149] In one embodiment, dynamic flow switching for dropped packets can be implemented. As discussed elsewhere herein, a user equipment configured to intentionally drop packets in a flow may not expect to receive dropped packets via the flow because the RAN may drop packets that violate the corresponding latency budget due to network congestion in order not to cause additional buffer delays. Such a violation of the latency budget can indicate network resource congestion or starvation, and therefore packets may be dropped from configured high-reliability and low-latency flows. However, in one embodiment, instead of dropping and not transmitting packets already in the scheduling buffer, the RAN may “offload” packets dropped from one flow and transmit the offloaded packets via a set of resources allocated to a different flow. Different flow can be configured for less stringent reliability, and therefore different flows may have idle or available resources, while the flow that dropped the packets does not have idle or available resources (e.g., because different flows are configured for lower priority or lower reliability traffic, the scheduled packets require fewer resources, and therefore the resources allocated to different flows may not be fully utilized). Packet offloading can be useful for transmitting packets dropped from a first flow with a strict delay budget but relaxed reliability requirements, allowing for a tolerable amount of packet loss if packets from the actual received flow are received according to the strict delay budget. Therefore, RAN nodes can dynamically switch or offload the transmission of dropped or pending dropped packets to other active but less reliable flow to facilitate possible packet transmission rather than dropping them. Dropped packets that have been offloaded to a resource set allocated to a less reliable flow may still not be received at the receiving device, but at least an attempt can be made to achieve transmission without affecting the delay budget of the original flow. Figure 6C As shown, DCI format 675 may include a packet drop identifier 680, which includes a target stream identifier 684. The target stream identifier 684 corresponds to a future transmission of packets in a stream that is indicated as enabled for drop by a drop-enabled stream identifier 682. Therefore, from the perspective of the receiving user equipment, when one or more packets are lost in a stream transmission corresponding to the stream indicated by the drop-enabled stream identifier 682, the receiving user equipment may attempt to receive packets dropped from the drop-enabled stream 982 via the target stream 684. As an example, see reference... Figure 4 The described flow 430 can be indicated as a drop-enabled flow by indication 682, and flow 431 can be indicated as a target flow by indication 684, the target flow being configured to receive packets dropped from flow 430 and offloaded to flow 431.

[0150] Now go to Figure 7The accompanying figure illustrates a timing diagram of an example method 700 for discarding packets of a traffic stream at the receiving device without triggering a negative acknowledgment message transmission due to out-of-order packets. At action 705, RAN 105 may transmit to UE 115, and at action 710, the UE may receive dynamic discard information for a set of Protocol Data Units (“PDUs”) as part of a Radio Resource Control (“RRC”) configuration signaling procedure. (It should be understood that a PDU set may include multiple PDUs; for example, a traffic stream may include multiple packets.) For example, the discard information may include a PDU set identifier indicated as being associated with a traffic stream configured for packet discarding (e.g., for a traffic stream indicated by an identifier associated with the traffic stream, RAN 105 may not perform in-order delivery of PDUs for traffic streams corresponding to PDU set identifiers exceeding a standard (e.g., a delay standard). The discard information may include or may indicate a downlink control information format for monitoring and configuring the set of PDUs discarded by RAN 105. At action 715, the UE / WTRU 115 can monitor and blindly decode the control channel resources configured by RAN 105 for the UE to use for control channel signaling, and the UE can receive a DCI format indication that indicates the DCI format to be used in conjunction with a packet drop indication to determine how to process the set of PDUs identified by the corresponding PDU set identifier in the packet drop indication. The packet drop indication may indicate the DCI format for use by the UE 115. The packet drop indication may include information to be used in conjunction with the indicated DCI format to identify the set of PDUs (e.g., streams) to be packet-dropped by RAN 105. At action 720, the UE / WTRU 115 can determine the DCI format based on the packet drop indication, for example, by referring to... Figure 6A , Figure 6B or Figure 6C The described DCI format 605, 650, or 675, and the corresponding PDU set identifier, which resources are permitted for that PDU set identifier, and which packets are enabled for that PDU set identifier.

[0151] continue Figure 7As described, if UE 115 receives an out-of-order packet corresponding to the identified flow in a packet drop indication, or if packet drop is permitted by RAN 105 based on information received in the packet drop indication, then at action 725, UE / WTRU 115 may update the sequence number corresponding to the most recently received packet to be sequential with respect to the second most recently received packet in that flow. In embodiments, updating the sequence number may include renumbering the sequence number of the most recently received packet to be consistent with the second most recently received convention. In embodiments, updating the sequence number may include simply ignoring the sequence number of the lost packet, even if the lost packet is lost from a flow that UE 115 is not configured to treat as a best-effort flow. Therefore, by renumbering or otherwise updating the sequence number of the out-of-order received packet (e.g., skipping one or more sequence numbers relative to the second most recently received sequence number), UE 115 does not trigger the initiation of a packet drop wait timer or the initiation of a negative acknowledgment message, and the UE continues to receive packets for the indicated flow without expecting to receive packets corresponding to the lost sequence number. It should be understood that the sequence number of a given packet can be based on the sequence number of the immediately preceding sequential packet and the byte size of the immediately preceding sequential packet. Therefore, it should be understood that the incremental numbering of packets described in the various figures described herein is for illustrative purposes and is not intended to represent examples of actual packet sequence numbers or PDU sequence numbers.

[0152] In one embodiment, UE 115 can receive and decode one or more IP packets belonging to a PDU set, extract and decode the Media Access Control (“MAC”) control element (“CE”) attached to the packets, and determine PDU set-specific discard information. Upon detecting a MAC CE corresponding to the PDU set discarded as indicated in action 710, at action 725, UE / WTRU 115 can update the sequence number of the most recently received packet in the sequence number of the most recently received packet, so that the second most recently received packet is in the sequence relative to the flow described above.

[0153] Figure 8 A timing diagram of an example method 800 for offloading dropped packets to an alternative traffic stream is shown. At action 805, RAN node 105 may transmit a packet drop indication, including dynamic drop information of the PDU set, to UE 115. At action 810, UE 115 may receive the automatic packet drop indication transmitted at action 805. The automatic packet drop indication may be transmitted as part of a radio resource control configuration signaling message and may include information from... Figure 6A , Figure 6B ,or Figure 6CThe information shown may include information indicating information described in reference DCI formats 605, 650, or 675. The packet drop instruction, in conjunction with the information indicated by the indicated DCI format, may indicate automatic dropping of a set of PDUs (e.g., a PDU stream) identified by the PDU set identifier indicated by the packet drop instruction. In embodiments, the packet drop instruction may indicate stream dropping of the identified and indicated streams. In embodiments, the packet drop instruction may indicate stream dropping of the identified and indicated streams received via the identified resource. In such embodiments, the packet drop instruction may indicate that if a packet of a given traffic stream is received via a resource, packet dropping is enabled for that given traffic stream, but not for that given traffic stream if a packet of a given traffic stream is received via a different resource. In embodiments, the packet drop instruction may indicate stream dropping of the identified and indicated streams, wherein the dropped packets are indicated to be offloaded to a target stream to increase the likelihood that packets dropped from one stream can still be delivered via another stream (e.g., stream switching). At action 815, upon receiving an out-of-order packet associated with one or more PDU set identifiers configured to enable packet drop, the UE / WTRU 115 may determine the PDUDCI format based on a PDU drop format indication included in an automatic packet drop indication. At action 820, upon determining that drop has been enabled for the flow corresponding to the received out-of-order packet, the UE / WTRU 115 may update the sequence number of the most recently received packet to match the sequence number of the second most recent packet in the same flow. At action 825, upon determining that flow switching (e.g., via offload indication) has been enabled for the flow corresponding to the received out-of-order packet, the UE / WTRU 115 may determine one or more packets (or packet sequence numbers) that the RAN 105 may drop based on the UE 115 not receiving packets sequentially with other packets. The UE 115 may determine the target flow identifier (or associated resource) corresponding to the flow, and the RAN 105 may offload the transmission of the potentially dropped packets to that flow. At action 830, given the determination of the dropped packet and the target flow or resources of the target flow, the dropped packet is transmitted via the target flow, and the UE / WTRU 115 can update the reception configuration corresponding to the dropped packet based on the quality of service corresponding to the target flow.

[0154] Figure 9A flowchart of an example method 900 is shown, illustrating the discarding of packets from a traffic stream at a receiving device without out-of-order packets triggering the transmission of a negative acknowledgment message. Method 900 begins at action 905. At action 910, a radio access network node and a user equipment (UE) may establish a communication session. The communication session may be used for purposes facilitating applications performed on the UE, such as virtual reality applications facilitating the use of virtual reality devices. At action 920, the radio access network node may transmit a packet drop indication, and the UE may receive the packet drop indication. The establishment of the communication session at action 910 is shown by a dashed line around action 920 to illustrate that the transmission and reception of the packet drop indication may be part of establishing the communication session, for example, via an RRC signaling message, or the transmission and reception of the packet drop indication may be separate from the establishment of the communication session. The communication session may include one or more sets of protocol data units, such as one or more traffic streams comprising packets.

[0155] In action 925, the radio access network node may receive packets corresponding to a communication session directed to a user equipment and may store, place, or otherwise retain the packets in a buffer corresponding to the radio access network node. The buffer may be a scheduling buffer. In action 930, the radio access network node may determine whether network conditions are available for transmitting the packets stored in the buffer in action 925. For example, if congestion or radio interference impairs or may impair a channel that may have been configured during session establishment in action 910, resources may not be available for transmitting packets from the radio access network node to the user equipment. If action 930 determines that resources are unavailable for transmitting packets, method 900 proceeds to action 935. In action 935, the radio access network node may determine whether the packets have been in the buffer longer than a standard, such as a latency standard, which may be a configuration value corresponding to an application performed by the user equipment. If action 935 determines that the packets have not been in the buffer longer than the latency standard, method 900 returns to action 930.

[0156] Returning to the description of Action 930, if the radio access network node determines in Action 925 that there are resources available for transmitting packets received in the buffer, then in Action 945 the radio access network node may transmit packets to the user equipment.

[0157] Returning to the description of action 935, if it is determined that the packet received in the buffer in action 925 has been in the buffer for longer than the delay criterion, then method 900 proceeds to action 940. At action 940, the radio access network node can determine whether offloading is enabled via a packet drop instruction transmitted to the user equipment in action 920. If offloading of packets for the stream corresponding to the packet stored in the buffer in action 925 is not enabled, then at action 942, the radio access network node drops the packet from the buffer, method 900 returns to action 925, and the radio access network node can continue to receive packets directed to the user equipment into the scheduling buffer.

[0158] Returning to the description of action 940, if the radio access network node determines that packet offloading of the flow corresponding to the packet stored in the buffer at action 925, established at action 910, is enabled, the radio access network node can offload the packet at action 944. Offloading the packet stored in the buffer at action 925 may include: removing the packet from the buffer, selecting a resource corresponding to a different traffic flow, and then selecting the resource through which the packet can be configured to be transmitted via the flow corresponding to the packet. After offloading the packet stored in the buffer at action 925, the radio access network node can transmit the packet to the user equipment at action 945 using resources different from those already transmitted at action 945 after method 900 proceeds from action 930 to action 945. In other words, the radio access network node can use resources corresponding to and configured for the second traffic flow indicated by the packet drop instruction, instead of using resources corresponding to the first traffic flow, which may be the traffic flow corresponding to the packet stored in the buffer at action 925.

[0159] After the radio access network node transmits the packet at action 945, the user equipment to which the packet is directed can receive the packet, and at action 950 it is determined whether the packet contains a sequence number that is out of order relative to the most recently received packet. If the user equipment determines at action 950 that the just received packet is not out of order, then method 900 proceeds to action 955 and ends. If the radio access network node determines at action 930 that resources are available for transmitting the packet, the packet has not exceeded the delay standard in the buffer, and the radio access network node determines at action 930 that there are sufficient network resources available for transmitting the packet, then transmitting the packet at action 945 may not result in the packet being out of order.

[0160] Returning to the description of action 950, if it is determined that the packet transmitted at action 945 is out of order, method 900 proceeds to action 960. At action 960, the user equipment may determine whether the packet drop indication received at action 920 indicates that packet drop corresponding to the flow containing the packet transmitted at action 945 is enabled. If it is determined that packet drop is enabled for the flow corresponding to the packet transmitted at action 945, method 900 proceeds to action 965. At action 965, the user equipment may determine whether offloading is indicated by the packet drop indication received at action 920. If it is determined that the packet drop indication does not indicate that packet offloading is enabled, method 900 proceeds to action 970. At action 970, the user equipment may continue operation without sending a negative acknowledgment message to the radio access network node, indicating that one or more packets may have been lost in the flow corresponding to the packet transmitted at action 945 and determined to be out of order at action 950. Method 900 proceeds to action 955 and ends.

[0161] Returning to the description of action 965, if it is determined at action 965 that the packet drop instruction received at action 920, indicating that packet offloading is enabled, then method 900 proceeds to action 975 and receives the packet transmitted at action 945. At action 975, the user equipment can tune to a resource corresponding to a different traffic stream than the traffic stream corresponding to the packet transmitted at action 945. The different traffic stream can be the traffic stream of the communication session established at action 910, which has different quality of service, different latency budgets, different reliability targets, or different other quality-related characteristics. The user equipment can receive at action 975 the packet offloaded at action 944 and transmitted at action 945 according to one or more quality characteristics corresponding to the different traffic stream.

[0162] Therefore, using the offloading indicated by the packet drop instruction received at action 920, the user equipment can receive packets stored in the buffer at action 925, packets that may have been dropped and not transmitted by the radio access network node, for example, due to channel congestion. However, transmission of packets via offloading resources corresponding to a different traffic flow than the traffic flow corresponding to the packets may have lower reliability than the original flow of the packets. However, using offloading at least provides the possibility that packets can be delivered instead of being dropped and not transmitted by the radio access network node. After receiving the packets transmitted at action 945 via offloading, method 900 proceeds to action 977, and the user equipment continues to operate on lost packets without transmitting NACK to the radio access network node. The method proceeds from action 977 to action 95 and ends.

[0163] Returning to the description of action 960, if the user equipment determines that dropping the packet identified as out of order in action 950 is not permissible, method 900 proceeds to action 980. At action 980, the user equipment transmits a negative acknowledgment to the radio access network node and waits at action 985 to receive a packet in response to that negative acknowledgment. It should be understood that the user equipment's wait for receiving the lost packet at action 985 is not necessarily a wait corresponding to a timer used by the user equipment to determine whether the lost packet corresponding to the out-of-order packet has been received, but may correspond to a wait before sending a negative acknowledgment. At action 990, the user equipment receives the lost packet corresponding to the packet identified as out of order at action 950 and continues operation on that lost packet. Method 900 proceeds from action 990 to action 955 and terminates.

[0164] It should be understood that if the user equipment determines at action 960 to discard a packet corresponding to the flow corresponding to the packet determined to be out of order at action 950, this determination can be made based on a packet discarding indication received at 920 that does not indicate that the flow corresponding to the packet determined to be out of order at action 950 is allowed to be discarded. It should also be understood that the packet discarding indication received at action 920, used by the user equipment to determine at action 960 that discarding is not enabled, can indicate that if the user equipment receives the packet according to a first resource, the flow corresponding to the packet determined to be out of order at action 950 can be enabled for discarding; however, if the user equipment receives the packet according to a second resource or a different resource, discarding of the flow corresponding to the packet is not enabled.

[0165] like Figure 9 As can be seen, if the user equipment determines at action 960 that packet dropping is not enabled for the flow corresponding to the packet determined to be out of order at action 950, the user equipment transmits a negative acknowledgment at action 980, waits for the lost packet at action 985, and then receives and operates on the lost packet at action 990.

[0166] Conversely, if dropping packets from a flow corresponding to a packet determined to be out of order at action 950 is permitted, the user equipment (UE) does not transmit a negative acknowledgment and operates without lost packets at action 970, or receives lost packets via offload resources and operates with lost packets at action 977. Therefore, based on the information included in the packet drop instruction received at action 920, the UE can be configured to identify a packet determined to be out of order at action 950 corresponding to a flow for which, after determining the packet is out of order, the radio access network node can drop the packet from the scheduling buffer if the packet exceeds a delay criterion at action 935, without additional message transmission or delay at the UE.

[0167] Now go to Figure 10 The accompanying drawing illustrates an example embodiment of method 1000, which includes, at block 1005, establishing a communication session including a first traffic stream associated with quality of service by a radio access network node including a processor having a user equipment; at block 1010, transmitting a packet drop indication corresponding to the first traffic stream to the user equipment by the radio access network node, wherein the packet drop indication indicates to the user equipment that out-of-order packets of the first traffic stream will indicate that the radio access network node will drop packets of the first traffic stream; at block 1015, receiving at least one packet into a buffer by the radio access network node, the at least one packet being transmitted to the user equipment via the first traffic stream; at block 1020, determining a buffering time for the at least one packet in the buffer to obtain a determined buffering time; at block 1025, analyzing the determined buffering time relative to a delay criterion corresponding to the first quality of service by the radio access network node to obtain an analyzed determined buffering time; and at block 1030, discarding the at least one packet based on the analyzed determined buffering time being determined to meet the delay criterion.

[0168] Now go to Figure 11 The accompanying drawing illustrates an example first communication device 1100, which includes a processor at block 1105 configured to establish a communication session with a second communication device comprising at least a first traffic stream; at block 1110, receiving at least one packet of the first traffic stream into a buffer corresponding to the first communication device, the at least one packet being transmitted to the second communication device corresponding to the first traffic stream; at block 1115, determining the buffering time of the at least one packet of the first traffic stream in the buffer to obtain a determined buffering time; at block 1120, analyzing the determined buffering time relative to a first delay criterion corresponding to the first traffic stream to obtain an analyzed determined buffering time; at block 1125, based on the analyzed determined buffering time satisfying the first delay criterion, discarding at least one packet of the first traffic stream according to a packet discarding indication; and at block 1130, wherein the establishment of the communication session includes transmitting a packet discarding indication corresponding to the first traffic stream, wherein the packet discarding indication is used to indicate that out-of-order packets of the first traffic stream indicate that packets of the first traffic stream are discarded.

[0169] Now go to Figure 12The accompanying drawing illustrates a non-transient machine-readable medium 1200 including executable instructions at block 1205, which, when executed by a processor of a radio access network node, facilitates the execution of operations including establishing a communication session with a user equipment including a first traffic stream associated with a first maximum delay; enabling packet dropping for the first traffic stream at block 1210 based on the first maximum delay; transmitting a packet dropping indication at block 1215, indicating to the user equipment that out-of-order packets of the first traffic stream indicate that the radio access network node has dropped at least one packet of the first traffic stream; receiving packets of the first traffic stream into a buffer at block 1220; determining the time a packet has been in the buffer at block 1225 to obtain a determined buffer time at block 1225; analyzing the determined buffer time relative to the first maximum delay at block 1230 to obtain an analyzed determined buffer time at block 1230; and dropping the packet at block 1235 based on the analyzed determined buffer time exceeding the first maximum delay to obtain a dropped packet.

[0170] Now go to Figure 13 The accompanying drawing illustrates an example embodiment of method 1300, which includes, at block 1305, establishing a communication session including a first traffic stream by a user equipment including a processor having a radio access network node to facilitate the execution of an application by the user equipment; at block 1310, receiving a packet drop indication corresponding to the first traffic stream from the radio access network node by the user equipment; at block 1315, receiving a first out-of-order packet corresponding to the first traffic stream by the user equipment; at block 1320, suppressing the transmission of negative acknowledgments corresponding to the first out-of-order packet to the radio access network node based on the packet drop indication; at block 1325, using the first out-of-order packet to execute an application by the user equipment; and at block 1330, wherein the packet drop indication includes a first stream identifier corresponding to the first traffic stream, wherein the first stream identifier indicates that packet drop is enabled by the radio access network node, the packet drop being applied to packets constituting the first traffic stream, and wherein the user equipment suppresses the transmission of negative acknowledgments corresponding to the first out-of-order packet to the radio access network node based on the first out-of-order packet corresponding to the first stream identifier.

[0171] Now go to Figure 14The accompanying drawing illustrates an example first communication device 1400, which includes a processor at block 1405 configured to establish a communication session with a second communication device comprising at least a first traffic stream. The establishment of the communication session includes receiving a packet drop indication corresponding to the first traffic stream, wherein the packet drop indication includes a first stream identifier corresponding to the first traffic stream, and wherein the packet drop indication is used to indicate that an out-of-order packet including the first stream identifier indicates that a packet of the first traffic stream has been dropped by the second communication device; at block 1410, receiving a first packet including the first stream identifier from the second communication device; at block 1415, receiving a second packet including the first stream identifier from the second communication device; at block 1420, determining that the second packet is out of order relative to the first packet to obtain the determined out-of-order packet; and at block 1425, suppressing the transmission of a negative acknowledgment corresponding to the third packet based on the determined out-of-order packet indicating that at least a third packet of the first traffic stream has been dropped by the second communication device.

[0172] Now go to Figure 15 The accompanying drawing illustrates a non-transient machine-readable medium 1500 including executable instructions at block 1505, which, when executed by a processor of a user equipment, facilitates the execution of operations including receiving a radio resource control message from a radio access network node by the user equipment. The radio resource control message includes a downlink control information format indication indicating a downlink control information format, wherein the downlink control information format includes a protocol data unit discard indication corresponding to a communication session between the user equipment and the radio access network node, wherein the communication session includes at least a first set of protocol data units, and wherein the protocol data unit discard indication is used to indicate that out-of-order data units of the first set of protocol data units are to indicate that data units of the first set of protocol data units are discarded by the radio access network node; at block 1510, the user equipment receives out-of-order data units corresponding to the first set of protocol data units from the radio access network node to obtain received out-of-order data units; and at block 1515, based on the reception of the received out-of-order data units, and according to the protocol data unit discard indication, the user equipment determines to suppress the transmission of a negative acknowledgment corresponding to the out-of-order data units to the radio access network node.

[0173] To provide additional context for the various embodiments described herein, Figure 16 The following discussion is intended to provide a brief overview of a suitable computing environment 1600 in which various embodiments of the embodiments described herein may be implemented. While the embodiments have been described above in the general context of computer-executable instructions that can run 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.

[0174] Typically, program modules include routines, programs, components, data structures, etc., that perform specific tasks or implement specific abstract data types. Furthermore, those skilled in the art will appreciate that this method can be practiced using other computer system configurations, including single-processor or multi-processor computer systems, minicomputers, IoT devices, distributed computing systems, and personal computers, handheld computing devices, microprocessor-based or programmable consumer electronics, etc., each of which can be operatively coupled to one or more associated devices.

[0175] The embodiments illustrated herein can also be practiced in a distributed computing environment, where certain tasks are performed by remote processing devices linked via a communication network. In a distributed computing environment, program modules can reside on both local and remote memory storage devices.

[0176] Computing devices typically include various media, which may include computer-readable storage media, machine-readable storage media, and / or communication media, these two terms being used interchangeably herein as follows. A computer-readable storage medium or a machine-readable storage medium can be any available storage medium accessible to a computer, and includes volatile and non-volatile media, removable and non-removable media. By way of example and not limitation, a computer-readable storage medium or a machine-readable storage medium can be implemented in conjunction with any method or technique for storing information, such as computer-readable or machine-readable instructions, program modules, structured data, or unstructured data.

[0177] Computer-readable storage media may include, but is not limited to, random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, optical disc read-only memory (CDROM), digital versatile disc (DVD), Blu-ray disc (BD) or other optical disc storage devices, magnetic tape cassettes, magnetic tape, disk storage devices, or other magnetic storage devices, solid-state drives or other solid-state storage devices, or other tangible and / or non-transient media that can be used to store desired information. In this regard, the terms “tangible” or “non-transient” as used herein for storage devices, memories, or computer-readable media shall be understood to exclude the use of the modifier “only propagating transient signals” and shall not waive the rights to all standard storage devices, memories, or computer-readable media that do not only propagate transient signals.

[0178] Computer-readable storage media can be accessed by one or more local or remote computing devices, for example, through access requests, queries, or other data retrieval protocols, for various operations concerning the information stored on the media.

[0179] Communication media typically embody computer-readable instructions, data structures, program modules, or other structured or unstructured data in data signals such as modulated data signals (e.g., carrier waves or other transmission mechanisms), and include any information transmission or delivery medium. The terms "modulated data signal" or "multiple signals" refer to signals whose one or more characteristics are set or altered in a manner that encodes information in one or more signals. By way of example and not limitation, communication media include wired media (such as wired networks or direct-line connections) and wireless media (such as acoustic, RF, infrared, and other wireless media).

[0180] Refer again Figure 16 Example environment 1300 for implementing various embodiments of the various aspects described herein includes computer 1302, which includes processing unit 1604, system memory 1606, and system bus 1608. System bus 1608 couples system components, including but not limited to system memory 1606, to processing unit 1604. Processing unit 1604 can be any of a variety of commercially available processors and may include cache memory. Dual microprocessors and other multiprocessor architectures may also be used as processing unit 1604.

[0181] System bus 1608 can be any of several types of bus architectures, and it can also interconnect to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of the various commercially available bus architectures. System memory 1606 includes ROM 1610 and RAM 1612. The Basic Input / Output System (BIOS) can be stored in non-volatile memory (such as ROM, erasable programmable read-only memory (EPROM), EEPROM), where the BIOS includes basic routines such as those that help transfer information between components within computer 1602 during startup. RAM 1612 can also include high-speed RAM, such as static RAM for caching data.

[0182] Computer 1602 also includes an internal hard disk drive (HDD) 1614 (e.g., EIDE, SATA), one or more external storage devices 1616 (e.g., floppy disk drive (FDD) 1616, memory stick, or flash drive reader, memory card reader, etc.), and an optical disc drive 1620 (e.g., capable of reading from or writing to CD-ROMs, DVDs, BDs, etc.). While the internal HDD 1614 is shown as residing within computer 1602, it can also be configured for external use in a suitable chassis (not shown). Furthermore, although not shown in environment 1600, a solid-state drive (SSD) may be used in addition to or in place of the HDD 1614. The HDD 1614, external storage device 1616, and optical disc drive 1620 can be connected to system bus 1608 via HDD interface 1624, external storage interface 1626, and optical disc drive interface 1628, respectively. The interface 1624 for external driver implementation may include at least one of Universal Serial Bus (USB) and Institute of Electrical and Electronics Engineers (IEEE) 1394 interface technologies, or both. Other external driver connectivity technologies are also within the scope of the embodiments described herein.

[0183] The drive and its associated computer-readable storage medium provide non-volatile storage means for data, data structures, computer-executable instructions, etc. For computer 1602, the drive and storage medium accommodate storage of any data in a suitable digital format. Although the above description of computer-readable storage media refers to a corresponding type of storage device, those skilled in the art will understand that other types of computer-readable storage media, whether currently existing or developed in the future, may also be used in the example operating environment, and further, any such storage medium may include computer-executable instructions for performing the methods described herein.

[0184] Multiple program modules can be stored in the drive and RAM 1612, including an operating system 1630, one or more applications 1632, other program modules 1634, and program data 1636. All or part of the operating system, applications, modules, and / or data can also be cached in RAM 1612. The systems and methods described herein can be implemented using various commercially available operating systems or combinations of operating systems.

[0185] Computer 1602 may optionally include emulation technology. For example, a system management program (not shown) or other intermediate program may emulate the hardware environment of operating system 1630, and the emulated hardware may optionally be different from that of operating system 1630. Figure 16The hardware shown is illustrated. In this embodiment, the operating system 1630 may include one of a plurality of virtual machines (VMs) hosted on the computer 1602. Furthermore, the operating system 1630 may provide a runtime environment for the application 1632, such as the Java Runtime Environment or the .NET Framework. A runtime environment is a consistent execution environment that allows the application 1632 to run on any operating system that includes a runtime environment. Similarly, the operating system 1630 may support containers, and the application 1632 may be in the form of containers, which are lightweight, stand-alone, executable software packages including, for example, code, runtime, system tools, system libraries, and application-specific settings.

[0186] Furthermore, computer 1602 may include a security module, such as a Trusted Processing Module (TPM). For example, with a TPM, before loading the next boot component, the boot component hashes the next boot component in time and waits for the result to match a security value. This process can occur at any layer of the computer 1602's code execution stack, for example, at the application execution level or at the operating system (OS) kernel level, thereby enabling security at any code execution level.

[0187] Users can input commands and information into computer 1602 using one or more wired / wireless input devices (such as keyboard 1638, touchscreen 1640, and pointing devices such as mouse 1642). Other input devices (not shown) may include microphones, infrared (IR) remote controls, radio (RF) remote controls, or other remote controls, joysticks, virtual reality controllers and / or virtual reality headsets, gaming pads, pointing pens, image input devices (e.g., cameras), gesture sensor input devices, visual motion sensor input devices, emotion or facial detection devices, biometric input devices (e.g., fingerprint or iris scanners), etc. These and other input devices are typically connected to processing unit 1604 via input device interface 1644, which may be coupled to system bus 1608, but may also be connected via other interfaces, such as parallel ports, IEEE 1394 serial ports, gaming ports, USB ports, IR interfaces, etc. Interfaces, etc.

[0188] The monitor 1646 or other types of display devices can also be connected to the system bus 1608 via an interface such as the video adapter 1648. In addition to the monitor 1646, the computer typically includes other peripheral output devices (not shown), such as speakers, printers, etc.

[0189] Computer 1602 can operate in a networked environment using a logical connection to one or more remote computers (e.g., remote computer 1650) via wired and / or wireless communication. Remote computer 1650 can be a workstation, server computer, router, personal computer, portable computer, microprocessor-based entertainment device, peer-to-peer device, or other public network node, and typically includes many or all of the elements described relative to computer 1602, although only memory / storage device 1652 is shown for the sake of brevity. The depicted logical connections include wired / wireless connections to a local area network (LAN) 1654 and / or a larger network (e.g., a wide area network (WAN) 1656). Such LAN and WAN network environments are common in offices and companies and facilitate enterprise-wide computer networks such as intranets, all of which can connect to global communication networks such as the Internet.

[0190] When used in a LAN networking environment, computer 1602 can be connected to local network 1654 via a wired and / or wireless communication network interface or adapter 1658. Adapter 1658 facilitates wired or wireless communication with LAN 1654, which may also include a wireless access point (AP) placed thereon for wireless communication with adapter 1658.

[0191] When used in a WAN networking environment, computer 1602 may include modem 1660, or may be connected to a communication server on WAN 1656 via other means for establishing communication on WAN 1656 (e.g., via the Internet). Modem 1660 may be built-in or external, wired or wireless, and may be connected to system bus 1608 via input device interface 1644. In a networked environment, program modules depicted relative to computer 1602 or parts thereof may be stored in remote memory / storage device 1652. It will be understood that the network connections shown are illustrative, and other means for establishing communication links between computers may be used.

[0192] When used in a LAN or WAN networking environment, computer 1602 can access a cloud storage system or other network-based storage systems besides or replacing the external storage device 1616 described above. Typically, the connection between computer 1602 and the cloud storage system can be established on LAN 1654 or WAN 656 via, for example, adapter 1658 or modem 1660. When connecting computer 1602 to an associated cloud storage system, external storage interface 1626 can manage the storage devices provided by the cloud storage system, just like other types of external storage devices, via adapter 1658 and / or modem 1660. For example, external storage interface 1626 can be configured to provide access to cloud storage sources, just like those physically connected to computer 1602.

[0193] Computer 1602 may be operable to communicate with any wireless device or entity operably placed in wireless communication, such as a printer, scanner, desktop and / or portable computer, portable data assistant, communication satellite, any device or location associated with a wirelessly detectable tag (e.g., kiosk, newsstand, shop shelf, etc.), and telephone. This may include Wi-Fi and Wireless technology. Therefore, communication can be a pre-defined structure like a traditional network, or simply self-organizing communication between at least two devices.

[0194] Go to Figure 17 The accompanying figure shows a block diagram of an example UE 1760. UE 1760 may include a smartphone, a wireless tablet computer, a wirelessly capable laptop computer, a wearable device, a machine that can facilitate vehicle telematics, a tracking device, a remote sensing device, etc. UE 1760 includes a first processor 1730, a second processor 1732, and shared memory 1734. UE 1760 includes a radio front-end circuitry 1762, which may be referred to herein as a transceiver, but is understood to generally include transceiver circuitry, a separate filter, and a separate antenna for facilitating communication over a wireless link (e.g., [missing information]). Figure 1 Transmitters 1762 transmit and receive signals on one or more wireless links 125, 135, and 137. Furthermore, transceiver 1762 may include a plurality of circuitry sets, 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 125), device-to-device links (e.g., link 135), and short-range wireless links (e.g., link 137).

[0195] Continue to Figure 17As described above, UE 1760 may also include SIM 1764 or SIM profile, which may include information stored in memory (memory 34 or a separate memory portion) for facilitating communication with... Figure 1 The wireless communication of RAN105 or core network 130 shown in the diagram. Figure 17 The SIM 1764 is shown as a single component in the shape of a traditional SIM card; however, it will be understood that the SIM 1764 can represent multiple SIM cards, multiple SIM profiles, or multiple eSIMs, some or all of which can be implemented in hardware or software. It will be understood that a SIM profile may include, for example, security credentials (e.g., encryption keys, values ​​that can be used to generate encryption keys, or information about the connection between the SIM 1764 and another device, which may be...) Figure 1 Information shared between components of RAN 105 or core network 130 as shown in the diagram. SIM profile 1764 may also include unique identification information for the SIM or SIM profile, such as the International Mobile Subscriber Identity (“IMSI”) or information that may constitute the IMSI.

[0196] SIM 1764 is shown as being coupled to a first processor section 1730 and a second processor section 1732. This implementation provides the advantage that the first processor section 30 does not need to request or receive information or data from SIM 1764, which can be requested from the second processor 1732, thus eliminating the use of the first processor as a "middleman" when the second processor uses information from the SIM in performing its functions and executing applications. The first processor 1730 (which may be a modem processor or a baseband processor) is shown as smaller than processor 1732 (which may be a more complex application processor) to visually indicate the relative complexity (i.e., processing power and performance) and corresponding relative operating power consumption between the two processor sections. Keeping the second processor section 1732 in a sleep / inactive / low-power state when the UE 1760 does not need it to execute applications and process application-related data provides the following advantages: reduced power consumption when the UE only needs to use the first processor section 1730 while in listening mode to monitor bearer management and mobility management / maintenance processes of a regular configuration, or to monitor the search space that the UE has been configured to monitor while the second processor section remains inactive / sleep.

[0197] UE 1760 may also include a sensor 1766 that can provide signals to the first processor 1730 or the second processor 1732, such as a temperature sensor, accelerometer, gyroscope, barometer, humidity sensor, etc. Output device 1768 may include, for example, one or more visual displays (e.g., computer monitors, VR devices, etc.), acoustic transducers (e.g., speakers or microphones), vibration components, etc. Output device 1768 may include software that interfaces with output devices external to UE 1760 (e.g., visual displays, speakers, microphones, tactile devices, olfactory or gustatory devices, etc.).

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

[0199]

[0200]

[0201] Table 1

[0202] The above description includes non-limiting examples of various embodiments. It is certainly not possible to describe every contemplative combination of components or methods for the purpose of describing the disclosed subject matter, and those skilled in the art will recognize that further combinations and arrangements of various embodiments are possible. The disclosed subject matter is intended to cover all such changes, modifications, and variations falling within the spirit and scope of the appended claims.

[0203] Regarding the various functions performed by the components, devices, circuits, systems, etc., described above, unless otherwise indicated, the terminology used to describe these components (including references to "apparatus") is intended to also include any structure (e.g., functional equivalent) that performs the specified functions of the described components, even if it is not structurally equivalent to the disclosed structure. Furthermore, while specific features of the disclosed subject matter may be disclosed only with respect to one of several implementations, such features may be combined with one or more other features of other implementations, which may be desirable and advantageous for any given or particular application.

[0204] The terms “exemplary” and / or “illustrative” or variations thereof, as used herein, are intended to mean as examples, instances, or illustrations. For the avoidance of doubt, the subject matter disclosed herein is not limited to these examples. Furthermore, any aspect or design described herein as “exemplary” and / or “illustrative” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor does it exclude equivalent structures and techniques known to those skilled in the art. Moreover, with regard to the use of the terms “comprising,” “having,” “containing,” and other similar words in the detailed description or claims, these terms are intended to be inclusive—in a manner similar to the term “comprising” as an open-ended transition—without excluding any additional or other elements.

[0205] As used herein, the term “or” refers to 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 articles “a” and “an” as used in this application and the appended claims should generally be interpreted as meaning “one or more” unless otherwise stated or clearly indicated from the context.

[0206] As used herein, the term "set" does not include an empty set, i.e., a set containing no elements. Therefore, "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.

[0207] The terms “first,” “second,” “third,” etc., used in the claims are for clarity only and do not otherwise indicate or imply any temporal order unless the context clearly states otherwise. For example, “first determination,” “second determination,” and “third determination” do not indicate or imply that the first determination will precede the second determination, or vice versa, etc.

[0208] The description of the embodiments shown in this disclosure, including those described in the abstract, is not intended to be exhaustive or to limit the disclosed embodiments to their precise forms. While specific embodiments and examples have been described herein for illustrative purposes, those skilled in the art will recognize that various modifications can be contemplated within the scope of these embodiments and examples. In this regard, although the subject matter has been described herein in conjunction with various embodiments and corresponding drawings, it will be understood where applicable that other similar embodiments may be used, or modifications and additions may be made to the described embodiments to perform the same, similar, alternative, or substitute functions of the disclosed subject matter without departing from the subject matter. Therefore, the disclosed subject matter should not be limited to any single embodiment described herein, but should be interpreted in accordance with the breadth and scope of the appended claims.

Claims

1. A method comprising: A communication session, including a first traffic stream, is established by a user equipment including a processor with a radio access network node to facilitate the execution of an application by the user equipment; The user equipment receives a packet drop indication corresponding to the first traffic flow from the radio access network node; The user equipment receives a first out-of-order packet corresponding to the first traffic stream; Based on the packet drop indication, the user equipment suppresses the transmission of negative acknowledgments corresponding to the first out-of-order packet to the radio access network node; as well as The application is executed by the user equipment using the first out-of-order packet.

2. The method of claim 1, wherein the communication session includes a second traffic stream, and the method further includes: The user equipment receives a second out-of-order packet corresponding to the second traffic stream; A negative acknowledgment corresponding to the second out-of-order packet is transmitted to the radio access network node; Based on the transmission with the negative acknowledgment, a lost packet corresponding to the second traffic stream is received; as well as The user equipment uses the lost packets to execute the application.

3. The method of claim 1, wherein the packet drop indication includes a first flow identifier corresponding to the first traffic flow, wherein the first flow identifier indicates that packet drop is enabled by the radio access network node, the packet drop is to be applied to packets constituting the first traffic flow, and wherein the user equipment suppresses the transmission of negative acknowledgments to the radio access network node corresponding to the first out-of-order packet based on the first out-of-order packet corresponding to the first flow identifier.

4. The method of claim 3, further comprising determining a latency corresponding to the first traffic flow by the user equipment, wherein the application corresponds to an application type, and wherein the latency is determined based on the application type.

5. The method of claim 4, wherein the delay standard corresponds to the first traffic stream, wherein the establishment of the communication session includes transmitting a radio resource control message indicating the delay standard, and wherein one or more packets of the first traffic stream longer than the delay standard are discarded and are to be applied to a buffer stored in the radio access network node.

6. The method of claim 1, wherein the packet drop indication includes a first flow identifier corresponding to the first traffic stream, wherein the packet drop indication includes a first resource associated with the first flow identifier, wherein the first flow identifier associated with the first resource indicates packet drop enabled by the radio access network node, the packet drop being applied to packets constituting the first traffic stream transmitted via the first resource, and wherein the transmission of a negative acknowledgment corresponding to the first out-of-order packet is suppressed by the user equipment based on the correspondence between the first out-of-order packet and the first flow identifier, and based on the first out-of-order packet being received via the first resource.

7. The method of claim 1, wherein the packet drop indication includes a first flow identifier corresponding to the first traffic flow, wherein the packet drop indication includes a first resource associated with the first flow identifier, wherein the communication session includes a second traffic flow, wherein the packet drop indication includes a second flow identifier corresponding to the second traffic flow, wherein the packet drop indication includes a second resource associated with the second flow identifier, wherein the packet drop indication includes a packet offload indication for indicating that out-of-order packets of the first traffic flow are to be transmitted by the radio access network node to the user equipment via the second resource, the method further comprising: Based on the packet offloading instruction, the user equipment receives the lost packet of the first traffic stream corresponding to the first out-of-order packet via the second resource; as well as The user equipment uses the lost packets to execute the application.

8. The method of claim 7, wherein the first traffic flow is associated with a first priority, wherein the second traffic flow is associated with a second priority, and wherein the second priority is lower than the first priority.

9. The method of claim 8, wherein the first flow stream corresponds to data directed to the central portion of the virtual reality device, and wherein the second flow stream corresponds to data directed to the peripheral portion of the virtual reality device.

10. The method of claim 1, wherein the application is any real-world application that manages a virtual reality device communicatively coupled to the user equipment.

11. The method of claim 1, wherein the establishment of the communication session includes receiving a radio resource control message, the radio resource control message including the packet drop indication and associating the packet drop indication with a first traffic flow identifier corresponding to the first traffic flow.

12. The method of claim 1, wherein the establishment of the communication session includes receiving a radio resource control message, the radio resource control message including the packet drop indication and associating the packet drop indication with a protocol data unit set identifier corresponding to the first traffic stream.

13. The method of claim 1, wherein the establishment of the communication session includes receiving a radio resource control message including the packet drop indication, and wherein the packet drop indication is used to indicate the association of the packet drop indication with a category quality identifier corresponding to the first traffic stream.

14. A first communication device, comprising: Processor, the processor being configured to: Establish a communication session with a second communication device including at least a first traffic stream, wherein the establishment of the communication session includes receiving a packet drop indication corresponding to the first traffic stream, wherein the packet drop indication includes a first stream identifier corresponding to the first traffic stream, and wherein the packet drop indication is used to indicate that out-of-order packets including the first stream identifier indicate that packets of the first traffic stream have been dropped by the second communication device; Receive a first packet including the first stream identifier from the second communication device; Receive a second packet including the first stream identifier from the second communication device; Determine that the second group is out of order relative to the first group to obtain the determined out-of-order group; as well as Based on the determined out-of-order packet indication, at least a third packet of the first traffic stream that has been discarded by the second communication device is suppressed from transmission of a negative acknowledgment corresponding to the third packet.

15. The first communication device of claim 14, wherein the communication session includes a second traffic stream, wherein the packet drop indication includes a first resource indication and a second resource indication, the first resource indication indicating a first resource to be used for transmitting the first traffic stream, the second resource indication indicating a second resource to be used for transmitting the second traffic stream, and wherein the packet drop indication includes an offloading indication for dropped packets of the first traffic stream transmitted by the second communication device via the second resource, wherein the processor is further configured to: Based on the unload instruction, the third packet is received via the second resource.

16. The first communication device according to claim 15, wherein the first traffic stream corresponds to a first reliability, wherein the second traffic stream corresponds to a second reliability, and wherein the second reliability is lower than the first reliability.

17. A non-transient machine-readable medium, the non-transient machine-readable medium comprising executable instructions that, when executed by a processor of a user device, facilitate the execution of operations, the operations comprising: The user equipment receives a radio resource control message from a radio access network node, including a downlink control information format indication indicating the downlink control information format, wherein the downlink control information format includes a protocol data unit discard indication corresponding to a communication session between the user equipment and the radio access network node, wherein the communication session includes at least a first protocol data unit set, and wherein the protocol data unit discard indication is used to indicate that out-of-order data units of the first protocol data unit set indicate that data units of the first protocol data unit set are discarded by the radio access network node; The user equipment receives out-of-order data units corresponding to the first protocol data unit set from the radio access network node to obtain the received out-of-order data units; as well as Based on the reception of the out-of-order data unit, and in accordance with the protocol data unit discard instruction, the user equipment determines to suppress the transmission of a negative acknowledgment corresponding to the out-of-order data unit to the radio access network node.

18. The non-transient machine-readable medium of claim 17, wherein the protocol data unit discard indication includes a first protocol data unit set identifier corresponding to the first protocol data unit set, wherein the received out-of-order data unit includes the first protocol data unit set identifier, and wherein the user equipment determines to suppress the transmission of a negative acknowledgment corresponding to the out-of-order data unit to the radio access network node based on the received out-of-order data unit including the first protocol data unit set identifier.

19. The non-transient machine-readable medium of claim 17, wherein the downlink control information format indicates a resource to be used by the radio access network node for transmission of the first protocol data unit set to the user equipment, wherein the protocol data unit discard indication includes a first protocol data unit set identifier corresponding to the first protocol data unit set, wherein the protocol data unit discard indication is used to indicate that out-of-order data units received via the resource, including the first protocol data unit set identifier, indicate data units in the first protocol data unit set that have been discarded by the radio access network node, and wherein the received out-of-order data units include the first protocol data unit set identifier and are received via the resource.

20. The non-transient machine-readable medium of claim 17, wherein the communication session includes a second set of protocol data units, wherein the downlink control information format indicates a first resource to be used by the radio access network node for transmission of the first set of protocol data units to the user equipment, wherein the downlink control information format indicates a second resource to be used by the radio access network node for transmission of the second set of protocol data units to the user equipment, wherein the protocol data unit discard indication includes a first protocol data unit set identifier corresponding to the first set of protocol data units, wherein the protocol data unit discard indication includes a second protocol data unit set identifier corresponding to the second ... The protocol data unit (DAC) drop instruction includes an offload instruction, which indicates that data units in the first protocol data unit set to be dropped by the radio access network node should be offloaded from the first protocol data unit set for transmission by the radio access network node to the user equipment via the second resource. The protocol data unit drop instruction indicates out-of-order data units, including a first protocol data unit set identifier received via the first resource, indicating that data units in the first protocol data unit set already dropped by the radio access network node are dropped data units. The received out-of-order data units include the first protocol data unit set identifier and are received via the first resource. The operation also includes: Based on the received out-of-order data unit including the first protocol data unit set identifier and received via the first resource, at least one discarded data unit from the first protocol data unit set discarded by the radio access network node is received via the second resource.

Images