WO2022016488A1 - Rateless coding at a packet data convergence protocol layer - Google Patents

Rateless coding at a packet data convergence protocol layer Download PDF

Info

Publication number
WO2022016488A1
WO2022016488A1 PCT/CN2020/104027 CN2020104027W WO2022016488A1 WO 2022016488 A1 WO2022016488 A1 WO 2022016488A1 CN 2020104027 W CN2020104027 W CN 2020104027W WO 2022016488 A1 WO2022016488 A1 WO 2022016488A1
Authority
WO
WIPO (PCT)
Prior art keywords
pdcp
pdus
pdu
encoded
sdu
Prior art date
Application number
PCT/CN2020/104027
Other languages
French (fr)
Inventor
Ruiming Zheng
Changlong Xu
Jian Li
Kangqi LIU
Liangming WU
Peng Cheng
Hao Xu
Original Assignee
Qualcomm Incorporated
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Incorporated filed Critical Qualcomm Incorporated
Priority to PCT/CN2020/104027 priority Critical patent/WO2022016488A1/en
Priority to US18/004,648 priority patent/US20230269026A1/en
Priority to CN202180060285.6A priority patent/CN116097592A/en
Priority to EP21847381.7A priority patent/EP4186306A1/en
Priority to PCT/CN2021/108240 priority patent/WO2022017517A1/en
Priority to CN202180060229.2A priority patent/CN116261834A/en
Priority to EP21845745.5A priority patent/EP4186191A1/en
Priority to PCT/CN2021/108260 priority patent/WO2022017521A1/en
Priority to US18/004,652 priority patent/US20230283411A1/en
Publication of WO2022016488A1 publication Critical patent/WO2022016488A1/en

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/06Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H04W28/065Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information using assembly or disassembly of packets
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/004Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0041Arrangements at the transmitter end
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/004Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0045Arrangements at the receiver end
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/004Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0075Transmission of coding parameters to receiver
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/004Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0076Distributed coding, e.g. network coding, involving channel coding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607Details of the supervisory signal
    • H04L1/1671Details of the supervisory signal the supervisory signal being transmitted together with control information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607Details of the supervisory signal
    • H04L1/1614Details of the supervisory signal using bitmaps
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607Details of the supervisory signal
    • H04L1/1642Formats specially adapted for sequence numbers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867Arrangements specially adapted for the transmitter end
    • H04L1/1874Buffer management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/324Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC

