CN112534915A - ACK and NACK differentiation on PUCCH for HARQ-ACK feedback for URLLC PDSCH transmission - Google Patents

Abstract

A User Equipment (UE) is described. The UE includes an upper layer processor configured to: configuring Physical Uplink Control Channel (PUCCH) resources for ultra-reliable low latency communication (URLLC) traffic. The UE also includes transmission circuitry configured to transmit HARQ-ACK feedback for URLLC Downlink (DL) data based on the configured PUCCH resources and HARQ-ACK status.

Description

ACK and NACK differentiation on PUCCH for HARQ-ACK feedback for URLLC PDSCH transmission

Technical Field

The present disclosure relates generally to communication systems. More specifically, the present disclosure relates to Acknowledgement (ACK) and Negative Acknowledgement (NACK) differentiation on a Physical Uplink Control Channel (PUCCH) for HARQ-ACK feedback of an ultra-reliable low latency communication (URLLC) Physical Downlink Shared Channel (PDSCH) transmission.

Background

Wireless communication devices have become smaller and more powerful in order to meet consumer needs and improve portability and convenience. Consumers have become dependent on wireless communication devices and desire reliable service, expanded coverage areas, and enhanced functionality. A wireless communication system may provide communication for a plurality of wireless communication devices, each of which may be served by a base station. A base station may be a device that communicates with a wireless communication device.

With the development of wireless communication devices, methods of improving communication capacity, speed, flexibility, and/or efficiency are continually being sought. However, improving communication capacity, speed, flexibility, and/or efficiency may present certain problems.

For example, a wireless communication device may communicate with one or more devices using a communication structure. However,

the communication architecture used may provide only limited flexibility and/or efficiency. As shown in the present discussion,

systems and methods that improve communication flexibility and/or efficiency may be advantageous.

Disclosure of Invention

In one example, a User Equipment (UE) is described. The UE includes a higher layer processor configured to: configuring Physical Uplink Control Channel (PUCCH) resources for ultra-reliable low latency communication (URLLC) traffic. The UE also includes transmission circuitry configured to transmit HARQ-ACK feedback for URLLC Downlink (DL) data based on the configured PUCCH resources and HARQ-ACK status.

In one example, a base station (gbb) is also described. The gNB includes an upper layer processor configured to configure PUCCH resources at the UE for URLLC traffic. The gNB further includes receive circuitry configured to receive HARQ-ACK feedback for URLLC DL data based on the configured PUCCH resources and HARQ-ACK states.

Drawings

Fig. 1 is a block diagram illustrating one implementation of one or more base stations (gnbs) and one or more User Equipments (UEs) in which Acknowledgement (ACK) and Negative Acknowledgement (NACK) differentiation on a Physical Uplink Control Channel (PUCCH) for HARQ-ACK feedback for ultra-reliable low latency communication (URLLC) Physical Downlink Shared Channel (PDSCH) transmissions may be implemented;

fig. 2 is an example illustrating sub-slot ultra-reliable low-delay communication (URLLC) Physical Downlink Shared Channel (PDSCH) and HARQ-ACK feedback within 1 sub-frame;

fig. 3 illustrates a method of distinguishing ACK feedback from NACK feedback;

fig. 4 shows an example of collision of URLLC PUCCH with other UL channels for HARQ-ACK;

figure 5 shows an example of URLLC PUCCH for HARQ-ACK puncturing all other channels in overlapping symbols;

fig. 6 shows an example of URLLC PUCCH and other UL channels for HARQ-ACK transmitted simultaneously;

fig. 7 is a diagram illustrating an example of a resource grid for downlink;

fig. 8 is a diagram illustrating one example of a resource grid for the uplink;

FIG. 9 shows examples of several parameters;

FIG. 10 shows an example of a subframe structure for the parameters shown in FIG. 9;

FIG. 11 shows an example of a time slot and a sub-slot;

FIG. 12 shows an example of a scheduling timeline;

fig. 13 shows an example of a DL control channel monitoring region;

fig. 14 shows an example of a DL control channel comprising more than one control channel element;

fig. 15 shows an example of a UL control channel structure;

fig. 16 is a block diagram illustrating one implementation of a gNB;

fig. 17 is a block diagram illustrating one implementation of a UE;

FIG. 18 illustrates various components that may be utilized in a UE;

fig. 19 illustrates various components that may be utilized in a gNB;

fig. 20 is a block diagram illustrating one implementation of a UE in which ACK and NACK differentiation on PUCCH for HARQ-ACK feedback for URLLC PDSCH transmission may be implemented; and is

Fig. 21 is a block diagram illustrating one implementation of a gNB in which ACK and NACK differentiation on PUCCH for HARQ-ACK feedback for URLLC PDSCH transmission may be implemented.

Detailed Description

A User Equipment (UE) is described. The UE includes a higher layer processor configured to: configuring Physical Uplink Control Channel (PUCCH) resources for ultra-reliable low latency communication (URLLC) traffic. The UE also includes transmission circuitry configured to transmit HARQ-ACK feedback for URLLC Downlink (DL) data based on the configured PUCCH resources and HARQ-ACK status.

The PUCCH resource set for URLLC traffic may be configured to satisfy Negative Acknowledgement (NACK) feedback error probability, and the same PUCCH resource is used for feedback Acknowledgement (ACK) and NACK.

The PUCCH resource set for URLLC traffic may be configured to satisfy NACK feedback error probability. The UE may use all of the PUCCH resources configured according to the parameter if the HARQ-ACK corresponds to NACK. The UE may use a portion of the PUCCH resources configured in accordance with the parameters if the HARQ-ACK corresponds to an ACK.

The PUCCH resource set for URLLC traffic may be configured separately for harq-ACK with ACK and NACK feedback. More resources may be defined by the parameters for NACK feedback than by the parameters for ACK feedback. The UE may use the PUCCH resources configured only according to the parameters for NACK feedback if the HARQ-ACK corresponds to NACK. The UE may use the PUCCH resources configured only in accordance with the parameters for ACK feedback if the HARQ-ACK corresponds to an ACK.

The PUCCH resource for NACK has more redundancy or overhead than the PUCCH resource for ACK and may be configured with different parameters in terms of the number of Physical Resource Blocks (PRBs), the number of symbols in the time domain, the number of time domain repetitions, the transmission diversity configuration, and/or the transmission power.

The UE may be configured with only PUCCH resources for NACK feedback. The UE may use the PUCCH resources configured according to the parameters for NACK feedback if the HARQ-ACK corresponds to NACK. The UE may not transmit a PUCCH corresponding to the PDSCH if the HARQ-ACK corresponds to an ACK.

A base station (gNB) is also described. The gNB includes an upper layer processor configured to configure PUCCH resources at the UE for URLLC traffic. The gNB further includes receive circuitry configured to receive HARQ-ACK feedback for URLLC DL data based on the configured PUCCH resources and HARQ-ACK states.

The 3 rd generation partnership project (also referred to as "3 GPP") is a partnership protocol intended to establish globally applicable technical specifications and technical reports for third and fourth generation wireless communication systems. The 3GPP may specify specifications for next generation mobile networks, systems, and devices.

The 3GPP Long Term Evolution (LTE) is the name given to a project for improving the Universal Mobile Telecommunications System (UMTS) mobile phone or device standard to cope with future demands. In one aspect, UMTS has been modified to provide support and specification for evolved Universal terrestrial radio Access (E-UTRA) and evolved Universal terrestrial radio Access network (E-UTRAN).

At least some aspects of the systems and methods disclosed herein may be described in connection with 3GPP LTE, LTE-advanced (LTE-a), and other standards (e.g., 3GPP release 8, 9, 10, 11, and/or 12). However, the scope of the present disclosure should not be limited in this respect. At least some aspects of the systems and methods disclosed herein may be used in other types of wireless communication systems.

The wireless communication device may be an electronic device that communicates voice and/or data to a base station, which in turn may communicate with a network of devices (e.g., the Public Switched Telephone Network (PSTN), the internet, etc.). In describing the systems and methods herein, a wireless communication device may alternatively be referred to as a mobile station, a UE, an access terminal, a subscriber station, a mobile terminal, a remote station, a user terminal, a subscriber unit, a mobile device, or the like. Examples of wireless communication devices include cellular phones, smart phones, Personal Digital Assistants (PDAs), laptop computers, netbooks, e-readers, wireless modems, and so forth. In the 3GPP specifications, the wireless communication apparatus is generally referred to as a UE. However, as the scope of the present disclosure should not be limited to 3GPP standards, the terms "UE" and "wireless communication device" are used interchangeably herein to represent the more general term "wireless communication device". The UE may also be referred to more generally as a terminal device.

In the 3GPP specifications, a base station is often referred to as a node B, an evolved node B (enb), a home enhanced or evolved node B (henb), or some other similar terminology. As the scope of the present disclosure should not be limited to 3GPP standards, the terms "base station," node B, "" eNB, "" gNB, "and/or" HeNB "are used interchangeably herein to represent the more general term" base station. Moreover, the term "base station" can be utilized to represent an access point. An access point may be an electronic device that provides access to a network (e.g., a Local Area Network (LAN), the internet, etc.) for wireless communication devices. The term "communication device" may be used to refer to a wireless communication device and/or a base station. The eNB may also be referred to more generally as a base station device.

It should be noted that as used herein, a "cell" may be any such communication channel: it is specified by standardization or regulatory bodies for Advanced international mobile telecommunications (IMT-Advanced) and all or a subset thereof to be adopted by 3GPP as a licensed frequency band (e.g., a frequency band) for communication between an eNB and a UE. It should also be noted that in the general description of E-UTRA and E-UTRAN, "cell" may be defined as a "combination of downlink resources and optionally uplink resources" as used herein. The linking between the carrier frequency of the downlink resource and the carrier frequency of the uplink resource may be indicated in system information transmitted on the downlink resource.

"configured cells" are those cells that the UE knows and is granted permission by the eNB to transmit or receive information. The "configured cell" may be a serving cell. The UE may receive system information and perform the required measurements on all configured cells. A "configured cell" for a radio connection may include a primary cell and/or zero, one, or more secondary cells. The "active cells" are those configured cells on which the UE is transmitting and receiving. That is, the active cells are those cells for which the UE monitors its Physical Downlink Control Channel (PDCCH) and, in the case of downlink transmission, decodes its Physical Downlink Shared Channel (PDSCH). "deactivated cells" are those configured cells for which the UE does not monitor the transmission PDCCH. It should be noted that a "cell" may be described in different dimensions. For example, a "cell" may have temporal, spatial (e.g., geographical), and frequency characteristics.

Fifth generation (5G) cellular communication (also referred to by 3GPP as "new radio", "new radio access technology" or "NR") envisages the use of time/frequency/space resources to allow services such as enhanced mobile broadband (eMBB) communication and ultra-reliable low-delay communication (URLLC) services, as well as large-scale machine type communication (MMTC). The New Radio (NR) base station may be referred to as the gbb. The gbb may also be referred to more generally as a base station apparatus.

In 5G NR, different services may be supported by different quality of service (QoS) requirements (e.g., reliability and delay tolerance). For example, eMBB may target high data rates, and URLLC is used to achieve ultra-reliability and low latency. To provide super-reliability for URLLC traffic, PUCCH for UCI feedback may be enhanced to the same reliability level as data for URLLC. PUCCH format 0 (i.e. short PUCCH with up to 2 bits UCI) is more suitable for URLLC data HARQ-ACK feedback according to ultra-low delay requirements.

