Patent Description:
Examples of such multiple access technologies include code division multiple access (CDMA) systems, time division multiple access (TDMA) systems, frequency-division multiple access (FDMA) systems, orthogonal frequency-division multiple access (OFDMA) systems, single carrier frequency-division multiple access (SC-FDMA) systems, time division synchronous code division multiple access (TD-SCDMA) systems, and Long Term Evolution (LIE).

As will be described in more detail herein, a BS may be referred to as a NodeB, a gNB, an access point (AP), a radio head, a transmit receive point (TRP), a new radio (NR) BS, a <NUM> Node B, and/or the like.

New radio (NR. ), which may also be referred to as <NUM>, is a set of enhancements to the LTE mobile standard promulgated by the Third Generation Partnership Project (3GPP). NR is designed to better support mobile broadband Internet access by improving spectral efficiency, lowering costs, improving services, making use of new spectrum, and better integrating with other open standards using orthogonal frequency division multiplexing (OFDM) with a cyclic prefix (CP) (CP-OFDM) on the downlink (DL), using CP-OFDM and/or SC-FDM (e.g., also known as discrete Fourier transform spread OFDM: (DFT-s-OFDM)) on the uplink (UL), as well as supporting beamforming, multiple-input multiple-output (MIMO) antenna technology, and carrier aggregation.

<CIT> relates to a data transmission method. <CIT> relates to a method and apparatus for transmitting machine type communication data via a packet downlink control channel.

The dependent claims provide advantageous embodiments.

On the uplink, at UE <NUM>, a transmit processor <NUM> may receive and process data from a data source <NUM> and control information (e.g., for reports compri sing RSRP, RSSI, RSRQ, CQI, and/or the like) from controller/processor <NUM>.

Controller/processor <NUM> of base station <NUM>, controller/processor <NUM> of UE <NUM>, and/or any other component(s) of <FIG> may perform one or more techniques associated with transmitting data in a control channel, as described in more detail elsewhere herein. For example, controller/processor <NUM> of base station <NUM>, controller/processor <NUM> of UE <NUM>, and/or any other component(s) of <FIG> may perform or direct operations of, for example, process <NUM> of <FIG>, process <NUM> of <FIG>, process <NUM> of <FIG>, process <NUM> of <FIG>, and/or other processes as described herein. Memories <NUM> and <NUM> may store data and program codes for base station <NUM> and UE <NUM>, respectively.

In some aspects, UE <NUM> may include means for receiving an indicator, in a physical downlink control channel (PDCCH) payload, that indicates whether the PDCCH payload includes data or downlink control information (DCI) for obtaining the data; means for obtaining at least one of the data or the DCI based at least in part on the indicator; and/or the like. Additionally, or alternatively, UE <NUM> may include means for determining whether to transmit data in a physical uplink control channel (PUCCH) payload or a physical uplink shared channel (PUSCH) payload based at least in part on a size of the data; means for selectively transmitting the data in the PUCCH payload or the PUSCH payload based at least in part on the size of the data, wherein the PUCCH payload includes an indicator that indicates whether the PUCCH payload includes the data or uplink control information (UCI); and/or the like. In some aspects, such means may include one or more components of UE <NUM> described in connection with <FIG>.

In some aspects, base station <NUM> may include means for determining whether to transmit data in a physical downlink control channel (PDCCH) payload or a physical downlink shared channel (PDSCH) payload based at least in part on a size of the data; means for transmitting an indicator, in the PDCCH payload, that indicates whether the PDCCH payload includes the data or downlink control information (DCI) for obtaining the data from the PDSCH payload; means for selectively transmitting the data in the PDCCH payload or the PDSCH payload based at least in part on the size of the data; and/or the like. Additionally, or alternatively, base station <NUM> may include means for receiving an indicator, in a physical uplink control channel (PUCCH) payload, that indicates whether the PUCCH payload includes data or uplink control information (UCI); means for obtaining at least one of the data or the UCI based at least in part on the indicator; and/or the like. In some aspects, such means may include one or more components of base station <NUM> described in connection with <FIG>.

<FIG> shows an example frame structure <NUM> for FDD in a telecommunications system (e.g., NR). Each radio frame may have a predetermined duration and may be partitions into a set of Z (Z ≥ <NUM>) subframes (e.g., with indices of <NUM> through Z-<NUM>). Each subframe may include a set of slots (e.g., two slots per subframe are shown in <FIG>). For example, each slot may include seven symbol periods (e.g., as shown in <FIG>), fifteen symbol periods, and/or the like. In a case where the subframe includes two slots, the subframe may include <NUM> symbol periods, where the <NUM> symbol periods in each subframe may be assigned indices of <NUM> through <NUM>-<NUM>. In some aspects, a scheduling unit for the FDD may frame-based, subframe-based, slot-based, symbol-based, and/or the like.

