WO2022016489A1

WO2022016489A1 - Polling and status reporting for network coding

Info

Publication number: WO2022016489A1
Application number: PCT/CN2020/104029
Authority: WO
Inventors: Ruiming Zheng; Changlong Xu; Jian Li; Kangqi LIU; Liangming WU; Peng Cheng; Hao Xu
Original assignee: Qualcomm Incorporated
Priority date: 2020-07-24
Filing date: 2020-07-24
Publication date: 2022-01-27

Abstract

Methods, systems, and devices for wireless communications are described. A receiving device may receive a set of packet data convergence protocol (PDCP) protocol data units (PDUs) at a PDCP layer from a transmitting device. The set of PDCP PDUs may correspond to one or more PDCP service data units (SDUs). The receiving device may generate a report indicating a status of the set of PDCP PDUs or the one or more PDCP SDUs at the PDCP layer. The receiving device may transmit the report to the transmitting device. The receiving device may receive a subsequent PDCP PDU that includes a polling flag from the transmitting device, and the report may be generated based on the polling flag. The report may be additionally or alternatively be generated based on the expiration of a timer at the receiving device.

Description

POLLING AND STATUS REPORTING FOR NETWORK CODING

FIELD OF TECHNOLOGY

The following relates to wireless communications, including polling and status reporting for network coding.

BACKGROUND

Wireless communications systems are widely deployed to provide various types of communication content such as voice, video, packet data, messaging, broadcast, and so on. These systems may be capable of supporting communication with multiple users by sharing the available system resources (e.g., time, frequency, and power) . Examples of such multiple-access systems include fourth generation (4G) systems such as Long Term Evolution (LTE) systems, LTE-Advanced (LTE-A) systems, or LTE-A Pro systems, and fifth generation (5G) systems which may be referred to as New Radio (NR) systems. These systems may employ technologies such as code division multiple access (CDMA) , time division multiple access (TDMA) , frequency division multiple access (FDMA) , orthogonal frequency division multiple access (OFDMA) , or discrete Fourier transform spread orthogonal frequency division multiplexing (DFT-S-OFDM) . A wireless multiple-access communications system may include one or more base stations or one or more network access nodes, each simultaneously supporting communication for multiple communication devices, which may be otherwise known as user equipment (UE) .

A UE may receive packet data convergence protocol (PDCP) protocol data units (PDUs) from a base station, and the UE may assemble one or more service data units (SDUs) based on the received PDUs. Current techniques for exchanging PDCP PDUs may fail to address SDUs that are missing or have not been successfully decoded by the UE.

SUMMARY

The described techniques relate to improved methods, systems, devices, and apparatuses that support polling and status reporting for network coding. Generally, the described techniques provide for reducing latency by enabling feedback (e.g., automatic repeat request (ARQ) procedures) at a packet data convergence protocol (PDCP) layer of a device in a wireless communications system. A transmitting device (e.g., a base station) may perform PDCP polling, and a receiving device (e.g., a user equipment (UE) ) may perform PDCP status protocol data units (PDU) reporting as part of the ARQ procedures.

For example, a receiving device may receive a set of PDCP PDUs at a PDCP layer from a transmitting device. The set of PDCP PDUs may correspond to one or more PDCP service data units (SDUs) . The receiving device may generate a report indicating a status of the set of PDCP PDUs or the one or more PDCP SDUs at the PDCP layer. For instance, the status may indicate whether one or more PDCP PDUs or PDCP SDUs were successfully or unsuccessfully received by the receiving device. The receiving device may transmit the report to the transmitting device. In some cases, the receiving device may receive a PDCP PDU that includes a polling flag from the transmitting device, and the report may be generated based on the polling flag. Additionally or alternatively, the report may be generated based on the expiration of a timer at the receiving device.

A method of wireless communications at a transmitting device is described. The method may include transmitting, to one or more receiving devices, a set of PDCP PDUs corresponding to one or more PDCP SDUs, determining that a polling condition at the transmitting device has been met, setting, based on determining that the polling condition has been met, a polling flag within a subsequent PDCP PDU, transmitting the subsequent PDCP PDU to the one or more receiving devices, and monitoring for a report from a receiving device of the one or more receiving devices based on transmitting the subsequent PDCP PDU, the report indicating a status of the transmitted set of PDCP PDUs or the one or more PDCP SDUs.

An apparatus for wireless communications at a transmitting device is described. The apparatus may include a processor, memory coupled with the processor, and instructions stored in the memory. The instructions may be executable by the processor to cause the apparatus to transmit, to one or more receiving devices, a set of PDCP PDUs corresponding to one or more PDCP SDUs, determine that a polling condition at the transmitting device has been met, set, based on determining that the polling condition has been met, a polling flag within a subsequent PDCP PDU, transmit the subsequent PDCP PDU to the one or more receiving devices, and monitor for a report from a receiving device of the one or more receiving devices based on transmitting the subsequent PDCP PDU, the report indicating a status of the transmitted set of PDCP PDUs or the one or more PDCP SDUs.

Another apparatus for wireless communications at a transmitting device is described. The apparatus may include means for transmitting, to one or more receiving devices, a set of PDCP PDUs corresponding to one or more PDCP SDUs, determining that a polling condition at the transmitting device has been met, setting, based on determining that the polling condition has been met, a polling flag within a subsequent PDCP PDU, transmitting the subsequent PDCP PDU to the one or more receiving devices, and monitoring for a report from a receiving device of the one or more receiving devices based on transmitting the subsequent PDCP PDU, the report indicating a status of the transmitted set of PDCP PDUs or the one or more PDCP SDUs.

A non-transitory computer-readable medium storing code for wireless communications at a transmitting device is described. The code may include instructions executable by a processor to transmit, to one or more receiving devices, a set of PDCP PDUs corresponding to one or more PDCP SDUs, determine that a polling condition at the transmitting device has been met, set, based on determining that the polling condition has been met, a polling flag within a subsequent PDCP PDU, transmit the subsequent PDCP PDU to the one or more receiving devices, and monitor for a report from a receiving device of the one or more receiving devices based on transmitting the subsequent PDCP PDU, the report indicating a status of the transmitted set of PDCP PDUs or the one or more PDCP SDUs.

In some examples of the method, apparatuses, and non-transitory computer-readable medium described herein, determining that the polling condition may have been met may include operations, features, means, or instructions for determining that a quantity of PDCP PDUs included in the set of PDCP PDUs satisfies a threshold.

Some examples of the method, apparatuses, and non-transitory computer-readable medium described herein may further include operations, features, means, or instructions for receiving an indication of the threshold via radio resource control signaling.

In some examples of the method, apparatuses, and non-transitory computer-readable medium described herein, determining that the polling condition may have been met may include operations, features, means, or instructions for determining that a quantity of data included in the set of PDCP PDUs satisfies a threshold.

Some examples of the method, apparatuses, and non-transitory computer-readable medium described herein may further include operations, features, means, or instructions for initiating a timer based on transmitting a prior PDCP PDU that includes a prior polling flag, where determining that the polling condition may have been met includes identifying an expiration of the timer.

Some examples of the method, apparatuses, and non-transitory computer-readable medium described herein may further include operations, features, means, or instructions for receiving an indication to enable or disable the timer via radio resource control signaling, and enabling or disabling the timer based on the indication.

In some examples of the method, apparatuses, and non-transitory computer-readable medium described herein, the indication may be an indication to disable the timer, and where the indication to disable the timer includes an indication of an infinite duration for the timer.

Some examples of the method, apparatuses, and non-transitory computer-readable medium described herein may further include operations, features, means, or instructions for receiving an indication of a duration for the timer via radio resource control signaling, and configuring the duration for the timer based on the indication.

Some examples of the method, apparatuses, and non-transitory computer-readable medium described herein may further include operations, features, means, or instructions for receiving the report based on the monitoring, where the report includes an indication of a quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain a PDCP SDU, and adjusting a code rate for encoding PDCP SDUs at the PDCP layer based on the indicated quantity of PDCP PDUs or PDCP sub-PDUs.

In some examples of the method, apparatuses, and non-transitory computer-readable medium described herein, the report further includes a bitmap indicating, for each PDCP SDU of the one or more PDCP SDUs having a sequence number greater than the indicated sequence number, whether the receiving device was successful or unsuccessful in obtaining a respective PDCP SDU.

Some examples of the method, apparatuses, and non-transitory computer-readable medium described herein may further include operations, features, means, or instructions for receiving the report based on the monitoring, where the report includes an indication of an average quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain each PDCP SDU of a set of PDCP SDUs, and adjusting a code rate for encoding PDCP SDUs at the PDCP layer based on the indicated average quantity of PDCP PDUs or PDCP sub-PDUs.

Some examples of the method, apparatuses, and non-transitory computer-readable medium described herein may further include operations, features, means, or instructions for receiving the report based on the monitoring, where the report includes an indication of a sequence number for a PDCP SDU of the one or more PDCP SDUs, the indication of the sequence number indicating that the receiving device was able to obtain each of the one or more PDCP SDUs having a sequence number lower than the indicated sequence number.

In some examples of the method, apparatuses, and non-transitory computer-readable medium described herein, a header of the subsequent PDCP PDU includes the polling flag.

Some examples of the method, apparatuses, and non-transitory computer-readable medium described herein may further include operations, features, means, or instructions for receiving the report based on the monitoring, where the report includes an indication of a report type for the report, the indicated report type one of a set of report types, and decoding the report based on least in part on the indication of the report type for the report.

In some examples of the method, apparatuses, and non-transitory computer-readable medium described herein, the report type may be a first report type of the set of report types, the report including an indication of a sequence number for a PDCP SDU of the one or more PDCP SDUs, the indication of the sequence number indicating that the receiving device was able to obtain each of the one or more PDCP SDUs having a sequence number lower than the indicated sequence number, the report type may be a second report type of the set of report types, the report including the indication of the sequence number for the PDCP SDU of the one or more PDCP SDUs, and the report further including at least one of an indication of a quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain a PDCP SDU or an indication of an average quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain each PDCP SDU of a set of PDCP SDUs; or, and the report type may be a third report type of the set of report types, the report including the indication of the sequence number for the PDCP SDU of the one or more PDCP SDUs, the report further including at least one of the indication of a quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain a PDCP SDU or the indication of the average quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain each PDCP SDU of the set of PDCP SDUs, and the report further including a bitmap indicating, for each PDCP SDU of the one or more PDCP SDUs having a sequence number greater than the indicated sequence number, whether the receiving device was successful or unsuccessful in obtaining a respective PDCP SDU.

A method of wireless communications at a receiving device is described. The method may include receiving, at a packet data convergence protocol (PDCP) layer of the receiving device, a set of PDCP PDUs from a transmitting device, the set of PDPC PDUs corresponding to one or more PDCP SDUs, generating, at a PDCP layer, a report indicating a status of the set of PDCP PDUs or the one or more PDCP SDUs at the receiving device, and transmitting the report to the transmitting device.

An apparatus for wireless communications at a receiving device is described. The apparatus may include a processor, memory coupled with the processor, and instructions stored in the memory. The instructions may be executable by the processor to cause the apparatus to receive, at a packet data convergence protocol (PDCP) layer of the receiving device, a set of PDCP PDUs from a transmitting device, the set of PDPC PDUs corresponding to one or more PDCP SDUs, generate, at a PDCP layer, a report indicating a status of the set of PDCP PDUs or the one or more PDCP SDUs at the receiving device, and transmit the report to the transmitting device.

Another apparatus for wireless communications at a receiving device is described. The apparatus may include means for receiving, at a packet data convergence protocol (PDCP) layer of the receiving device, a set of PDCP PDUs from a transmitting device, the set of PDPC PDUs corresponding to one or more PDCP SDUs, generating, at a PDCP layer, a report indicating a status of the set of PDCP PDUs or the one or more PDCP SDUs at the receiving device, and transmitting the report to the transmitting device.

A non-transitory computer-readable medium storing code for wireless communications at a receiving device is described. The code may include instructions executable by a processor to receive, at a packet data convergence protocol (PDCP) layer of the receiving device, a set of PDCP PDUs from a transmitting device, the set of PDPC PDUs corresponding to one or more PDCP SDUs, generate, at a PDCP layer, a report indicating a status of the set of PDCP PDUs or the one or more PDCP SDUs at the receiving device, and transmit the report to the transmitting device.

Some examples of the method, apparatuses, and non-transitory computer-readable medium described herein may further include operations, features, means, or instructions for receiving, from the transmitting device after receiving the set of PDCP PDUs, a subsequent PDCP PDU that includes a polling flag, where generating the report may be based on the polling flag.

Some examples of the method, apparatuses, and non-transitory computer-readable medium described herein may further include operations, features, means, or instructions for initiating a timer at the receiving device, where generating the report may be based on an expiration of the timer.

Some examples of the method, apparatuses, and non-transitory computer-readable medium described herein may further include operations, features, means, or instructions for receiving a PDCP PDU of the set of PDCP PDUs at an empty buffer of the receiving device, where initiating the timer may be based on receiving the PDU at the empty buffer.

Some examples of the method, apparatuses, and non-transitory computer-readable medium described herein may further include operations, features, means, or instructions for transmitting, to the transmitting device before transmitting the report, a prior report indicating a status of a prior set of PDCP PDUs, where initiating the timer may be based on transmitting the prior report.

Some examples of the method, apparatuses, and non-transitory computer-readable medium described herein may further include operations, features, means, or instructions for receiving, via radio resource control signaling, an indication of a report type for the receiving device to use to indicate a status of PDCP PDUs at the receiving device, the indicated report type one of a set of report types, where the report may be of the indicated report type.

In some examples of the method, apparatuses, and non-transitory computer-readable medium described herein, the report indicates the report type to the transmitting device.

In some examples of the method, apparatuses, and non-transitory computer-readable medium described herein, the report type may be a first report type of the set of report types, the report including a sequence number of the PDCP SDU based on the PDCP SDU having a lowest sequence number among a subset of one or more PDCP SDU that the receiving device may be unable to obtain among the one or more PDCP SDUs, the report type may be a second report type of the set of report types, the report including the sequence number of the PDCP SDU, and the report further including at least one of an indication of a quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain a PDCP SDU or an indication of an average quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain each PDCP SDU of a set of PDCP SDUs; or, and the report type may be a third report type of the set of report types, the report including the indication of the sequence number for the PDCP SDU of the one or more PDCP SDUs, the report further including at least one of the indication of the quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain the PDCP SDU or the indication of the average quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain each PDCP SDU of the set of PDCP SDUs, and the report further including a bitmap indicating, for each PDCP SDU among the one or more PDCP SDUs having a sequence number greater than the sequence number of the PDCP SDU, whether the receiving device was successful or unsuccessful in receiving a respective PDCP SDU.

In some examples of the method, apparatuses, and non-transitory computer-readable medium described herein, the receiving device may be unable to obtain a PDCP SDU of the one or more PDCP SDUs, and the report includes a sequence number of the PDCP SDU based on the PDCP SDU having a lowest sequence number among a subset of one or more PDCP SDU that the receiving device may be unable to obtain among the one or more PDCP SDUs.

In some examples of the method, apparatuses, and non-transitory computer-readable medium described herein, the report further includes a bitmap indicating, for each PDCP SDU among the one or more PDCP SDUs having a sequence number greater than the sequence number of the PDCP SDU, whether the receiving device was successful or unsuccessful in obtaining a respective PDCP SDU.

In some examples of the method, apparatuses, and non-transitory computer-readable medium described herein, the report includes an indication of a quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain a PDCP SDU.

In some examples of the method, apparatuses, and non-transitory computer-readable medium described herein, the report includes an indication of an average quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain each PDCP SDU of a set of PDCP SDUs.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example of a wireless communications system that supports polling and status reporting for network coding in accordance with aspects of the present disclosure.

FIG. 2 illustrates an example of a wireless communications system that supports polling and status reporting for network coding in accordance with aspects of the present disclosure.

FIG. 3 illustrates an example of a PDCP configuration that supports polling and status reporting for network coding in accordance with aspects of the present disclosure.

FIG. 4 illustrates an example of a PDCP configuration that supports polling and status reporting for network coding in accordance with aspects of the present disclosure.

FIGs. 5A and 5B illustrate examples of PDCP polling messages that supports polling and status reporting for network coding in accordance with aspects of the present disclosure.

FIGs. 6A and 6B illustrate examples of PDCP status messages that supports polling and status reporting for network coding in accordance with aspects of the present disclosure.

FIG. 7 illustrates an example of a process flow that supports polling and status reporting for network coding in accordance with aspects of the present disclosure.

FIGs. 8 and 9 show block diagrams of devices that support polling and status reporting for network coding in accordance with aspects of the present disclosure.

FIG. 10 shows a block diagram of a communications manager that supports polling and status reporting for network coding in accordance with aspects of the present disclosure.

FIG. 11 shows a diagram of a system including a user equipment (UE) that supports polling and status reporting for network coding in accordance with aspects of the present disclosure.

FIG. 12 shows a diagram of a system including a base station that supports polling and status reporting for network coding in accordance with aspects of the present disclosure.

FIGs. 13 through 19 show flowcharts illustrating methods that support polling and status reporting for network coding in accordance with aspects of the present disclosure.

DETAILED DESCRIPTION

Wireless communication systems may utilize fountain codes, which are rateless codes in the sense that the number of coded packets may be limitless. For example, the transmitted packets may be recovered at the receiver side so long as the number of received packets is sufficiently large (e.g., slightly larger than the number of source packets) , regardless of which particular packets are received and successfully decoded. Examples of such rateless codes include Luby transform (LT) codes, Raptor codes (an enhanced code based on variations of low-density parity check (LDPC) and LT codes) , and the like. Fountain codes may also be referred to as network codes because in some cases they may be applied to the network/application layer (e.g., for multimedia broadcast multi-cast service (MBMS) , integrated access and backhaul (IAB) , vehicle-to-everything (V2X) , and the like) . At the receiving side, each coded symbol would either be decoded correctly or discarded. A transmitting device (e.g., a base station) may transmit (e.g., unicast, broadcast, multicast) a set of messages (e.g., packet data convergence protocol (PDCP) protocol data units (PDUs) ) to a user equipment (UE) or group of UEs, and one or more UEs of the group of UEs may assemble a service data unit (SDU) based on the set of messages. However, the UE may fail to assemble one or more SDUs, which may result in lost packets, increased system latency, or other issues.

Various aspects of the present disclosure provide communication techniques for a transmitting and receiving devices. For example, a transmitting device may transmit a set of PDCP PDUs to a group of receiving devices, and the set of PDCP PDUs may correspond to one or more PDCP SDUs. A receiving device of the group of receiving devices may receive set of PDCP PDUs and attempt to generate or assemble a corresponding PDCP SDU, but the receiving device may not successfully generate the corresponding SDU. In some cases, the receiving device may not receive one or more PDCP PDUs of the set of PDCP PDUs, while in some other cases, the receiving device may not properly decode one or more PDCP PDUs of the set of PDCP PDUs, which may prevent the receiving device from generating and obtaining a corresponding SDU. The receiving device may generate a report (e.g., a PDCP status PDU) to indicate the status of the set of PDCP PDUs or one or more PDCP SDUs to the transmitting device. In some cases, the transmitting device may alter a coding rate based on the report, which may improve communication reliability and decrease system latency.

Such techniques may involve a transmitting device determining that a polling condition has been met. In such cases, the transmitting device may set a polling flag within a subsequent PDCP PDU based on determining that the polling condition has been met, and the transmitting device may transmit the subsequent PDCP PDU to the group of UEs. The polling condition may be based on a timer, a number of transmitted PDCP PDUs, a number of bytes corresponding to transmitted PDCP PDUs, or any combination thereof. The transmitting device may monitor for one or more reports from the group of UEs. In some cases, the report may be generated by a receiving device based on a prohibit timer or a PDCP PDU indicating a polling flag. Generating a report based on a timer or a polling flag may support automatic repeat request (ARQ) procedures at the PDCP layer, which may improve communication reliability and decrease system latency.