For HARQ-ACK feedback, different Bit Error Rate (BER) requirements are applied for ACK to NACK errors and NACK to ACK errors. Some differentiation method may be introduced to provide better NACK feedback protection than ACK feedback.

In addition, carryThe PUCCH for HARQ-ACK of URLLC PDSCH may have higher priority than other channels. Thus, the PUCCH carrying HARQ-ACK for URLLC PDSCH transmission may puncture any other UL channel if collision occurs. If an ACK is always reported, excessive dropping of other UL channels may occur because URLLC data has 10⁵Very low error probability. Therefore, a method that avoids unnecessary UL channel drops while providing the required reliability may be beneficial.

Various examples of the systems and methods disclosed herein will now be described with reference to the drawings, wherein like reference numbers may indicate functionally similar elements. The systems and methods as generally described and illustrated in the figures herein can be arranged and designed in a wide variety of different implementations. Thus, the following more detailed description of several implementations presented in the figures is not intended to limit the scope of the claims, but is merely representative of the systems and methods.

Fig. 1 is a block diagram illustrating one implementation of one or more base stations (gnbs) 160 and one or more User Equipments (UEs) 102 in which Acknowledgement (ACK) and Negative Acknowledgement (NACK) differentiation on a Physical Uplink Control Channel (PUCCH) for HARQ-ACK feedback for ultra-reliable low-latency communication (URLLC) Physical Downlink Shared Channel (PDSCH) transmissions may be implemented. One or more UEs 102 communicate with one or more gnbs 160 using one or more antennas 122 a-n. For example, UE102 transmits electromagnetic signals to gNB160 and receives electromagnetic signals from gNB160 using one or more antennas 122 a-n. The gNB160 communicates with the UE102 using one or more antennas 180 a-n.

UE102 and gNB160 may communicate with each other using one or more channels 119, 121. For example, UE102 may transmit information or data to gNB160 using one or more uplink channels 121. Examples of the uplink channel 121 include PUCCH (physical uplink control channel) and PUSCH (physical uplink shared channel), PRACH (physical random access channel), and the like. For example, an uplink channel 121 (e.g., PUSCH) may be used to transmit UL data (i.e., transport blocks), MAC PDUs, and/or UL-SCH (uplink shared channel)).

Here, the UL data may include URLLC data. The URLLC data may be UL-SCH data.

Here, URLLC-PUSCH (i.e., a different physical uplink shared channel from PUSCH) may be defined to transmit URLLC data. For simplicity of description, the term "PUSCH" may represent any one of the following: (1) PUSCH only (e.g., regular PUSCH, non-URLLC-PUSCH, etc.), (2) PUSCH or URLLC-PUSCH, (3) PUSCH and URLLC-PUSCH, or (4) URLLC-PUSCH only (e.g., not regular PUSCH).

Also, for example, the uplink channel 121 may be used to transmit hybrid automatic repeat request-ACK (HARQ-ACK), Channel State Information (CSI), and/or Scheduling Request (SR). The HARQ-ACK may include information indicating positive Acknowledgement (ACK) or Negative Acknowledgement (NACK) of DL data (i.e., a transport block), a medium access control protocol data unit (MAC PDU), and/or a DL-SCH (downlink shared channel).

The CSI may include information indicating channel quality of a downlink. The SR may be used to request UL-SCH (uplink shared channel) resources for new transmissions and/or retransmissions. That is, the SR may be used to request UL resources for transmission of UL data.

For example, one or more gnbs 160 may also transmit information or data to one or more UEs 102 using one or more downlink channels 119. Examples of the downlink channel 119 include PDCCH, PDSCH, and the like. Other kinds of channels may be used. The PDCCH may be used to transmit Downlink Control Information (DCI).

Each of the one or more UEs 102 may include one or more transceivers 118, one or more demodulators 114, one or more decoders 108, one or more encoders 150, one or more modulators 154, a data buffer 104, and a UE operations module 124. For example, one or more receive paths and/or transmit paths may be implemented in the UE 102. For convenience, only a single transceiver 118, decoder 108, demodulator 114, encoder 150, and modulator 154 are shown in the UE102, but multiple parallel elements (e.g., multiple transceivers 118, decoders 108, demodulators 114, encoders 150, and modulators 154) may be implemented.

The transceiver 118 may include one or more receivers 120 and one or more transmitters 158. One or more receivers 120 may receive signals from a gNB160 using one or more antennas 122 a-n. For example, receiver 120 may receive and down-convert a signal to generate one or more received signals 116. One or more received signals 116 may be provided to demodulator 114. One or more transmitters 158 may transmit signals to the gNB160 using one or more antennas 122 a-n. For example, one or more transmitters 158 may upconvert and transmit one or more modulated signals 156.

Demodulator 114 may demodulate one or more received signals 116 to produce one or more demodulated signals 112. One or more demodulated signals 112 may be provided to decoder 108. The UE102 may decode the signal using the decoder 108. The decoder 108 may generate a decoded signal 110, which may include the UE-decoded signal 106 (also referred to as the first UE-decoded signal 106). For example, the first UE decoded signal 106 may include received payload data, which may be stored in the data buffer 104. Another signal included in the decoded signal 110 (also referred to as the second UE decoded signal 110) may include overhead data and/or control data. For example, the second UE decoded signal 110 may provide data that the UE operations module 124 may use to perform one or more operations.

In general, UE operations module 124 may enable UE102 to communicate with one or more gnbs 160. The UE operations module 124 may include a UE scheduling module 126.

UE scheduling module 126 may perform Acknowledgement (ACK) and Negative Acknowledgement (NACK) differentiation on a Physical Uplink Control Channel (PUCCH) for HARQ-ACK feedback of an ultra-reliable low latency communication (URLLC) Physical Downlink Shared Channel (PDSCH) transmission. For URLLC PDSCH transmission, HARQ-ACK feedback for URLLC Downlink (DL) data may have the same reliability requirements as the URLLC data transmission itself. The target of the current NR PUCCH design is 1% Acknowledgement (ACK) false detection probability and 0.1% Negative Acknowledgement (NACK) to ACK error probability. Thus, some enhancements may be specified to improve PUCCH reliability for HARQ-ACK feedback for URLLC traffic.

In NR, PUCCH format 0 is a short PUCCH having 1 or 2 symbols and is designed for feedback of up to 2 UCI bits. To reduce the error probability of PUCCH format 0, several methods may be considered (e.g., configuring more than one Physical Resource Block (PRB); time domain repetition; transmit diversity; different transmit power settings). The methods may be configured independently or in combination. New PUCCH formats may be defined to obtain these enhancements.

According to low latency requirements, two or more PUCCH resources may need to be configured in a single slot. The current practice of allocating the time domain for the short PUCCH by configuring a single starting symbol in the slot will not suffice. Thus, PUCCH resource sets for URLLC traffic may be configured independently and separately from eMBB PUCCH resource sets. PUCCH resources for URLLC may be configured with different parameters and/or some different fields than eMBB resources.

For URLLC, PDSCH transmission with a single codeword or TB is the most common case, since MIMO transmission with up to 4 layers supports only one codeword. The error probability of the PUCCH carrying HARQ-ACK of URLLC PDSCH should be at least the same error probability as URLLC data (e.g., 10)^-5) Targeted, or on a lower order of magnitude (e.g. 10)^-6) Is the target. Furthermore, the NACK-to-ACK error probability should also be lower than the ACK-to-NACK error probability. Thus, the NACK-to-ACK error probability may be 10^-6Even as low as 10^-7。

To provide sufficient protection for NACK feedback, in one approach, the PUCCH for both ACK and NACK feedback should be enhanced to achieve a lower error probability (e.g., 10) defined by NACK^-6Or 10^-7). But this may result in allocating too many resources for the PUCCH. In another approach, if different BER requirements apply between ACK-to-NACK errors and NACK-to-ACK errors, some differentiating method may be introduced to provide better NACK feedback protection than ACK feedback. For example, the distinguishing method may include using different PUCCH resources for ACK feedback and NACK feedback, NACK feedback having more PRBs or time domain repetition than ACK feedback, and/or NACK feedback having higher transmission power than ACK feedback.

In addition, carry for URLLC PDSCH may have a higher priority for the PUCCH for HARQ-ACK than for other channels. Thus, the PUCCH carrying HARQ-ACK for URLLC PDSCH transmission may puncture any other UL channel if collision occurs. If an ACK is always reported, excessive dropping of other UL channels may occur because URLLC data has 10^-5Very low error probability. To avoid excessive dropping of other channels, ACK feedback may be turned on/off. If the ACK feedback is off, only NACKs are reported for URLLC DL data.

Aspects of PUCCH formats in NR are described herein. The PUCCH may be used to report important Uplink Control Information (UCI) including HARQ-ACK, SR, Channel State Information (CSI), and the like. While NR release 15 is primarily designed for enhanced mobile broadband (eMBB), a variety of Physical Uplink Control Channel (PUCCH) formats are specified for different numbers of bits, as described below.

The physical uplink control channel supports a variety of formats as shown in table 1. In case of configuring frequency hopping for PUCCH format 1, 3 or 4, the number of symbols in the first hop is determined by

Is given in

Is the length of PUCCH transmission in OFDM symbol units.

TABLE 1

In 5G NR, different services may be supported by different quality of service (QoS) requirements (e.g., reliability and delay tolerance). For example, eMBB may target high data rates, and URLLC is used to achieve ultra-reliability and low latency.

URLLC traffic may use the same parameters as the eMBB service. URLLC downlink transmissions may also use a different SCS than eMBB DL transmissions. For example, URLLC traffic may use higher parameters than eMBB services (i.e., the subcarrier spacing (SCS) of URLLC transmissions may be greater than that of eMBB transmissions). The larger SCS configuration for URLLC reduces the length of OFDM symbols, thus reducing the delay of transmission and its HARQ-ACK feedback.

In some approaches, URLLC DL transmissions and UL transmissions may be configured with the same parameters. In other approaches, URLLC DL transmissions and UL transmissions may be configured with different parameters. For HARQ-ACK feedback for DL URLLC transmissions, the URLLC short PUCCH may use different parameters than the other short PUCCHs. For example, URLLC PUCCH should have a shorter symbol length than other short PUCCH or PUSCH transmissions. In this disclosure, URLLC DL data transmission and corresponding HARQ-ACK feedback to PUCCH is described.

To provide super-reliability for URLLC traffic, 10 may be used^-5Error probability to configure different CQI and MCS tables for URLLC. Meanwhile, PUCCH for HARQ-ACK feedback of URLLC data may be enhanced to at least the same reliability level as data for URLLC.

For URLLC traffic, several aspects of PUCCH design and PUCCH transmission may need to be considered. URLLC traffic requires ultra-high reliability and low latency. HARQ-ACK for URLLC packets may be supported to provide the required reliability. Furthermore, HARQ-ACK feedback may be reported immediately after URLLC transmission. Furthermore, HARQ-ACK feedback may have the same reliability as URLLC data transmission (i.e., current 1% or 0.1% PUCCH channel BER requirements may not meet URLLC requirements). The HARQ-ACK BER requirement may be the same or higher (i.e., at least 10) as the URLLC data channel^-5Or 10^-6)。

URLLC traffic may share HARQ-ACK processes with eMBB. However, the number of HARQ-ACK processes for URLLC may be limited (e.g., only 1 or 2 HARQ-ACK processes are used for URLLC traffic). Thus, the PUCCH format for URLLC DL transmission may also provide ultra-high reliability and low latency after URLLC DL transmission. Only the short PUCCH may be used for URLLC HARQ-ACK feedback. The location of the short PUCCH may be determined dynamically based on URLLC DL data transmissions (e.g., immediately after URLLC DL transmissions with a gap that satisfies processing time requirements).