Definitions

  • the following relates to wireless communications, including rateless coding at a packet data convergence protocol layer.
  • 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.
  • 4G systems such as Long Term Evolution (LTE) systems, LTE-Advanced (LTE-A) systems, or LTE-A Pro systems
  • 5G systems which may be referred to as New Radio (NR) systems.
  • 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) .
  • UE user equipment
  • a PDCU service data unit may be segmented into one or more PDCP packet data units (PDUs) , and the PDCP PDUs may be encoded using a rateless code (e.g., a network code, outer code, etc. ) .
  • a transmitting device e.g., a user equipment (UE) and/or base station performing a transmission
  • the set of PDCP SDUs may correspond to a payload of data (e.g., packets) for transmission to receiving device (s) (e.g., a UE (s) and/or base station (s) receiving the transmission) .
  • the transmitting device may use the rateless code to encode a PDCP SDU to generate, create, obtain, etc., a set of encoded PDCP PDUs, including source PDCP PDUs and parity PDCP PDUs.
  • the set of encoded PDCP PDUs are then passed down to one or more lower layer (s) for transmission to the receiving devices.
  • the receiving device may receive the transmission and provide the set of encoded PDCP PDUs to the PDCP layer for decoding.
  • the receiving device may decode the set of encoded PDCP PDUs to obtain a PDCP SDU.
  • the receiving device may receive a threshold quantity of PDCP PDUs of a PDCP SDU (e.g., source PDUs and parity PDUs) , rearrange/reassemble the PDCP PDUs, and then use the rateless code to decode the set of encoded PDCP PDUs to obtain the corresponding PDCP SDU.
  • the PDCP SDU (e.g., obtained based on decoding using the rateless code) may be passed or otherwise provided to integrity protection and ciphering then an upper layer of the receiving device for further processing/recovery of the PDCP SDU.
  • a method for wireless communication at a transmitting device may include segmenting a PDCP SDU into a set of PDCP PDUs at a PDCP layer of the transmitting device, encoding, at the PDCP layer, the set of PDCP PDUs according to one or more network coding parameters to obtain a set of encoded PDCP PDUs, the one or more network coding parameters including a rateless code, generating, for the set of encoded PDCP PDUs, a corresponding set of PDU headers, and outputting the set of encoded PDCP PDUs and the corresponding set of PDU headers from the PDCP layer to a lower layer of the transmitting device for transmission to one or more receiving devices.
  • the apparatus may include a processor, memory in electronic communication with the processor, and instructions stored in the memory.
  • the instructions may be executable by the processor to cause the apparatus to segment a PDCP SDU into a set of PDCP PDUs at a PDCP layer of the transmitting device, encode, at the PDCP layer, the set of PDCP PDUs according to one or more network coding parameters to obtain a set of encoded PDCP PDUs, the one or more network coding parameters including a rateless code, generate, for the set of encoded PDCP PDUs, a corresponding set of PDU headers, and output the set of encoded PDCP PDUs and the corresponding set of PDU headers from the PDCP layer to a lower layer of the transmitting device for transmission to one or more receiving devices.
  • the apparatus may include means for segmenting a PDCP SDU into a set of PDCP PDUs at a PDCP layer of the transmitting device, means for encoding, at the PDCP layer, the set of PDCP PDUs according to one or more network coding parameters to obtain a set of encoded PDCP PDUs, the one or more network coding parameters including a rateless code, means for generating, for the set of encoded PDCP PDUs, a corresponding set of PDU headers, and means for outputting the set of encoded PDCP PDUs and the corresponding set of PDU headers from the PDCP layer to a lower layer of the transmitting device for transmission to one or more receiving devices.
  • a non-transitory computer-readable medium storing code for wireless communication at a transmitting device is described.
  • the code may include instructions executable by a processor to segment a PDCP SDU into a set of PDCP PDUs at a PDCP layer of the transmitting device, encode, at the PDCP layer, the set of PDCP PDUs according to one or more network coding parameters to obtain a set of encoded PDCP PDUs, the one or more network coding parameters including a rateless code, generate, for the set of encoded PDCP PDUs, a corresponding set of PDU headers, and output the set of encoded PDCP PDUs and the corresponding set of PDU headers from the PDCP layer to a lower layer of the transmitting device for transmission to one or more receiving devices.
  • Some examples of the method, apparatuses, and non-transitory computer-readable medium described herein may further include operations, features, means, or instructions for performing, at the PDCP layer and before the encoding, an integrity protection and ciphering function on the PDCP SDU.
  • the set of PDCP PDUs includes a set of source PDCP PDUs
  • encoding the set of PDCP PDUs may include operations, features, means, or instructions for encoding the set of source PDCP PDUs to obtain a set of encoded source PDCP PDUs and a set of encoded parity PDCP PDUs.
  • generating the set of PDU headers may include operations, features, means, or instructions for setting, within each PDU header of the set of PDU headers, a field indicating an index for an associated encoded PDCP PDU corresponding to the PDCP SDU, where the index corresponds to an ordering for the set of encoded PDUs.
  • generating the set of PDU headers may include operations, features, means, or instructions for setting, within a PDU header of the set of PDU headers, a flag indicating that an associated encoded PDCP PDU may be a last encoded PDCP PDU of the set of encoded PDUs corresponding to the PDCP SDU.
  • generating the set of PDU headers may include operations, features, means, or instructions for setting, within each PDU header of the set of PDU headers, a repair field indicating whether an associated encoded PDCP PDU may be a repaired PDCP PDU.
  • the one or more network coding parameters include a minimum code rate for the set of encoded PDCP PDUs, and where a quantity of encoded PDCP PDUs included in the set of encoded PDCP PDUs may be based on the minimum code rate.
  • 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 minimum code rate for the set of encoded PDCP PDUs via radio resource control signaling.
  • Some examples of the method, apparatuses, and non-transitory computer-readable medium described herein may further include operations, features, means, or instructions for storing the PDCP SDU or the set of encoded PDCP PDUs in a retransmission buffer implemented at the PDCP layer.
  • 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 a receiving device of the one or more receiving devices, feedback for the set of encoded PDCP PDUs indicating that the receiving device was unable to obtain the 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 retrieving, based on the feedback, the set of encoded PDCP PDUs from a retransmission buffer implemented at the PDCP layer, and retransmitting the set of encoded PDCP PDUs to the one or more receiving devices based on the retrieving.
  • Some examples of the method, apparatuses, and non-transitory computer-readable medium described herein may further include operations, features, means, or instructions for retrieving, based on the feedback, the PDCP SDU from a retransmission buffer implemented at the PDCP layer, encoding the set of PDCP PDUs according to the one or more network coding parameters to obtain a set of re-encoded PDCP PDUs based on the retrieving, and transmitting the set of re-encoded PDCP PDUs to the one or more receiving devices.
  • 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 a receiving device of the one or more receiving devices, feedback for the set of encoded PDCP PDUs indicating that the receiving device was able to obtain the 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, from the receiving device, an indication of a quantity of encoded PDCP PDUs used by the receiving device to obtain the PDCP SDU, and adjusting a code rate of the one or more network coding parameters based on the indicated quantity of encoded PDCP PDUs.
  • Some examples of the method, apparatuses, and non-transitory computer-readable medium described herein may further include operations, features, means, or instructions for configuring a radio link control layer at the transmitting device to operate a transparent mode or an unacknowledged mode, where the encoding at the PDCP layer may be based on the configuring.
  • a method for wireless communication at a receiving device may include receiving, at a PDCP layer of the receiving device, a set of PDCP PDUs and a corresponding set of PDCP PDU headers from a transmitting device, the set of PDCP PDUs and the corresponding set of PDCP PDU headers corresponding to a PDCP SDU, decoding, at the PDCP layer, at least a subset of the set of PDCP PDUs based on one or more network coding parameters and the corresponding set of PDCP PDU headers, the one or more network coding parameters including a rateless code, generating a report based on the decoding, where the report indicates whether the PDCP SDU was obtained from the set of PDCP PDUs, and transmitting the report to the transmitting device.
  • the apparatus may include a processor, memory in electronic communication 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 PDCP layer of the receiving device, a set of PDCP PDUs and a corresponding set of PDCP PDU headers from a transmitting device, the set of PDCP PDUs and the corresponding set of PDCP PDU headers corresponding to a PDCP SDU, decode, at the PDCP layer, at least a subset of the set of PDCP PDUs based on one or more network coding parameters and the corresponding set of PDCP PDU headers, the one or more network coding parameters including a rateless code, generate a report based on the decoding, where the report indicates whether the PDCP SDU was obtained from the set of PDCP PDUs, and transmit the report to the transmitting device.
  • the apparatus may include means for receiving, at a PDCP layer of the receiving device, a set of PDCP PDUs and a corresponding set of PDCP PDU headers from a transmitting device, the set of PDCP PDUs and the corresponding set of PDCP PDU headers corresponding to a PDCP SDU, means for decoding, at the PDCP layer, at least a subset of the set of PDCP PDUs based on one or more network coding parameters and the corresponding set of PDCP PDU headers, the one or more network coding parameters including a rateless code, means for generating a report based on the decoding, where the report indicates whether the PDCP SDU was obtained from the set of PDCP PDUs, and means for transmitting the report to the transmitting device.
  • a non-transitory computer-readable medium storing code for wireless communication at a receiving device is described.
  • the code may include instructions executable by a processor to receive, at a PDCP layer of the receiving device, a set of PDCP PDUs and a corresponding set of PDCP PDU headers from a transmitting device, the set of PDCP PDUs and the corresponding set of PDCP PDU headers corresponding to a PDCP SDU, decode, at the PDCP layer, at least a subset of the set of PDCP PDUs based on one or more network coding parameters and the corresponding set of PDCP PDU headers, the one or more network coding parameters including a rateless code, generate a report based on the decoding, where the report indicates whether the PDCP SDU was obtained from the set of PDCP PDUs, 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 performing, at the PDCP layer after decoding at least the subset of the set of PDCP PDUs and obtaining the PDCP SDU, an integrity verification and deciphering function on the 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 determining that at least a minimum quantity of PDCP PDUs of the set of PDCP PDUs may have been received, where the decoding may be based on determining that at least the minimum quantity of PDCP PDUs may have been received.
  • 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 minimum quantity of PDCP PDUs in the set of PDCP PDUs via radio resource control signaling.
  • Some examples of the method, apparatuses, and non-transitory computer-readable medium described herein may further include operations, features, means, or instructions for obtaining the PDCP SDU from the subset of the set of PDCP PDUs, and refraining from decoding a remaining subset of the set of PDCP PDUs based on obtaining the 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 indicating, to the transmitting device, a quantity of PDCP PDUs used by the receiving device to obtain the 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 determining that the PDCP SDU cannot be obtained from the set of PDCP PDUs, where the report indicates that the receiving device was unable to obtain the 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 monitoring for a retransmission of the set of PDCP PDUs based on transmitting the report.
  • the determining may be based on receiving all PDCP PDUs of the set of PDCP PDUs.
  • the PDCP SDU may be included in a set of PDCP SDUs, the receiving device may be unable to obtain one or more PDCP SDUs in the set of PDCP SDUs, and the report includes a sequence number of the PDCP SDU based on the PDCP SDU having a lowest sequence number among the one or more PDCP SDUs that the receiving device may be unable to obtain.
  • the report further includes a bitmap indicating, for each PDCP SDU in a set of PDCP SDUs having a sequence number greater than the sequence number of the PDCP SDU, whether the receiving device was able to successfully obtain or was not able to obtain 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 identifying, within each PDU header of the set of PDU headers, a field indicating an index for an associated PDCP PDU corresponding to the PDCP SDU, where the set of PDCP PDUs may be decoded based on an ordering corresponding to the index.
  • Some examples of the method, apparatuses, and non-transitory computer-readable medium described herein may further include operations, features, means, or instructions for identifying, within a PDU header of the set of PDU headers, a flag indicating that an associated PDCP PDU may be a last PDCP PDU of the set of PDCP PDUs corresponding to the 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 identifying, within each PDU header of the set of PDU headers, a repair field indicating whether an associated PDCP PDU may be a repaired PDCP PDU.
  • Some examples of the method, apparatuses, and non-transitory computer-readable medium described herein may further include operations, features, means, or instructions for configuring a radio link control layer at the receiving device for a transparent mode or an unacknowledged mode, where the decoding at the PDCP layer may be based on the configuring.
  • receiving the set of PDCP PDUs may include operations, features, means, or instructions for receiving a set of source PDCP PDUs and a set of parity PDCP PDUs.
  • FIG. 1 illustrates an example of a system for wireless communications that supports rateless coding at a packet data convergence protocol (PDCP) layer in accordance with aspects of the present disclosure.
  • PDCP packet data convergence protocol
  • FIG. 2 illustrates an example of a PDCP entity that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure.
  • FIG. 3 illustrates an example of a PDCP configuration that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure.
  • FIG. 4 illustrates an example of a PDCP protocol data unit (PDU) format that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure.
  • PDU protocol data unit
  • FIG. 5 illustrates an example of a PDCP PDU format that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure.
  • FIG. 6 illustrates an example of a PDCP configuration that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure.
  • FIGs. 7 and 8 show block diagrams of devices that support rateless coding at a PDCP layer in accordance with aspects of the present disclosure.
  • FIG. 9 shows a block diagram of a communication manager that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure.
  • FIG. 10 shows a diagram of a system including a user equipment (UE) that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure.
  • UE user equipment
  • FIG. 11 shows a diagram of a system including a base station that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure.
  • FIGs. 12 through 17 show flowcharts illustrating methods that support rateless coding at a PDCP layer in accordance with aspects of the present disclosure.
  • Wireless communication systems may utilize fountain codes, which are rateless codes in the sense that the number of coded packets is potentially limitless.
  • 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.
  • 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) .
  • MBMS multimedia broadcast multi-cast service
  • IAB integrated access and backhaul
  • V2X vehicle-to-everything
  • each coded symbol would either be decoded correctly or discarded.
  • application of such rateless codes at the network layer may add latency to communications as data must be passed from the network layer to other layers within the protocol stack for additional processing/packaging before transmissions, and then make its way back up the protocol stack back to the network layer for final processing/recovery of the data. This process at the transmitting and receiving side may result in intolerable traffic delays for the data being communicated within the wireless network.
  • layer 2 (L2) retransmission may not be supported for at least some types of transmissions (e.g., single-point to multi-point, multi-cast, broadcast, etc. ) , which may negatively impact reliability. Extending the maximum number retransmissions in a lower layer, however, (e.g., using HARQ techniques) may be inefficient and result in a potentially long latency. And employing a 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 introduce undesired complexities, latencies, or inefficiencies if used to correct residual errors of lower layers. For example, the use of RLC AM technique may require unicast retransmission and thus may be undesirable for use in a broadcast system where data is initially broadcast.
  • AM window-based RLC acknowledgment mode
  • rateless codes e.g., fountain codes
  • PDCP packet data convergence protocol
  • SDUs PDCP service data units
  • a transmitting device may receive a set of PDCP SDUs at the PDCP layer.
  • the set of PDCP SDUs may correspond to a payload of data (e.g., packets) for transmission to receiving device (s) (e.g., a UE (s) and/or base station (s) receiving the transmission) .
  • receiving device e.g., a UE (s) and/or base station (s) receiving the transmission
  • the transmitting device may use the rateless code to segment a PDCP SDU into multiple source PDCP protocol data units (PDUs) and encode the set of PDCP PDUs to generate, create, obtain, etc., a set of encoded PDCP PDUs, including the source PDCP PDUs and a set of parity PDCP PDUs.
  • the set of encoded PDCP PDUs may then be passed down to the lower layer (s) for transmission to the receiving devices.
  • the receiving device may receive the transmission and provide the set of encoded PDCP PDUs to the PDCP layer for decoding.
  • the receiving device may decode a set of encoded PDCP PDUs to obtain a PDCP SDU.
  • the receiving device may receive a threshold quantity of PDCP PDUs of a PDCP SDU (e.g., source PDCP PDUs and parity PDCP PDUs) , rearrange/reassemble the PDCP PDUs, and then use the rateless code to decode the set of encoded PDCP PDUs to obtain the corresponding PDCP SDU.
  • the PDCP SDU (e.g., obtained based on decoding using the rateless code) may be passed or otherwise provided to an upper layer of the receiving device for further processing/recovery of the PDCP SDU.
  • aspects of the disclosure are initially described in the context of wireless communications systems. Aspects of the disclosure are further illustrated by and described with reference to apparatus diagrams, system diagrams, and flowcharts that relate to rateless coding at a PDCP layer.
  • FIG. 1 illustrates an example of a wireless communications system 100 that supports rateless coding at a PDCP layer 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.
  • 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.
  • LTE Long Term Evolution
  • LTE-A LTE-Advanced
  • LTE-A Pro LTE-A Pro
  • NR New Radio
  • 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.
  • ultra-reliable e.g., mission critical
  • 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.
  • network equipment e.g., core network nodes, relay devices, integrated access and backhaul (IAB) nodes, or other network equipment
  • the base stations 105 may communicate with the core network 130, or with one another, or both.
  • 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.
  • 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 base transceiver station a radio base station
  • an access point a radio transceiver
  • a NodeB an eNodeB (eNB)
  • eNB eNodeB
  • a next-generation NodeB or a giga-NodeB either of which may be referred to as a gNB
  • gNB giga-NodeB
  • 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.
  • PDA personal digital assistant
  • 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.
  • WLL wireless local loop
  • IoT Internet of Things
  • IoE Internet of Everything
  • MTC machine type communications
  • 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.
  • 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.
  • 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) .
  • BWP bandwidth part
  • 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.
  • FDD frequency division duplexing
  • TDD time division duplexing
  • 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.
  • E-UTRA evolved universal mobile telecommunication system terrestrial radio access
  • 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.
  • 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
  • the wireless communications system 100 may include base stations 105 or UEs 115 that support simultaneous communications via carriers associated with multiple carrier bandwidths.
  • 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) ) .
  • MCM multi-carrier modulation
  • OFDM orthogonal frequency division multiplexing
  • DFT-S-OFDM discrete Fourier transform spread OFDM
  • 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) .
  • 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.
  • a UE 115 may be configured with multiple BWPs.
  • 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.
  • 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) .
  • SFN system frame number
  • Each frame may include multiple consecutively numbered subframes or slots, and each subframe or slot may have the same duration.
  • 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.
  • 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) .
  • 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) .
  • TTI duration e.g., the number of symbol periods in a TTI
  • 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)
  • CORESET control resource set
  • a control region 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.
  • 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) .
  • 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.
  • 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.
  • 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.
  • protocol types e.g., MTC, narrowband IoT (NB-IoT) , enhanced mobile broadband (eMBB)
  • NB-IoT narrowband IoT
  • eMBB enhanced mobile broadband
  • a base station 105 may be movable and therefore provide communication coverage for a moving geographic coverage area 110.
  • 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.
  • 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.
  • the base stations 105 may have similar frame timings, and transmissions from different base stations 105 may be approximately aligned in time.
  • 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 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.
  • 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) .
  • 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.
  • 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.
  • 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.
  • 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) .
  • MCPTT mission critical push-to-talk
  • MCVideo mission critical video
  • MCData mission critical data
  • 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.
  • 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) .
  • D2D device-to-device
  • P2P peer-to-peer
  • 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.
  • 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.
  • 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.
  • 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) .
  • vehicles may communicate using vehicle-to-everything (V2X) communications, vehicle-to-vehicle (V2V) communications, or some combination of these.
  • V2X vehicle-to-everything
  • V2V vehicle-to-vehicle
  • a vehicle may signal information related to traffic conditions, signal scheduling, weather, safety, emergencies, or any other information relevant to a V2X system.
  • 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.
  • V2N vehicle-to-network
  • 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) ) .
  • EPC evolved packet core
  • 5GC 5G core
  • MME mobility management entity
  • AMF access and mobility management function
  • S-GW serving gateway
  • PDN Packet Data Network gateway
  • UPF user plane function
  • 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.
  • NAS non-access stratum
  • 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 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.
  • 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) .
  • 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.
  • 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.
  • HF high frequency
  • VHF very high frequency
  • 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.
  • SHF super high frequency
  • EHF extremely high frequency
  • 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.
  • mmW millimeter wave
  • the propagation of EHF transmissions 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.
  • 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.
  • LAA License Assisted Access
  • LTE-U LTE-Unlicensed
  • NR NR technology
  • an unlicensed band such as the 5 GHz industrial, scientific, and medical (ISM) band.
  • devices such as the base stations 105 and the UEs 115 may employ carrier sensing for collision detection and avoidance.
  • 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.
  • one or more base station antennas or antenna arrays may be co-located at an antenna assembly, such as an antenna tower.
  • 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.
  • a UE 115 may have one or more antenna arrays that may support various MIMO or beamforming operations.
  • 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.
  • SU-MIMO single-user MIMO
  • 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.
  • 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
  • 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 layer transmission or reception by the base station 105.
  • a transmitting device such as a base station 105
  • a receiving device such as a UE 115
  • Some signals 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) .
  • 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.
  • 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.
  • transmissions by a device 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.
  • a reference signal e.g., a cell-specific reference signal (CRS) , a channel state information reference signal (CSI-RS)
  • CRS cell-specific reference signal
  • CSI-RS channel state information reference signal
  • 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) .
  • PMI precoding matrix indicator
  • codebook-based feedback e.g., a multi-panel type codebook, a linear combination type codebook, a port selection type codebook
  • 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 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.
  • receive configurations e.g., directional listening
  • 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.
  • receive beamforming weight sets e.g., different directional listening weight sets
  • 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) .
  • SNR signal-to-noise ratio
  • the UEs 115 and the base stations 105 may support retransmissions of data to increase the likelihood that data is received successfully.
  • Hybrid automatic repeat request (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., automatic repeat request (ARQ) ) .
  • FEC forward error correction
  • ARQ automatic repeat request
  • HARQ may improve throughput at the MAC layer in poor radio conditions (e.g., low signal-to-noise conditions) .
  • 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.
  • 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 multiple-access systems capable of supporting communication with multiple users by sharing the available system resources (e.g., time, frequency, and power) .
  • a wireless network for example a wireless local area network (WLAN) , such as a Wi-Fi (i.e., Institute of Electrical and Electronics Engineers (IEEE) 802.11) network may include an access point (AP) that may communicate with one or more wireless or mobile devices.
  • the AP may be coupled to a network, such as the Internet, and may enable a mobile device to communicate via the network (or communicate with other devices coupled to the access point) .
  • a wireless device may communicate with a network device bi-directionally.
  • a device may communicate with an associated AP via downlink (e.g., the communication link from the AP to the device) and uplink (e.g., the communication link from the device to the AP) .
  • a wireless personal area network which may include a Bluetooth connection, may provide for short range wireless connections between two or more paired wireless devices.
  • wireless devices such as cellular phones may utilize wireless PAN communications to exchange information such as audio signals with wireless headsets.
  • the wireless communications system 100 may be a packet-based network that operates according to a layered protocol stack.
  • 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.
  • RLC Radio Link Control
  • 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.
  • 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.
  • RRC Radio Resource Control
  • transport channels may be mapped to physical channels.
  • a transmitting device may receive, at a PDCP layer of the transmitting device, a set of PDCP SDUs corresponding to a payload of data for transmission to one or more receiving devices.
  • the transmitting device may encode, at the PDCP layer, the set of PDCP SDUs according to a set of network coding parameters to obtain a set of encoded PDCP PDUs, the network coding parameters comprising at least a rateless code.
  • the transmitting device may provide the set of encoded PDCP PDUs to a lower layer of the transmitting device for transmission to the one or more receiving devices (e.g., one or more other UE (s) 115 and/or base station (s) 105 receiving the transmission) .
  • the one or more receiving devices e.g., one or more other UE (s) 115 and/or base station (s) 105 receiving the transmission.
  • a receiving device may receive, at a PDCP layer of the receiving device, a set of encoded PDCP PDUs from a transmitting device.
  • the receiving device may decode, at the PDCP layer, the set of encoded PDCP PDUs according to a set of network coding parameters to obtain a set of PDCP SDUs corresponding to a payload of data, the set of network coding parameters comprising at least a rateless code.
  • the receiving device may provide the set of PDCP SDUs to an upper layer of receiving device, the upper layer being a higher layer than the PDCP layer of the receiving device.
  • FIG. 2 illustrates an example of a PDCP entity 200 that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure.
  • the PDCP entity 200 may implement aspects of wireless communication system 100.
  • PDCP entity 200 may include a PDCP entity 205 comprising transmitting PDCP entity 210 at a transmitting device and receiving PDCP entity 215 at a receiving device.
  • the transmitting device and/or receiving device may be examples of a UE and/or base station as described herein.
  • 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.
  • 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.
  • such wireless transmissions may be performed by the base station 105 to another base station 105 (e.g., in an IAB network) and/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) .
  • a transmitting device e.g., a UE and/or a base station performing a transmission to other UE (s) and/or base station (s)
  • the physical layer may also be referred to as layer 1 (L1) .
  • 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.
  • the PDCP layer transfers user plane/control plane data, provides PDCP sequence number (SN) maintenance, ciphering/integrity protection, bearer routing, etc.
  • L3 within the protocol stack is also referred to as the network layer, application layer, etc.
  • 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) .
  • PDCP entity 205 is established between a transmitting device (e.g., transmitting PDCP entity 210) and a receiving device (e.g., receiving PDCP entity 215) to support wireless communications.
  • MAC layers e.g., a MAC entity
  • RLC layers e.g., an RLC entity
  • a payload of data for transmission to the receiving device (s) from an upper layer 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.
  • a payload of data for transmission to a receiving device 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.
  • SDAP service data adaptation protocol
  • 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.
  • 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.
  • a SDU refers to input data received at one layer from an upper layer for processing.
  • 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.
  • a PDU specifies the data that will be sent to the peer protocol layer (e.g., a PCDP PDU from the transmitting PDCP entity 210) to the receiving device (s) (e.g., a PDCP PDU provided to receiving PDCP entity 215) .
  • Some wireless communication systems 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
  • Wireless communication systems may utilize fountain codes, which are rateless codes in that the number of encoded packets to be transmitted is potentially limitless.
  • 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.
  • 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) .
  • 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) and/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) .
  • 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.
  • fountain codes are rateless codes with an unlimited number of columns in the original generator matrix generated by the transmitting device.
  • 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:
  • 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.
  • the SDAP provides quality of service (QoS) mapping and flow identifier (ID) and does not impact packet processing.
  • QoS quality of service
  • ID flow identifier
  • the RLC layer works under transparent mode (TM) or unacknowledgement mode (UM) without providing ARQ functionality.
  • Rateless/network coding techniques may support recovery of missing packets in a multi-cast/broadcast system.
  • the PDCP layer 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.
  • 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.
  • a lower layer e.g., the RLC layer
  • the PDCP layer may encode the set of PDCP SDUs using network coding parameters (e.g., a rateless code) .
  • network coding parameters e.g., a rateless code
  • encoding of the PDCP SDUs at the PDCP layer may be performed after integrity protection, ciphering, and the like.
  • the set of PDCP SDUs may be received in transmission buffer 220. 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.
  • TX_NEXT next transmission field
  • the packets may be provided to header compression 225 for processing, e.g., to perform header compression of the PDCP SDU.
  • header compression 225 may modify the header of the PDCP SDU for efficiency.
  • header compression 225 may not be applied for non-PDCP SDU packets (e.g., control plane packets, such as RRC/non-access stratum (NAS) messages) .
  • header compression 225 may be applied to PDCP SDU packets (e.g., user plane packets, such as the packets corresponding to the payload of data) .
  • header compression 225 may be applied to user plane packets, although this may be skipped in some scenarios.
  • the PDCP SDU packets may leave header compression 225 and be processed by integrity protection (IP) 230 and ciphering 235 functions before being provided for header addition 245 and routing/duplication 250 for final processing before being provided to lower layers for transmission.
  • Header addition 245 adds the PDCP header to the PDCP SDU and routing/duplication 250 routes the packet to the intended bearer, if applicable.
  • encoder 240 may be enabled, configured, implemented, or otherwise provided, at the PDCP layer of the packet before integrity protection/ciphering functions.
  • the encoder 240 may encode a PDCP SDU of the set of PDCP SDUs to create, define, or otherwise obtain a corresponding set of encoded PDCP PDUs.
  • the PDCP SDUs may be PDCP PDUs from the perspective of receiving PDCP entity 215 after routing/duplication 250 processing.
  • the transmitting PDCP entity 210 e.g., the PDCP layer in this example
  • aspects of the described techniques permit, after integrity protection 230 and ciphering 235 functionality, the PDCP data PDU (e.g., the PDCP SDU) being encoded using network coding, rateless coding, etc.
  • the encoded PDCP PDU using rateless coding may also be referred to as a coded PDCP SDU.
  • the encoder 240 may segment the PDCP SDU into one or more PDCP PDUs, in some cases referred to as source PDCP PDUs.
  • the encoder 240 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.
  • the transmitting device may store the encoded set of PDCP PDUs in a retransmission buffer 290.
  • 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 245 discussed above, where a PDCP header is added to each encoded PDCP PDU and then provided to routing/duplication 250 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.
  • 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.
  • 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.
  • 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.
  • a PDCP PDU header may include a T field, which may indicate whether the attached PDCP data PDU is a repaired PDU or not.
  • 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) .
  • a set of source symbols or packets, such as SDUs or PDUs
  • a rateless code 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.
  • 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 or a given set of source symbols, at the cost of extra signaling or other overhead) .
  • any quantity of corresponding 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.
  • the network may configure a minimum code rate for the source PDCP data PDU (e.g., using the PDCP-Config field in RRC signaling) .
  • 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.
  • 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) .
  • a PDCP status PDU e.g., a status report indicating HARQ information, or a more simple report
  • 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 215.
  • a field e.g., NumPDU
  • the PDCP status PDU e.g., the report
  • the code rate of the encoding using the rateless code may be adjusted based on the status report.
  • the encoding process for each encoding symbol may include the transmitting device (e.g., encoding 240) 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.
  • the transmitting device e.g., encoding 240
  • XOR exclusive or
  • 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 215.
  • 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 255 for removal the PDCP header.
  • 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 255.
  • the PDCP SDU may be decoded at decoder 260 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 260 may decode the PDCP SDU and deliver this to the deciphering 265.
  • 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) .
  • the one or more network coding parameters can include, additionally to other parameters described elsewhere herein, the minimum number of PDCP data PDUs.
  • the network may configure the minimum number of PDCP data PDUs.
  • 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 265, integrity verification 270, and reception buffer 275 for processing.
  • deciphering 265 may decipher the PDCP SDU
  • integrity verification 270 may verify the integrity of the PDCP SDU
  • reception buffer 275 may store the PDCP SDU.
  • Reception buffer 275 may provide the PDCP SDU to header compression 280, which then provides the PDCP SDU to an upper layer of the receiving device higher than the PDCP layer (e.g., an RRC layer) .
  • non-PDCP SDU packets e.g., control plane packets
  • aspects of the described techniques may also provide HARQ functionality at the PDCP layer.
  • the receiving device may determine that the PDCP SDU is unable to be successfully received and decoded.
  • PDCP status PDU 285 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.
  • 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) .
  • 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.
  • 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 290 of the transmitting PDCP entity 210 may monitor for and receive the status report from PDCP status PDU 285 (e.g., the status report may be transmitted over the radio interface) and use this information to provide some degree of HARQ functionality.
  • retransmission buffer 290 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.
  • the retransmission buffer 290 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 240 may encode the PDCP SDU as a repair PDCP SDU based on the negative acknowledgment.
  • the RLC layer typically sets below (e.g., is a lower layer) the PDCP layer.
  • the RLC layer may operate in UM/TM.
  • the RLC layer may provide segmentation of the PDCP SDU for the transmitting device and/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.
  • the RLC layer may provide transparent transmissions (e.g., neither SDU segmentation nor ARQ functionality) .
  • segmentation/re-segmentation may be implemented at the MAC layer, e.g., a MAC SDU can be segmented based on a grant of resource.
  • the PDCP layer may provide security, outer coding based ARQ, and in-order delivery of the PDCP PDUs.
  • FIG. 3 illustrates an example of a PDCP configuration 300 that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure.
  • the PDCP configuration 300 may implement aspects of wireless communication system 100.
  • a transmitting device may identify a PDCP SDU 305 for transmission to one or more receiving devices and prepare the PDCP SDU 305 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 305 with integrity protection and ciphering.
  • the transmitting device may segment the PDCP SDU 305 into a set of source PDCP PDUs 310. For example, the transmitting device may segment the PDCP SDU 305 into source PDCP PDU 310-a through 310-m. In some cases, the transmitting device may be configured with a size or number of source PDCP PDUs 310 to segment the PDCP SDU into.
  • the transmitting device may encode the set of source PDCP PDUs 310 according to a set of network coding parameters. In some cases, encoding the source PDCP PDUs 310 according to the set of network coding parameters may generate a set of parity PDCP PDUs 315.
  • 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.
  • the code rate may be pre-configured at the transmitting device.
  • the transmitting device may generate a quantity of encoded source PDUs 310 and encoded parity PDCP PDUs 315, where the combined quantity of encoded source PDUs 310 and encoded parity PDCP PDUs 315 (e.g., the total quantity of encoded PDUs in the set of encoded PDCP PDUs) relative to the quantity of segmented source PDUs 310 is based on (e.g., equal to) the code rate.
  • the transmitting device may generate N parity PDCP PDUs 315 to achieve the code rate, from parity PDCP PDU 315-a to parity PDCP PDU 315-n. Therefore, the transmitting device may generate a set of encoded PDCP PDUs, including the source PDCP PDUs 310 and the parity PDCP PDUs 315.
  • 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 the minimum number of encoded parity PDCP PDUs 315, or other parameters described elsewhere herein.
  • the transmitting device may encode the source PDCP PDUs 310 to generate encoded PDCP PDUs 310 and encoded parity PDCP PDUs 315 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.
  • 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 320 for the set of encoded PDCP PDUs.
  • Each PDCP PDU of the set of encoded PDCP PDUs (e.g., including source PDCP PDUs 310 and parity PDCP PDUs 315) may have a PDU header prepended.
  • the PDU header 320 may be an example of a PDU header 405 or a PDU header 505 described with reference to FIGs. 4 and 5, respectively.
  • the PDU header 320 may, in some cases, include fields or parameters related to the network coding.
  • 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.
  • FIG. 4 illustrates an example of a PDCP PDU format 400 that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure.
  • PDCP PDU format 400 may implement aspects of wireless communication system 100.
  • PDCP PDU format 400 may include an example of a PDU header 405 which may be added to network coded PDCP PDUs.
  • the PDU header 405 may be prepended to a source PDCP PDUs and parity PDCP PDUs corresponding to a PDCP SDU.
  • the PDCP PDU format 400 may be an example of a PDU header 405 with a 12-bit PDCP sequence number.
  • the PDU header 405 may include, for example, 4 octaves of 8 bits (e.g., b0 through b7) .
  • a transmitting device may segment a PDCP SDU into source PDCP PDUs and perform network coding to the source PDCP PDUs to generate parity PDCP PDUs.
  • the transmitting device may generate PDU headers for the set of encoded PDCP PDUs, including the source PDCP PDUs and parity PDCP PDUs.
  • Each PDCP PDU of the set of encoded PDCP PDUs may have a PDU header 405.
  • the PDU header 405 for a PDCP PDU may include a data or control field 410, which may indicate whether the PDCP PDU includes data or control information.
  • the PDU header 405 may include one or more fields which may be based on the network coding.
  • PDU header 405 may include P field 415.
  • the P field 415 may indicate whether the PDU requests a status report (e.g., HARQ feedback, a PDCP status PDU, etc. ) from the receiver or not.
  • the PDU header 405 may include a T field 420, which may indicate whether the PDCP PDU is a repaired PDU (e.g., a retransmitted PDU or a PDU corresponding to an SDU for which one or more PDUs were previously transmitted) or not.
  • a repaired PDU e.g., a retransmitted PDU or a PDU corresponding to an SDU for which one or more PDUs were previously transmitted
  • the transmitting device may retransmit PDCP PDUs corresponding to the PDCP SDU, and the transmitting device may indicate whether the PDCP PDUs for the retransmissions are repaired (e.g., retransmissions) or not. Indicating whether the PDCP PDU is repaired may assist receiving devices in obtaining or successfully decoding a missed PDCP SDU.
  • the PDU header 405 may include an L field 425, which may indicate whether the PDCP PDU is a last PDCP PDU corresponding to a PDCP SDU.
  • the transmitting device may indicate when all encoded PDCP PDUs corresponding to a PDCP SDU have been transmitted. If a receiving device cannot successfully decode and obtain the PDCP SDU after receiving all of the encoded PDCP PDUs corresponding to the PDCP SDU, the receiving device may determine that the PDCP SDU cannot be obtained, and the receiving device may consider the PDCP SDU as missing.
  • the PDU header 405 may include PDCP sequence number fields 430 and 435, where a value for the PDCP sequence number fields 430 and 435 correspond to a PDCP SDU.
  • the sequence number of the PDCP SDU may be associated with a count value configured at the transmitting device.
  • the transmitting device may set the PDCP sequence number field 430 in the PDU header 405 to indicate which PDCP SDU the PDCU PDU is associated with.
  • the PDU header 405 may use 12 bits in the PDCP sequence number fields 430 and 435 to indicate the PDCP sequence number.
  • the PDU header 405 may include a sub-sequence number field 440.
  • the sub-sequence number field 440 may indicate an index of the PDCP PDU corresponding to the PDCP SDU.
  • the sub-sequence number field 440 may be used to indicate an ordering for the encoded set of PDC PDPUs. For example, if the transmitting device generates a set of K data PDCP PDUs, the sub-sequence number of a PDU header may indicate the index of the corresponding PDCP PDU in the K data PDCP PDUs.
  • the sub-sequence number may be used at the one or more receiving devices to organize the received PDCP data PDUs and obtain the corresponding PDCP SDU.
  • the sub-SN field may be an 8-bit field, indicating indexes for up to 256 encoded PDCP PDUs corresponding to a single PDCP SDUs.
  • the PDU header 405 may be prepended to a PDCP payload including one or more fields including data and message authentication code –integrity (MAC-I) information.
  • MAC-I message authentication code –integrity
  • the PDCP PDU payload may include one or more octaves, or bytes, for the data and MAC-I information, such as field 445 through field 450.
  • FIG. 5 illustrates an example of a PDCP PDU format 500 that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure.
  • PDCP PDU format 500 may implement aspects of wireless communication system 100.
  • PDCP PDU format 500 may include an example of a PDU header 505 which may be added to network coded PDCP PDUs.
  • the PDU header 505 may be prepended to a source PDCP PDUs and parity PDCP PDUs corresponding to a PDCP SDU.
  • the PDCP PDU format 500 may be an example of a PDU header 505 with a 20-bit PDCP sequence number.
  • the PDU header 505 may include, for example, 4 octaves of 8 bits (e.g., b0 through b7) .
  • a transmitting device may segment a PDCP SDU into source PDCP PDUs and perform network coding to the source PDCP PDUs to generate parity PDCP PDUs.
  • the transmitting device may generate PDU headers for the set of encoded PDCP PDUs, including the source PDCP PDUs and parity PDCP PDUs.
  • Each PDCP PDU of the set of encoded PDCP PDUs may have a PDU header 505.
  • the PDU header 505 for a PDCP PDU may include a data or control field 510, which may indicate whether the PDCP PDU includes data or control information.
  • the PDU header 505 may include one or more fields which may be based on the network coding.
  • PDU header 505 may include P field 515.
  • the P field 515 may indicate whether the PDU requests a status report (e.g., HARQ feedback, a PDCP status PDU, etc. ) from the receiver or not.
  • a status report e.g., HARQ feedback, a PDCP status PDU, etc.
  • the PDU header 505 may include a T field 520, which may indicate whether the PDCP PDU is a repaired PDU (e.g., a retransmitted PDU or a PDU corresponding to an SDU for which one or more PDUs were previously transmitted) or not.
  • a repaired PDU e.g., a retransmitted PDU or a PDU corresponding to an SDU for which one or more PDUs were previously transmitted
  • the transmitting device may retransmit PDCP PDUs corresponding to the PDCP SDU, and the transmitting device may indicate whether the PDCP PDUs for the retransmissions are repaired (e.g., retransmissions) or not. Indicating whether the PDCP PDU is repaired may assist receiving devices in obtaining or successfully decoding a missed PDCP SDU.
  • the PDU header 505 may include an L field 525, which may indicate whether the PDCP PDU is a last PDCP PDU corresponding to a PDCP SDU. By indicating a last PDCP PDU of the set of encoded PDCP PDUs, the transmitting device may indicate when all encoded PDCP PDUs corresponding to a PDCP SDU have been transmitted. If a receiving device cannot successfully decode and obtain the PDCP SDU after receiving all of the encoded PDCP PDUs corresponding to the PDCP SDU, the receiving device may determine that the PDCP SDU cannot be obtained, and the receiving device may consider the PDCP SDU as missing. In some cases, the PDU header 505 may include one or more R fields 530. The R fields 530 may be reserved fields for some additional or alternative function of the PDCP PDU.
  • the PDU header 505 may include PDCP sequence number fields 535, 540-a, and 540-b, where a value for the PDCP sequence number fields 535 and 540 may correspond to a PDCP SDU.
  • the sequence number of the PDCP SDU may be associated with a count value configured at the transmitting device.
  • the transmitting device may set the PDCP sequence number field 535 and 540 in the PDU header 505 to indicate which PDCP SDU the PDCU PDU is associated with.
  • the PDU header 505 may use 20 bits across the PDCP sequence number fields 535 and 540 to indicate the PDCP sequence number.
  • the PDU header 505 may include a sub-sequence number field 545.
  • the sub-sequence number field 545 may indicate an index of the PDCP PDU corresponding to the PDCP SDU.
  • the sub-sequence number field 545 may be used to indicate an ordering for the encoded set of PDC PDPUs. For example, if the transmitting device generates a set of K data PDCP PDUs, the sub-sequence number of a PDU header may indicate the index of the corresponding PDCP PDU in the K data PDCP PDUs.
  • the sub-sequence number may be used at the one or more receiving devices to organize the received PDCP data PDUs and obtain the corresponding PDCP SDU.
  • the sub-SN field may be an 8-bit field, indicating indexes for up to 256 encoded PDCP PDUs corresponding to a single PDCP SDUs.
  • the PDU header 505 may be prepended to a PDCP PDU payload including one or more fields for data and MAC-I information.
  • the PDCP PDU payload may include one or more octaves, or bytes, for the data and MAC-I information, such as field 550 through field 555.
  • FIG. 6 illustrates an example of a PDCP configuration 600 that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure.
  • PDCP configuration 600 may implement aspects of wireless communication system 100.
  • a receiving device may receive at least a subset of the set of encoded PDCP data PDUs and attempt to obtain a PDCP SDU 605 from the encoded PDCP data PDUs.
  • the set of encoded PDCP data PDUs may include source PDCP PDUs 615 and parity PDCP PDUs 620.
  • the receiving device may receive PDCP PDUs 615-a and 615-b through 615-n and parity PDCP PDUs 620-a through 620-n.
  • Each PDCP PDU may have a PDU header 610, which may be an example of a PDU header 405 or 505 as described with reference to FIGs. 4 and 5, respectively.
  • the receiving device may attempt to assemble (e.g., obtain, decode) the PDCP SDU 605 from the received PDCP PDUs.
  • the receiving device may begin assembling the PDCP SDU 605 after receiving a minimum number of corresponding PDCP PDUs.
  • the receiving device may be unable to retrieve the PDCP SDU 605 prior to receiving a certain number of corresponding PDCP PDUs (e.g., based on the network coding procedure) , so the receiving device may wait to receive at least the minimum number of PDCP PDUs before attempting to reassemble the PDCP SDU 605.
  • the receiving device may reassemble a PDCP SDU 605 based on information in the PDU headers 610. For example, the receiving device may organize received PDCP PDUs according to associated PDCP SDUs 605. For example, the PDU headers 610 for each of the source PDCP PDUs 615 and parity PDCP PDUs 620 may include a field associating the PDCP PDUs with the PDCP SDU 605. In some cases, the receiving device may organize received PDCP data PDUs associated with a PDCP SDU based on the sub-sequence number indexes of the received PDCP data PDUs. For example, the PDU header 610 may indicate an ordering for the PDCP PDUs, and the receiving device may organize, for example, source PDCP PDU 615-a before source PDCP PDU 615-b based on the indexes.
  • the receiving device may be able to reassemble the PDCP SDU 605 from received PDCP PDUs.
  • the receiving device may store the PDCP SDU 605 in a reception buffer for in-order delivery of PDCP SDUs.
  • the receiving device may stop decoding or discard any additional received PDCP data PDUs associated with the obtained PDCP SDU 605. For example, the receiving device may not use all of the parity PDCP PDUs 620 to obtain the PDCP SDU 605.
  • the receiving device may discard any additional PDCP PDUs 615 and/or parity PDCP PDUs 620 after obtaining the PDCP SDU 605. This may reduce packet decoding latency and processing time at the receiving device.
  • the receiving device may record a number of PDCP PDUs used to successfully decode a PDCP SDU, or an average number of PDCP PDUs used to successfully decode each PDCP SDU of a set of PDCP SDUs. For example, if the receiving device successfully decodes the PDCP SDU without using all of the transmitted set of encoded PDCP PDUs, the receiving device may report how many PDCP PDUs were used to obtain the PDCP SDU to the transmitting device, and a code rate may be adjusted at the transmitting device.
  • the receiving device may consider the PDCP SDU missing. For example, if the receiving device cannot assemble the PDCP SDU 605 after receiving all source PDCP data PDUs associated with the PDCP SDU and all parity PDCP data PDUs associated with the PDCP SDU, the receiving device may identify the PDCP SDU as missing.
  • the receiving device may determine that all of the encoded set of PDCP data PDUs have been received based on receiving a PDCP data PDU with a flag in the PDU header 610 set indicating the PDCP data PDU is a last PDCP data PDU.
  • PDU header 610-e may include a field which is set to indicate that parity PDCP PDU 620-n is the last PDP PDU of a set of encoded PDCP PDUs associated with the PDCP SDU 605.
  • the receiving device may generate a PDCP status PDU for the PDCP SDU 605 and transmit the PDCP status PDU to the transmitting device.
  • a PDCP status PDU may provide feedback for one or more PDCP SDUs including the PDCP SDU 605.
  • the PDCP status PDU may include a field indicating the sequence number of a next not received PDCP SDU. For example, if the receiving device cannot obtain the PDCP SDU 605 from the set of encoded PDCP PDUs, the receiving device may indicate the sequence number of the PDCP SDU 605.
  • this may initiate a retransmission procedure, and the receiving device may receive a retransmission of PDCP PDUs corresponding to the PDCP SDU 605 or repaired PDCP DPUs for the PDCP SDU 605. If the receiving device can obtain the PDCP SDU 605, the receiving device may indicate a sequence number of a following PDCP SDU.
  • the PDCP status PDU may include an indicator of a number of PDCP PDUs used to assemble the PDCP SDU 605, or an average number of PDCP PDUs used to assemble a set of PDCP SDUs that includes the PDCP SDU 605.
  • the receiving device may not have used all of the parity PDCP PDUs 620 to obtain the PDCP SDU 605, and the receiving device may indicate how many PDCP PDUs were used to obtain the PDCP SDU 605.
  • the transmitting device may adjust a code rate for communications with the one or more receiving devices.
  • the transmitting device may receive multiple PDCP status PDUs from multiple receiving devices, and the transmitting device may adjust the code rate based on a largest number of PDCP PDUs used to obtain the PDCP SDU. This may ensure reliable communications with each of the multiple receiving devices.
  • the PDCP status PDU may include a bitmap to indicate missing PDCP SDUs or correctly received PDCP SDUs.
  • the bitmap may indicate which SDUs are missing and which SDUs are correctly received by the receiving device.
  • Each bit of the bitmap may correspond to a different PDCP SDU.
  • a bit of the bitmap is toggled (e.g., “1” )
  • an associated PDCP SDU may have been successfully received at the receiving device
  • the bit is not toggled (e.g., “0” )
  • the associated PDCP SDU may be missing at the receiving device.
  • FIG. 7 shows a block diagram 700 of a device 705 that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure.
  • the device 705 may be an example of aspects of a UE 115 or base station 105 as described herein.
  • the device 705 may include a receiver 710, a communication manager 715, and a transmitter 720.
  • the device 705 may also include a processor. Each of these components may be in communication with one another (e.g., via one or more buses) .
  • the receiver 710 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 rateless coding at a PDCP layer, etc. ) . Information may be passed on to other components of the device 705.
  • the receiver 710 may be an example of aspects of the transceiver 1015 described with reference to FIG. 10.
  • the receiver 710 may utilize a single antenna or a set of antennas.
  • the communication manager 715 may segment a PDCP SDU into a set of PDCP PDUs at a PDCP layer of the transmitting device, encode, at the PDCP layer, the set of PDCP PDUs according to one or more network coding parameters to obtain a set of encoded PDCP PDUs, the one or more network coding parameters including a rateless code, generate, for the set of encoded PDCP PDUs, a corresponding set of PDU headers, and output the set of encoded PDCP PDUs and the corresponding set of PDU headers from the PDCP layer to a lower layer of the transmitting device for transmission to one or more receiving devices.
  • the communication manager 715 may also receive, at a PDCP layer of the receiving device, a set of PDCP PDUs and a corresponding set of PDCP PDU headers from a transmitting device, the set of PDCP PDUs and the corresponding set of PDCP PDU headers corresponding to a PDCP SDU, decode, at the PDCP layer, at least a subset of the set of PDCP PDUs based on one or more network coding parameters and the corresponding set of PDCP PDU headers, the one or more network coding parameters including a rateless code, generate a report based on the decoding, where the report indicates whether the PDCP SDU was obtained from the set of PDCP PDUs, and transmit the report to the transmitting device.
  • the communication manager 715 may be an example of aspects of the communication manager 1010 or 1110 as described herein.
  • the communication manager 715 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 communication manager 715, or its sub-components may be executed by a general-purpose processor, a DSP, an application-specific integrated circuit (ASIC) , a 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.
  • code e.g., software or firmware
  • ASIC application-specific integrated circuit
  • the communication manager 715 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.
  • the communication manager 715, or its sub-components may be a separate and distinct component in accordance with various aspects of the present disclosure.
  • the communication manager 715, 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.
  • I/O input/output
  • the actions performed by the communication manager 715as described herein may be implemented to realize one or more potential advantages.
  • One implementation may allow a transmitting or receiving device to support Layer 2 retransmission schemes without significant latency by supporting network coding at the PDCP layer.
  • network coding at the PDCP layer may increase reliability for communication of PDCP SDUs.
  • the transmitter 720 may transmit signals generated by other components of the device 705.
  • the transmitter 720 may be collocated with a receiver 710 in a transceiver module.
  • the transmitter 720 may be an example of aspects of the transceiver 1015 described with reference to FIG. 10.
  • the transmitter 720 may utilize a single antenna or a set of antennas.
  • FIG. 8 shows a block diagram 800 of a device 805 that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure.
  • the device 805 may be an example of aspects of a device 705, a UE 115, or a base station 105 as described herein.
  • the device 805 may include a receiver 810, a communication manager 815, and a transmitter 855.
  • 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) .
  • the 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 rateless coding at a PDCP layer, 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 1015 described with reference to FIG. 10.
  • the receiver 810 may utilize a single antenna or a set of antennas.
  • the communication manager 815 may be an example of aspects of the communication manager 715 as described herein.
  • the communication manager 815 may include a PDCP SDU manager 820, a PDCP encoding manager 825, a PDCP PDU manager 830, a PDCP PDU outputting manager 835, a PDCP decoding manager 840, a PDCP SDU report manager 845, and a report transmitting manager 850.
  • the communication manager 815 may be an example of aspects of the communication manager 1010 or 1110 as described herein.
  • the PDCP SDU manager 820 may segment a PDCP SDU into a set of PDCP PDUs at a PDCP layer of the transmitting device.
  • the PDCP encoding manager 825 may encode, at the PDCP layer, the set of PDCP PDUs according to one or more network coding parameters to obtain a set of encoded PDCP PDUs, the one or more network coding parameters including a rateless code.
  • the PDCP PDU manager 830 may generate, for the set of encoded PDCP PDUs, a corresponding set of PDU headers.
  • the PDCP PDU outputting manager 835 may output the set of encoded PDCP PDUs and the corresponding set of PDU headers from the PDCP layer to a lower layer of the transmitting device for transmission to one or more receiving devices.
  • the PDCP PDU manager 830 may receive, at a PDCP layer of the receiving device, a set of PDCP PDUs and a corresponding set of PDCP PDU headers from a transmitting device, the set of PDCP PDUs and the corresponding set of PDCP PDU headers corresponding to a PDCP SDU.
  • the PDCP decoding manager 840 may decode, at the PDCP layer, at least a subset of the set of PDCP PDUs based on one or more network coding parameters and the corresponding set of PDCP PDU headers, the one or more network coding parameters including a rateless code.
  • the PDCP SDU report manager 845 may generate a report based on the decoding, where the report indicates whether the PDCP SDU was obtained from the set of PDCP PDUs.
  • the report transmitting manager 850 may transmit the report to the transmitting device.
  • the transmitter 855 may transmit signals generated by other components of the device 805.
  • the transmitter 855 may be collocated with a receiver 810 in a transceiver module.
  • the transmitter 855 may be an example of aspects of the transceiver 1015 described with reference to FIG. 10.
  • the transmitter 855 may utilize a single antenna or a set of antennas.
  • FIG. 9 shows a block diagram 900 of a communication manager 905 that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure.
  • the communication manager 905 may be an example of aspects of a communication manager 715, a communication manager 815, or a communication manager 1010 described herein.
  • the communication manager 905 may include a PDCP SDU manager 910, a PDCP encoding manager 915, a PDCP PDU manager 920, a PDCP PDU outputting manager 925, an integrity protection and ciphering manager 930, a PDU header manager 935, a feedback manager 940, a RLC layer manager 945, a PDCP decoding manager 950, a PDCP SDU report manager 955, a report transmitting manager 960, and an integrity verification and deciphering manager 965.
  • Each of these modules may communicate, directly or indirectly, with one another (e.g., via one or more buses) .
  • the PDCP SDU manager 910 may segment a PDCP SDU into a set of PDCP PDUs at a PDCP layer of the transmitting device.
  • the PDCP encoding manager 915 may encode, at the PDCP layer, the set of PDCP PDUs according to one or more network coding parameters to obtain a set of encoded PDCP PDUs, the one or more network coding parameters including a rateless code.
  • encode the set of PDCP PDUs includes encoding the set of source PDCP PDUs to obtain a set of encoded source PDCP PDUs and a set of encoded parity PDCP PDUs.
  • the PDCP encoding manager 915 may receive an indication of the minimum code rate for the set of encoded PDCP PDUs via radio resource control signaling.
  • the set of PDCP PDUs includes a set of source PDCP PDUs.
  • the PDCP PDU manager 920 may generate, for the set of encoded PDCP PDUs, a corresponding set of PDU headers.
  • the PDCP PDU manager 920 may receive, at a PDCP layer of the receiving device, a set of PDCP PDUs and a corresponding set of PDCP PDU headers from a transmitting device, the set of PDCP PDUs and the corresponding set of PDCP PDU headers corresponding to a PDCP SDU.
  • the PDCP PDU manager 920 may store the PDCP SDU or the set of encoded PDCP PDUs in a retransmission buffer implemented at the PDCP layer.
  • the PDCP PDU outputting manager 925 may output the set of encoded PDCP PDUs and the corresponding set of PDU headers from the PDCP layer to a lower layer of the transmitting device for transmission to one or more receiving devices.
  • the PDCP decoding manager 950 may decode, at the PDCP layer, at least a subset of the set of PDCP PDUs based on one or more network coding parameters and the corresponding set of PDCP PDU headers, the one or more network coding parameters including a rateless code. In some examples, the PDCP decoding manager 950 may determine that at least a minimum quantity of PDCP PDUs of the set of PDCP PDUs has been received, where the decoding is based on determining that at least the minimum quantity of PDCP PDUs has been received. In some examples, the PDCP decoding manager 950 may receive an indication of the minimum quantity of PDCP PDUs in the set of PDCP PDUs via radio resource control signaling.
  • the PDCP decoding manager 950 may obtain the PDCP SDU from the subset of the set of PDCP PDUs. In some examples, the PDCP decoding manager 950 may refrain from decoding a remaining subset of the set of PDCP PDUs based on obtaining the PDCP SDU. In some examples, the PDCP decoding manager 950 may receive a set of source PDCP PDUs and a set of parity PDCP PDUs.
  • the PDCP SDU report manager 955 may generate a report based on the decoding, where the report indicates whether the PDCP SDU was obtained from the set of PDCP PDUs. In some examples, the PDCP SDU report manager 955 may indicate, to the transmitting device, a quantity of PDCP PDUs used by the receiving device to obtain the PDCP SDU. In some examples, the PDCP SDU report manager 955 may determine that the PDCP SDU cannot be obtained from the set of PDCP PDUs, where the report indicates that the receiving device was unable to obtain the PDCP SDU. In some examples, the PDCP SDU report manager 955 may monitor for a retransmission of the set of PDCP PDUs based on transmitting the report.
  • the PDCP SDU report manager 955 may identify, within each PDU header of the set of PDU headers, a field indicating an index for an associated PDCP PDU corresponding to the PDCP SDU, where the set of PDCP PDUs are decoded based on an ordering corresponding to the index.
  • the PDCP SDU is included in a set of PDCP SDUs.
  • the receiving device is unable to obtain one or more PDCP SDUs in the set of PDCP SDUs.
  • the report includes a sequence number of the PDCP SDU based on the PDCP SDU having a lowest sequence number among the one or more PDCP SDUs that the receiving device is unable to obtain.
  • the report further includes a bitmap indicating, for each PDCP SDU in a set of PDCP SDUs having a sequence number greater than the sequence number of the PDCP SDU, whether the receiving device was able to successfully obtain or was not able to obtain a respective PDCP SDU.
  • the report transmitting manager 960 may transmit the report to the transmitting device.
  • the integrity protection and ciphering manager 930 may perform, at the PDCP layer and before the encoding, an integrity protection and ciphering function on the PDCP SDU.
  • the PDU header manager 935 may set, within each PDU header of the set of PDU headers, a field indicating an index for an associated encoded PDCP PDU corresponding to the PDCP SDU, where the index corresponds to an ordering for the set of encoded PDUs.
  • the PDU header manager 935 may set, within a PDU header of the set of PDU headers, a flag indicating that an associated encoded PDCP PDU is a last encoded PDCP PDU of the set of encoded PDUs corresponding to the PDCP SDU. In some examples, the PDU header manager 935 may set, within each PDU header of the set of PDU headers, a repair field indicating whether an associated encoded PDCP PDU is a repaired PDCP PDU.
  • the PDU header manager 935 may identify, within a PDU header of the set of PDU headers, a flag indicating that an associated PDCP PDU is a last PDCP PDU of the set of PDCP PDUs corresponding to the PDCP SDU. In some examples, the PDU header manager 935 may identify, within each PDU header of the set of PDU headers, a repair field indicating whether an associated PDCP PDU is a repaired PDCP PDU.
  • the feedback manager 940 may receive, from a receiving device of the one or more receiving devices, feedback for the set of encoded PDCP PDUs indicating that the receiving device was unable to obtain the PDCP SDU. In some examples, the feedback manager 940 may retrieve, based on the feedback, the set of encoded PDCP PDUs from a retransmission buffer implemented at the PDCP layer. In some examples, the feedback manager 940 may retransmit the set of encoded PDCP PDUs to the one or more receiving devices based on the retrieving. In some examples, the feedback manager 940 may retrieve, based on the feedback, the PDCP SDU from a retransmission buffer implemented at the PDCP layer.
  • the feedback manager 940 may encode the set of PDCP PDUs according to the one or more network coding parameters to obtain a set of re-encoded PDCP PDUs based on the retrieving. In some examples, the feedback manager 940 may transmit the set of re-encoded PDCP PDUs to the one or more receiving devices. In some examples, the feedback manager 940 may receive, from a receiving device of the one or more receiving devices, feedback for the set of encoded PDCP PDUs indicating that the receiving device was able to obtain the PDCP SDU. In some examples, the feedback manager 940 may receive, from the receiving device, an indication of a quantity of encoded PDCP PDUs used by the receiving device to obtain the PDCP SDU. In some examples, the feedback manager 940 may adjust a code rate of the one or more network coding parameters based on the indicated quantity of encoded PDCP PDUs.
  • the RLC layer manager 945 may configure a radio link control layer at the transmitting device to operate a transparent mode or an unacknowledged mode, where the encoding at the PDCP layer is based on the configuring. In some examples, the RLC layer manager 945 may configure a radio link control layer at the receiving device for a transparent mode or an unacknowledged mode, where the decoding at the PDCP layer is based on the configuring.
  • the integrity verification and deciphering manager 965 may perform, at the PDCP layer after decoding at least the subset of the set of PDCP PDUs and obtaining the PDCP SDU, an integrity verification and deciphering function on the PDCP SDU.
  • FIG. 10 shows a diagram of a system 1000 including a device 1005 that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure.
  • the device 1005 may be an example of or include the components of device 705, device 805, or a UE 115 as described herein.
  • the device 1005 may include components for bi-directional voice and data communications including components for transmitting and receiving communications, including a communication manager 1010, a transceiver 1015, an antenna 1020, memory 1025, and a processor 1035. These components may be in electronic communication via one or more buses (e.g., bus 1040) .
  • buses e.g., bus 1040
  • the communication manager 1010 may segment a PDCP SDU into a set of PDCP PDUs at a PDCP layer of the transmitting device, encode, at the PDCP layer, the set of PDCP PDUs according to one or more network coding parameters to obtain a set of encoded PDCP PDUs, the one or more network coding parameters including a rateless code, generate, for the set of encoded PDCP PDUs, a corresponding set of PDU headers, and output the set of encoded PDCP PDUs and the corresponding set of PDU headers from the PDCP layer to a lower layer of the transmitting device for transmission to one or more receiving devices.
  • the communication manager 1010 may also receive, at a PDCP layer of the receiving device, a set of PDCP PDUs and a corresponding set of PDCP PDU headers from a transmitting device, the set of PDCP PDUs and the corresponding set of PDCP PDU headers corresponding to a PDCP SDU, decode, at the PDCP layer, at least a subset of the set of PDCP PDUs based on one or more network coding parameters and the corresponding set of PDCP PDU headers, the one or more network coding parameters including a rateless code, generate a report based on the decoding, where the report indicates whether the PDCP SDU was obtained from the set of PDCP PDUs, and transmit the report to the transmitting device.
  • the transceiver 1015 may communicate bi-directionally, via one or more antennas, wired, or wireless links as described above.
  • the transceiver 1015 may represent a wireless transceiver and may communicate bi-directionally with another wireless transceiver.
  • the transceiver 1015 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.
  • the wireless device may include a single antenna 1020. However, in some cases the device may have more than one antenna 1020, which may be capable of concurrently transmitting or receiving multiple wireless transmissions.
  • the memory 1025 may include RAM and ROM.
  • the memory 1025 may store computer-readable, computer-executable code 1030 including instructions that, when executed, cause the processor to perform various functions described herein.
  • the memory 1025 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 code 1030 may include instructions to implement aspects of the present disclosure, including instructions to support wireless communications.
  • the code 1030 may be stored in a non-transitory computer-readable medium such as system memory or other type of memory.
  • the code 1030 may not be directly executable by the processor 1035 but may cause a computer (e.g., when compiled and executed) to perform functions described herein.
  • the processor 1035 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) .
  • the processor 1035 may be configured to operate a memory array using a memory controller.
  • a memory controller may be integrated into the processor 1035.
  • the processor 1035 may be configured to execute computer-readable instructions stored in a memory (e.g., the memory 1025) to cause the device 1005 to perform various functions (e.g., functions or tasks supporting rateless coding at a PDCP layer) .
  • FIG. 11 shows a diagram of a system 1100 including a device 1105 that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure.
  • the device 1105 may be an example of or include the components of device 705, device 805, or a base station 105 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 communication manager 1110, a transceiver 1115, an antenna 1120, memory 1125, and a processor 1135. These components may be in electronic communication via one or more buses (e.g., bus 1140) .
  • buses e.g., bus 1140
  • the communication manager 1110 may segment a PDCP SDU into a set of PDCP PDUs at a PDCP layer of the transmitting device, encode, at the PDCP layer, the set of PDCP PDUs according to one or more network coding parameters to obtain a set of encoded PDCP PDUs, the one or more network coding parameters including a rateless code, generate, for the set of encoded PDCP PDUs, a corresponding set of PDU headers, and output the set of encoded PDCP PDUs and the corresponding set of PDU headers from the PDCP layer to a lower layer of the transmitting device for transmission to one or more receiving devices.
  • the communication manager 1110 may also receive, at a PDCP layer of the receiving device, a set of PDCP PDUs and a corresponding set of PDCP PDU headers from a transmitting device, the set of PDCP PDUs and the corresponding set of PDCP PDU headers corresponding to a PDCP SDU, decode, at the PDCP layer, at least a subset of the set of PDCP PDUs based on one or more network coding parameters and the corresponding set of PDCP PDU headers, the one or more network coding parameters including a rateless code, generate a report based on the decoding, where the report indicates whether the PDCP SDU was obtained from the set of PDCP PDUs, and transmit the report to the transmitting device.
  • the transceiver 1115 may communicate bi-directionally, via one or more antennas, wired, or wireless links as described above.
  • the transceiver 1115 may represent a wireless transceiver and may communicate bi-directionally with another wireless transceiver.
  • the transceiver 1115 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.
  • the wireless device may include a single antenna 1120. However, in some cases the device may have more than one antenna 1120, which may be capable of concurrently transmitting or receiving multiple wireless transmissions.
  • the memory 1125 may include RAM and ROM.
  • the memory 1125 may store computer-readable, computer-executable code 1130 including instructions that, when executed, cause the processor to perform various functions described herein.
  • the memory 1125 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 code 1130 may include instructions to implement aspects of the present disclosure, including instructions to support wireless communications.
  • the code 1130 may be stored in a non-transitory computer-readable medium such as system memory or other type of memory. In some cases, the code 1130 may not be directly executable by the processor 1135 but may cause a computer (e.g., when compiled and executed) to perform functions described herein.
  • the processor 1135 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) .
  • the processor 1135 may be configured to operate a memory array using a memory controller.
  • a memory controller may be integrated into the processor 1135.
  • the processor 1135 may be configured to execute computer-readable instructions stored in a memory (e.g., the memory 1125) to cause the device 1105 to perform various functions (e.g., functions or tasks supporting rateless coding at a PDCP layer) .
  • FIG. 12 shows a flowchart illustrating a method 1200 that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure.
  • the operations of method 1200 may be implemented by a UE 115 or base station 105 or its components as described herein.
  • the operations of method 1200 may be performed by a communication manager as described with reference to FIGs. 7 through 11.
  • 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 described functions.
  • a UE or base station may perform aspects of the described functions using special-purpose hardware.
  • the UE or base station may segment a PDCP SDU into a set of PDCP PDUs at a PDCP layer of the transmitting device.
  • the operations of 1205 may be performed according to the methods described herein. In some examples, aspects of the operations of 1205 may be performed by a PDCP SDU manager as described with reference to FIGs. 7 through 11.
  • the UE or base station may encode, at the PDCP layer, the set of PDCP PDUs according to one or more network coding parameters to obtain a set of encoded PDCP PDUs, the one or more network coding parameters including a rateless code. Additionally or alternatively, the network coding parameters may further include other parameters as described elsewhere herein.
  • the operations of 1210 may be performed according to the methods described herein. In some examples, aspects of the operations of 1210 may be performed by a PDCP encoding manager as described with reference to FIGs. 7 through 11.
  • the UE or base station may generate, for the set of encoded PDCP PDUs, a corresponding set of PDU headers.
  • the operations of 1215 may be performed according to the methods described herein. In some examples, aspects of the operations of 1215 may be performed by a PDCP PDU manager as described with reference to FIGs. 7 through 11.
  • the UE or base station may output the set of encoded PDCP PDUs and the corresponding set of PDU headers from the PDCP layer to a lower layer of the transmitting device for transmission to one or more receiving devices.
  • the operations of 1220 may be performed according to the methods described herein. In some examples, aspects of the operations of 1220 may be performed by a PDCP PDU outputting manager as described with reference to FIGs. 7 through 11.
  • FIG. 13 shows a flowchart illustrating a method 1300 that supports rateless coding at a PDCP layer 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.
  • the operations of method 1300 may be performed by a communication manager as described with reference to FIGs. 7 through 11.
  • 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 described functions.
  • a UE or base station may perform aspects of the described functions using special-purpose hardware.
  • the UE or base station may perform, at the PDCP layer and before the encoding, an integrity protection and ciphering function on the PDCP SDU.
  • 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 an integrity protection and ciphering manager as described with reference to FIGs. 7 through 11.
  • the UE or base station may segment a PDCP SDU into a set of PDCP PDUs at a PDCP layer of the transmitting device.
  • 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 PDCP SDU manager as described with reference to FIGs. 7 through 11.
  • the UE or base station may encode, at the PDCP layer, the set of PDCP PDUs according to one or more network coding parameters to obtain a set of encoded PDCP PDUs, the one or more network coding parameters including a rateless code. Additionally or alternatively, the set of network coding parameters can include additional parameters as described elsewhere herein.
  • 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 PDCP encoding manager as described with reference to FIGs. 7 through 11.
  • the UE or base station may generate, for the set of encoded PDCP PDUs, a corresponding set of PDU headers.
  • 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 PDCP PDU manager as described with reference to FIGs. 7 through 11.
  • the UE or base station may output the set of encoded PDCP PDUs and the corresponding set of PDU headers from the PDCP layer to a lower layer of the transmitting device for transmission to one or more receiving devices.
  • 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 PDCP PDU outputting manager as described with reference to FIGs. 7 through 11.
  • FIG. 14 shows a flowchart illustrating a method 1400 that supports rateless coding at a PDCP layer 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.
  • the operations of method 1400 may be performed by a communication manager as described with reference to FIGs. 7 through 11.
  • 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 described functions.
  • a UE or base station may perform aspects of the described functions using special-purpose hardware.
  • the UE or base station may segment a PDCP SDU into a set of PDCP PDUs at a PDCP layer of the transmitting device.
  • 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 PDCP SDU manager as described with reference to FIGs. 7 through 11.
  • the UE or base station may encode, at the PDCP layer, the set of PDCP PDUs according to one or more network coding parameters to obtain a set of encoded PDCP PDUs, the one or more network coding parameters including a rateless code. Additionally or alternatively, the set of network coding parameters can include additional parameters as described elsewhere herein.
  • 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 PDCP encoding manager as described with reference to FIGs. 7 through 11.
  • the UE or base station may generate, for the set of encoded PDCP PDUs, a corresponding set of PDU headers.
  • 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 PDCP PDU manager as described with reference to FIGs. 7 through 11.
  • the UE or base station may output the set of encoded PDCP PDUs and the corresponding set of PDU headers from the PDCP layer to a lower layer of the transmitting device for transmission to one or more receiving devices.
  • 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 PDCP PDU outputting manager as described with reference to FIGs. 7 through 11.
  • the UE or base station may receive, from a receiving device of the one or more receiving devices, feedback for the set of encoded PDCP PDUs indicating that the receiving device was unable to obtain the PDCP SDU.
  • 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 feedback manager as described with reference to FIGs. 7 through 11.
  • FIG. 15 shows a flowchart illustrating a method 1500 that supports rateless coding at a PDCP layer 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.
  • the operations of method 1500 may be performed by a communication manager as described with reference to FIGs. 7 through 11.
  • 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 described functions.
  • a UE or base station may perform aspects of the described functions using special-purpose hardware.
  • the UE or base station may receive, at a PDCP layer of the receiving device, a set of PDCP PDUs and a corresponding set of PDCP PDU headers from a transmitting device, the set of PDCP PDUs and the corresponding set of PDCP PDU headers corresponding to a PDCP SDU.
  • 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 PDCP PDU manager as described with reference to FIGs. 7 through 11.
  • the UE or base station may decode, at the PDCP layer, at least a subset of the set of PDCP PDUs based on one or more network coding parameters and the corresponding set of PDCP PDU headers, the one or more network coding parameters including a rateless code. Additionally or alternatively, the set of network coding parameters can include additional parameters as described elsewhere herein.
  • 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 PDCP decoding manager as described with reference to FIGs. 7 through 11.
  • the UE or base station may generate a report based on the decoding, where the report indicates whether the PDCP SDU was obtained from the set of PDCP PDUs.
  • 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 PDCP SDU report manager as described with reference to FIGs. 7 through 11.
  • the UE or base station may transmit the report to the transmitting device.
  • 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 report transmitting manager as described with reference to FIGs. 7 through 11.
  • FIG. 16 shows a flowchart illustrating a method 1600 that supports rateless coding at a PDCP layer 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.
  • the operations of method 1600 may be performed by a communication manager as described with reference to FIGs. 7 through 11.
  • 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 described functions. Additionally, or alternatively, a UE or base station may perform aspects of the described functions using special-purpose hardware.
  • the UE or base station may receive, at a PDCP layer of the receiving device, a set of PDCP PDUs and a corresponding set of PDCP PDU headers from a transmitting device, the set of PDCP PDUs and the corresponding set of PDCP PDU headers corresponding to a PDCP SDU.
  • 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 PDCP PDU manager as described with reference to FIGs. 7 through 11.
  • the UE or base station may determine that at least a minimum quantity of PDCP PDUs of the set of PDCP PDUs has been received, where the decoding is based on determining that at least the minimum quantity of PDCP PDUs has been received.
  • 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 PDCP decoding manager as described with reference to FIGs. 7 through 11.
  • the UE or base station may decode, at the PDCP layer, at least a subset of the set of PDCP PDUs based on one or more network coding parameters and the corresponding set of PDCP PDU headers, the one or more network coding parameters including a rateless code. Additionally or alternatively, the one or more network coding parameters may include a minimum code rate, the minimum quantity of PDCP PDUs with reference to 1610, a generation or generator matrix, or the like.
  • 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 PDCP decoding manager as described with reference to FIGs. 7 through 11.
  • the UE or base station may generate a report based on the decoding, where the report indicates whether the PDCP SDU was obtained from the set of PDCP PDUs.
  • 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 PDCP SDU report manager as described with reference to FIGs. 7 through 11.
  • the UE or base station may transmit the report to the transmitting device.
  • 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 transmitting manager as described with reference to FIGs. 7 through 11.
  • FIG. 17 shows a flowchart illustrating a method 1700 that supports rateless coding at a PDCP layer 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.
  • the operations of method 1700 may be performed by a communication manager as described with reference to FIGs. 7 through 11.
  • 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 described functions.
  • a UE or base station may perform aspects of the described functions using special-purpose hardware.
  • the UE or base station may receive, at a PDCP layer of the receiving device, a set of PDCP PDUs and a corresponding set of PDCP PDU headers from a transmitting device, the set of PDCP PDUs and the corresponding set of PDCP PDU headers corresponding to a PDCP SDU.
  • 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 PDCP PDU manager as described with reference to FIGs. 7 through 11.
  • the UE or base station may decode, at the PDCP layer, at least a subset of the set of PDCP PDUs based on one or more network coding parameters and the corresponding set of PDCP PDU headers, the one or more network coding parameters including a rateless code. Additionally or alternatively, the set of network coding parameters can include additional parameters as described elsewhere herein.
  • 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 PDCP decoding manager as described with reference to FIGs. 7 through 11.
  • the UE or base station may obtain the PDCP SDU from the subset of the set of PDCP PDUs.
  • 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 PDCP decoding manager as described with reference to FIGs. 7 through 11.
  • the UE or base station may refrain from decoding a remaining subset of the set of PDCP PDUs based on obtaining the PDCP SDU.
  • the operations of 1720 may be performed according to the methods described herein. In some examples, aspects of the operations of 1720 may be performed by a PDCP decoding manager as described with reference to FIGs. 7 through 11.
  • the UE or base station may generate a report based on the decoding, where the report indicates whether the PDCP SDU was obtained from the set of PDCP PDUs.
  • the operations of 1725 may be performed according to the methods described herein. In some examples, aspects of the operations of 1725 may be performed by a PDCP SDU report manager as described with reference to FIGs. 7 through 11.
  • the UE or base station may transmit the report to the transmitting device.
  • the operations of 1730 may be performed according to the methods described herein. In some examples, aspects of the operations of 1730 may be performed by a report transmitting manager as described with reference to FIGs. 7 through 11.
  • LTE, LTE-A, LTE-A Pro, or NR 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.
  • 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.
  • UMB Ultra Mobile Broadband
  • IEEE Institute of Electrical and Electronics Engineers
  • Wi-Fi Institute of Electrical and Electronics Engineers
  • WiMAX IEEE 802.16
  • IEEE 802.20 Flash-OFDM
  • Information and signals described herein may be represented using any of a variety of different technologies and techniques.
  • 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.
  • 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.
  • 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.
  • RAM random-access memory
  • ROM read-only memory
  • EEPROM electrically erasable programmable ROM
  • flash memory compact disk (CD) ROM or other optical disk storage
  • CD compact disk
  • 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,
  • Disk and disc 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.