Similarly, in some aspects, one or more SS blocks of the SS burst may be transmitted in consecutive radio resources (e.g., consecutive symbol periods) during one or more subframes.

The base station may transmit system information, such as system information blocks (SIBs) on a physical downlink shared channel (PDSCH) in certain subframes. The base station may transmit control information/data on a physical downlink control channel (PDCCH) in C symbol periods of a subframe, where B may be configurable for each subframe. The base station may transmit traffic data and/or other data on the PDSCH in the remaining symbol periods of each subframe.

Other examples are possible and may differ from what was described with regard to <FIG> and <FIG>.

<FIG> shows an example subframe format <NUM> with a normal cyclic prefix. Each resource block may cover a set to of subcarriers (e.g., <NUM> subcarriers) in one slot and may include a number of resource elements. In some aspects, subframe format <NUM> may be used for transmission of SS blocks that carry the PSS, the SSS, the PBCH, and/or the like, as described herein.

An interlace structure may be used for each of the downlink and uplink for FDD in certain telecommunications systems (e.g., NR). For example, Q interlaces with indices of <NUM> through Q - <NUM> may be defined, where Q may be equal to <NUM>, <NUM>, <NUM>, <NUM>, or some other value. Each interlace may include subframes that are spaced apart by Q frames. In particular, interlace q may include subframes q, q + Q, q + 2Q, etc., where q ∈ {<NUM>,.

Each radio frame may include <NUM> subframes with a length of <NUM>. Consequently, each subframe may have a length of <NUM>. Each subframe may indicate a link direction (e.g., DL or UL) for data transmission and the link direction for each subframe may be dynamically switched. Each subframe may include DL/UL data as well as DL/UL control data.

<FIG> is a diagram <NUM> showing an example of a DL-centric subframe or wireless communication structure. In some aspects, the control portion <NUM> may include legacy PDCCH information, shortened PDCCH (sPDCCH) information), a control format indicator (CFI) value (e.g., carried on a physical control format indicator channel (PCFICH)), one or more grants (e.g., downlink grants, uplink grants, and/or the like), and/or the like.

The DL-centric subframe may also include an UL short burst portion <NUM>. The UL short burst portion <NUM> may sometimes be referred to as an UL burst, an UL burst portion, a common UL burst, a short burst, an UL short burst, a common UL short burst, a common UL short burst portion, and/or various other suitable terms. In some aspects, the UL short burst portion <NUM> may include one or more reference signals. Additionally, or alternatively, the UL short burst portion <NUM> may include feedback information corresponding to various other portions of the DL-centric subframe. For example, the UL short burst portion <NUM> may include feedback information corresponding to the control portion <NUM> and/or the data portion <NUM>. Non-limiting examples of information that may be included in the UL short burst portion <NUM> include an ACK signal (e.g., a PUCCH ACK, a PUSCH ACK, an immediate ACK), a NACK signal (e.g., a PUCCH NACK, a PUSCH NACK, an immediate NACK), a scheduling request (SR), a buffer status report (BSR), a HARQ indicator, a channel state indication (CSI), a channel quality indicator (CQI), a sounding reference signal (SRS), a demodulation reference signal (DMRS), PUSCH data, and/or various other suitable types of information. The UL short burst portion <NUM> may include additional or alternative information, such as information pertaining to random access channel (RACH) procedures, scheduling requests, and various other suitable types of information.

<FIG> is a diagram <NUM> showing an example of an UL-centric subframe or wireless communication structure. The UL-centric subframe may include a control portion <NUM>. The control portion <NUM> may exist in the initial or beginning portion of the UL-centric subframe. The control portion <NUM> in <FIG> may be similar to the control portion <NUM> described above with reference to <FIG>. The UL-centric subframe may also include an UL long burst portion <NUM>. The UL long burst portion <NUM> may sometimes be referred to as the payload of the UL-centric subframe. The UL portion may refer to the communication resources utilized to communicate UL data from the subordinate entity (e.g., UE) to the scheduling entity (e.g., UE or BS). In some configurations, the control portion <NUM> may be a physical DL control channel (PDCCH).

The UL-centric subframe may also include an UL short burst portion <NUM>. The UL short burst portion <NUM> in <FIG> may be similar to the UL short burst portion <NUM> described above with reference to <FIG>, and may include any of the information described above in connection with <FIG>. The foregoing is merely one example of an UL-centric wireless communication structure, and alternative structures having similar features may exist without necessarily deviating from the aspects described herein.

In some aspects, the sidelink signals may be communicated using a licensed spectrum (unlike wireless local area networks, which typically use an unlicensed spectrum).

<FIG> is a diagram illustrating an example <NUM> of transmitting data in a control channel, in accordance with various aspects of the present disclosure.