PUCCH format 0 (i.e. short PUCCH with up to 2 bits UCI) is more suitable for URLLC data HARQ-ACK feedback according to ultra-low delay requirements. NR PUCCH format 0 occupies a single Physical Resource Block (PRB) and uses a sequence to indicate a maximum of 2-bit payload. To reduce the error probability of PUCCH format 0, several methods may be considered (e.g., configuring more than one PRB, time domain repetition, transmit diversity, different transmit power settings).

The methods may be configured independently or in combination. New PUCCH formats may be defined to obtain these enhancements. The new PUCCH format may be named PUCCH format 5, PUCCH format 0_1, advanced PUCCH format 0(PUCCH format 0a), enhanced PUCCH format 0(PUCCH format 0e), super-reliable PUCCH format 0(PUCCH format 0_ r or format 0_ u), and the like.

URLLC PUCCH resource allocation and configuration is described herein. In NR, multiple PUCCH resource sets may be configured for different payload sizes. Up to 16 PUCCH resources may be configured in each PUCCH resource set. If the number of resources is greater than 4, a subset is formed. In NR, for PUCCH reporting, a PUCCH resource set may first be determined based on UCI payload size. The ARI field may indicate a PUCCH resource subset in the PUCCH resource set. If there are more than 1 PUCCH resource in each subset, a PUCCH resource for UCI reporting may be implicitly determined based on a CCE index of the scheduling DCI.

For URLLC, a short PUCCH may be useful according to low delay requirements. At least one PUCCH resource set for up to 2-bit UCI may be configured. Since URLLC has different reliability and delay requirements than eMBB. HARQ-ACK feedback PUCCH resources for URLLC may be configured separately from eMBB. PUCCH resources for URLLC may be configured with different parameters than normal PUCCH resources for eMBB.

To provide the desired reliability for DL URLLC transmissions, PUCCH resources may be allocated to allow PDSCH retransmissions. According to high reliability and low delay requirements, to support retransmission of URLLC PDSCH, one or more HARQ-ACK feedbacks may be reported within a subframe, and more than 2 PUCCH resources may be configured in a subframe or slot, as shown in fig. 2.

The current practice of allocating the time domain for the short PUCCH by configuring the starting symbol and duration would probably not be sufficient. Some enhancements to time domain PUCCH resource allocation and configuration may be achieved, resulting in an enhanced short PUCCH (e.g., PUCCH resource subset includes multiple PUCCH resources with different starting symbols in a slot; a single PUCCH resource may be configured with multiple starting symbol positions in a slot; PUCCH resources may be configured with PUCCH formats and periodicity, etc.).

The differentiation of URLLC ACK feedback and NACK feedback is described herein. BER requirements for HARQ-ACK feedback for PUCCH for URLLC PDSCH transmission should be the same or higher (e.g., at least 10) than the URLLC data channel^-5Or 10^-6). Furthermore, the NACK-to-ACK error probability should be much lower than the ACK-to-NACK error probability. If the ACK is detected as NACK, the PDSCH will be retransmitted and cause unnecessary waste of resources. On the other hand, if a NACK is detected as an ACK, then the gNB160 may assume that it was received correctly and the packet data will be discarded. This can result in much more retransmission overhead. If a fragment is erroneously dropped, it may be necessary to retransmit all fragments through higher layer packet dropping and retransmission. Thus, if the ACK-to-NACK error probability is 10⁵Then the NACK-to-ACK error probability should be 10^-6(ii) a If the ACK-to-NACK error probability is 10^-6Then the NACK-to-ACK error probability should be 10^-7。

To provide sufficient protection for NACK feedback, in one approach, the PUCCH for both ACK and NACK feedback should be enhanced to achieve the lower error probability (e.g., 10) required for NACK feedback^-6Or 10^-7). But this may result in allocating too many resources for the PUCCH.

In another approach, if different BER requirements apply between ACK-to-NACK errors and NACK-to-ACK errors, some differentiation method may be introduced to provide better protection for NACK feedback than ACK feedback. Several methods are described herein. Fig. 3 illustrates two methods of distinguishing ACK feedback from NACK feedback described herein.

In a first approach (approach 1), the PUCCH resources may be configured to report HARQ-ACKs (ACKs or NACKs) for URLLC PDSCH transmissions, but the ACKs and NACKs may be reported using different actual transmission modes and configurations.

PUCCH resources for URLLC may be configured with multiple PRBs, time domain repetition, transmission diversity, and/or enhanced power control. The PUCCH resources may be configured based on higher reliability requirements between ACK and NACK (e.g., based on NACK feedback BER requirements). If the feedback is a NACK, the configured parameters may be used. If the feedback is an ACK, different PUCCH parameters may be used to reduce PUCCH resource overhead. That is, based on detecting the PDSCH transmission, if the UE102 feeds back HARQ-ACK (ACK or NACK), the UE102 may feed back the HARQ-ACK using PUCCH resources based on the configured parameters. And, if the HARQ-ACK corresponds to NACK, the UE102 may use the entire PUCCH resource configured according to the parameter. Further, if the HARQ-ACK corresponds to an ACK, the UE102 may use a portion of the PUCCH resources configured according to the parameter.

In one example, if multiple PRBs are configured, then all configured PRBs should be used to report NACKs, and fewer PRBs may be utilized to report ACKs.

In another example, if time domain repetition is configured, a NACK may be reported using a configured number of time domain repetitions (e.g., a number of slots and/or symbols), and an ACK may be reported with a lesser number of time domain repetitions. As a special case, if a dual-symbol PUCCH is configured, NACK should be reported using the dual-symbol PUCCH, and ACK may be reported using a single-symbol PUCCH by using only the first symbol of the dual-symbol PUCCH resource.

As another example, if TxD is configured, NACK should be transmitted using two PUCCH resources with two antenna ports, and ACK may be reported with a single antenna port on a single PUCCH resource.

As another example, different transmission powers may be applied to PUCCH transmission of ACK and NACK. The transmission power for NACK feedback should be higher than the transmission of ACK feedback. The difference or delta value between the transmission powers may be predefined or configured to the UE102 by RRC.

It should be noted that different parameters may be configured independently or jointly for PUCCH resources for ACK feedback and NACK feedback. For example, the gNB160 may transmit parameters for configuring PUCCH resources for ACK and NACK by using a higher layer signal (e.g., RRC message). Further, the gNB160 may transmit a parameter indicating PUCCH resources for ACK and NACK by using DCI included in a DCI format for scheduling PDSCH transmission. Further, a PDCCH (e.g., a control channel element of the PDCCH) scheduling PDSCH transmission may be used to indicate PUCCH resources for ACK and NACK. Here, as described above, the gNB160 may configure parameters for only short PUCCH formats (e.g., PUCCH format 0 and/or PUCCH format 1).

Here, as described above, the parameter may include at least a parameter for configuring the starting PRB index and/or the number of PRBs (i.e., frequency domain configuration). Further, the parameter may include at least a parameter for configuring the number of repetitions (i.e., time-domain configuration). Further, the parameters may include at least a parameter for configuring the number of antenna ports (i.e., spatial domain configuration, whether two antenna ports are used). Further, the parameter may include at least a parameter for configuring a transmission power. Further, as described below, the parameter may include at least a parameter for configuring a cyclic shift value.

As described above, the UE102 may transmit HARQ-ACK (ACK or NACK) using PUCCH resources (i.e., one PUCCH resource) based on the parameter. Also, the UE102 may determine an amount of resources (e.g., a number of Resource Elements (REs) in a frequency domain and/or a time domain) for HARQ-ACK feedback based on whether the HARQ-ACK corresponds to an ACK or a NACK. For example, for ACK feedback, the UE102 may use a smaller amount of resources than the resources used for NACK feedback. Here, how to determine the amount of resources (e.g., the amount of resources for ACK feedback) may be determined in advance by specifications or the like (e.g., by using a formula). Further, the gNB160 may configure a parameter (e.g., an offset value) for configuring an amount of resources (e.g., an amount of resources for ACK feedback) by using a higher layer signal. UE102 may determine an amount of resources on PUCCH resources for HARQ-ACK feedback (e.g., an amount of resources for ACK feedback) based on the parameter (e.g., offset value).

In the second method (method 2), separate PUCCH resources may be configured for ACK feedback and NACK feedback. For example, the gNB160 may configure PUCCH resources only for ACK feedback, and may configure PUCCH resources only for NACK feedback. Also, based on detecting PDSCH transmission, if the HARQ-ACK corresponds to an ACK, the UE102 may use PUCCH resources only for ACK feedback. Further, based on detecting the PDSCH transmission, the UE102 may use PUCCH resources for NACK feedback only if the HARQ-ACK corresponds to a NACK.

In the method, different PUCCH resources and different parameters are configured for ACK feedback and NACK feedback. The PUCCH resource for NACK feedback may be configured with parameters that provide better BER performance than the PUCCH resource for ACK feedback.

In one example, PUCCH resources for ACK feedback and NACK feedback may have different starting PRB indices and different numbers of PRBs. The number of PRBs configured for NACK feedback (e.g., the number of PRBs supported) may be higher than the number of ACK feedback.

In another example, PUCCH resources for ACK feedback and NACK feedback may have different numbers of symbols (e.g., a supported number of symbols) or different numbers of time domain repetitions (e.g., a supported number of time domain repetitions). For example, 1-symbol PUCCH is used for ACK feedback and 2-symbol PUCCH is used for NACK feedback.

In another example, PUCCH for NACK feedback may be configured with TxD, and PUCCH for ACK may not be configured with TxD. That is, dual antenna port transmission may be supported only for NACK feedback. For example, if the UE102 is configured with dual antenna port transmission for PUCCH format 0, for HARQ-ACK transmission using PUCCH format 0, the UE102 may use only dual antenna ports (with two PUCCH resources) for NACK feedback and a single antenna port (with a single PUCCH resource) for ACK feedback.

As another example, the transmission power of NACK feedback may be configured with a higher value than the transmission power of the PUCCH for ACK feedback. The difference or delta value between the transmission powers may be predefined or configured to the UE102 by RRC.

It should be noted that different parameters may be configured independently or jointly for PUCCH resources for ACK feedback and NACK feedback. Here, as with method 1, the gNB160 may configure different parameters for PUCCH resources. Further, these different parameters may include at least the parameters described in method 1.

In this second method, in addition to PUCCH transmission and detection, another level of ACK/NACK feedback may be provided by on/off keying on different PUCCH resources. NACK may be reported only on configured NACK resources (e.g., PUCCH resources for NACK feedback only), and ACK may be reported only on configured ACK resources (e.g., PUCCH resources for ACK feedback only).

With PUCCH format 0, resources are defined by the sequence and cyclic shift in each configured RB. Thus, if one PUCCH resource is configured for a single bit of ACK or NACK feedback (e.g., similar to method 1), two cyclic shifts of distance 6 are reserved and the resource is configured based on the lowest BER requirement between ACK and NACK. If two different PUCCH resources are configured for ACK feedback and NACK feedback (e.g., similar to method 2), each PUCCH resource retains only one cyclic shift of the sequence. Therefore, PUCCH resource overhead does not increase. In fact, since the PUCCH resource for ACK feedback has less redundancy or overhead than the PUCCH resource for NACK feedback, the overall resource overhead of the separate PUCCH resources for ACK feedback and NACK feedback in method 2 is lower than that of the single PUCCH resource for both ACK feedback and NACK feedback in method 1.