Abstract

Methods, systems, and devices for wireless communications are described. A transmitting device may segment a packet data convergence protocol (PDCP) service data unit (SDU) into a set of PDCP protocol data units (PDUs) at a PDCP layer of the transmitting device. The transmitting device may encode, at the PDCP layer, the set of PDCP PDUs according to one or more network coding parameters to obtain a set of encoded PDCP PDUs, the one or more network coding parameters including a rateless code. The transmitting device may generate, for the set of encoded PDCP PDUs, a corresponding set of PDU headers and output the set of encoded PDCP PDUs and the corresponding set of PDU headers from the PDCP layer to a lower layer of the transmitting device for transmission to one or more receiving devices.

Description

RATELESS CODING AT A PACKET DATA CONVERGENCE PROTOCOL LAYER
FIELD OF TECHNOLOGY
The following relates to wireless communications, including rateless coding at a packet data convergence protocol layer.
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) .
SUMMARY
The described techniques relate to improved methods, systems, devices, and apparatuses that support rateless coding at (e.g., in) a packet data convergence protocol (PDCP) layer. Generally, at the PDCP layer and in at least some cases after integrity protection and ciphering, a PDCU service data unit (SDU) may be segmented into one or more PDCP packet data units (PDUs) , and the PDCP PDUs may be encoded using a rateless code (e.g., a network code, outer code, etc. ) . For example, a transmitting device (e.g., a user equipment (UE) and/or base station performing a transmission) may receive a set of PDCP SDUs at the PDCP layer. The set of PDCP SDUs may correspond to a payload of data (e.g., packets) for transmission to receiving device (s) (e.g., a UE (s) and/or base station (s) receiving the transmission) . The transmitting device may use the rateless code to encode a PDCP SDU  to generate, create, obtain, etc., a set of encoded PDCP PDUs, including source PDCP PDUs and parity PDCP PDUs. The set of encoded PDCP PDUs are then passed down to one or more lower layer (s) for transmission to the receiving devices.
The receiving device may receive the transmission and provide the set of encoded PDCP PDUs to the PDCP layer for decoding. The receiving device may decode the set of encoded PDCP PDUs to obtain a PDCP SDU. For example, the receiving device may receive a threshold quantity of PDCP PDUs of a PDCP SDU (e.g., source PDUs and parity PDUs) , rearrange/reassemble the PDCP PDUs, and then use the rateless code to decode the set of encoded PDCP PDUs to obtain the corresponding PDCP SDU. The PDCP SDU (e.g., obtained based on decoding using the rateless code) may be passed or otherwise provided to integrity protection and ciphering then an upper layer of the receiving device for further processing/recovery of the PDCP SDU.
A method for wireless communication at a transmitting device is described. The method may include segmenting a PDCP SDU into a set of PDCP PDUs at a PDCP layer of the transmitting device, encoding, at the PDCP layer, the set of PDCP PDUs according to one or more network coding parameters to obtain a set of encoded PDCP PDUs, the one or more network coding parameters including a rateless code, generating, for the set of encoded PDCP PDUs, a corresponding set of PDU headers, and outputting the set of encoded PDCP PDUs and the corresponding set of PDU headers from the PDCP layer to a lower layer of the transmitting device for transmission to one or more receiving devices.
An apparatus for wireless communication at a transmitting device is described. The apparatus may include a processor, memory in electronic communication with the processor, and instructions stored in the memory. The instructions may be executable by the processor to cause the apparatus to segment a PDCP SDU into a set of PDCP PDUs at a PDCP layer of the transmitting device, encode, at the PDCP layer, the set of PDCP PDUs according to one or more network coding parameters to obtain a set of encoded PDCP PDUs, the one or more network coding parameters including a rateless code, generate, for the set of encoded PDCP PDUs, a corresponding set of PDU headers, and output the set of encoded PDCP PDUs and the corresponding set of PDU headers from the PDCP layer to a lower layer of the transmitting device for transmission to one or more receiving devices.
Another apparatus for wireless communication at a transmitting device is described. The apparatus may include means for segmenting a PDCP SDU into a set of PDCP PDUs at a PDCP layer of the transmitting device, means for encoding, at the PDCP layer, the set of PDCP PDUs according to one or more network coding parameters to obtain a set of encoded PDCP PDUs, the one or more network coding parameters including a rateless code, means for generating, for the set of encoded PDCP PDUs, a corresponding set of PDU headers, and means for outputting the set of encoded PDCP PDUs and the corresponding set of PDU headers from the PDCP layer to a lower layer of the transmitting device for transmission to one or more receiving devices.
A non-transitory computer-readable medium storing code for wireless communication at a transmitting device is described. The code may include instructions executable by a processor to segment a PDCP SDU into a set of PDCP PDUs at a PDCP layer of the transmitting device, encode, at the PDCP layer, the set of PDCP PDUs according to one or more network coding parameters to obtain a set of encoded PDCP PDUs, the one or more network coding parameters including a rateless code, generate, for the set of encoded PDCP PDUs, a corresponding set of PDU headers, and output the set of encoded PDCP PDUs and the corresponding set of PDU headers from the PDCP layer to a lower layer of the transmitting device for transmission to one or more receiving devices.
Some examples of the method, apparatuses, and non-transitory computer-readable medium described herein may further include operations, features, means, or instructions for performing, at the PDCP layer and before the encoding, an integrity protection and ciphering function on the PDCP SDU.
In some examples of the method, apparatuses, and non-transitory computer-readable medium described herein, the set of PDCP PDUs includes a set of source PDCP PDUs, and encoding the set of PDCP PDUs may include operations, features, means, or instructions for encoding the set of source PDCP PDUs to obtain a set of encoded source PDCP PDUs and a set of encoded parity PDCP PDUs.
In some examples of the method, apparatuses, and non-transitory computer-readable medium described herein, generating the set of PDU headers may include operations, features, means, or instructions for setting, within each PDU header of the set of PDU headers, a field indicating an index for an associated encoded PDCP PDU  corresponding to the PDCP SDU, where the index corresponds to an ordering for the set of encoded PDUs.
In some examples of the method, apparatuses, and non-transitory computer-readable medium described herein, generating the set of PDU headers may include operations, features, means, or instructions for setting, within a PDU header of the set of PDU headers, a flag indicating that an associated encoded PDCP PDU may be a last encoded PDCP PDU of the set of encoded PDUs corresponding to the PDCP SDU.
In some examples of the method, apparatuses, and non-transitory computer-readable medium described herein, generating the set of PDU headers may include operations, features, means, or instructions for setting, within each PDU header of the set of PDU headers, a repair field indicating whether an associated encoded PDCP PDU may be a repaired PDCP PDU.
In some examples of the method, apparatuses, and non-transitory computer-readable medium described herein, the one or more network coding parameters include a minimum code rate for the set of encoded PDCP PDUs, and where a quantity of encoded PDCP PDUs included in the set of encoded PDCP PDUs may be based on the minimum code rate.
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 minimum code rate for the set of encoded PDCP PDUs via radio resource control signaling.
Some examples of the method, apparatuses, and non-transitory computer-readable medium described herein may further include operations, features, means, or instructions for storing the PDCP SDU or the set of encoded PDCP PDUs in a retransmission buffer implemented at the PDCP layer.
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 a receiving device of the one or more receiving devices, feedback for the set of encoded PDCP PDUs indicating that the receiving device was unable to obtain the 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 retrieving, based on the feedback, the set of encoded PDCP PDUs from a retransmission buffer implemented at the PDCP layer, and retransmitting the set of encoded PDCP PDUs to the one or more receiving devices based on the retrieving.
Some examples of the method, apparatuses, and non-transitory computer-readable medium described herein may further include operations, features, means, or instructions for retrieving, based on the feedback, the PDCP SDU from a retransmission buffer implemented at the PDCP layer, encoding the set of PDCP PDUs according to the one or more network coding parameters to obtain a set of re-encoded PDCP PDUs based on the retrieving, and transmitting the set of re-encoded PDCP PDUs to the one or more receiving devices.
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 a receiving device of the one or more receiving devices, feedback for the set of encoded PDCP PDUs indicating that the receiving device was able to obtain the 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, from the receiving device, an indication of a quantity of encoded PDCP PDUs used by the receiving device to obtain the PDCP SDU, and adjusting a code rate of the one or more network coding parameters based on the indicated quantity of encoded PDCP PDUs.
Some examples of the method, apparatuses, and non-transitory computer-readable medium described herein may further include operations, features, means, or instructions for configuring a radio link control layer at the transmitting device to operate a transparent mode or an unacknowledged mode, where the encoding at the PDCP layer may be based on the configuring.
A method for wireless communication at a receiving device is described. The method may include receiving, at a PDCP layer of the receiving device, a set of PDCP PDUs and a corresponding set of PDCP PDU headers from a transmitting device, the set of PDCP PDUs and the corresponding set of PDCP PDU headers corresponding to a PDCP SDU, decoding, at the PDCP layer, at least a subset of the set of PDCP PDUs based on one or more  network coding parameters and the corresponding set of PDCP PDU headers, the one or more network coding parameters including a rateless code, generating a report based on the decoding, where the report indicates whether the PDCP SDU was obtained from the set of PDCP PDUs, and transmitting the report to the transmitting device.
An apparatus for wireless communication at a receiving device is described. The apparatus may include a processor, memory in electronic communication 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 PDCP layer of the receiving device, a set of PDCP PDUs and a corresponding set of PDCP PDU headers from a transmitting device, the set of PDCP PDUs and the corresponding set of PDCP PDU headers corresponding to a PDCP SDU, decode, at the PDCP layer, at least a subset of the set of PDCP PDUs based on one or more network coding parameters and the corresponding set of PDCP PDU headers, the one or more network coding parameters including a rateless code, generate a report based on the decoding, where the report indicates whether the PDCP SDU was obtained from the set of PDCP PDUs, and transmit the report to the transmitting device.
Another apparatus for wireless communication at a receiving device is described. The apparatus may include means for receiving, at a PDCP layer of the receiving device, a set of PDCP PDUs and a corresponding set of PDCP PDU headers from a transmitting device, the set of PDCP PDUs and the corresponding set of PDCP PDU headers corresponding to a PDCP SDU, means for decoding, at the PDCP layer, at least a subset of the set of PDCP PDUs based on one or more network coding parameters and the corresponding set of PDCP PDU headers, the one or more network coding parameters including a rateless code, means for generating a report based on the decoding, where the report indicates whether the PDCP SDU was obtained from the set of PDCP PDUs, and means for transmitting the report to the transmitting device.
A non-transitory computer-readable medium storing code for wireless communication at a receiving device is described. The code may include instructions executable by a processor to receive, at a PDCP layer of the receiving device, a set of PDCP PDUs and a corresponding set of PDCP PDU headers from a transmitting device, the set of PDCP PDUs and the corresponding set of PDCP PDU headers corresponding to a PDCP SDU, decode, at the PDCP layer, at least a subset of the set of PDCP PDUs based on one or  more network coding parameters and the corresponding set of PDCP PDU headers, the one or more network coding parameters including a rateless code, generate a report based on the decoding, where the report indicates whether the PDCP SDU was obtained from the set of PDCP PDUs, 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 performing, at the PDCP layer after decoding at least the subset of the set of PDCP PDUs and obtaining the PDCP SDU, an integrity verification and deciphering function on the 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 determining that at least a minimum quantity of PDCP PDUs of the set of PDCP PDUs may have been received, where the decoding may be based on determining that at least the minimum quantity of PDCP PDUs may have been received.
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 minimum quantity of PDCP PDUs in the set of PDCP PDUs via radio resource control signaling.
Some examples of the method, apparatuses, and non-transitory computer-readable medium described herein may further include operations, features, means, or instructions for obtaining the PDCP SDU from the subset of the set of PDCP PDUs, and refraining from decoding a remaining subset of the set of PDCP PDUs based on obtaining the 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 indicating, to the transmitting device, a quantity of PDCP PDUs used by the receiving device to obtain the 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 determining that the PDCP SDU cannot be obtained from the set of PDCP PDUs, where the report indicates that the receiving device was unable to obtain the 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 monitoring for a retransmission of the set of PDCP PDUs based on transmitting the report.
In some examples of the method, apparatuses, and non-transitory computer-readable medium described herein, the determining may be based on receiving all PDCP PDUs of the set of PDCP PDUs.
In some examples of the method, apparatuses, and non-transitory computer-readable medium described herein, the PDCP SDU may be included in a set of PDCP SDUs, the receiving device may be unable to obtain one or more PDCP SDUs in the set of PDCP SDUs, and the report includes a sequence number of the PDCP SDU based on the PDCP SDU having a lowest sequence number among the one or more PDCP SDUs that the receiving device may be unable to obtain.
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 in a set of PDCP SDUs having a sequence number greater than the sequence number of the PDCP SDU, whether the receiving device was able to successfully obtain or was not able to obtain 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 identifying, within each PDU header of the set of PDU headers, a field indicating an index for an associated PDCP PDU corresponding to the PDCP SDU, where the set of PDCP PDUs may be decoded based on an ordering corresponding to the index.
Some examples of the method, apparatuses, and non-transitory computer-readable medium described herein may further include operations, features, means, or instructions for identifying, within a PDU header of the set of PDU headers, a flag indicating that an associated PDCP PDU may be a last PDCP PDU of the set of PDCP PDUs corresponding to the 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  identifying, within each PDU header of the set of PDU headers, a repair field indicating whether an associated PDCP PDU may be a repaired PDCP PDU.
Some examples of the method, apparatuses, and non-transitory computer-readable medium described herein may further include operations, features, means, or instructions for configuring a radio link control layer at the receiving device for a transparent mode or an unacknowledged mode, where the decoding at the PDCP layer may be based on the configuring.
In some examples of the method, apparatuses, and non-transitory computer-readable medium described herein, receiving the set of PDCP PDUs may include operations, features, means, or instructions for receiving a set of source PDCP PDUs and a set of parity PDCP PDUs.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 illustrates an example of a system for wireless communications that supports rateless coding at a packet data convergence protocol (PDCP) layer in accordance with aspects of the present disclosure.
FIG. 2 illustrates an example of a PDCP entity that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure.
FIG. 3 illustrates an example of a PDCP configuration that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure.
FIG. 4 illustrates an example of a PDCP protocol data unit (PDU) format that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure.
FIG. 5 illustrates an example of a PDCP PDU format that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure.
FIG. 6 illustrates an example of a PDCP configuration that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure.
FIGs. 7 and 8 show block diagrams of devices that support rateless coding at a PDCP layer in accordance with aspects of the present disclosure.
FIG. 9 shows a block diagram of a communication manager that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure.
FIG. 10 shows a diagram of a system including a user equipment (UE) that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure.
FIG. 11 shows a diagram of a system including a base station that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure.
FIGs. 12 through 17 show flowcharts illustrating methods that support rateless coding at a PDCP layer 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 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 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. However, application of such rateless codes at the network layer may add latency to communications as data must be passed from the network layer to other layers within the protocol stack for additional processing/packaging before transmissions, and then make its way back up the protocol stack back to the network layer for final processing/recovery of the data. This process at the transmitting and receiving side may result in intolerable traffic delays for the data being communicated within the wireless network.
In some wireless communication systems, layer 2 (L2) retransmission may not be supported for at least some types of transmissions (e.g., single-point to multi-point, multi-cast, broadcast, etc. ) , which may negatively impact reliability. Extending the maximum number retransmissions in a lower layer, however, (e.g., using HARQ techniques) may be  inefficient and result in a potentially long latency. And employing a 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 introduce undesired complexities, latencies, or inefficiencies if used to correct residual errors of lower layers. For example, the use of RLC AM technique may require unicast retransmission and thus may be undesirable for use in a broadcast system where data is initially broadcast.
The use of rateless codes (e.g., fountain codes) , which may also be referred to as network coding, at the packet data convergence protocol (PDCP) layer may support L2 retransmission, including in a broadcast context and thus provide reliability or other benefits that may be appreciated by one or ordinary skill in the art. Aspects of the disclosure are initially described in the context of wireless communications systems. At the PDCP layer of a transmitting device (e.g., a lower layer within the protocol stack below the network layer and within L2) , PDCP service data units (SDUs) may be encoded using a rateless code (e.g., a network code, outer code, etc. ) . For example, a transmitting device (e.g., a user equipment (UE) and/or base station performing a transmission) may receive a set of PDCP SDUs at the PDCP layer. The set of PDCP SDUs may correspond to a payload of data (e.g., packets) for transmission to receiving device (s) (e.g., a UE (s) and/or base station (s) receiving the transmission) . The transmitting device may use the rateless code to segment a PDCP SDU into multiple source PDCP protocol data units (PDUs) and encode the set of PDCP PDUs to generate, create, obtain, etc., a set of encoded PDCP PDUs, including the source PDCP PDUs and a set of parity PDCP PDUs. The set of encoded PDCP PDUs may then be passed down to the lower layer (s) for transmission to the receiving devices.
The receiving device may receive the transmission and provide the set of encoded PDCP PDUs to the PDCP layer for decoding. The receiving device may decode a set of encoded PDCP PDUs to obtain a PDCP SDU. For example, the receiving device may receive a threshold quantity of PDCP PDUs of a PDCP SDU (e.g., source PDCP PDUs and parity PDCP PDUs) , rearrange/reassemble the PDCP PDUs, and then use the rateless code to decode the set of encoded PDCP PDUs to obtain the corresponding PDCP SDU. The PDCP SDU (e.g., obtained based on decoding using the rateless code) may be passed or otherwise provided to an upper layer of the receiving device for further processing/recovery of the PDCP SDU.
Aspects of the disclosure are initially described in the context of wireless communications systems. Aspects of the disclosure are further illustrated by and described with reference to apparatus diagrams, system diagrams, and flowcharts that relate to rateless coding at a PDCP layer.
FIG. 1 illustrates an example of a wireless communications system 100 that supports rateless coding at a PDCP layer 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.
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.
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) .
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 layer 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 UEs 115 and the base stations 105 may support retransmissions of data to increase the likelihood that data is received successfully. Hybrid automatic repeat request (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., automatic repeat request (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.
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 multiple-access systems capable of supporting communication with multiple users by sharing the available system resources (e.g., time, frequency, and power) . A wireless network, for example a wireless local area network (WLAN) , such as a Wi-Fi (i.e., Institute of Electrical and Electronics Engineers (IEEE) 802.11) network may include an access point (AP) that may communicate with one or more wireless or mobile devices. The AP may be coupled to a network, such as the Internet, and may enable a mobile device to communicate via the network (or communicate with other devices coupled to the access point) . A wireless device may communicate with a network device bi-directionally. For example, in a WLAN, a device may communicate with an associated AP via downlink (e.g., the communication link from the AP to the device) and uplink (e.g., the communication link from the device to the AP) . A wireless personal area network (PAN) , which may include a Bluetooth connection, may provide for short range wireless connections between two or more paired wireless devices. For example, wireless devices such as cellular phones may utilize wireless PAN communications to exchange information such as audio signals with wireless headsets.
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. In some cases, 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.
A transmitting device (e.g., a UE 115 and/or base station 105 performing a transmission) may receive, at a PDCP layer of the transmitting device, a set of PDCP SDUs corresponding to a payload of data for transmission to one or more receiving devices. The transmitting device may encode, at the PDCP layer, the set of PDCP SDUs according to a set of network coding parameters to obtain a set of encoded PDCP PDUs, the network coding parameters comprising at least a rateless code. The transmitting device may provide the set of encoded PDCP PDUs to a lower layer of the transmitting device for transmission to the one or more receiving devices (e.g., one or more other UE (s) 115 and/or base station (s) 105 receiving the transmission) .
A receiving device (e.g., a UE 115 and/or base station 105 receiving a transmission) may receive, at a PDCP layer of the receiving device, a set of encoded PDCP PDUs from a transmitting device. The receiving device may decode, at the PDCP layer, the set of encoded PDCP PDUs according to a set of network coding parameters to obtain a set of PDCP SDUs corresponding to a payload of data, the set of network coding parameters comprising at least a rateless code. The receiving device may provide the set of PDCP SDUs to an upper layer of receiving device, the upper layer being a higher layer than the PDCP layer of the receiving device.
FIG. 2 illustrates an example of a PDCP entity 200 that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure. In some examples, the PDCP entity 200 may implement aspects of wireless communication system 100. PDCP entity 200 may include a PDCP entity 205 comprising transmitting PDCP entity 210 at a transmitting device and receiving PDCP entity 215 at a receiving device. In some aspects, the transmitting device and/or receiving device may be examples of a UE and/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) and/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 and/or a base station performing a transmission to other UE (s) and/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 205 is established between a transmitting device (e.g., transmitting PDCP entity 210) and a receiving device (e.g., receiving PDCP entity 215) 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 210) to the receiving device (s) (e.g., a PDCP PDU provided to receiving PDCP entity 215) .
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) and/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:
Figure PCTCN2020104027-appb-000001
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:
Figure PCTCN2020104027-appb-000002
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 and/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 210) 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 220. 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 225 for processing, e.g., to perform header compression of the PDCP SDU. For example, header compression 225 may modify the header of the PDCP SDU for efficiency. In some aspects, header compression 225 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 225 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 225 may be applied to user plane packets, although this may be skipped in some scenarios.
The PDCP SDU packets may leave header compression 225 and be processed by integrity protection (IP) 230 and ciphering 235 functions before being provided for header addition 245 and routing/duplication 250 for final processing before being provided to lower layers for transmission. Header addition 245 adds the PDCP header to the PDCP SDU and routing/duplication 250 routes the packet to the intended bearer, if applicable.
However, aspects of the described techniques provide for encoder 240 to be enabled, configured, implemented, or otherwise provided, at the PDCP layer of the packet before integrity protection/ciphering functions. As discussed, the encoder 240 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 215 after routing/duplication 250 processing. Accordingly, the transmitting PDCP entity 210 (e.g., the  PDCP layer in this example) may apply network coding parameters including a rateless code to the PDCP SDUs at encoder 240.
Accordingly, aspects of the described techniques permit, after integrity protection 230 and ciphering 235 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 240 may segment the PDCP SDU into one or more PDCP PDUs, in some cases referred to as source PDCP PDUs. The encoder 240 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 290.
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 245 discussed above, where a PDCP header is added to each encoded PDCP PDU and then provided to routing/duplication 250 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 or 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 215. 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 240) 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 215. 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 255 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 255.
The PDCP SDU may be decoded at decoder 260 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 260 may decode the PDCP SDU and deliver this to the deciphering 265.
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 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 cases, the network may configure 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 265, integrity verification 270, and reception buffer 275 for processing. For example, deciphering 265 may decipher the PDCP SDU, integrity verification 270 may verify the integrity of the PDCP SDU, and reception buffer 275 may store the PDCP SDU. Reception buffer 275 may provide the PDCP SDU to header compression 280, 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 265, integrity verification 270, etc.
As discussed above, aspects of the described techniques may also provide HARQ 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 285 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 290 of the transmitting PDCP entity 210 may monitor for and receive the status report from PDCP status PDU 285 (e.g., the status report may be transmitted over the radio interface) and use this information to provide some degree of HARQ functionality. For example, retransmission buffer 290 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 290 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 240 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 and/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.
FIG. 3 illustrates an example of a PDCP configuration 300 that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure. In some examples, the PDCP configuration 300 may implement aspects of wireless communication system 100.
A transmitting device may identify a PDCP SDU 305 for transmission to one or more receiving devices and prepare the PDCP SDU 305 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 305 with integrity protection and ciphering.
To perform network coding at the PDCP layer, the transmitting device may segment the PDCP SDU 305 into a set of source PDCP PDUs 310. For example, the transmitting device may segment the PDCP SDU 305 into source PDCP PDU 310-a through 310-m. In some cases, the transmitting device may be configured with a size or number of source PDCP PDUs 310 to segment the PDCP SDU into.
The transmitting device may encode the set of source PDCP PDUs 310 according to a set of network coding parameters. In some cases, encoding the source PDCP PDUs 310 according to the set of network coding parameters may generate a set of parity PDCP PDUs 315.
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 310 and encoded parity PDCP PDUs 315, where the combined quantity of encoded source PDUs 310 and encoded parity PDCP PDUs 315 (e.g., the total quantity of encoded PDUs in the set of encoded PDCP PDUs) relative to the quantity of segmented source PDUs 310 is based on (e.g., equal to) the code rate. In addition to the encoded source PDUs 310, the transmitting device may generate N parity PDCP PDUs 315 to achieve the code rate, from parity PDCP PDU 315-a to parity PDCP PDU 315-n. Therefore, the transmitting device may generate a set of encoded PDCP PDUs, including the source PDCP PDUs 310 and the parity PDCP PDUs 315.
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 the minimum number of encoded parity PDCP PDUs 315, or other parameters described elsewhere herein. The transmitting device may encode the source PDCP PDUs 310 to generate encoded PDCP PDUs 310 and encoded parity PDCP PDUs 315 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 320 for the set of encoded PDCP PDUs. Each PDCP PDU of the set of encoded PDCP PDUs (e.g., including source PDCP PDUs 310 and parity PDCP PDUs 315) may have a PDU header prepended. The PDU header 320 may be an example of a PDU header 405 or a PDU header 505 described with reference to FIGs. 4 and 5, respectively. The PDU header 320 may, in some cases, include fields or parameters related to the network coding.
After prepending the PDU headers 320 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.
FIG. 4 illustrates an example of a PDCP PDU format 400 that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure. In some examples, PDCP PDU format 400 may implement aspects of wireless communication system 100.
PDCP PDU format 400 may include an example of a PDU header 405 which may be added to network coded PDCP PDUs. For example, the PDU header 405 may be prepended to a source PDCP PDUs and parity PDCP PDUs corresponding to a PDCP SDU. The PDCP PDU format 400 may be an example of a PDU header 405 with a 12-bit PDCP  sequence number. The PDU header 405 may include, for example, 4 octaves of 8 bits (e.g., b0 through b7) .
A transmitting device may segment a PDCP SDU into source PDCP PDUs and perform network coding to the source PDCP PDUs to generate parity PDCP PDUs. The transmitting device may generate PDU headers for the set of encoded PDCP PDUs, including the source PDCP PDUs and parity PDCP PDUs. Each PDCP PDU of the set of encoded PDCP PDUs may have a PDU header 405. The PDU header 405 for a PDCP PDU may include a data or control field 410, which may indicate whether the PDCP PDU includes data or control information.
In some cases, the PDU header 405 may include one or more fields which may be based on the network coding. For example, PDU header 405 may include P field 415. The P field 415 may indicate whether the PDU requests a status report (e.g., HARQ feedback, a PDCP status PDU, etc. ) from the receiver or not.
The PDU header 405 may include a T field 420, which may indicate whether the PDCP PDU is a repaired PDU (e.g., a retransmitted PDU or a PDU corresponding to an SDU for which one or more PDUs were previously transmitted) or not. For example, if the transmitting device is sending a retransmission of a PDCP SDU which was unsuccessfully received by one or more receiving devices, the transmitting device may retransmit PDCP PDUs corresponding to the PDCP SDU, and the transmitting device may indicate whether the PDCP PDUs for the retransmissions are repaired (e.g., retransmissions) or not. Indicating whether the PDCP PDU is repaired may assist receiving devices in obtaining or successfully decoding a missed PDCP SDU.
The PDU header 405 may include an L field 425, which may indicate whether the PDCP PDU is a last PDCP PDU corresponding to a PDCP SDU. By indicating a last PDCP PDU of the set of encoded PDCP PDUs, the transmitting device may indicate when all encoded PDCP PDUs corresponding to a PDCP SDU have been transmitted. If a receiving device cannot successfully decode and obtain the PDCP SDU after receiving all of the encoded PDCP PDUs corresponding to the PDCP SDU, the receiving device may determine that the PDCP SDU cannot be obtained, and the receiving device may consider the PDCP SDU as missing.
The PDU header 405 may include PDCP  sequence number fields  430 and 435, where a value for the PDCP  sequence number fields  430 and 435 correspond to a PDCP SDU. In some cases, the sequence number of the PDCP SDU may be associated with a count value configured at the transmitting device. For example, the transmitting device may set the PDCP sequence number field 430 in the PDU header 405 to indicate which PDCP SDU the PDCU PDU is associated with. The PDU header 405 may use 12 bits in the PDCP  sequence number fields  430 and 435 to indicate the PDCP sequence number.
In some cases, the PDU header 405 may include a sub-sequence number field 440. The sub-sequence number field 440 may indicate an index of the PDCP PDU corresponding to the PDCP SDU. The sub-sequence number field 440 may be used to indicate an ordering for the encoded set of PDC PDPUs. For example, if the transmitting device generates a set of K data PDCP PDUs, the sub-sequence number of a PDU header may indicate the index of the corresponding PDCP PDU in the K data PDCP PDUs. The sub-sequence number may be used at the one or more receiving devices to organize the received PDCP data PDUs and obtain the corresponding PDCP SDU. In some cases, the sub-SN field may be an 8-bit field, indicating indexes for up to 256 encoded PDCP PDUs corresponding to a single PDCP SDUs.
In some cases, the PDU header 405 may be prepended to a PDCP payload including one or more fields including data and message authentication code –integrity (MAC-I) information. For example, the PDCP PDU payload may include one or more octaves, or bytes, for the data and MAC-I information, such as field 445 through field 450.
FIG. 5 illustrates an example of a PDCP PDU format 500 that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure. In some examples, PDCP PDU format 500 may implement aspects of wireless communication system 100.
PDCP PDU format 500 may include an example of a PDU header 505 which may be added to network coded PDCP PDUs. For example, the PDU header 505 may be prepended to a source PDCP PDUs and parity PDCP PDUs corresponding to a PDCP SDU. The PDCP PDU format 500 may be an example of a PDU header 505 with a 20-bit PDCP sequence number. The PDU header 505 may include, for example, 4 octaves of 8 bits (e.g., b0 through b7) .
A transmitting device may segment a PDCP SDU into source PDCP PDUs and perform network coding to the source PDCP PDUs to generate parity PDCP PDUs. The transmitting device may generate PDU headers for the set of encoded PDCP PDUs, including the source PDCP PDUs and parity PDCP PDUs. Each PDCP PDU of the set of encoded PDCP PDUs may have a PDU header 505. The PDU header 505 for a PDCP PDU may include a data or control field 510, which may indicate whether the PDCP PDU includes data or control information.
In some cases, the PDU header 505 may include one or more fields which may be based on the network coding. For example, PDU header 505 may include P field 515. The P field 515 may indicate whether the PDU requests a status report (e.g., HARQ feedback, a PDCP status PDU, etc. ) from the receiver or not.
The PDU header 505 may include a T field 520, which may indicate whether the PDCP PDU is a repaired PDU (e.g., a retransmitted PDU or a PDU corresponding to an SDU for which one or more PDUs were previously transmitted) or not. For example, if the transmitting device is sending a retransmission of a PDCP SDU which was unsuccessfully received by one or more receiving devices, the transmitting device may retransmit PDCP PDUs corresponding to the PDCP SDU, and the transmitting device may indicate whether the PDCP PDUs for the retransmissions are repaired (e.g., retransmissions) or not. Indicating whether the PDCP PDU is repaired may assist receiving devices in obtaining or successfully decoding a missed PDCP SDU.
The PDU header 505 may include an L field 525, which may indicate whether the PDCP PDU is a last PDCP PDU corresponding to a PDCP SDU. By indicating a last PDCP PDU of the set of encoded PDCP PDUs, the transmitting device may indicate when all encoded PDCP PDUs corresponding to a PDCP SDU have been transmitted. If a receiving device cannot successfully decode and obtain the PDCP SDU after receiving all of the encoded PDCP PDUs corresponding to the PDCP SDU, the receiving device may determine that the PDCP SDU cannot be obtained, and the receiving device may consider the PDCP SDU as missing. In some cases, the PDU header 505 may include one or more R fields 530. The R fields 530 may be reserved fields for some additional or alternative function of the PDCP PDU.
The PDU header 505 may include PDCP sequence number fields 535, 540-a, and 540-b, where a value for the PDCP  sequence number fields  535 and 540 may correspond to a PDCP SDU. In some cases, the sequence number of the PDCP SDU may be associated with a count value configured at the transmitting device. For example, the transmitting device may set the PDCP  sequence number field  535 and 540 in the PDU header 505 to indicate which PDCP SDU the PDCU PDU is associated with. The PDU header 505 may use 20 bits across the PDCP  sequence number fields  535 and 540 to indicate the PDCP sequence number.
In some cases, the PDU header 505 may include a sub-sequence number field 545. The sub-sequence number field 545 may indicate an index of the PDCP PDU corresponding to the PDCP SDU. The sub-sequence number field 545 may be used to indicate an ordering for the encoded set of PDC PDPUs. For example, if the transmitting device generates a set of K data PDCP PDUs, the sub-sequence number of a PDU header may indicate the index of the corresponding PDCP PDU in the K data PDCP PDUs. The sub-sequence number may be used at the one or more receiving devices to organize the received PDCP data PDUs and obtain the corresponding PDCP SDU. In some cases, the sub-SN field may be an 8-bit field, indicating indexes for up to 256 encoded PDCP PDUs corresponding to a single PDCP SDUs.
In some cases, the PDU header 505 may be prepended to a PDCP PDU payload including one or more fields for data and MAC-I information. For example, the PDCP PDU payload may include one or more octaves, or bytes, for the data and MAC-I information, such as field 550 through field 555.
FIG. 6 illustrates an example of a PDCP configuration 600 that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure. In some examples, PDCP configuration 600 may implement aspects of wireless communication system 100.
A receiving device may receive at least a subset of the set of encoded PDCP data PDUs and attempt to obtain a PDCP SDU 605 from the encoded PDCP data PDUs. The set of encoded PDCP data PDUs may include source PDCP PDUs 615 and parity PDCP PDUs 620. For example, the receiving device may receive PDCP PDUs 615-a and 615-b through 615-n and parity PDCP PDUs 620-a through 620-n. Each PDCP PDU may have a PDU header 610,  which may be an example of a  PDU header  405 or 505 as described with reference to FIGs. 4 and 5, respectively.
The receiving device may attempt to assemble (e.g., obtain, decode) the PDCP SDU 605 from the received PDCP PDUs. In some cases, the receiving device may begin assembling the PDCP SDU 605 after receiving a minimum number of corresponding PDCP PDUs. For example, the receiving device may be unable to retrieve the PDCP SDU 605 prior to receiving a certain number of corresponding PDCP PDUs (e.g., based on the network coding procedure) , so the receiving device may wait to receive at least the minimum number of PDCP PDUs before attempting to reassemble the PDCP SDU 605.
In some cases, the receiving device may reassemble a PDCP SDU 605 based on information in the PDU headers 610. For example, the receiving device may organize received PDCP PDUs according to associated PDCP SDUs 605. For example, the PDU headers 610 for each of the source PDCP PDUs 615 and parity PDCP PDUs 620 may include a field associating the PDCP PDUs with the PDCP SDU 605. In some cases, the receiving device may organize received PDCP data PDUs associated with a PDCP SDU based on the sub-sequence number indexes of the received PDCP data PDUs. For example, the PDU header 610 may indicate an ordering for the PDCP PDUs, and the receiving device may organize, for example, source PDCP PDU 615-a before source PDCP PDU 615-b based on the indexes.
In some examples, the receiving device may be able to reassemble the PDCP SDU 605 from received PDCP PDUs. The receiving device may store the PDCP SDU 605 in a reception buffer for in-order delivery of PDCP SDUs. In some cases, once a PDCP SDU is obtained, the receiving device may stop decoding or discard any additional received PDCP data PDUs associated with the obtained PDCP SDU 605. For example, the receiving device may not use all of the parity PDCP PDUs 620 to obtain the PDCP SDU 605. The receiving device may discard any additional PDCP PDUs 615 and/or parity PDCP PDUs 620 after obtaining the PDCP SDU 605. This may reduce packet decoding latency and processing time at the receiving device.
In some cases, the receiving device may record a number of PDCP PDUs used to successfully decode a PDCP SDU, or an average number of PDCP PDUs used to successfully decode each PDCP SDU of a set of PDCP SDUs. For example, if the receiving device  successfully decodes the PDCP SDU without using all of the transmitted set of encoded PDCP PDUs, the receiving device may report how many PDCP PDUs were used to obtain the PDCP SDU to the transmitting device, and a code rate may be adjusted at the transmitting device.
If the receiving device cannot assemble a PDCP SDU 605 after receiving all of the PDCP data PDUs associated with the PDCP SDU 605, the receiving device may consider the PDCP SDU missing. For example, if the receiving device cannot assemble the PDCP SDU 605 after receiving all source PDCP data PDUs associated with the PDCP SDU and all parity PDCP data PDUs associated with the PDCP SDU, the receiving device may identify the PDCP SDU as missing. In some cases, the receiving device may determine that all of the encoded set of PDCP data PDUs have been received based on receiving a PDCP data PDU with a flag in the PDU header 610 set indicating the PDCP data PDU is a last PDCP data PDU. For example, PDU header 610-e may include a field which is set to indicate that parity PDCP PDU 620-n is the last PDP PDU of a set of encoded PDCP PDUs associated with the PDCP SDU 605.
The receiving device may generate a PDCP status PDU for the PDCP SDU 605 and transmit the PDCP status PDU to the transmitting device. In some cases, a PDCP status PDU may provide feedback for one or more PDCP SDUs including the PDCP SDU 605. The PDCP status PDU may include a field indicating the sequence number of a next not received PDCP SDU. For example, if the receiving device cannot obtain the PDCP SDU 605 from the set of encoded PDCP PDUs, the receiving device may indicate the sequence number of the PDCP SDU 605. In some cases, this may initiate a retransmission procedure, and the receiving device may receive a retransmission of PDCP PDUs corresponding to the PDCP SDU 605 or repaired PDCP DPUs for the PDCP SDU 605. If the receiving device can obtain the PDCP SDU 605, the receiving device may indicate a sequence number of a following PDCP SDU.
In some cases, the PDCP status PDU may include an indicator of a number of PDCP PDUs used to assemble the PDCP SDU 605, or an average number of PDCP PDUs used to assemble a set of PDCP SDUs that includes the PDCP SDU 605. For example, the receiving device may not have used all of the parity PDCP PDUs 620 to obtain the PDCP SDU 605, and the receiving device may indicate how many PDCP PDUs were used to obtain  the PDCP SDU 605. Based on indicating the number of PDCP PDUs used to successfully receive a PDCP SDU, the transmitting device may adjust a code rate for communications with the one or more receiving devices. In some cases, the transmitting device may receive multiple PDCP status PDUs from multiple receiving devices, and the transmitting device may adjust the code rate based on a largest number of PDCP PDUs used to obtain the PDCP SDU. This may ensure reliable communications with each of the multiple receiving devices.
In some examples, the PDCP status PDU may include a bitmap to indicate missing PDCP SDUs or correctly received PDCP SDUs. For example, the bitmap may indicate which SDUs are missing and which SDUs are correctly received by the receiving device. Each bit of the bitmap may correspond to a different PDCP SDU. In an example, if a bit of the bitmap is toggled (e.g., “1” ) , then an associated PDCP SDU may have been successfully received at the receiving device, and if the bit is not toggled (e.g., “0” ) , then the associated PDCP SDU may be missing at the receiving device.
FIG. 7 shows a block diagram 700 of a device 705 that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure. The device 705 may be an example of aspects of a UE 115 or base station 105 as described herein. The device 705 may include a receiver 710, a communication manager 715, and a transmitter 720. The device 705 may also include a processor. Each of these components may be in communication with one another (e.g., via one or more buses) .
The receiver 710 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 rateless coding at a PDCP layer, etc. ) . Information may be passed on to other components of the device 705. The receiver 710 may be an example of aspects of the transceiver 1015 described with reference to FIG. 10. The receiver 710 may utilize a single antenna or a set of antennas.
The communication manager 715 may segment a PDCP SDU into a set of PDCP PDUs at a PDCP layer of the transmitting device, encode, at the PDCP layer, the set of PDCP PDUs according to one or more network coding parameters to obtain a set of encoded PDCP PDUs, the one or more network coding parameters including a rateless code, generate, for the set of encoded PDCP PDUs, a corresponding set of PDU headers, and output the set of encoded PDCP PDUs and the corresponding set of PDU headers from the PDCP layer to a  lower layer of the transmitting device for transmission to one or more receiving devices. The communication manager 715 may also receive, at a PDCP layer of the receiving device, a set of PDCP PDUs and a corresponding set of PDCP PDU headers from a transmitting device, the set of PDCP PDUs and the corresponding set of PDCP PDU headers corresponding to a PDCP SDU, decode, at the PDCP layer, at least a subset of the set of PDCP PDUs based on one or more network coding parameters and the corresponding set of PDCP PDU headers, the one or more network coding parameters including a rateless code, generate a report based on the decoding, where the report indicates whether the PDCP SDU was obtained from the set of PDCP PDUs, and transmit the report to the transmitting device. The communication manager 715 may be an example of aspects of the  communication manager  1010 or 1110 as described herein.
The communication manager 715, 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 communication manager 715, or its sub-components may be executed by a general-purpose processor, a DSP, an application-specific integrated circuit (ASIC) , a 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 communication manager 715, 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 communication manager 715, or its sub-components, may be a separate and distinct component in accordance with various aspects of the present disclosure. In some examples, the communication manager 715, 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.
The actions performed by the communication manager 715as described herein may be implemented to realize one or more potential advantages. One implementation may allow a transmitting or receiving device to support Layer 2 retransmission schemes without  significant latency by supporting network coding at the PDCP layer. Additionally, network coding at the PDCP layer may increase reliability for communication of PDCP SDUs.
The transmitter 720 may transmit signals generated by other components of the device 705. In some examples, the transmitter 720 may be collocated with a receiver 710 in a transceiver module. For example, the transmitter 720 may be an example of aspects of the transceiver 1015 described with reference to FIG. 10. The transmitter 720 may utilize a single antenna or a set of antennas.
FIG. 8 shows a block diagram 800 of a device 805 that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure. The device 805 may be an example of aspects of a device 705, a UE 115, or a base station 105 as described herein. The device 805 may include a receiver 810, a communication manager 815, and a transmitter 855. 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) .
The 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 rateless coding at a PDCP layer, 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 1015 described with reference to FIG. 10. The receiver 810 may utilize a single antenna or a set of antennas.
The communication manager 815 may be an example of aspects of the communication manager 715 as described herein. The communication manager 815 may include a PDCP SDU manager 820, a PDCP encoding manager 825, a PDCP PDU manager 830, a PDCP PDU outputting manager 835, a PDCP decoding manager 840, a PDCP SDU report manager 845, and a report transmitting manager 850. The communication manager 815 may be an example of aspects of the  communication manager  1010 or 1110 as described herein.
The PDCP SDU manager 820 may segment a PDCP SDU into a set of PDCP PDUs at a PDCP layer of the transmitting device. The PDCP encoding manager 825 may encode, at the PDCP layer, the set of PDCP PDUs according to one or more network coding parameters to obtain a set of encoded PDCP PDUs, the one or more network coding parameters including a rateless code. The PDCP PDU manager 830 may generate, for the set  of encoded PDCP PDUs, a corresponding set of PDU headers. The PDCP PDU outputting manager 835 may output the set of encoded PDCP PDUs and the corresponding set of PDU headers from the PDCP layer to a lower layer of the transmitting device for transmission to one or more receiving devices.
The PDCP PDU manager 830 may receive, at a PDCP layer of the receiving device, a set of PDCP PDUs and a corresponding set of PDCP PDU headers from a transmitting device, the set of PDCP PDUs and the corresponding set of PDCP PDU headers corresponding to a PDCP SDU. The PDCP decoding manager 840 may decode, at the PDCP layer, at least a subset of the set of PDCP PDUs based on one or more network coding parameters and the corresponding set of PDCP PDU headers, the one or more network coding parameters including a rateless code. The PDCP SDU report manager 845 may generate a report based on the decoding, where the report indicates whether the PDCP SDU was obtained from the set of PDCP PDUs. The report transmitting manager 850 may transmit the report to the transmitting device.
The transmitter 855 may transmit signals generated by other components of the device 805. In some examples, the transmitter 855 may be collocated with a receiver 810 in a transceiver module. For example, the transmitter 855 may be an example of aspects of the transceiver 1015 described with reference to FIG. 10. The transmitter 855 may utilize a single antenna or a set of antennas.
FIG. 9 shows a block diagram 900 of a communication manager 905 that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure. The communication manager 905 may be an example of aspects of a communication manager 715, a communication manager 815, or a communication manager 1010 described herein. The communication manager 905 may include a PDCP SDU manager 910, a PDCP encoding manager 915, a PDCP PDU manager 920, a PDCP PDU outputting manager 925, an integrity protection and ciphering manager 930, a PDU header manager 935, a feedback manager 940, a RLC layer manager 945, a PDCP decoding manager 950, a PDCP SDU report manager 955, a report transmitting manager 960, and an integrity verification and deciphering manager 965. Each of these modules may communicate, directly or indirectly, with one another (e.g., via one or more buses) .
The PDCP SDU manager 910 may segment a PDCP SDU into a set of PDCP PDUs at a PDCP layer of the transmitting device. The PDCP encoding manager 915 may encode, at the PDCP layer, the set of PDCP PDUs according to one or more network coding parameters to obtain a set of encoded PDCP PDUs, the one or more network coding parameters including a rateless code. In some examples, encode the set of PDCP PDUs includes encoding the set of source PDCP PDUs to obtain a set of encoded source PDCP PDUs and a set of encoded parity PDCP PDUs. In some examples, the PDCP encoding manager 915 may receive an indication of the minimum code rate for the set of encoded PDCP PDUs via radio resource control signaling. In some cases, the set of PDCP PDUs includes a set of source PDCP PDUs.
The PDCP PDU manager 920 may generate, for the set of encoded PDCP PDUs, a corresponding set of PDU headers. In some examples, the PDCP PDU manager 920 may receive, at a PDCP layer of the receiving device, a set of PDCP PDUs and a corresponding set of PDCP PDU headers from a transmitting device, the set of PDCP PDUs and the corresponding set of PDCP PDU headers corresponding to a PDCP SDU. In some examples, the PDCP PDU manager 920 may store the PDCP SDU or the set of encoded PDCP PDUs in a retransmission buffer implemented at the PDCP layer. The PDCP PDU outputting manager 925 may output the set of encoded PDCP PDUs and the corresponding set of PDU headers from the PDCP layer to a lower layer of the transmitting device for transmission to one or more receiving devices.
The PDCP decoding manager 950 may decode, at the PDCP layer, at least a subset of the set of PDCP PDUs based on one or more network coding parameters and the corresponding set of PDCP PDU headers, the one or more network coding parameters including a rateless code. In some examples, the PDCP decoding manager 950 may determine that at least a minimum quantity of PDCP PDUs of the set of PDCP PDUs has been received, where the decoding is based on determining that at least the minimum quantity of PDCP PDUs has been received. In some examples, the PDCP decoding manager 950 may receive an indication of the minimum quantity of PDCP PDUs in the set of PDCP PDUs via radio resource control signaling.
In some examples, the PDCP decoding manager 950 may obtain the PDCP SDU from the subset of the set of PDCP PDUs. In some examples, the PDCP decoding manager  950 may refrain from decoding a remaining subset of the set of PDCP PDUs based on obtaining the PDCP SDU. In some examples, the PDCP decoding manager 950 may receive a set of source PDCP PDUs and a set of parity PDCP PDUs.
The PDCP SDU report manager 955 may generate a report based on the decoding, where the report indicates whether the PDCP SDU was obtained from the set of PDCP PDUs. In some examples, the PDCP SDU report manager 955 may indicate, to the transmitting device, a quantity of PDCP PDUs used by the receiving device to obtain the PDCP SDU. In some examples, the PDCP SDU report manager 955 may determine that the PDCP SDU cannot be obtained from the set of PDCP PDUs, where the report indicates that the receiving device was unable to obtain the PDCP SDU. In some examples, the PDCP SDU report manager 955 may monitor for a retransmission of the set of PDCP PDUs based on transmitting the report.
In some examples, the PDCP SDU report manager 955 may identify, within each PDU header of the set of PDU headers, a field indicating an index for an associated PDCP PDU corresponding to the PDCP SDU, where the set of PDCP PDUs are decoded based on an ordering corresponding to the index. In some cases, the PDCP SDU is included in a set of PDCP SDUs. In some cases, the receiving device is unable to obtain one or more PDCP SDUs in the set of PDCP SDUs.
In some cases, the report includes a sequence number of the PDCP SDU based on the PDCP SDU having a lowest sequence number among the one or more PDCP SDUs that the receiving device is unable to obtain. In some cases, the report further includes a bitmap indicating, for each PDCP SDU in a set of PDCP SDUs having a sequence number greater than the sequence number of the PDCP SDU, whether the receiving device was able to successfully obtain or was not able to obtain a respective PDCP SDU. The report transmitting manager 960 may transmit the report to the transmitting device.
The integrity protection and ciphering manager 930 may perform, at the PDCP layer and before the encoding, an integrity protection and ciphering function on the PDCP SDU. The PDU header manager 935 may set, within each PDU header of the set of PDU headers, a field indicating an index for an associated encoded PDCP PDU corresponding to the PDCP SDU, where the index corresponds to an ordering for the set of encoded PDUs.
In some examples, the PDU header manager 935 may set, within a PDU header of the set of PDU headers, a flag indicating that an associated encoded PDCP PDU is a last encoded PDCP PDU of the set of encoded PDUs corresponding to the PDCP SDU. In some examples, the PDU header manager 935 may set, within each PDU header of the set of PDU headers, a repair field indicating whether an associated encoded PDCP PDU is a repaired PDCP PDU.
In some examples, the PDU header manager 935 may identify, within a PDU header of the set of PDU headers, a flag indicating that an associated PDCP PDU is a last PDCP PDU of the set of PDCP PDUs corresponding to the PDCP SDU. In some examples, the PDU header manager 935 may identify, within each PDU header of the set of PDU headers, a repair field indicating whether an associated PDCP PDU is a repaired PDCP PDU.
The feedback manager 940 may receive, from a receiving device of the one or more receiving devices, feedback for the set of encoded PDCP PDUs indicating that the receiving device was unable to obtain the PDCP SDU. In some examples, the feedback manager 940 may retrieve, based on the feedback, the set of encoded PDCP PDUs from a retransmission buffer implemented at the PDCP layer. In some examples, the feedback manager 940 may retransmit the set of encoded PDCP PDUs to the one or more receiving devices based on the retrieving. In some examples, the feedback manager 940 may retrieve, based on the feedback, the PDCP SDU from a retransmission buffer implemented at the PDCP layer.
In some examples, the feedback manager 940 may encode the set of PDCP PDUs according to the one or more network coding parameters to obtain a set of re-encoded PDCP PDUs based on the retrieving. In some examples, the feedback manager 940 may transmit the set of re-encoded PDCP PDUs to the one or more receiving devices. In some examples, the feedback manager 940 may receive, from a receiving device of the one or more receiving devices, feedback for the set of encoded PDCP PDUs indicating that the receiving device was able to obtain the PDCP SDU. In some examples, the feedback manager 940 may receive, from the receiving device, an indication of a quantity of encoded PDCP PDUs used by the receiving device to obtain the PDCP SDU. In some examples, the feedback manager 940 may adjust a code rate of the one or more network coding parameters based on the indicated quantity of encoded PDCP PDUs.
The RLC layer manager 945 may configure a radio link control layer at the transmitting device to operate a transparent mode or an unacknowledged mode, where the encoding at the PDCP layer is based on the configuring. In some examples, the RLC layer manager 945 may configure a radio link control layer at the receiving device for a transparent mode or an unacknowledged mode, where the decoding at the PDCP layer is based on the configuring. The integrity verification and deciphering manager 965 may perform, at the PDCP layer after decoding at least the subset of the set of PDCP PDUs and obtaining the PDCP SDU, an integrity verification and deciphering function on the PDCP SDU.
FIG. 10 shows a diagram of a system 1000 including a device 1005 that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure. The device 1005 may be an example of or include the components of device 705, device 805, or a UE 115 as described herein. The device 1005 may include components for bi-directional voice and data communications including components for transmitting and receiving communications, including a communication manager 1010, a transceiver 1015, an antenna 1020, memory 1025, and a processor 1035. These components may be in electronic communication via one or more buses (e.g., bus 1040) .
The communication manager 1010 may segment a PDCP SDU into a set of PDCP PDUs at a PDCP layer of the transmitting device, encode, at the PDCP layer, the set of PDCP PDUs according to one or more network coding parameters to obtain a set of encoded PDCP PDUs, the one or more network coding parameters including a rateless code, generate, for the set of encoded PDCP PDUs, a corresponding set of PDU headers, and output the set of encoded PDCP PDUs and the corresponding set of PDU headers from the PDCP layer to a lower layer of the transmitting device for transmission to one or more receiving devices. The communication manager 1010 may also receive, at a PDCP layer of the receiving device, a set of PDCP PDUs and a corresponding set of PDCP PDU headers from a transmitting device, the set of PDCP PDUs and the corresponding set of PDCP PDU headers corresponding to a PDCP SDU, decode, at the PDCP layer, at least a subset of the set of PDCP PDUs based on one or more network coding parameters and the corresponding set of PDCP PDU headers, the one or more network coding parameters including a rateless code, generate a report based on the decoding, where the report indicates whether the PDCP SDU was obtained from the set of PDCP PDUs, and transmit the report to the transmitting device.
The transceiver 1015 may communicate bi-directionally, via one or more antennas, wired, or wireless links as described above. For example, the transceiver 1015 may represent a wireless transceiver and may communicate bi-directionally with another wireless transceiver. The transceiver 1015 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 1020. However, in some cases the device may have more than one antenna 1020, which may be capable of concurrently transmitting or receiving multiple wireless transmissions.
The memory 1025 may include RAM and ROM. The memory 1025 may store computer-readable, computer-executable code 1030 including instructions that, when executed, cause the processor to perform various functions described herein. In some cases, the memory 1025 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 code 1030 may include instructions to implement aspects of the present disclosure, including instructions to support wireless communications. The code 1030 may be stored in a non-transitory computer-readable medium such as system memory or other type of memory. In some cases, the code 1030 may not be directly executable by the processor 1035 but may cause a computer (e.g., when compiled and executed) to perform functions described herein.
The processor 1035 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 1035 may be configured to operate a memory array using a memory controller. In other cases, a memory controller may be integrated into the processor 1035. The processor 1035 may be configured to execute computer-readable instructions stored in a memory (e.g., the memory 1025) to cause the device 1005 to perform various functions (e.g., functions or tasks supporting rateless coding at a PDCP layer) .
FIG. 11 shows a diagram of a system 1100 including a device 1105 that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure. The device 1105 may be an example of or include the components of device 705, device 805, or a base station 105 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 communication manager 1110, a transceiver 1115, an antenna 1120, memory 1125, and a processor 1135. These components may be in electronic communication via one or more buses (e.g., bus 1140) .
The communication manager 1110 may segment a PDCP SDU into a set of PDCP PDUs at a PDCP layer of the transmitting device, encode, at the PDCP layer, the set of PDCP PDUs according to one or more network coding parameters to obtain a set of encoded PDCP PDUs, the one or more network coding parameters including a rateless code, generate, for the set of encoded PDCP PDUs, a corresponding set of PDU headers, and output the set of encoded PDCP PDUs and the corresponding set of PDU headers from the PDCP layer to a lower layer of the transmitting device for transmission to one or more receiving devices.
The communication manager 1110 may also receive, at a PDCP layer of the receiving device, a set of PDCP PDUs and a corresponding set of PDCP PDU headers from a transmitting device, the set of PDCP PDUs and the corresponding set of PDCP PDU headers corresponding to a PDCP SDU, decode, at the PDCP layer, at least a subset of the set of PDCP PDUs based on one or more network coding parameters and the corresponding set of PDCP PDU headers, the one or more network coding parameters including a rateless code, generate a report based on the decoding, where the report indicates whether the PDCP SDU was obtained from the set of PDCP PDUs, and transmit the report to the transmitting device.
The transceiver 1115 may communicate bi-directionally, via one or more antennas, wired, or wireless links as described above. For example, the transceiver 1115 may represent a wireless transceiver and may communicate bi-directionally with another wireless transceiver. The transceiver 1115 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 1120. However, in some cases the device may have more than one antenna 1120, which may be capable of concurrently transmitting or receiving multiple wireless transmissions.
The memory 1125 may include RAM and ROM. The memory 1125 may store computer-readable, computer-executable code 1130 including instructions that, when executed, cause the processor to perform various functions described herein. In some cases, the memory 1125 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 code 1130 may include instructions to implement aspects of the present disclosure, including instructions to support wireless communications. The code 1130 may be stored in a non-transitory computer-readable medium such as system memory or other type of memory. In some cases, the code 1130 may not be directly executable by the processor 1135 but may cause a computer (e.g., when compiled and executed) to perform functions described herein.
The processor 1135 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 1135 may be configured to operate a memory array using a memory controller. In other cases, a memory controller may be integrated into the processor 1135. The processor 1135 may be configured to execute computer-readable instructions stored in a memory (e.g., the memory 1125) to cause the device 1105 to perform various functions (e.g., functions or tasks supporting rateless coding at a PDCP layer) .
FIG. 12 shows a flowchart illustrating a method 1200 that supports rateless coding at a PDCP layer in accordance with aspects of the present disclosure. The operations of method 1200 may be implemented by a UE 115 or base station 105 or its components as described herein. For example, the operations of method 1200 may be performed by a communication manager as described with reference to FIGs. 7 through 11. 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 described functions. Additionally, or  alternatively, a UE or base station may perform aspects of the described functions using special-purpose hardware.
At 1205, the UE or base station may segment a PDCP SDU into a set of PDCP PDUs at a PDCP layer of the transmitting device. The operations of 1205 may be performed according to the methods described herein. In some examples, aspects of the operations of 1205 may be performed by a PDCP SDU manager as described with reference to FIGs. 7 through 11.
At 1210, the UE or base station may encode, at the PDCP layer, the set of PDCP PDUs according to one or more network coding parameters to obtain a set of encoded PDCP PDUs, the one or more network coding parameters including a rateless code. Additionally or alternatively, the network coding parameters may further include other parameters as described elsewhere herein. The operations of 1210 may be performed according to the methods described herein. In some examples, aspects of the operations of 1210 may be performed by a PDCP encoding manager as described with reference to FIGs. 7 through 11.
At 1215, the UE or base station may generate, for the set of encoded PDCP PDUs, a corresponding set of PDU headers. The operations of 1215 may be performed according to the methods described herein. In some examples, aspects of the operations of 1215 may be performed by a PDCP PDU manager as described with reference to FIGs. 7 through 11.
At 1220, the UE or base station may output the set of encoded PDCP PDUs and the corresponding set of PDU headers from the PDCP layer to a lower layer of the transmitting device for transmission to one or more receiving devices. The operations of 1220 may be performed according to the methods described herein. In some examples, aspects of the operations of 1220 may be performed by a PDCP PDU outputting manager as described with reference to FIGs. 7 through 11.
FIG. 13 shows a flowchart illustrating a method 1300 that supports rateless coding at a PDCP layer 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 communication manager as described with reference to FIGs. 7 through 11. 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 described functions. Additionally, or  alternatively, a UE or base station may perform aspects of the described functions using special-purpose hardware.
At 1305, the UE or base station may perform, at the PDCP layer and before the encoding, an integrity protection and ciphering function on the PDCP SDU. 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 an integrity protection and ciphering manager as described with reference to FIGs. 7 through 11.
At 1310, the UE or base station may segment a PDCP SDU into a set of PDCP PDUs at a PDCP layer of the transmitting device. 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 PDCP SDU manager as described with reference to FIGs. 7 through 11.
At 1315, the UE or base station may encode, at the PDCP layer, the set of PDCP PDUs according to one or more network coding parameters to obtain a set of encoded PDCP PDUs, the one or more network coding parameters including a rateless code. Additionally or alternatively, the set of network coding parameters can include additional parameters as described elsewhere herein. 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 PDCP encoding manager as described with reference to FIGs. 7 through 11.
At 1320, the UE or base station may generate, for the set of encoded PDCP PDUs, a corresponding set of PDU headers. 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 PDCP PDU manager as described with reference to FIGs. 7 through 11.
At 1325, the UE or base station may output the set of encoded PDCP PDUs and the corresponding set of PDU headers from the PDCP layer to a lower layer of the transmitting device for transmission to one or more receiving devices. 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 PDCP PDU outputting manager as described with reference to FIGs. 7 through 11.
FIG. 14 shows a flowchart illustrating a method 1400 that supports rateless coding at a PDCP layer 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 communication manager as described with reference to FIGs. 7 through 11. 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 described functions. Additionally, or alternatively, a UE or base station may perform aspects of the described functions using special-purpose hardware.
At 1405, the UE or base station may segment a PDCP SDU into a set of PDCP PDUs at a PDCP layer of the transmitting device. 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 PDCP SDU manager as described with reference to FIGs. 7 through 11.
At 1410, the UE or base station may encode, at the PDCP layer, the set of PDCP PDUs according to one or more network coding parameters to obtain a set of encoded PDCP PDUs, the one or more network coding parameters including a rateless code. Additionally or alternatively, the set of network coding parameters can include additional parameters as described elsewhere herein. 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 PDCP encoding manager as described with reference to FIGs. 7 through 11.
At 1415, the UE or base station may generate, for the set of encoded PDCP PDUs, a corresponding set of PDU headers. 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 PDCP PDU manager as described with reference to FIGs. 7 through 11.
At 1420, the UE or base station may output the set of encoded PDCP PDUs and the corresponding set of PDU headers from the PDCP layer to a lower layer of the transmitting device for transmission to one or more receiving devices. 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 PDCP PDU outputting manager as described with reference to FIGs. 7 through 11.
At 1425, the UE or base station may receive, from a receiving device of the one or more receiving devices, feedback for the set of encoded PDCP PDUs indicating that the receiving device was unable to obtain the PDCP SDU. 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 feedback manager as described with reference to FIGs. 7 through 11.
FIG. 15 shows a flowchart illustrating a method 1500 that supports rateless coding at a PDCP layer 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 communication manager as described with reference to FIGs. 7 through 11. 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 described functions. Additionally, or alternatively, a UE or base station may perform aspects of the described functions using special-purpose hardware.
At 1505, the UE or base station may receive, at a PDCP layer of the receiving device, a set of PDCP PDUs and a corresponding set of PDCP PDU headers from a transmitting device, the set of PDCP PDUs and the corresponding set of PDCP PDU headers corresponding to a PDCP SDU. 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 PDCP PDU manager as described with reference to FIGs. 7 through 11.
At 1510, the UE or base station may decode, at the PDCP layer, at least a subset of the set of PDCP PDUs based on one or more network coding parameters and the corresponding set of PDCP PDU headers, the one or more network coding parameters including a rateless code. Additionally or alternatively, the set of network coding parameters can include additional parameters as described elsewhere herein. 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 PDCP decoding manager as described with reference to FIGs. 7 through 11.
At 1515, the UE or base station may generate a report based on the decoding, where the report indicates whether the PDCP SDU was obtained from the set of PDCP PDUs.  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 PDCP SDU report manager as described with reference to FIGs. 7 through 11.
At 1520, the UE or base station may transmit the report to the transmitting device. 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 report transmitting manager as described with reference to FIGs. 7 through 11.
FIG. 16 shows a flowchart illustrating a method 1600 that supports rateless coding at a PDCP layer 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 communication manager as described with reference to FIGs. 7 through 11. 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 described functions. Additionally, or alternatively, a UE or base station may perform aspects of the described functions using special-purpose hardware.
At 1605, the UE or base station may receive, at a PDCP layer of the receiving device, a set of PDCP PDUs and a corresponding set of PDCP PDU headers from a transmitting device, the set of PDCP PDUs and the corresponding set of PDCP PDU headers corresponding to a PDCP SDU. 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 PDCP PDU manager as described with reference to FIGs. 7 through 11.
At 1610, the UE or base station may determine that at least a minimum quantity of PDCP PDUs of the set of PDCP PDUs has been received, where the decoding is based on determining that at least the minimum quantity of PDCP PDUs has been received. 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 PDCP decoding manager as described with reference to FIGs. 7 through 11.
At 1615, the UE or base station may decode, at the PDCP layer, at least a subset of the set of PDCP PDUs based on one or more network coding parameters and the corresponding set of PDCP PDU headers, the one or more network coding parameters  including a rateless code. Additionally or alternatively, the one or more network coding parameters may include a minimum code rate, the minimum quantity of PDCP PDUs with reference to 1610, a generation or generator matrix, or the like. 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 PDCP decoding manager as described with reference to FIGs. 7 through 11.
At 1620, the UE or base station may generate a report based on the decoding, where the report indicates whether the PDCP SDU was obtained from the set of PDCP PDUs. 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 PDCP SDU report manager as described with reference to FIGs. 7 through 11.
At 1625, the UE or base station may transmit the report to the transmitting device. 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 transmitting manager as described with reference to FIGs. 7 through 11.
FIG. 17 shows a flowchart illustrating a method 1700 that supports rateless coding at a PDCP layer 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 communication manager as described with reference to FIGs. 7 through 11. 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 described functions. Additionally, or alternatively, a UE or base station may perform aspects of the described functions 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 and a corresponding set of PDCP PDU headers from a transmitting device, the set of PDCP PDUs and the corresponding set of PDCP PDU headers corresponding to a PDCP SDU. 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 PDCP PDU manager as described with reference to FIGs. 7 through 11.
At 1710, the UE or base station may decode, at the PDCP layer, at least a subset of the set of PDCP PDUs based on one or more network coding parameters and the corresponding set of PDCP PDU headers, the one or more network coding parameters including a rateless code. Additionally or alternatively, the set of network coding parameters can include additional parameters as described elsewhere herein. 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 PDCP decoding manager as described with reference to FIGs. 7 through 11.
At 1715, the UE or base station may obtain the PDCP SDU from the subset of the set of PDCP PDUs. 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 PDCP decoding manager as described with reference to FIGs. 7 through 11.
At 1720, the UE or base station may refrain from decoding a remaining subset of the set of PDCP PDUs based on obtaining the PDCP SDU. The operations of 1720 may be performed according to the methods described herein. In some examples, aspects of the operations of 1720 may be performed by a PDCP decoding manager as described with reference to FIGs. 7 through 11.
At 1725, the UE or base station may generate a report based on the decoding, where the report indicates whether the PDCP SDU was obtained from the set of PDCP PDUs. The operations of 1725 may be performed according to the methods described herein. In some examples, aspects of the operations of 1725 may be performed by a PDCP SDU report manager as described with reference to FIGs. 7 through 11.
At 1730, the UE or base station may transmit the report to the transmitting device. The operations of 1730 may be performed according to the methods described herein. In some examples, aspects of the operations of 1730 may be performed by a report transmitting manager as described with reference to FIGs. 7 through 11.
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 (66)

  1. A method for wireless communication at a transmitting device, comprising:
    segmenting a packet data convergence protocol (PDCP) service data unit (SDU) into a set of PDCP protocol data units (PDUs) at a PDCP layer of the transmitting device;
    encoding, at the PDCP layer, the set of PDCP PDUs according to one or more network coding parameters to obtain a set of encoded PDCP PDUs, the one or more network coding parameters comprising a rateless code;
    generating, for the set of encoded PDCP PDUs, a corresponding set of PDU headers; and
    outputting the set of encoded PDCP PDUs and the corresponding set of PDU headers from the PDCP layer to a lower layer of the transmitting device for transmission to one or more receiving devices.
  2. The method of claim 1, further comprising:
    performing, at the PDCP layer and before the encoding, an integrity protection and ciphering function on the PDCP SDU.
  3. The method of claim 1, wherein:
    the set of PDCP PDUs comprises a set of source PDCP PDUs; and
    encoding the set of PDCP PDUs comprises encoding the set of source PDCP PDUs to obtain a set of encoded source PDCP PDUs and a set of encoded parity PDCP PDUs.
  4. The method of claim 1, wherein generating the set of PDU headers comprises:
    setting, within each PDU header of the set of PDU headers, a field indicating an index for an associated encoded PDCP PDU corresponding to the PDCP SDU, wherein the index corresponds to an ordering for the set of encoded PDUs.
  5. The method of claim 1, wherein generating the set of PDU headers comprises:
    setting, within a PDU header of the set of PDU headers, a flag indicating that an associated encoded PDCP PDU is a last encoded PDCP PDU of the set of encoded PDUs corresponding to the PDCP SDU.
  6. The method of claim 1, wherein generating the set of PDU headers comprises:
    setting, within each PDU header of the set of PDU headers, a repair field indicating whether an associated encoded PDCP PDU is a repaired PDCP PDU.
  7. The method of claim 1, wherein the one or more network coding parameters comprise a minimum code rate for the set of encoded PDCP PDUs, and wherein a quantity of encoded PDCP PDUs included in the set of encoded PDCP PDUs is based at least in part on the minimum code rate.
  8. The method of claim 7, further comprising:
    receiving an indication of the minimum code rate for the set of encoded PDCP PDUs via radio resource control signaling.
  9. The method of claim 1, further comprising:
    storing the PDCP SDU or the set of encoded PDCP PDUs in a retransmission buffer implemented at the PDCP layer.
  10. The method of claim 1, further comprising:
    receiving, from a receiving device of the one or more receiving devices, feedback for the set of encoded PDCP PDUs indicating that the receiving device was unable to obtain the PDCP SDU.
  11. The method of claim 10, further comprising:
    retrieving, based at least in part on the feedback, the set of encoded PDCP PDUs from a retransmission buffer implemented at the PDCP layer; and
    retransmitting the set of encoded PDCP PDUs to the one or more receiving devices based at least in part on the retrieving.
  12. The method of claim 10, further comprising:
    retrieving, based at least in part on the feedback, the PDCP SDU from a retransmission buffer implemented at the PDCP layer;
    encoding the set of PDCP PDUs according to the one or more network coding parameters to obtain a set of re-encoded PDCP PDUs based at least in part on the retrieving; and
    transmitting the set of re-encoded PDCP PDUs to the one or more receiving devices.
  13. The method of claim 1, further comprising:
    receiving, from a receiving device of the one or more receiving devices, feedback for the set of encoded PDCP PDUs indicating that the receiving device was able to obtain the PDCP SDU.
  14. The method of claim 13, further comprising:
    receiving, from the receiving device, an indication of a quantity of encoded PDCP PDUs used by the receiving device to obtain the PDCP SDU; and
    adjusting a code rate of the one or more network coding parameters based at least in part on the indicated quantity of encoded PDCP PDUs.
  15. The method of claim 1, further comprising:
    configuring a radio link control layer at the transmitting device to operate a transparent mode or an unacknowledged mode, wherein the encoding at the PDCP layer is based at least in part on the configuring.
  16. A method for wireless communication at a receiving device, comprising:
    receiving, at a packet data convergence protocol (PDCP) layer of the receiving device, a set of PDCP protocol data units (PDUs) and a corresponding set of PDCP PDU headers from a transmitting device, the set of PDCP PDUs and the corresponding set of PDCP PDU headers corresponding to a PDCP service data unit (SDU) ;
    decoding, at the PDCP layer, at least a subset of the set of PDCP PDUs based at least in part on one or more network coding parameters and the corresponding set of PDCP PDU headers, the one or more network coding parameters comprising a rateless code;
    generating a report based at least in part on the decoding, wherein the report indicates whether the PDCP SDU was obtained from the set of PDCP PDUs; and
    transmitting the report to the transmitting device.
  17. The method of claim 16, further comprising:
    performing, at the PDCP layer after decoding at least the subset of the set of PDCP PDUs and obtaining the PDCP SDU, an integrity verification and deciphering function on the PDCP SDU.
  18. The method of claim 16, further comprising:
    determining that at least a minimum quantity of PDCP PDUs of the set of PDCP PDUs has been received, wherein the decoding is based at least in part on determining that at least the minimum quantity of PDCP PDUs has been received.
  19. The method of claim 18, further comprising:
    receiving an indication of the minimum quantity of PDCP PDUs in the set of PDCP PDUs via radio resource control signaling.
  20. The method of claim 16, further comprising:
    obtaining the PDCP SDU from the subset of the set of PDCP PDUs; and
    refraining from decoding a remaining subset of the set of PDCP PDUs based at least in part on obtaining the PDCP SDU.
  21. The method of claim 16, further comprising:
    indicating, to the transmitting device, a quantity of PDCP PDUs used by the receiving device to obtain the PDCP SDU.
  22. The method of claim 16, further comprising:
    determining that the PDCP SDU cannot be obtained from the set of PDCP PDUs, wherein the report indicates that the receiving device was unable to obtain the PDCP SDU.
  23. The method of claim 22, further comprising:
    monitoring for a retransmission of the set of PDCP PDUs based at least in part on transmitting the report.
  24. The method of claim 22, wherein the determining is based at least in part on receiving all PDCP PDUs of the set of PDCP PDUs.
  25. The method of claim 22, wherein:
    the PDCP SDU is included in a set of PDCP SDUs;
    the receiving device is unable to obtain one or more PDCP SDUs in the set of 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 the one or more PDCP SDUs that the receiving device is unable to obtain.
  26. The method of claim 22, wherein the report further comprises a bitmap indicating, for each PDCP SDU in a set of PDCP SDUs having a sequence number greater than the sequence number of the PDCP SDU, whether the receiving device was able to successfully obtain or was not able to obtain a respective PDCP SDU.
  27. The method of claim 16, further comprising:
    identifying, within each PDU header of the set of PDU headers, a field indicating an index for an associated PDCP PDU corresponding to the PDCP SDU, wherein the set of PDCP PDUs are decoded based at least in part on an ordering corresponding to the index.
  28. The method of claim 16, further comprising:
    identifying, within a PDU header of the set of PDU headers, a flag indicating that an associated PDCP PDU is a last PDCP PDU of the set of PDCP PDUs corresponding to the PDCP SDU.
  29. The method of claim 16, further comprising:
    identifying, within each PDU header of the set of PDU headers, a repair field indicating whether an associated PDCP PDU is a repaired PDCP PDU.
  30. The method of claim 16, further comprising:
    configuring a radio link control layer at the receiving device for a transparent mode or an unacknowledged mode, wherein the decoding at the PDCP layer is based at least in part on the configuring.
  31. The method of claim 16, wherein receiving the set of PDCP PDUs comprises:
    receiving a set of source PDCP PDUs and a set of parity PDCP PDUs.
  32. An apparatus for wireless communication at a transmitting device, comprising:
    a processor,
    memory in electronic communication with the processor, and
    instructions stored in the memory and executable by the processor to cause the apparatus to:
    segment a packet data convergence protocol (PDCP) service data unit (SDU) into a set of PDCP protocol data units (PDUs) at a PDCP layer of the transmitting device;
    encode, at the PDCP layer, the set of PDCP PDUs according to one or more network coding parameters to obtain a set of encoded PDCP PDUs, the one or more network coding parameters comprising a rateless code;
    generate, for the set of encoded PDCP PDUs, a corresponding set of PDU headers; and
    output the set of encoded PDCP PDUs and the corresponding set of PDU headers from the PDCP layer to a lower layer of the transmitting device for transmission to one or more receiving devices.
  33. The apparatus of claim 32, wherein the instructions are further executable by the processor to cause the apparatus to:
    perform, at the PDCP layer and before the encoding, an integrity protection and ciphering function on the PDCP SDU.
  34. The apparatus of claim 32, wherein:
    the set of PDCP PDUs comprises a set of source PDCP PDUs; and
    the instructions to encode the set of PDCP PDUs are executable by the processor to cause the apparatus to encode the set of source PDCP PDUs to obtain a set of encoded source PDCP PDUs and a set of encoded parity PDCP PDUs.
  35. The apparatus of claim 32, wherein the instructions to generate the set of PDU headers are executable by the processor to cause the apparatus to:
    set, within each PDU header of the set of PDU headers, a field indicating an index for an associated encoded PDCP PDU corresponding to the PDCP SDU, wherein the index corresponds to an ordering for the set of encoded PDUs.
  36. The apparatus of claim 32, wherein the instructions to generate the set of PDU headers are executable by the processor to cause the apparatus to:
    set, within a PDU header of the set of PDU headers, a flag indicating that an associated encoded PDCP PDU is a last encoded PDCP PDU of the set of encoded PDUs corresponding to the PDCP SDU.
  37. The apparatus of claim 32, wherein the instructions to generate the set of PDU headers are executable by the processor to cause the apparatus to:
    set, within each PDU header of the set of PDU headers, a repair field indicating whether an associated encoded PDCP PDU is a repaired PDCP PDU.
  38. The apparatus of claim 32, wherein the one or more network coding parameters comprise a minimum code rate for the set of encoded PDCP PDUs, and wherein a quantity of encoded PDCP PDUs included in the set of encoded PDCP PDUs is based at least in part on the minimum code rate.
  39. The apparatus of claim 38, wherein the instructions are further executable by the processor to cause the apparatus to:
    receive an indication of the minimum code rate for the set of encoded PDCP PDUs via radio resource control signaling.
  40. The apparatus of claim 32, wherein the instructions are further executable by the processor to cause the apparatus to:
    store the PDCP SDU or the set of encoded PDCP PDUs in a retransmission buffer implemented at the PDCP layer.
  41. The apparatus of claim 32, wherein the instructions are further executable by the processor to cause the apparatus to:
    receive, from a receiving device of the one or more receiving devices, feedback for the set of encoded PDCP PDUs indicating that the receiving device was unable to obtain the PDCP SDU.
  42. The apparatus of claim 41, wherein the instructions are further executable by the processor to cause the apparatus to:
    retrieve, based at least in part on the feedback, the set of encoded PDCP PDUs from a retransmission buffer implemented at the PDCP layer; and
    retransmit the set of encoded PDCP PDUs to the one or more receiving devices based at least in part on the retrieving.
  43. The apparatus of claim 41, wherein the instructions are further executable by the processor to cause the apparatus to:
    retrieve, based at least in part on the feedback, the PDCP SDU from a retransmission buffer implemented at the PDCP layer;
    encode the set of PDCP PDUs according to the one or more network coding parameters to obtain a set of re-encoded PDCP PDUs based at least in part on the retrieving; and
    transmit the set of re-encoded PDCP PDUs to the one or more receiving devices.
  44. The apparatus of claim 32, wherein the instructions are further executable by the processor to cause the apparatus to:
    receive, from a receiving device of the one or more receiving devices, feedback for the set of encoded PDCP PDUs indicating that the receiving device was able to obtain the PDCP SDU.
  45. The apparatus of claim 44, wherein the instructions are further executable by the processor to cause the apparatus to:
    receive, from the receiving device, an indication of a quantity of encoded PDCP PDUs used by the receiving device to obtain the PDCP SDU; and
    adjust a code rate of the one or more network coding parameters based at least in part on the indicated quantity of encoded PDCP PDUs.
  46. The apparatus of claim 32, wherein the instructions are further executable by the processor to cause the apparatus to:
    configure a radio link control layer at the transmitting device to operate a transparent mode or an unacknowledged mode, wherein the encoding at the PDCP layer is based at least in part on the configuring.
  47. An apparatus for wireless communication at a receiving device, comprising:
    a processor,
    memory in electronic communication 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 PDCP protocol data units (PDUs) and a corresponding set of PDCP PDU headers from a transmitting device, the set of PDCP PDUs and the corresponding set of PDCP PDU headers corresponding to a PDCP service data unit (SDU) ;
    decode, at the PDCP layer, at least a subset of the set of PDCP PDUs based at least in part on one or more network coding parameters and the corresponding set of PDCP PDU headers, the one or more network coding parameters comprising a rateless code;
    generate a report based at least in part on the decoding, wherein the report indicates whether the PDCP SDU was obtained from the set of PDCP PDUs; and
    transmit the report to the transmitting device.
  48. The apparatus of claim 47, wherein the instructions are further executable by the processor to cause the apparatus to:
    perform, at the PDCP layer after decoding at least the subset of the set of PDCP PDUs and obtaining the PDCP SDU, an integrity verification and deciphering function on the PDCP SDU.
  49. The apparatus of claim 47, wherein the instructions are further executable by the processor to cause the apparatus to:
    determine that at least a minimum quantity of PDCP PDUs of the set of PDCP PDUs has been received, wherein the decoding is based at least in part on determining that at least the minimum quantity of PDCP PDUs has been received.
  50. The apparatus of claim 49, wherein the instructions are further executable by the processor to cause the apparatus to:
    receive an indication of the minimum quantity of PDCP PDUs in the set of PDCP PDUs via radio resource control signaling.
  51. The apparatus of claim 47, wherein the instructions are further executable by the processor to cause the apparatus to:
    obtain the PDCP SDU from the subset of the set of PDCP PDUs; and
    refrain from decoding a remaining subset of the set of PDCP PDUs based at least in part on obtaining the PDCP SDU.
  52. The apparatus of claim 47, wherein the instructions are further executable by the processor to cause the apparatus to:
    indicate, to the transmitting device, a quantity of PDCP PDUs used by the receiving device to obtain the PDCP SDU.
  53. The apparatus of claim 47, wherein the instructions are further executable by the processor to cause the apparatus to:
    determine that the PDCP SDU cannot be obtained from the set of PDCP PDUs, wherein the report indicates that the receiving device was unable to obtain the PDCP SDU.
  54. The apparatus of claim 53, wherein the instructions are further executable by the processor to cause the apparatus to:
    monitor for a retransmission of the set of PDCP PDUs based at least in part on transmitting the report.
  55. The apparatus of claim 53, wherein the determining is based at least in part on receiving all PDCP PDUs of the set of PDCP PDUs.
  56. The apparatus of claim 53, wherein:
    the PDCP SDU is included in a set of PDCP SDUs;
    the receiving device is unable to obtain one or more PDCP SDUs in the set of 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 the one or more PDCP SDUs that the receiving device is unable to obtain.
  57. The apparatus of claim 53, wherein the report further comprises a bitmap indicating, for each PDCP SDU in a set of PDCP SDUs having a sequence number greater than the sequence number of the PDCP SDU, whether the receiving device was able to successfully obtain or was not able to obtain a respective PDCP SDU.
  58. The apparatus of claim 47, wherein the instructions are further executable by the processor to cause the apparatus to:
    identify, within each PDU header of the set of PDU headers, a field indicating an index for an associated PDCP PDU corresponding to the PDCP SDU, wherein the set of PDCP PDUs are decoded based at least in part on an ordering corresponding to the index.
  59. The apparatus of claim 47, wherein the instructions are further executable by the processor to cause the apparatus to:
    identify, within a PDU header of the set of PDU headers, a flag indicating that an associated PDCP PDU is a last PDCP PDU of the set of PDCP PDUs corresponding to the PDCP SDU.
  60. The apparatus of claim 47, wherein the instructions are further executable by the processor to cause the apparatus to:
    identify, within each PDU header of the set of PDU headers, a repair field indicating whether an associated PDCP PDU is a repaired PDCP PDU.
  61. The apparatus of claim 47, wherein the instructions are further executable by the processor to cause the apparatus to:
    configure a radio link control layer at the receiving device for a transparent mode or an unacknowledged mode, wherein the decoding at the PDCP layer is based at least in part on the configuring.
  62. The apparatus of claim 47, wherein the instructions to receive the set of PDCP PDUs are executable by the processor to cause the apparatus to:
    receive a set of source PDCP PDUs and a set of parity PDCP PDUs.
  63. An apparatus for wireless communication at a transmitting device, comprising:
    means for segmenting a packet data convergence protocol (PDCP) service data unit (SDU) into a set of PDCP protocol data units (PDUs) at a PDCP layer of the transmitting device;
    means for encoding, at the PDCP layer, the set of PDCP PDUs according to one or more network coding parameters to obtain a set of encoded PDCP PDUs, the one or more network coding parameters comprising a rateless code;
    means for generating, for the set of encoded PDCP PDUs, a corresponding set of PDU headers; and
    means for outputting the set of encoded PDCP PDUs and the corresponding set of PDU headers from the PDCP layer to a lower layer of the transmitting device for transmission to one or more receiving devices.
  64. An apparatus for wireless communication at a receiving device, comprising:
    means for receiving, at a packet data convergence protocol (PDCP) layer of the receiving device, a set of PDCP protocol data units (PDUs) and a corresponding set of PDCP PDU headers from a transmitting device, the set of PDCP PDUs and the corresponding set of PDCP PDU headers corresponding to a PDCP service data unit (SDU) ;
    means for decoding, at the PDCP layer, at least a subset of the set of PDCP PDUs based at least in part on one or more network coding parameters and the corresponding set of PDCP PDU headers, the one or more network coding parameters comprising a rateless code;
    means for generating a report based at least in part on the decoding, wherein the report indicates whether the PDCP SDU was obtained from the set of PDCP PDUs; and
    means for transmitting the report to the transmitting device.
  65. A non-transitory computer-readable medium storing code for wireless communication at a transmitting device, the code comprising instructions executable by a processor to:
    segment a packet data convergence protocol (PDCP) service data unit (SDU) into a set of PDCP protocol data units (PDUs) at a PDCP layer of the transmitting device;
    encode, at the PDCP layer, the set of PDCP PDUs according to one or more network coding parameters to obtain a set of encoded PDCP PDUs, the one or more network coding parameters comprising a rateless code;
    generate, for the set of encoded PDCP PDUs, a corresponding set of PDU headers; and
    output the set of encoded PDCP PDUs and the corresponding set of PDU headers from the PDCP layer to a lower layer of the transmitting device for transmission to one or more receiving devices.
  66. A non-transitory computer-readable medium storing code for wireless communication 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 PDCP protocol data units (PDUs) and a corresponding set of PDCP PDU headers from a transmitting device, the set of PDCP PDUs and the corresponding set of PDCP PDU headers corresponding to a PDCP service data unit (SDU) ;
    decode, at the PDCP layer, at least a subset of the set of PDCP PDUs based at least in part on one or more network coding parameters and the corresponding set of PDCP PDU headers, the one or more network coding parameters comprising a rateless code;
    generate a report based at least in part on the decoding, wherein the report indicates whether the PDCP SDU was obtained from the set of PDCP PDUs; and
    transmit the report to the transmitting device.
