WO2025148034A1

WO2025148034A1 - Time and data packet number configurations for wireless communications

Info

Publication number: WO2025148034A1
Application number: PCT/CN2024/072114
Authority: WO
Inventors: Shuaihua KOU; Xianghui HAN; Wei Gou; Xing Liu
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2024-01-12
Filing date: 2024-01-12
Publication date: 2025-07-17
Anticipated expiration: 2026-07-12

Abstract

This document generally relates to wireless communication that includes a network device that determines at least one of time information or a data packet number at which a user device is to perform a processing operation. The network device transmits, and/or the user device receives, the at least one of the time information or the data packet number. The user device performs the processing operation at a time indicated by the time information or at the data packet number.

Description

TIME AND DATA PACKET NUMBER CONFIGURATIONS FOR WIRELESS COMMUNICATIONS

TECHNICAL FIELD

This document is directed generally to time and data packet number configurations for wireless communications.

BACKGROUND

In wireless communication systems, more than one user device may transmit the same signal in order to improve the reliability of the data carried by the signal. The user devices transmitting the same signal may receive the same data from the same data source and perform further processing. In each user device, the data may be processed layer by layer. In order for the user devices to generate the same signal and/or determine the data carried by the signal in the same way, the layers in the respective user devices may process the data and deliver data packets after processing to lower layers in the same way. In addition, the user devices may transmit the physical signal at the same time. Ways to improve the ability of user devices to generate the same data packet and the same physical signal may be desirable.

SUMMARY

This document relates to methods, systems, apparatuses and devices for wireless communication. In some implementations, a method for wireless communication includes: receiving, by a user device, at least one of time information or a data packet number from a network device; and performing, by the user device, a processing operation at a time indicated by the time information or at the data packet number.

In some other implementations, a method for wireless communication includes:

determining, by a network device, at least one of time information or a data packet number at which a user device is to perform a processing operation; and transmitting, by the network device, the at least one of the time information or the data packet number to the user device.

In some other implementations, a device, such as a network device, is disclosed. The device may include one or more processors and one or more memories, wherein the one or more processors are configured to read computer code from the one or more memories to implement any of the methods above.

In yet some other implementations, a computer program product is disclosed. The computer program product may include a non-transitory computer-readable program medium with computer code stored thereupon, the computer code, when executed by one or more processors, causing the one or more processors to implement any of the methods above.

The above and other aspects and their implementations are described in greater detail in the drawings, the descriptions, and the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a block diagram of an example of a wireless communication system.

FIG. 2 shows a block diagram of an example protocol stack for a communication node.

FIG. 3 shows a flow chart of a method for wireless communication.

FIG. 4 shows a flow chart of another method for wireless communication.

FIG. 5 shows a schematic diagram of an example physical uplink shared channel (PUSCH) transmission.

FIG. 6 shows a schematic diagram of an example physical uplink control channel (PUCCH) and PUSCH transmission.

FIG. 7 shows a schematic diagram of another example PUSCH transmission.

DETAILED DESCRIPTION

The example headings for the various sections below are used to facilitate the understanding of the disclosed subject matter and do not limit the scope of the claimed subject matter in any way. Accordingly, one or more features of one example section can be combined with one or more features of another example section. Furthermore, 5G terminology is used for the sake of clarity of explanation, but the techniques disclosed in the present document are not limited to 5G technology only, and may be used in wireless systems that implemented other protocols, e.g., 6G or beyond.

The present description describes various embodiments of systems, apparatuses, devices, and methods for wireless communications related to time and data packet number configurations.

FIG. 1 shows a diagram of an example wireless communication system 100 including a plurality of communication nodes (or just nodes) that are configured to wirelessly communicate with each other. In general, the communication nodes include at least one user device 102 and at least one network device 104. The example wireless communication system 100 in FIG. 1 is shown as including two user devices 102, including a first user device 102 (1) and a second user device 102 (2) , and one network device 104. However, various other examples of the wireless communication system 100 that include any of various combinations of one or more user devices 102 and/or one or more network devices 104 may be possible.