Further, the ACK feedback may be turned off based on an ultra-low error probability, as described in detail below. In this case, the UE102 may be configured with PUCCH resources for NACK feedback only.

URLLC PUCCH transmission and collision handling with other UL channels is also described herein. URLLC traffic requires ultra-high reliability and low latency. A URLLC UL data transmission may collide with PUCCH or PUSCH transmissions of the same UE102 (e.g., on the same symbol). An example of collision of URLLC PUCCH with other UL channels for HARQ-ACK is shown in fig. 4.

As a general rule, URLLC traffic should have a higher priority than any other UL transmission. Furthermore, HARQ-ACK feedback for DL URLLC PDSCH transmissions should have higher priority than UL URLLC data. Therefore, PUCCH feedback for URLLC PDSCH transmission should have the highest priority among all channels or UL transmissions.

In NR release 15, simultaneous UL channel transmission on the same BWP or CC is not supported. In case of full or partial overlap between PUCCH and/or PUSCH, some UCI multiplexing rules may be defined with some processing time constraints.

At least for PUCCH carrying HARQ-ACK feedback for URLLC PDSCH transmissions, UCI multiplexing with other PUCCH used for normal PDSCH transmissions is difficult for several reasons. The multiplexed HARQ-ACK of URLLC traffic on the normal PUCCH cannot meet the ultra-low BER requirement. Also, PUCCH does not have sufficient resources to improve reliability to a desired level. Multiplexing on HARQ-ACK PUCCH for URLLC will increase the payload and reduce the BER performance of HARQ-ACK feedback for URLLC traffic. The starting position and duration of the normal PUCCH may be very different from the PUCCH used for URLLC feedback. Additionally, the normal PUCCH and URLLC PUCCH may be misaligned.

HARQ-ACK multiplexing on normal PUSCH transmission may also be difficult, at least for PUCCH carrying HARQ-ACK feedback for URLLC PDSCH transmission. The RE mapping for URLLC HARQ-ACK should be different from normal HARQ-ACK. A much higher beta offset value may be used. The UE102 may not have sufficient processing time to handle PUSCH data puncturing or rate matching. The HARQ-ACK of URLLC may occur at any symbol, and if the HARQ-ACK is multiplexed after the DMRS symbol, the URLLC traffic may violate timing requirements.

Thus, PUCCH carrying HARQ-ACK for URLLC PDSCH may be always transmitted and other UL channels may be de-prioritized or dropped.

In a first method (method 1), the PUCCH carrying HARQ-ACK of the URLLC PDSCH may be transmitted and any other UL channels in the overlapping symbols are discarded. An example of the URLLC PUCCH for HARQ-ACK puncturing all other channels in overlapping symbols is shown in fig. 5.

This is a simple solution, applicable to all cases, regardless of the type of overlapping channels. In the case where URLLC traffic is configured with a higher SCS than eMBB traffic, the entire symbol in the overlapping channel should be discarded even if the PUCCH of URLLC occupies a portion of the symbol duration of the overlapping channel. For example, the first SCS may be configured for the first PDCCH and/or the first PDSCH. The first PDCCH may be used to schedule the PDSCH. Further, the second SCS may be configured for a second PDCCH and/or a second PDSCH. The second PDCCH may be used to schedule a second PDSCH. Here, the first SCS and the second SCS may be configured for the same BWP (e.g., the same DL BWP) and/or the same timing (e.g., the same slot and/or symbol).

In the case where the first SCS (e.g., 60kHz SCS) is configured with a higher SCS than the second SCS (e.g., 15kHz), if the UE102 detects the first PDCCH and/or the first PDSCH, the UE102 may perform HARQ-ACK transmission on the PUCCH corresponding to the first PDSCH (e.g., even if the PUCCH symbols for the first PDSCH and the PUCCH symbols for the second PDSCH overlap). In this case, UE102 may discard the HARQ-ACK transmission for the second PDSCH (e.g., discard the entire symbol of the PUCCH for the HARQ-ACK transmission for the second PDSCH).

In a second method (method 2), simultaneous transmission of PUCCH and other PUCCH or PUSCH transmissions carrying HARQ-ACK for the URLLC PDSCH may occur, with power reduction on other channels with power limitation. An example of URLLC PUCCH and other UL channels for HARQ-ACK transmitted simultaneously is shown in fig. 6.

To support URLLC traffic without dropping too many UL channels, simultaneous UL channel transmission may be supported in release 16 and later releases. If supported, the PUCCH for URLLC traffic may be transmitted simultaneously with another PUCCH or PUSCH channel.

If simultaneous transmission of PUCCH for URLLC and another UL channel (PUCCH or PUSCH) is supported on the same symbol, and if there are overlapping REs between PUCCH for URLLC PDSCH feedback and the other UL channel, the overlapping REs of the other UL channel are punctured by PUCCH for URLLC PDSCH feedback. Furthermore, UL transmission power should be first allocated to PUCCH for URLLC traffic. The remaining power may be allocated to the remaining REs of the other UL channel in the same UL symbol. In the power limited case, power reduction should be performed on the remaining REs of the other UL channel in the same UL symbol to meet the Pcmax limit for a given BWP or serving cell.

While UL channel transmissions may be limited to URLLC transmissions (e.g., only in the UL channel)One UL channel for URLLC or sub-slot transmission, simultaneous UL transmission can be supported). In this case, simultaneous UL channel transmission support may be defined as UE features under URLLC and may be configured from gNB160 to UE102 through RRC signaling. If configured, the following simultaneous transmissions may be supported: the PUCCH for HARQ-ACK of URLLC PDSCH may be transmitted simultaneously with other UL channels; URLLC PUSCH (e.g., with 10)^-5Sub-slot PUSCH of the new MCS table for the target BLER) may be transmitted simultaneously with other UL channels; and/or PUCCH for HARQ-ACK of URLLC PDSCH may be transmitted simultaneously with URLLC PUSCH transmission by grant-based or grant-free scheduling.

Simultaneous UL channel transmission may be extended to all traffic types (e.g., PUCCH and PUSCH are both used for eMBB transmission). In this case, simultaneous UL channel transmission support may be defined as a separate UE feature and may be configured from the gNB160 to the UE102 through RRC signaling.

To simplify the process, simultaneous UL transmission may be limited to 2 UL channels. A priority order from highest priority to lowest priority may be defined for the UL channel (e.g., PUCCH for HARQ-ACK of URLLC PDSCH transmission > PUCCH for SR of URLLC > PUSCH for URLLC > PUCCH for URLLC CSI reporting > PUCCH for HARQ-ACK feedback of eMBB PDSCH > PUCCH for SR of eMBB > PUCCH for CSI feedback of eMBB PDSCH > PUSCH for eMBB).

URLLC PUCCH on/off for ACK feedback is also described herein. Due to the super-reliability of URLLC data transmission, the probability of reporting a NACK is very low, only 10^-5. In other words, 99.999% of the HARQ-ACK feedback for URLLC PDSCH will be ACK. If PUCCH for HARQ-ACK feedback is always reported for URLLC PDSCH transmission, ACK is reported 99.999% of the time. Whenever there is a collision between PUCCH for URLLC traffic and another UL channel, if the above method 1 is applied (e.g., URLLC PUCCH punctures any other UL channel), then the other UL channel is discarded; or if the above method 2 is applied (e.g., simultaneous transmission of PUCCH and other channels for URLLC), performance is degraded.

To avoid excessive dropping of other UL channels, it may be turned on orThe ACK feedback is turned off. If the ACK feedback is turned off, only NACK is reported on PUCCH (e.g., PUCCH for URLLC DL data). This significantly reduces the number of PUCCH transmissions since the NACK probability is only 10^-5. Therefore, in most cases, other UL channel transmissions are not affected.

There is a potential problem with DL false detection. For normal PDSCH transmission, the PDCCH false detection probability is 1%, the PDSCH decoding block error rate (BLER) target is 10%, and the HARQ-ACK feedback error probability is 1% to 0.1%.

In the normal HARQ-ACK procedure, for a single PDSCH transmission, if the UE102 does not correctly detect the scheduling DCI for the given PDSCH transmission, no HARQ-ACK is reported and no PUCCH is transmitted. The corresponding lack of PUCCH feedback is considered DTX by the gNB160 and the gNB160 subsequently retransmits the PDSCH.

If ACK feedback is turned off (e.g., for URLLC PDSCH transmissions), then gNB160 cannot distinguish DTX from ACK. In case of DTX occurring, the gNB160 may consider the PDSCH to be correctly received because no NACK is reported. However, if the PDCCH false detection probability is lower than the data error probability, the PDCCH false detection error is acceptable because it already meets the data performance criteria. For example, if the expected URLLC data error probability is 10⁵And the PDCCH error probability is 10^-5Or 10^-6DTX errors are acceptable even if ACK feedback is turned off.

It should be noted that the error probability of PDSCH already takes into account the necessary PDSCH retransmissions and the initial PDSCH transmission probability may be much higher than the expected URLLC data error probability. For example, the initial PDSCH transmission error probability may be 10^-3After retransmission, the PDSCH error probability may be reduced to 10^-5Or 10^-6。

In summary, if the PDCCH for URLLC scheduling is enhanced to have the same or a much lower error probability as the target URLLC data error probability, the ACK feedback (e.g., for URLLC PDSCH transmission) may be turned off to avoid excessive dropping of other UL channels.

ACK feedback on/off may be considered a special treatment for ACK and NACK differentiation. In this extreme case, there is no need to report an ACK, and only a NACK is reported. If ACK feedback is turned off, the UE102 may be configured with PUCCH resources only for NACK reporting (e.g., for sequence base format 0 feedback) and only one cyclic shift of the reserved sequence is needed for HARQ-ACK feedback. The PUCCH report will not be considered an ACK and the detection of PUCCH transmission is a NACK. Basically, NACK feedback is acknowledged by on/off keying of PUCCH transmissions. The combination of on/off keying on PUCCH and NACK detection will provide higher reliability for HARQ-ACK feedback.

Several methods for signaling ACK feedback on/off are described. In one approach, the on/off of ACK feedback (e.g., for URLLC DL transmissions) may be configured by higher layer signaling. If ACK feedback is turned off (e.g., for URLLC DL transmission), the PUCCH resources for HARQ-ACK feedback are configured for NACK feedback only. That is, the gNB160 may transmit a parameter indicating whether to perform ACK feedback (i.e., whether to turn on or off ACK feedback) by using a higher layer signal. For example, the gNB160 may configure a parameter for indicating whether to perform ACK feedback according to the PUCCH format. Further, gNB160 may configure parameters indicating whether to perform ACK feedback according to BWP (e.g., UL BWP). Further, the gNB160 may configure parameters indicating whether to perform ACK feedback according to the serving cell. Further, the gNB160 may configure a parameter indicating whether to perform ACK feedback according to a PUCCH cell group (e.g., a primary PUCCH group and a secondary PUCCH group). Also, the UE102 may determine whether to perform ACK feedback based on the parameter.

For example, the UE102 may perform HARQ-ACK (i.e., ACK or NACK) feedback for eMBB PDSCH transmission (i.e., PDSCH transmission) with ACK feedback configured to be "on" by higher layer signals. The gNB160 may configure a first PUCCH resource for HARQ-ACK (i.e., ACK or NACK) feedback.

In the case where the ACK feedback is configured "on" by the higher layer signal, the UE102 may perform HARQ-ACK (i.e., ACK or NACK) feedback for URLLC PDSCH transmission (i.e., PDSCH transmission). The gNB160 may configure a first PUCCH resource for HARQ-ACK (i.e., ACK or NACK) feedback.