Aspects of the disclosure are initially described in the context of wireless communications systems. Aspects of the disclosure are further described in the context of PDCP configurations, PDCP polling messages, and PDCP status messages. Aspects of the disclosure are further illustrated by and described with reference to apparatus diagrams, system diagrams, and flowcharts that relate to polling and status reporting for network coding.

FIG. 1 illustrates an example of a wireless communications system 100 that supports polling and status reporting for network coding in accordance with aspects of the present disclosure. The wireless communications 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 communications system 100 may be a Long Term Evolution (LTE) network, an LTE-Advanced (LTE-A) network, an LTE-A Pro network, or a New Radio (NR) network. In some examples, the wireless communications system 100 may support enhanced broadband communications, ultra-reliable (e.g., mission critical) communications, low latency communications, communications with low-cost and low-complexity devices, or any combination thereof.

The base stations 105 may be dispersed throughout a geographic area to form the wireless communications system 100 and may be devices in different forms or having different capabilities. The base stations 105 and the UEs 115 may wirelessly communicate via one or more communication links 125. Each base station 105 may provide a coverage area 110 over which the UEs 115 and the base station 105 may establish one or more communication links 125. The coverage area 110 may be an example of a geographic area over which a base station 105 and a UE 115 may support the communication of signals according to one or more radio access technologies.

The UEs 115 may be dispersed throughout a coverage area 110 of the wireless communications system 100, and each UE 115 may be stationary, or mobile, or both at different times. The UEs 115 may be devices in different forms or having different capabilities. Some example UEs 115 are illustrated in FIG. 1. The UEs 115 described herein may be able to communicate with various types of devices, such as other UEs 115, the base stations 105, or network equipment (e.g., core network nodes, relay devices, integrated access and backhaul (IAB) nodes, or other network equipment) , as shown in FIG. 1.

The base stations 105 may communicate with the core network 130, or with one another, or both. For example, the base stations 105 may interface with the core network 130 through one or more backhaul links 120 (e.g., via an S1, N2, N3, or other interface) . The base stations 105 may communicate with one another over the backhaul links 120 (e.g., via an X2, Xn, or other interface) either directly (e.g., directly between base stations 105) , or indirectly (e.g., via core network 130) , or both. In some examples, the backhaul links 120 may be or include one or more wireless links.

One or more of the base stations 105 described herein may include or may be referred to by a person having ordinary skill in the art as a base transceiver station, a radio base station, an access point, a radio transceiver, a NodeB, an eNodeB (eNB) , a next-generation NodeB or a giga-NodeB (either of which may be referred to as a gNB) , a Home NodeB, a Home eNodeB, or other suitable terminology.

A UE 115 may include or may be referred to as a mobile device, a wireless device, a remote device, a handheld device, or a subscriber device, or some other suitable terminology, where the “device” may also be referred to as a unit, a station, a terminal, or a client, among other examples. A UE 115 may also include or may be referred to as a personal electronic device such as a cellular phone, a personal digital assistant (PDA) , a tablet computer, a laptop computer, or a personal computer. In some examples, a UE 115 may include or be referred to as a wireless local loop (WLL) station, an Internet of Things (IoT) device, an Internet of Everything (IoE) device, or a machine type communications (MTC) device, among other examples, which may be implemented in various objects such as appliances, or vehicles, meters, among other examples.

The UEs 115 described herein may be able to communicate with various types of devices, such as other UEs 115 that may sometimes act as relays as well as the base stations 105 and the network equipment including macro eNBs or gNBs, small cell eNBs or gNBs, or relay base stations, among other examples, as shown in FIG. 1.

The UEs 115 and the base stations 105 may wirelessly communicate with one another via one or more communication links 125 over one or more carriers. The term “carrier” may refer to a set of radio frequency spectrum resources having a defined physical layer structure for supporting the communication links 125. For example, a carrier used for a communication link 125 may include a portion of a radio frequency spectrum band (e.g., a bandwidth part (BWP) ) that is operated according to one or more physical layer channels for a given radio access technology (e.g., LTE, LTE-A, LTE-A Pro, NR) . Each physical layer channel may carry acquisition signaling (e.g., synchronization signals, system information) , control signaling that coordinates operation for the carrier, user data, or other signaling. The wireless communications system 100 may support communication with a UE 115 using carrier aggregation or multi-carrier operation. A UE 115 may be configured with multiple downlink component carriers and one or more uplink component carriers according to a carrier aggregation configuration. Carrier aggregation may be used with both frequency division duplexing (FDD) and time division duplexing (TDD) component carriers.

In some examples (e.g., in a carrier aggregation configuration) , a carrier may also have acquisition signaling or control signaling that coordinates operations for other carriers. A carrier may be associated with a frequency channel (e.g., an evolved universal mobile telecommunication system terrestrial radio access (E-UTRA) absolute radio frequency channel number (EARFCN) ) and may be positioned according to a channel raster for discovery by the UEs 115. A carrier may be operated in a standalone mode where initial acquisition and connection may be conducted by the UEs 115 via the carrier, or the carrier may be operated in a non-standalone mode where a connection is anchored using a different carrier (e.g., of the same or a different radio access technology) .

The communication links 125 shown in the wireless communications system 100 may include uplink transmissions from a UE 115 to a base station 105, or downlink transmissions from a base station 105 to a UE 115. Carriers may carry downlink or uplink communications (e.g., in an FDD mode) or may be configured to carry downlink and uplink communications (e.g., in a TDD mode) .

A carrier may be associated with a particular bandwidth of the radio frequency spectrum, and in some examples the carrier bandwidth may be referred to as a “system bandwidth” of the carrier or the wireless communications system 100. For example, the carrier bandwidth may be one of a number of determined bandwidths for carriers of a particular radio access technology (e.g., 1.4, 3, 5, 10, 15, 20, 40, or 80 megahertz (MHz) ) . Devices of the wireless communications system 100 (e.g., the base stations 105, the UEs 115, or both) may have hardware configurations that support communications over a particular carrier bandwidth or may be configurable to support communications over one of a set of carrier bandwidths. In some examples, the wireless communications system 100 may include base stations 105 or UEs 115 that support simultaneous communications via carriers associated with multiple carrier bandwidths. In some examples, each served UE 115 may be configured for operating over portions (e.g., a sub-band, a BWP) or all of a carrier bandwidth.

Signal waveforms transmitted over a carrier may be made up of multiple subcarriers (e.g., using multi-carrier modulation (MCM) techniques such as orthogonal frequency division multiplexing (OFDM) or discrete Fourier transform spread OFDM (DFT-S-OFDM) ) . In a system employing MCM techniques, a resource element may consist of one symbol period (e.g., a duration of one modulation symbol) and one subcarrier, where the symbol period and subcarrier spacing are inversely related. The number of bits carried by each resource element may depend on the modulation scheme (e.g., the order of the modulation scheme, the coding rate of the modulation scheme, or both) . Thus, the more resource elements that a UE 115 receives and the higher the order of the modulation scheme, the higher the data rate may be for the UE 115. A wireless communications resource may refer to a combination of a radio frequency spectrum resource, a time resource, and a spatial resource (e.g., spatial layers or beams) , and the use of multiple spatial layers may further increase the data rate or data integrity for communications with a UE 115.

One or more numerologies for a carrier may be supported, where a numerology may include a subcarrier spacing (Δf) and a cyclic prefix. A carrier may be divided into one or more BWPs having the same or different numerologies. In some examples, a UE 115 may be configured with multiple BWPs. In some examples, a single BWP for a carrier may be active at a given time and communications for the UE 115 may be restricted to one or more active BWPs.

The time intervals for the base stations 105 or the UEs 115 may be expressed in multiples of a basic time unit which may, for example, refer to a sampling period of T _s= 1/ (Δf _max·N _f) seconds, where Δf _max may represent the maximum supported subcarrier spacing, and N _f may represent the maximum supported discrete Fourier transform (DFT) size. Time intervals of a communications resource may be organized according to radio frames each having a specified duration (e.g., 10 milliseconds (ms) ) . Each radio frame may be identified by a system frame number (SFN) (e.g., ranging from 0 to 1023) .

Each frame may include multiple consecutively numbered subframes or slots, and each subframe or 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 a number of slots. Alternatively, each frame may include a variable number of slots, and the number of slots may depend on subcarrier spacing. Each slot may include a number of symbol periods (e.g., depending on the length of the cyclic prefix prepended to each symbol period) . In some wireless communications systems 100, a slot may further be divided into multiple mini-slots containing one or more symbols. Excluding the cyclic prefix, each symbol period may contain one or more (e.g., N _f) sampling periods. The duration of a symbol period may depend on the subcarrier spacing or frequency band of operation.

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

Physical channels may be multiplexed on a carrier according to various techniques. A physical control channel and a physical data channel may be multiplexed on a downlink carrier, for example, using one or more of time division multiplexing (TDM) techniques, frequency division multiplexing (FDM) techniques, or hybrid TDM-FDM techniques. A control region (e.g., a control resource set (CORESET) ) for a physical control channel may be defined by a number of symbol periods and may extend across the system bandwidth or a subset of the system bandwidth of the carrier. One or more control regions (e.g., CORESETs) may be configured for a set of the UEs 115. For example, one or more of the UEs 115 may monitor or search control regions for control information according to one or more search space sets, and each search space set may include one or multiple control channel candidates in one or more aggregation levels arranged in a cascaded manner. An aggregation level for a control channel candidate may refer to a number of control channel resources (e.g., control channel elements (CCEs) ) associated with encoded information for a control information format having a given payload size. Search space sets may include common search space sets configured for sending control information to multiple UEs 115 and UE-specific search space sets for sending control information to a specific UE 115.

Each base station 105 may provide communication coverage via one or more cells, for example a macro cell, a small cell, a hot spot, or other types of cells, or any combination thereof. The term “cell” may refer to a logical communication entity used for communication with a base station 105 (e.g., over a carrier) and may be associated with an identifier for distinguishing neighboring cells (e.g., a physical cell identifier (PCID) , a virtual cell identifier (VCID) , or others) . In some examples, a cell may also refer to a geographic coverage area 110 or a portion of a geographic coverage area 110 (e.g., a sector) over which the logical communication entity operates. Such cells may range from smaller areas (e.g., a structure, a subset of structure) to larger areas depending on various factors such as the capabilities of the base station 105. For example, a cell may be or include a building, a subset of a building, or exterior spaces between or overlapping with geographic coverage areas 110, among other examples.

A macro cell generally covers a relatively large geographic area (e.g., several kilometers in radius) and may allow unrestricted access by the UEs 115 with service subscriptions with the network provider supporting the macro cell. A small cell may be associated with a lower-powered base station 105, as compared with a macro cell, and a small cell may operate in the same or different (e.g., licensed, unlicensed) frequency bands as macro cells. Small cells may provide unrestricted access to the UEs 115 with service subscriptions with the network provider or may provide restricted access to the UEs 115 having an association with the small cell (e.g., the UEs 115 in a closed subscriber group (CSG) , the UEs 115 associated with users in a home or office) . A base station 105 may support one or multiple cells and may also support communications over the one or more cells using one or multiple component carriers.

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

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

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

Some UEs 115, such as MTC or IoT devices, may be low cost or low complexity devices and may provide for automated communication between machines (e.g., via Machine-to-Machine (M2M) communication) . M2M communication or MTC may refer to data communication technologies that allow devices to communicate with one another or a base station 105 without human intervention. In some examples, M2M communication or MTC may include communications from devices that integrate sensors or meters to measure or capture information and relay such information to a central server or application program that makes use of the information or presents the information to humans interacting with the application program. Some UEs 115 may be designed to collect information or enable automated behavior of machines or other devices. Examples of applications for MTC devices include smart metering, inventory monitoring, water level monitoring, equipment monitoring, healthcare monitoring, wildlife monitoring, weather and geological event monitoring, fleet management and tracking, remote security sensing, physical access control, and transaction-based business charging.

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

The wireless communications system 100 may be configured to support ultra-reliable communications or low-latency communications, or various combinations thereof. For example, the wireless communications system 100 may be configured to support ultra-reliable low-latency communications (URLLC) or mission critical communications. The UEs 115 may be designed to support ultra-reliable, low-latency, or critical functions (e.g., mission critical functions) . Ultra-reliable communications may include private 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 prioritization of services, and mission critical services may be used for public safety or general commercial applications. The terms ultra-reliable, low-latency, mission critical, and ultra-reliable low-latency may be used interchangeably herein.

In some examples, a UE 115 may also be able to communicate directly with other UEs 115 over a device-to-device (D2D) communication link 135 (e.g., using a peer-to-peer (P2P) or D2D protocol) . One or more UEs 115 utilizing D2D communications may be within the geographic coverage area 110 of a base station 105. Other UEs 115 in such a group may be outside the geographic coverage area 110 of a base station 105 or be otherwise unable to receive transmissions from a base station 105. In some examples, groups of the UEs 115 communicating via D2D communications may utilize a one-to-many (1: M) system in which each UE 115 transmits to every other UE 115 in the group. In some examples, a base station 105 facilitates the scheduling of resources for D2D communications. In other cases, D2D communications are carried out between the UEs 115 without the involvement of a base station 105.

In some systems, the D2D communication link 135 may be an example of a communication channel, such as a sidelink communication channel, between vehicles (e.g., UEs 115) . In some examples, vehicles may communicate using vehicle-to-everything (V2X) communications, vehicle-to-vehicle (V2V) communications, or some combination of these. A vehicle may signal information related to traffic conditions, signal scheduling, weather, safety, emergencies, or any other information relevant to a V2X system. In some examples, vehicles in a V2X system may communicate with roadside infrastructure, such as roadside units, or with the network via one or more network nodes (e.g., base stations 105) using vehicle-to-network (V2N) communications, or with both.

The core network 130 may provide user authentication, access authorization, tracking, Internet Protocol (IP) connectivity, and other access, routing, or mobility functions. The core network 130 may be an evolved packet core (EPC) or 5G core (5GC) , which may include at least one control plane entity that manages access and mobility (e.g., a mobility management entity (MME) , an access and mobility management function (AMF) ) and at least one user plane entity that routes packets or interconnects to external networks (e.g., a serving gateway (S-GW) , a Packet Data Network (PDN) gateway (P-GW) , or a user plane function (UPF) ) . The control plane entity may manage non-access stratum (NAS) functions such as mobility, authentication, and bearer management for the UEs 115 served by the base stations 105 associated with the core network 130. User IP packets may be transferred through the user plane entity, which may provide IP address allocation as well as other functions. The user plane entity may be connected to the network operators IP services 150. The network operators IP services 150 may include access to the Internet, Intranet (s) , an IP Multimedia Subsystem (IMS) , or a Packet-Switched Streaming Service.

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

The wireless communications system 100 may operate using one or more frequency bands, typically in the range of 300 megahertz (MHz) to 300 gigahertz (GHz) . Generally, the region from 300 MHz to 3 GHz is known as the ultra-high frequency (UHF) region or decimeter band because the wavelengths range from approximately one decimeter to one meter in length. The UHF waves may be blocked or redirected by buildings and environmental features, but the waves may penetrate structures sufficiently for a macro cell to provide service to the UEs 115 located indoors. The transmission of UHF waves may be associated with smaller antennas and shorter ranges (e.g., less than 100 kilometers) compared to transmission using the smaller frequencies and longer waves of the high frequency (HF) or very high frequency (VHF) portion of the spectrum below 300 MHz.

The wireless communications system 100 may also operate in a super high frequency (SHF) region using frequency bands from 3 GHz to 30 GHz, also known as the centimeter band, or in an 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 communications system 100 may support millimeter wave (mmW) communications between the UEs 115 and the base stations 105, and EHF antennas of the respective devices may be smaller and more closely spaced than UHF antennas. In some examples, this may facilitate use of antenna arrays within a device. The propagation of EHF transmissions, however, may be subject to even greater atmospheric attenuation and shorter range than SHF or UHF transmissions. The techniques disclosed herein may be employed across transmissions that use one or more different frequency regions, and designated use of bands across these frequency regions may differ by country or regulating body.

The wireless communications system 100 may utilize both licensed and unlicensed radio frequency spectrum bands. For example, the wireless communications system 100 may employ License Assisted Access (LAA) , LTE-Unlicensed (LTE-U) radio access technology, or NR technology in an unlicensed band such as the 5 GHz industrial, scientific, and medical (ISM) band. When operating in unlicensed radio frequency spectrum bands, devices such as the base stations 105 and the UEs 115 may employ carrier sensing for collision detection and avoidance. In some examples, operations in unlicensed bands may be based on a carrier aggregation configuration in conjunction with component carriers operating in a licensed band (e.g., LAA) . Operations in unlicensed spectrum may include downlink transmissions, uplink transmissions, P2P transmissions, or D2D transmissions, among other examples.

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

The base stations 105 or the UEs 115 may use MIMO communications to exploit multipath signal propagation and increase the spectral efficiency by transmitting or receiving multiple signals via different spatial layers. Such techniques may be referred to as spatial multiplexing. The multiple signals may, for example, be transmitted by the transmitting device via different antennas or different combinations of antennas. Likewise, the multiple signals may be received by the receiving device via different antennas or different combinations of antennas. Each of the multiple signals may be referred to as a separate spatial stream and may carry bits associated with the same data stream (e.g., the same codeword) or different data streams (e.g., different codewords) . Different spatial layers may be associated with different antenna ports used for channel measurement and reporting. MIMO techniques include single-user MIMO (SU-MIMO) , where multiple spatial layers are transmitted to the same receiving device, and multiple-user MIMO (MU-MIMO) , where multiple spatial layers are transmitted to multiple devices.

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

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

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

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

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

The wireless communications system 100 may be a packet-based network that operates according to a layered protocol stack. In the user plane, communications at the bearer or PDCP layer may be IP-based. A Radio Link Control (RLC) layer may perform packet segmentation and reassembly to communicate over logical channels. A Medium Access Control (MAC) layer may perform priority handling and multiplexing of logical channels into transport channels. The MAC layer may also use error detection techniques, error correction techniques, or both to support retransmissions at the MAC layer to improve link efficiency. In the control plane, the Radio Resource Control (RRC) protocol layer may provide establishment, configuration, and maintenance of an RRC connection between a UE 115 and a base station 105 or a core network 130 supporting radio bearers for user plane data. At the physical layer, transport channels may be mapped to physical channels.

The UEs 115 and the base stations 105 may support retransmissions of data to increase the likelihood that data is received successfully. Hybrid ARQ (HARQ) feedback is one technique for increasing the likelihood that data is received correctly over a communication link 125. HARQ may include a combination of error detection (e.g., using a cyclic redundancy check (CRC) ) , forward error correction (FEC) , and retransmission (e.g., ARQ) . HARQ may improve throughput at the MAC layer in poor radio conditions (e.g., low signal-to-noise conditions) . In some examples, a device may support same-slot HARQ feedback, where the device may provide HARQ feedback in a specific slot for data received in a previous symbol in the slot. In other cases, the device may provide HARQ feedback in a subsequent slot, or according to some other time interval.

For example, a receiving device (e.g., a UE 115) may receive a set of PDCP PDUs at a PDCP layer from a transmitting device (e.g., a base station 105) . In some cases, the transmitting device may correspond to a UE 115. For example, a UE 115 may support broadcasted transmissions, relayed transmissions, or the like, which may facilitate a UE 115 acting as a transmitting device. The set of PDCP PDUs may correspond to one or more PDCP SDUs. The receiving device may generate a report indicating a status of the set of PDCP PDUs or the one or more PDCP SDUs at the PDCP layer. The receiving device may transmit the report to the transmitting device. The receiving device may receive a subsequent PDCP PDU that includes a polling flag from the transmitting device, and the report may be generated based on the polling flag. The report may be additionally or alternatively be generated based on the expiration of a timer at the receiving device.

FIG. 2 illustrates an example of a wireless communications system 200 that supports polling and status reporting for network coding in accordance with aspects of the present disclosure. In some examples, wireless communications system 200 may implement aspects of wireless communications system 100. Wireless communications system 200 may include base station 105-a, which may be an example of a base station 105 as described with reference to FIG. 1. Base station 105-a may be associated with coverage area 110-a. Wireless communications system 200 may include a group of UEs 215, which may include a number of UEs 115.

