Soft harq scheme, signaling method and reporting granularity in mobile communication

Abstract

Various examples are described with respect to soft hybrid automatic repeat request (HARQ) schemes, signaling methods, and reporting granularity in mobile communications. An apparatus, capable of implementation in a user equipment (UE), receives a transmission from a network node. In response to receiving the transmission, the apparatus generates a soft HARQ. The apparatus then transmits the soft HARQ to the network node. In generating the soft HARQ, the apparatus selects a measurement method, a metric, and a reporting granularity. Accordingly, the apparatus generates the soft HARQ using the selected measurement method, the selected metric, and the selected reporting granularity.

Description

[0001] Cross-referencing of related patent applications

[0002] This disclosure is a part of a non-provisional application claiming priority to U.S. Patent Application No. 63 / 125,422, filed December 15, 2020, the contents of which are incorporated herein by reference in their entirety. Technical Field

[0003] This disclosure relates generally to mobile communications, and more particularly to hybrid automatic repeat request (HARQ) schemes, signaling methods, and reporting granularity in mobile communications. Background Technology

[0004] Unless otherwise stated herein, the methods described in this section are not prior art to the claims listed below, and are not acknowledged as prior art by virtue of being included in this section.

[0005] In wireless communication (such as in 5G (5G)) th Generation (5G) New Radio (NR) 3rd Generation Partnership Program (3G) rd In mobile communications under the Generation Partnership Project (3GPP) specification, downlink (DL) HARQ typically refers to transmitting DL data on the physical downlink shared channel (PDSCH) and returning a HARQ acknowledgment on the physical uplink control channel (PUCCH) or physical uplink shared channel (PUSCH). When PDSCH decoding is successful, the user equipment (UE) reports an acknowledgment (ACK) to the base station (e.g., gNB); otherwise, the UE reports a negative acknowledgment (NACK).

[0006] Outer loop link adaptation (OLLA) can be implemented at the gNB to maintain the desired block error ratio (BLER). A typical operation of the gNB is to increase the backoff duration by a specific value upon NACK reception. This can lead to a reduced effective signal-to-interference-and-noise ratio (SINR) used for modulation coding scheme (MCS) selection, resulting in a lower MCS selection. The gNB can similarly operate to reduce the backoff duration upon ACK reception. The ratio of ACK and NACK adjustments can be varied depending on the desired BLER. OLLA works well for initial transmissions with a target BLER of 0.2 (e.g., for enhanced mobile broadband (eMBB)) and an error rate target of approximately 20%. However, in ultra-reliable low-latency communication (URLLC) with a low target BLER, there may not be enough NACK events for OLLA outer loop convergence. One way to utilize OLLA is to apply the outer loop to events before they cause block errors. This can be achieved by sending soft HARQs. Therefore, a solution for soft HARQ schemes, signaling methods, and reporting granularity is needed in mobile communications. Summary of the Invention

[0007] The following summary is merely illustrative and not intended to be limiting in any way. That is, it is provided to illustrate the concepts, highlights, benefits, and advantages of the novel and non-obvious techniques described herein. The selected implementations are further described in the detailed description below. Therefore, the following summary is not intended to identify the essential features of the claimed subject matter, nor is it intended to define the scope of the claimed subject matter.

[0008] The purpose of this disclosure is to provide solutions and schemes aimed at solving the problems described herein. More specifically, it is believed that the various schemes proposed in this disclosure provide solutions relating to soft HARQ schemes, signaling methods, and reporting granularity in mobile communications.

[0009] In one aspect, a method may include: receiving a transmission from a network node. The method may also include: generating a soft HARQ. The method may further include: sending the soft HARQ to the network node. Generating the soft HARQ may include: selecting a measurement method, a metric, and a reporting granularity. Additionally, the method may include: generating the soft HARQ using the selected measurement method, the selected metric, and the selected reporting granularity.

[0010] In another aspect, an apparatus may include a transceiver and a processor coupled to the transceiver. The transceiver may be configured for wireless communication. The processor may be configured to receive transmissions from a network node via the transceiver; generate a soft HARQ; and transmit the soft HARQ to the network node via the transceiver. In generating the soft HARQ, the processor may select a measurement method, a metric, and a reporting granularity. Therefore, the processor may use the selected measurement method, the selected metric, and the selected reporting granularity to generate the soft HARQ.

[0011] It is worth noting that although the descriptions provided herein may be within the context of certain radio access technologies, networks, and network topologies (such as 5G / NR mobile communications), the proposed concepts, schemes, and any variations / derivatives thereof can be implemented in, used in, and by other types of radio access technologies, networks, and network topologies, such as (e.g., but not limited to): Long-Term Evolution (LTE), LTE-Advanced, LTE-Advanced Pro, Internet of Things (IoT), Narrow Band Internet of Things (NB-IoT), Industrial Internet of Things (IIoT), Vehicle-to-Everything (V2X), and non-terrestrial network (NTN) communications. Therefore, the scope of this disclosure is not limited to the examples described herein. Attached Figure Description

[0012] The accompanying drawings are included to provide a further understanding of this disclosure, and are incorporated in and constitute a part of this disclosure. The drawings illustrate implementations of this disclosure and, together with the description, serve to explain the principles of this disclosure. It will be apparent that the drawings are not necessarily drawn to scale, as some components may be shown out of proportion to their actual dimensions in order to clearly illustrate the concepts of this disclosure.

[0013] Figure 1 This is a schematic diagram of an example network environment that can realize the various proposed schemes according to this disclosure.

[0014] Figure 2 This is a schematic diagram of an example design based on the scheme proposed in this disclosure.

[0015] Figure 3 This is a schematic diagram of an example design based on the scheme proposed in this disclosure.

[0016] Figure 4 This is a schematic diagram of an example design based on the scheme proposed in this disclosure.

[0017] Figure 5 This is a schematic diagram of an example design based on the scheme proposed in this disclosure.

[0018] Figure 6 This is a schematic diagram of an example design based on the scheme proposed in this disclosure.

[0019] Figure 7 This is a block diagram of an example communication system implemented according to this disclosure.

[0020] Figure 8 This is a flowchart illustrating an example of processing based on an implementation of this disclosure. Detailed Implementation

[0021] This document discloses detailed embodiments and implementations of the claimed subject matter. However, it should be understood that the disclosed embodiments and implementations are merely illustrative of the claimed subject matter, which can be implemented in various forms. This disclosure may be implemented in many different forms and should not be construed as limiting the exemplary embodiments and implementations set forth herein. Rather, these exemplary embodiments and implementations are provided to make the description of this disclosure thorough and complete, and to fully convey the scope of this disclosure to those skilled in the art. In the following description, details of known features and / or techniques may be omitted to avoid unnecessarily obscuring the presented embodiments and implementations.

[0022] Overview

[0023] Implementations of this disclosure relate to various techniques, methods, schemes, and / or solutions related to soft HARQ schemes, signaling methods, and reporting granularity in mobile communications. According to this disclosure, numerous possible solutions can be implemented individually or in combination. That is, although these possible solutions may be described individually below, two or more of these possible solutions may be implemented in one combination or another.

[0024] Figure 1A schematic diagram illustrating an example network environment 100 that can implement various solutions and schemes according to this disclosure is provided. (See also...) Figure 1 Network environment 100 may involve a UE 110 that wirelessly communicates with wireless network 120 (e.g., a 5G NR mobile network or another type of network such as NTN). UE 110 may wirelessly communicate with wireless network 120 via a base station or network node 125 (e.g., an eNB, gNB, or a transmit-receive point (TRP)). In network environment 100, UE 110 and wireless network 120 (via network node 125) may implement various schemes related to soft HARQ schemes, signaling methods, and reporting granularity in mobile communications, as described below.

[0025] Figure 2 An example design 200 is illustrated under the proposed scheme according to this disclosure. Under the various proposed schemes of this disclosure, processing involving multiple operations can be performed in generating and reporting soft HARQs. (Refer to...) Figure 2 You can select a measurement method, then a metric, and also a reporting granularity. Then, UE 110 can use the selected measurement method, the selected metric, and the selected reporting granularity to generate a soft HARQ and report the soft HARQ to network node 125.