PCT/CN2020/104027 2020-07-24 2020-07-24 Rateless coding at a packet data convergence protocol layer WO2022016488A1 (en)

Priority Applications (9)

Application Number Priority Date Filing Date Title
PCT/CN2020/104027 WO2022016488A1 (en) 2020-07-24 2020-07-24 Rateless coding at a packet data convergence protocol layer
US18/004,648 US20230269026A1 (en) 2020-07-24 2021-07-23 Rateless coding at layer two protocol layer
CN202180060285.6A CN116097592A (en) 2020-07-24 2021-07-23 Rate-less decoding of layer two protocol layers
EP21847381.7A EP4186306A1 (en) 2020-07-24 2021-07-23 Rateless coding at layer two protocol layer
PCT/CN2021/108240 WO2022017517A1 (en) 2020-07-24 2021-07-23 Rateless coding at a layer two protocol layer
CN202180060229.2A CN116261834A (en) 2020-07-24 2021-07-23 Rate-less decoding of layer two protocol layers
EP21845745.5A EP4186191A1 (en) 2020-07-24 2021-07-23 Rateless coding at a layer two protocol layer
PCT/CN2021/108260 WO2022017521A1 (en) 2020-07-24 2021-07-23 Rateless coding at layer two protocol layer
US18/004,652 US20230283411A1 (en) 2020-07-24 2021-07-23 Rateless coding at a layer two protocol layer

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2020/104027 WO2022016488A1 (en) 2020-07-24 2020-07-24 Rateless coding at a packet data convergence protocol layer