The UE102 may perform HARQ-ACK (i.e., ACK or NACK) feedback for eMBB PDSCH transmission in the event that ACK feedback is configured to be "off" by higher layer signals. The gNB160 may configure a first PUCCH resource for HARQ-ACK (i.e., ACK or NACK) feedback.

In the case where the ACK feedback is configured to be "off" by the higher layer signal, the UE102 may perform NACK feedback only for URLLC PDSCH transmissions. The gNB160 may configure the second PUCCH resource for NACK feedback only. That is, the UE102 may apply on/off of ACK feedback only for URLLC PDSCH transmissions.

Alternatively, the UE102 may perform NACK feedback only for eMBB and URLLC PDSCH transmissions (i.e., PDSCH transmissions) in the event that ACK feedback is configured to be "off" by higher layer signals. The gNB160 may configure the second PUCCH resource for NACK feedback only. That is, the UE102 may apply on/off of ACK feedback for eMBB and URLLC PDSCH transmissions.

Here, the first PUCCH resource may correspond to a PUCCH resource described in method 1 and/or 2.

In another approach, the on/off of ACK feedback for URLLC DL transmissions may be signaled in a DCI format. That is, information indicating whether to perform ACK feedback (i.e., whether to turn ACK feedback on or off) may be included in a DCI format (e.g., a DCI format used to schedule a PDSCH (i.e., PDSCH transmission)). For example, the UE102 may perform HARQ-ACK (i.e., ACK or NACK) feedback in the case that the DCI (e.g., DCI format) indicates "on" ACK feedback. The gNB160 may configure a first PUCCH resource for HARQ-ACK (i.e., ACK or NACK) feedback.

In the case where the DCI (e.g., DCI format) indicates to turn "off" ACK feedback, the UE102 may perform NACK feedback only. The gNB160 may configure the second PUCCH resource for NACK feedback only.

In one case, the URLLC PDSCH HARQ-ACK feedback timing may be indicated in the DCI by the PDSCH-to-HARQ timing indication identification field. If ACK on/off is supported, the entries for PDSCH to HARQ timing indication identification field may be divided into 2 groups, one group indicating timing for ACK feedback on and another group indicating timing for ACK feedback off. Thus, the 8 entries of the PDSCH-to-HARQ timing indication identification field may indicate only 4 different timings.

In a similar approach, the current 3-bit PDSCH-to-HARQ timing indication identification field may be divided into two parts. HARQ-ACK timing is indicated using an index of the RRC-configured timing table with only 4 entries of two bits. Another bit is used to explicitly indicate whether an ACK should be reported. If the bit is "0", no ACK is reported and only NACK is reported; if the bit is "1", both ACK and NACK should be reported.

In yet another approach, a new field of one bit length may be added to the DCI to explicitly indicate whether an ACK should be reported. If the bit is "0", no ACK is reported and only NACK is reported; if the bit is "1", both ACK and NACK should be reported.

In another case, the URLLC PDSCH HARQ-ACK feedback timing may be determined based on a predefined or configured processing schedule, and the PDSCH-to-HARQ timing indication identification field may be omitted or removed from the PDSCH scheduling DCI format for URLLC data. In this case, a new field of one bit length may be added to the DCI to explicitly indicate whether an ACK should be reported. If the bit is "0", no ACK is reported and only NACK is reported; if the bit is "1", both ACK and NACK should be reported.

In yet another approach, different DCI formats may be used to implicitly determine whether ACK feedback should be reported (i.e., on or off). For example, compact DCI without HARQ-ACK timing information means that ACK feedback is turned off. Note that in this case, the default HARQ-ACK timing is applied to NACK feedback for the scheduled URLLC PDSCH transmission. A regular DCI with a timing indication or a long DCI implies that feedback of both ACK and NACK is required. For example, the UE102 may perform HARQ-ACK (i.e., ACK or NACK) feedback in the event that regular DCI or long DCI (e.g., the first DCI format) for scheduling the PDSCH is detected. The gNB160 may configure a first PUCCH resource for HARQ-ACK (i.e., ACK or NACK) feedback.

In the case where a compact DCI (e.g., the second DCI format) for scheduling the PDSCH is detected, the UE102 may perform NACK feedback only. The gNB160 may configure the second PUCCH resource for NACK feedback only.

In another approach, it may be based onMCS setting for PDSCH transmission to determine ACK feedback on/off. For PDSCH and PUSCH with CP-OFDM, a new MCS table is introduced for URLLC, as given in table 2 below. The new MCS table has 10^-5The BEER target of (1).

The normal MCS table has a BLER target of 10%.

TABLE 2

For PDSCH scheduling, the MCS information field in the DCI has 5 bits. If DCI CRC is scrambled with new RNTI, the new MCS table is compared with 10⁵The target BLER of (a), ACK feedback can be turned off; otherwise, the conventional MCS table is used with a target BLER of 10% and ACK feedback is turned on. For DL SPS, RRC indicates whether to configure a new 64QAM table. The indication of the new MCS table for DL SPS is separate from the indication for grant based DL scheduling. Thus, if a new MCS table is configured for DL SPS transmissions, ACK feedback may be turned off; otherwise, the ACK feedback is turned on.

That is, for example, where the PDSCH transmission corresponds to an old MCS table (e.g., the first MCS table), the UE102 may perform HARQ-ACK (i.e., ACK or NACK) feedback. The gNB160 may configure a first PUCCH resource for HARQ-ACK (i.e., ACK or NACK) feedback. In the case where the PDSCH transmission corresponds to the new MCS table (e.g., the second MCS table), the UE102 may perform NACK feedback only. The gNB160 may configure the second PUCCH resource for NACK feedback only.

Further, for example, the UE102 may perform HARQ-ACK (i.e., ACK or NACK) feedback where the PDSCH transmission is indicated by a DCI format with a CRC scrambled by an old RNTI (e.g., C-RNTI). The gNB160 may configure a first PUCCH resource for HARQ-ACK (i.e., ACK or NACK) feedback. The UE102 may perform NACK feedback only in the case where the PDSCH transmission is indicated by a DCI format with a CRC scrambled by a new RNTI (e.g., a first RNTI different from the C-RNTI). The gNB160 may configure the second PUCCH resource for NACK feedback only.

Here, a new RNTI (i.e., a DCI format with a CRC scrambled by the new RNTI) may be used to identify the new MCS table. That is, the UE102 may determine the MCS table based on the detected RNTI (e.g., C-RNTI or new RNTI) (e.g., select one MCS table from more than one MCS table). Further, MCS tables (i.e., the first MCS table and the second MCS table) may be used to determine a target MCS and/or coding rate.

As described above, the UE102 may perform HARQ-ACK (ACK or NACK) feedback for eMBB PDSCH transmission even when the ACK feedback is configured to be "off. That is, the UE102 may apply on/off of ACK feedback only for URLLC PDSCH transmissions. The following description is an example of UE behavior in the case where ACK feedback is configured to be "off.

For example, eMBB PDSCH transmission and URLLC PDSCH transmission may be identified by information included in a DCI format (e.g., a DCI format used to schedule PDSCH). For example, similar to the description above, eMBB PDSCH transmission and URLLC PDSCH transmission may be identified by a value (or 1-bit information) set to the PDSCH-to-HARQ timing indication identification field.

Further, the eMBB PDSCH transmission and the URLLC PDSCH transmission may be identified by DCI formats (e.g., long DCI, compact DCI). For example, the UE102 may identify an eMBB PDSCH transmission based on detecting a long DCI format (i.e., a first DCI format). For example, based on detecting the long DCI format, the UE102 may perform HARQ-ACK (ACK or NACK) feedback for the eMBB PDSCH transmission. Further, UE102 may identify a URLLC PDSCH transmission based on detecting the compact DCI format (i.e., the second DCI format). For example, based on detecting the compact DCI format, the UE102 may perform NACK feedback only for URLLC PDSCH transmissions.

Further, the eMBB PDSCH transmission and the URLLC PDSCH transmission may be identified by an MCS table. For example, the UE102 may identify an eMBB PDSCH transmission based on an MCS table corresponding to the PDSCH transmission. For example, the UE102 may perform HARQ-ACK (ACK or NACK) feedback for eMBB PDSCH transmissions where the PDSCH transmissions correspond to the old MCS table (i.e., the first MCS table). Further, UE102 may identify a URLLC PDSCH transmission based on an MCS table corresponding to the PDSCH transmission. For example, in the case where the PDSCH transmission corresponds to the new MCS table (i.e., the second MCS table), the UE102 may perform NACK feedback only for the URLLC PDSCH transmission.

In addition, the eMBB PDSCH transmission and the URLLC PDSCH transmission may be identified by an RNTI used to scramble a CRC to be attached to the DCI format. For example, the UE102 may identify an eMBB PDSCH transmission based on detecting a DCI format with a CRC scrambled by an old RNTI (e.g., C-RNTI). For example, the UE102 may perform HARQ-ACK (ACK or NACK) feedback for eMBB PDSCH transmissions where the PDSCH transmissions are indicated by a DCI format with a CRC scrambled by an old RNTI (e.g., C-RNTI). Further, the UE102 may identify a URLLC PDSCH transmission based on detecting a DCI format with a CRC scrambled by a new RNTI (e.g., a first RNTI). For example, the UE102 may only perform NACK feedback for a URLLC PDSCH transmission where the PDSCH transmission is indicated by a DCI format with a CRC scrambled by a new RNTI (e.g., a first RNTI).

UE operations module 124 may provide information 148 to one or more receivers 120. For example, the UE operations module 124 may notify one or more receivers 120 when to receive the retransmission.

UE operations module 124 may provide information 138 to demodulator 114. For example, UE operations module 124 may inform demodulator 114 of the modulation pattern expected for transmissions from gNB 160.

UE operations module 124 may provide information 136 to decoder 108. For example, UE operations module 124 may inform decoder 108 of the encoding expected for the transmission from gNB 160.

UE operations module 124 may provide information 142 to encoder 150. Information 142 may include data to be encoded and/or instructions for encoding. For example, UE operations module 124 may instruct encoder 150 to encode transmission data 146 and/or other information 142. Other information 142 may include PDSCH HARQ-ACK information.

The encoder 150 may encode the transmission data 146 and/or other information 142 provided by the UE operations module 124. For example, encoding the data 146 and/or other information 142 may involve error detection and/or correction coding, mapping the data to space, time, and/or frequency resources for transmission, multiplexing, and/or the like. The encoder 150 may provide encoded data 152 to a modulator 154.

UE operations module 124 may provide information 144 to modulator 154. For example, UE operations module 124 may inform modulator 154 of the modulation type (e.g., constellation mapping) to be used for transmission to the gNB 160. The modulator 154 may modulate the encoded data 152 to provide one or more modulated signals 156 to one or more transmitters 158.

UE operations module 124 may provide information 140 to one or more transmitters 158. The information 140 may include instructions for one or more transmitters 158. For example, the UE operations module 124 may instruct one or more transmitters 158 when to transmit signals to the gNB 160. For example, one or more transmitters 158 may transmit during the UL subframe. One or more transmitters 158 may up-convert one or more modulated signals 156 and transmit the one or more modulated signals to one or more gnbs 160.