In general, a user device as described herein, such as the user device 102, may include a single electronic device or apparatus, or multiple (e.g., a network of) electronic devices or apparatuses, capable of communicating wirelessly over a network. A user device may comprise or otherwise be referred to as a user terminal, a user terminal device, or a user equipment (UE) . Additionally, a user device may be or include, but not limited to, a mobile device (such as a mobile phone, a smart phone, a smart watch, a tablet, a laptop computer, vehicle or other vessel (human, motor, or engine-powered, such as an automobile, a plane, a train, a ship, or a bicycle as non-limiting examples) or a fixed or stationary device, (such as a desktop computer or other computing device that is not ordinarily moved for long periods of time, such as appliances, other relatively heavy devices including Internet of things (IoT) , or computing devices used in commercial or industrial environments, as non-limiting examples) . In various embodiments, a user device 102 may include transceiver circuitry 106 coupled to an antenna 108 to effect wireless communication with the network device 104. The transceiver circuitry 106 may also be coupled to a processor 110, which may also be coupled to a memory 112 or other storage device. The memory 112 may store therein instructions or code that, when read and executed by the processor 110, cause the processor 110 to implement various ones of the methods described herein.

Additionally, in general, a network device as described herein, such as the network device 104, may include a single electronic device or apparatus, or multiple (e.g., a network of) electronic devices or apparatuses, and may comprise one or more wireless access nodes, base stations, or other wireless network access points capable of communicating wirelessly over a network with one or more user devices and/or with one or more other network devices 104. For example, the network device 104 may comprise a 4G LTE base station, a 5G NR base station, a 5G central-unit base station, a 5G distributed-unit base station, a next generation Node B (gNB) , an enhanced Node B (eNB) , or other similar or next-generation (e.g., 6G) base stations, in various embodiments. A network device 104 may include transceiver circuitry 114 coupled to an antenna 116, which may include an antenna tower 118 in various approaches, to effect wireless communication with the user device 102 or another network device 104. The transceiver circuitry 114 may also be coupled to one or more processors 120, which may also be coupled to a memory 122 or other storage device. The memory 122 may store therein instructions or code that, when read and executed by the processor 120, cause the processor 120 to implement one or more of the methods described herein.

In various embodiments, two communication nodes in the wireless system 100-such as a user device 102 and a network device 104, two user devices 102 without a network device 104, or two network devices 104 without a user device 102-may be configured to wirelessly communicate with each other in or over a mobile network and/or a wireless access network according to one or more standards and/or specifications. In general, the standards and/or specifications may define the rules or procedures under which the communication nodes can wirelessly communicate, which, in various embodiments, may include those for communicating in millimeter (mm) -Wave bands, and/or with multi-antenna schemes and beamforming functions. In addition or alternatively, the standards and/or specifications are those that define a radio access technology and/or a cellular technology, such as Fourth Generation (4G) Long Term Evolution (LTE) , Fifth Generation (5G) New Radio (NR) , or New Radio Unlicensed (NR-U) , as non-limiting examples.

Additionally, in the wireless system 100, the communication nodes are configured to wirelessly communicate signals between each other. In general, a communication in the wireless system 100 between two communication nodes can be or include a transmission or a reception, and is generally both simultaneously, depending on the perspective of a particular node in the communication. For example, for a given communication between a first node and a second node where the first node is transmitting a signal to the second node and the second node is receiving the signal from the first node, the first node may be referred to as a source or transmitting node or device, the second node may be referred to as a destination or receiving node or device, and the communication may be considered a transmission for the first node and a reception for the second node. Of course, since communication nodes in a wireless system 100 can both send and receive signals, a single communication node may be both a transmitting/source node and a receiving/destination node simultaneously or switch between being a source/transmitting node and a destination/receiving node.

Also, particular signals can be characterized or defined as either an uplink (UL) signal, a downlink (DL) signal, or a sidelink (SL) signal. An uplink signal is a signal transmitted from a user device 102 to a network device 104. A downlink signal is a signal transmitted from a network device 104 to a user device 102. A sidelink signal is a signal transmitted from a one user device 102 to another user device 102, or a signal transmitted from one network device 104 to a another network device 104. Also, for sidelink transmissions, a first/source user device 102 directly transmits a sidelink signal to a second/destination user device 102 without any forwarding of the sidelink signal to a network device 104.

Additionally, signals communicated between communication nodes in the system 100 may be characterized or defined as a data signal or a control signal. In general, a data signal is a signal that includes or carries data, such multimedia data (e.g., voice and/or image data) , and a control signal is a signal that carries control information that configures the communication nodes in certain ways in order to communicate with each other, or otherwise controls how the communication nodes communicate data signals with each other. Also, certain signals may be defined or characterized by combinations of data/control and uplink/downlink/sidelink, including uplink control signals, uplink data signals, downlink control signals, downlink data signals, sidelink control signals, and sidelink data signals.

For at least some specifications, such as 5G NR, data and control signals are transmitted and/or carried on physical channels. Generally, a physical channel corresponds to a set of time-frequency resources used for transmission of a signal. Different types of physical channels may be used to transmit different types of signals. For example, physical data channels (or just data channels) , also herein called traffic channels, are used to transmit data signals, and physical control channels (or just control channels) are used to transmit control signals. Example types of traffic channels (or physical data channels) include, but are not limited to, a physical downlink shared channel (PDSCH) used to communicate downlink data signals, a physical uplink shared channel (PUSCH) used to communicate uplink data signals, and a physical sidelink shared channel (PSSCH) used to communicate sidelink data signals. In addition, example types of physical control channels include, but are not limited to, a physical downlink control channel (PDCCH) used to communicate downlink control signals, a physical uplink control channel (PUCCH) used to communicate uplink control signals, and a physical sidelink control channel (PSCCH) used to communicate sidelink control signals. As used herein for simplicity, unless specified otherwise, a particular type of physical channel is also used to refer to a signal that is transmitted on that particular type of physical channel, and/or a transmission on that particular type of transmission. As an example illustration, a PDSCH refers to the physical downlink shared channel itself, a downlink data signal transmitted on the PDSCH, or a downlink data transmission. Accordingly, a communication node transmitting or receiving a PDSCH means that the communication node is transmitting or receiving a signal on a PDSCH.

Additionally, for at least some specifications, such as 5G NR, and/or for at least some types of control signals, a control signal that a communication node transmits may include control information comprising the information necessary to enable transmission of one or more data signals between communication nodes, and/or to schedule one or more data channels (or one or more transmissions on data channels) . For example, such control information may include the information necessary for proper reception, decoding, and demodulation of a data signals received on physical data channels during a data transmission, and/or for uplink scheduling grants that inform the user device about the resources and transport format to use for uplink data transmissions. In some embodiments, the control information includes downlink control information (DCI) that is transmitted in the downlink direction from a network device 104 to a user device 102. In other embodiments, the control information includes uplink control information (UCI) that is transmitted in the uplink direction from a user device 102 to a network device 104, or sidelink control information (SCI) that is transmitted in the sidelink direction from one user device 102 (1) to another user device 102 (2) .

FIG. 2 shows a block diagram of an example protocol stack 200 plurality of layer entities or modules of a communication node (e.g., a user device 102 or a wireless access node 104) , including a physical layer (PHY) entity or module (also called herein as just PHY layer, PHY module, or PHY entity) 202, a medium-access control (MAC) layer entity or module (also called herein as just MAC layer, MAC module, or MAC entity) 204, a radio-link control (RLC) layer entity or module (also called herein as just RLC layer, RLC entity, or RLC module) 206, a package data convergence protocol (PDCP) layer entity or module (also called herein as just PDCP layer, PDCP entity, or PDCP module) 208, and a service data adaptation protocol (SDAP) /radio resource control (RRC) layer entity or module (also called herein as just SDAP/RRC layer, SDAP/RRC entity, or SDAP/RRC module) 210.

In general, as used herein unless expressed otherwise, the terms “layer” , “entity” , and “module” , used alone or in combination with each other, and as used for one or more components of a communication node, is an electronic device, such as electronic circuit, that includes hardware or a combination of hardware and software. In various embodiments, a module or an entity may be considered part of, or a component of, or implemented using one or more of the components of a communication node of FIG. 1, including a processor 110/120, a memory 112/122, a transceiver circuit 106/114, or the antenna 108/116. For example, the processor 110/120, such as when executing computer code stored in the memory 112/116, may perform the functions of a module or entity. Additionally, in various embodiments, the functions that a module or entity performs may be defined by one or more standards or protocols, such as 5G NR for example.

Additionally, the layer entities 202-210 in FIG. 2 may be higher (or upper) and lower layers relative to each other, with the PHY layer entity 202 being the lowest layer among the layer entities 202-210; the MAC layer entity 204 being a higher layer than the PHY layer entity 202 and lower than the other layer entities 206-210; the RLC layer entity 206 being higher than the PHY and MAC layer entities 202, 204 and lower than the PDCP and SDAP/RRC layer entities 208, 210; the PDCP layer entity 208 being higher than the PHY, MAC, and RLC layer entities 202-206 and lower than the SDAP/RRC layer entity 210; and the SDAP/RRC layer entity 210 being the highest layer entity among the layer entities 202-210 shown in FIG. 2. In various embodiments, a communication node of the system 100 may include modules and/or layer entities other than, including fewer than or more than, those shown in FIG. 2.

The layer entities or modules shown in FIG. 2 may perform various functions and communicate with each other, such as by communicating signals, messages, or data packets between each other, in order to send and receive data packets. The PHY layer entity or module 202 may perform various functions, including encoding and decoding transport blocks to be transmitted to, or received from, another communication node; modulation and demodulation of data according to any of various modulation schemes or types, such as quadrature amplitude modulation (QAM) and quadrature phase shift keying (QPSK) , as non-limiting examples; channel estimation on received data to determine channel state information on one or more channels on which the communication node receives signals; signal recovery of different signals, which the transmitting communication node may transmit on multiple antenna elements.

The MAC layer entity or module 204 may perform or handle logical-channel multiplexing and demultiplexing, hybrid automatic repeat request (HARQ) retransmissions, and scheduling-related functions, including the assignment of uplink and downlink resources in both the frequency domain and the time domain. Additionally, the MAC layer entity or module 204 may determine transport formats specifying how a transport block is to be transmitted. A transport format may specify a transport-block size, a coding and modulation mode, and antenna mapping. By varying the parameters of the transport format, the MAC layer entity or module 204 can effect different data rates. The MAC layer entity or module 204 may also control distributing data from flows across different component carriers or cells for carrier aggregation.

The RLC layer entity or module 206 may perform segmentation of service data units (SDU) to suitably sized protocol data units (PDU) . In various embodiments, a data package from/to a higher protocol layer or module is called a SDU, and the corresponding data package to/from a lower protocol layer or module is called a PDU. The RLC layer entity or module 206 may also perform retransmission management that involves monitoring sequence numbers in PDUs in order to identify missing PDUs. Additionally, the RLC layer entity or module 206 may communicate status reports to enable retransmission of missing PDUs. The RLC layer entity or module 206 may also be configured to identify errors due to noise or channel variations.

The PDCP layer entity or module 208 may perform functions including, but not limited to, Internet Protocol (IP) header compression and decompression, ciphering and deciphering, integrity protection, retransmission management, in-sequence delivery, duplicate removal, dual connectivity, and handover functions.

The SDAP/RRC layer entity or module 210 may perform functions designated for a SDAP layer entity or module, including mapping traffic from quality of service (QoS) flows to suitable data radio bearers (DRBs) , and/or perform functions designated for a RRC layer entity or module, including determining and/or controlling the determining of configurations for two communication nodes to communicate with each other, and configuring the lower layer entities or modules 202-208 according to the determined configuration. In some embodiments, the SDAP/RRC layer entity or module 210 may perform the functions of a SDAP layer entity and the functions of a RRC layer entity. In other embodiments, the SDAP/RRC layer entity 210 may perform the functions of a SDAP layer entity but not the functions of a RRC layer entity, or may perform the functions of a RRC layer entity but not a SDAP layer entity. For at least some of these embodiments, the SDAP/RRC layer entity 210 is a SDAP layer entity that performs the functions of a SDAP layer entity for configurations where the SDAP/RRC layer entity 210 is part of a data radio bearer (DRB) , or is a RRC layer entity that performs the functions of a RRC layer entity for configurations where the SDAP/RRC layer entity is part of a signaling radio bearer (SRB) . In still other embodiments, a communication node may organize or configure the SDAP/RRC layer entity 210 into two separate layer entities, including a SDAP layer entity and a RRC layer entity. Hereafter, for simplicity, the layer entity 210 is referred to as the SDAP layer entity (or just SDAP layer or SDAP entity) configured to perform the functions generally designated or defined under the SDAP. The SDAP layer 210 may or may not be configured to perform RRC functions in any of various embodiments.

Additionally, in various embodiments, a given communication node (e.g., a user device 102 or a network device 104) may have a protocol stack configuration that describes or identifies the layer entities of the given communication node. A protocol stack may also describe or identify how the layer entities are organized or configured with respect to one or more radio bearers (RBs) of the communication node. In general, in a communication node, a radio bearer has, is associated with, and/or is configured to operate according to a protocol stack that includes at least one layer entity. In any of various embodiments, different radio bearers of a given communication node may have, be associated with, and/or be configured to operate according to respective protocol stacks. For at least some embodiments, the at least one layer entity may include one or more layers higher than the MAC layer entity. Within the same communication node, protocol stacks of different radio bearers may have the same configuration as, or different configurations from, each other in any of various embodiments. In addition, in any of various embodiments, two communication nodes configured to communicate with each other may have the same or different protocol stack configurations.

FIG. 3 shows a flow chart of an example method 300 for wireless communication that involves operating according to times and/or data packet numbers. At block 302, a user device 102 receives at least one of time information or a data packet number. At block 304, the user device 102 may perform a processing operation at a time indication by the time information or at the data packet number.

FIG. 4 shows a flow chart of an example method 400 for wireless communication that involves operating according to times and/or data packet numbers. At block 402, a network device 104 determines at least one of time information or a data packet number at which a user device 102 is to perform a processing operation. At block 404, the network device 104 transmits the at least one of the time information or the data packet number to the user device 102.

In some embodiments of the method 300 and/or the method 400, the time indicated by the time information includes an absolute time, a starting boundary of a specific time unit, or an ending boundary of the specific time unit. In some of these embodiments, the specific time unit is indicated by the network device 104.

In some embodiments of the method 300 and/or the method 400, the data packet number includes a packet data convergence protocol (PDCP) sequence number (SN) , a count, or a radio link control (RLC) SN. In some of these embodiments, the data packet number is periodic.

In some embodiments of the method 300 and/or the method 400, the processing operation includes: establishing a mapping relationship between a quality of service (QoS) flow and an indicated radio bearer; delivering a control protocol data unit (PDU) to a lower layer before or after a data packet indicated by the data packet number; establishing or re-establishing a packet data convergence protocol (PDCP) entity for the indicated radio bearer and setting a plurality of state variables to initial values for the indicated radio bearer; performing a data packet retransmission at the PDCP layer or a radio link control (RLC) layer; setting or resetting a medium access control (MAC) layer; or starting or stopping a data channel transmission.

In some embodiments of the method 300 and/or the method 400, the user device 102 receives, and/or the network device 104 transmits, a downlink control information (DCI) that schedules at least one physical uplink shared channel (PUSCH) from the network device 104. The user device 102 transmits the PUSCH to the network device 104, and/or the network device 104 receives the PUSCH from the user device 102.

In some of these embodiments, the user device 102 also transmits, and/or the network device 104 also receives, a physical uplink control channel (PUCCH) that includes at least one information bit indicating that the user device 102 has received the DCI. In some of these embodiments, an offset between the PUCCH and the DCI is configured by the network device 104. In addition or alternatively, the PUCCH and the PUSCH are transmitted in different time units. In addition or alternatively, the PUSCH includes at least a first reserved resource and a second reserved resource, where the first reserved resource and the second reserved resource are configured by the network device 104. In some embodiments involving the first and second reserved resources, the user device 102 transmits, and/or the network device 104 receives, on the first reserved resource within the PUSCH, one information bit indicating that the user device 102 has received the DCI. In addition or alternatively, the user device 102 is configured to not transmit anything on the second reserved resource. In addition or alternatively, in some embodiments where the user device 102 receives, and/or the network device 104 transmits, the DCI, the DCI includes a field indicating a DCI order. In some of these embodiments, in response to determining that there is a missing DCI between a previous DCI and a current DCI, the user device 102 generates one or more transport blocks, and discards the one or more transport blocks. In particular of these embodiments, a number of the one or more transport blocks is equal to a number of one or more missing DCIs times a number of transport blocks that can be scheduled by the DCI. In addition or alternatively, a size of each of the one or more transport blocks is configured by the network device 104.

Further details, any or all of which may be implemented in any of various embodiments of the method 200, the method 300, and/or other methods, is now described.

In some embodiments, in the wireless communication system 100, a first user device 102 (1) may be associated with at least a second user device 102 (2) . The first user device 102 (1) and the second user device 102 (2) may transmit the same data to the network device 104. Other embodiments may include more than two user devices 102 associated with each other (e.g., three user devices, four user devices, and so on) that transmit the same data to the network device 104.

Additionally, information that a given user device 102 (e.g., the first user device 102 (1) or the second user device 102 (2) ) may send to the network device 104 may be included in an uplink control information (UCI) , a medium access control (MAC) control element (CE) , or a radio resource control (RRC) signaling. Also, information that the network device 104 may send to one or more of the user device 102 (e.g., the first user device 102 (1) and/or the second user device 102 (2) ) may be included in a downlink control information (DCI) , a MAC CE, or RRC signaling.

In some embodiments of the wireless communication system 100, the service data adaptation protocol (SDAP) layer (or SDAP entity) 210 of a given communication node (e.g., a user device 102 or a network device 104) may be configured to perform, and/or responsible for performing one or more of the following actions: transferring user plane data, mapping between a quality of service (QoS) flow and a radio bearer (e.g., data radio bearer (DRB) , a multicast radio bearer (MRB) , or a sidelink data radio bearer (SL-DRB) ) , and marking a QoS flow ID.

In some embodiments, the network device 104 may configure a SDAP related configuration for a given user device 102. In particular embodiments, the network device 104 may configure for the user device 102 the mapping relationship between one QoS flow and one radio bearer. Additionally or alternatively, the network device 104 may configure for the user device 102 a reflective QoS flow to radio bearer mapping for at least one radio bearer. The user device 102 may determine the mapping relationship between the QoS flow and the radio bearer for uplink (UL) according to the relationship between the QoS flow and the radio bearer for downlink (DL) . In some implementations, the mapping relationship between the QoS flow and the radio bearer may be the same for the DL and UL. For example, the user device 102 may receive a DL data with radio bearer 3 corresponding to QoS flow 10. The user device 102 may determine that the QoS flow 10 is mapped to radio bearer 3 for UL transmission.

Additionally, in some embodiments, the network device 104 may configure (or indicate) a time for a given user device 102. For example, the network device 104 may send a first message including the time to the user device 102. The configured SDAP related configuration (e.g., a configured mapping relationship or a determined mapping relationship) may not take effect until the configured time. In other words, the previous SDAP related configuration (e.g., a previous mapping relationship) may be applied or used by the user device 102 before the configured time and the configured SDAP related configuration (e.g., the configured mapping relationship or the determined mapping relationship) may be applied or used by the user device 102 starting from configured time.

In some embodiments, the configured time may be an absolute or a unique time defined by a particular granularity of time units. For example, the absolute time may be 8 o’ clock AM, 52 minutes, 33 seconds, 139 milliseconds, 823 microseconds, and 130 nanoseconds on December 3rd 2024. In other embodiments, the configured time may be the time of a starting boundary or an ending boundary of a specific time unit. Alternatively, the configured time may the time of the starting boundary or the ending boundary of the specific time unit that the user device 102 may receive. The time unit may include an orthogonal frequency domain multiplexing (OFDM) symbol, a sub-slot, a slot, a sub-frame, or a frame, in any of various embodiments. The specific time unit may be indicated by the network device 104 via the first message or specified by a communication protocol according to which the communication nodes in the wireless communication system 100 communicate. For example, the network device 104 may indicate the time unit number for the user device 102. The specific time unit may be the time unit with an indicated time unit number that is closest to the time when the user device 102 receives the first message. For example, the first message may indicate a particular system frame number (SFN) (e.g., SFN 512) , and the first message may be transmitted on another SFN (e.g., SFN 500) . Then the specific time unit may be the first system frame with SFN 512 after the SFN 500 where the user device 102 receives the first message.

In addition or alternatively, the specific time unit may have a fixed offset with the time unit when the user device 102 receives the first message (or a PDSCH carrying the first message) or with the time unit when the user device 102 transmits the feedback corresponding to the first message (or the PDSCH carrying the first message) . To illustrate as an example, the network device 104 may transmit the first message carried by the PDSCH to the user device 102 in a slot N. Further, suppose the user device 102 may transmit the PUCCH carrying the hybrid automatic repeat request (HARQ) feedback (e.g., acknowledgement (ACK) feedback) for the PDSCH in a slot N+2, and that the fixed offset is three slots. Then, the specific time unit may be slot N+3 or N+5.

Additionally, in some embodiments, the network device 104 may configure the same mapping relationship or the same reflective QoS flow to radio bearer mapping for the first user device 102 (1) and the second user device 102 (2) . For a QoS flow, the first user device 102 (1) and the second user device 102 (2) may map the QoS flow to the same radio bearer. In addition, the network device 104 may configure the same time for the first user device 102 (1) and the second user device 102 (2) . At the user device side, the first user device 102(1) and the second user device 102 (2) may apply or use the same mapping relationship between QoS flow and radio bearer at the same configured time. As such, the different user devices 102 (1) , 102 (2) may apply the same SDAP configuration at the same configured time.

Additionally, in some embodiments, in a user device 102, the SDAP layer 210 may generate a SDAP control protocol data unit (PDU) . The SDAP control PDU may be used by the SDAP layer (or SDAP entity) 210 to indicate that it may stop the mapping of a SDAP service data unit (SDU) of the QoS flow indicated by the SDAP control PDU to the radio bearer on which the SDAP control PDU is transmitted. The SDAP layer 210 may deliver the SDAP control PDU to the lower layer (e.g., the PDCP layer 208) at the configured time. For at least some of these embodiments, the configured time is periodic. The network device 104 may configure the period for the user device 102 and the time of the first one of the periodic times. For example, the network device 104 may configure that the period is 40 system frames and the first one of the periodic times is SFN 2. In turn, the configured time may be the starting boundary or ending boundary of SFN 2, SFN 42, SFN 82, and so on. Then the SDAP layer 210 may deliver the SDAP control PDU to the lower layer (e.g., the PDCP layer 208) at the starting boundary or ending boundary of SFN 2, SFN 42, SFN 82, and so on, if any. In the user device side, the first user device 102 (1) and the second user device 102 (2) may deliver the SDAP control PDU to their respective lower layers at the same time. As such, the different user devices 102 (1) , 102 (2) may deliver the SDAP control PDU to their respective lower layers at the same time.

Additionally, in some embodiments in the wireless communication system 100, a packet data convergence protocol (PDCP) layer (or PDCP entity) 208 may perform and/or be responsible for at least one of: transfer of data, maintenance of PDCP sequence numbers (SN) , header compression and decompression, uplink data compression and decompression, ciphering and deciphering, and integrity protection and integrity verification. For the PDCP layer (or PDCP entity) 208, the user device 102 may maintain at least one state variable. The state variable may include at least one of count, PDCP SN, TX_NEXT, RX_NEXT, RX_DELIV, and RX_RECORD. The state variable count may be associated with one PDCP PDU or PDCP SDU. Each PDCP PDU or PDCP SDU may have one specific count. The state variable PDCP SN may be associated with one PDCP PDU or PDCP SDU. A PDCP SN may be part of the count for one PDCP PDU or PDCP SDU, e.g., several least significant bits of the count. The count or the SN may be used for identifying the PDCP PDU or PDCP SDU. The state variable TX_NEXT may indicate the count value of the next PDCP SDU to be transmitted. The state variable RX_NEXT may indicate the count value of a next PDCP SDU expected to be received. The state variable RX_DELIV may indicate the count value of the first PDCP SDU not delivered to upper layers (e.g., SDAP/RRC layer 210) , but still waited for. The state variable RX_RECORD may indicate the count value following the count value associated with the PDCP data PDU that may trigger a timer used to detect loss of PDCP PDU.

In some embodiments, the network device 104 may configure a PDCP related configuration for a user device 102. Upon receiving the PDCP related configuration, the user device 102 may establish or re-establish a PDCP entity 208 for the radio bearer. When the user device 102 establishes the PDCP entity 208, the user device 102 may set the state variables of the PDCP entity 208 to initial values. The network device 104 may configure (or indicate) the time for the user device 102, such as in accordance with the actions as previously described. The user device 102 may establish or re-establish the PDCP entity 208 for the radio bearer at the configured time. The network device 104 may configure the same time for the first user device 102 (1) and the second user device 102 (2) . In the user device side, the first user device 102 (1) and the second user device 102 (2) may establish or re-establish respective PDCP entities 208 for the same radio bearer at the same configured time.

When the first user device 102 (1) re-establishes its PDCP entity 208 for the radio bearer, the first user device 102 (1) may set at least one of the state variables to an initial value. In some embodiments, the first user device 102 (1) may report or send, to the network device 104, at least one of a latest value of at least one state variable and the corresponding radio bearer information before setting it to initial value. In some embodiments, the network device 104 may send at least one of the latest value of at least one state variable and the corresponding radio bearer information to the second user device 102 (2) . In some embodiments, the network device 104 may send the second user device 102 (2) a second message that may indicate to the second user device 102(2) to re-establish the PDCP entity 208 for the indicated radio bearer when the state variable of the PDCP entity 208 for the indicated bearer is equal to indicated value. In some embodiments, the second user device 102(2) may re-establish the PDCP entity 208 for the indicated radio bearer when the state variable of the PDCP entity 208 for the indicated bearer is equal to the indicated value. In any of various embodiments, at least one of the procedures may not be performed.

To illustrate for example, suppose for radio bearer 3, when the first user device 102 (1) performs re-establishment of the PDCP entity 208, the value of state variable TX_NEXT may be 388. This means that the latest value of the state variable TX_NEXT before setting it to an initial value is 388. The first user device 102 may send the state variable TX_NEXT, with a value of 388, and radio bearer 3 to the network device 104. In turn, the network device 104 may send the state variable TX_NEXT, with a value of 388, and radio bearer 3 to the second user device 102 (2) . In turn, the second user device 102 (2) may perform re-establishment of the PDCP entity 208 for radio bearer 3 when the state variable TX_NEXT for radio bearer 3 is equal to 388. As such, the second user device 102 (2) and the first user device 102 (1) may perform re-establishment of the PDCP entity 208 at the same transmission packet. Additionally, the respective PDCP entities 208 of the first user device 102 (1) and the second user device 102 (2) may deliver the same data packet to the lower layer (e.g., the RLC layer 206) .

Additionally, in some embodiments, the network device 104 may send (or indicate or configure) a new key to a given user device 102. The network device 104 may send (or indicate or configure) at least one of the PDCP SN value or a count value to the user device 102. The PDCP PDU or PDCP SDU with the indicated PDCP SN value or with the indicated count value may be the first one to which the user device 102 may apply the indicated key. In other words, the user device 102 may apply the indicated key from the PDCP PDU or PDCP SDU with the indicated PDCP SN value or with the indicated count value. To illustrate for example, suppose the network device 104 sends count value 3948 to the user device 102. The user device 102 may apply the previous key to the PDCP PDU with a count less than 3948. Additionally, the user device 102 may apply the indicated key to the PDCP PDU with a count equal to or greater than 3948. Alternatively, the PDCP PDU or PDCP SDU with the indicated PDCP SN value or with the indicated count value may be the last one to which the user device 102 applies the previous key. In other words, the user device 102 may apply the indicated key after the PDCP PDU or PDCP SDU with the indicated PDCP SN value or with the indicated count value. For example, the user device 102 may apply the previous key to the PDCP PDU with a count not greater than 3948. The user device 102 may apply the indicated key to the PDCP PDU with a count greater than 3948. As such, the first user device 102(1) and the second user device 102 (2) may apply the same key for the same data packet. As a result, the respective PDCP entities 208 of the first user device 102 (1) and the second user device 102 (2) may deliver the same data packet to the lower layer (e.g., the RLC layer 206) .

Additionally, in some embodiments, the network device 104 may send the first user device 102 (1) a third message that may indicate to the first user device 102 (1) to freeze the data transfer for at least one radio bearer indicated by the third message. In some of these embodiments, the first user device 102 (1) may freeze the data transfer at the PDCP layer 208 for the radio bearer. In the first user device 102 (1) , the PDCP layer (or PDCP entity) 208 may stop delivering the PDCP PDU to the lower layer (e.g., the RLC layer 206) for the radio bearer. In other of these embodiments, in the first user device 102 (1) , the PDCP layer (or PDCP entity) 208 may stop generating new PDCP PDUs for the radio bearer. In some embodiments, the first user device 102 (1) may send (or report) the PDCP SN value or the count value of the last PDCP PDU or PDCP SDU that the PDCP layer 208 has already sent to the lower layer (e.g., the RLC layer 206) or the first PDCP PDU or PDCP SDU that the PDCP layer 208 has not sent to the lower layer (e.g., the RLC layer 206) yet for the radio bearer. In some embodiments, the network device 104 may send the second user device 102 (2) the PDCP SN value or the count value of the PDCP PDU or PDCP SDU reported by the first user device 102 (1) . In some embodiments, the PDCP layer (or PDCP entity) 208 of the second user device 102 (2) may deliver the PDCP PDU to the lower layer (e.g., the RLC layer 206) after the PDCP PDU (or PDCP SDU) with the indicated PDCP SN or count or starting from the PDCP PDU or PDCP SDU with the indicated PDCP SN or count for the radio bearer. In some embodiments, in the second user device 102 (1) , the PDCP entity 208 may discard the PDCP PDU with the SN or count smaller than or equal to the indicated PDCP SN or indicated count. In some embodiments, the network device 104 may send the first user device 102 (1) a fourth message that indicates to the first user device 102 (1) to continue the data transfer or the PDU generation for the at least one radio bearer indicated by the fourth message. In the user device side, the user device 102 may continue the data transfer or the PDU generation for the at least one radio bearer indicated by the fourth message upon receiving the fourth message. In any of various of these embodiments, less than all of the above-described actions may be performed.

To illustrate for example, suppose the network device 104 indicate to the first user device 102 (1) to freeze the data transfer for a radio bearer 8. In turn, the first user device 102 (1) may freeze the data transfer for radio bearer 8. In the first user device 102 (1) , the PDCP entity 208 may stop delivering the PDCP PDU to the lower layer (e.g., the RLC layer 206) for radio bearer 8. Additionally, for radio bearer 8, suppose the first PDCP PDU not delivered to the lower layer (e.g., the RLC layer 206) has PDCP SN 683. Correspondingly, the last PDCP PDU that has been delivered to the lower layer (e.g., the RLC layer 206) may have PDCP SN 682. The first user device 102 (1) may send the PDCP SN 683 or PDCP SN 682 and the corresponding radio bearer 8 to the network device 104. In turn, the network device 104 may send the PDCP SN 683 or PDCP SN 682 and the corresponding radio bearer 8 to the second user device 102 (2) . In the second user device 102 (2) , the PDCP entity 208 may deliver the PDCP PDU to the lower layer (e.g., the RLC layer 206) starting from the one with PDCP SN 683 for radio bearer 8. The second user device 102 (2) may discard the PDCP PDU with a SN less than 683. The network device 104 may indicate to the first user device 102 (1) to continue the data transfer for radio bearer 8.In the first user device 102 (1) , the PDCP entity 208 may continue delivering the PDCP PDU to the lower layer (e.g., the RLC layer 206) , such as from the PDCP PDU with SN 683. In some embodiments, the network device 104 may determine the PDCP SN or count for a given radio bearer. In turn, the network device 104 may send the determined PDCP SN or determined count to at least one of the user devices 102 (e.g., the first UE 102(1) and/or the second user device 102 (2) ) . Accordingly, the respective PDCP entities 208 of the first user device 102 (1) and the second user device 102 (2) may deliver the same data packet to their respective lower layers (e.g., the RLC layer 206) at the same time.

Additionally, in some embodiments, for the radio bearer, the network device 104 may send a given user device 102 a PDCP status reporting that may include which PDCP PDU or PDCP SDU may have been successfully received by the network device 104 and/or which PDCP PDU or PDCP SDU may not have been successfully received by the network device 104, at least not yet. The network device 104 may send the user device 102 a first message that may include a time. The user device 102 may start to perform PDCP PDU retransmission according to the PDCP status reporting at the configured time in accordance with any of the various embodiments as described herein. For the PDCP PDU retransmission, the user device 102 may retransmit the PDCP PDU that may not have been received by the network device 104 indicated by the PDCP status reporting in the order (e.g., ascending order or descending order) of the PDCP SN or count. Additionally, the network device 104 may send the same time to the first user device 102 (1) and the second user device 102 (2) . In the user device side, the first user device 102 (1) and the second user device 102 (2) may perform the PDCP PDU retransmission at the same time. As such, the respective PDCP entities 208 of the first user device 102 (1) and the second user device 102 (2) may deliver the same data packet to the lower layer (e.g., the RLC layer 206) at the same time.

To illustrate for example, suppose the network device 104 sends a given user device 102 a PDCP status reporting that may indicate that PDCP PDUs with SNs 0, 1, 3, 4, 5, 6, 8, 9, 10 have been received by the network device 104, and that may indicate that PDCP PDUs with SNs 2 and 7 have not been received by the network for radio bearer 8. The user device 102 may start to retransmit PDCP PDUs with SNs 2 and 7 at the configured time. The PDCP entity 208 may deliver the PDCP PDUs with SNs 2 and 7 to the lower layer (e.g., the RLC layer 206) . The delivery order may be PDCP PDU with SN 2 and PDCP PDU with SN 7.

In some embodiments, the network device 104 may configure a duration of a discard timer for the radio bearer for the user device 102. When the PDCP layer (or PDCP entity) 208 receive the PDCP SDUs from the upper layer (e.g., the SDAP layer 210) , the PDCP layer (or PDCP entity) 208 may start a discard timer associated with this PDCP SDU. For a first type of radio bearer, when the discard timer expires for a first PDCP SDU and the PDCP SDUs with a PDCP SN or a count less than the first PDCP SDU have been transmitted successfully, the PDCP layer (or PDCP entity) 208 may discard the PDCP SDU and/or the corresponding PDCP PDU. For a second type of radio bearer, when the discard timer expires for a first PDCP SDU, the PDCP layer (or PDCP entity) 208 may discard the PDCP SDU and/or the corresponding PDCP PDU. The network device 104 may configure the same duration of the discard timer for the radio bearer for the first user device 102 (1) and the second user device 102 (2) . In the user device side, the first user device 102 (1) and the second user device 102(2) may perform the same operation on PDCP PDU or PDCP SDU discarding. As a result, the respective PDCP entities 208 of the first user device 102 (1) and the second user device 102 (2) may discard the same data packet simultaneously.

Additionally, in some embodiments of the wireless communication system 100, the radio link control (RLC) layer or (RLC entity) 206 may perform and/or be responsible for at least one of: transfer of data, error correction, segmentation (or re-segmentation) and reassembly, duplicate detection, and RLC SDU discard.

In some embodiments, the network device 104 may configure for a given user device 102 an RLC related configuration. The RLC related configuration may include at least one of: a transmission mode (e.g., acknowledged mode or unacknowledged mode) , an SN field length, data packet size, or a number of data packets.

Upon receiving the RLC related configuration, the user device 102 may establish or re-establish an RLC entity 206 for a given radio bearer. When the user device 102 establishes the RLC entity 206, the user device 102 may set state variables of the RLC entity 206 to initial values. The network device 104 may configure (or indicate) a time for the user device 102, such as in accordance with the embodiments described herein. Additionally, the user device 102 may establish or re-establish the RLC entity 206 for the radio bearer at the configured time. The network device 104 may configure the same time for the first user device 102 (1) and the second user device 102 (2) . Additionally, the network device 104 may configure the same RLC related configuration for the first user device 102 (1) and the second user device 102 (2) . In the user device side, the first user device 102 (1) and the second user device 102 (2) may establish or re-establish the RLC entity 206 for the same radio bearer at the same configured time. As such, the different first user device 102 (1) and the second user device 102 (2) may establish or re-establish their respective RLC entities 206 for the same radio bearer at the same time.

In some embodiments, for the radio bearer, when the total transmitted data packet size is greater than or equal to the configured data packet size or when the total number of transmitted data packet is greater than or equal to the configured number of data packets, an RLC status reporting request may be triggered.

Additionally, in some embodiments, an indication with a value that may request the RLC status reporting may only be included in at least a specific RLC PDU. In other words, only a specific RLC PDU may request the RLC status reporting. The network device 104 may configure, or a protocol according to which the communication nodes in the wireless communication system 100 may operate may specify, the specific RLC PDU for a given user device 102. The network device 104 may configure the RLC PDU SN of the specific RLC PDU. Additionally, the network device 104 may configure the SN period. The specific RLC PDU may be determined by the indicated RLC PDU SN and the SN period. The SN of the specific RLC PDU minus the configured RLC PDU SN may be equal to the integral multiple of the configured SN period. To illustrate, suppose a configured RLC PDU SN is 80, and a configured SN period is 320. Correspondingly, a specific RLC PDU may be the one with SN 80+x*320, where may x be any integer. The specific RLC PDU may be one that has a PDU SN of 80, 400, 720, 1040, and so on. Additionally, the RLC PDU or the header of the RLC PDU may include a field that indicates the RLC status reporting request. For example, the field may have 1 bit with a logic value ‘1’ that may indicate that the RLC status reporting is requested and logic value ‘0’ that may indicate that the RLC status reporting is not requested. The field may be set to ‘0’ or ‘1’ in the RLC PDUs having SN 80, 400, 720, 1040, and so on. In some implementations, the field may only be set to ‘0’ in the other RLC SDUs. In addition or alternatively, when the RLC status reporting request is triggered, the indication that may request the RLC status reporting (e.g., the field set to ‘1’ ) may only be included in the next specific RLC PDU. For example, the RLC status reporting request may be triggered at RLC PDU with SN 536. In addition or alternatively, the RLC status reporting request indication information (e.g., the field set to ‘1’ ) may be included in the RLC PDU with SN 720. As a result, the first user device 102 (1) and the second user device 102 (2) may request the RLC status reporting in the same RLC PDU.

Additionally, in some embodiments, the network device 104 may configure the RLC entity 206 to never trigger the RLC status reporting for the first type of radio bearer. In the user device side, the RLC entity 206 may never trigger the RLC status reporting for the first type of radio bearer, e.g., the field may be always set to 0 for the RLC PDU for the first type of radio bearer. The RLC PDU for the first type of radio bearer may not include the field with a value indicating the RLC status reporting request. Alternatively, RLC PDU or the header of the RLC PDU for the first type of radio bearer may not include the field. The field may only be included in the RLC PDU or the header of the RLC PDU for the second radio bearer.

In some embodiments, for the radio bearer, the network device 104 may send a given user device 102 an RLC status reporting that may include which RLC PDUs or RLC SDUs have been received by the network device 104 successfully and/or which RLC PDUs or RLC SDUs have not been successfully received by the network device 104, at least not yet. The network device 104 may send the user device 102 a first message that may include a time. The user device 102 may start to perform RLC PDU retransmission according to the RLC status reporting at the configured time in accordance with the embodiments described herein. For the RLC PDU retransmission, the user device 102 may retransmit the RLC PDU that may not have been received by the network device 104 indicated by the RLC status reporting in the order (e.g., ascending order or descending order) of the RLC SN. The network device 104 may send the same time to the first user device 102 (1) and the second user device 102 (2) . In the user device side, the first user device 102 (1) and the second user device 102 (2) may perform the RLC PDU retransmission at the same time.

To illustrate for example, the network device 104 may send a given user device 102 the RLC status reporting that may indicate that RLC PDUs with SNs 10, 11, 13, 17, 18, 19, 23, 24, 25 have been received by the network device 104, and the RLC PDU with SNs 12, 14, 15, 16, 20, 21, and 22 have not been received by the network for radio bearer 8. The user device 102 may start to retransmit RLC PDUs with SNs 12, 14, 15, 16, 20, 21, and 22 at the configured time. The RLC entity 206 may deliver the RLC PDUs with SNs 12, 14, 15, 16, 20, 21 and 22 to the lower layer (e.g., the MAC layer 204) . The delivery order may be RLC PDU with SN 12, RLC PDU with SN 14, RLC PDU with SN 15, RLC PDU with SN 16, RLC PDU with SN 20, RLC PDU with SN 21, and RLC PDU with SN 22.

Additionally, in some embodiments, the first user device 102 (1) may re-establish the RLC entity 206 for the radio bearer. The first user device 102 (1) may discard all the RLC SDU and/or RLC SDU segments, and RLC PDUs for the radio bearer, if any. In some embodiments, the first user device 102 (1) may send the discarded RLC SDU and/or RLC SDU segments, and RLC PDUs to the network device 104. In some embodiments, the network device 104 may send the second user device 102 (2) the discarded RLC SDUs and/or RLC SDU segments, and RLC PDUs reported by the first user device 102 (1) . In some embodiments, the second user device 102 (2) may discard the RLC SDU and/or RLC SDU segments, and RLC PDUs indicated by the network device 104. In other embodiments, the first user device 102 (1) may re-establish the RLC entity 206 for the radio bearer. The first user device 102 (1) may not discard the RLC SDU and/or RLC SDU segments or RLC PDUs. The first user device 102 (1) may set (or reset) all state variables to the initial values.

Additionally, in some embodiments, the network device 104 may configure a transport block size for a given user device 102. A DCI may schedule a data channel that may carry one or more transport blocks each with the configured size. The data channel may include a PDSCH, a PUSCH, or a PSSCH. Additionally, the DCI may include a second field. In some embodiments, the second field may indicate a DCI order. The DCI may be ordered in the order (e.g., ascending order or descending order) of the starting time of the data channel or the DCI. Alternatively, the DCI may be ordered first in the order (e.g., ascending order or descending order) of the starting time of the data channel or the DCI, second in the order (e.g., ascending order or descending order) of the serving cell index. Alternatively, the DCI may be ordered first in the order (e.g., ascending order or descending order) of the serving cell index, second in the order (e.g., ascending order or descending order) of the starting time of the data channel or the DCI. In other embodiments, the second field may indicate a data channel order. The data channel may be ordered in the order (e.g., ascending order or descending order) of the starting time of the data channel. Also, the starting time of the data channel may be the starting symbol of the data channel. For example, the second field may have 2 bits. The second field may indicate the DCI order or data channel order cyclically. According to the order, the second field in the consecutive DCIs may be ‘00’ , ‘01’ , ‘10’ , ‘11’ , ‘00’ , and so on. Based on the second field, the user device 102 may be able to determine whether the user device 102 misses the DCI. Alternatively, the data channel may be ordered first in the order (e.g., ascending order or descending order) of the starting time of the data channel, second in the order (e.g., ascending order or descending order) of the serving cell index. Alternatively, the data channel may be ordered first in the order (e.g., ascending order or descending order) of the serving cell index, second in the order (e.g., ascending order or descending order) of the starting time of the data channel.

Additionally, in some embodiments, in the user device side, a given user device 102 may first receive a first DCI (DCI 1) , and then may receive a second DCI (DCI 2) . Based on the second field in the DCI 1 and DCI 2, the user device 102 may be able to determine whether or how many DCIs the user device 102 may miss between DCI 1 and DCI 2. An example of a number of missed DCIs is shown in Table 1 below. The number 0 means no DCIs are missed. In event that the second field in DCI 1 received by the user device 102 is '00' , the second field with value '00' , '01' , '10' , and '11' in DCI 2 received by the user device 102 indicates that the user device 102 misses 3, 0, 1, and 2 DCIs between DCI 1 and DCI 2, respectively.

Table 1: Missed DCIs Between DCI 1 and DCI 2

Additionally, in event that the user device 102 determines that there is at least one missed DCI, the user device 102 may generate at least one MAC PDU with a configured size and discard at least one generated MAC PDU. The number of generated MAC PDUs may be determined based on the number of missed DCIs. For example, one DCI may schedule Z transport blocks or MAC PDUs. The number of generated MAC PDUs may be Z*N, where N is the number of missed DCIs determined by the user device 102. For configurations where one DCI schedules one transport block, the number of generated MAC PDUs may be equal to the number of missed DCIs determined by the user device 102. Correspondingly, the user device 102 may generate the MAC PDU according to the received DCI and then transmit the generated MAC PDU.

FIG. 5 is a schematic diagram illustrating an example of a PUSCH transmission. In the example in FIG. 5, five DCIs denoted by DCI 5-9, are transmitted on slot 3-slot 7, respectively. Each DCI schedules one PUSCH in the same slot. Additionally, each PUSCH may carry one transport block. The second field in each of DCI 5 -DCI 9 may be '00' , '01' , '10' , '11' and '00' , respectively. In event that the user device 102 receives all of DCI 5 –DCI 9, the user device 102 may generate and transmit five transport blocks. Suppose, for example, that the user device 102 receives DCI 5 and DCI 8 and misses DCI 6 and DCI 7. Correspondingly, the user device 102 may determine that two DCI are missed between DCI 5 and DCI 8. The user device 102 may generate two MAC PDUs, each with the configured size. Therefore, the user device 102 may still generate MAC PDUs for DCI 6 and DCI 7 even though the user device 102 misses the two DCIs. The user device 102 may discard the two generated MAC PDUs. Additionally, the user device 102 may generate one MAC PDU according to the DCI 8 and then transmit the generated MAC PDU to the network device 104. As a result, the user device 102 may be able to determine whether a DCI is missed. Additionally, the user device 102 may be able to determine the same transport block and transmit the same transport block with another user device 102 even if it misses the DCI.

Additionally, in some embodiments, the network device 104 may configure a PUCCH resource for the user device 102. The network device 104 may further configure or indicate a time offset between the PUCCH and a DCI. For example, the network device 104 may configure the time unit offset between the time unit of the PUCCH (or the first time unit of the PUCCH) and the time unit of the DCI (or the last time unit of the DCI) . The PUCCH transmission may depend on whether the user device 102 receives the DCI. When the user device 102 receives the DCI, the user device 102 may transmit the PUCCH. The PUCCH may carry at least one information bit with value '0' or '1' . The at least one information bit may indicate that the user device 102 has received the DCI. When the user device 102 does not receive the DCI, the user device 102 may not transmit the PUCCH. Based on the PUCCH, the network device 104 may be able to determine whether the user device 102 receives the DCI.

Additionally, in some embodiments, the network device 104 may configure different PUCCH resources for the first user device 102 (1) and the second user device 102 (2) . In this way, the PUCCH resource is user device-specific. Further, the DCI may schedule a data channel. In some embodiments, the PUCCH and the data channel may not be in the same time unit.

FIG. 6 is a schematic diagram of an example of a PUCCH and PUSCH transmission. In the example, the network device 104 may configure a first PUCCH (PUCCH 1) for the first user device 102 (1) and configure a second PUCCH (PUCCH 2) for the second user device 102 (2) . Further, suppose in the example that the offset between a PUCCH and a DCI is 2 slots. In the example, a DCI transmitted on slot 3 schedules a PUSCH on slot 6 for both the first user device 102 (1) and the second user device 102 (2) . In event that the first user device 102 (1) receives the DCI, the first user device 102 (1) may determine that the PUCCH 1 is in slot 5. In turn, the first user device 102 (1) may transmit PUCCH 1 in slot 5 and PUSCH in slot 6. In event that the first user device 102 (1) does not receive the DCI, the first user device 102 (1) may transmit neither PUCCH 1 nor the PUSCH. Also, in event that the second user device 102 (2) receives the DCI, the second user device 102 (2) may determine that PUCCH 2 is in slot 5. The second user device 102 (2) may transmit PUCCH 2 in slot 5 and the PUSCH in slot 6. In event that the second user device 102 (2) does not receive the DCI, the second user device 102 (2) may transmit neither PUCCH 2 nor the PUSCH. As a result, the network device 104 may be able to determine whether or not the first user device 102 (1) and/or the second user device 102 (2) receives the DCI.

Additionally, in some embodiments, the DCI may schedule the PUSCH. The DCI may indicate the PUSCH resource. The PUSCH may be scheduled for at least one user device 102. A resource within the PUSCH may be reserved. However, the reserved resource may not be used for PUSCH transmission. Instead, the reserved resource may be used for indicating whether a user device 102 received the DCI. Further, the reserved resource may include one or more resource elements (RE) . The network device 104 may configure, or a protocol according to which communication nodes in the wireless communication system 100 communicate, may specify the reserved resource. For example, the network device 104 may configure the time location and/or the frequency location.

Additionally, in some embodiments, PUSCH mapping may be performed through a rate matching operation or a puncture operation. For rate matching, a rate matching output sequence length may be determined by the PUSCH resource excluding the reserved resource. The information bits and/or the modulated symbols of the PUSCH may be mapped to the PUSCH resource excluding the reserved resource. The information bits and/or the modulated symbols of the PUSCH may not be mapped to the reserved resource. For a puncture operation, the rate matching output sequence length may be determined by the PUSCH resource including the reserved resource. The information bits and/or the modulated symbols of the PUSCH may be mapped to the PUSCH resource including the reserved resource. The information bits or the modulated symbols of the PUSCH mapped to the reserved resource may be punctured (e.g., removed) .

Additionally, in some embodiments, the PUSCH may be scheduled for more than one user device 102, such as the first user device 102 (1) and the second user device 102 (2) . Different user devices 102 may have (or occupy) different REs in the reserved resource. A given user device 102 may use its RE in the reserved resource for transmitting signals. The given user device 102 may not transmit anything on the other resource in the reserved resource. In other embodiments, a given user device 102 may transmit only one information bit on its reserved resource. The transmitted one information bit may be '1' or '0' . The one information bit may indicate that the user device 102 has received the DCI. Additionally, the one information bit may be processed in the same way as a PUSCH, and the processing may include at least one of coding, scrambling, or modulation. Then, the modulated symbol (s) of the one information bit may be mapped to its reserved resource.

FIG. 7 is a schematic diagram of another example PUSCH transmission. In the example in FIG. 7, the PUSCH may occupy four resource blocks (RB) , denoted by RB 1-RB 4, respectively. The PUSCH may be configured for both the first user device 102 (1) and the second user device 102 (2) . Additionally, in the example, each RB may include 14 OFDM symbols, denoted by symbols 0-13, respectively, and 12 sub-carriers, denoted by sub-carriers 0-11, respectively. The reserved resources for the first user device 102 (1) and the second user device 102 (2) may be on the first RB (e.g., RB 1) . Additionally, the reserved resources may be on the first symbol after the demodulation reference signal (DMRS) symbol, i.e., the reserved resources may be on the third symbol (symbol 3) . The first user device 102 (1) and the second user device 102 (2) may have different reserved resources. In the example, the reserved resource for the first user device 102 (1) may be on sub-carriers 0, 2, and 4. Additionally, the reserved resource for the second user device 102 (2) may be on sub-carriers 6, 8, and 10. The reserved resource may include 6 resource elements (RE) , e.g., reserved REs. Therefore, there are 150 REs in RB 1 for the PUSCH.

Additionally, for at least some embodiments where rate matching is performed, a PUSCH RE may be used to determine the rate matching output sequence length. Referring to the example, 150 REs in RB 1 and 156 REs in each of RBs 2, 3, and 4 may be used to determine the rate matching sequence length since there is no reserved resource in each of RB 2, 3, and 4. The information bits and/or the modulated symbols of the PUSCH may be mapped to the PUSCH REs. Also, in some embodiments, nothing is mapped to the reserved RE (s) .

Additionally, for at least some embodiments where a puncture operation is performed, a PUSCH RE and a reserved RE may be used to determine the rate matching output sequence length. Referring to the example, 156 REs in each of RBs 1, 2, 3, and 4 are used to determine the rate matching sequence length. The information bits or the modulated symbols of the PUSCH may be mapped to the PUSCH REs and reserved REs. After the mapping, the information bits or the modulated symbols of the PUSCH mapped to the reserved REs (e.g., sub-carriers 0, 2, 4, 6, 8, and 10 of symbol 3) are punctured.

Additionally, in some embodiments, still referring to the example in FIG. 7, the first user device 102 (1) may transmit one information bit on the sub-carriers 0, 2, and 4 of symbol 3. The information bit '1' may be processed, such as by being coded, scrambled, or modulated, as non-limiting examples. The modulated symbols may be mapped to sub-carriers 0, 2, and 4 of symbol #3 by the first user device 102 (1) . Finally, the first user device 102 (1) may transmit the modulated symbols on sub-carriers 0, 2, and 4 of symbol 3. For the first user device 102 (1) , nothing is mapped to sub-carriers 6, 8, and 10 of symbol 3. Correspondingly, the first user device 102 (1) may transmit nothing on sub-carriers 6, 8, and 10 of symbol 3. Based on the signal transmitted on the reserved sub-carriers 0, 2, and 4 of symbol 3, the network device 104 can determine whether the first user device 102 (1) receives the DCI.

Additionally, in some embodiments, still referring to the example in FIG. 7, the second user device 102 (2) may transmit one information bit on sub-carriers 6, 8, and 10 of symbol 3. The information bit '1' may be processed, such as by being coded, scrambled, or modulated, as non-limiting examples. The modulated symbols may be mapped to sub-carriers 6, 8, and 10 of symbol 3 by the second user device 102 (2) . Finally, the second user device 102 (2) may transmit the modulated symbols on sub-carriers 6, 8, and 10 of symbol 3. For the second user device 102 (2) , nothing is mapped to sub-carriers 0, 2, and 4 of symbol 3. Correspondingly, the second user device 102 (2) may transmit nothing on sub-carriers 0, 2, and 4 of symbol 3. Based on the signal transmitted on the reserved sub-carriers 6, 8, and 10 of symbol 3, the network device 104 can determine whether the second user device 102 (2) receives the DCI.

Additionally, both the first user device 102 (1) and the second user device 102 (2) may transmit the PUSCH. For at least some embodiments, the first user device 102 (1) and the second user device 102 (2) may process the PUSCH the same way.

In some embodiments, the network device 104 may configure a data channel for a given user device 102. For at least some of these embodiments, the data channel may be transmitted periodically. The network device 104 may configure or indicate the time for the user device 102 in accordance with the various embodiments described herein. In addition, the network device 104 may further configure or indicate to the user device 102 to start the data channel transmission or stop the data channel transmission at the configured time. In the user device side, the user device 102 may start the data channel transmission or stop the data channel transmission at the configured time. The network device 104 may configure the same time for the first user device 102 (1) and the second user device 102 (2) . As a result, the first user device 102 (1) and the second user device 102 (2) may be able to perform the data channel transmission simultaneously.

Additionally, in some embodiments, the network device 104 may schedule the PUSCH for a given user device 102. The PUSCH may include at least one of a first type of PUSCH and a second type of PUSCH. The DCI may indicate the type of the PUSCH. In particular of these embodiments, the DCI may indicate the type of the PUSCH explicitly. For example, the DCI may include a third field for indicating the type of PUSCH. The third field may have a first value (e.g., '0' ) for indicating that the first type of PUSCH may be scheduled and a second value (e.g., '1' ) for indicating that the second type of PUSCH may be scheduled. The DCI may indicate the type of the PUSCH implicitly. A radio network temporary identifier (RNTI) , a search space (e.g., search space type or search space index) , or a control resource set (CORESET) of the DCI may be used to indicate the type of the PUSCH. A first RNTI, a first search space (e.g., a first search space type or a first search space index) , or a first CORESET of the DCI may indicate that the first type of PUSCH may be scheduled. A second RNTI, a second search space (e.g., a second search space type, a second search space index) , or a second CORESET of the DCI may indicate that the second type of PUSCH may be scheduled.

The first type of PUSCH may carry the data that may be common for the first user device 102 (1) and the second user device 102 (2) . The first user device 102 (1) and the second user device 102 (2) may transmit the first type of PUSCH in the same resource. The first user device 102 (1) and the second user device 102 (2) may perform the same processing to the first type of PUSCH, which may include at least one of coding, scrambling, modulation, layer mapping, transform precoding, precoding, mapping symbols to virtual resource blocks, or mapping from virtual resource blocks to physical resource blocks. The second type of PUSCH may carry the data that may be specific for the first user device 102 (1) or for the second user device 102 (2) .

Additionally, in some embodiments, only the data of the first type of radio bearer may be mapped to the first type of PUSCH. In other embodiments, the data PDU of the first type of radio bearer may be mapped to the first type of PUSCH. The data PDU may include at least one of a RLC data PDU, a PDCP data PDU, or a SDAP PDU. The control PDU of the first type of radio bearer may be mapped to the first type of PUSCH. Alternatively, the control PDU of the first type of radio bearer may not be mapped to the first type of PUSCH. The control PDU may include at least one of a RLC control PDU, a PDCP control PDU, or a SDAP control PDU. The control PDU of the first type of radio bearer may be only mapped to the second type of PUSCH. The data PDU or control PDU of the second type of radio bearer may be mapped to the second type of PUSCH. The MAC CE may be only mapped to the second type of PUSCH.

Additionally, in some embodiments, for a logical channel, the network device 104 may configure the allowed PUSCH type. The logical channel may be selected to be mapped to the PUSCH if the PUSCH satisfies the allowed PUSCH type configured by the network device 104. The logical channel may not be selected to be mapped to the PUSCH if the PUSCH does not satisfy the allowed PUSCH type configured by the network device 104. For the logical channel of the first type of radio bearer, the allowed PUSCH type that the network device 104 configures may be the first type. For the logical channel of the second type of radio bearer, the allowed PUSCH type that the network device 104 configures may be the second type. Therefore, the logical channel of the first radio bearer may be selected to be mapped to the first type of PUSCH, and may not be selected to be mapped to the second type of PUSCH. The logical channel of the second radio bearer may be selected to be mapped to the second type of PUSCH. The logical channel of the second radio bearer may not be selected to be mapped to the first type of PUSCH.

Additionally, in some embodiments, for the data PDU of the logical channel, the network device 104 may configure the allowed PUSCH type. The data PDU may be selected to be mapped to the PUSCH if the PUSCH satisfies the allowed PUSCH type configured by the network device 104. The data PDU may not be selected to be mapped to the PUSCH if the PUSCH does not satisfy the allowed PUSCH type. For the control PDU of the logical channel, the network device 104 may configure the allowed PUSCH type. The control PDU may be selected to be mapped to the PUSCH if the PUSCH satisfies the allowed PSUCH type configured by the network device 104. The control PDU may not be selected to be mapped to the PUSCH if the PUSCH does not satisfy the allowed PSUCH type configured by the network device 104. For example, for the data PDU of logical channel, the allowed PUSCH type that the network device 104 configures may be the first type. For the control PDU of logical channel, the allowed PUSCH type that the network device 104 configures may be the second type. Therefore, the data PDU may be selected to be mapped to the first type of PUSCH. The data PDU may not be selected to be mapped to the second type of PUSCH. The control PDU may be selected to be mapped to the second type of PUSCH. The control PDU may not be selected to be mapped to the first type of PUSCH.

Additionally, in some embodiments, for the MAC CE, the network device 104 may configure the allowed PUSCH type. The MAC CE may be selected to be mapped to a PUSCH if the PUSCH satisfies the allowed PUSCH type. The MAC CE may not be selected to be mapped to a PUSCH if the PUSCH does not satisfy the allowed PUSCH type. For example, the network device 104 may configure the allowed PUSCH type to be the second type. Therefore, the MAC CE may be selected to be mapped to the second type of PUSCH. The MAC CE may not be selected to be mapped to the first type of PUSCH.

Additionally, in some embodiments, the PUSCH type may be reflected by the third field value in a DCI, a RNTI of the DCI, a search space of the DCI, or a CORESET of the DCI. That is, for a logical channel, a data PDU of the logical channel, a control PDU of the logical channel, or a MAC CE, the network device 104 may configure the allowed third value, the allowed RNTI, the allowed search space, or the allowed CORESET. The logical channel, the data PDU of the logical channel, the control PDU of the logical channel, or the MAC CE may be selected to be mapped to the PUSCH scheduled by the DCI that may include the allowed third value, or by the DCI with the allowed RNTI, the allowed search space, or the allowed CORESET. The logical channel, the data PDU of the logical channel, the control PDU of the logical channel, or the MAC CE may not be selected to be mapped to the PUSCH if the PUSCH is scheduled by the DCI that may not include the allowed third value, or if the PUSCH is scheduled by the DCI without the allowed RNTI, without the allowed search space, or without the allowed CORESET.

Additionally, in some embodiments, for the PUSCH, a given user device 102 may allocate resources to the one or more selected logical channels. Each logical channel may be configured with a priority. In some of these embodiments, the user device 102 may allocate resources to the one or more selected logical channels only according to the priority. In particular of these embodiments, the user device 102 may allocate the resources to the logical channel with the highest priority. After the data of the logical channel is exhausted, the user device 102 may allocate resources to the logical channel with the second highest priority if there are remaining resources, and so on.

The network device 104 may configure or indicate the time for a given user device 102 in accordance with the embodiments described herein. The network device 104 may configure the user device 102 to reset the MAC layer 204 at the configured time. In the user device side, the user device 102 may reset the MAC layer 204 at the configured time. The network device 104 may configure the same time for the first user device 102 (1) and the second user device 102 (2) . Correspondingly, the first user device 102 (1) and the second user device 102 (2) may be able to reset their respective MAC layers 204 at the same time.

The description and accompanying drawings above provide specific example embodiments and implementations. The described subject matter may, however, be embodied in a variety of different forms and, therefore, covered or claimed subject matter is intended to be construed as not being limited to any example embodiments set forth herein. A reasonably broad scope for claimed or covered subject matter is intended. Among other things, for example, subject matter may be embodied as methods, devices, components, systems, or non-transitory computer-readable media for storing computer codes. Accordingly, embodiments may, for example, take the form of hardware, software, firmware, storage media or any combination thereof. For example, the method embodiments described above may be implemented by components, devices, or systems including memory and processors by executing computer codes stored in the memory.

Throughout the specification and claims, terms may have nuanced meanings suggested or implied in context beyond an explicitly stated meaning. Likewise, the phrase “in one embodiment/implementation” as used herein does not necessarily refer to the same embodiment and the phrase “in another embodiment/implementation” as used herein does not necessarily refer to a different embodiment. It is intended, for example, that claimed subject matter includes combinations of example embodiments in whole or in part.

In general, terminology may be understood at least in part from usage in context. For example, terms, such as “and” , “or” , or “and/or, ” as used herein may include a variety of meanings that may depend at least in part on the context in which such terms are used. Typically, “or” if used to associate a list, such as A, B or C, is intended to mean A, B, and C, here used in the inclusive sense, as well as A, B or C, here used in the exclusive sense. In addition, the term “one or more” as used herein, depending at least in part upon context, may be used to describe any feature, structure, or characteristic in a singular sense or may be used to describe combinations of features, structures or characteristics in a plural sense. Similarly, terms, such as “a, ” “an, ” or “the, ” may be understood to convey a singular usage or to convey a plural usage, depending at least in part upon context. In addition, the term “based on” may be understood as not necessarily intended to convey an exclusive set of factors and may, instead, allow for existence of additional factors not necessarily expressly described, again, depending at least in part on context.

Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present solution should be or are included in any single implementation thereof. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present solution. Thus, discussions of the features and advantages, and similar language, throughout the specification may, but do not necessarily, refer to the same embodiment.

Furthermore, the described features, advantages and characteristics of the present solution may be combined in any suitable manner in one or more embodiments. One of ordinary skill in the relevant art will recognize, in light of the description herein, that the present solution can be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the present solution.

The subject matter of the disclosure may also relate to or include, among others, the following aspects:

A first aspect includes a method for wireless communication that includes: receiving, by a user device, at least one of time information or a data packet number from a network device; and performing, by the user device, a processing operation at a time indicated by the time information or at the data packet number.

A second aspect includes a method for wireless communication that includes: determining, by a network device, at least one of time information or a data packet number at which a user device is to perform a processing operation; and transmitting, by the network device, the at least one of the time information or the data packet number to the user device.

A third aspect includes any of the first or second aspects, and further includes wherein the time indicated by the time information comprises an absolute time, a starting boundary of a specific time unit, or an ending boundary of the specific time unit.

A fourth aspect includes the third aspect, and further includes wherein the specific time unit is indicated by the network device.

A fifth aspect includes any of the first through fourth aspects, and further includes wherein the data packet number comprises a packet data convergence protocol (PDCP) sequence number (SN) , a count, or a radio link control (RLC) SN.

A sixth aspect includes the fifth aspect, and further includes wherein the data packet number is periodic.

A seventh aspect includes any of the first through sixth aspects, and further includes wherein the processing operation includes: establishing a mapping relationship between a quality of service (QoS) flow and an indicated radio bearer; delivering a control protocol data unit (PDU) to a lower layer before or after a data packet indicated by the data packet number; establishing or re-establishing a packet data convergence protocol (PDCP) entity for the indicated radio bearer and setting a plurality of state variables to initial values for the indicated radio bearer; performing a data packet retransmission at the PDCP layer or a radio link control (RLC) layer; setting or resetting a medium access control (MAC) layer; or starting or stopping a data channel transmission.

An eighth aspect includes any of the first through seventh aspects, and further includes: receiving, by the user device, a downlink control information (DCI) that schedules at least one physical uplink shared channel (PUSCH) from the network device; and transmitting, by the user device, the PUSCH to the network device.

A ninth aspect includes the eighth aspect, and further includes: transmitting, by the user device, a physical uplink control channel (PUCCH) that comprises at least one information bit indicating that the user device has received the DCI.

A tenth aspect includes any of the first through ninth aspects, and further includes: transmitting, by the network device, a downlink control information (DCI) that schedules at least one physical uplink shared channel (PUSCH) ; and receiving, by the network device, the PUSCH from the user device.

An eleventh aspect includes the tenth aspect, and further includes: receiving, by the network device, a physical uplink control channel (PUCCH) that comprises at least one information bit indicating that the user device has received the DCI.

A twelfth aspect includes any of the ninth or eleventh aspects, and further includes wherein an offset between the PUCCH and the DCI is configured by the network device.

A thirteenth aspect includes any of the ninth, eleventh, or twelfth aspects, and further includes wherein the PUCCH and the PUSCH are transmitted in different time units.

A fourteenth aspect includes any of the eighth through thirteenth aspects, and further includes wherein the PUSCH comprises at least a first reserved resource and a second reserved resource, the first reserved resource and the second reserved resource configured by the network device.

A fifteenth aspect includes the fourteenth aspect, and further includes: transmitting, by the user device, on the first reserved resource within the PUSCH, one information bit indicating that the user device has received the DCI.

A sixteenth aspect includes any of the fourteenth or fifteenth aspects, and further includes: receiving, by the network device, on the first reserved resource within the PUSCH, one information bit indicating that the user device has received the DCI.

A seventeenth aspect includes any of the fifteenth or sixteenth aspects, and further includes wherein the user device is configured to not transmit anything on the second reserved resource.

An eighteenth aspect includes any of the eighth through seventeenth aspects, and further includes wherein the DCI comprises a field indicating a DCI order.

A nineteenth aspect includes the eighteenth aspect, and further includes: in response to determining that there is a missing DCI between a previous DCI and a current DCI, generating, by the user device, one or more transport blocks; and discarding, by the user device, the one or more transport blocks.

A twentieth aspect includes the nineteenth aspect, and further includes wherein a number of the one or more transport blocks is equal to a number of one or more missing DCIs times a number of transport blocks that can be scheduled by the DCI.

A twenty-first aspect includes any of the twentieth or twenty-first aspects, and further includes wherein a size of each of the one or more transport blocks is configured by the network device.

A twenty-second aspect includes a wireless communications apparatus that includes a processor and a memory, wherein the processor is configured to read code from the memory to implement any of the first through twenty-first aspects.

A twenty-third aspect includes a computer program product that includes a computer-readable program medium comprising code stored thereupon, the code, when executed by a processor, causing the processor to implement any of the first through twenty-first aspects.

In addition to the features mentioned in each of the independent aspects enumerated above, some examples may show, alone or in combination, the optional features mentioned in the dependent aspects and/or as disclosed in the description above and shown in the figures.

Claims

A method for wireless communication, the method comprising:

receiving, by a user device, at least one of time information or a data packet number from a network device; and

performing, by the user device, a processing operation at a time indicated by the time information or at the data packet number.
A method for wireless communication, the method comprising:

determining, by a network device, at least one of time information or a data packet number at which a user device is to perform a processing operation; and

transmitting, by the network device, the at least one of the time information or the data packet number to the user device.
The method of any of claim 1 or 2, wherein the time indicated by the time information comprises an absolute time, a starting boundary of a specific time unit, or an ending boundary of the specific time unit.
The method of claim 3, wherein the specific time unit is indicated by the network device.
The method of any of claim 1 or 2, wherein the data packet number comprises a packet data convergence protocol (PDCP) sequence number (SN) , a count, or a radio link control (RLC) SN.
The method of claim 5, wherein the data packet number is periodic.
The method of any of claim 1 or 2, wherein the processing operation comprises:

establishing a mapping relationship between a quality of service (QoS) flow and an indicated radio bearer;

delivering a control protocol data unit (PDU) to a lower layer before or after a data packet indicated by the data packet number;

establishing or re-establishing a packet data convergence protocol (PDCP) entity for the indicated radio bearer and setting a plurality of state variables to initial values for the indicated radio bearer;

performing a data packet retransmission at the PDCP layer or a radio link control (RLC) layer;

setting or resetting a medium access control (MAC) layer; or

starting or stopping a data channel transmission.
The method of claim 1, further comprising:

receiving, by the user device, a downlink control information (DCI) that schedules at least one physical uplink shared channel (PUSCH) from the network device; and

transmitting, by the user device, the PUSCH to the network device.
The method of claim 8, further comprising:

transmitting, by the user device, a physical uplink control channel (PUCCH) that comprises at least one information bit indicating that the user device has received the DCI.
The method of claim 2, further comprising:

transmitting, by the network device, a downlink control information (DCI) that schedules at least one physical uplink shared channel (PUSCH) ; and

receiving, by the network device, the PUSCH from the user device.
The method of claim 10, further comprising:

receiving, by the network device, a physical uplink control channel (PUCCH) that comprises at least one information bit indicating that the user device has received the DCI.
The method of any of claim 9 or 11, wherein an offset between the PUCCH and the DCI is configured by the network device.
The method of any of claim 9 or 11, wherein the PUCCH and the PUSCH are transmitted in different time units.
The method of any of claim 8 or 10, wherein the PUSCH comprises at least a first reserved resource and a second reserved resource, the first reserved resource and the second reserved resource configured by the network device.
The method of claim 14, further comprising:

transmitting, by the user device, on the first reserved resource within the PUSCH, one information bit indicating that the user device has received the DCI.
The method of claim 14, further comprising:

receiving, by the network device, on the first reserved resource within the PUSCH, one information bit indicating that the user device has received the DCI.
The method of claim 15, wherein the user device is configured to not transmit anything on the second reserved resource.
The method of any of claim 8 or 10, wherein the DCI comprises a field indicating a DCI order.
The method of claim 18, further comprising:

in response to determining that there is a missing DCI between a previous DCI and a current DCI, generating, by the user device, one or more transport blocks; and

discarding, by the user device, the one or more transport blocks.
The method of claim 19, wherein a number of the one or more transport blocks is equal to a number of one or more missing DCIs times a number of transport blocks that can be scheduled by the DCI.
The method of claim 19, wherein a size of each of the one or more transport blocks is configured by the network device.
A wireless communications apparatus comprising a processor and a memory, wherein the processor is configured to read code from the memory to implement a method of any of claims 1 to 21.
A computer program product comprising a computer-readable program medium comprising code stored thereupon, the code, when executed by a processor, causing the processor to implement a method of any of claims 1 to 21.