Base station 105-a may transmit or broadcast a number of PDCP PDUs 205 to the group of UEs 215. For example, base station 105-a may transmit a set of PDCP PDUs that includes PDCP PDU 205-a and PDCP PDU 205-b, and the set of PDCP PDUs may correspond to one or more PDCP SDUs. The set of PDCP PDUs may additionally include subsequent PDCP PDU 205-c. Base station 105-a may determine that a polling condition has been met and set a polling flag in subsequent PDCP PDU 205-c. The polling flag may correspond to a polling field in the header of subsequent PDCP PDU 205-c that is set to a bit value (e.g., 0 or 1) to indicate the polling flag. In some cases, base station 105-a may determine that the polling condition has been met based on a timer 220-a.

In some cases, timer 220-a may be a period polling timer that is configured by an RRC procedure. For example, a first RRC parameter may indicate an enabled timer mode or a disabled timer mode, and base station 105-a may enable or disable timer 220-a based on the first RRC parameter. In some additional or alternative examples, a second RRC parameter may indicate an association of timer 220-a to a value corresponding to PDCP-Config. The value may indicate an infinite value, which may indicate a disabled mode of timer 220-a. Base station 105-a may insert a polling bit into subsequent PDCP PDU 205-c based on the expiration of timer 220-a.

In some cases, base station 105-a may determine that the polling condition has been met based on transmitted PDCP PDUs 205. For example, base station 105-a may be configured with a first PDCP PDU threshold corresponding to a number of transmitted PDCP PDUs 205. Subsequent PDCP PDU 205-c may include a polling bit in the header when the number of transmitted PDCP PDUs satisfies (e.g., meets or exceeds) the threshold. As a non-limiting example, base station 105-a may be configured with a first threshold of “2” , transmit PDCP PDU 205-a and PDCP PDU 205-c, and insert a polling bit into PDCP PDU 205-c based on the number of transmitted PDCP PDUs 205 satisfying the first threshold. In some additional or alternative examples, base station 105-a may be configured with a second PDCP PDU threshold corresponding to a number of bytes associated with transmitted PDCP PDUs 205, and base station 105-a may insert a polling bit into subsequent PDCP PDU 205-c based on the number of bytes associated with transmitted PDCP PDUs 205 satisfying the threshold.

Base station 105-a may monitor the group of UEs 215 for a report 210 (e.g., a PDCP status PDU) based on transmitting the subsequent PDCP PDU 205-c. The report 210 may indicate a status of the transmitted set of PDCP PDUs 205 or the corresponding one or more PDCP SDUs. UE 115-a may generate the report 210 based on a polling condition for met. In some cases, UE 115-a may generate and transmit the report 210 based on the expiration of timer 220-b (e.g., a prohibit timer) . Timer 220-b may be configured as part of an RRC procedure. In some examples, as part of the RRC procedure, the timer 220-b may be configured with a duration, enabled, or disabled. Timer 220-b may be started or restarted based on receiving a PDCP PDU 205 at an empty PDCP buffer or transmitting a report 210 (e.g., a PDCP status PDU) . In some additional or alternative cases, UE 115-a may generate and transmit the report 210 based on identifying a polling flag in PDCP PDU 205-c.

UE 115-a may receive the set of PDCP PDUs 205 from base station 105-a, and the set of PDCP PDUs may correspond to one or more SDUs. In some cases, multiple UEs 115 may receive the set of PDCP PDUs 205. One or more UEs 115 of UE group 215 may receive the set of PDCP PDUs 205 and assemble one or more corresponding PDCP SDUs. In some cases, UE 115-a may receive the set of PDCP PDUs 205 and attempt to assemble a corresponding PDCP SDU, but the PDCP SDU may not be correctly assembled based on missing PDCP PDUs or incorrectly decoded PDCP PDUs. UE 115-a may transmit the report 210 to base station 105-a, which may include an indication of a sequence number (SN) of the corresponding PDCP SDU (e.g., ACK_SN) , an indication of the number of PDCP PDUs (includes source or parity PDCP PDUs) decoded and used to assemble the corresponding PDCP SDU (e.g., NumPDU) , an indication of the number of PDCP subPDUs decided and used to assemble the corresponding PDCP SDU (e.g., NumPDU) , or an indication of missing or correctly assembled PDCP SDUs, which may provide feedback information that supports base station 105-a adjusting the code rate for PDCP PDUs, which may improve system efficiency. The report 210 may additionally include an indication of the type of report 210 (e.g., a “C” field of the report 210 may indicate a PDCP status PDU type) . Different ARQ schemes may be performed in the wireless communications system 200 based on the report 210, which may reduce system latency.

FIG. 3 illustrates an example of a PDCP configuration 300 that supports polling and status reporting for network coding in accordance with aspects of the present disclosure. In some examples, PDCP configuration 300 may implement aspects of

wireless communications systems

100 or 200. PDCP entity 300 may include a PDCP entity 305 comprising transmitting PDCP entity 310 at a transmitting device and receiving PDCP entity 315 at a receiving device. In some aspects, the transmitting device or receiving device may be examples of a UE or base station as described herein.

In some aspects, a base station may be configured or otherwise act as a transmitting device performing a wireless transmission to a UE, 115 which may be configured or otherwise acting as a receiving device in this scenario. Conversely, the UE 115 may also implement various aspects of the described techniques when configured or otherwise acting as a transmitting device performing a wireless transmission to a base station 105, which would be configured or otherwise acting as the receiving device in this scenario. In some examples, such wireless transmissions may be performed by the base station 105 to another base station 105 (e.g., in an IAB network) or by a UE 115 to another UE 115 (e.g., in a V2X, IAB, etc., network) .

Wireless devices communicating over a wireless network may form peer entities between layers within a protocol stack established at each end of the communications (e.g., at the transmitting device end and the receiving device end) . For example, a transmitting device (e.g., a UE or a base station performing a transmission to other UE (s) or base station (s) ) may implement a protocol stack that includes, starting at the bottom, a physical layer that maps transport channels to physical channels of the wireless medium, implements the 5G frame structure, beamforming, variable bandwidths, and the like. The physical layer may also be referred to as layer 1 (L1) . Above L1 within the protocol stack lies layer two (L2) , which includes a MAC layer, an RLC layer, a PDCP layer, etc. The MAC layer generally provides priority handling between logical channels, transport format selection, padding, etc. The RLC layer generally provides packet segmentation and concatenation, RLC timers, etc. Traditionally, the PDCP layer transfers user plane/control plane data, provides PDCP sequence number (SN) maintenance, ciphering/integrity protection, bearer routing, etc. Above L2 within the protocol stack lies layer three (L3) , which may include an RRC layer, IP layer, and the like. L3 within the protocol stack is also referred to as the network layer, application layer, etc.

When a transmitting device communicates with the receiving device, a logical entity is established between each layer of the transmitting device and the corresponding layer of the receiving device (e.g., a next-generation radio access network (NG-RAN) entity structure) . For example, PDCP entity 305 is established between a transmitting device (e.g., transmitting PDCP entity 310) and a receiving device (e.g., receiving PDCP entity 315) to support wireless communications. Such logical entities are also established between the MAC layers (e.g., a MAC entity) , RLC layers (e.g., an RLC entity) , etc., which are used to monitor, control, or otherwise manage the aspects of the wireless communication functions being performed at the particular layer. Traditionally, a payload of data for transmission to the receiving device (s) from an upper layer (e.g., L3) is processed at the upper layer, passed down to L2 for further packaging, processing, etc., and then passed down to L1 to be mapped to a physical resources (e.g., time, frequency, spatial, code, etc. resources) for transmission to the receiving device (s) via a radio interface, such as the Uu interface, a PC5 interface, etc. The receiving device receives the transmission over the radio interface at L1. The payload of data is then passed upwards within the protocol stack of the receiving device for processing at each of L2 and L3.

At a high level, a payload of data for transmission to a receiving device (s) may be generated at an upper layer as a set of IP packet (s) . Each IP packet at the resource block level is passed down to the service data adaptation protocol (SDAP) layer, where a SDAP header is added to the packet. This creates an SDAP SDU including the SDAP header. The SDAP SDU with the SDAP header is then passed down to the PDCP layer, where a PDCP PDU header is added to the packet. This creates a PDCP SDU including the PDCP header. The PDCP SDU with the PDCP header is passed down to the RLC layer, where an RLC header is added to the packet. This creates an RLC SDU with the RLC header. The RLC SDU with the RLC header is then passed down to the MAC layer, where a MAC header is added to the packet. This creates a MAC SDU plus the MAC header. The MAC layer assembles the MAC SDUs with MAC headers into a MAC PDU transport block, which is passed down to the physical layer for transmission.

Broadly, the PDU/SDU references relates to L2 protocols. In some aspects, a SDU refers to input data received at one layer from an upper layer for processing. For example, a layer receives a PDU, which is an SDU from the perspective of the receiving layer, and then outputs a PDU after packaging/processing at the receiving layer to a the lower layer (e.g., in a transmission scenario) . This PDU being provided to the lower layer is an SDU from the perspective of that lower layer. Accordingly, the output of the data from the protocol entity is the PDU and the input to that protocol entity is the SDU. For example, what arrives at the PDCP layer (e.g., in a transmission scenario) is an RRC PDU which becomes, from the perspective of the PDCP layer, a PDCP PDU. The PDCP layer performs PDCP related processing on the PDCP SDU and then outputs PDCP PDUs to a lower layer (e.g., the RLC layer) . In other words, a PDU specifies the data that will be sent to the peer protocol layer (e.g., a PCDP PDU from the transmitting PDCP entity 310) to the receiving device (s) (e.g., a PDCP PDU provided to receiving PDCP entity 315) .

Some wireless communication systems (e.g., unicast, multi-cast, broadcast, etc. ) do not support L2 retransmissions (e.g., retransmissions of L2 SDUs or PDUs) , which may negative impact reliability. Extending the maximum number retransmissions in a lower layer using HARQ techniques may be inefficient and result in a potentially long latency. Window based RLC acknowledgment mode (AM) , which may include a sliding window being used to detect error packets and assemble the packets at the RLC receiver side, may involve undesirable complexities, latencies, or inefficiencies when used for correcting residual errors of lower layers. For example, such techniques may require unicast retransmission, even where initial transmissions are broadcast or multicast.

Wireless communication systems may utilize fountain codes, which are rateless codes in that the number of encoded packets to be transmitted is potentially limitless. For example, the transmitted packets may be recovered at the receiver side so long as the number of received packets is sufficiently large (e.g., slightly larger than the number of source packets) , regardless of which particular packets are received and successfully decoded. Examples of such rateless codes include LT codes, raptor codes (an enhanced code based on variations of LDPC and LT codes) , and the like.

Fountain codes may also be referred to as network codes because they are typically applied to the network/application layer (e.g., for MBMS, IAB, V2X, and the like) . At the receiving side, each encoded symbol would either be decoded correctly or discarded (e.g., the encoded packet (s) transmitted during a symbol) . This approach permits a block number (e.g., SBN) or a symbol identifier (e.g., ESI) associated with the packet (s) to be added as a header file to the encoded symbols. The SBN generally corresponds to an integer identifier for the source block (e.g., the column of the original generator matrix) that the encoded symbols within the packet relate to. The ESI generally corresponds to an integer identifier for the encoding symbols within the packet. Each encoded packet may include the SBN (e.g., the first 16 bits) , the ESI (e.g., the last 16 bits) , and the encoding symbol (s) . Based on the SBN and ESI, the transmitting device and receiving device may determine which source symbols (e.g., which column of the original generator matrix) were selected to generate the encoded symbol.

Accordingly, fountain codes are rateless codes with an unlimited number of columns in the original generator matrix generated by the transmitting device. For example, the transmitting device may have K symbols for transmission to the receiving device. The original generator matrix may therefore be generated with K rows (corresponding to the K symbols) and, as the fountain code is a rateless code, a potentially infinite number of columns. The number of transmitted packets may correspond to the formula:

For a conventional ARQ, the original generator matrix may begin with the unit matrix.

The recovered packets (e.g., the received packets) may correspond to the formula:

The condition or scenario for the receiving device to recover the packets may include G′ according to the received packets being invertible or the rank of G′ being K. A design rule for the original generator matrix is that G′ is invertible with minimum N.

However, as discussed above conventional wireless communication systems do not support application (e.g., encoding) of the rateless codes at L2, such as at the PDCP layer. Accordingly, and given that the PDCP layer is the entrance to the L2 protocol stack, aspects of the described techniques provide for rateless coding to be configured in the PDCP layer, which may increase link reliability without causing significant latency issues or protocol change. For example, the SDAP provides quality of service (QoS) mapping and flow identifier (ID) and does not impact packet processing. The RLC layer works under transparent mode (TM) or unacknowledgement mode (UM) without providing ARQ functionality. Rateless/network coding techniques, as described herein, may support recovery of missing packets in a multi-cast/broadcast system.

For example, the PDCP layer (e.g., transmitting PDCP entity 310) may receive a set of PDCP SDUs corresponding to a payload of data for transmission to receiving device (s) . The set of PDCP SDUs may generally include packets for transmission to convey the payload of data. Broadly, the PDCP layer may perform various processing operations, additions, etc., on the set of PDCP SDUs in order to generate a corresponding set of PDCP PDUs to be provided to a lower layer (e.g., the RLC layer) , which will ultimately be processed and passed down to the physical layer for transmission to the receiving device (s) over the air interface. For example, the PDCP layer may encode the set of PDCP SDUs using network coding parameters (e.g., a rateless code) . In some aspects, encoding of the PDCP SDUs at the PDCP layer may be performed after integrity protection, ciphering, and the like.

For example, the set of PDCP SDUs may be received in transmission buffer 320. That is, the data (e.g., the set of PDCP SDUs corresponding to packets of the payload of data) may be stored in the transmission buffer and have a sequence number added to each PDCP SDU. Broadly, the sequence number may be used to determine whether the packet is received in order, whether there are any duplications for the packet, how the packets are to be arranged to re-create the original payload of data, and the like. In some aspects, the sequence number applied to a PDCP SDU may be associated with a COUNT value that may correspond to a next transmission field (TX_NEXT) for the PDCP SDU. The packets may be provided to header compression 325 for processing, e.g., to perform header compression of the PDCP SDU. For example, header compression 325 may modify the header of the PDCP SDU for efficiency. In some aspects, header compression 325 may not be applied for non-PDCP SDU packets (e.g., control plane packets, such as RRC/non-access stratum (NAS) messages) . In some aspects, header compression 325 may be applied to PDCP SDU packets (e.g., user plane packets, such as the packets corresponding to the payload of data) . For example, header compression 325 may be applied to user plane packets, although this may be skipped in some scenarios.

The PDCP SDU packets may leave header compression 325 and be processed by integrity protection (IP) 330 and ciphering 335 functions before being provided for header addition 345 and routing/duplication 350 for final processing before being provided to lower layers for transmission. Header addition 345 adds the PDCP header to the PDCP SDU and routing/duplication 350 routes the packet to the intended bearer, if applicable.

However, aspects of the described techniques provide for encoder 340 to be enabled, configured, implemented, or otherwise provided, at the PDCP layer of the packet before integrity protection/ciphering functions. As discussed, the encoder 340 may encode a PDCP SDU of the set of PDCP SDUs to create, define, or otherwise obtain a corresponding set of encoded PDCP PDUs. However, it is to be understood that in some examples the PDCP SDUs may be PDCP PDUs from the perspective of receiving PDCP entity 315 after routing/duplication 350 processing. Accordingly, the transmitting PDCP entity 310 (e.g., the PDCP layer in this example) may apply network coding parameters including a rateless code to the PDCP SDUs at encoder 340.

Accordingly, aspects of the described techniques permit, after integrity protection 330 and ciphering 335 functionality, the PDCP data PDU (e.g., the PDCP SDU) being encoded using network coding, rateless coding, etc. In some aspects, the encoded PDCP PDU using rateless coding may also be referred to as a coded PDCP SDU.

To encode the PDCP SDU, the encoder 340 may segment the PDCP SDU into one or more PDCP PDUs, in some cases referred to as source PDCP PDUs. The encoder 340 may encode the one or more source PDCP PDUs using a rateless code (e.g., fountain code, network code, etc. ) to generate one or more parity PDCP PDUs. The source PDCP PDUs and the parity PDCP PDUs may, collectively, be referred to as an encoded set of PDCP PDUs. In some cases, the transmitting device may store the encoded set of PDCP PDUs in a retransmission buffer 390.

In some examples, the number of source PDCP PDUs that the PDCP SDU is segmented into may be configured by the network (e.g., using RRC configuration signaling in a PDCP-Config field) . Accordingly, the encoded set of PDCP PDUs may be passed to header addition 345 discussed above, where a PDCP header is added to each encoded PDCP PDU and then provided to routing/duplication 350 for final processing before being provided to a lower layer for transmission to the receiving device (s) .

Each PDCP PDU header may include fields to assist a receiving device in decoding and reassembling the associated PDCP SDU. For example, each PDU header may include a sequence number for one associated PDCP SDU. The receiving device may be able to determine which PDCP PDUs are for a same PDCP SDU based on the sequence numbers. In some cases, a PDCP PDU header may include an L field, which indicates whether the attached PDCP data PDU is a last PDU of one SDU. The L field may be used by the receiving device to determine if all PDCP PDUs associated with one PDCP SDU have been received. If the receiving device cannot reassemble the PDCP SDU after receiving all PDCP PDUs, the PDCP SDU may be considered missing by the receiving device. In some cases, a PDCP PDU header may include a sub-sequence number field, which indicate the index of the attached PDCP PDU associating to one PDCP SDU. The receiving device may use the sub-sequence number field to order the received PDCP PDUs and obtain the PDCP SDU. In some cases, a PDCP PDU header may include a T field, which may indicate whether the attached PDCP data PDU is a repaired PDU or not.

In some aspects, while a rateless code may itself be rateless, it may be utilized so as to achieve an actual code rate. A code may be considered rateless if the code is not associated with any fixed code rate (which may alternatively be referred to as coding rate) . For example, a set of source symbols (or packets, such as SDUs or PDUs) may be encoded using a rateless code to generate any quantity of encoded symbols (or packets, such as SDUs or PDUs) , and the source symbols may be recovered based on any sufficiently large group of encoded symbols-that is, it may not matter which particular encoded symbols are received by a receiving device, so long as a sufficient quantity of encoded symbols are received. Thus, a transmitting device may generate and transmit any quantity of encoded symbols for a given quantity of source symbols, so long as the quantity generated and transmitted is sufficiently large, and the actual quantity generated and transmitted may vary over time (e.g., during a first period of time, the transmitting device may generate and transmit X encoded symbols per N source symbols using the rateless code, and during a second period of time, the transmitting device may generate and transmit Y encoded symbols per N source symbols using the same rateless code, where X and Y are both sufficiently large, but perhaps Y is larger than X to further increase a likelihood that a receiving device is able to successfully decode a sufficient number of the transmitted encoded symbols for a given set of source symbols, at the cost of extra signaling or other overhead) .

Thus, though any quantity of corresponding PDCP PDUs (e.g., including the source PDCP PDUs and parity PDCP PDUs) may be generated by encoding an SDU using a rateless code, the actual code rate with which a set of one or more SDUs is encoded using the rateless code may be equal to the total quantity of SDUs in the set of one or more SDUs (or alternatively the total quantity of corresponding source PDUs) divided by the total number of corresponding PDCP PDUs actually generated for the set of one or more SDUs. In some cases, the network may configure a minimum code rate for the source PDCP data PDU (e.g., using the PDCP-Config field in RRC signaling) . For example, RRC configuration signaling may be received indicating the minimum code rate for the encoding using the rateless code. The actual (as utilized) code rate for the encoding using the rateless code may be adjusted based on the RRC signaling.