Each of the one or more gnbs 160 may include one or more transceivers 176, one or more demodulators 172, one or more decoders 166, one or more encoders 109, one or more modulators 113, data buffers 162, and a gNB operations module 182. For example, one or more receive paths and/or transmit paths may be implemented in the gNB 160. For convenience, only a single transceiver 176, decoder 166, demodulator 172, encoder 109, and modulator 113 are shown in the gNB160, but multiple parallel elements (e.g., multiple transceivers 176, decoders 166, demodulators 172, encoders 109, and modulators 113) may be implemented.

The transceiver 176 may include one or more receivers 178 and one or more transmitters 117. One or more receivers 178 may receive signals from UE102 using one or more antennas 180 a-n. For example, receiver 178 may receive and down-convert a signal to generate one or more received signals 174. One or more received signals 174 may be provided to a demodulator 172. One or more transmitters 117 may transmit signals to UE102 using one or more antennas 180 a-n. For example, one or more transmitters 117 may upconvert and transmit one or more modulated signals 115.

Demodulator 172 may demodulate one or more received signals 174 to produce one or more demodulated signals 170. The one or more demodulated signals 170 can be provided to a decoder 166. The gNB160 may use the decoder 166 to decode the signal. The decoder 166 may generate one or more decoded signals 164, 168. For example, the first eNB decoded signal 164 may include received payload data, which may be stored in the data buffer 162. The second eNB decoded signal 168 may include overhead data and/or control data. For example, the second eNB decoded signal 168 may provide data (e.g., PDSCH HARQ-ACK information) that the gNB operation module 182 may use to perform one or more operations.

In general, the gNB operations module 182 may enable the gNB160 to communicate with one or more UEs 102. The gNB operations module 182 may include a gNB scheduling module 194. The gNB scheduling module 194 may perform operations for ACK and NACK differentiation on PUCCH for HARQ-ACK feedback for URLLC PDSCH transmission as described herein.

The gNB operations module 182 may provide information 188 to the demodulator 172. For example, the gNB operation module 182 may inform the demodulator 172 of the modulation pattern expected for transmissions from one or more UEs 102.

The gNB operations module 182 may provide information 186 to the decoder 166. For example, the gNB operation module 182 may inform the decoder 166 of the encoding expected for the transmission from one or more UEs 102.

The gNB operation module 182 may provide the information 101 to the encoder 109. Information 101 may include data to be encoded and/or instructions for encoding. For example, the gNB operation module 182 may instruct the encoder 109 to encode the information 101, including the transmission data 105.

Encoder 109 may encode transmission data 105 and/or other information provided by gNB operations module 182 that is included in information 101. For example, encoding transmission data 105 and/or other information included in information 101 may involve error detection and/or correction coding, mapping data to spatial, time, and/or frequency resources for transmission, multiplexing, and/or the like. Encoder 109 may provide encoded data 111 to modulator 113. The transmission data 105 may include network data to be relayed to the UE 102.

The gNB operations module 182 may provide the information 103 to the modulator 113. This information 103 may include instructions for the modulator 113. For example, the gNB operation module 182 may inform the modulator 113 of one or more modulation types (e.g., constellation mapping) to be used for transmission to the UE 102. The modulator 113 may modulate the encoded data 111 to provide one or more modulated signals 115 to one or more transmitters 117.

The gNB operations module 182 may provide the information 192 to one or more transmitters 117. This information 192 may include instructions for one or more transmitters 117. For example, the gNB operation module 182 may indicate when (when) the one or more transmitters 117 are to transmit signals to the one or more UEs 102. The one or more transmitters 117 may up-convert the one or more modulated signals 115 and transmit the one or more modulated signals to the one or more UEs 102.

It should be noted that DL subframes may be transmitted from gNB160 to one or more UEs 102, and UL subframes may be transmitted from one or more UEs 102 to gNB 160. Further, the gNB160 and one or more UEs 102 may each transmit data in standard special subframes.

It should also be noted that one or more of the elements or components thereof included in one or more enbs 160 and one or more UEs 102 may be implemented in hardware. For example, one or more of these elements or components thereof may be implemented as a chip, a circuit, or a hardware component, among others. It should also be noted that one or more of the functions or methods described herein may be implemented in hardware and/or performed using hardware. For example, one or more of the methods described herein may be implemented in and/or using a chipset, Application Specific Integrated Circuit (ASIC), large scale integrated circuit (LSI), or integrated circuit, etc.

URLLC may coexist with other services (e.g., eMBB). Due to latency requirements, URLLC may have the highest priority in some approaches. Some examples of URLLC coexistence with other services are given herein (e.g., in one or more of the following figure descriptions).

Fig. 2 is an example illustrating sub-slot URLLC PDSCH and HARQ-ACK feedback within 1 subframe.

Fig. 3 shows a method of distinguishing ACK feedback from NACK feedback. In the first method (method 1), HARQ-ACK PUCCH resources are configured, but NACK and ACK are transmitted with different parameters (e.g., the number of PRBs, TxD, transmission power, etc.). In a second method (method 2), different PUCCH resources are configured for NACK and ACK feedback with different parameters.

Fig. 4 shows an example of collision of URLLC PUCCH with other UL channels for HARQ-ACK.

Fig. 5 shows an example of the URLLC PUCCH for HARQ-ACK puncturing all other channels in overlapping symbols.

Fig. 6 shows an example of URLLC PUCCH and other UL channels for HARQ-ACK transmitted simultaneously.

Fig. 7 is a diagram illustrating one example of a resource grid for downlink. The resource grid shown in fig. 7 may be used in some implementations of the systems and methods disclosed herein. More details regarding the resource grid are given in connection with fig. 1.

In fig. 7, one downlink subframe 769 may include two downlink slots 783. N is a radical of^DL _RBDownlink bandwidth configuration for serving cell, in N^RB _scIs expressed in multiples of (A), wherein N^RB _scIs the size of resource block 789 in the frequency domain, expressed as the number of subcarriers, and N^DL _symbIs the number of OFDM symbols 787 in downlink slot 783. Resource block 789 may include multiple Resource Elements (REs) 791.

For PCell, N^DL _RBIs broadcast as part of the system information. For SCell (including Licensed Assisted Access (LAA) SCell), N^DL _RBConfigured via RRC messages dedicated to the UE 102. For PDSCH mapping, the available RE 791 may be such that its index 1 satisfies 1 ≧ 1 in the subframe_{Data, start}And/or 1_{Data, end}RE 791 of more than or equal to 1.

In the downlink, an OFDM access scheme with a Cyclic Prefix (CP), which may also be referred to as CP-OFDM, may be employed. In the downlink, PDCCH, enhanced PDCCH (epdcch), PDSCH, etc. may be transmitted. A downlink radio frame may include a plurality of pairs of downlink Resource Blocks (RBs), which are also referred to as Physical Resource Blocks (PRBs). The downlink RB pair is a unit for allocating downlink radio resources defined by a predetermined bandwidth (RB bandwidth) and a slot. The downlink RB pair includes two downlink RBs consecutive in the time domain.

The downlink RB includes twelve subcarriers in the frequency domain and includes seven (for a normal CP) or six (for an extended CP) OFDM symbols in the time domain. A region defined by one subcarrier in the frequency domain and one OFDM symbol in the time domain is called a Resource Element (RE) and is uniquely identified by an index pair (k, l) in a slot, where k and 1 are indexes in the frequency domain and the time domain, respectively. Although a downlink subframe in one Component Carrier (CC) is discussed herein, a downlink subframe is defined for each CC, and the downlink subframes are substantially synchronized with each other between CCs.

Fig. 8 is a diagram illustrating one example of a resource grid for uplink. The resource grid shown in fig. 8 may be used in some implementations of the systems and methods disclosed herein. More details regarding the resource grid are given in connection with fig. 1.

In fig. 8, one uplink subframe 869 may include two uplink slots 883. N is a radical of^UL _RBUplink bandwidth configuration for serving cell, in N^RB _scIs expressed in multiples of (A), wherein N^RB _scIs the size of a resource block 889 in the frequency domain, expressed as the number of subcarriers, and N^UL _symbThe number of SC-FDMA symbols 893 in the uplink slot 883. Resource block 889 may include a plurality of Resource Elements (REs) 891.

For PCell, N^UL _RBIs broadcast as part of the system information. For SCell (including LAA SCell), N^UL _RBConfigured via RRC messages dedicated to the UE 102.

In the uplink, in addition to CP-OFDM, a single carrier frequency division multiple access (SC-FDMA) access scheme, also known as discrete Fourier transform spread OFDM (DFT-S-OFDM), may be employed. In the uplink, PUCCH, PUSCH, PRACH, etc. may be transmitted. The uplink radio frame may include a plurality of pairs of uplink resource blocks. The uplink RB pair is a unit for allocating uplink radio resources defined by a predetermined bandwidth (RB bandwidth) and slots. The uplink RB pair includes two uplink RBs consecutive in the time domain.

The uplink RB may include twelve subcarriers in the frequency domain and seven (for normal CP) or six (for extended CP) OFDM/DFT-S-OFDM symbols in the time domain. A region defined by one subcarrier in the frequency domain and one OFDM/DFT-S-OFDM symbol in the time domain is called an RE and is uniquely identified by an index pair (k, l) in a slot, where k and 1 are indexes in the frequency domain and the time domain, respectively. Although an uplink subframe in one Component Carrier (CC) is discussed herein, the uplink subframe is defined for each CC.

Fig. 9 shows an example of several parameters 901. The parameter # 1901 a may be a basic parameter (e.g., a reference parameter). For example, the RE 995a of the base parameter 901a may be defined as having a subcarrier spacing 905a of 15kHz in the frequency domain and a length of 2048Ts + CP (e.g., 160Ts or 144Ts) in the time domain (i.e., symbol length # 1903 a), where Ts represents a baseband sampling time unit defined as 1/(15000 x 2048) seconds. For the ith parameter, subcarrier spacing 905 may be equal to 15 x 2ⁱAnd the effective OFDM symbol length is 2048 x 2^-iTs. This may result in a symbol length of 2048 x 2^-iTs + CP length (e.g., 160 x 2)^-iTs or 144 x 2^-iTs). In other words, the subcarrier spacing of the (i + 1) th parameter is twice the subcarrier spacing of the (i) th parameter, and the symbol length of the (i + 1) th parameter is half the symbol length of the (i) th parameter. Fig. 9 shows four parameters, but the system may support another number of parameters. Furthermore, the system does not have to support all of the 0 th through ith parameters (I0, 1.., I).

For example, a first UL transmission on a first SPS resource as described above may be performed only on parameter #1 (e.g., 15kHz subcarrier spacing). Here, the UE102 may acquire (detect) the parameter #1 based on the synchronization signal. Further, the UE102 may receive a dedicated RRC signal including information of configuration parameter #1 (e.g., handover command). The dedicated RRC signal may be a UE-specific signal. Here, the first UL transmission on the first SPS resource may be performed on parameter #1, parameter #2 (with 30kHz subcarrier spacing), and/or parameter #3 (with 60kHz subcarrier spacing).

Further, the second UL transmission on the second SPS resource as described above may be performed only on parameter # 3. Here, for example, the UE102 may receive system information (e.g., a Master Information Block (MIB) and/or a System Information Block (SIB)) including information for configuration parameter #2 and/or parameter # 3.