As shown in <FIG>, a base station <NUM> and a UE <NUM> may communicate with one another. For example, the base station <NUM> may transmit downlink data (e.g., a protocol data unit (PDU) in the media access control (MAC) layer, and/or the like) to the UE <NUM>. In some cases, the downlink data may be transmitted on a PDSCH. However, in some scenarios, transmitting data on the PDSCH may be inefficient. For example, when data is transmitted on the PDSCH, downlink control information (DCI) must first be transmitted on the PDCCH. The DCI indicates information used to obtain and/or decode the data on the PDSCH, such as a modulation and coding scheme (MCS) used to modulate and/or encode the data, a resource allocation for the data (e.g., one or more resource blocks on which the data is to be transmitted), and/or the like. This design may be efficient for a large amount of data, but may be inefficient for a small amount of data. This may lead to inefficient use of device and/or network resources, particularly in scenarios where small data packets are communicated more frequently than large data packets, such as when the UE <NUM> is an IoT UE, when the UE <NUM> is using a service or application that uses a small amount of data, when small packets are being reported (e.g., a timing advance (TA) value, a buffer status report (BSR)), and/or the like.

As an example, for data with a small packet size of <NUM> bits, <NUM> bits of PDCCH payload may be used to indicate DCI for obtaining the data, and <NUM> bits of PDSCH payload may be used to transmit the data, for a total of <NUM> bits that consume network and device resources. Since the payload size of the PDCCH is around <NUM> to <NUM> bits, this small amount of data may be transmitted directly in the PDCCH, for a total of <NUM> bits that consume network and device resources, thereby saving <NUM> bits of consumed resources as compared to transmitting the data in the PDSCH. Furthermore, in <NUM>/NR, information carried on the PDCCH may be encoded using polar coding, and information carried on the PDSCH may be encoded using low-density parity-check (LDPC) coding. For small block sizes, polar coding outperforms LDPC coding, and thus small amounts of data may be transmitted more reliably on the PDCCH as compared to the PDSCH.

However, if the base station <NUM> sometimes transmits data on the PDCCH, and sometimes transmits data on the PDSCH and uses the PDCCH to transmit DCI for obtaining the data on the PDSCH, then the UE <NUM> may encounter errors if the UE <NUM> is unable to determine how to interpret and/or use the information (e.g., data or DCI) received on the PDCCH. Some techniques and apparatus described herein permit the base station <NUM> to indicate whether the PDCCH is being used to carry data or DCI, thereby reducing errors at the UE <NUM> and allowing for dynamic use of the PDCCH or the PDSCH for data transmission depending on a size of the data. In this way, the PDCCH may be used for increased efficiency when the data is small, and the PDSCH may be used for increased efficiency when the data is large. Additional details are described below.

As shown by reference number <NUM>, the base station <NUM> may determine whether to transmit data in a PDCCH payload or a PDSCH payload based at least in part on a size of the data. For example, as shown by reference number <NUM>, the base station <NUM> may determine to transmit the data in the PDSCH payload when the size of the data satisfies a threshold (e.g., is greater than the threshold, is greater than or equal to the threshold, and/or the like). Conversely, the base station <NUM> may determine to transmit the data in the PDCCH payload when the size of the data does not satisfy the threshold (e.g., is less than the threshold, is less than or equal to the threshold, and/or the like).

In some aspects, the threshold may be determined based at least in part on a size of the PDCCH payload. For example, if data is not to be segmented across multiple PDCCH payloads, then the threshold may be equal to the size of the PDCCH payload. In this way, the data may be transmitted in the PDCCH payload if the size of the data is less than or equal to the size of the PDCCH payload, and may be transmitted on the PDSCH otherwise. In some aspects, the size of the PDCCH payload may be determined based at least in part on a transmission mode for communications between the base station <NUM> and the UE <NUM>. Thus, in some aspects, the threshold may be determined based at least in part on the transmission mode. Additionally, or alternatively, the size of the PDCCH payload may be determined based at least in part on an aggregation level to be used for communications between the base station <NUM> and the UE <NUM>, which may be determined based at least in part on channel conditions. Thus, in some aspects, the threshold may be determined based at least in part on the aggregation level and/or channel conditions.

In some aspects, the base station <NUM> may determine to segment the data across multiple PDCCH payloads. In this case, the threshold may be greater than the size of a single PDCCH payload. In some aspects, the threshold may be determined based at least in part on a combined size of a number of PDCCH payloads, so as to limit segmentation of the data across no more than a threshold number of PDCCH payloads. Additionally, or alternatively, the base station <NUM> may use multiple thresholds to determine whether to transmit the data in a single PDCCH payload, to segment the data across multiple PDCCH payloads, or to transmit the data in a PDSCH payload. For example, the base station <NUM> may segment the data across multiple PDCCH payloads based at least in part on determining that the size of the data satisfies a first threshold (e.g., is greater than a first threshold for transmitting the data in a single PDCCH payload, is greater than or equal to the first threshold, and/or the like) but does not satisfy a second threshold (e.g., is less than a second threshold for transmitting the data on the PDSCH, is less than or equal to the second threshold, and/or the like).