In some aspects, an actual code rate may be dynamically adjusted based on the feedback from the receiving device (s) , such as in a PDCP status PDU (e.g., a status report indicating HARQ information, or a more simple report) . For example, the status report may be received that indicates the quantity of PDCP PDUs that the receiving device decoded and used to attempt to reassemble the PDCP SDU within receiving PDCP entity 315. A field (e.g., NumPDU) in the PDCP status PDU (e.g., the report) may indicate the number of PDCP data PDUs used to decode the whole PDCP SDU. The code rate of the encoding using the rateless code may be adjusted based on the status report. For example, the encoding process for each encoding symbol (e.g., each PDCP SDU) may include the transmitting device (e.g., encoding 340) randomly choosing a degree d _i from a degree distribution and randomly choosing d _i distinct source symbols with uniform distribution and performing an exclusive or (XOR) function on them. Selecting different degrees d _i may result in effectively providing a minimum code rate for encoding using the rateless codes.

Accordingly, a PDCP SDU may, after segmentation, be used to generate of a set of source PDCP PDUs (e.g., source PDUs) associated with one PDCP SDU as well as a set of corresponding parity PDCP PDUs (e.g., parity PDUs) . Headers may be added to the encoded PDCP PDUs may carry or otherwise convey an indication of the total number of source PDCP PDUs and parity PDCP PDUs, which the receiving device (s) may use to efficiently parse the received encoded PDCP PDUs.

The encoded set of PDCP PDUs are then transmitted to the receiving device (s) over the Uu radio interface by the physical layer of the transmitting device. The payload of data is received at the physical layer of the receiving device (s) , processed, and then passed up to L2 for additional processing, e.g., the PDCP layer of the receiving device, which corresponds to the receiving PDCP entity 315. Accordingly, the set of encoded PDCP PDUs may be received at the PDCP layer of the receiving device. Initially this may include each PDCP PDU being provided to header removal 355 for removal the PDCP header. As discussed above, the PDCP header may indicate an index for each PDCP PDU as well as an associated PDCP SDU. Accordingly, the receiving device may determine an order for the source PDCP PDUs and parity PDCP PDUs associated with one PDCP SDU based on the header removed at header removal 355.

The PDCP SDU may be decoded at decoder 360 according to the network coding parameters (including the rateless code) to obtain corresponding PDCP SDUs. In some aspects, this may include window based PDCP receive procedures being used (e.g., for PDCP in-order delivery, PDU duplication detection, and the like) . Decoder 360 may decode the PDCP SDU and deliver this to the deciphering 365.

In some aspects, the receiving device may begin to decode and reassemble a PDCP SDU when a minimum number of PDCP data PDUs have been received that are associated with a single PDCP SDU (e.g., to reduce decoding complexity) . In some cases, the network may configure the minimum number of PDCP data PDUs. In one example, the one or more network coding parameters can include, additionally to other parameters described elsewhere herein, the minimum number of PDCP data PDUs. In some examples, the receiving device may stop decoding PDCP data PDUs associated to one PDCP SDU if the PDCP SDU can be reassembled successfully. The receiving device may discard any additional PDCP PDUs once the associated PDCP SDU is reassembled, which may save packet decoding latency and processing

The decoded PDCP SDU is then routed through deciphering 365, integrity verification 370, and reception buffer 375 for processing. For example, deciphering 365 may decipher the PDCP SDU, integrity verification 370 may verify the integrity of the PDCP SDU, and reception buffer 375 may store the PDCP SDU. Reception buffer 375 may provide the PDCP SDU to header compression 380, which then provides the PDCP SDU to an upper layer of the receiving device higher than the PDCP layer (e.g., an RRC layer) . As discussed above, non-PDCP SDU packets (e.g., control plane packets) may skip deciphering 365, integrity verification 370, etc.

As discussed above, aspects of the described techniques may also provide ARQ functionality at the PDCP layer. For example, the receiving device may determine that the PDCP SDU is unable to be successfully received and decoded. Accordingly, PDCP status PDU 385 may transmit or otherwise provide a status report (e.g., or more simply report) indicating that the PDCP SDU is unable to be successfully received and decoded. In some aspects, the status report may carry or otherwise convey an indication of a sequence number to a next PDCP SDU that is yet to be received (e.g., ACK_SN, which corresponds to the SN of the next PDCP SDU that has not been received) . In some aspects, the status report may carry or otherwise convey an indication of a bitmap indicating the PDCP SDUs which are missing or correctly received at the receiving device. In some aspects, the status report may carry or otherwise indicate a quantity of PDCP PDUs the receiving device decoded and used to attempt to obtain the at least one PDCP SDU (e.g., number of PDCP PDUs, including source and parity PDUs, that were decoded and used to assemble one PDCP SDU) . The transmitting device may adjust the minimum code rate for encoding a repair PDCP SDU based on the report. Additionally, or alternatively, the minimum code rate may be adjusted for future (e.g., non-repair) PDCP SDU encodings.

Retransmission buffer 390 of the transmitting PDCP entity 310 may monitor for and receive the status report from PDCP status PDU 385 (e.g., the status report may be transmitted over the radio interface) and use this information to provide some degree of ARQ functionality. For example, retransmission buffer 390 implemented at the PDCP layer of the transmitting device may determine that the status report for a previously transmitted encoded PDCP PDU comprises a negative acknowledgment for the encoded PDCP PDU. Accordingly, the retransmission buffer 390 may determine that at least one PDCP SDU in the set of PDCP SDUs correspond to the previously transmitted set of encoded PDCP PDUs (e.g., a repair/retransmission PDCP PDU) . Encoder 340 may encode the PDCP SDU as a repair PDCP SDU based on the negative acknowledgment.

As discussed above, the RLC layer typically sets below (e.g., is a lower layer) the PDCP layer. The RLC layer may operate in UM/TM. When operating in UM, the RLC layer may provide segmentation of the PDCP SDU for the transmitting device or reassembly of the PDCP PDU for the receiving device. This may include a sliding window being implemented at the RLC entity of both the transmitting device and the receiving device, segmentation/re-segmentation in the RLC layer of the transmitting device, reassembly of the segmented RLC SDU at the RLC entity of the receiving device, and the like. When operating in TM, the RLC layer may provide transparent transmissions (e.g., neither SDU segmentation nor ARQ functionality) . In this situation, segmentation/re-segmentation may be implemented at the MAC layer, e.g., a MAC SDU can be segmented based on a grant of resource. In this situation, the PDCP layer may provide security, outer coding based ARQ, and in-order delivery of the PDCP PDUs.

It is to be understood that FIG. 3 illustrates just an example approach to implementing network coding at the PDCP layer, and that other approaches are possible. For example, rather than encoding PDCP SDUs after integrity protection 330 and ciphering 335 (and decoding PDCP SDUs before deciphering 365 and integrity verification 370) , an alternative implementation may encode PDCP SDUs before integrity protection integrity protection 330 and ciphering 335 (and decode PDCP SDUs after deciphering 365 and integrity verification 370) but still within the PDCP layer. As another example, an alternative implementation may segment a PDCP SDU to obtain a corresponding set of source PDCP sub-PDUs, and encode the set of source PDCP sub-PDUs to obtain a set of encoded source PDPC sub-PDUs, and prepend a PDCP PDU header to a single PDPC PDU that includes the set of encoded source PDPC sub-PDUs. Thus, rather than each segment of the PDCP SDU eventually corresponding to a PDCP PDU with a corresponding PDCP PDU header (and thus multiple PDCP PDUs and associated PDCP PDU headers being generated for a single PDCP SDU) , each segment of the PDCP SDU may eventually correspond to a sub-PDU within a single encoded PDCP PDU that has a single PDCP PDU header.

FIG. 4 illustrates an example of a PDCP configuration 400 that supports polling and status reporting for network coding in accordance with aspects of the present disclosure. In some examples, PDCP configuration 400 may implement aspects of

wireless communication systems

100 or 200. Aspects of PDCP configuration 400 may be implemented by a transmitting device or receiving device, which may be examples of the UE or base station as described herein.

A transmitting device may identify a PDCP SDU 405 for transmission to one or more receiving devices and prepare the PDCP SDU 405 for network coding at the PDCP layer. For example, the transmitting device may perform sequence numbering, header compression, integrity protection, and ciphering as described herein. The transmitting device may then obtain a PDCP SDU 405 with integrity protection and ciphering.

To perform network coding at the PDCP layer, the transmitting device may segment the PDCP SDU 405 into a set of source PDCP PDUs 410. For example, the transmitting device may segment the PDCP SDU 405 into source PDCP PDU 410-a through 410-m. In some cases, the transmitting device may be configured with a size or number of source PDCP PDUs 410 to segment the PDCP SDU into.

The transmitting device may encode the set of source PDCP PDUs 410 according to a set of network coding parameters. In some cases, encoding the source PDCP PDUs 410 according to the set of network coding parameters may generate a set of parity PDCP PDUs 415.

The set of network coding parameters may include a code (e.g., a rateless code) as well as a code rate (e.g., an actual or as-applied code rate) for the encoding. In some cases, the code rate may be pre-configured at the transmitting device. For example, the transmitting device may generate a quantity of encoded source PDUs 410 and encoded parity PDCP PDUs 415, where the combined quantity of encoded source PDUs 410 and encoded parity PDCP PDUs 415 (e.g., the total quantity of encoded PDUs in the set of encoded PDCP PDUs) relative to the quantity of segmented source PDUs 410 is based on (e.g., equal to) the code rate. In addition to the encoded source PDUs 410, the transmitting device may generate N parity PDCP PDUs 415 to achieve the code rate, from parity PDCP PDU 415-a to parity PDCP PDU 415-n. Therefore, the transmitting device may generate a set of encoded PDCP PDUs, including the source PDCP PDUs 410 and the parity PDCP PDUs 415.

In some cases, the set of network coding parameters may include a minimum code rate for the PDCP PDUs. Additionally or alternatively, the set of network coding parameters may include the minimum number of encoded parity PDCP PDUs 315, or other parameters described elsewhere herein. The transmitting device may encode the source PDCP PDUs 410 to generate encoded PDCP PDUs 410 and encoded parity PDCP PDUs 415 according to the minimum code rate, at least for a first network coded PDCP SDU transmission. An actual code rate may be dynamically adjusted based on feedback from the one or more receiving devices.

In some cases, the transmitting device may store the encoded set of PDCP PDUs in a retransmission buffer. Storing the encoded set of PDCP PDUs may decrease latency for generating a retransmission of the PDCP SDU 305. For example, the transmitting device may obtain the PDCP PDUs for a missed PDCP SDU from the retransmission buffer instead of generating a new set of encoded PDCP PDUs.

The transmitting device may generate PDU headers 420 for the set of encoded PDCP PDUs. Each PDCP PDU of the set of encoded PDCP PDUs (e.g., including source PDCP PDUs 410 and parity PDCP PDUs 415) may have a PDU header prepended. The PDU header 420 may be an example of a PDU header 505 or a PDU header 605 described with reference to FIGs. 5 and 6, respectively. The PDU header 420 may, in some cases, include fields or parameters related to the network coding.

After prepending the PDU headers 420 for the set of encoded PDCP PDUs, the transmitting device may perform routing and duplication for the set of encoded PDCP PDUs and submit the resulting set of encoded PDCP PDUs to a lower layer. The transmitting device may transmit the set of encoded PDCP PDUs via the lower layers (e.g., over a wireless interface) to the one or more receiving devices.

In some cases, a receiving device may transmit a PDCP status PDU to a transmitting device based on failing to correctly assemble a PDCP SDU 405 from a set of source PDCP PDUs 410. The PDCP status PDU may contain feedback information which may support the transmitting device in dynamically adjusting a code rate, which may reduce latency and improve system efficiency.

It is to be understood that FIG. 4 illustrates just an example approach to implementing network coding at the PDCP layer, and that other approaches are possible. For example, as discussed elsewhere herein, an alternative implementation may segment a PDCP SDU 405 to obtain a corresponding set of source PDCP sub-PDUs, and encode the set of source PDCP sub-PDUs to obtain a set of encoded source PDPC sub-PDUs, and prepend a PDCP PDU header to a single PDPC PDU that includes the set of encoded source PDPC sub-PDUs. Thus, rather than each segment of the PDCP SDU 405 eventually corresponding to a PDCP PDU 410 with a corresponding PDCP PDU header 420 (and thus multiple PDCP PDUs 410 and associated PDCP PDU headers 420 being generated for a single PDCP SDU 405) , each segment of the PDCP SDU 405 may eventually correspond to a sub-PDU within a single encoded PDCP PDU that has a single PDCP PDU header.

FIGs. 5A and 5B illustrate examples of

PDCP polling messages

501 and 502 that support polling and status reporting for network coding in accordance with aspects of the present disclosure. In some examples,

PDCP polling messages

501 and 502 may implement aspects of

wireless communication system

100 or 200. The PDCP polling message 501 may illustrate an example of a PDCP message transmitted from a transmitting device to a receiving device. In some cases, the

PDCP polling message

501 or 502 may provide a polling mechanism that supports PDCP feedback from a PDCP receiving device.

The PDCP polling message 501 (e.g., a PDCP PDU) may include PDU header 505-a, D/C field 510-a indicating whether the message is a data message or a control message, P field 515-a indicating whether the message is a polling message (e.g., whether the message is prompting the transmission of a PDCP status PDU) , T field 520-a indicating whether the message is a repair PDU (e.g., a retransmission PDU) , L field 525-a indicating whether the message is the last PDU of an SDU, PDCP SN fields 530 indicating a SN of the message, and Sub SN field 535-a indicating the index (e.g., the source) PDU or parity PDU associated with an SDU. PDCP SN field 530-a may correspond to a first index and PDCP SN field 530-b may correspond to a second index different from the first index. P bit 515-a may be inserted into the PDCP polling message 501 based on a polling condition being met. In some cases, the polling condition may correspond to a timer expiration, a number of transmitted PDCP data PDUs, a number of bytes associated with a number of transmitted PDCP data PDUs, or any combination thereof.

The polling condition may be based on an RRC configuration, and the transmitting device may include P bit 515-a based on the polling condition being met. In some cases, the duration of the timer (e.g., a polling timer) may be configured as part the RRC procedure, and the transmitting device may insert P bit 515-a into PDU header 505-a based on an expiration of the timer. In some cases, a first RRC parameter may correspond to enabling or disabling the timer, and in some additional or alternative examples, a second RRC parameter may correspond to a time duration of the timer. In some examples, a time duration value may correspond to disabling the timer. For example, an infinite time duration may correspond to disabling the timer, and the transmitting device may disable the timer based on receiving an RRC parameter corresponding to an infinite time duration. The transmitting device may start or restart the timer after inserting P bit 515-a into PDU header 505-a.

A PDCP receiving device (e.g., a UE) may be associated with a timer (e.g., a prohibit timer) , and the timer may be configured as part of an RRC procedure. The RRC procedure may enable the timer, disable the timer, or configure the timer with a value (e.g., via the PDCP-Config field) . In some cases, a timer value corresponding to an infinite value may correspond to disabling the timer. The timer may start or restart when a PDCP data PDU arrives at an empty buffer (e.g., a PDCP buffer) at the receiving device. The timer may additionally or alternatively start or restart when a report (e.g., a new PDCP status PDU) is transmitted by the receiving device. The receiving device may generate a report (e.g., a PDCP status PDU) when the timer expires. For example, the duration of the timer may be configured via an RRC procedure, and the receiving device may generate a PDCP status PDU and transmit the PDCP status PDU to a transmitting device based on the expiration of the timer.

The PDCP polling message 502 (e.g., a PDCP PDU) may include PDU header 505-b, D/C field 510-b indicating whether the message is a data message or a control message, P filed 515-b indicating whether the message is a polling message (e.g., whether the message is prompting the transmission of a PDCP status PDU) , T field 520-b indicating whether the message is a repair PDU (e.g., a retransmission PDU) , L field 525-b indicating whether the message is the last PDU of an SDU, R fields 540-a and 545-b corresponding to reserved bits, PDCP SN fields 530-c, 530-d, and 530-e indicating a SN of the message, and Sub SN field 535-b indicating an index (e.g., the source) PDU or parity PDU associated with an SDU. P bit 515-a may be inserted into the PDCP polling message 502 based on a polling condition being met. In some cases, the polling condition may correspond to a timer expiration, a number of transmitted PDCP data PDUs, a number of bytes associated with a number of transmitted PDCP data PDUs, or any combination thereof.

FIGs. 6A and 6B illustrate examples of

PDCP status messages

601 and 602 that support polling and status reporting for network coding in accordance with aspects of the present disclosure. In some examples,

PDCP status messages

601 and 602 may implement aspects of

wireless communication system

100 or 200. In some cases, the

PDCP status message

601 or 602 may provide a feedback mechanism that supports PDCP status PDU feedback from a PDCP receiving device. The

message

601 or 602 may be transmitted by a receiving device (e.g., a UE) in accordance with a unicast transmission, and the feedback may indicate the status of a set of PDCP PDUs or one or more PDCP SDUs.

The PDCP status message 601 (e.g., a PDCP status PDU) may include PDU header 605-a, D/C field 610-a indicating whether the message is a data message or a control message, PDU Type field 615-a indicating a type of report, a number of R fields 620 (e.g., R fields 620-a, 620-b, 620-c, 620-d, 620-e, and 620-f) corresponding to a number of reserved bits. Either as part of or outside the header, the PDCP status message 601 may further include C field 625-a indicating the type of PDCP status PDU (e.g., type 1 comprising an ACK_SN field, type 2 comprising an ACK_SN field and a NumPDU field, type 3 comprising an ACK_SN field, a NumPDU field, and a Bitmap field, etc. ) . The ACK SN fields 630 may indicate the SN of a PDCP SDU that was not received at the receiving device. In some cases, ACK SN 630-a and ACK SN 630-b may correspond to the same SN (e.g., a conjunction or concatenation of ACK SN 630-a and ACK SN 630-b may indicate a single SN) and therefore the same PDCP SDU. For example, the combination of ACK SN 630-a and ACK SN 630-b, which may include 12 bits, may be used to indicate the SN of a PDCP SDU that was not received at the receiving device.

In some examples, a NumPDU field 635 may indicate a number of PDCP PDUs decoded and used to assemble a PDCP SDU, and in some additional or alternative examples, a NumPDU field 635 may indicate the number of PDCP sub-PDUs decoded and used to assemble a PDCP SDU. For example, NumPDU 635-a field may correspond to a quantity (e.g., a one-shot number) indicating the number of PDCP PDUs (e.g., including source PDCP PDUs or parity PDCP PDUs) decoded and used to assemble a PDCP SDU. The quantity may be based on PDCP PDUs or PDCP sub-PDUs received with a polling flag. As an additional or alternative example, NumPDU field 635-a may correspond to a statistical measure (e.g., an average recorded quantity, a median quantity, a mode quantity, etc. ) of the number of PDCP PDUs or PDCP sub-PDUs decoded and used to assemble a PDCP SDU. The statistical measure may be based on PDCP PDUs or PDCP sub-PDUs received since a most recent polling flag was received or since a most recent PDCP status PDU was transmitted.

A Bitmap field 640 may indicate PDCP SDUs that are missing from the receiver or correctly received or assembled at the receiver. In some cases, a bitmap field 640 may include a bitmap that indicates the PDCP SDUs in relation to the ACK SN 630 field. For example, bitmap 640-a may indicate PDCP SDUs that have been correctly received by the receiver, and bitmap 640-b may indicate PDCP SDUs that are missing (e.g., not received, unsuccessfully decoded, etc. ) from the receiver. Bitmap field 640-a may correspond to a first bitmap field and bitmap field 640-b may correspond to a second bitmap field different from the first bitmap field.