Further, UE102 may receive a dedicated RRC signal including information (e.g., handover command) of configuration parameter #2 and/or parameter # 3. System information (e.g., MIB) can be transmitted on BCH (broadcast channel) and/or dedicated RRC signals. The system information (e.g., SIBs) may contain information about when to evaluate whether the UE102 is allowed to access the cell and/or define scheduling of other system information. The System Information (SIB) may include radio resource configuration information that is common to multiple UEs 102. That is, the dedicated RRC signal may include each of a plurality of parameter configurations (first, second, and/or third parameters) for each of the UL transmissions (e.g., each of the UL-SCH transmissions, each of the PUSCH transmissions). Further, the dedicated RRC signal may include each of a plurality of parameter configurations (first, second, and/or third parameters) for each of the DL transmissions (e.g., each of the PDCCH transmissions).

Fig. 10 shows an example of a subframe structure of the parameter 1001 shown in fig. 9. Consider that slot 1083 includes N^DL _Symb(or N)^UL _Symb) The slot length of the i +1 th parameter 1001 is half of the slot length of the i-th parameter 1001 for 7 symbols, and the number of slots 1083 in a subframe (e.g., 1ms) is eventually doubled. It should be noted that a radio frame may comprise 10 subframes, and the radio frame length may be equal to 10 ms.

Fig. 11 shows an example of a slot 1183 and a sub-slot 1107. If it is notSub-slot 1107 is not configured by higher layers, then UE102 and eNB/gNB 160 may use only slot 1183 as a scheduling unit. More specifically, a given transport block may be allocated to slot 1183. The UE102 and eNB/gNB 160 may use the sub-slots 1107 as well as the slots 1183 if the sub-slots 1107 are configured by higher layers. Sub-slot 1107 may include one or more OFDM symbols. The maximum number of OFDM symbols constituting the sub-slot 1107 may be N^DL _symb-1 (or N)^UL _symb-l)。

The sub-slot length may be configured by higher layer signaling. Alternatively, the sub-slot length may be indicated by a physical layer control channel (e.g., by DCI format).

Sub-slot 1107 may start from any symbol within slot 1183 unless it collides with the control channel. There may be a limit to the micro-slot length based on the limit of the starting position. For example, a length of^DL _symbSub-slot 1107 of-1 (or NULsymb-1) may start from the second symbol in slot 1183. The starting position of sub-slot 1107 may be indicated by a physical layer control channel (e.g., by DCI format). Alternatively, the starting position of the sub-slot 1107 may be derived from information of a physical layer control channel (e.g., search space index, blind decoding candidate index, frequency and/or time resource index, PRB index, control channel element aggregation level, antenna port index, etc.) on which data in the sub-slot 1107 is scheduled.

In the case of configuring the sub-slots 1107, a given transport block may be allocated to the time slot 1183, the sub-slots 1107, the aggregated sub-slots 1107, or the aggregated sub-slots 1107 and 1183. The unit may also be a unit for HARQ-ACK bit generation.

Fig. 12 shows an example of a scheduling timeline 1209. For normal DL scheduling timeline 1209a, the DL control channels are mapped to the initial portion of time slot 1283 a. The DL control channel 1211 schedules a DL shared channel 1213a in the same time slot 1283 a. HARQ-ACKs for DL shared channels 1213a (i.e., HARQ-ACKs each indicating whether a transport block in each DL shared channel 1213a was successfully detected) are reported via UL control channel 1215a in the later slot 1283 b. In this case, a given time slot 1283 may include one of a DL transmission and an UL transmission.

For normal UL scheduling timeline 1209b, DL control channel 1211b is mapped to the initial portion of time slot 1283 c. DL control channel 1211b schedules UL shared channel 1217a in last time slot 1283 d. For these cases, the associated timing (time offset) between DL time slot 1283c and UL time slot 1283d may be fixed or configured by higher layer signaling. Alternatively, it may be indicated by a physical layer control channel (e.g., a DL allocation DCI format, a UL grant DCI format, or another DCI format, such as a UE common signaling DCI format that may be monitored in a common search space).

For self-contained base DL scheduling timeline 1209c, DL control channel 1211c is mapped to the initial portion of time slot 1283 e. The DL control channel 1211c schedules the DL shared channel 1213b in the same time slot 1283 e. HARQ-ACK for DL shared channel 1213b is reported in UL control channel 1215b, which is mapped at the end portion of slot 1283 e.

For self-contained base UL scheduling timeline 1209d, DL control channel 1211d is mapped to an initial portion of time slot 1283 f. DL control channel 1211d schedules UL shared channel 1217b in the same time slot 1283 f. For these cases, time slot 1283f may include a DL portion and an UL portion, and a guard period may exist between DL transmissions and UL transmissions.

The use of the self-contained time slots may be based on the configuration of the self-contained time slots. Alternatively, the use of self-contained time slots may be based on the configuration of the sub-slots. Still alternatively, the use of self-contained slots may be based on the configuration of shortened physical channels (e.g., PDSCH, PUSCH, PUCCH, etc.).

Fig. 13 shows an example of a DL control channel monitoring region. One or more sets of PRBs may be configured for DL control channel monitoring. In other words, a control resource set is a set of PRBs in the frequency domain within which the UE102 attempts to blindly decode downlink control information, where PRBs may or may not be frequency contiguous, the UE102 may have one or more control resource sets, and one DCI message may be located in one control resource set. In the frequency domain, a PRB is a resource element size for a control channel (which may or may not include a demodulation reference signal (DM-RS)). The DL shared channel may start at a later OFDM symbol than the symbol carrying the detected DL control channel. Alternatively, the DL shared channel may start at the last OFDM symbol carrying the detected DL control channel (or at an earlier symbol than the last OFDM symbol). In other words, dynamic reuse of at least a portion of resources in a control resource set for data of the same or different UEs 102, at least in the frequency domain, may be supported.

Fig. 14 shows an example of a DL control channel comprising more than one control channel element. When the control resource set spans multiple OFDM symbols, the control channel candidates may be mapped to multiple OFDM symbols or may be mapped to a single OFDM symbol. One DL control channel element may be mapped on REs defined by a single PRB and a single OFDM symbol. DL control channel element aggregation may be performed if more than one DL control channel element is used for a single DL control channel transmission.

The number of DL control channel elements aggregated is referred to as DL control channel element aggregation level. The DL control channel element aggregation level may be 1 or 2 to an integer power. The gNB160 may inform the UE102 which control channel candidates are mapped to each subset of OFDM symbols in the control resource set. If one DL control channel is mapped to a single OFDM symbol and does not span multiple OFDM symbols, DL control channel element aggregation is performed within one OFDM symbol, i.e. multiple DL control channel elements are aggregated within one OFDM symbol. Otherwise, DL control channel elements may be aggregated in different OFDM symbols.

Fig. 15 shows an example of a UL control channel structure. The UL control channel may be mapped on REs defined by PRBs and time slots in the frequency and time domains, respectively. The UL control channel may be referred to as a long format (or just a first format). The UL control channel may be mapped on REs on a limited OFDM symbol in the time domain. This may be referred to as a short format (or just a second format). UL control channels with short formats may be mapped on REs within a single PRB. Alternatively, the UL control channel with short format may be mapped on REs within multiple PRBs. For example, a staggered mapping may be applied, i.e., the UL control channel may be mapped to every N PRBs (e.g., 5 or 10) within the system bandwidth.

Fig. 16 is a block diagram illustrating one implementation of a gNB 1660. The gNB 1660 may include a high-layer processor 1623, a DL transmitter 1625, a UL receiver 1633, and one or more antennas 1631. The DL transmitter 1625 may include a PDCCH transmitter 1627 and a PDSCH transmitter 1629. UL receiver 1633 may include PUCCH receiver 1635 and PUSCH receiver 1637.

The higher layer processor 1623 may manage the behavior of the physical layer (the behavior of the DL transmitter and UL receiver) and provide higher layer parameters to the physical layer. The higher layer processor 1623 may obtain transport blocks from the physical layer. The higher layer processor 1623 may transmit/acquire higher layer messages, such as RRC messages and MAC messages, to/from higher layers of the UE. The higher layer processor 1623 may provide transport blocks to the PDSCH transmitter and transmit parameters related to the transport blocks to the PDCCH transmitter.

DL transmitter 1625 may multiplex the downlink physical channels and downlink physical signals (including the reservation signal) and transmit them via transmit antenna 1631. The Ul receiver 1633 may receive and demultiplex the multiplexed uplink physical channel and uplink physical signal via a reception antenna 1631. The PUCCH receiver 1635 may provide UCI to the higher layer processor 1623. The PUSCH receiver 1637 may provide the received transport blocks to the higher layer processor 1623.

Fig. 17 is a block diagram illustrating one implementation of a UE 1702. UE 1702 may include a higher layer processor 1723, an UL transmitter 1751, a DL receiver 1743, and one or more antennas 1731. UL transmitter 1751 may include a PUCCH transmitter 1753 and a PUSCH transmitter 1755. DL receiver 1743 may include a PDCCH receiver 1745 and a PDSCH receiver 1747.

The higher layer processor 1723 may manage the behavior of the physical layer (the behavior of the UL transmitter and DL receiver) and provide higher layer parameters to the physical layer. The higher layer processor 1723 may obtain transport blocks from the physical layer. The upper layer processor 1723 may transmit/acquire upper layer messages, such as RRC messages and MAC messages, to/from an upper layer of the UE. The higher layer processor 1723 may provide transport blocks to the PUSCH transmitter and UCI to the PUCCH transmitter 1753.

DL receiver 1743 may receive and demultiplex the multiplexed downlink physical channels and downlink physical signals via reception antenna 1731. PDCCH receiver 1745 may provide DCI to higher layer processor 1723. PDSCH receiver 1747 may provide the received transport blocks to higher layer processor 1723.

It should be noted that the names of the physical channels described herein are examples. Other names such as "NRPDCCH, NRPDSCH, NRPUCCH, and NRPUSCH", "new generation- (G) PDCCH, GPDSCH, GPUCCH, and GPUSCH", and the like may be used.

Fig. 18 illustrates various components that may be utilized in a UE 1802. The UE1802 described in connection with fig. 18 may be implemented in accordance with the UE102 described in connection with fig. 1. The UE1802 includes a processor 1803 that controls operation of the UE 1802. The processor 1803 may also be referred to as a Central Processing Unit (CPU). Memory 1805, which may include read-only memory (ROM), random-access memory (RAM), a combination of the two, or any type of device that may store information, provides instructions 1807a and data 1809a to processor 1803. A portion of the memory 1805 may also include non-volatile random access memory (NVRAM). Instructions 1807b and data 1809b may also reside in the processor 1803. The instructions 1807b and/or data 1809b loaded into the processor 1803 may also include instructions 1807a and/or data 1809a from the memory 1805, which are loaded for execution or processing by the processor 1803. The instructions 1807b may be executable by the processor 1803 to implement the methods described above.

The UE1802 may also include a housing that houses one or more transmitters 1858 and one or more receivers 1820 to allow for the transmission and reception of data. Transmitter 1858 and receiver 1820 may be combined into one or more transceivers 1818. One or more antennas 1822a-n are attached to the housing and electrically coupled to the transceiver 1818.

The various components of the UE1802 are coupled together by a bus system 1811 (which may include a power bus, a control signal bus, and a status signal bus in addition to a data bus). However, for clarity, the various buses are illustrated in FIG. 18 as the bus system 1811. The UE1802 may also include a Digital Signal Processor (DSP)1813 for use in processing signals. The UE1802 may also include a communication interface 1815 that provides user access to the functions of the UE 1802. The UE1802 shown in fig. 18 is a functional block diagram rather than a listing of specific components.