As shown by reference number <NUM>, the base station <NUM> transmits and the UE <NUM> receives an indicator, in the PDCCH payload, that indicates whether the PDCCH payload includes the data or DCI for obtaining the data from the PDSCH payload. For example, the indicator may indicate that the PDCCH payload includes the DCI, for obtaining the data from the PDSCH, when the size of the data satisfies a threshold (e.g., is greater than the threshold, is greater than or equal to the threshold, and/or the like). Conversely, the indicator may indicate that the PDCCH payload includes the data when the size of the data does not satisfy the threshold (e.g., is less than the threshold, is less than or equal to the threshold, and/or the like). In some aspects, the base station <NUM> may encode the PDCCH payload using polar coding.

In some aspects, the indicator is included in a bit field, of the PDCCH payload, dedicated to indicating whether the PDCCH payload includes data or DCI. In some aspects, the indicator may be a binary indicator of one bit, where a first value of the bit indicates that the PDCCH payload includes data, and a second value of the bit indicates that the PDCCH payload includes DCI. In some aspects, the indicator may be multiple bits. In this case, different values of the indicator may indicate whether the PDCCH payload includes only data (and not DCI), includes only DCI (and not data), or includes both data and DCI. Additionally, if the data is included in the PDCCH, then different values of the indicator indicate whether the data is self-contained within the PDCCH payload (e.g., within a single PDCCH payload) or segmented across multiple PDCCH payloads. Additionally, or alternatively, if the data is segmented across multiple PDCCH payloads, different values of the indicator may indicate a number of PDCCH payloads or segments used to transmit the data (e.g., a number of PDCCH payloads across which the data is segmented), a start of the data (e.g., an indication that a current PDCCH payload includes the start of the data), an end of the data (e.g., an indication that a current PDCCH payload includes the end of the data), and/or the like.

The indicator is an initial state of a cyclic redundancy check (CRC) that includes a predefined sequence of bits. For example, the base station <NUM> may use an initial sequence of CRC bits (e.g., all zeroes, all ones, or a particular sequence of zeroes and ones) when encoding the PDCCH payload. In this case, different initial sequences of CRC bits may be used for different indications, as described above (e.g., in connection with using a dedicated bit field as the indicator). When the UE <NUM> decodes the PDCCH payload, the UE <NUM> may test using multiple different hypotheses about the initial state of the CRC, and the initial state that is the correct hypothesis (e.g., that results in proper decoding with a CRC check that passes) may indicate whether the PDCCH payload includes data, may indicate whether the PDCCH payload includes DCI, and/or may indicate one or more other indications described above.

As shown by reference number <NUM>, the UE <NUM> receives the indicator in the PDCCH payload, and may use the indicator to obtain the data and/or the DCI. For example, if the indicator indicates that the PDCCH payload includes data, then the UE <NUM> may obtain the data directly from the PDCCH payload (e.g., rather than interpreting the data as DCI). Conversely, if the indicator indicates that the PDCCH payload includes DCI, then the UE <NUM> may use the DCI to obtain the data on the PDSCH. In some aspects, the PDCCH payload may be encoded using polar coding, and the UE <NUM> may use successive cancellation and/or another suitable technique to decode the PDCCH payload.

In some aspects, the UE <NUM> may obtain the data from multiple PDCCH payloads if the indicator indicates that the data has been segmented across multiple PDCCH payloads. Additionally, or alternatively, the UE <NUM> may use the indicator to determine the start of the segmented data, an end of the segment data, a number of PDCCH payloads that include the segmented data, and/or the like.

As shown by reference number <NUM>, the base station <NUM> may selectively transmit the data in the PDCCH payload or the PDSCH payload based at least in part on the size of the data. For example, the base station <NUM> may transmit the data in the PDCCH payload (or may segment the data across multiple PDCCH payloads) if a size of the data does not satisfy a threshold, as described above. In this case, the indicator in the PDCCH payload may indicate that the PDCCH payload includes the data, and the UE <NUM> may use the indicator to determine that the PDCCH payload includes the data. Based at least in part on this determination, the UE <NUM> may obtain the data from the PDCCH payload.

Alternatively, the base station <NUM> may transmit the data in the PDSCH payload if a size of the data satisfies a threshold, as described above. In this case, the indicator in the PDCCH payload may indicate that the PDCCH payload includes DCI, and the UE <NUM> may use the indicator to determine that the PDCCH payload includes the DCI. Based at least in part on this determination, the UE <NUM> may use the DCI to obtain the data from the PDSCH payload.