The PDCP status message 602 (e.g., a PDCP status PDU) may include PDU header 605-b, D/C field 610-b indicating whether the message is a data message or a control message, PDU type field 615-b indicating the type of report, a number of R fields 620 (e.g., R fields 620-g, 620-h, 620-i, 620-j, 620-k, 620-l, 620-m and 620-n) corresponding to a number of reserved bits. Either as part of or outside the header, the PDCP status message 602 may further include C field 625-b indicating the type of PDCP status PDU (e.g., type 1 comprising an ACK_SN field, type 2 comprising an ACK_SN field and a NumPDU field, type 3 comprising an ACK_SN field, a NumPDU field, and a Bitmap field, etc. ) The ACK SN fields 630 may indicate the SN of a PDCP SDU that was not received at the receiving device. In some cases, ACK SN field 630-c, ACK SN field 630-d, and ACK SN field 630-e may correspond to the same SN (and therefore the same PDCP SDU) . For example, the combination of ACK SN 630-c, ACK SN 630-d, and ACK SN 630-e, which may include 18 bits, may be used to indicate the SN of a PDCP SDU that was not received at the receiving device.

In some examples, a NumPDU field 635 may indicate a number of PDCP PDUs decoded and used to assemble a PDCP SDU, and in some additional or alternative examples, a NumPDU field 635 may indicate the number of PDCP sub-PDUs decoded and used to assemble a PDCP SDU. For example, NumPDU 635-b field may correspond to a quantity (e.g., a one-shot number) indicating the number of PDCP PDUs (e.g., including source PDCP PDUs or parity PDCP PDUs) decoded and used to assemble a PDCP SDU. The quantity may be based on PDCP PDUs or PDCP sub-PDUs received with a polling flag. As an additional or alternative example, NumPDU field 635-b may correspond to a statistical measure (e.g., an average recorded quantity, a median quantity, a mode quantity, etc. ) of the number of PDCP PDUs or PDCP sub-PDUs decoded and used to assemble a PDCP SDU. The statistical measure may be based on PDCP PDUs or PDCP sub-PDUs received since a most recent polling flag was received or since a most recent PDCP status PDU was transmitted.

One or more bitmap fields 640 may indicate PDCP SDUs that are missing from the receiver or correctly received or assembled at the receiver. In some cases, a bitmap field 640 may include a bitmap that indicates the PDCP SDUs in relation to the ACK SN 630 field. For example, bitmap 640-c may indicate PDCP SDUs that have been correctly received by the receiver, and bitmap 640-d may indicate PDCP SDUs that are missing (e.g., not received, unsuccessfully decoded, etc. ) from the receiver. Bitmap field 640-c may correspond to a first bitmap field and bitmap field 640-d may correspond to a second bitmap field.

In some cases, the transmitting device may dynamically adjust a coding rate for PDCP messages based on the PDCP status message 602. For example, the transmitting device may adjust the coding rate based on receiving a PDCP status message 602 that includes an acknowledgement SN (e.g., an ACK SN field 630, the SN of the next non-received PDCP SDU) and any combination of an indication of a quantity of PDUs (e.g., a NumPDU field 635, a one-shot number of PDCP PDUs or PDCP sub-PDUs) , an indication of an average quantity of PDUs (e.g., a NumPDU field 635, an average recorded number of PDCP PDUs or PDCP sub-PDUs) , or a bitmap (e.g., a bitmap field 635, an indication of the missing or correctly received PDCP SDUs) . In some cases, different ARQ schemes may be performed based on feedback information indicated as part of

PDCP status message

601 or 602, which may reduce system latency.

FIG. 7 illustrates an example of a process flow 700 that supports polling and status reporting for network coding in accordance with aspects of the present disclosure. In some examples, process flow 700 may implement aspects of

wireless communication systems

100 or 200. The process flow 700 may include UE 115-e, UE 115-f, and base station 105-b, which may be examples of the corresponding devices described with reference to FIGs. 1 through 6. Alternative examples of the following may be implemented, where some steps are performed in a different order than described or are not performed at all. In some cases, steps may include additional features not mentioned below, or further steps may be added.

At 705, a transmitting device (e.g., base station 105-b) may transmit a set of PDCP PDUs corresponding to one or more PDCP SDUs to one or more receiving devices (e.g., one or more UEs 115) . The transmitting device may transmit the set of PDCP PDUs to UE 115-e, and in some cases, the transmitting device may also transmit the set of PDCP PDUs to UE 115-f. For example, base station 105-b may broadcast the set of PDCP PDUs a group of UEs 115.

At 710, the transmitting device may determine that a polling condition has been met. The polling condition may correspond to an expiration of a timer (e.g., a periodic timer) , a number of transmitted PDCP data PDUs, or a number of bytes associated with a number of transmitted PDCP data PDUs.

At 715, the transmitting device may set a polling flag within a subsequent PDCP PDU based on determining that the polling condition has been met. The transmitting device may transmit the subsequent PDCP PDU to one or more receiving devices (e.g., UE 115-e or UE 115-f) . The transmitting device may monitor for a report from the receiving device of the one or more receiving devices based on transmitting the subsequent PDCP PDU.

At 725, the receiving device may generate a report indicating a status of the set of PDCP PDUs or the one or more PDCP SDUs at the PDCP layer. In some cases, the receiving device may generate the report based on receiving the polling flag at 715 or the timer (e.g., a prohibit timer) expiration at 720. The report may indicate a status of the transmitted set of PDCP PDUs or the one or more PDCP SDUs.

At 730, the receiving device may transmit the report to the transmitting device. The report may include a SN of a PDCP SDU, an indication of a quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain a PDCP SDU, an average quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain one or more PDCP SDUs, a bitmap indicating, for each PDCP SDU, whether the receiving device was successful or unsuccessful in receiving a respective SDU, or any combination thereof. In some cases, UE 115-e or UE 115-f may transmit a report to the transmitting device. The transmitting device may modify a coding rate based on receiving the report, which may reduce system latency.

FIG. 8 shows a block diagram 800 of a device 805 that supports polling and status reporting for network coding in accordance with aspects of the present disclosure. The device 805 may be an example of aspects of a UE 115 or base station 105 as described herein. The device 805 may include a receiver 810, a communications manager 815, and a transmitter 820. The device 805 may also include a processor. Each of these components may be in communication with one another (e.g., via one or more buses) .

Receiver 810 may receive information such as packets, user data, or control information associated with various information channels (e.g., control channels, data channels, and information related to polling and status reporting for network coding, etc. ) . Information may be passed on to other components of the device 805. The receiver 810 may be an example of aspects of the

transceiver

1120 or 1220 as described with reference to FIGs. 11 and 12. The receiver 810 may utilize a single antenna or a set of antennas.

The communications manager 815 may transmit, to one or more receiving devices, a set of PDCP PDUs corresponding to one or more PDCP SDUs, transmit the subsequent PDCP PDU to the one or more receiving devices, determine that a polling condition at the transmitting device has been met, set, based on determining that the polling condition has been met, a polling flag within a subsequent PDCP PDU, and monitor for a report from a receiving device of the one or more receiving devices based on transmitting the subsequent PDCP PDU, the report indicating a status of the transmitted set of PDCP PDUs or the one or more PDCP SDUs. The communications manager 815 may also receive, at a PDCP layer of the receiving device, a set of PDCP PDUs from a transmitting device, the set of PDPC PDUs corresponding to one or more PDCP SDUs, generate, at the PDCP layer, a report indicating a status of the set of PDCP PDUs or the one or more PDCP SDUs at the receiving device, and transmit the report to the transmitting device. The communications manager 815 may be an example of aspects of the

communications manager

1110 or 1210 as described herein.

The communications manager 815, or its sub-components, may be implemented in hardware, code (e.g., software or firmware) executed by a processor, or any combination thereof. If implemented in code executed by a processor, the functions of the communications manager 815, or its sub-components may be executed by a general-purpose processor, a digital signal processor (DSP) , an application-specific integrated circuit (ASIC) , a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described in the present disclosure.

The communications manager 815, or its sub-components, may be physically located at various positions, including being distributed such that portions of functions are implemented at different physical locations by one or more physical components. In some examples, the communications manager 815, or its sub-components, may be a separate and distinct component in accordance with various aspects of the present disclosure. In some examples, the communications manager 815, or its sub-components, may be combined with one or more other hardware components, including but not limited to an input/output (I/O) component, a transceiver, a network server, another computing device, one or more other components described in the present disclosure, or a combination thereof in accordance with various aspects of the present disclosure.

In some examples, the communications manager 815 may be implemented as an integrated circuit or chipset for a mobile device modem, and the receiver 810 and transmitter 820 may be implemented as analog components (e.g., amplifiers, filters, antennas) coupled with the mobile device modem to enable wireless transmission and reception over one or more bands.

The communications manage 815 as described herein may be implemented to realize one or more potential advantages. One implementation may allow device 805 to support ARQ procedures at the PDCP layer. Based on the techniques described herein, the communications manage 815 may support PDCP status polling and the generating of PDCP status reports. As such, the device 805 may decrease system latency and increase likelihood of successful receptions of packets (e.g., one or more PDCP PDUs or SDUs) . In some examples, based on the decreased system latency, the device 805 may improve user experience and increase battery life at the device 805.

Transmitter 820 may transmit signals generated by other components of the device 805. In some examples, the transmitter 820 may be collocated with a receiver 810 in a transceiver module. For example, the transmitter 820 may be an example of aspects of the

transceiver

1120 or 1220 as described with reference to FIGs. 11 and 12. The transmitter 820 may utilize a single antenna or a set of antennas.

FIG. 9 shows a block diagram 900 of a device 905 that supports polling and status reporting for network coding in accordance with aspects of the present disclosure. The device 905 may be an example of aspects of a device 805, a UE 115, or a base station 105 as described herein. The device 905 may include a receiver 910, a communications manager 915, and a transmitter 955. The device 905 may also include a processor. Each of these components may be in communication with one another (e.g., via one or more buses) .

Receiver 910 may receive information such as packets, user data, or control information associated with various information channels (e.g., control channels, data channels, and information related to polling and status reporting for network coding, etc. ) . Information may be passed on to other components of the device 905. The receiver 910 may be an example of aspects of the

transceiver

1120 or 1220 as described with reference to FIGs. 11 and 12. The receiver 910 may utilize a single antenna or a set of antennas.

The communications manager 915 may be an example of aspects of the communications manager 815 as described herein. The communications manager 915 may include a PDU transmitter 920, a polling condition manager 925, a polling flag component 930, a report monitor 935, a PDU receiver 940, a report generator 945, and a report transmitter 950. The communications manager 915 may be an example of aspects of the

communications manager

1110 or 1210 as described herein.

The PDU transmitter 920 may transmit, to one or more receiving devices, a set of PDCP PDUs corresponding to one or more PDCP SDUs and transmit the subsequent PDCP PDU to the one or more receiving devices.

The polling condition manager 925 may determine that a polling condition at the transmitting device has been met.

The polling flag component 930 may set, based on determining that the polling condition has been met, a polling flag within a subsequent PDCP PDU.

The report monitor 935 may monitor for a report from a receiving device of the one or more receiving devices based on transmitting the subsequent PDCP PDU, the report indicating a status of the transmitted set of PDCP PDUs or the one or more PDCP SDUs.

The PDU receiver 940 may receive, at a PDCP layer of the receiving device, a set of PDCP PDUs from a transmitting device, the set of PDPC PDUs corresponding to one or more PDCP SDUs.

The report generator 945 may generate, at the PDCP layer, a report indicating a status of the set of PDCP PDUs or the one or more PDCP SDUs at the receiving device.

The report transmitter 950 may transmit the report to the transmitting device.

Transmitter 955 may transmit signals generated by other components of the device 905. In some examples, the transmitter 955 may be collocated with a receiver 910 in a transceiver module. For example, the transmitter 955 may be an example of aspects of the

transceiver

1120 or 1220 as described with reference to FIGs. 11 and 12. The transmitter 955 may utilize a single antenna or a set of antennas.

FIG. 10 shows a block diagram 1000 of a communications manager 1005 that supports polling and status reporting for network coding in accordance with aspects of the present disclosure. The communications manager 1005 may be an example of aspects of a communications manager 815, a communications manager 915, or a communications manager 1110 described herein. The communications manager 1005 may include a PDU transmitter 1010, a polling condition manager 1015, a polling flag component 1020, a report monitor 1025, an indication receiver 1030, a timer component 1035, a code rate manager 1040, a report decoder 1045, a PDU receiver 1050, a report generator 1055, a report transmitter 1060, a timer manager 1065, and a report type manager 1070. Each of these modules may communicate, directly or indirectly, with one another (e.g., via one or more buses) .

The PDU transmitter 1010 may transmit, to one or more receiving devices, a set of PDCP PDUs corresponding to one or more PDCP SDUs.

In some examples, the PDU transmitter 1010 may transmit the subsequent PDCP PDU to the one or more receiving devices.

In some cases, a header of the subsequent PDCP PDU includes the polling flag.

The polling condition manager 1015 may determine that a polling condition at the transmitting device has been met.

In some examples, the polling condition manager 1015 may determine that a quantity of PDCP PDUs included in the set of PDCP PDUs satisfies a threshold.

In some examples, the polling condition manager 1015 may determine that a quantity of data included in the set of PDCP PDUs satisfies a threshold.

The polling flag component 1020 may set, based on determining that the polling condition has been met, a polling flag within a subsequent PDCP PDU.

The report monitor 1025 may monitor for a report from a receiving device of the one or more receiving devices based on transmitting the subsequent PDCP PDU, the report indicating a status of the transmitted set of PDCP PDUs or the one or more PDCP SDUs.

In some examples, receiving the report based on the monitoring, where the report includes an indication of a quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain a PDCP SDU.

In some examples, receiving the report based on the monitoring, where the report includes an indication of an average quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain each PDCP SDU of a set of PDCP SDUs.

In some examples, receiving the report based on the monitoring, where the report includes an indication of a SN for a PDCP SDU of the one or more PDCP SDUs, the indication of the SN indicating that the receiving device was able to obtain each of the one or more PDCP SDUs having a SN lower than the indicated SN.

In some examples, receiving the report based on the monitoring, where the report includes an indication of a report type for the report, the indicated report type one of a set of report types.

In some cases, the report further includes a bitmap indicating, for each PDCP SDU of the one or more PDCP SDUs having a SN greater than the indicated SN, whether the receiving device was successful or unsuccessful in obtaining a respective PDCP SDU.

The PDU receiver 1050 may receive, at a PDCP layer of the receiving device, a set of PDCP PDUs from a transmitting device, the set of PDPC PDUs corresponding to one or more PDCP SDUs.

In some examples, the PDU receiver 1050 may receive, from the transmitting device after receiving the set of PDCP PDUs, a subsequent PDCP PDU that includes a polling flag, where generating the report is based on the polling flag.

In some examples, the PDU receiver 1050 may receive a PDCP PDU of the set of PDCP PDUs at an empty buffer of the receiving device, where initiating the timer is based on receiving the PDU at the empty buffer.

In some cases, the receiving device is unable to obtain a PDCP SDU of the one or more PDCP SDUs.

The report generator 1055 may generate, at the PDCP layer, a report indicating a status of the set of PDCP PDUs or the one or more PDCP SDUs at the receiving device.

In some cases, the report includes a SN of the PDCP SDU based on the PDCP SDU having a lowest SN among a subset of one or more PDCP SDU that the receiving device is unable to obtain among the one or more PDCP SDUs.

In some cases, the report further includes a bitmap indicating, for each PDCP SDU among the one or more PDCP SDUs having a SN greater than the SN of the PDCP SDU, whether the receiving device was successful or unsuccessful in obtaining a respective PDCP SDU.

In some cases, the report includes an indication of a quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain a PDCP SDU.

In some cases, the report includes an indication of an average quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain each PDCP SDU of a set of PDCP SDUs.

The report transmitter 1060 may transmit the report to the transmitting device.

In some examples, the report transmitter 1060 may transmit, to the transmitting device before transmitting the report, a prior report indicating a status of a prior set of PDCP PDUs, where initiating the timer is based on transmitting the prior report.

The indication receiver 1030 may receive an indication of the threshold via radio resource control signaling.

In some examples, the indication receiver 1030 may receive an indication to enable or disable the timer via radio resource control signaling.

In some examples, the indication receiver 1030 may receive an indication of a duration for the timer via radio resource control signaling.

In some cases, the indication is an indication to disable the timer, and where the indication to disable the timer includes an indication of an infinite duration for the timer.

The timer component 1035 may initiate a timer based on transmitting a prior PDCP PDU that includes a prior polling flag, where determining that the polling condition has been met includes identifying an expiration of the timer.

In some examples, the timer component 1035 may enable or disabling the timer based on the indication.

In some examples, the timer component 1035 may configure the duration for the timer based on the indication.

The code rate manager 1040 may adjust a code rate for encoding PDCP SDUs at the PDCP layer based on the indicated quantity of PDCP PDUs or PDCP sub-PDUs.

In some examples, the code rate manager 1040 may adjust a code rate for encoding PDCP SDUs at the PDCP layer based on the indicated average quantity of PDCP PDUs or PDCP sub-PDUs.

The report decoder 1045 may decode the report based on least in part on the indication of the report type for the report.

In some cases, the report type is a first report type of the set of report types, the report including an indication of a SN for a PDCP SDU of the one or more PDCP SDUs, the indication of the SN indicating that the receiving device was able to obtain each of the one or more PDCP SDUs having a SN lower than the indicated SN.

In some cases, the report type is a second report type of the set of report types, the report including the indication of the SN for the PDCP SDU of the one or more PDCP SDUs, and the report further including at least one of an indication of a quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain a PDCP SDU or an indication of an average quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain each PDCP SDU of a set of PDCP SDUs; or.

In some cases, the report type is a third report type of the set of report types, the report including the indication of the SN for the PDCP SDU of the one or more PDCP SDUs, the report further including at least one of the indication of a quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain a PDCP SDU or the indication of the average quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain each PDCP SDU of the set of PDCP SDUs, and the report further including a bitmap indicating, for each PDCP SDU of the one or more PDCP SDUs having a SN greater than the indicated SN, whether the receiving device was successful or unsuccessful in obtaining a respective PDCP SDU.

The timer manager 1065 may initiate a timer at the receiving device, where generating the report is based on an expiration of the timer.

In some examples, the timer manager 1065 may receive an indication to enable or disable the timer via radio resource control signaling.

In some examples, the timer manager 1065 may enable or disabling the timer based on the indication.

In some examples, the timer manager 1065 may receive an indication of a duration for the timer via radio resource control signaling.

In some examples, the timer manager 1065 may configure the duration for the timer based on the indication.

The report type manager 1070 may receive, via radio resource control signaling, an indication of a report type for the receiving device to use to indicate a status of PDCP PDUs at the receiving device, the indicated report type one of a set of report types, where the report is of the indicated report type.

In some cases, the report indicates the report type to the transmitting device.

In some cases, the report type is a first report type of the set of report types, the report including a SN of the PDCP SDU based on the PDCP SDU having a lowest SN among a subset of one or more PDCP SDU that the receiving device is unable to obtain among the one or more PDCP SDUs.

In some cases, the report type is a second report type of the set of report types, the report including the SN of the PDCP SDU, and the report further including at least one of an indication of a quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain a PDCP SDU or an indication of an average quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain each PDCP SDU of a set of PDCP SDUs; or.

In some cases, the report type is a third report type of the set of report types, the report including the indication of the SN for the PDCP SDU of the one or more PDCP SDUs, the report further including at least one of the indication of the quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain the PDCP SDU or the indication of the average quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain each PDCP SDU of the set of PDCP SDUs, and the report further including a bitmap indicating, for each PDCP SDU among the one or more PDCP SDUs having a SN greater than the SN of the PDCP SDU, whether the receiving device was successful or unsuccessful in receiving a respective PDCP SDU.

FIG. 11 shows a diagram of a system 1100 including a device 1105 that supports polling and status reporting for network coding in accordance with aspects of the present disclosure. The device 1105 may be an example of or include the components of device 805, device 905, or a UE 115 as described herein. The device 1105 may include components for bi-directional voice and data communications including components for transmitting and receiving communications, including a communications manager 1110, a transceiver 1120, an antenna 1125, memory 1130, a processor 1140, and an I/O controller 1150. These components may be in electronic communication via one or more buses (e.g., bus 1155) .