Fig. 19 illustrates various components that may be utilized in a gNB 1960. The gNB1960 described in connection with fig. 19 may be implemented in accordance with the gNB160 described in connection with fig. 1. The gNB1960 includes a processor 1903 that controls the operation of the gNB 1960. The processor 1903 may also be referred to as a Central Processing Unit (CPU). Memory 1905, which may include Read Only Memory (ROM), Random Access Memory (RAM), a combination of the two, or any type of device that may store information, provides instructions 1907a and data 1909a to processor 1903. A portion of the memory 1905 may also include non-volatile random access memory (NVRAM). Instructions 1907b and data 1909b may also reside in the processor 1903. The instructions 1907b and/or data 1909b loaded into the processor 1903 may also include instructions 1907a and/or data 1909a from the memory 1905, which are loaded for execution or processing by the processor 1903. The instructions 1907b may be executed by the processor 1903 to implement the methods described above.

The gNB1960 may also include a housing that houses one or more transmitters 1917 and one or more receivers 1978 to allow for the transmission and reception of data. The transmitter 1917 and the receiver 1978 may be combined into one or more transceivers 1976. One or more antennas 1980a-n are attached to the housing and electrically coupled to the transceiver 1976.

The various components of the gNB1960 are coupled together by a bus system 1911 (which may include a power bus, a control signal bus, and a status signal bus in addition to a data bus). However, for clarity, the various buses are shown in FIG. 19 as bus system 1911. The gNB1960 may also include a Digital Signal Processor (DSP)1913 for processing signals. The gNB1960 may also include a communication interface 1915 that provides user access to the functionality of the gNB 1960. The gNB1960 shown in fig. 19 is a functional block diagram rather than a listing of specific components.

Fig. 20 is a block diagram illustrating one implementation of a UE 2002 in which ACK and NACK differentiation on PUCCH for HARQ-ACK feedback for URLLC PDSCH transmission may be implemented. The UE 2002 comprises transmitting means 2058, receiving means 2020 and control means 2024. The transmitting device 2058, the receiving device 2020, and the controlling device 2024 may be configured to perform one or more of the functions described in connection with fig. 1 above. Fig. 18 above shows an example of a specific device structure of fig. 20. Various other structures may be implemented to achieve one or more of the functions of fig. 1. For example, the DSP may be implemented by software.

Fig. 21 is a block diagram illustrating one implementation of a gNB 2160 in which ACK and NACK differentiation on PUCCH for HARQ-ACK feedback for URLLC PDSCH transmission may be implemented. The gNB 2160 comprises transmitting means 2123, receiving means 2178 and control means 2182. The transmitting device 2123, receiving device 2178, and control device 2182 may be configured to perform one or more of the functions described in connection with fig. 1 above. Fig. 19 above shows an example of a specific device structure of fig. 21. Various other structures may be implemented to achieve one or more of the functions of fig. 1. For example, the DSP may be implemented by software.

The term "computer-readable medium" refers to any available medium that can be accessed by a computer or processor. As used herein, the term "computer-readable medium" may represent a non-transitory and tangible computer-readable medium and/or processor-readable medium. By way of example, and not limitation, computer-readable media or processor-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer or processor. Disk and disc, as used herein, includes Compact Disc (CD), laser disc, optical disc, Digital Versatile Disc (DVD), floppy disk and

optical disks, in which disks usually reproduce data magnetically, and optical disks reproduce data optically with lasers.

It should be noted that one or more of the methods described herein may be implemented in hardware and/or performed using hardware. For example, one or more of the methods described herein may be implemented in and/or using a chipset, Application Specific Integrated Circuit (ASIC), large scale integrated circuit (LSI), or integrated circuit, etc.

Each of the methods disclosed herein includes one or more steps or actions for achieving the method. The method steps and/or actions may be interchanged with one another and/or combined into a single step without departing from the scope of the claims. In other words, unless a specific order of steps or actions is required for proper operation of the method, the order and/or use of specific steps and/or actions may be modified without departing from the scope of the claims.

It is to be understood that the claims are not limited to the precise configuration and components shown above. Various modifications, changes and variations may be made in the arrangement, operation and details of the systems, methods and apparatus described herein without departing from the scope of the claims.

The program that runs on the gNB160 or the UE102 according to the system and method is a program (a program that causes a computer to operate) that controls a CPU or the like in such a manner as to realize the functions according to the system and method. Then, the information processed in these devices is temporarily stored in the RAM while being processed. This information is then stored in various ROMs or HDDs, and is read by the CPU for modification or writing whenever necessary. As a recording medium on which the program is stored, any of a semiconductor (e.g., ROM, nonvolatile memory card, or the like), an optical storage medium (e.g., DVD, MO, MD, CD, BD, or the like), a magnetic storage medium (e.g., magnetic tape, floppy disk, or the like), and the like are possible. Further, in some cases, the functions according to the system and method described above are implemented by executing a loaded program, and in addition, the functions according to the system and method are implemented based on instructions from a program in combination with an operating system or other application programs.

Further, in the case where the program is commercially available, the program stored on the portable recording medium may be distributed, or the program may be transmitted to a server computer connected through a network such as the internet. In this case, a storage device in the server computer is also included. Further, some or all of the gNB160 and UE102 in accordance with the above-described systems and methods may be implemented as ESIs as typical integrated circuits. Each of the functional blocks of the gNB160 and the UE102 may be separately built into a chip, and some or all of the functional blocks may be integrated into a chip. Further, the technique of the integrated circuit is not limited to the LSI, and the integrated circuit for the functional block may be implemented with a dedicated circuit or a general-purpose processor. Further, if an integrated circuit technology that replaces LSI appears as the semiconductor technology advances, an integrated circuit to which the technology is applied may also be used.

Furthermore, each of the functional blocks or various features of the base station apparatus and the terminal apparatus used in each of the above-described embodiments may be implemented or executed by a circuit (typically, an integrated circuit or a plurality of integrated circuits). Circuitry designed to perform the functions described in this specification may include a general purpose processor, a Digital Signal Processor (DSP), an application specific or general purpose integrated circuit (ASIC), a Field Programmable Gate Array (FPGA), or other programmable logic device, discrete gate or transistor logic, or discrete hardware components, or a combination thereof. A general-purpose processor may be a microprocessor, or alternatively, the processor may be a conventional processor, controller, microcontroller, or state machine. The general purpose processor or each of the circuits described above may be configured by digital circuitry or may be configured by analog circuitry. Further, when a technology for making an integrated circuit that replaces a current integrated circuit appears due to the advancement of semiconductor technology, an integrated circuit produced by the technology can also be used.

As used herein, the term "and/or" should be interpreted to mean one or more items. For example, the phrase "A, B and/or C" should be interpreted to mean any of the following: a only, B only, C, A only and B (but not C), B and C (but not a), a and C (but not B), or A, B and C all. As used herein, the phrase "at least one" should be interpreted to mean one or more items. For example, the phrase "at least one of A, B and C" or the phrase "at least one of A, B or C" should be interpreted to mean any of the following: only a, only B, only C, A and B (but not C), B and C (but not a), a and C (but not B), or A, B and C. As used herein, the phrase "one or more" should be understood to refer to one or more items. For example, the phrase "A, B and one or more of C" or the phrase "A, B or one or more of C" should be interpreted to mean any of the following: only a, only B, only C, A and B (but not C), B and C (but not a), a and C (but not B), or A, B and C.

< Cross reference >

This non-provisional application claims priority from provisional application 62/716,811 filed on 8, 9, 2018, according to united states code, volume 35, section 119 (35 u.s.c. § 119), the entire contents of which are hereby incorporated by reference.

Claims (12)

1. A User Equipment (UE), comprising:

a high-level processor configured to: configuring Physical Uplink Control Channel (PUCCH) resources for ultra-reliable low latency communication (URLLC) traffic; and

transmission circuitry configured to transmit HARQ-ACK feedback for URLLC Downlink (DL) data based on the configured PUCCH resources and HARQ-ACK status.

2. The UE of claim 1, wherein a set of PUCCH resources for URLLC traffic is configured to satisfy a Negative Acknowledgement (NACK) feedback error probability, and the same PUCCH resources are used for feedback Acknowledgements (ACKs) and NACKs.

3. The UE of claim 1, wherein a PUCCH resource set for URLLC traffic is configured to meet the NACK feedback error probability, and wherein

The UE may use all of the PUCCH resources configured according to the parameter if the HARQ-ACK corresponds to NACK, and may use a part of the PUCCH resources configured according to the parameter if the HARQ-ACK corresponds to ACK.

4. The UE of claim 1, wherein a PUCCH resource set for URLLC traffic is separately configured for HARA-ACK with ACK and NACK feedback, wherein more resources are defined by parameters for NACK feedback than parameters for ACK feedback, and wherein

The UE may use the PUCCH resource configured only according to the parameter for NACK feedback if the HARQ-ACK corresponds to NACK, and

the UE may use the PUCCH resources configured only in accordance with the parameters for ACK feedback if the HARQ-ACK corresponds to an ACK.

5. The UE of claim 1, wherein a PUCCH resource for NACK has more redundancy or overhead than a PUCCH resource for ACK and may be configured with different parameters in terms of number of Physical Resource Blocks (PRBs), number of symbols in time domain, number of time domain repetitions, transmit diversity configuration, and/or transmission power.

6. The UE of claim 1, wherein the UE may be configured with only PUCCH resources for NACK feedback, and wherein

The UE may use the PUCCH resource configured according to the parameter for NACK feedback if the HARQ-ACK corresponds to NACK, and

the UE may not transmit a PUCCH corresponding to the PDSCH if the HARQ-ACK corresponds to an ACK.

7. A base station (gbb) comprising:

a high-level processor configured to: configuring, at a User Equipment (UE), Physical Uplink Control Channel (PUCCH) resources for ultra-reliable low latency communication (URLLC) traffic; and

receive circuitry configured to receive HARQ-ACK feedback for URLLC Downlink (DL) data based on the configured PUCCH resources and HARQ-ACK status.

8. The gNB of claim 7, wherein a set of PUCCH resources used for URLLC traffic is configured to satisfy a Negative Acknowledgement (NACK) feedback error probability, and the same PUCCH resources are used for feedback Acknowledgements (ACKs) and NACKs.

9. The gNB of claim 7, wherein a PUCCH resource set for URLLC traffic is configured to satisfy the NACK feedback error probability, and wherein

The UE may use all of the PUCCH resources configured according to the parameter if the HARQ-ACK corresponds to NACK, and may use a part of the PUCCH resources configured according to the parameter if the HARQ-ACK corresponds to ACK.

10. The gNB of claim 7, wherein a PUCCH resource set for URLLC traffic is separately configured for HARA-ACK with ACK and NACK feedback, wherein more resources are defined by parameters for NACK feedback than by parameters for ACK feedback, and wherein

The UE may use the PUCCH resource configured only according to the parameter for NACK feedback if the HARQ-ACK corresponds to NACK, and

the UE may use the PUCCH resources configured only in accordance with the parameters for ACK feedback if the HARQ-ACK corresponds to an ACK.

11. The gNB of claim 7, wherein a PUCCH resource for NACK has more redundancy or overhead than a PUCCH resource for ACK and can be configured with different parameters with respect to number of Physical Resource Blocks (PRBs), number of symbols in time domain, number of time domain repetitions, transmission diversity configuration, and/or transmission power.

12. The gNB of claim 7, wherein the UE is configurable only with

PUCCH resources for NACK feedback, and wherein

The UE may use the PUCCH resource configured according to the parameter for NACK feedback if the HARQ-ACK corresponds to NACK, and

the UE may not transmit a PUCCH corresponding to the PDSCH if the HARQ-ACK corresponds to an ACK.

Images