In this way, the base station <NUM> and the UE <NUM> may transmit and receive data in a PDCCH payload when the data is small, thereby taking advantage of efficiencies associated with transmitting small data on the PDCCH, including conserving network resources (e.g., by using only the PDCCH instead of both the PDCCH and the PDSCH), conserving resources (e.g., processing power, battery power, memory, and/or the like) of the base station <NUM> and the UE <NUM> (e.g., due to processing only the PDCCH payload instead of both PDCCH and PDSCH payloads), reducing latency for small data (e.g., that can be transmitted in a limited number of PDCCH payloads) improving reliability for small data using polar coding, and/or the like. Furthermore, the base station <NUM> and the UE <NUM> may transmit and receive data in a PDSCH payload when the data is large, thereby taking advantage of efficiencies associated with transmitting large data on the PDSCH, including improving performance for large data (e.g., when the data is too large to efficiently communicate on the PDCCH), reducing latency for large data (e.g., that would require a large number of PDCCH payloads that are separated in time), improving reliability for large data using LDPC coding, and/or the like.

<FIG> is a diagram illustrating another example <NUM> of transmitting data in a control channel, in accordance with various aspects of the present disclosure.

As shown in <FIG>, a base station <NUM> and a UE <NUM> may communicate with one another. For example, the UE <NUM> may transmit uplink data (e.g., a MAC PDU and/or the like) to the base station <NUM>. In some cases, the uplink data may be transmitted on a PUSCH. However, in some scenarios, transmitting data on the PUSCH may be inefficient. For example, when data is transmitted on the PUSCH, DCI must first be received on the PDCCH. The DCI indicates information to be used to encode and/or transmit the data on the PUSCH, such as MCS used to modulate and/or encode the data, and/or the like. This design may be efficient for a large amount of data, but may be inefficient for a small amount of data. This may lead to inefficient use of device and/or network resources, particularly in scenarios where small data packets are communicated more frequently than large data packets, as described above in connection with <FIG>.

As an example, for data with a small packet size of <NUM> bits, <NUM> bits of PDCCH payload may be used to indicate DCI for transmitting the data, and <NUM> bits of PUSCH payload may be used to transmit the data, for a total of <NUM> bits that consume network and device resources. In some aspects, this small amount of data may be transmitted directly in the PUCCH, for a total of <NUM> bits that consume network and device resources, thereby saving <NUM> bits of consumed resources as compared to transmitting the data in the PUSCH. Furthermore, in <NUM>/NR, information carried on the PUCCH may be encoded using polar coding, and information carried on the PUSCH may be encoded using low-density parity-check (LDPC) coding. For small block sizes, polar coding outperforms LDPC coding, and thus small amounts of data may be transmitted more reliably on the PUCCH as compared to the PUSCH. Furthermore, there may be a delay between receiving the DCI in the PDCCH and transmitting the corresponding data on the PUSCH (e.g., due to a structure of a slot, as described above in connection with <FIG> and <FIG>, due to a sequence of slot types that do not include the PUSCH, and/or the like). Since the resource allocation for PUCCH may be preconfigured (e.g., during radio resource control (RRC) signaling and/or the like), this resource allocation may be used to directly transmit data on the PUCCH.

However, if the UE <NUM> sometimes transmits data on the PUCCH, sometimes transmits data on the PUSCH, and/or sometimes transmits uplink control information (UCI) on the PUCCH, then the base station <NUM> may encounter errors if the base station <NUM> is unable to determine how to interpret and/or use the information (e.g., data or UCI) received on the PUCCH. Some techniques and apparatus described herein permit the UE <NUM> to indicate whether the PUCCH is being used to carry data or UCI, thereby reducing errors at the base station <NUM> and allowing for dynamic use of the PUCCH or the PUSCH for data transmission depending on a size of the data. In this way, the PUCCH may be used for increased efficiency when the data is small, and the PUSCH may be used for increased efficiency when the data is large. Additional details are described below.

As shown by reference number <NUM>, the UE <NUM> may determine whether to transmit data in a PUCCH payload or a PUSCH payload based at least in part on a size of the data. For example, as shown by reference number <NUM>, the UE <NUM> may determine to transmit the data in the PUSCH payload when the size of the data satisfies a threshold (e.g., is greater than the threshold, is greater than or equal to the threshold, and/or the like). Conversely, the UE <NUM> may determine to transmit the data in the PUCCH payload when the size of the data does not satisfy the threshold (e.g., is less than the threshold, is less than or equal to the threshold, and/or the like).

In some aspects, the threshold may be determined based at least in part on a size of the PUCCH payload. For example, if data is not to be segmented across multiple PUCCH payloads, then the threshold may be equal to the size of the PUCCH payload. In this way, the data may be transmitted in the PUCCH payload if the size of the data is less than or equal to the size of the PUCCH payload, and may be transmitted on the PUSCH otherwise. In some aspects, the UE <NUM> may determine a size of the PUCCH payload based at least in part on a set of candidate payload sizes for the PUCCH payload, which may be indicated by the base station <NUM>. In this case, the UE <NUM> may determine a size of the PUCCH payload by selecting a candidate payload size from the set of candidate payload sizes. Additionally, or alternatively, the UE <NUM> may determine a size of the PUCCH payload based at least in part on a PUCCH resource allocation and/or a set of candidate coding rates for transmission of the PUCCH payload, either or both of which may be indicated to the UE <NUM> by the base station <NUM>. In this case, the UE <NUM> may determine a size of the PUCCH payload by selecting a candidate coding rate, from the set of candidate coding rates, and applying the coding rate to the PUCCH resource allocation.