Publications (1)

Publication Number Publication Date
WO2022016488A1 true WO2022016488A1 (en) 2022-01-27

Family

ID=79729728

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/104027 WO2022016488A1 (en) 2020-07-24 2020-07-24 Rateless coding at a packet data convergence protocol layer

Country Status (1)

Country Link
WO (1) WO2022016488A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023206141A1 (en) * 2022-04-27 2023-11-02 Lenovo (Beijing) Limited Wireless transmission device and method for indicating association of protocol data unit set
WO2024045190A1 (en) * 2022-09-02 2024-03-07 Telefonaktiebolaget Lm Ericsson (Publ) Methods and apparatuses for resource management in cloud

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105306165A (en) * 2014-06-23 2016-02-03 中兴通讯股份有限公司 Data transmission method and device
CN107769887A (en) * 2016-08-17 2018-03-06 华为技术有限公司 A kind of data transfer, data processing method and device
WO2018082816A1 (en) * 2017-02-03 2018-05-11 Telefonaktiebolaget Lm Ericsson (Publ) Retransmission technique
US20190357196A1 (en) * 2018-05-17 2019-11-21 At&T Intellectual Property I, L.P. Network coding for bandwidth efficient reliability improvement for urllc service

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105306165A (en) * 2014-06-23 2016-02-03 中兴通讯股份有限公司 Data transmission method and device
CN107769887A (en) * 2016-08-17 2018-03-06 华为技术有限公司 A kind of data transfer, data processing method and device
WO2018082816A1 (en) * 2017-02-03 2018-05-11 Telefonaktiebolaget Lm Ericsson (Publ) Retransmission technique
US20190357196A1 (en) * 2018-05-17 2019-11-21 At&T Intellectual Property I, L.P. Network coding for bandwidth efficient reliability improvement for urllc service

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ALCATEL, ASUSTEK, ERICSSON, LG ELECTRONICS, MOTOROLA, NOKIA, NORTEL NETWORKS, PHILIPS, QUALCOMM, SIEMENS, TALITY, TTP: "General clarifications", 3GPP DRAFT; R2-011882, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG2, no. Helsinki, Finland; 20010904, 4 September 2001 (2001-09-04), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP050118672 *
RAPPORTEUR (ERICSSON): "Running CR for 38.322 for NR V2X", 3GPP DRAFT; R2-1916449, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG2, no. Reno, USA; 20191118 - 20191122, 23 November 2019 (2019-11-23), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP051828936 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023206141A1 (en) * 2022-04-27 2023-11-02 Lenovo (Beijing) Limited Wireless transmission device and method for indicating association of protocol data unit set
WO2024045190A1 (en) * 2022-09-02 2024-03-07 Telefonaktiebolaget Lm Ericsson (Publ) Methods and apparatuses for resource management in cloud