[0026] The choice of measurement method can be based on the operating point. For example, it can be based on the bit error rate (BER) of the flipped log-likelihood ratio (LLR) or variance or SINR measurement results. Alternatively, it can be based on the difficulty of decoding the PDSCH according to, but not limited to, the number of iterations and hardware (HW) cycles (e.g., the time required for PDSCH decoding). The metric used for the generation method can be selected based on the redundancy version (RV) or the new data indicator (NDI). For example, the metric used to generate soft HARQ feedback / reports can be based on the estimated SINR or incremental SINR (in...). Figure 2 In the expression "dSINR", the estimated MCS or incremental MCS is represented as "dSINR". Figure 2 (represented as "dMCS"), estimated BLER or incremental BLER (in Figure 2 (represented as "dBLER"), estimated BER or incremental BER (in) Figure 2The cause of a NACK (represented as "dBER") can be used. Furthermore, this generation can utilize the packet MCS and a configured reference (e.g., per RV or NDI) or a previous (or another) packet (or transmission of the same packet) as a reference. The reporting granularity can be selected at per code block (CB), per code block group (CBG), or per transport block (TB).

[0027] It is worth noting that the various proposed schemes described below can be categorized based on the information source as: (a) soft HARQ based on the difficulty of whether PDSCH decoding was successful or unsuccessful, and (b) soft HARQ based on estimated SINR information. For difficulty-based soft HARQ, the report can be based on any one or two of the following: (i) incremental MCS, and (ii) estimated BLER or incremental BLER. For soft HARQ based on estimated SINR information, the report can be based on one or more of the following: (i) actual SINR reading and / or change, (ii) MCS value or change, and (iii) estimated BLER or incremental BLER.

[0028] Under the first proposed scheme according to this disclosure, UE 110 can report soft HARQ to network node 125 based on the difficulty of whether PDSCH decoding is successful or unsuccessful. Under the proposed scheme, UE 110 can determine the difficulty of decoding PDSCH based on the time required to complete the decoding process. For example, the time required to achieve a successful cyclic redundancy check (CRC) within the HW cycle can be used to determine the difficulty of PDSCH decoding. Alternatively, or additionally, UE 110 can determine the difficulty of decoding PDSCH based on one or more LLR values ​​and / or variance. Alternatively, or additionally, UE 110 can determine the difficulty of decoding PDSCH based on any change in the number of flipped bits before and after low-density parity-check (LDPC) decoding.

[0029] Under the second proposed scheme according to this disclosure, UE 110 can report soft HARQ to network node 125 based on incremental MCS. Different options can be applied or otherwise configured to determine the incremental MCS. In the first option (option 1), the incremental MCS can be defined as the difference between: (1) the estimated MCS value of the PDSCH based on a reference-specific or configured BLER (or BER), and (2) the MCS used for PDSCH transmission (which can be considered as the MCS reference). For example, to determine the incremental MCS, UE 110 can first determine the estimated MCS of the PDSCH and then compare the estimated MCS with the MCS used for PDSCH transmission. The incremental MCS can be defined or expressed as follows: Incremental MCS = MCS used for PDSCH transmission - Estimated MCS.

[0030] In the second option (Option 2), the incremental MCS can be defined as the difference between the estimated MCS values ​​of two PDSCHs for a given BLER (or BER). For example, to determine the incremental MCS, UE 110 can first determine the estimated MCS of the PDSCH and compare it with the estimated MCS of the previous PDSCH. The MCS offset can be defined or expressed as follows: MCS offset = Estimated MCS of the transmitted PDSCH - Estimated MCS of the previously transmitted PDSCH.

[0031] In the third option (Option 3), the incremental MCS can be defined based on the difference between the LLR quality value of the currently received PDSCH and the LLR quality value of the previously received PDSCH. Under the proposed scheme, UE 110 can determine the incremental MCS for a given specific BLER (or BER). Alternatively, UE 110 can determine the incremental MCS without a given BLER (or BER). For example, UE 110 can determine the LLR value / variance of a given PDSCH to compare with the LLR value / variance of a previously received PDSCH, and then map the difference in LLR quality values ​​to the incremental MCS.

[0032] Under the proposed scheme, UE 110 can determine the estimated MCS value based on the LLR value and / or variance. Alternatively, or additionally, UE 110 can determine the estimated MCS value based on the change in the number of flipped bits before and after LDPC decoding. Alternatively, or additionally, UE 110 can determine the estimated MCS value based on the SINR measurement of a specific BLER (or BER).

[0033] Under the third proposed scheme according to this disclosure, UE 110 can report soft HARQ to network node 125 based on incremental SINR. Different options can be applied or otherwise configured to determine incremental SINR. In the first option (Option 1), incremental SINR can be defined as the difference between the estimated SINR value of a given PDSCH and a specific SINR reference value for the same PDSCH. For example, to determine incremental SINR, UE 110 can first determine the estimated SINR of the PDSCH and then compare the estimated SINR with the SINR reference. Incremental SINR can be defined or expressed as follows: Incremental SINR = SINR reference - Estimated SINR.

[0034] In the second option (Option 2), the incremental SINR can be defined as the difference between estimated SINR values ​​between two PDSCHs. For example, UE 110 can determine the SINR increment between a DL transmission (e.g., a PDSCH) and a previously received PDSCH. In the third option (Option 3), the incremental SINR can be defined based on the difference between the LLR quality value of the currently received PDSCH and the LLR quality value of a previously received PDSCH. For example, UE 110 can determine the LLR value / variance of a given PDSCH to compare with the LLR value / variance of a previously received PDSCH, and then map the difference in LLR quality values ​​to the incremental SINR.

[0035] Under the proposed scheme, in options 1, 2, and 3, UE 110 can determine the incremental SINR for a given specific BLER (or BER). Alternatively, in options 1, 2, and 3, UE 110 can determine the incremental SINR without a given BLER (or BER). Alternatively, or additionally, UE 110 can determine the estimated SINR value based on the LLR value and / or variance. Alternatively, or additionally, UE 110 can determine the estimated SINR value based on the change in the number of flipped bits before and after LDPC decoding. Alternatively, or additionally, UE 110 can determine the estimated SINR value based on the SINR measurement result of a specific BLER (or BER). Alternatively, or additionally, UE 110 can determine or otherwise calculate (or configure) the SINR reference under the first or second method. In the first method, the SINR reference can be configured by network node 125 (e.g., using radio resource control (RRC) parameters, downlink control information (DCI), or other options). For example, network node 125 can indicate the SINR reference to UE 110 for use by UE 110 when calculating incremental SINR. In the second method, the SINR reference can be calculated by UE 110 based on other configuration parameters (such as a specific BLER target or an indicated MCS value). For example, UE 110 can determine the SINR reference value using a configured BLER target and a configured MCS value for a given PDSCH transmission.

[0036] Under the fourth proposed scheme according to this disclosure, UE 110 can report soft HARQ to network node 125 based on the incremental BLER index. Different options can be applied or otherwise configured to determine the incremental BLER index. In a first option (option 1), the incremental BLER index can be defined as the difference between an estimated BLER index and a configured or specific target BLER index. For example, to determine the incremental BLER index, UE 110 can estimate the BLER of the PDSCH and compare that BLER with a configured BLER target. In a second option (option 2), the incremental BLER index can be defined as the difference between the estimated BLER index of a DL transmission (e.g., PDSCH) and the estimated BLER index of a previous PDSCH. For example, to determine the incremental BLER index, UE 110 can estimate the BLER of the PDSCH and compare that BLER with the estimated BLER of a different (e.g., previously received) PDSCH. In the third option (Option 3), the incremental BLER index can be defined based on the difference between the LLR quality value of the received PDSCH and the LLR quality value of the previously received PDSCH. For example, UE 110 can first determine the LLR value and / or variance of the PDSCH, compare the LLR and / or variance with the LLR value and / or variance of the previously received PDSCH, and then UE 110 can map the difference in LLR quality values ​​to the incremental BLER.

[0037] Under the proposed scheme, in options 1, 2, and 3, UE 110 can determine the incremental BLER for a given specific BLER (or BER). Alternatively, in options 1, 2, and 3, UE 110 can determine the incremental BLER without a given BLER (or BER). Alternatively, or additionally, UE 110 can determine the estimated BLER value based on the SINR measurement of a specific BLER (or BER) and a given MCS value. Alternatively, or additionally, UE 110 can determine the estimated BLER value based on the change in the number of flipped bits before and after LDPC decoding. Alternatively, or additionally, UE 110 can determine the estimated BLER value based on the LLR value and / or LLR variance measurement. Alternatively, or additionally, UE 110 can determine the estimated BLER value based on the number of LDPC decoding iterations.

[0038] Under the fifth proposed scheme according to this disclosure, UE 110 can report soft HARQ to network node 125 based on an incremental BER index (or an exact BER index). Different options can be applied or otherwise configured to determine the incremental BER index. In a first option (option 1), the incremental BER index can be defined as the difference between an estimated BER index and a configured or specific target BER index. For example, to determine the incremental BER index, UE 110 can estimate the BER of the PDSCH and compare that BER with a configured BER target. In a second option (option 2), the incremental BER index can be defined as the difference between an estimated BER index of a DL transmission (e.g., PDSCH) and an estimated BER index of a previous PDSCH. For example, to determine the incremental BER index, UE 110 can estimate the BER of the PDSCH and compare that BER with estimated BERs of different (e.g., previously received) PDSCHs. In a third option (option 3), the incremental BER index can be defined based on the difference between the LLR quality value of the received PDSCH and the LLR quality value of a previously received PDSCH. For example, UE 110 can first determine the LLR value and / or variance of the PDSCH, and compare the LLR and / or variance with the LLR value and / or variance of the previously received PDSCH. Then, UE 110 can map the difference in LLR quality values ​​to the incremental BER. In the fourth option (option 4), the precise BER index can be estimated and reported to network node 125.

[0039] Under the proposed scheme, in options 2, 3, and 4, UE 110 can determine the incremental (or precise) BER for a given specific BLER (or BER). Alternatively, in options 2, 3, and 4, UE 110 can determine the incremental (or precise) BER without a given BLER (or BER). Alternatively, or additionally, UE 110 can determine the estimated BER value based on the SINR measurement of a specific BLER (or BER). Alternatively, or additionally, UE 110 can determine the estimated BER value based on the LLR value and / or LLR variance measurement. Alternatively, or additionally, UE 110 can determine the estimated BER value based on the number of LDPC decoding iterations. Alternatively, or additionally, the measured BER can be defined as the flip bits before and after LDPC decoding. Alternatively, or additionally, UE 110 can determine the estimated BER value based on the mean squared error (MSE) measured for the LLR value input to the decoder. Alternatively, the recovered coded bits can be used as a reference for calculating the error.

[0040] Under each of the schemes proposed in the first, second, third, fourth, and fifth embodiments above, a given specific BLER (or BER) (or BLER / BER target) can be configured via upper-layer parameters (e.g., RRC parameters). For example, a given specific BLER (or BER) (or BLER / BER target) can be configured per TB. Alternatively, or additionally, a given specific BLER (or BER) (or BLER / BER target) can be configured per CBG. Alternatively, or additionally, a given specific BLER (or BER) (or BLER / BER target) can be configured per codebook. Under each of the schemes proposed above, one or more different options can be used to indicate which previously received PDSCH can be considered as a reference. For example, network node 125 can use RRC parameters to indicate or otherwise select which of a plurality of previously received PDSCHs should be used as a reference. Alternatively, UE 110 can select the PDSCH to be used as a reference. For example, UE110 can select the most recently received PDSCH, or UE110 can select another previously received PDSCH that was received using the same configuration MCS as the PDSCH of interest.

[0041] Under the sixth proposed scheme of this disclosure, UE 110 can report soft HARQ to network node 125 based on an estimate of the exact (or incremental) BLER index, the exact (or incremental) BER index, the exact (or incremental) SINR level, the exact (or incremental) MCS index, or the exact (or incremental) LLR level or variance, at an estimated x-step. For example, for x=2 with a BLER index, the BLER index estimation granularity can be equal to 2, meaning that estimated BLERs of 0.1 and 0.01 can be reported in a single entry in the soft HARQ. As another example, for x=1 with a SINR level, the SINR estimation granularity can be equal to 1, meaning that individual SINR integer values ​​can be reported as a single entry in the soft HARQ.

[0042] Under the proposed scheme, the x-value can be configured or otherwise applied via upper-layer signaling (e.g., RRC parameters). Alternatively, or additionally, the x-value can be configured or otherwise applied based on the BLER target. Alternatively, or additionally, the x-value can be configured or otherwise applied based on the configured bandwidth part (BWP) size. Alternatively, or additionally, the x-value can be configured or otherwise applied based on the parameter set (numerology) (e.g., bandwidth subcarrier spacing). Alternatively, or additionally, the x-value can be configured or otherwise applied based on HARQ feedback such as ACK and / or NACK. Alternatively, or additionally, the x-value can be configured or otherwise applied based on the initial transmission and retransmission. Alternatively, or additionally, the x-value can be configured or otherwise applied based on the RV index. Alternatively, or additionally, the x-value can be configured or otherwise applied by the UE 110 based on UE calculations. Alternatively, or additionally, different options based on the number of bits can be considered.

[0043] Under the seventh proposed scheme according to this disclosure, additional soft information (e.g., incremental BLER index) can be mapped to a reporting table and reported as soft HARQ (with additional information) together with the existing HARQ scheme (e.g., with additional soft information in addition to the existing HARQ scheme). Under the proposed scheme, UE 110 can use additional bits to map estimated soft information (such as incremental BLER index) to a reporting table (based on different options). Then, in addition to the existing HARQ feedback scheme, UE 110 can also report the mapped information as soft HARQ feedback. Figure 3 Example design 300 is illustrated under the proposed scheme. Specifically, Figure 3 The table shown depicts the mapping from the incremental BLER exponent to a 2-bit table soft HARQ.

[0044] Under the proposed scheme, the entries in the mapping report table, which can be used to report additional information, can be defined, configured, or otherwise applied using different options. In the first option (Option 1), the selected report table can be defined in the 3GPP specification. For example, network node 125 can use upper-layer parameters such as RRC parameters to select which table to use for reporting from the 3GPP specification. Alternatively, UE 110 can select the table for reporting from the 3GPP specification. In the second option (Option 2), the entries in the report table can be configured by network node 125 or otherwise modified.

[0045] Under the proposed scheme, different options based on the number of bits can be considered. In the first option (Option 1), two bits can be used for soft HARQ, and thus four entries can be reported. For example, the entries for the incremental BLER exponent can be ≤0, =1, =2, and ≥3, such as... Figure 3 As shown. In the second option (Option 2), one bit can be used for the soft HARQ, and therefore two entries can be reported. In the third option (Option 3), three bits can be used for the soft HARQ, and therefore eight entries can be defined.

[0046] Under the proposed scheme, different reporting forms can be applied or used for different additional information. For example, the form used to report incremental BLER can be different from the form used to report incremental MCS. It is worth noting that the additional information reporting form can be used or otherwise applied to one or more schemes or different combinations of the first, second, third, fourth, and fifth schemes proposed above.

[0047] Under the scheme proposed in the eighth aspect of this disclosure, additional soft information can be merged with existing HARQ report feedback to generate a soft HARQ feedback scheme. That is, additional soft information with ACK and NACK can be mapped to a reporting table to represent the soft ACK and soft NACK levels, thus the new scheme can be a soft HARQ feedback scheme. Figure 4 Example design 400 is illustrated under the proposed scheme. Specifically, Figure 4 The table shown illustrates a mapping method using a 2-bit table with incremental BLER exponents and ACK / NACK information.

[0048] Under the proposed scheme, the soft HARQ defined in the first, second, third, fourth, and fifth proposed schemes above can be mapped to soft ACK and soft NACK. Alternatively, or additionally, the mapped soft ACK and soft NACK can be based on one or more of the proposed schemes above. For example, the soft ACK level can be based on the estimated increment BLER, the estimated increment SINR, or the estimated increment MCS.

[0049] Under the proposed scheme, different reporting options can be considered based on the number of bits or other parameters. In the first option (Option 1), two bits can be used for soft HARQ to define three soft ACK levels plus one hard NACK level. For example, the three ACK levels can be based on an incremental BLER exponent, which can be ≤0 for high soft ACK, =1 for medium soft ACK, and ≥2 for low soft ACK, and a fourth entry can be used for NACK. Alternatively, two bits can be used for soft HARQ to define two soft ACK levels plus two soft NACK levels. For example, there can be one entry for high ACK, one entry for low ACK, one entry for high NACK, and one entry for low ACK, such as... Figure 4 As shown. Alternatively, two soft ACK levels plus two soft NACK levels can be applied to the initial transmission, while three soft ACK levels plus one hard NACK level can be applied to the retransmission. In the second option (Option 2), three bits can be used for soft HARQ, thus defining eight entries.

[0050] Under the ninth scheme proposed according to this disclosure, in addition to the existing HARQ scheme, UE 110 can also report soft ACK and the reason for decoding failure to network node 125. That is, in addition to the existing HARQ scheme, UE 110 can also use additional bits to report additional information (which may include the soft ACK level and the reason for decoding failure in the case of NACK), wherein the information in these additional bits is a report table. Figure 5 Example design 500 is shown under the proposed scheme. For example, Figure 5 The table on the left depicts the mapping information with NACK using two bits (e.g., the reason for decoding failure). Furthermore, Figure 5 The table on the right depicts the mapping information with ACK using two bits (e.g., incremental BLER exponent). ACK and NACK information can be reported using existing HARQ feedback.

[0051] Under the proposed scheme, the entries in the reporting table used to report additional information are defined, configured, or otherwise applied using different options. In the first option (Option 1), the selected reporting table can be defined in the 3GPP specification. For example, network node 125 can use upper-layer parameters such as RRC parameters to select which table to use for reporting from the 3GPP specification. Alternatively, UE 110 can select the table for reporting from the 3GPP specification. In the second option (Option 2), the entries in the reporting table can be configured or modified by network node 125.

[0052] Under the proposed scheme, different options based on the number of bits can be considered. In the first option (Option 1), one bit can be used for both the soft ACK and the reason for decoding failure, and thus two entries can be reported for either the soft ACK or the decoding failure. In some cases, two entries can be used for soft HARQ, or two entries can be used for the reason for decoding failure. For example, one entry can be used for soft high ACK, one entry can be used for soft low ACK, one entry can be used for NACK with inter-cell interference as the reason for decoding failure, and one entry can be used for NACK with fading as the reason for decoding failure, such as... Figure 5 As shown. In the second option (Option 2), two bits can be used for soft HARQ, and therefore four entries can be reported for soft ACK or decoding failure. In the third option (Option 3), three bits can be used for soft HARQ, and therefore eight entries can be defined for soft ACK or decoding failure.

[0053] Under the proposed scheme, the soft ACK level can be based on different soft HARQ supplementary information. For example, the table used to report incremental BLER can be different from the table used to report incremental MCS. It is worth noting that the supplementary information reporting table can be used or otherwise applied to one or more schemes or different combinations thereof proposed in the first, second, third, fourth, and fifth schemes above.

[0054] Under the tenth proposed scheme according to this disclosure, information on soft ACK and the reason for decoding failure can be merged with existing HARQ report feedback. That is, additional soft information with ACK and NACK can be mapped to the report table to represent the soft ACK level and the NACK with the reason for decoding failure, so the new scheme can be a soft HARQ feedback scheme. Figure 6 Example design 600 is shown under the proposed scheme. Specifically, Figure 6 The table shown depicts the mapping of the incremental BLER exponent for the ACK case and the reason for decoding failure in the NACK case to a 2-bit soft HARQ table.

[0055] Under the proposed scheme, the entries in the reporting table used to report additional information are defined, configured, or otherwise applied using different options. In the first option (Option 1), the selected reporting table can be defined in the 3GPP specification. For example, network node 125 can use upper-layer parameters such as RRC parameters to select which table to use for reporting from the 3GPP specification. Alternatively, UE 110 can select the table for reporting from the 3GPP specification. In the second option (Option 2), the entries in the reporting table can be configured or modified by network node 125.

[0056] Under the proposed scheme, different options based on the number of bits can be considered. In the first option (Option 1), two bits can be used for soft ACK and the reason for decoding failure, and different options can be defined. Specifically, two soft ACK levels plus two NACK levels with reasons for decoding failure can be defined. (See reference...) Figure 6 The table shown allows for two soft ACK levels based on the incremental BLER exponent, while the NACK level can be based on inter-cell interference, fading, or beamblocking. In the second option (Option 2), three bits can be used for the reason for soft ACK and decoding failure, thus defining eight entries.

[0057] Under the proposed scheme, the soft ACK level can be based on different soft HARQ supplementary information. For example, the table used to report incremental BLER can be different from the table used to report incremental MCS. It is worth noting that the supplementary information reporting table can be used or otherwise applied to one or more schemes or different combinations thereof proposed in the first, second, third, fourth, and fifth schemes above.

[0058] Regarding the schemes proposed in the sixth, seventh, eighth, ninth, and tenth schemes above, the selection of one or more reporting forms under the sixth, seventh, eighth, ninth, and tenth schemes can be configured or otherwise applied based on RRC parameters. Alternatively, or additionally, the selection of one or more reporting forms under the sixth, seventh, eighth, ninth, and tenth schemes can be configured or otherwise applied based on BLER targets. Alternatively, or additionally, the selection of one or more reporting forms under the sixth, seventh, eighth, ninth, and tenth schemes can be configured or otherwise applied based on the configured BWP size. Alternatively, or additionally, the selection of one or more reporting forms under the sixth, seventh, eighth, ninth, and tenth schemes can be configured or otherwise applied based on a parameter set (e.g., bandwidth subcarrier spacing). Alternatively, or additionally, the selection of one or more reporting forms under the schemes proposed in the sixth, seventh, eighth, ninth, and tenth schemes can be configured or otherwise applied based on HARQ feedback such as ACK and / or NACK. Alternatively, or additionally, the selection of one or more reporting forms under the schemes proposed in the sixth, seventh, eighth, ninth, and tenth schemes can be configured or otherwise applied based on the initial transmission and its corresponding retransmission. Alternatively, or additionally, the selection of one or more reporting forms under the schemes proposed in the sixth, seventh, eighth, ninth, and tenth schemes can be configured or otherwise applied based on the RV index.

[0059] Under the scheme proposed according to the eleventh provision of this disclosure, soft HARQ feedback can be applied, reported, or otherwise configured differently for the initial transmission and its corresponding retransmission. Under the proposed scheme, UE 110 can use the same reporting mechanism for initial transmission and retransmission to report soft HARQ, such as reporting soft ACK information. However, the parameters and / or metrics defining the soft ACK for initial transmission and retransmission can be different. For example, UE 110 can be configured to use different BLER targets in the process of finding the soft ACK for initial transmission and retransmission. As another example, different numbers of LDPC decoding iterations can be considered to define high ACK for initial transmission and retransmission. More specifically, for the initial transmission case, when the number of LDPC decoding iterations is ≤8, UE 110 can report the ACK as high ACK, while for the retransmission case, when the number of LDPC decoding iterations is ≤3, the same high ACK can be reported.

[0060] Under the proposed scheme, UE 110 can report to network node 125 different mechanisms or options for finding or estimating and reporting soft HARQs for initial transmissions and retransmissions. For example, UE 110 can use soft HARQs for initial transmissions and existing HARQs for retransmissions. As another example, the soft HARQ for initial transmissions can be based on estimated BLER, while the soft HARQ for retransmissions can be based on incremental MCS. Alternatively, or additionally, UE 110 can use different mechanisms or options based on the RV index for reporting.

[0061] It is worth noting that when UE 110 reports soft HARQ-ACK to network node 125, there are different options for the reporting granularity of soft HARQ (e.g., soft ACK / NACK), such as reporting per CB, per CBG, or per TB. Under the scheme proposed in the twelfth aspect of this disclosure, UE 110 can determine and report a single soft HARQ feedback report to network node 125 per CB. For example, UE 110 can use the LLR value / variance or SINR value per CB, the number of LDPC iterations, the estimated BLER, the MCS / channel quality indicator (CQI) value or difference, or the BER to determine and report the soft HARQ per CB.

[0062] Under the scheme proposed according to the thirteenth of this disclosure, UE 110 can determine and report a single soft HARQ feedback report per CBG to network node 125. In a first option (option 1), using LLR value / variance or SINR value, estimated BLER, MCS / CQI value or MCS / CQI difference, or BER, UE 110 can determine the soft HARQ for each CB in the CBG. For example, UE 110 can determine and report the soft HARQ for the average CB per CBG (option 1a). Alternatively, UE 110 can determine and report the best or highest soft HARQ for each CBG (option 1b). Alternatively, UE 110 can determine and report the worst or lowest soft HARQ for each CBG (option 1c). In a second option (option 2), using the number of LDPC iterations per CB, UE 110 can determine the soft HARQ for each CB in the CBG. For example, UE 110 can determine and report the soft HARQ for a common CB per CBG (Option 2a). Alternatively, UE 110 can determine and report the best or highest soft HARQ for a CB per CBG (Option 2b). Alternatively, UE 110 can determine and report the worst or lowest soft HARQ for a CB per CBG (Option 2c). In a third option (Option 3), UE 110 can report different combinations of options to network node 125 for initial transmission and retransmission cases. For example, UE 110 can report using options 1a and 2a for initial transmission and options 1c and 2c for retransmission. Alternatively, UE 110 can report using different combinations of options for NACK and ACK cases. For example, UE 110 can report using options 1a, 1c, 2a, and 2c for ACK and options 1b and 2b for NACK per CBG. In the fourth option (Option 4), UE 110 may report two quantities for a given option in the thirteenth proposed scheme (e.g., lowest soft HARQ and highest soft HARQ, or average soft HARQ and lowest soft HARQ, or average soft HARQ and highest soft HARQ). In the fifth option (Option 5), UE 110 may determine a soft HARQ based on a CB with ACK and another soft HARQ based on a CB with NACK (Option 5a). For example, a CB with ACK may be excluded (Option 5b). Alternatively, a CB with NACK may be excluded. Alternatively, any one or both of Options 5a and 5b may be applied, configured, or otherwise selected based on the reporting configuration.

[0063] Under the scheme proposed according to the fourteenth of this disclosure, UE 110 can determine and report a single soft HARQ feedback report to network node 125 per TB. In the first option (Option 1), using the LLR variance and / or value or SINR value, LDPC iteration count, estimated BLER, MCS / CQI value or difference, or BER, UE 110 can determine the soft HARQ per TB. For example, UE 110 can determine and report the average soft HARQ per TB (Option 1a). Alternatively, for the case of using the LDPC iteration count, UE 110 can determine and report the common soft HARQ per TB (Option 1b). Alternatively, UE 110 can determine and report the best or highest soft HARQ of CB per TB (Option 1c). Alternatively, UE 110 can determine and report the worst or lowest soft HARQ of CB per TB (Option 1d). Alternatively, UE 110 can utilize one of the above options for NACK and different options for ACK for reporting (Option 1e). For example, UE 110 can report using ACK options 1a, 1b, or 1c and NACK option 1d. Alternatively, UE 110 can report using one of the above options for initial transmission and different retransmission options (option 1f). For example, UE 110 can report using initial transmission options 1a, 1b, or 1c and retransmission option 1d.

[0064] In the second option (Option 2), using the LLR variance and / or value or SINR value, the number of LDPC iterations, the estimated BLER, or BER, UE 110 can determine the soft HARQ per CBG as described in Options 1a, 1b, 1c, 1d, 1e, and 1f above. For example, UE 110 can determine and report the highest or best soft HARQ report per TB from the best soft HARQ CBG values ​​(Option 2a). Alternatively, UE 110 can determine and report the highest or best soft HARQ report per TB from the worst soft HARQ CBG values ​​(Option 2b). Alternatively, UE 110 can determine and report the highest or best soft HARQ report per TB from the average / common soft HARQ CBG values ​​(Option 2c). Alternatively, UE 110 can determine and report the worst or lowest soft HARQ report per TB from the best soft HARQ CBG values ​​(Option 2d). Alternatively, UE 110 can determine and report the worst or lowest soft HARQ report per TB from the worst soft HARQ CBG value (Option 2e). Alternatively, UE 110 can determine and report the worst or lowest soft HARQ report per TB from the average / common soft HARQ CBG value (Option 2f). Alternatively, UE 110 can determine and report the average / common soft HARQ report per TB from the best soft HARQ CBG value (Option 2g). Alternatively, UE 110 can determine and report the average / common soft HARQ report per TB from the worst soft HARQ CBG value (Option 2h). Alternatively, UE 110 can determine and report the average / common soft HARQ report per TB from the average / common soft HARQ CBG value (Option 2i).

[0065] In the third option (Option 3), UE 110 can report using different combinations of options for NACK and ACK cases. For example, UE 110 can report using option 2a or 2c for ACK per TB and option 2b for NACK. In the fourth option (Option 4), UE 110 can report using different combinations of options for initial transmission or retransmission cases. For example, UE 110 can report using option 2a or 2c for initial transmission and option 2b for retransmission. In the fifth option (Option 5), under this proposed scheme, UE 110 can report two quantities for a given option (e.g., lowest soft HARQ and highest soft HARQ, average soft HARQ and lowest soft HARQ, or average soft HARQ and highest soft HARQ). In the sixth option (Option 6), UE 110 can determine a soft HARQ based on a CBG with ACK and another soft HARQ based on a CBG with NACK. For example, a CBG with ACK can be excluded (Option 6a). Alternatively, CBGs with NACK can be excluded (Option 6b). Alternatively, one or both of Options 6a and 6b can be applied, configured, or otherwise selected based on the report configuration.

[0066] It is worth noting that in all the proposed schemes described above, the BLER (or BER) target can be configured based on upper-level parameters (e.g., RRC parameters). For example, the BLER (or BER) target can be configured or otherwise defined per TB. Alternatively, or additionally, the BLER (or BER) target can be configured or otherwise defined per CBG. Alternatively, or additionally, the BLER (or BER) target can be configured or otherwise defined per codebook.

[0067] Instantiatory implementation

[0068] Figure 7 An example communication system 700, having at least example apparatus 710 and example apparatus 720, is illustrated according to an implementation of this disclosure. Each apparatus in apparatus 710 and 720 can perform various functions to implement the schemes, techniques, processes, and methods described herein relating to soft HARQ schemes, signaling methods, and reporting granularity in mobile communications, including the various schemes described above with reference to the proposed designs, concepts, schemes, systems, and methods, including network environment 100, and the processes described below.

[0069] The various devices in devices 710 and 720 can be part of an electronic device, which can be a network device or UE (e.g., UE 110), such as a portable or mobile device, a wearable device, an in-vehicle device or vehicle, a wireless communication device, or a computing device. For example, the various devices in devices 710 and 720 can be implemented in a smartphone, smartwatch, personal digital assistant, electronic control unit (ECU) in a vehicle, digital camera, or a computing device such as a tablet computer, laptop computer, or notebook computer. The various devices in devices 710 and 720 can also be part of a machine-type device, which can be an IoT device such as a stationary or fixed device, a home appliance, a roadside unit (RSU), a wired communication device, or a computing device. For example, the various devices in devices 710 and 720 can be implemented in a smart thermostat, a smart refrigerator, a smart door lock, a wireless speaker, or a home control center. When implemented in or implemented as a network device, device 710 and / or device 720 may be implemented in an eNodeB in an LTE, LTE-Advanced, or LTE-Advanced Pro network, or in a gNB or TRP in a 5G, NR, or IoT network.

[0070] In some implementations, the various devices in apparatus 710 and apparatus 720 can be implemented as one or more integrated circuit (IC) chips, for example, but not limited to, one or more single-core processors, one or more multi-core processors, one or more complex instruction-set computing (CISC) processors, or one or more reduced instruction-set computing (RISC) processors. In the various embodiments described above, the various devices in apparatus 710 and apparatus 720 can be implemented in or be implemented as a network device or UE. For example, the various devices in apparatus 710 and apparatus 720 can each include... Figure 7 At least some of the components shown, such as processor 712 and processor 722. The various devices in apparatus 710 and apparatus 720 may also include one or more other components (e.g., internal power supply, display device, and / or user interface device) unrelated to the proposed solutions of this disclosure, and therefore, for simplicity and brevity, such components of apparatus 710 and apparatus 720 are not... Figure 7 It is shown in the text, but not described below.

[0071] In one aspect, the respective processors in processors 712 and 722 may be implemented as one or more single-core processors, one or more multi-core processors, or one or more CISC or RISC processors. That is, even though the singular term "processor" is used herein to refer to processors 712 and 722, the respective processors in processors 712 and 722 according to this disclosure may include multiple processors in some implementations and a single processor in other implementations. In another aspect, the respective processors in processors 712 and 722 may be implemented as hardware (and optionally firmware) having electronic components, including, for example and not limited to, one or more transistors, one or more diodes, one or more capacitors, one or more registers, one or more inductors, one or more memristors, and / or one or more variable capacitors, configured and set to achieve a particular purpose according to this disclosure. In other words, in at least some implementations, the processors in processors 712 and 722 are dedicated machines specifically designed, set up, and configured to perform specific tasks, including those related to soft HARQ schemes, signaling methods, and reporting granularity in mobile communications according to various implementations of this disclosure.

[0072] In some implementations, device 710 may further include a transceiver 716 coupled to processor 712. Transceiver 716 is capable of wirelessly transmitting and receiving data. In some implementations, transceiver 716 is capable of wirelessly communicating with different types of wireless networks using different Radio Access Technologies (RATs). In some implementations, transceiver 716 may be equipped with multiple antenna ports (not shown), for example, four antenna ports. That is, transceiver 716 may be equipped with multiple transmit antennas and multiple receive antennas for multiple-input multiple-output (MIMO) wireless communication. In some implementations, device 720 may further include a transceiver 726 coupled to processor 722. Transceiver 726 may include a transceiver capable of wirelessly transmitting and receiving data. In some implementations, transceiver 726 is capable of wirelessly communicating with different types of UE / wireless networks using different RATs. In some implementations, transceiver 726 may be equipped with multiple antenna ports (not shown), for example, four antenna ports. That is, the transceiver 726 can be equipped with multiple transmit antennas and multiple receive antennas for MIMO wireless communication.

[0073] In some implementations, device 710 may further include a memory 714 coupled to and accessible by processor 712 and storing data therein. In some implementations, device 720 may further include a memory 724 coupled to and accessible by processor 722 and storing data therein. The various memories in memory 714 and memory 724 may include random-access memory (RAM) types, such as dynamic RAM (DRAM), static RAM (SRAM), thyristor RAM (T-RAM), and / or zero-capacitor RAM (Z-RAM). Alternatively, or additionally, the various memories in memory 714 and memory 724 may include read-only memory (ROM) types, such as mask ROM, programmable ROM (PROM), erasable programmable ROM (EPROM), and / or electrically erasable programmable ROM (EEPROM). Alternatively, or additionally, the individual memories in memories 714 and 724 may include non-volatile random-access memory (NVRAM) classes, such as flash memory, solid-state memory, ferroelectric RAM (FeRAM), magnetoresistive RAM (MRAM), and / or phase-change memory.

[0074] The various devices in apparatus 710 and apparatus 720 may be communication entities capable of communicating with each other using various proposed schemes according to this disclosure. For illustrative purposes and not for limitation, a description of the capabilities of apparatus 710 as a UE (e.g., UE 110) and apparatus 720 as a network node (e.g., network node 125) of a wireless network (e.g., network 120 as a 5G / NR mobile network) is provided below.

[0075] Under the various proposed schemes related to soft HARQ in mobile communications according to this disclosure, signaling methods, and reporting granularity, the processor 712 of device 710 (implemented as UE 110 or as UE 110) can receive transmissions (e.g., PDSCH transmissions) from network nodes of a wireless network (e.g., device 720 as network node 125 of wireless network 120) via transceiver 716. Additionally, the processor 712 can generate soft HARQs. Furthermore, the processor 712 can send soft HARQs to network nodes via transceiver 716.

[0076] In generating a soft HARQ, the processor 712 can perform certain operations. For example, the processor 712 can select a measurement method, a metric, and a reporting granularity. Furthermore, the processor 712 can use the selected measurement method, the selected metric, and the selected reporting granularity to generate a soft HARQ.

[0077] In some implementations, the processor 712 may report a soft HARQ based on the difficulty of decoding the PDSCH transmission when sending a soft HARQ to a network node.

[0078] In some implementations, when sending soft HARQs to network nodes, the processor 712 can report soft HARQs based on the incremental MCS, which is the difference between the MCS used for PDSCH transmission and the estimated MCS.

[0079] In some implementations, when sending soft HARQs to network nodes, the processor 712 can report soft HARQs based on incremental SINR, which is the difference between the reference SINR and the estimated SINR.

[0080] In some implementations, when sending soft HARQs to network nodes, the processor 712 may report soft HARQs based on an incremental BLER index, which is the difference between an estimated BLER index and a configured or specific target BLER index.

[0081] In some implementations, when sending soft HARQs to network nodes, the processor 712 can report soft HARQs based on an incremental BER index, which is the difference between an estimated BER index and a configured or specific target BER index.

[0082] In some implementations, when sending soft HARQs to network nodes, processor 712 may report the soft HARQ based on an estimated x-order of the exact or incremental BLER index, the exact or incremental BER index, the exact or incremental SINR, or the exact or incremental MCS index. Here, the incremental BLER index is the difference between the estimated BLER index and the configured or specific target BLER index; the incremental BER index is the difference between the estimated BER index and the configured or specific target BER index; the incremental SINR is the difference between the reference SINR and the estimated SINR; and the incremental MCS index is the difference between the estimated MCS value of the PDSCH based on the referenced, specific, or configured BLER or BER and the MCS used for PDSCH transmission.

[0083] In some implementations, a soft HARQ may include additional soft information for multiple incremental BLER indices, each of which is the difference between a corresponding estimated BLER index and a configured or specific target BLER index. Furthermore, these multiple incremental BLER indices may be mapped to a reporting table included in the soft HARQ.

[0084] In some implementations, soft HARQ may include additional soft information that is merged with existing HARQ report feedback.

[0085] In some implementations, in addition to existing HARQ schemes, the processor 712 can also report soft ACKs and the reasons for decoding failures when sending soft HARQs to network nodes.

[0086] In some implementations, when sending soft HARQs to network nodes, the processor 712 can report soft ACKs merged with existing HARQ report feedback and the reasons for decoding failures.

[0087] In some implementations, soft HARQ can be applied, reported, or configured differently depending on whether the received transmission is an initial transmission or a retransmission.

[0088] In some implementations, the processor 712 may report a single soft HARQ feedback report per CB in sending soft HARQs to network nodes. Alternatively, the processor 712 may report a single soft HARQ feedback report per CBG in sending soft HARQs to network nodes. Furthermore, the processor 712 may report a single soft HARQ feedback report per TB in sending soft HARQs to network nodes.

[0089] In some implementations, the processor 712 may select a measurement method based on: (a) the BER of the measurement result based on the inverted LLR value or variance or SINR; or (b) the difficulty in decoding the received transmission.

[0090] In some implementations, the processor 712 may select a metric based on the following: (a) incremental SINR, which is the difference between a reference SINR and an estimated SINR; (b) incremental BLER index, which is the difference between an estimated BLER index and a configured or specific target BLER index; (c) incremental BER index, which is the difference between an estimated BER index and a configured or specific target BER index; or (d) incremental MCS index, which is the difference between an estimated MCS value of the received transmission based on a reference, specific, or configured BLER or BER and the MCS used for the received transmission.

[0091] In some implementations, the processor 712 can select a reporting granularity of per CB, per CBG, or per TB.

[0092] Indicative process

[0093] Figure 8 An example process 800 according to an implementation of this disclosure is illustrated. Process 800 may represent aspects of implementing the various proposed designs, concepts, schemes, systems, and methods described above (whether partially or completely, including those related to those described above). More specifically, process 800 may represent aspects of proposed concepts and schemes related to soft HARQ schemes, signaling methods, and reporting granularity in mobile communications. Process 800 may include one or more operations, actions, or functions as illustrated by one or more of blocks 810, 820, and 830 and sub-blocks 822 and 824. Although illustrated as discrete blocks, the individual blocks of process 800 may be divided into additional blocks, combined into fewer blocks, or eliminated as desired. Furthermore, the blocks / sub-blocks of process 800 may be... Figure 8 The process can be executed in the indicated order, or alternatively in a different order. Furthermore, one or more blocks / sub-blocks of process 800 can be executed iteratively. Process 800 can be implemented by or within devices 710 and 720 and any variations thereof. For illustrative purposes only and without limiting the scope, process 800 is described below in the context of device 710 as a UE (e.g., UE 110) and device 720 as a communication entity (such as a network node or base station of a wireless network (e.g., wireless network 120)). Process 800 may begin at block 810.

[0094] At 810, process 800 may include: the processor 712 of device 710 receiving a transmission (e.g., a PDSCH transmission) from a network node of a wireless network (e.g., device 720 as network node 125 of wireless network 120) via transceiver 716. Process 800 proceeds from 810 to 820.

[0095] At 820, process 800 may include: processor 712 generating a soft HARQ. Process 800 proceeds from 820 to 830.

[0096] In 830, process 800 may include: processor 712 sending soft HARQ to network nodes via transceiver 716.

[0097] In generating a soft HARQ, process 800 may include: processing 712 performing certain operations represented by subframes 822 and 824.

[0098] In 822, process 800 may include: processor 712 selecting a measurement method, a metric, and a reporting granularity. Process 800 proceeds from 822 to 824.

[0099] In 824, process 800 may include: processor 712 generating a soft HARQ using a selected measurement method, a selected metric, and a selected reporting granularity.

[0100] In some implementations, in sending soft HARQs to network nodes, process 800 may include processor 712 reporting soft HARQs based on the difficulty of decoding PDSCH transmissions.

[0101] In some implementations, in sending soft HARQs to network nodes, process 800 may include: processor 712 reporting soft HARQs based on an incremental MCS, which is the difference between the MCS used for PDSCH transmission and the estimated MCS.

[0102] In some implementations, in sending soft HARQs to network nodes, process 800 may include: processor 712 reporting soft HARQs based on incremental SINR, which is the difference between a reference SINR and an estimated SINR.

[0103] In some implementations, in sending soft HARQs to network nodes, process 800 may include: processor 712 reporting soft HARQs based on an incremental BLER index, which is the difference between an estimated BLER index and a configured or specific target BLER index.

[0104] In some implementations, in sending soft HARQs to network nodes, process 800 may include: processor 712 reporting soft HARQs based on an incremental BER index, which is the difference between an estimated BER index and a configured or specific target BER index.

[0105] In some implementations, in sending soft HARQs to network nodes, process 800 may include: processor 712 reporting the soft HARQ based on an estimated x-order of an exact or incremental BLER index, an exact or incremental BER index, an exact or incremental SINR, or an exact or incremental MCS index. Here, the incremental BLER index is the difference between the estimated BLER index and a configured or specific target BLER index; the incremental BER index is the difference between the estimated BER index and a configured or specific target BER index; the incremental SINR is the difference between a reference SINR and an estimated SINR; and the incremental MCS index is the difference between an estimated MCS value of the PDSCH based on a reference, specific, or configured BLER or BER and the MCS used for the PDSCH transmission.

[0106] In some implementations, a soft HARQ may include additional soft information for multiple incremental BLER indices, each of which is the difference between a corresponding estimated BLER index and a configured or specific target BLER index. Furthermore, these multiple incremental BLER indices may be mapped to a reporting table included in the soft HARQ.

[0107] In some implementations, soft HARQ may include additional soft information that is merged with existing HARQ report feedback.

[0108] In some implementations, in sending soft HARQs to network nodes, process 800 may include, in addition to the existing HARQ scheme, processor 712 reporting soft ACKs and the reasons for decoding failures.

[0109] In some implementations, in sending a soft HARQ to a network node, process 800 may include: processor 712 reporting a soft ACK that is merged with existing HARQ report feedback and the reason for decoding failure.

[0110] In some implementations, soft HARQ can be applied, reported, or configured differently depending on whether the received transmission is an initial transmission or a retransmission.

[0111] In some implementations, in sending a soft HARQ to a network node, process 800 may include: processor 712 reporting a single soft HARQ feedback report per CB. Alternatively, in sending a soft HARQ to a network node, process 800 may include: processor 712 reporting a single soft HARQ feedback report per CBG. In sending a soft HARQ to a network node, process 800 may include: processor 712 reporting a single soft HARQ feedback report per TB.

[0112] In some implementations, in selecting the measurement method, process 800 may include: processor 712 selecting the measurement method based on: (a) the BER of the inverted LLR value or variance or SINR measurement result; or (b) the difficulty in decoding the received transmission.

[0113] In some implementations, in selecting the metric, process 800 may include: processor 712 selecting the metric based on: (a) incremental SINR, which is the difference between a reference SINR and an estimated SINR; (b) incremental BLER index, which is the difference between an estimated BLER index and a configured or specific target BLER index; (c) incremental BER index, which is the difference between an estimated BER index and a configured or specific target BER index; or (d) incremental MCS index, which is the difference between an estimated MCS value of the received transmission based on a reference, specific, or configured BLER or BER and the MCS used for the received transmission.

[0114] In some implementations, in terms of selecting the reporting granularity, process 800 may include: processor 712 selecting the reporting granularity per CB, per CBG, or per TB.

[0115] Additional Notes

[0116] The topics described herein sometimes illustrate different components contained within or connected to other components. It should be understood that the architectures depicted are merely exemplary, and in reality, many other architectures can be implemented to achieve the same functionality. Conceptually, any arrangement of components used to achieve the same functionality is effectively “associated” to achieve the desired functionality. Thus, any two components combined here to achieve a specific function can be considered “associated” with each other to achieve the desired functionality, regardless of the architecture or intermediate components. Similarly, any two such associated components can also be considered “operably connected” or “operably coupled” to each other to achieve the desired functionality, and any two components that can be suchly associated can also be considered “operably coupled” to each other to achieve the desired functionality. Specific examples of being operablely coupled include, but are not limited to, components that can physically cooperate and / or physically interact and / or components that can wirelessly interact and / or components that logically interact and / or components that can logically interact.

[0117] Furthermore, for any plural and / or singular terms used in this context, those skilled in the art can translate them from plural to singular and / or from singular to plural as appropriate, depending on the context and / or application. For clarity, various singular / plural substitutions can be explicitly described herein.

[0118] Furthermore, those skilled in the art will understand that, generally, the terms used herein, and especially those used in the appended claims (e.g., the body of the appended claims), are generally intended to be “open-ended” terms (e.g., the term “comprising” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “having at least,” the term “including” should be interpreted as “including but not limited to,” etc.). Those skilled in the art will also understand that if there is an intent to state a particular number of referenced claims, such intent will be explicitly stated in those claims, and without such statements, such intent does not exist. For example, to aid understanding, the appended claims may contain the use of introductory phrases “at least one” and “one or more” to introduce the claim statements. However, the use of such phrases should not be construed as implying that a claim statement introduced by the indefinite article "a" or "an" will limit any particular claim containing such an introductory claim statement to containing only one implementation of such a statement, even if the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an" (e.g., "a" or "an" should be interpreted as meaning "at least one" or "one or more"); the same applies to the use of definite articles for referencing claim statements. Furthermore, even if a specific number of referred claim statements are explicitly stated, those skilled in the art should recognize that such a statement should be interpreted as meaning at least the number stated (e.g., a bare statement of "two statements" means at least two statements, or two or more statements, in the absence of other modifiers). Furthermore, in instances where the convention of “at least one of A, B, and C” is used, this syntactic structure is generally intended to be understood by a person skilled in the art to mean the convention (e.g., “a system having at least one of A, B, and C” should include, but is not limited to, systems having a single A, a single B, a single C, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). In instances where the convention of “at least one of A, B, or C” is used, this syntactic structure is generally intended to be understood by a person skilled in the art to mean the convention (e.g., “a system having at least one of A, B, or C” should include, but is not limited to, systems having a single A, a single B, a single C, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). It should also be understood by a person skilled in the art that, in practice, any transition words and / or phrases presenting two or more alternative terms (whether in the specification, claims, or drawings) should be understood to contemplate the possibility of including one, any, or both of these terms. For example, the phrase “A or B” should be understood as including the possibility of “A” or “B” or “A and B”.

[0119] Based on the foregoing, it should be clear that the various implementations of this disclosure have been described for illustrative purposes, and various modifications may be made without departing from the scope and spirit of this disclosure. Therefore, the various implementations disclosed herein are not intended to be limiting, and the true scope and spirit are indicated by the following claims.

Claims

1. A method for reporting soft HARQ, the method comprising: Receive transmissions from network nodes; Generate a soft blend automatic repeat request (HARQ); as well as Send the soft HARQ to the network node. Generating the soft HARQ includes: Select measurement methods, metrics, and reporting granularity; and The soft HARQ is generated using a selected measurement method, a selected metric, and a selected reporting granularity, wherein the transmission includes a Physical Downlink Shared Channel (PDSCH) transmission, and wherein sending the soft HARQ to the network node includes reporting the soft HARQ based on the difficulty in decoding the PDSCH transmission.

2. The method according to claim 1, wherein, The transmission includes Physical Downlink Shared Channel (PDSCH) transmission, and wherein sending the soft HARQ to the network node includes reporting the soft HARQ based on an incremental modulation and coding scheme (MCS), wherein the incremental MCS is the difference between the MCS used for the PDSCH transmission and the estimated MCS.

3. The method according to claim 1, wherein, Sending the soft HARQ to the network node includes reporting the soft HARQ based on the incremental signal-to-interference and noise ratio (SINR), where the incremental SINR is the difference between a reference SINR and an estimated SINR.

4. The method according to claim 1, wherein, Sending the soft HARQ to the network node includes reporting the soft HARQ based on an incremental block error rate (BLER) index, wherein the incremental BLER index is an estimated difference between a BLER index and a configured or specific target BLER index.

5. The method according to claim 1, wherein, Sending the soft HARQ to the network node includes reporting the soft HARQ based on an incremental bit error rate (BER) index, wherein the incremental BER index is the difference between an estimated BER index and a configured or specific target BER index.

6. The method according to claim 1, wherein, The transmission includes Physical Downlink Shared Channel (PDSCH) transmission, wherein sending the soft HARQ to the network node includes: reporting the soft HARQ based on an estimated x-order of an exact or incremental block error rate (BLER) exponent, an exact or incremental bit error rate (BER) exponent, an exact or incremental signal-to-interference and noise ratio (SINR), or an exact or incremental modulation and coding scheme (MCS) index, and wherein: The incremental BLER index is the estimated difference between the BLER index and the configured or specific target BLER index. The incremental BER index is the difference between the estimated BER index and the configured or specific target BER index. The incremental SINR is the difference between the reference SINR and the estimated SINR, and The incremental MCS index is the difference between the estimated MCS value of the PDSCH based on a reference, specific, or configured BLER or BER and the MCS used for the PDSCH transmission.

7. The method according to claim 1, wherein, The soft HARQ includes additional soft information for a plurality of incremental block error rate (BLER) indices, each of the plurality of incremental BLER indices being the difference between a corresponding estimated BLER index and a configured or specific target BLER index, and wherein the plurality of incremental BLER indices are mapped to a reporting table included in the soft HARQ.

8. The method according to claim 1, wherein, The soft HARQ includes additional soft information that is merged with existing HARQ report feedback.

9. The method according to claim 1, wherein, Sending the soft HARQ to the network node includes, in addition to the existing HARQ scheme, reporting a soft acknowledgment (ACK) and the reason for the decoding failure.

10. The method according to claim 1, wherein, Sending the soft HARQ to the network node includes: reporting a soft acknowledgment (ACK) that is merged with the feedback from the existing HARQ report, and the reason for the decoding failure.

11. The method according to claim 1, wherein, The soft HARQ is applied, reported, or configured differently depending on whether the received transmission is an initial transmission or a retransmission.

12. The method according to claim 1, wherein, Sending the soft HARQ to the network node includes: reporting a single soft HARQ feedback report per code block (CB).

13. The method according to claim 1, wherein, Sending the soft HARQ to the network node includes: reporting a single soft HARQ feedback report per code block group (CBG).

14. The method according to claim 1, wherein, Sending the soft HARQ to the network node includes: reporting a single soft HARQ feedback report per transport block (TB).

15. The method according to claim 1, wherein, The selection of the measurement method includes selecting the measurement method based on the following: The bit error rate (BER) is measured based on the flipped log-likelihood ratio (LLR) value, variance, or signal-to-interference and noise ratio (SINR).

16. An apparatus for reporting soft HARQ, the apparatus comprising: A transceiver configured for wireless communication; as well as A processor, coupled to the transceiver and configured to perform operations including: The transceiver receives transmissions from the network node. Generate soft blend automatic repeat request (HARQ); and The soft HARQ is sent to the network node via the transceiver. In generating the soft HARQ, the processor is configured to perform operations including the following: Select measurement methods, metrics, and reporting granularity; and The soft HARQ is generated using a selected measurement method, a selected metric, and a selected reporting granularity, wherein the processor is configured to select the measurement method based on the difficulty of decoding the received transmission.

17. The apparatus according to claim 16, wherein, In selecting the measurement method, the processor is configured to select the measurement method based on the following: The bit error rate (BER) is measured based on the flipped log-likelihood ratio (LLR) value, variance, or signal-to-interference and noise ratio (SINR).

18. The apparatus according to claim 16, wherein, In selecting the metric, the processor is configured to select the metric based on the following: Incremental signal-to-interference-and-noise ratio (SINR), where the incremental SINR is the difference between the reference SINR and the estimated SINR; Incremental Block Error Rate (BLER) index, wherein the incremental BLER index is the difference between an estimated BLER index and a configured or specific target BLER index; Incremental bit error rate (BER) index, which is the difference between an estimated BER index and a configured or specific target BER index; or The incremental modulation coding scheme (MCS) index is the difference between the estimated MCS value of the received transmission based on a reference, specific, or configured BLER or BER and the MCS used for the received transmission.

19. The apparatus according to claim 16, wherein, In selecting the reporting granularity, the processor is configured to select the reporting granularity per code block (CB), per code block group (CBG), or per transport block (TB).

Images