The communications manager 1110 may transmit, to one or more receiving devices, a set of PDCP PDUs corresponding to one or more PDCP SDUs, transmit the subsequent PDCP PDU to the one or more receiving devices, determine that a polling condition at the transmitting device has been met, set, based on determining that the polling condition has been met, a polling flag within a subsequent PDCP PDU, and monitor for a report from a receiving device of the one or more receiving devices based on transmitting the subsequent PDCP PDU, the report indicating a status of the transmitted set of PDCP PDUs or the one or more PDCP SDUs. The communications manager 1110 may also receive, at a PDCP layer of the receiving device, a set of PDCP PDUs from a transmitting device, the set of PDPC PDUs corresponding to one or more PDCP SDUs, generate, at the PDCP layer, a report indicating a status of the set of PDCP PDUs or the one or more PDCP SDUs at the receiving device, and transmit the report to the transmitting device.

Transceiver 1120 may communicate bi-directionally, via one or more antennas, wired, or wireless links as described herein. For example, the transceiver 1120 may represent a wireless transceiver and may communicate bi-directionally with another wireless transceiver. The transceiver 1120 may also include a modem to modulate the packets and provide the modulated packets to the antennas for transmission, and to demodulate packets received from the antennas.

In some cases, the wireless device may include a single antenna 1125. However, in some cases the device may have more than one antenna 1125, which may be capable of concurrently transmitting or receiving multiple wireless transmissions.

The memory 1130 may include RAM, ROM, or a combination thereof. The memory 1130 may store computer-readable code 1135 including instructions that, when executed by a processor (e.g., the processor 1140) cause the device to perform various functions described herein. In some cases, the memory 1130 may contain, among other things, a basic input/output system (BIOS) which may control basic hardware or software operation such as the interaction with peripheral components or devices.

The processor 1140 may include an intelligent hardware device, (e.g., a general-purpose processor, a DSP, a CPU, a microcontroller, an ASIC, an FPGA, a programmable logic device, a discrete gate or transistor logic component, a discrete hardware component, or any combination thereof) . In some cases, the processor 1140 may be configured to operate a memory array using a memory controller. In other cases, a memory controller may be integrated into the processor 1140. The processor 1140 may be configured to execute computer-readable instructions stored in a memory (e.g., the memory 1130) to cause the device 1105 to perform various functions (e.g., functions or tasks supporting polling and status reporting for network coding) .

The I/O controller 1150 may manage input and output signals for the device 1105. The I/O controller 1150 may also manage peripherals not integrated into the device 1105. In some cases, the I/O controller 1150 may represent a physical connection or port to an external peripheral. In some cases, the I/O controller 1150 may utilize an operating system such as

or another known operating system. In other cases, the I/O controller 1150 may represent or interact with a modem, a keyboard, a mouse, a touchscreen, or a similar device. In some cases, the I/O controller 1150 may be implemented as part of a processor. In some cases, a user may interact with the device 1105 via the I/O controller 1150 or via hardware components controlled by the I/O controller 1150.

The code 1135 may include instructions to implement aspects of the present disclosure, including instructions to support wireless communications. The code 1135 may be stored in a non-transitory computer-readable medium such as system memory or other type of memory. In some cases, the code 1135 may not be directly executable by the processor 1140 but may cause a computer (e.g., when compiled and executed) to perform functions described herein.

FIG. 12 shows a diagram of a system 1200 including a device 1205 that supports polling and status reporting for network coding in accordance with aspects of the present disclosure. The device 1205 may be an example of or include the components of device 805, device 905, or a base station 105 as described herein. The device 1205 may include components for bi-directional voice and data communications including components for transmitting and receiving communications, including a communications manager 1210, a network communications manager 1215, a transceiver 1220, an antenna 1225, memory 1230, a processor 1240, and an inter-station communications manager 1245. These components may be in electronic communication via one or more buses (e.g., bus 1255) .

The communications manager 1210 may transmit, to one or more receiving devices, a set of PDCP PDUs corresponding to one or more PDCP SDUs, transmit the subsequent PDCP PDU to the one or more receiving devices, determine that a polling condition at the transmitting device has been met, set, based on determining that the polling condition has been met, a polling flag within a subsequent PDCP PDU, and monitor for a report from a receiving device of the one or more receiving devices based on transmitting the subsequent PDCP PDU, the report indicating a status of the transmitted set of PDCP PDUs or the one or more PDCP SDUs. The communications manager 1210 may also receive, at a PDCP layer of the receiving device, a set of PDCP PDUs from a transmitting device, the set of PDPC PDUs corresponding to one or more PDCP SDUs, generate, at the PDCP layer, a report indicating a status of the set of PDCP PDUs or the one or more PDCP SDUs at the receiving device, and transmit the report to the transmitting device.

Network communications manager 1215 may manage communications with the core network (e.g., via one or more wired backhaul links) . For example, the network communications manager 1215 may manage the transfer of data communications for client devices, such as one or more UEs 115.

Transceiver 1220 may communicate bi-directionally, via one or more antennas, wired, or wireless links as described herein. For example, the transceiver 1220 may represent a wireless transceiver and may communicate bi-directionally with another wireless transceiver. The transceiver 1220 may also include a modem to modulate the packets and provide the modulated packets to the antennas for transmission, and to demodulate packets received from the antennas.

In some cases, the wireless device may include a single antenna 1225. However, in some cases the device may have more than one antenna 1225, which may be capable of concurrently transmitting or receiving multiple wireless transmissions.

The memory 1230 may include RAM, ROM, or a combination thereof. The memory 1230 may store computer-readable code 1235 including instructions that, when executed by a processor (e.g., the processor 1240) cause the device to perform various functions described herein. In some cases, the memory 1230 may contain, among other things, a BIOS which may control basic hardware or software operation such as the interaction with peripheral components or devices.

The processor 1240 may include an intelligent hardware device, (e.g., a general-purpose processor, a DSP, a CPU, a microcontroller, an ASIC, an FPGA, a programmable logic device, a discrete gate or transistor logic component, a discrete hardware component, or any combination thereof) . In some cases, the processor 1240 may be configured to operate a memory array using a memory controller. In other cases, a memory controller may be integrated into the processor 1240. The processor 1240 may be configured to execute computer-readable instructions stored in a memory (e.g., the memory 1230) to cause the device 1205 to perform various functions (e.g., functions or tasks supporting polling and status reporting for network coding) .

Inter-station communications manager 1245 may manage communications with other base station 105, and may include a controller or scheduler for controlling communications with UEs 115 in cooperation with other base stations 105. For example, the inter-station communications manager 1245 may coordinate scheduling for transmissions to UEs 115 for various interference mitigation techniques such as beamforming or joint transmission. In some examples, inter-station communications manager 1245 may provide an X2 interface within an LTE/LTE-A wireless communication network technology to provide communication between base stations 105.

The code 1235 may include instructions to implement aspects of the present disclosure, including instructions to support wireless communications. The code 1235 may be stored in a non-transitory computer-readable medium such as system memory or other type of memory. In some cases, the code 1235 may not be directly executable by the processor 1240 but may cause a computer (e.g., when compiled and executed) to perform functions described herein.

FIG. 13 shows a flowchart illustrating a method 1300 that supports polling and status reporting for network coding in accordance with aspects of the present disclosure. The operations of method 1300 may be implemented by a UE 115 or base station 105 or its components as described herein. For example, the operations of method 1300 may be performed by a communications manager as described with reference to FIGs. 8 through 12. In some examples, a UE or base station may execute a set of instructions to control the functional elements of the UE or base station to perform the functions described herein. Additionally or alternatively, a UE or base station may perform aspects of the functions described herein using special-purpose hardware.

At 1305, the UE or base station may transmit, to one or more receiving devices, a set of PDCP PDUs corresponding to one or more PDCP SDUs. The operations of 1305 may be performed according to the methods described herein. In some examples, aspects of the operations of 1305 may be performed by a PDU transmitter as described with reference to FIGs. 8 through 12.

At 1310, the UE or base station may determine that a polling condition at the transmitting device has been met. The operations of 1310 may be performed according to the methods described herein. In some examples, aspects of the operations of 1310 may be performed by a polling condition manager as described with reference to FIGs. 8 through 12.

At 1315, the UE or base station may set, based on determining that the polling condition has been met, a polling flag within a subsequent PDCP PDU. The operations of 1315 may be performed according to the methods described herein. In some examples, aspects of the operations of 1315 may be performed by a polling flag component as described with reference to FIGs. 8 through 12.

At 1320, the UE or base station may transmit the subsequent PDCP PDU to the one or more receiving devices. The operations of 1320 may be performed according to the methods described herein. In some examples, aspects of the operations of 1320 may be performed by a PDU transmitter as described with reference to FIGs. 8 through 12.

At 1325, the UE or base station may monitor for a report from a receiving device of the one or more receiving devices based on transmitting the subsequent PDCP PDU, the report indicating a status of the transmitted set of PDCP PDUs or the one or more PDCP SDUs. The operations of 1325 may be performed according to the methods described herein. In some examples, aspects of the operations of 1325 may be performed by a report monitor as described with reference to FIGs. 8 through 12.

FIG. 14 shows a flowchart illustrating a method 1400 that supports polling and status reporting for network coding in accordance with aspects of the present disclosure. The operations of method 1400 may be implemented by a UE 115 or base station 105 or its components as described herein. For example, the operations of method 1400 may be performed by a communications manager as described with reference to FIGs. 8 through 12. In some examples, a UE or base station may execute a set of instructions to control the functional elements of the UE or base station to perform the functions described herein. Additionally or alternatively, a UE or base station may perform aspects of the functions described herein using special-purpose hardware.

At 1405, the UE or base station may transmit, to one or more receiving devices, a set of PDCP PDUs corresponding to one or more PDCP SDUs. The operations of 1405 may be performed according to the methods described herein. In some examples, aspects of the operations of 1405 may be performed by a PDU transmitter as described with reference to FIGs. 8 through 12.

At 1410, the UE or base station may determine that a quantity of PDCP PDUs included in the set of PDCP PDUs satisfies a threshold. The operations of 1410 may be performed according to the methods described herein. In some examples, aspects of the operations of 1410 may be performed by a polling condition manager as described with reference to FIGs. 8 through 12.

At 1415, the UE or base station may determine that a polling condition at the transmitting device has been met. The operations of 1415 may be performed according to the methods described herein. In some examples, aspects of the operations of 1415 may be performed by a polling condition manager as described with reference to FIGs. 8 through 12.

At 1420, the UE or base station may set, based on determining that the polling condition has been met, a polling flag within a subsequent PDCP PDU. The operations of 1420 may be performed according to the methods described herein. In some examples, aspects of the operations of 1420 may be performed by a polling flag component as described with reference to FIGs. 8 through 12.

At 1425, the UE or base station may transmit the subsequent PDCP PDU to the one or more receiving devices. The operations of 1425 may be performed according to the methods described herein. In some examples, aspects of the operations of 1425 may be performed by a PDU transmitter as described with reference to FIGs. 8 through 12.

At 1430, the UE or base station may monitor for a report from a receiving device of the one or more receiving devices based on transmitting the subsequent PDCP PDU, the report indicating a status of the transmitted set of PDCP PDUs or the one or more PDCP SDUs. The operations of 1430 may be performed according to the methods described herein. In some examples, aspects of the operations of 1430 may be performed by a report monitor as described with reference to FIGs. 8 through 12.

FIG. 15 shows a flowchart illustrating a method 1500 that supports polling and status reporting for network coding in accordance with aspects of the present disclosure. The operations of method 1500 may be implemented by a UE 115 or base station 105 or its components as described herein. For example, the operations of method 1500 may be performed by a communications manager as described with reference to FIGs. 8 through 12. In some examples, a UE or base station may execute a set of instructions to control the functional elements of the UE or base station to perform the functions described herein. Additionally or alternatively, a UE or base station may perform aspects of the functions described herein using special-purpose hardware.

At 1505, the UE or base station may transmit, to one or more receiving devices, a set of PDCP PDUs corresponding to one or more PDCP SDUs. The operations of 1505 may be performed according to the methods described herein. In some examples, aspects of the operations of 1505 may be performed by a PDU transmitter as described with reference to FIGs. 8 through 12.

At 1510, the UE or base station may determine that a quantity of data included in the set of PDCP PDUs satisfies a threshold. The operations of 1510 may be performed according to the methods described herein. In some examples, aspects of the operations of 1510 may be performed by a polling condition manager as described with reference to FIGs. 8 through 12.

At 1515, the UE or base station may determine that a polling condition at the transmitting device has been met. The operations of 1515 may be performed according to the methods described herein. In some examples, aspects of the operations of 1515 may be performed by a polling condition manager as described with reference to FIGs. 8 through 12.

At 1520, the UE or base station may set, based on determining that the polling condition has been met, a polling flag within a subsequent PDCP PDU. The operations of 1520 may be performed according to the methods described herein. In some examples, aspects of the operations of 1520 may be performed by a polling flag component as described with reference to FIGs. 8 through 12.

At 1525, the UE or base station may transmit the subsequent PDCP PDU to the one or more receiving devices. The operations of 1525 may be performed according to the methods described herein. In some examples, aspects of the operations of 1525 may be performed by a PDU transmitter as described with reference to FIGs. 8 through 12.

At 1530, the UE or base station may monitor for a report from a receiving device of the one or more receiving devices based on transmitting the subsequent PDCP PDU, the report indicating a status of the transmitted set of PDCP PDUs or the one or more PDCP SDUs. The operations of 1530 may be performed according to the methods described herein. In some examples, aspects of the operations of 1530 may be performed by a report monitor as described with reference to FIGs. 8 through 12.

FIG. 16 shows a flowchart illustrating a method 1600 that supports polling and status reporting for network coding in accordance with aspects of the present disclosure. The operations of method 1600 may be implemented by a UE 115 or base station 105 or its components as described herein. For example, the operations of method 1600 may be performed by a communications manager as described with reference to FIGs. 8 through 12. In some examples, a UE or base station may execute a set of instructions to control the functional elements of the UE or base station to perform the functions described herein. Additionally or alternatively, a UE or base station may perform aspects of the functions described herein using special-purpose hardware.

At 1605, the UE or base station may transmit, to one or more receiving devices, a set of PDCP PDUs corresponding to one or more PDCP SDUs. The operations of 1605 may be performed according to the methods described herein. In some examples, aspects of the operations of 1605 may be performed by a PDU transmitter as described with reference to FIGs. 8 through 12.

At 1610, the UE or base station may determine that a polling condition at the transmitting device has been met. The operations of 1610 may be performed according to the methods described herein. In some examples, aspects of the operations of 1610 may be performed by a polling condition manager as described with reference to FIGs. 8 through 12.

At 1615, the UE or base station may set, based on determining that the polling condition has been met, a polling flag within a subsequent PDCP PDU. The operations of 1615 may be performed according to the methods described herein. In some examples, aspects of the operations of 1615 may be performed by a polling flag component as described with reference to FIGs. 8 through 12.

At 1620, the UE or base station may transmit the subsequent PDCP PDU to the one or more receiving devices. The operations of 1620 may be performed according to the methods described herein. In some examples, aspects of the operations of 1620 may be performed by a PDU transmitter as described with reference to FIGs. 8 through 12.

At 1625, the UE or base station may monitor for a report from a receiving device of the one or more receiving devices based on transmitting the subsequent PDCP PDU, the report indicating a status of the transmitted set of PDCP PDUs or the one or more PDCP SDUs. The operations of 1625 may be performed according to the methods described herein. In some examples, aspects of the operations of 1625 may be performed by a report monitor as described with reference to FIGs. 8 through 12.

At 1630, the UE or base station may receive the report based on the monitoring, where the report includes an indication of a quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain a PDCP SDU. The operations of 1630 may be performed according to the methods described herein. In some examples, aspects of the operations of 1630 may be performed by a report monitor as described with reference to FIGs. 8 through 12.

At 1635, the UE or base station may adjust a code rate for encoding PDCP SDUs at the PDCP layer based on the indicated quantity of PDCP PDUs or PDCP sub-PDUs. The operations of 1635 may be performed according to the methods described herein. In some examples, aspects of the operations of 1635 may be performed by a code rate manager as described with reference to FIGs. 8 through 12.

FIG. 17 shows a flowchart illustrating a method 1700 that supports polling and status reporting for network coding in accordance with aspects of the present disclosure. The operations of method 1700 may be implemented by a UE 115 or base station 105 or its components as described herein. For example, the operations of method 1700 may be performed by a communications manager as described with reference to FIGs. 8 through 12. In some examples, a UE or base station may execute a set of instructions to control the functional elements of the UE or base station to perform the functions described herein. Additionally or alternatively, a UE or base station may perform aspects of the functions described herein using special-purpose hardware.

At 1705, the UE or base station may receive, at a PDCP layer of the receiving device, a set of PDCP PDUs from a transmitting device, the set of PDPC PDUs corresponding to one or more PDCP SDUs. The operations of 1705 may be performed according to the methods described herein. In some examples, aspects of the operations of 1705 may be performed by a PDU receiver as described with reference to FIGs. 8 through 12.

At 1710, the UE or base station may generate, at the PDCP layer, a report indicating a status of the set of PDCP PDUs or the one or more PDCP SDUs at the receiving device. The operations of 1710 may be performed according to the methods described herein. In some examples, aspects of the operations of 1710 may be performed by a report generator as described with reference to FIGs. 8 through 12.

At 1715, the UE or base station may transmit the report to the transmitting device. The operations of 1715 may be performed according to the methods described herein. In some examples, aspects of the operations of 1715 may be performed by a report transmitter as described with reference to FIGs. 8 through 12.

FIG. 18 shows a flowchart illustrating a method 1800 that supports polling and status reporting for network coding in accordance with aspects of the present disclosure. The operations of method 1800 may be implemented by a UE 115 or base station 105 or its components as described herein. For example, the operations of method 1800 may be performed by a communications manager as described with reference to FIGs. 8 through 12. In some examples, a UE or base station may execute a set of instructions to control the functional elements of the UE or base station to perform the functions described herein. Additionally or alternatively, a UE or base station may perform aspects of the functions described herein using special-purpose hardware.

At 1805, the UE or base station may receive, at a PDCP layer of the receiving device, a set of PDCP PDUs from a transmitting device, the set of PDPC PDUs corresponding to one or more PDCP SDUs. The operations of 1805 may be performed according to the methods described herein. In some examples, aspects of the operations of 1805 may be performed by a PDU receiver as described with reference to FIGs. 8 through 12.

At 1810, the UE or base station may receive, from the transmitting device after receiving the set of PDCP PDUs, a subsequent PDCP PDU that includes a polling flag, where generating the report is based on the polling flag. The operations of 1810 may be performed according to the methods described herein. In some examples, aspects of the operations of 1810 may be performed by a PDU receiver as described with reference to FIGs. 8 through 12.

At 1815, the UE or base station may generate, at the PDCP layer, a report indicating a status of the set of PDCP PDUs or the one or more PDCP SDUs at the receiving device. The operations of 1815 may be performed according to the methods described herein. In some examples, aspects of the operations of 1815 may be performed by a report generator as described with reference to FIGs. 8 through 12.

At 1820, the UE or base station may transmit the report to the transmitting device. The operations of 1820 may be performed according to the methods described herein. In some examples, aspects of the operations of 1820 may be performed by a report transmitter as described with reference to FIGs. 8 through 12.

FIG. 19 shows a flowchart illustrating a method 1900 that supports polling and status reporting for network coding in accordance with aspects of the present disclosure. The operations of method 1900 may be implemented by a UE 115 or base station 105 or its components as described herein. For example, the operations of method 1900 may be performed by a communications manager as described with reference to FIGs. 8 through 12. In some examples, a UE or base station may execute a set of instructions to control the functional elements of the UE or base station to perform the functions described herein. Additionally or alternatively, a UE or base station may perform aspects of the functions described herein using special-purpose hardware.

At 1905, the UE or base station may receive, at a PDCP layer of the receiving device, a set of PDCP PDUs from a transmitting device, the set of PDPC PDUs corresponding to one or more PDCP SDUs. The operations of 1905 may be performed according to the methods described herein. In some examples, aspects of the operations of 1905 may be performed by a PDU receiver as described with reference to FIGs. 8 through 12.