In some aspects, the UE <NUM> may determine to segment the data across multiple PUCCH payloads. In this case, the threshold may be greater than the size of a single PUCCH payload. In some aspects, the threshold may be determined based at least in part on a combined size of a number of PUCCH payloads, so as to limit segmentation of the data across no more than a threshold number of PUCCH payloads. Additionally, or alternatively, the UE <NUM> may use multiple thresholds to determine whether to transmit the data in a single PUCCH payload, to segment the data across multiple PUCCH payloads, or to transmit the data in a PUSCH payload. For example, the UE <NUM> may segment the data across multiple PUCCH payloads based at least in part on determining that the size of the data satisfies a first threshold (e.g., is greater than a first threshold for transmitting the data in a single PUCCH payload, is greater than or equal to the first threshold, and/or the like) but does not satisfy a second threshold (e.g., is less than a second threshold for transmitting the data on the PUSCH, is less than or equal to the second threshold, and/or the like).

As shown by reference number <NUM>, the UE <NUM> transmits and the base station <NUM> receives an indicator, in the PUCCH payload, that indicates whether the PUCCH payload includes the data or UCI. For example, the indicator may indicate that the PUCCH payload includes the UCI when the size of the data satisfies a threshold (e.g., is greater than the threshold, is greater than or equal to the threshold, and/or the like). Conversely, the indicator may indicate that the PUCCH payload includes the data when the size of the data does not satisfy the threshold (e.g., is less than the threshold, is less than or equal to the threshold, and/or the like). In some aspects, the UE <NUM> may encode the PUCCH payload using polar coding. In some aspects, before transmitting a PUCCH payload (e.g., regardless of whether the UE <NUM> has data to transmit), the UE <NUM> may determine whether the PUCCH payload is to include data or UCI, and may transmit an indicator, in the PUCCH payload, that indicates whether the PUCCH payload includes data or UCI. The base station <NUM> may use this indicator to obtain the data or the UCI from the PUCCH payload.

In some aspects, the indicator is included in a bit field, of the PUCCH payload, dedicated to indicating whether the PUCCH payload includes data or UCI. In some aspects, the indicator may be a binary indicator of one bit, where a first value of the bit indicates that the PUCCH payload includes data, and a second value of the bit indicates that the PUCCH payload includes UCI. In some aspects, the indicator may be multiple bits. In this case, different values of the indicator may indicate whether the PUCCH payload includes only data (and not UCI), includes only UCI (and not data), or includes both data and UCI (e.g., data and ACK/NACK feedback and/or the like). Additionally, if the data is included in the PUCCH, then different values of the indicator indicate whether the data is self-contained within the PUCCH payload (e.g., within a single PUCCH payload) or segmented across multiple PUCCH payloads. Additionally, or alternatively, if the data is segmented across multiple PUCCH payloads, different values of the indicator may indicate a number of PUCCH payloads or segments used to transmit the data (e.g., a number of PUCCH payloads across which the data is segmented), a start of the data (e.g., an indication that a current PUCCH payload includes the start of the data), an end of the data (e.g., an indication that a current PUCCH payload includes the end of the data), and/or the like.

The indicator is an initial state of a CRC that includes a predefined sequence of bits. For example, the UE <NUM> may use an initial sequence of CRC bits (e.g., all zeroes, all ones, or a particular sequence of zeroes and ones) when encoding the PUCCH payload. In this case, different initial sequences of CRC bits may be used for different indications, as described above (e.g., in connection with using a dedicated bit field as the indicator). When the base station <NUM> decodes the PUCCH payload, the base station <NUM> may test using multiple different hypotheses about the initial state of the CRC, and the initial state that is the correct hypothesis (e.g., that results in proper decoding with a CRC check that passes) may indicate whether the PUCCH payload includes data, may indicate whether the PUCCH payload includes UCI, and/or may indicate one or more other indications described above.

As shown by reference number <NUM>, the base station <NUM> receives the indicator in the PUCCH payload, and may use the indicator to obtain the data and/or the UCI. For example, if the indicator indicates that the PUCCH payload includes data, then the base station <NUM> may obtain the data directly from the PUCCH payload (e.g., rather than interpreting the data as UCI). Conversely, if the indicator indicates that the PUCCH payload includes UCI, then the base station <NUM> may obtain the UCI (e.g., ACK/NACK feedback, a request for an uplink grant, a scheduling request, and/or the like). In some aspects, the PUCCH payload may be encoded using polar coding, and the base station <NUM> may use successive cancellation and/or another suitable technique to decode the PUCCH payload.