Similar Documents

Publication Publication Date Title
US11606797B2 (en) Decoding downlink control information in a combined physical downlink control channel candidate
US20230283411A1 (en) Rateless coding at a layer two protocol layer
US11595943B2 (en) Outer coding schemes in downlink control information
US20220022235A1 (en) Feedback schemes for multiple component carrier scheduling and joint feedback reporting
US11792771B2 (en) Transport block forwarding over different air interfaces
US11962407B2 (en) Blind decoding counting for repetition-based physical downlink control channel candidates
WO2022016488A1 (en) Rateless coding at a packet data convergence protocol layer
WO2022226437A1 (en) Sidelink groupcast over millimeter wave frequency bands
WO2022016489A1 (en) Polling and status reporting for network coding
WO2022016541A1 (en) Retransmission procedures at a packet data convergence protocol layer
WO2022041187A1 (en) Degree selection schemes for rapid tornado (raptor) codes in multicast and broadcast services and in unicast services
EP4128611A1 (en) Feedback for single-downlink control information to multi-cell scheduling
WO2022016501A1 (en) Outer coding at a packet data convergence protocol layer
WO2022006850A1 (en) Transmitting encoding symbol identifier of raptor codes using control channel coding
WO2022056807A1 (en) Rateless coding over a packet data convergence protocol layer
US20230254092A1 (en) Flexible feedback with outer coding
WO2022067837A1 (en) Control signaling for rateless codes with feedback
WO2022227001A1 (en) Techniques for radio resource control reconfiguration alignment
WO2021179151A1 (en) Encoding scheme selection for wireless transmissions
WO2022041183A1 (en) Indication scheme for rateless codes transmissions without feedback information
US20220303047A1 (en) Network coding to mitigate blockage with spatial division multiplexing beams
WO2022052087A1 (en) Sidelink reliability enhancements
US20230145149A1 (en) Dynamic coding for wireless systems
WO2021184184A1 (en) Modulation and coding scheme indication for multi-slot transmissions
US20230139023A1 (en) Adaptive rateless coding for sidelink communications

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20946196

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20946196

Country of ref document: EP

Kind code of ref document: A1