At 1910, the UE or base station may initiate a timer at the receiving device, where generating the report is based on an expiration of the timer. The operations of 1910 may be performed according to the methods described herein. In some examples, aspects of the operations of 1910 may be performed by a timer manager as described with reference to FIGs. 8 through 12.

At 1915, the UE or base station may generate, at the PDCP layer, a report indicating a status of the set of PDCP PDUs or the one or more PDCP SDUs at the receiving device. The operations of 1915 may be performed according to the methods described herein. In some examples, aspects of the operations of 1915 may be performed by a report generator as described with reference to FIGs. 8 through 12.

At 1920, the UE or base station may transmit the report to the transmitting device. The operations of 1920 may be performed according to the methods described herein. In some examples, aspects of the operations of 1920 may be performed by a report transmitter as described with reference to FIGs. 8 through 12.

It should be noted that the methods described herein describe possible implementations, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible. Further, aspects from two or more of the methods may be combined.

Although aspects of an LTE, LTE-A, LTE-A Pro, or NR system may be described for purposes of example, and LTE, LTE-A, LTE-A Pro, or NR terminology may be used in much of the description, the techniques described herein are applicable beyond LTE, LTE-A, LTE-A Pro, or NR networks. For example, the described techniques may be applicable to various other wireless communications systems such as Ultra Mobile Broadband (UMB) , Institute of Electrical and Electronics Engineers (IEEE) 802.11 (Wi-Fi) , IEEE 802.16 (WiMAX) , IEEE 802.20, Flash-OFDM, as well as other systems and radio technologies not explicitly mentioned herein.

Information and signals described herein may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

The various illustrative blocks and components described in connection with the disclosure herein may be implemented or performed with a general-purpose processor, a DSP, an ASIC, a CPU, an FPGA or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but in the alternative, the processor may be any processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices (e.g., a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration) .

The functions described herein may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Other examples and implementations are within the scope of the disclosure and appended claims. For example, due to the nature of software, functions described herein may be implemented using software executed by a processor, hardware, firmware, hardwiring, or combinations of any of these. Features implementing functions may also be physically located at various positions, including being distributed such that portions of functions are implemented at different physical locations.

Computer-readable media includes both non-transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A non-transitory storage medium may be any available medium that may be accessed by a general-purpose or special-purpose computer. By way of example, and not limitation, non-transitory computer-readable media may include random-access memory (RAM) , read-only memory (ROM) , electrically erasable programmable ROM (EEPROM) , flash memory, compact disk (CD) ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other non-transitory medium that may be used to carry or store desired program code means in the form of instructions or data structures and that may be accessed by a general-purpose or special-purpose computer, or a general-purpose or special-purpose processor. Also, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL) , or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of computer-readable medium. Disk and disc, as used herein, include CD, laser disc, optical disc, digital versatile disc (DVD) , floppy disk and Blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above are also included within the scope of computer-readable media.

As used herein, including in the claims, “or” as used in a list of items (e.g., a list of items prefaced by a phrase such as “at least one of” or “one or more of” ) indicates an inclusive list such that, for example, a list of at least one of A, B, or C means A or B or C or AB or AC or BC or ABC (i.e., A and B and C) . Also, as used herein, the phrase “based on” shall not be construed as a reference to a closed set of conditions. For example, an example step that is described as “based on condition A” may be based on both a condition A and a condition B without departing from the scope of the present disclosure. In other words, as used herein, the phrase “based on” shall be construed in the same manner as the phrase “based at least in part on. ”

In the appended figures, similar components or features may have the same reference label. Further, various components of the same type may be distinguished by following the reference label by a dash and a second label that distinguishes among the similar components. If just the first reference label is used in the specification, the description is applicable to any one of the similar components having the same first reference label irrespective of the second reference label, or other subsequent reference label.

The description set forth herein, in connection with the appended drawings, describes example configurations and does not represent all the examples that may be implemented or that are within the scope of the claims. The term “example” used herein means “serving as an example, instance, or illustration, ” and not “preferred” or “advantageous over other examples. ” The detailed description includes specific details for the purpose of providing an understanding of the described techniques. These techniques, however, may be practiced without these specific details. In some instances, known structures and devices are shown in block diagram form in order to avoid obscuring the concepts of the described examples.

The description herein is provided to enable a person having ordinary skill in the art to make or use the disclosure. Various modifications to the disclosure will be apparent to a person having ordinary skill in the art, and the generic principles defined herein may be applied to other variations without departing from the scope of the disclosure. Thus, the disclosure is not limited to the examples and designs described herein, but is to be accorded the broadest scope consistent with the principles and novel features disclosed herein.

Claims

A method for wireless communications at a transmitting device, comprising:

transmitting, to one or more receiving devices, a set of packet data convergence protocol (PDCP) protocol data units (PDUs) corresponding to one or more PDCP service data units (SDUs) ;

determining that a polling condition at the transmitting device has been met;

setting, based at least in part on determining that the polling condition has been met, a polling flag within a subsequent PDCP PDU;

transmitting the subsequent PDCP PDU to the one or more receiving devices; and

monitoring for a report from a receiving device of the one or more receiving devices based at least in part on transmitting the subsequent PDCP PDU, the report indicating a status of the transmitted set of PDCP PDUs or the one or more PDCP SDUs.
The method of claim 1, wherein determining that the polling condition has been met comprises:

determining that a quantity of PDCP PDUs included in the set of PDCP PDUs satisfies a threshold.
The method of claim 2, further comprising:

receiving an indication of the threshold via radio resource control signaling.
The method of claim 1, wherein determining that the polling condition has been met comprises:

determining that a quantity of data included in the set of PDCP PDUs satisfies a threshold.
The method of claim 4, further comprising:

receiving an indication of the threshold via radio resource control signaling.
The method of claim 1, further comprising:

initiating a timer based at least in part on transmitting a prior PDCP PDU that includes a prior polling flag, wherein determining that the polling condition has been met comprises identifying an expiration of the timer.
The method of claim 6, further comprising:

receiving an indication to enable or disable the timer via radio resource control signaling; and

enabling or disabling the timer based at least in part on the indication.
The method of claim 7, wherein the indication is an indication to disable the timer, and wherein the indication to disable the timer comprises an indication of an infinite duration for the timer.
The method of claim 6, further comprising:

receiving an indication of a duration for the timer via radio resource control signaling; and

configuring the duration for the timer based at least in part on the indication.
The method of claim 1, further comprising:

receiving the report based at least in part on the monitoring, wherein the report comprises an indication of a quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain a PDCP SDU; and

adjusting a code rate for encoding PDCP SDUs at the PDCP layer based at least in part on the indicated quantity of PDCP PDUs or PDCP sub-PDUs.
The method of claim 10, wherein the report further comprises a bitmap indicating, for each PDCP SDU of the one or more PDCP SDUs having a sequence number greater than the indicated sequence number, whether the receiving device was successful or unsuccessful in obtaining a respective PDCP SDU.
The method of claim 1, further comprising:

receiving the report based at least in part on the monitoring, wherein the report comprises an indication of an average quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain each PDCP SDU of a set of PDCP SDUs; and

adjusting a code rate for encoding PDCP SDUs at the PDCP layer based at least in part on the indicated average quantity of PDCP PDUs or PDCP sub-PDUs.
The method of claim 1, further comprising:

receiving the report based at least in part on the monitoring, wherein the report comprises an indication of a sequence number for a PDCP SDU of the one or more PDCP SDUs, the indication of the sequence number indicating that the receiving device was able to obtain each of the one or more PDCP SDUs having a sequence number lower than the indicated sequence number.
The method of claim 1, wherein a header of the subsequent PDCP PDU includes the polling flag.
The method of claim 1, further comprising:

receiving the report based at least in part on the monitoring, wherein the report comprises an indication of a report type for the report, the indicated report type one of a plurality of report types; and

decoding the report based on least in part on the indication of the report type for the report.
The method of claim 15, wherein:

the report type is a first report type of the plurality of report types, the report comprising an indication of a sequence number for a PDCP SDU of the one or more PDCP SDUs, the indication of the sequence number indicating that the receiving device was able to obtain each of the one or more PDCP SDUs having a sequence number lower than the indicated sequence number;

the report type is a second report type of the plurality of report types, the report comprising the indication of the sequence number for the PDCP SDU of the one or more PDCP SDUs, and the report further comprising at least one of an indication of a quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain a PDCP SDU or an indication of an average quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain each PDCP SDU of a set of PDCP SDUs; or; and

the report type is a third report type of the plurality of report types, the report comprising the indication of the sequence number for the PDCP SDU of the one or more PDCP SDUs, the report further comprising at least one of the indication of a quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain a PDCP SDU or the indication of the average quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain each PDCP SDU of the set of PDCP SDUs, and the report further comprising a bitmap indicating, for each PDCP SDU of the one or more PDCP SDUs having a sequence number greater than the indicated sequence number, whether the receiving device was successful or unsuccessful in obtaining a respective PDCP SDU.
A method for wireless communications at a receiving device, comprising:

receiving, at a packet data convergence protocol (PDCP) layer of the receiving device, a set of packet data convergence protocol (PDCP) protocol data units (PDUs) from a transmitting device, the set of PDPC PDUs corresponding to one or more PDCP service data units (SDUs) ;

generating, at the PDCP layer, a report indicating a status of the set of PDCP PDUs or the one or more PDCP SDUs at the receiving device; and

transmitting the report to the transmitting device.
The method of claim 17, further comprising:

receiving, from the transmitting device after receiving the set of PDCP PDUs, a subsequent PDCP PDU that includes a polling flag, wherein generating the report is based at least in part on the polling flag.
The method of claim 17, further comprising:

initiating a timer at the receiving device, wherein generating the report is based at least in part on an expiration of the timer.
The method of claim 19, further comprising:

receiving an indication to enable or disable the timer via radio resource control signaling; and

enabling or disabling the timer based at least in part on the indication.
The method of claim 20, wherein the indication is an indication to disable the timer, and wherein the indication to disable the timer comprises an indication of an infinite duration for the timer.
The method of claim 19, further comprising:

receiving an indication of a duration for the timer via radio resource control signaling; and

configuring the duration for the timer based at least in part on the indication.
The method of claim 19, further comprising:

receiving a PDCP PDU of the set of PDCP PDUs at an empty buffer of the receiving device, wherein initiating the timer is based at least in part on receiving the PDU at the empty buffer.
The method of claim 19, further comprising:

transmitting, to the transmitting device before transmitting the report, a prior report indicating a status of a prior set of PDCP PDUs, wherein initiating the timer is based at least in part on transmitting the prior report.
The method of claim 17, further comprising:

receiving, via radio resource control signaling, an indication of a report type for the receiving device to use to indicate a status of PDCP PDUs at the receiving device, the indicated report type one of a plurality of report types, wherein the report is of the indicated report type.
The method of claim 25, wherein the report indicates the report type to the transmitting device.
The method of claim 25, wherein:

the report type is a first report type of the plurality of report types, the report comprising a sequence number of the PDCP SDU based at least in part on the PDCP SDU having a lowest sequence number among a subset of one or more PDCP SDU that the receiving device is unable to obtain among the one or more PDCP SDUs;

the report type is a second report type of the plurality of report types, the report comprising the sequence number of the PDCP SDU, and the report further comprising at least one of an indication of a quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain a PDCP SDU or an indication of an average quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain each PDCP SDU of a set of PDCP SDUs; or; and

the report type is a third report type of the plurality of report types, the report comprising the indication of the sequence number for the PDCP SDU of the one or more PDCP SDUs, the report further comprising at least one of the indication of the quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain the PDCP SDU or the indication of the average quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain each PDCP SDU of the set of PDCP SDUs, and the report further comprising a bitmap indicating, for each PDCP SDU among the one or more PDCP SDUs having a sequence number greater than the sequence number of the PDCP SDU, whether the receiving device was successful or unsuccessful in receiving a respective PDCP SDU.
The method of claim 17, wherein:

the receiving device is unable to obtain a PDCP SDU of the one or more PDCP SDUs; and

the report comprises a sequence number of the PDCP SDU based at least in part on the PDCP SDU having a lowest sequence number among a subset of one or more PDCP SDU that the receiving device is unable to obtain among the one or more PDCP SDUs.
The method of claim 28, wherein the report further comprises a bitmap indicating, for each PDCP SDU among the one or more PDCP SDUs having a sequence number greater than the sequence number of the PDCP SDU, whether the receiving device was successful or unsuccessful in obtaining a respective PDCP SDU.
The method of claim 17, wherein the report comprises an indication of a quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain a PDCP SDU.
The method of claim 17, wherein the report comprises an indication of an average quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain each PDCP SDU of a set of PDCP SDUs.
An apparatus for wireless communications at a transmitting device, comprising:

a processor,

memory coupled with the processor; and

instructions stored in the memory and executable by the processor to cause the apparatus to:

transmit, to one or more receiving devices, a set of packet data convergence protocol (PDCP) protocol data units (PDUs) corresponding to one or more PDCP service data units (SDUs) ;

determine that a polling condition at the transmitting device has been met;

set, based at least in part on determining that the polling condition has been met, a polling flag within a subsequent PDCP PDU;

transmit the subsequent PDCP PDU to the one or more receiving devices; and

monitor for a report from a receiving device of the one or more receiving devices based at least in part on transmitting the subsequent PDCP PDU, the report indicating a status of the transmitted set of PDCP PDUs or the one or more PDCP SDUs.
The apparatus of claim 32, wherein the instructions to determine that the polling condition has been met are executable by the processor to cause the apparatus to:

determine that a quantity of PDCP PDUs included in the set of PDCP PDUs satisfies a threshold.
The apparatus of claim 33, wherein the instructions are further executable by the processor to cause the apparatus to:

receive an indication of the threshold via radio resource control signaling.
The apparatus of claim 32, wherein the instructions to determine that the polling condition has been met are executable by the processor to cause the apparatus to:

determine that a quantity of data included in the set of PDCP PDUs satisfies a threshold.
The apparatus of claim 35, wherein the instructions are further executable by the processor to cause the apparatus to:

receive an indication of the threshold via radio resource control signaling.
The apparatus of claim 32, wherein the instructions are further executable by the processor to cause the apparatus to:

the instructions to initiate a timer based at least in part on transmitting a prior PDCP PDU that includes a prior polling flag, wherein determining that the polling condition has been met are executable by the processor to cause the apparatus to identify an expiration of the timer.
The apparatus of claim 37, wherein the instructions are further executable by the processor to cause the apparatus to:

receive an indication to enable or disable the timer via radio resource control signaling; and

enable or disabling the timer based at least in part on the indication.
The apparatus of claim 38, wherein the indication is an indication to disable the timer, and wherein the indication to disable the timer comprises an indication of an infinite duration for the timer.
The apparatus of claim 37, wherein the instructions are further executable by the processor to cause the apparatus to:

receive an indication of a duration for the timer via radio resource control signaling; and

configure the duration for the timer based at least in part on the indication.
The apparatus of claim 32, wherein the instructions are further executable by the processor to cause the apparatus to:

receive the report based at least in part on the monitoring, wherein the report comprises an indication of a quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain a PDCP SDU; and

adjust a code rate for encoding PDCP SDUs at the PDCP layer based at least in part on the indicated quantity of PDCP PDUs or PDCP sub-PDUs.
The apparatus of claim 41, wherein the report further comprises a bitmap indicating, for each PDCP SDU of the one or more PDCP SDUs having a sequence number greater than the indicated sequence number, whether the receiving device was successful or unsuccessful in obtaining a respective PDCP SDU.
The apparatus of claim 32, wherein the instructions are further executable by the processor to cause the apparatus to:

receive the report based at least in part on the monitoring, wherein the report comprises an indication of an average quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain each PDCP SDU of a set of PDCP SDUs; and

adjust a code rate for encoding PDCP SDUs at the PDCP layer based at least in part on the indicated average quantity of PDCP PDUs or PDCP sub-PDUs.
The apparatus of claim 32, wherein the instructions are further executable by the processor to cause the apparatus to:

receive the report based at least in part on the monitoring, wherein the report comprises an indication of a sequence number for a PDCP SDU of the one or more PDCP SDUs, the indication of the sequence number indicating that the receiving device was able to obtain each of the one or more PDCP SDUs having a sequence number lower than the indicated sequence number.
The apparatus of claim 32, wherein a header of the subsequent PDCP PDU includes the polling flag.
The apparatus of claim 32, wherein the instructions are further executable by the processor to cause the apparatus to:

receive the report based at least in part on the monitoring, wherein the report comprises an indication of a report type for the report, the indicated report type one of a plurality of report types; and

decode the report based on least in part on the indication of the report type for the report.
The apparatus of claim 46, wherein:

the report type is a first report type of the plurality of report types, the report comprising an indication of a sequence number for a PDCP SDU of the one or more PDCP SDUs, the indication of the sequence number indicating that the receiving device was able to obtain each of the one or more PDCP SDUs having a sequence number lower than the indicated sequence number;

the report type is a second report type of the plurality of report types, the report comprising the indication of the sequence number for the PDCP SDU of the one or more PDCP SDUs, and the report further comprising at least one of an indication of a quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain a PDCP SDU or an indication of an average quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain each PDCP SDU of a set of PDCP SDUs; or; and

the report type is a third report type of the plurality of report types, the report comprising the indication of the sequence number for the PDCP SDU of the one or more PDCP SDUs, the report further comprising at least one of the indication of a quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain a PDCP SDU or the indication of the average quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain each PDCP SDU of the set of PDCP SDUs, and the report further comprising a bitmap indicating, for each PDCP SDU of the one or more PDCP SDUs having a sequence number greater than the indicated sequence number, whether the receiving device was successful or unsuccessful in obtaining a respective PDCP SDU.
An apparatus for wireless communications at a receiving device, comprising:

a processor,

memory coupled with the processor; and

instructions stored in the memory and executable by the processor to cause the apparatus to:

receive, at a packet data convergence protocol (PDCP) layer of the receiving device, a set of packet data convergence protocol (PDCP) protocol data units (PDUs) from a transmitting device, the set of PDPC PDUs corresponding to one or more PDCP service data units (SDUs) ;

generate, at the PDCP layer, a report indicating a status of the set of PDCP PDUs or the one or more PDCP SDUs at the receiving device; and

transmit the report to the transmitting device.
The apparatus of claim 48, wherein the instructions are further executable by the processor to cause the apparatus to:

receive, from the transmitting device after receiving the set of PDCP PDUs, a subsequent PDCP PDU that includes a polling flag, wherein generating the report is based at least in part on the polling flag.
The apparatus of claim 48, wherein the instructions are further executable by the processor to cause the apparatus to:

initiate a timer at the receiving device, wherein generating the report is based at least in part on an expiration of the timer.
The apparatus of claim 50, wherein the instructions are further executable by the processor to cause the apparatus to:

receive an indication to enable or disable the timer via radio resource control signaling; and

enable or disabling the timer based at least in part on the indication.
The apparatus of claim 51, wherein the indication is an indication to disable the timer, and wherein the indication to disable the timer comprises an indication of an infinite duration for the timer.
The apparatus of claim 50, wherein the instructions are further executable by the processor to cause the apparatus to:

receive an indication of a duration for the timer via radio resource control signaling; and

configure the duration for the timer based at least in part on the indication.
The apparatus of claim 50, wherein the instructions are further executable by the processor to cause the apparatus to:

receive a PDCP PDU of the set of PDCP PDUs at an empty buffer of the receiving device, wherein initiating the timer is based at least in part on receiving the PDU at the empty buffer.
The apparatus of claim 50, wherein the instructions are further executable by the processor to cause the apparatus to:

transmit, to the transmitting device before transmitting the report, a prior report indicating a status of a prior set of PDCP PDUs, wherein initiating the timer is based at least in part on transmitting the prior report.
The apparatus of claim 48, wherein the instructions are further executable by the processor to cause the apparatus to:

receive, via radio resource control signaling, an indication of a report type for the receiving device to use to indicate a status of PDCP PDUs at the receiving device, the indicated report type one of a plurality of report types, wherein the report is of the indicated report type.
The apparatus of claim 56, wherein the report indicates the report type to the transmitting device.
The apparatus of claim 56, wherein:

the report type is a first report type of the plurality of report types, the report comprising a sequence number of the PDCP SDU based at least in part on the PDCP SDU having a lowest sequence number among a subset of one or more PDCP SDU that the receiving device is unable to obtain among the one or more PDCP SDUs;

the report type is a second report type of the plurality of report types, the report comprising the sequence number of the PDCP SDU, and the report further comprising at least one of an indication of a quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain a PDCP SDU or an indication of an average quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain each PDCP SDU of a set of PDCP SDUs; or; and

the report type is a third report type of the plurality of report types, the report comprising the indication of the sequence number for the PDCP SDU of the one or more PDCP SDUs, the report further comprising at least one of the indication of the quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain the PDCP SDU or the indication of the average quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain each PDCP SDU of the set of PDCP SDUs, and the report further comprising a bitmap indicating, for each PDCP SDU among the one or more PDCP SDUs having a sequence number greater than the sequence number of the PDCP SDU, whether the receiving device was successful or unsuccessful in receiving a respective PDCP SDU.
The apparatus of claim 48, wherein:

the receiving device is unable to obtain a PDCP SDU of the one or more PDCP SDUs; and

the report comprises a sequence number of the PDCP SDU based at least in part on the PDCP SDU having a lowest sequence number among a subset of one or more PDCP SDU that the receiving device is unable to obtain among the one or more PDCP SDUs.
The apparatus of claim 59, wherein the report further comprises a bitmap indicating, for each PDCP SDU among the one or more PDCP SDUs having a sequence number greater than the sequence number of the PDCP SDU, whether the receiving device was successful or unsuccessful in obtaining a respective PDCP SDU.
The apparatus of claim 48, wherein the report comprises an indication of a quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain a PDCP SDU.
The apparatus of claim 48, wherein the report comprises an indication of an average quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain each PDCP SDU of a set of PDCP SDUs.
An apparatus for wireless communications at a transmitting device, comprising:

means for transmitting, to one or more receiving devices, a set of packet data convergence protocol (PDCP) protocol data units (PDUs) corresponding to one or more PDCP service data units (SDUs) ;

means for determining that a polling condition at the transmitting device has been met;

means for setting, based at least in part on determining that the polling condition has been met, a polling flag within a subsequent PDCP PDU;

means for transmitting the subsequent PDCP PDU to the one or more receiving devices; and

means for monitoring for a report from a receiving device of the one or more receiving devices based at least in part on transmitting the subsequent PDCP PDU, the report indicating a status of the transmitted set of PDCP PDUs or the one or more PDCP SDUs.
The apparatus of claim 63, wherein the means for determining that the polling condition has been met comprises:

means for determining that a quantity of PDCP PDUs included in the set of PDCP PDUs satisfies a threshold.
The apparatus of claim 64, further comprising:

means for receiving an indication of the threshold via radio resource control signaling.
The apparatus of claim 63, wherein the means for determining that the polling condition has been met comprises:

means for determining that a quantity of data included in the set of PDCP PDUs satisfies a threshold.
The apparatus of claim 66, further comprising:

means for receiving an indication of the threshold via radio resource control signaling.
The apparatus of claim 63, further comprising:

means for initiating a timer based at least in part on transmitting a prior PDCP PDU that includes a prior polling flag, wherein determining that the polling condition has been met comprises identifying an expiration of the timer.
The apparatus of claim 68, further comprising:

means for receiving an indication to enable or disable the timer via radio resource control signaling; and

means for enabling or disabling the timer based at least in part on the indication.
The apparatus of claim 69, wherein the indication is an indication to disable the timer, and wherein the indication to disable the timer comprises an indication of an infinite duration for the timer.
The apparatus of claim 68, further comprising:

means for receiving an indication of a duration for the timer via radio resource control signaling; and

means for configuring the duration for the timer based at least in part on the indication.
The apparatus of claim 63, further comprising:

means for receiving the report based at least in part on the monitoring, wherein the report comprises an indication of a quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain a PDCP SDU; and

means for adjusting a code rate for encoding PDCP SDUs at the PDCP layer based at least in part on the indicated quantity of PDCP PDUs or PDCP sub-PDUs.
The apparatus of claim 72, wherein the report further comprises a bitmap indicating, for each PDCP SDU of the one or more PDCP SDUs having a sequence number greater than the indicated sequence number, whether the receiving device was successful or unsuccessful in obtaining a respective PDCP SDU.
The apparatus of claim 63, further comprising:

means for receiving the report based at least in part on the monitoring, wherein the report comprises an indication of an average quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain each PDCP SDU of a set of PDCP SDUs; and

means for adjusting a code rate for encoding PDCP SDUs at the PDCP layer based at least in part on the indicated average quantity of PDCP PDUs or PDCP sub-PDUs.
The apparatus of claim 63, further comprising:

means for receiving the report based at least in part on the monitoring, wherein the report comprises an indication of a sequence number for a PDCP SDU of the one or more PDCP SDUs, the indication of the sequence number indicating that the receiving device was able to obtain each of the one or more PDCP SDUs having a sequence number lower than the indicated sequence number.
The apparatus of claim 63, wherein a header of the subsequent PDCP PDU includes the polling flag.
The apparatus of claim 63, further comprising:

means for receiving the report based at least in part on the monitoring, wherein the report comprises an indication of a report type for the report, the indicated report type one of a plurality of report types; and

means for decoding the report based on least in part on the indication of the report type for the report.
The apparatus of claim 77, wherein:

the report type is a first report type of the plurality of report types, the report comprising an indication of a sequence number for a PDCP SDU of the one or more PDCP SDUs, the indication of the sequence number indicating that the receiving device was able to obtain each of the one or more PDCP SDUs having a sequence number lower than the indicated sequence number;

the report type is a second report type of the plurality of report types, the report comprising the indication of the sequence number for the PDCP SDU of the one or more PDCP SDUs, and the report further comprising at least one of an indication of a quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain a PDCP SDU or an indication of an average quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain each PDCP SDU of a set of PDCP SDUs; or; and

the report type is a third report type of the plurality of report types, the report comprising the indication of the sequence number for the PDCP SDU of the one or more PDCP SDUs, the report further comprising at least one of the indication of a quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain a PDCP SDU or the indication of the average quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain each PDCP SDU of the set of PDCP SDUs, and the report further comprising a bitmap indicating, for each PDCP SDU of the one or more PDCP SDUs having a sequence number greater than the indicated sequence number, whether the receiving device was successful or unsuccessful in obtaining a respective PDCP SDU.
An apparatus for wireless communications at a receiving device, comprising:

means for receiving, at a packet data convergence protocol (PDCP) layer of the receiving device, a set of packet data convergence protocol (PDCP) protocol data units (PDUs) from a transmitting device, the set of PDPC PDUs corresponding to one or more PDCP service data units (SDUs) ;

means for generating, at the PDCP layer, a report indicating a status of the set of PDCP PDUs or the one or more PDCP SDUs at the receiving device; and

means for transmitting the report to the transmitting device.
The apparatus of claim 79, further comprising:

means for receiving, from the transmitting device after receiving the set of PDCP PDUs, a subsequent PDCP PDU that includes a polling flag, wherein generating the report is based at least in part on the polling flag.
The apparatus of claim 79, further comprising:

means for initiating a timer at the receiving device, wherein generating the report is based at least in part on an expiration of the timer.
The apparatus of claim 81, further comprising:

means for receiving an indication to enable or disable the timer via radio resource control signaling; and

means for enabling or disabling the timer based at least in part on the indication.
The apparatus of claim 82, wherein the indication is an indication to disable the timer, and wherein the indication to disable the timer comprises an indication of an infinite duration for the timer.
The apparatus of claim 81, further comprising:

means for receiving an indication of a duration for the timer via radio resource control signaling; and

means for configuring the duration for the timer based at least in part on the indication.
The apparatus of claim 81, further comprising:

means for receiving a PDCP PDU of the set of PDCP PDUs at an empty buffer of the receiving device, wherein initiating the timer is based at least in part on receiving the PDU at the empty buffer.
The apparatus of claim 81, further comprising:

means for transmitting, to the transmitting device before transmitting the report, a prior report indicating a status of a prior set of PDCP PDUs, wherein initiating the timer is based at least in part on transmitting the prior report.
The apparatus of claim 79, further comprising:

means for receiving, via radio resource control signaling, an indication of a report type for the receiving device to use to indicate a status of PDCP PDUs at the receiving device, the indicated report type one of a plurality of report types, wherein the report is of the indicated report type.
The apparatus of claim 87, wherein the report indicates the report type to the transmitting device.
The apparatus of claim 87, wherein:

the report type is a first report type of the plurality of report types, the report comprising a sequence number of the PDCP SDU based at least in part on the PDCP SDU having a lowest sequence number among a subset of one or more PDCP SDU that the receiving device is unable to obtain among the one or more PDCP SDUs;

the report type is a second report type of the plurality of report types, the report comprising the sequence number of the PDCP SDU, and the report further comprising at least one of an indication of a quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain a PDCP SDU or an indication of an average quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain each PDCP SDU of a set of PDCP SDUs; or; and

the report type is a third report type of the plurality of report types, the report comprising the indication of the sequence number for the PDCP SDU of the one or more PDCP SDUs, the report further comprising at least one of the indication of the quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain the PDCP SDU or the indication of the average quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain each PDCP SDU of the set of PDCP SDUs, and the report further comprising a bitmap indicating, for each PDCP SDU among the one or more PDCP SDUs having a sequence number greater than the sequence number of the PDCP SDU, whether the receiving device was successful or unsuccessful in receiving a respective PDCP SDU.
The apparatus of claim 79, wherein:

the receiving device is unable to obtain a PDCP SDU of the one or more PDCP SDUs; and

the report comprises a sequence number of the PDCP SDU based at least in part on the PDCP SDU having a lowest sequence number among a subset of one or more PDCP SDU that the receiving device is unable to obtain among the one or more PDCP SDUs.
The apparatus of claim 90, wherein the report further comprises a bitmap indicating, for each PDCP SDU among the one or more PDCP SDUs having a sequence number greater than the sequence number of the PDCP SDU, whether the receiving device was successful or unsuccessful in obtaining a respective PDCP SDU.
The apparatus of claim 79, wherein the report comprises an indication of a quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain a PDCP SDU.
The apparatus of claim 79, wherein the report comprises an indication of an average quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain each PDCP SDU of a set of PDCP SDUs.
A non-transitory computer-readable medium storing code for wireless communications at a transmitting device, the code comprising instructions executable by a processor to:

transmit, to one or more receiving devices, a set of packet data convergence protocol (PDCP) protocol data units (PDUs) corresponding to one or more PDCP service data units (SDUs) ;

determine that a polling condition at the transmitting device has been met;

set, based at least in part on determining that the polling condition has been met, a polling flag within a subsequent PDCP PDU;

transmit the subsequent PDCP PDU to the one or more receiving devices; and

monitor for a report from a receiving device of the one or more receiving devices based at least in part on transmitting the subsequent PDCP PDU, the report indicating a status of the transmitted set of PDCP PDUs or the one or more PDCP SDUs.
The non-transitory computer-readable medium of claim 94, wherein the instructions to determine that the polling condition has been met are executable to:

determine that a quantity of PDCP PDUs included in the set of PDCP PDUs satisfies a threshold.
The non-transitory computer-readable medium of claim 95, wherein the instructions are further executable to:

receive an indication of the threshold via radio resource control signaling.
The non-transitory computer-readable medium of claim 94, wherein the instructions to determine that the polling condition has been met are executable to:

determine that a quantity of data included in the set of PDCP PDUs satisfies a threshold.
The non-transitory computer-readable medium of claim 97, wherein the instructions are further executable to:

receive an indication of the threshold via radio resource control signaling.
The non-transitory computer-readable medium of claim 94, wherein the instructions are further executable to:

the instructions to initiate a timer based at least in part on transmitting a prior PDCP PDU that includes a prior polling flag, wherein determining that the polling condition has been met are executable by the processor to cause the apparatus to identify an expiration of the timer.
The non-transitory computer-readable medium of claim 99, wherein the instructions are further executable to:

receive an indication to enable or disable the timer via radio resource control signaling; and

enable or disabling the timer based at least in part on the indication.
The non-transitory computer-readable medium of claim 100, wherein the indication is an indication to disable the timer, and wherein the indication to disable the timer comprises an indication of an infinite duration for the timer.
The non-transitory computer-readable medium of claim 99, wherein the instructions are further executable to:

receive an indication of a duration for the timer via radio resource control signaling; and

configure the duration for the timer based at least in part on the indication.
The non-transitory computer-readable medium of claim 94, wherein the instructions are further executable to:

receive the report based at least in part on the monitoring, wherein the report comprises an indication of a quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain a PDCP SDU; and

adjust a code rate for encoding PDCP SDUs at the PDCP layer based at least in part on the indicated quantity of PDCP PDUs or PDCP sub-PDUs.
The non-transitory computer-readable medium of claim 103, wherein the report further comprises a bitmap indicating, for each PDCP SDU of the one or more PDCP SDUs having a sequence number greater than the indicated sequence number, whether the receiving device was successful or unsuccessful in obtaining a respective PDCP SDU.
The non-transitory computer-readable medium of claim 94, wherein the instructions are further executable to:

receive the report based at least in part on the monitoring, wherein the report comprises an indication of an average quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain each PDCP SDU of a set of PDCP SDUs; and

adjust a code rate for encoding PDCP SDUs at the PDCP layer based at least in part on the indicated average quantity of PDCP PDUs or PDCP sub-PDUs.
The non-transitory computer-readable medium of claim 94, wherein the instructions are further executable to:

receive the report based at least in part on the monitoring, wherein the report comprises an indication of a sequence number for a PDCP SDU of the one or more PDCP SDUs, the indication of the sequence number indicating that the receiving device was able to obtain each of the one or more PDCP SDUs having a sequence number lower than the indicated sequence number.
The non-transitory computer-readable medium of claim 94, wherein a header of the subsequent PDCP PDU includes the polling flag.
The non-transitory computer-readable medium of claim 94, wherein the instructions are further executable to:

receive the report based at least in part on the monitoring, wherein the report comprises an indication of a report type for the report, the indicated report type one of a plurality of report types; and

decode the report based on least in part on the indication of the report type for the report.
The non-transitory computer-readable medium of claim 108, wherein:

the report type is a first report type of the plurality of report types, the report comprising an indication of a sequence number for a PDCP SDU of the one or more PDCP SDUs, the indication of the sequence number indicating that the receiving device was able to obtain each of the one or more PDCP SDUs having a sequence number lower than the indicated sequence number;

the report type is a second report type of the plurality of report types, the report comprising the indication of the sequence number for the PDCP SDU of the one or more PDCP SDUs, and the report further comprising at least one of an indication of a quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain a PDCP SDU or an indication of an average quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain each PDCP SDU of a set of PDCP SDUs; or; and

the report type is a third report type of the plurality of report types, the report comprising the indication of the sequence number for the PDCP SDU of the one or more PDCP SDUs, the report further comprising at least one of the indication of a quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain a PDCP SDU or the indication of the average quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain each PDCP SDU of the set of PDCP SDUs, and the report further comprising a bitmap indicating, for each PDCP SDU of the one or more PDCP SDUs having a sequence number greater than the indicated sequence number, whether the receiving device was successful or unsuccessful in obtaining a respective PDCP SDU.
A non-transitory computer-readable medium storing code for wireless communications at a receiving device, the code comprising instructions executable by a processor to:

receive, at a packet data convergence protocol (PDCP) layer of the receiving device, a set of packet data convergence protocol (PDCP) protocol data units (PDUs) from a transmitting device, the set of PDPC PDUs corresponding to one or more PDCP service data units (SDUs) ;

generate, at the PDCP layer, a report indicating a status of the set of PDCP PDUs or the one or more PDCP SDUs at the receiving device; and

transmit the report to the transmitting device.
The non-transitory computer-readable medium of claim 110, wherein the instructions are further executable to:

receive, from the transmitting device after receiving the set of PDCP PDUs, a subsequent PDCP PDU that includes a polling flag, wherein generating the report is based at least in part on the polling flag.
The non-transitory computer-readable medium of claim 110, wherein the instructions are further executable to:

initiate a timer at the receiving device, wherein generating the report is based at least in part on an expiration of the timer.
The non-transitory computer-readable medium of claim 112, wherein the instructions are further executable to:

receive an indication to enable or disable the timer via radio resource control signaling; and

enable or disabling the timer based at least in part on the indication.
The non-transitory computer-readable medium of claim 113, wherein the indication is an indication to disable the timer, and wherein the indication to disable the timer comprises an indication of an infinite duration for the timer.
The non-transitory computer-readable medium of claim 112, wherein the instructions are further executable to:

receive an indication of a duration for the timer via radio resource control signaling; and

configure the duration for the timer based at least in part on the indication.
The non-transitory computer-readable medium of claim 112, wherein the instructions are further executable to:

receive a PDCP PDU of the set of PDCP PDUs at an empty buffer of the receiving device, wherein initiating the timer is based at least in part on receiving the PDU at the empty buffer.
The non-transitory computer-readable medium of claim 112, wherein the instructions are further executable to:

transmit, to the transmitting device before transmitting the report, a prior report indicating a status of a prior set of PDCP PDUs, wherein initiating the timer is based at least in part on transmitting the prior report.
The non-transitory computer-readable medium of claim 110, wherein the instructions are further executable to:

receive, via radio resource control signaling, an indication of a report type for the receiving device to use to indicate a status of PDCP PDUs at the receiving device, the indicated report type one of a plurality of report types, wherein the report is of the indicated report type.
The non-transitory computer-readable medium of claim 118, wherein the report indicates the report type to the transmitting device.
The non-transitory computer-readable medium of claim 118, wherein:

the report type is a first report type of the plurality of report types, the report comprising a sequence number of the PDCP SDU based at least in part on the PDCP SDU having a lowest sequence number among a subset of one or more PDCP SDU that the receiving device is unable to obtain among the one or more PDCP SDUs;

the report type is a second report type of the plurality of report types, the report comprising the sequence number of the PDCP SDU, and the report further comprising at least one of an indication of a quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain a PDCP SDU or an indication of an average quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain each PDCP SDU of a set of PDCP SDUs; or; and

the report type is a third report type of the plurality of report types, the report comprising the indication of the sequence number for the PDCP SDU of the one or more PDCP SDUs, the report further comprising at least one of the indication of the quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain the PDCP SDU or the indication of the average quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain each PDCP SDU of the set of PDCP SDUs, and the report further comprising a bitmap indicating, for each PDCP SDU among the one or more PDCP SDUs having a sequence number greater than the sequence number of the PDCP SDU, whether the receiving device was successful or unsuccessful in receiving a respective PDCP SDU.
The non-transitory computer-readable medium of claim 110, wherein:

the receiving device is unable to obtain a PDCP SDU of the one or more PDCP SDUs; and

the report comprises a sequence number of the PDCP SDU based at least in part on the PDCP SDU having a lowest sequence number among a subset of one or more PDCP SDU that the receiving device is unable to obtain among the one or more PDCP SDUs.
The non-transitory computer-readable medium of claim 121, wherein the report further comprises a bitmap indicating, for each PDCP SDU among the one or more PDCP SDUs having a sequence number greater than the sequence number of the PDCP SDU, whether the receiving device was successful or unsuccessful in obtaining a respective PDCP SDU.
The non-transitory computer-readable medium of claim 110, wherein the report comprises an indication of a quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain a PDCP SDU.
The non-transitory computer-readable medium of claim 110, wherein the report comprises an indication of an average quantity of PDCP PDUs or PDCP sub-PDUs used by the receiving device to obtain each PDCP SDU of a set of PDCP SDUs.