In some aspects, the base station <NUM> may obtain the data from multiple PUCCH payloads if the indicator indicates that the data has been segmented across multiple PUCCH payloads. Additionally, or alternatively, the base station <NUM> may use the indicator to determine the start of the segmented data, an end of the segment data, a number of PUCCH payloads that include the segmented data, and/or the like.

As shown by reference number <NUM>, if the PUCCH payload includes the data, then the base station <NUM> may perform blind decoding to obtain the data from the PUCCH payload. For example, the base station <NUM> may perform blind decoding of the data using a set of payload size hypotheses (e.g., one or more payload size hypotheses). In some aspects, the base station <NUM> may determine the set of payload size hypothesis based at least in part on a set of candidate payload sizes, for the PUCCH payload, indicated by the base station <NUM> to the UE <NUM>. Additionally, or alternatively, the base station <NUM> may determine the set of payload size hypotheses based at least in part on a PUCCH resource allocation indicated by the base station <NUM> to the UE <NUM> and/or a set of candidate coding rates indicated by the base station <NUM> to the UE <NUM>.

As shown by reference number <NUM>, if the PUCCH payload includes UCI that requests an uplink grant, then base station <NUM> may schedule a PUSCH transmission for the UE <NUM>, such as by transmitting an uplink grant for the UE <NUM> in DCI (e.g., transmitted on the PDCCH).

As shown by reference number <NUM>, the UE <NUM> may selectively transmit the data in the PUCCH payload or the PUSCH payload based at least in part on the size of the data. For example, the UE <NUM> may transmit the data in the PUCCH payload (or may segment the data across multiple PUCCH payloads) if a size of the data does not satisfy a threshold, as described above. In this case, the indicator in the PUCCH payload may indicate that the PUCCH payload includes the data, and the base station <NUM> may use the indicator to determine that the PUCCH payload includes the data. Based at least in part on this determination, the base station <NUM> may obtain the data from the PUCCH payload. When the UE <NUM> transmits the data in the PUCCH payload in this manner, such transmission may be performed without first requesting (e.g., in UCI) and/or receiving (e.g., in DCI) an uplink grant for the transmission.

Alternatively, the UE <NUM> may transmit the data in the PUSCH payload if a size of the data satisfies a threshold, as described above. In this case, the UE <NUM> may request an uplink grant from the base station <NUM> (e.g., by transmitting a scheduling request). In some aspects, the uplink grant may be requested using UCI included in the PUCCH payload. In this case, the indicator in the PUCCH payload may indicate that the PUCCH payload includes UCI, and the base station <NUM> may use the indicator to determine that the PUCCH payload includes the UCI. Based at least in part on this determination, the base station <NUM> may determine that the UCI includes a request for an uplink grant, and may transmit an uplink grant to the UE <NUM> in DCI on the PDCCH. The UE <NUM> may use the uplink grant to schedule and transmit the data on the PUSCH.

In some aspects, the UE <NUM> may not request an uplink grant for transmission of data on the PUSCH, such as when the UE <NUM> is scheduled for uplink transmissions using semi-persistent scheduling or configured scheduling, when the UE <NUM> is configured for uplink grant-free transmissions, and/or the like. In this case, the UE <NUM> may not transmit a corresponding PUCCH payload if the UE <NUM> determines that the UE <NUM> is to transmit the data in the PUSCH payload.

In this way, the base station <NUM> and the UE <NUM> may transmit and receive data in a PUCCH payload when the data is small, thereby taking advantage of efficiencies associated with transmitting small data on the PUCCH, including conserving network resources (e.g., by using only the PUCCH instead of both the PDCCH and the PUSCH), conserving resources (e.g., processing power, battery power, memory, and/or the like) of the base station <NUM> and the UE <NUM> (e.g., due to processing only the PUCCH payload instead of both PDCCH and PUSCH payloads), reducing latency for small data (e.g., that can be transmitted in a limited number of PUCCH payloads) improving reliability for small data using polar coding, and/or the like. Furthermore, the base station <NUM> and the UE <NUM> may transmit and receive data in a PUSCH payload when the data is large, thereby taking advantage of efficiencies associated with transmitting large data on the PUSCH, including improving performance for large data (e.g., when the data is too large to efficiently communicate on the PUCCH), reducing latency for large data (e.g., that would require a large number of PUCCH payloads that are separated in time), improving reliability for large data using LDPC coding, and/or the like.

<FIG> is a diagram illustrating an example process <NUM> performed, for example, by a UE, in accordance with various aspects of the present disclosure. Example process <NUM> is an example where a UE (e.g., UE <NUM> and/or the like) performs operations relating to transmitting data in a control channel.

As shown in <FIG>, in some aspects, process <NUM> may include receiving an indicator, in a physical downlink control channel (PDCCH) payload, that indicates whether the PDCCH payload includes data or downlink control information (DCI) for obtaining the data (block <NUM>). For example, the UE (e.g., using antenna <NUM>, DEMOD <NUM>, MIMO detector <NUM>, receive processor <NUM>, controller/processor <NUM>, and/or the like) may receive an indicator, in a PDCCH payload, that indicates whether the PDCCH payload includes data or DCI for obtaining the data, as described above in connection with <FIG>.

As further shown in <FIG>, in some aspects, process <NUM> may include obtaining at least one of the data or the DCI based at least in part on the indicator (block <NUM>). For example, the UE (e.g., using controller/processor <NUM> and/or the like) may obtain at least one of the data or the DCI based at least in part on the indicator, as described above in connection with <FIG>.

<FIG> is a diagram illustrating an example process <NUM> performed, for example, by a base station, in accordance with various aspects of the present disclosure. Example process <NUM> is an example where a base station (e.g., base station <NUM> and/or the like) performs operations relating to transmitting data in a control channel.

As shown in <FIG>, in some aspects, process <NUM> may include determining whether to transmit data in a physical downlink control channel (PDCCH) payload or a physical downlink shared channel (PDSCH) payload based at least in part on a size of the data (block <NUM>). For example, the base station (e.g., using controller/processor <NUM> and/or the like) may determine whether to transmit data in a PDCCH payload or a PDSCH payload based at least in part on a size of the data, as described above in connection with <FIG>.

As further shown in <FIG>, in some aspects, process <NUM> may include transmitting an indicator, in the PDCCH payload, that indicates whether the PDCCH payload includes the data or downlink control information (DCI) for obtaining the data from the PDSCH payload (block <NUM>). For example, the base station (e.g., using controller/processor <NUM>, transmit processor <NUM>, TX MIMO processor <NUM>, MOD <NUM>, antenna <NUM>, and/or the like) may transmit an indicator, in the PDCCH payload, that indicates whether the PDCCH payload includes the data or DCI for obtaining the data from the PDSCH payload, as described above in connection with <FIG>.

As further shown in <FIG>, in some aspects, process <NUM> may include selectively transmitting the data in the PDCCH payload or the PDSCH payload based at least in part on the size of the data (block <NUM>). For example, the base station (e.g., using controller/processor <NUM>, transmit processor <NUM>, TX MIMO processor <NUM>, MOD <NUM>, antenna <NUM>, and/or the like) may selectively transmit the data in the PDCCH payload or the PDSCH payload based at least in part on the size of the data, as described above in connection with <FIG>.

As shown in <FIG>, in some aspects, process <NUM> may include determining whether to transmit data in a physical uplink control channel (PUCCH) payload or a physical uplink shared channel (PUSCH) payload based at least in part on a size of the data (block <NUM>). For example, the UE (e.g., using controller/processor <NUM> and/or the like) may determine whether to transmit data in a PUCCH payload or a PUSCH payload based at least in part on a size of the data, as described above in connection with <FIG>.

As further shown in <FIG>, in some aspects, process <NUM> may include selectively transmitting the data in the PUCCH payload or the PUSCH payload based at least in part on the size of the data, wherein the PUCCH payload includes an indicator that indicates whether the PUCCH payload includes the data or uplink control information (UCI) (block <NUM>). For example, the UE (e.g., using controller/processor <NUM>, transmit processor <NUM>, TX MIMO processor <NUM>, MOD <NUM>, antenna <NUM>, and/or the like) may selectively transmit the data in the PUCCH payload or the PUSCH payload based at least in part on the size of the data, as described above in connection with <FIG>.

As shown in <FIG>, in some aspects, process <NUM> may include receiving an indicator, in a physical uplink control channel (PUCCH) payload, that indicates whether the PUCCH payload includes data or uplink control information (UCI) (block <NUM>). For example, the base station (e.g., using antenna <NUM>, DEMOD <NUM>, MIMO detector <NUM>, receive processor <NUM>, controller/processor <NUM>, and/or the like) may receive an indicator, in a PUCCH payload, that indicates whether the PUCCH payload includes data or UCI, as described above in connection with <FIG>.

As further shown in <FIG>, in some aspects, process <NUM> may include obtaining at least one of the data or the UCI based at least in part on the indicator (block <NUM>). For example, the base station (e.g., using controller/processor <NUM> and/or the like) may obtain at least one of the data or the UCI based at least in part on the indicator, as described above in connection with <FIG>.

Claim 1:
A method of wireless communication performed by a user equipment, UE (<NUM>),
comprising:
receiving an indicator, in a physical downlink control channel, PDCCH, payload, that indicates whether the PDCCH payload includes data or downlink control information, DCI, for obtaining the data, wherein the indicator is an initial state of a cyclic redundancy check that includes a predefined sequence of bits and further indicates whether the data is self-contained within the PDCCH payload or segmented across multiple PDCCH payloads; and
obtaining at least one of the data or the DCI based at least in part on the indicator.