Patent Description:
The specification for desigining Release <NUM> of New Radio access technology (NR) has been completed for implementing the 5th Generation mobile communication systems (<NUM>) in the 3rd Generation Partnership Project (3GPP). NR supports Ultra Reliable and Low Latency Communication (URLLC) as well as high-speed and large capacity communication, which are basic requirements of enhanced Mobile Broadband (eMBB) (e.g., see Non-Patent Literatures (hereinafter, referred to as "NPL") <NUM> to <NUM>).

The requirements for URLLC in Release <NUM> defined by 3GPP are to achieve user plane latency of <NUM> or less each way and to achieve latency of <NUM> or less with constant reliability.

Release <NUM> NR achieves the low latency by flexibly controlling subcarrier spacings or the number of transmission symbols, and shortening Transmit Time Intervals (TTIs). In addition, highly reliable data transmission is implemented by configuring or indicating Modulation and Coding Schemes (MCSs) or Channel Quality Indicators (CQIs) to achieve a low target Block Error Rate (BLER). For example, a target error rate (or a target BLER) may be configured for a normal mode (e.g., BLER = <NUM>-<NUM>) or a high reliability mode (e.g., BLER = <NUM>-<NUM>)
<NPL> relates to short duration PUCCH. It is mentioned that separate coding and subcarrier mapping for ACK/NACK is used for URLLC and EMBB. <NPL> relates to transmitting UCI feedback on PUCCH or PUSCH and supporting URLLC. It is mentioned that UCI for eMBB may be fed back as in normal LTE while UCI for URLLC may be fed back quickly and that UCI for URLLC should not be bundled with normal UCI. <NPL> relates to PUCCH reliability and functionalities for eMBB and URLLC. Power control for PUCCH reliability and improvement of reliability of UCI with different latency requirements is discussed. <CIT> relates to transmitting uplink control information (UCI) for a plurality of communications like eMBB and URLLC. In an embodiment, the coding rate for the PUCCH format is adopted individually for each terminal and may be configured differently for eMBB and URLLC. <NPL>) relates to URLLC resource allocation for PUCCH. It is suggested to have separate configurations for URLLC and for eMBB.

Methods of transmitting uplink control information in NR have not been fully studied.

One non-limiting and exemplary embodiment facilitates providing a terminal, and a communication method each capable of appropriately transmitting uplink control information. The claims are directed towards the variation of embodiment <NUM>. The remaining implementations or embodiments are for explanatory purpose only.

It should be noted that general or specific embodiments may be implemented as a system, an apparatus, a method, an integrated circuit, a computer program, a storage medium, or any selective combination thereof.

According to an embodiment of the present disclosure, it is possible to appropriately transmit uplink control information.

Hereinafter, detailed descriptions will be given of embodiments of the present disclosure with reference to the accompanying drawings.

Cell throughput or frequency utilization efficiency is required to be maximized in use cases of eMBB in Long-Term Evolution (LTE) or NR. In such a case, a target error rate of data is generally configured to be relatively high (e.g., BLER = <NUM>-<NUM>) in the operation. This is because of the application of Hybrid Automatic Repeat Request (HARQ). For example, eMBB allows to eventually achieve highly reliable packet transmission (e.g., BLER = <NUM>-<NUM>) taking into consideration of a combining gain of some retransmissions by HARQ.

URLLC, however, is required to achieve highly reliable packet transmission (e.g., BLER = <NUM>-<NUM>) with delay of <NUM> or less. In the HARQ described above, for example, the occurance of a data transmission error causes a retransmission request, and the data is retransmitted accordingly. The delay time increases as the number of retransmissions increases, and the requirement of low latency can no longer be met in this case. Thus, in URLLC, it is conceivable to operate so as to surely transmit the data in the first transmission by the above-described high reliability mode, i.e. the mode where the target error rate of the data is configured to be relatively low (e.g., BLER = <NUM>-<NUM>), to achieve the highly reliable packet transmission without retransmissions by HARQ.

Although the configuration of a low target error rate leads to highly reliable data transmission, it requires more radio resources than the case of configuring a high target error rate. In Release <NUM> NR, the data size of URLLC is limited to <NUM> bytes, which is relatively small, and thus the configuration of the low target error rate does not cause so much influence on the resource utilization efficiency.

Release <NUM> or future URLLC, however, is expected to handle a larger data size than Release <NUM> NR and expand use cases of URLLC. In this case, the configuration of the low target error rate possibly needs a huge amount of radio resources to achieve the highly reliable packet transmission by a single transmission, and this is inefficient from the viewpoint of the resource utilization efficiency.

Thus, it is assumed to apply, for example, a high-speed HARQ retransmission control in the URLLC use cases handling a relatively large data size. The fast HARQ retransmission control is so operated that the high target error rate (e.g., BLER = <NUM>-<NUM> or BLER = <NUM>-<NUM>) is configured for the first transmission and even when an error occurs in the first transmission, the data is surely transmitted in the retransmission following the first transmission (the second transmission), for example. As described above, the fast HARQ retransmission control is effective for performing the highly reliable packet transmission with low latency while improving the resource utilization efficiency.

Focuing on HARQ transmission in downlink here, a terminal (User Equipment (UE)) transmits a response signal indicating an error detection result of downlink data (Acknowledgement/Negative Acknowledgement (ACK/NACK), or also referred to as HARQ-ACK) to a base station (e.g., eNB or gNB).

At this time, the required reliability or the latency requirement for the response signal transmission differs in accordance with the reliability, the latency requirement or the type of use cases/services (or usage scenarios) of the downlink data transmission.

Assuming the operation in URLLC that when an error occurs in the first transmission, the data can be surely transmitted in the next transmission (the retransmission), for example, the higher the target error rate of the first data transmission is, the higher reliability is required for the transmission of the response signal, i.e. the response signal transmission with a lower target error rate is required. For example, when the target error rate of the first data transmission is BLER = <NUM>-<NUM>, the required error rate for the response signal is BLER = <NUM>-<NUM> or less, and when the target error rate of the first data transmission is BLER = <NUM>-<NUM>, the required error rate for the response signal is BLER = <NUM>-<NUM> or less (see, for example, NPL <NUM>).

Incidentally, comparing eMBB and URLLC, lower latency is required for the response signal to the URLLC data transmission than the response signal to the eMBB data transmission.

In Release <NUM> NR, however, studies have not been fully carried out on the operations related to response signals with different reliability, latency requirements, or types of use cases (or services) in a feedback mechanism for the response signals from a terminal.

Further, the terminal transmits response signals to a base station using a Physical Uplink Control Channel (PUCCH). In Release <NUM> NR, however, PUCCH to achieve the reliability requirement (e.g., the error rate of BLER = <NUM>-<NUM> or less) for the response signal transmission in URLLC that allows retransmission has not been designed.

In addition, a terminal in NR is assumed to support a plurality of use cases or services (e.g., eMBB and URLLC). The terminal in NR is also assumed to support a plurality of data transmissions with different target error rates in URLLC. In this situation, the terminal possibly simultaneously transmits the response signals corresponding to the respective data transmissions with different reliability, latency requirements, or types of use cases (or services) in the same uplink slot.

In Release <NUM> NR, the number of PUCCHs that can transmit the response signals in a single slot is limited to one. Thus, the response signals are transmitted by being multiplexed in a single PUCCH if the response signals to the respective data transmissions with different reliability, latency requirements, or types of use cases (or services) are simultaneously transmitted in the same uplink slot as described above.

In a method in Release <NUM> NR, for example, when response signals with different required reliability are multiplexed, it is assumed to configure a radio resource for PUCCH according to the reliability of a response signal requiring high reliability in order to meet the requirement for the response signal requiring the high reliability. In this case, however, the radio resource for PUCCH for a response signal requiring lower reliability than the response signal requiring the high reliability (i.e., the response signal for which high reliability is not required) is configured similarly to the case of the response signal requiring the high reliability, and thus it is inefficient from the viewpoint of the resource utilization efficiency.

Further, when response signals with different required reliability are multiplexed, the response signals are arranged in a HARQ-ACK codebook (a response signal bit string) for multiplexing the response signals in order from the response signal corresponding to downlink data received earlier in time, regardless of the reliability, latency requirements, or types of use cases (or services). For example, when response signals with different latency requirements (e.g., the response signals corresponding to eMBB and URLLC) are transmitted by being multiplexed to a single PUCCH, the transmission of the response signal not requiring low latency (e.g., the response signal to eMBB) becomes a bottleneck for latency in some cases.

In this regard, an embodiment of the present disclosure will describe transmission methods for response signals with different reliability, latency requirements, or types of use cases (or services). In other words, descriptions will be given of transmission methods for response signals according to "requirements" such as reliability, latency requirements, or types of use cases (or services).

Hereinafter, each embodiment will be described in detail.

The communication system according to each embodiment of the present disclosure includes base station <NUM> and terminal <NUM>.

<FIG> is a block diagram illustrating a configuration of a part of terminal <NUM> according to each embodiment of the present disclosure. In terminal <NUM> illustrated in <FIG>, controller <NUM> determines a processing mode (e.g., a transmission method or a parameter configuration) for uplink control information (UCI; e.g., a response signal to downlink data) or an uplink control channel (e.g., PUCCH) to be used for transmission of the uplink control information according to a requirement (e.g., reliability, a latency requirement, or a type of use cases/services) for the uplink control information. Transmitter <NUM> transmits the uplink control information using the uplink control channel based on the determined processing mode.

<FIG> is a block diagram illustrating a configuration of base station <NUM> according to Embodiment <NUM> of the present disclosure. In <FIG>, base station <NUM> includes controller <NUM>, data generator <NUM>, encoder <NUM>, retransmission controller <NUM>, modulator <NUM>, higher-layer control signal generator <NUM>, encoder <NUM>, modulator <NUM>, downlink control signal generator <NUM>, encoder <NUM>, modulator <NUM>, signal assigner <NUM>, Inverse Fast Fourier Transformer (hereinafter, referred to as "IFFT") <NUM>, transmitter <NUM>, antenna <NUM>, receiver <NUM>, Fast Fourier Transformer (hereinafter, referred to as "FFT") <NUM>, extractor <NUM>, demodulator <NUM>, decoder <NUM>, and determiner <NUM>.

Controller <NUM> determines information on downlink data transmission for terminal <NUM>, and outputs the determined information to encoder <NUM>, modulator <NUM>, and signal assigner <NUM>. The information on downlink data transmission includes, for example, a coding and modulation scheme (e.g., MCS) for the downlink data to be transmitted in PDSCH, a radio resource for PDSCH (hereinafter, referred to as a "PDSCH resource"), or the like. Controller <NUM> also outputs the determined information to downlink control signal generator <NUM>.

In addition, controller <NUM> determines information on reliability, a latency requirement, or a type of use cases (or services) of downlink data for terminal <NUM> (i.e., information on a requirement for a response signal), and outputs the determined information to higher-layer control signal generator <NUM> or downlink control signal generator <NUM>. The information is indicated to terminal <NUM> (e.g., controller <NUM>).

Further, controller <NUM> also determines information on transmission of uplink control information (UCI) of terminal <NUM>, and outputs the determined information to extractor <NUM> and decoder <NUM>. Controller <NUM> also outputs the information on the transmission of UCI to higher-layer control signal generator <NUM> or downlink control signal generator <NUM>. The information on the transmission of UCI includes, for example, a transmission method or a parameter for UCI (e.g., a response signal or CSI) or PUCCH to be used for the transmission of UCI.

The information to be outputted to higher-layer control signal generator <NUM> includes, for example, information on a PUCCH resource set, information on a set of slot positions (e.g., PDSCH-to-HARQ-ACK timings) to be semi-statically configured, information on a maximum coding rate of UCI, or the like. Meanwhile, the information to be outputted to downlink control signal generator <NUM> includes, for example, information for indicating a radio resource to be actually used for PUCCH (hereinafter, referred to as a PUCCH resource) in the PUCCH resource set, information for indicating a PDSCH-to-HARQ-ACK timing to be actually used in the set of slot positions to be semi-statically configured, and the like.

In addition, controller <NUM> determines the radio resource allocation for a higher-layer control signal or a downlink control signal for transmitting downlink control information, and the radio resource allocation for downlink data. Controller <NUM> outputs the determined information to signal assigner <NUM>.

Data generator <NUM> generates the downlink data for terminal <NUM>, and outputs the data to encoder <NUM>.

Encoder <NUM> applies error correction encoding to the downlink data to be inputted from data generator <NUM> based on the information to be inputted from controller <NUM> (e.g., the information on the coding rate), and outputs the data signal after encoding to retransmnission controller <NUM>.

Retransmission controller <NUM> holds the encoded data signal to be inputted from encoder <NUM> in the first transmission, and also outputs the signal to modulator <NUM>. Further, when NACK to the transmitted data signal is inputted from determiner <NUM>, which will be described later, retransmission controller <NUM> outputs the corresponding holding data to modulator <NUM>. When ACK to the transmitted data signal is inputted from determiner <NUM>, in contrast, retransmission controller <NUM> deletes the corresponding holding data.

Modulator <NUM> modulates the data signal to be inputted from retransmission controller <NUM> based on the information to be inputted from controller <NUM> (e.g., the information on the modulation scheme), and outputs the data modulated signal to signal assigner <NUM>.

Higher-layer control signal generator <NUM> generates a control information bit string (a higher-layer control signal) using the control information to be inputted from controller <NUM>, and outputs the generated control information bit string to encoder <NUM>.

Encoder <NUM> applies error correction encoding to the control information bit string to be inputted from higher-layer control signal generator <NUM> and outputs the control signal after encoding to modulator <NUM>.

Modulator <NUM> modulates the control signal to be inputted from encoder <NUM>, and outputs the control signal after the modulation to signal assigner <NUM>.

Downlink control signal generator <NUM> generates a control information bit string (a downlink control signal; e.g., DCI) using the control information to be inputted from controller <NUM>, and outputs the generated control information bit string to encoder <NUM>. The control information is transmitted to a plurality of terminals in some cases, and thus downlink control signal generator <NUM> may generate the bit string including a terminal ID of each terminal in the control information for each terminal. Note that a scrambling sequence, which will be described later, may be used for the terminal ID.

Encoder <NUM> applies error correction encoding to the control information bit string to be inputted from downlink control signal generator <NUM>, and outputs the control signal after encoding to modulator <NUM>.

Signal assigner <NUM> maps the data signal to be inputted from modulator <NUM>, the higher-layer control signal to be inputted from modulator <NUM>, or the downlink control signal to be inputted from modulator <NUM> to a radio resource based on the information indicating the radio resource to be inputted from controller <NUM>. Signal assigner <NUM> outputs the downlink signal including the mapped signal to IFFT <NUM>.

IFFT <NUM> applies transmission waveform generation processing such as OFDM to the signal to be inputted from signal assigner <NUM>. IFFT <NUM> adds a Cyclic Prefix (CP) in the case of OFDM transmission adding a CP (not illustrated). IFFT <NUM> outputs the generated transmission waveform to transmitter <NUM>.

Transmitter <NUM> applies Radio Frequency (RF) processing such as Digital-to-Analog (D/A) conversion and up-conversion to the signal to be inputted from IFFT <NUM>, and transmits the radio signal to terminal <NUM> via antenna <NUM>.

Receiver <NUM> applies RF processing such as down-conversion or Analog-to-Digital (A/D) conversion to an uplink signal waveform received from terminal <NUM> via antenna <NUM>, and outputs the uplink signal waveform after the reception processing to FFT <NUM>.

FFT <NUM> applies FFT processing for converting a time-domain signal into a frequency-domain signal to the uplink signal waveform to be inputted from receiver <NUM>. FFT <NUM> outputs the frequency-domain signal obtained by the FFT processing to extractor <NUM>.

Extractor <NUM> extracts a radio resource component on which PUCCH has been transmitted from the signal to be inputted from FFT <NUM> based on the information to be inputted from controller <NUM> (e.g., the information on the transmission of UCI). Extractor <NUM> outputs the extracted radio resource component to demodulator <NUM>.

Demodulator <NUM> equalizes and demodulates the radio resource component corresponding to PUCCH to be inputted from extractor <NUM>, and outputs the demodulation result (the demodulation sequence) to decoder <NUM>.

Decoder <NUM> performs error correction decoding on the demodulation result to be inputted from demodulator <NUM> based on the information on the transmission of UCI to be inputted from controller <NUM> (e.g., the information on encoding of UCI), and outputs the bit sequence after decoding to determiner <NUM>.

Determiner <NUM> determines whether the response signal transmitted from terminal <NUM> indicates ACK (without error) or NACK (with error) to the transmitted data signal based on the bit sequence to be inputted from decoder <NUM>. Determiner <NUM> outputs the determination result to retransmission controller <NUM>.

<FIG> is a block diagram illustrating a configuration of terminal <NUM> according to Embodiment <NUM> of the present disclosure. In <FIG>, terminal <NUM> includes antenna <NUM>, receiver <NUM>, FFT <NUM>, extractor <NUM>, downlink control signal demodulator <NUM>, decoder <NUM>, higher-layer control signal demodulator <NUM>, decoder <NUM>, data demodulator <NUM>, decoder <NUM>, controller <NUM>, encoder <NUM>, modulator <NUM>, signal assigner <NUM>, IFFT <NUM>, and transmitter <NUM>.

Receiver <NUM> applies RF processing such as down-conversion or Analog-to-Digital (A/D) conversion to a signal waveform of a downlink signal (a data signal or a control signal) received from base station <NUM> via antenna <NUM>, and outputs the received signal (i.e., a baseband signal) obtained by the RF processing to FFT <NUM>.

FFT <NUM> applies FFT processing for converting a time-domain signal into a frequency-domain signal to the signal (the time-domain signal) to be inputted from receiver <NUM>. FFT <NUM> outputs the frequency-domain signal obtained by the FFT processing to extractor <NUM>.

Extractor <NUM> extracts a downlink control signal (e.g., DCI), a higher-layer control signal, or downlink data from the signal to be inputted from FFT <NUM> based on the control information to be inputted from controller <NUM> (e.g., information on a radio resource for the downlink data or the control signal). Extractor <NUM> outputs the downlink control signal to downlink control signal demodulator <NUM>, the higher-layer control signal to higher-layer control signal demodulator <NUM>, and the downlink data to data demodulator <NUM>.

Downlink control signal demodulator <NUM> equalizes and demodulates the downlink control signal to be inputted from extractor <NUM>, and outputs the demodulation result to decoder <NUM>.

Decoder <NUM> applies error correction decoding using the demodulation result to be inputted from downlink control signal demodulator <NUM>, and obtains control information. Decoder <NUM> then outputs the obtained control information to controller <NUM>.

Higher-layer control signal demodulator <NUM> equalizes and demodulates the higher-layer control signal to be inputted from extractor <NUM>, and outputs the demodulation result to decoder <NUM>.

Decoder <NUM> applies error correction decoding using the demodulation result to be inputted from higher-layer control signal demodulator <NUM>, and obtains control information. Decoder <NUM> then outputs the obtained control information to controller <NUM>.

Data demodulator <NUM> equalizes and demodulates the downlink data to be inputted from extractor <NUM>, and outputs the demodulation result to decoder <NUM>.

Decoder <NUM> applies error correction decoding using the demodulation result to be inputted from data demodulator <NUM>. Decoder <NUM> also applies error detection to the downlink data, and outputs the error detection result to controller <NUM>. In addition, decoder <NUM> outputs the downlink data determined to have no errors as a result of the error detection, as received data.

Controller <NUM> determines a transmission method or a parameter (e.g., MCS or a radio resource) for UCI (e.g., ACK/NACK or CSI) or PUCCH to be used for the transmission of UCI, based on the information on the transmission of UCI of terminal <NUM> included in the control information to be inputted from decoder <NUM> or decoder <NUM>. Controller <NUM> outputs the determined information to encoder <NUM>, modulator <NUM>, and signal assigner <NUM>.

Further, controller <NUM> generates a response signal (ACK/NACK) using the error detection result to be inputted from decoder <NUM>, and outputs the signal to encoder <NUM>.

Furthermore, controller <NUM> outputs the information on the radio resource for the downlink data or the control signal included in the control information to be inputted from decoder <NUM> or decoder <NUM>, to extractor <NUM>.

Encoder <NUM> applies error correction encoding to the response signal (a bit sequence of ACK/NACK) based on the information to be inputted from controller <NUM>, and outputs the response signal (the bit sequence) after encoding to modulator <NUM>. Encoder <NUM>, for example, may generate the encoded bit string by applying different encoding methods for response signals with different requirements such as reliability, latency requirements, or types of use cases (or services), as described later.

Modulator <NUM> modulates the response signal to be inputted from encoder <NUM> based on the information to be inputted from controller <NUM>, and outputs the response signal (a modulation symbol string) after the modulation to signal assigner <NUM>. When different encoding methods are applied to the encoded bit strings inputted from encoder <NUM>, for example, modulator <NUM> performs the modulation on each encoded bit string.

Signal assigner <NUM> maps the response signal (the modulation symbol string) to be inputted from modulator <NUM> to the radio resource for PUCCH to be indicated by controller <NUM>. Signal assigner <NUM> then outputs the signal including the mapped response signal to IFFT <NUM>.

IFFT <NUM> applies transmission waveform generation processing such as OFDM to the signal to be inputted from signal assigner <NUM>. IFFT <NUM> adds a Cyclic Prefix (CP) in the case of OFDM transmission adding a CP (not illustrated). Alternatively, a Discrete Fourier Transformer (DFT) may be added in a preceding stage of signal assigner <NUM> when IFFT <NUM> generates a single-carrier waveform (not illustrated). IFFT <NUM> outputs the generated transmission waveform to transmitter <NUM>.

Transmitter <NUM> applies Radio Frequency (RF) processing such as Digital-to-Analog (D/A) conversion and up-conversion to the signal to be inputted from IFFT <NUM>, and transmits the radio signal to base station <NUM> via antenna <NUM>.

Operations of base station <NUM> and terminal <NUM> that include above-mentioned configurations will be described in detail.

<FIG> illustrates the processing in base station <NUM> and terminal <NUM> according to the present embodiment.

Base station <NUM> transmits information on PUCCH to terminal <NUM> (ST101). Terminal <NUM> acquires the information on PUCCH indicated from base station <NUM> (ST102). The information on PUCCH includes, for example, information on a PUCCH resource set or information on an coding rate of PUCCH.

Base station <NUM> transmits DCI including information on downlink data to terminal <NUM> (ST103). Terminal <NUM> acquires scheduling information for the downlink data or the information on PUCCH, for example, based on the DCI to be indicated from base station <NUM> (ST104).

Base station <NUM> transmits the downlink data to terminal <NUM> (ST105). Terminal <NUM> receives the downlink data (PDSCH) based on the DCI that has been indicated from base station <NUM>, for example (ST106).

Terminal <NUM> controls the operation related to a response signal or the transmission of the response signal according to a requirement (i.e., reliability, a latency requirement, or a type of use cases/services) for the response signal (ST107). Terminal <NUM>, for example, determines a processing mode for the response signal or PUCCH according to the requirement for the response signal. In the determination of the processing mode for the response signal or PUCCH, an encoding method for the response signal, a determination method for the PUCCH resource, or a parameter related to the PUCCH transmission may be determined, for example.

Terminal <NUM> transmits UCI (including the response signal, for example) to base station <NUM> using PUCCH based on the determined operation (ST108). Base station <NUM> receives the UCI to be transmitted from terminal <NUM> (ST109).

Next, control methods of the operation related to the UCI transmission (e.g., a process in ST107 in <FIG>) in terminal <NUM> will be described in detail.

Terminal <NUM> generates HARQ-ACK bits by respectively applying different encoding methods for response signals with different reliability, latency requirements, or types of use cases (or services), i.e., response signals with different requirements.

Terminal <NUM> then multiplexes the encoded response signals to which the different encoding methods have been applied to PUCCH, and transmits the signals.

For example, terminal <NUM> respectively applies encoding processes with different coding rates for the response signals with different reliability, latency requirements, or types of use cases (or services).

For example, terminal <NUM> encodes the response signal requiring high reliability using a low coding rate (e.g., a coding rate equal to or less than a threshold), and generates a HARQ-ACK bit. The application of the low coding rate improves the reliability of the response signal.

In contrast, terminal <NUM> encodes the response signal not requiring high reliability using a high coding rate (e.g., a coding rate greater than a threshold), and generates a HARQ-ACK bit. The application of the high coding rate prevents the number of bits of the response signal from increasing, and improves the resource utilization efficiency.

The case where the reliability of the response signals is different from each other will be described as an example of causing a difference in encoding processes for the response signals. For example, in URLLC, the encoding process to be applied may be different between the response signal to downlink data with a high target error rate in the first data transmission (e.g., BLER = <NUM>-<NUM>) and the response signal to downlink data with a low target error rate in the first data transmission (e.g., BLER = <NUM>-<NUM>).

To be more specific, when the target error rate of the first data transmission is high, high reliability is required for the response signal so that the data is surely retransmitted, and thus the encoding method with a low coding rate is applied to the response signal. When the target error rate of the first data transmission is low, in contrast, errors in the data are less likely to occur and not very high reliability is required for the response signal. Thus, the encoding method with a high coding rate is applied to the response signal.

Other examples of causing a difference in the encoding processes for the response signals are the case where latency requirements of the response signals are different from each other, or the case where types of use cases (or services) of the response signals are different from each other (e.g., URLLC or eMBB).

<FIG> illustrates an example in which different encoding methods (encoding processes) are applied to the response signals for URLLC and eMBB. In <FIG>, terminal <NUM> applies encoding process <NUM> to the response signal to downlink data of eMBB (eMBB PDSCH), and applies encoding process <NUM> to the response signal to downlink data of URLLC (URLLC PDSCH).

For example, URLLC requires high reliability, and the encoding method with a low coding rate is thus applied in encoding process <NUM> for the response signal. Meanwhile, eMBB does not require high reliability compared with URLLC, and the encoding method with a high coding rate is thus applied in encoding process <NUM> for the response signal.

In <FIG>, terminal <NUM> generates a HARQ-ACK bit for each of the response signals for URLLC and eMBB by respectively applying different encoding methods. Terminal <NUM> then multiplexes the generated HARQ-ACK bits to a single PUCCH, and transmits the resultant bits to base station <NUM>.

As described above, the present embodiment enables terminal <NUM> to apply an appropriate encoding method (e.g., a coding rate) for each response signal according to the reliability, the latency requirement, or the type of use cases (or services) of the response signal. This makes it possible for each response signal to be encoded using the encoding method according to the requirement for each response signal even when the requirements of the response signals to be multiplexed to a single PUCCH are different from each other, thereby achieving the efficient PUCCH transmission from the viewpoint of the resource utilization efficiency.

Note that the application of different encoding processes for each ACK/NACK is not limited to be determined based on the reliability or the type of use cases (services) described above, and may be determined based on at least one of the reliability, the latency requirement, or the type of use cases (services), for example.

Next, descriptions will be given of mapping methods for the response signals with different reliability, latency requirements, or types of use cases (or services), i.e., response signals with different requirements, to a PUCCH resource.

For example, terminal <NUM> maps the response signals to PUCCH in order from the one requiring higher reliability, or the one requiring lower latency for the latency requirement. To be more specific, terminal <NUM> first maps the response signal requiring higher reliability or lower latency to the PUCCH resource. Terminal <NUM> then maps the response signal not requiring high reliability or low latency to the PUCCH resource.

Hereinafter, descriptions will be given as examples of mapping methods for the response signals in a Short-PUCCH (e.g., PUCCH Format <NUM>) composed of one or two symbols and a Long-PUCCH (e.g., PUCCH Format <NUM> or PUCCH Format <NUM>) composed of four or more symbols.

The following two methods (Option <NUM> and Option <NUM>) may be applied to the mapping of the response signals to the PUCCH resource in the Short PUCCH.

<FIG> illustrates an exemplary mapping of the response signals to Resource Elements (REs) in Option <NUM>.

In Option <NUM>, terminal <NUM> maps the modulated symbol sequences obtained by modulating the response signals (HARQ-ACK) to Resource Elements (REs) excluding the REs to which reference signals (RSs; e.g., Demodulation RSs (DMRSs)) are mapped, based on a "Frequency-first-time-second manner", as illustrated in <FIG>. In other words, terminal <NUM> maps the response signals in order from the frequency direction to the time direction in PUCCH.

To be more specific, in the mapping to REs, the response signal requiring high reliability or low latency (HARQ-ACK for URLLC in <FIG>) is mapped to the PUCCH resource first, and then the response signal not requiring very high reliability or very low latency (HARQ-ACK for eMBB in <FIG>) is mapped to the PUCCH resource, as described above.

In <FIG>, the HARQ-ACK for URLLC is mapped to all the REs in the first symbol composing PUCCH (except the REs to which DMRSs are mapped) and a part of the REs in the second symbol, and the HARQ-ACK for eMBB is mapped to the rest of the REs in the second symbol, according to the mapping method in Option <NUM>.

For example, the response signal requiring lower latency is mapped to the first symbol of PUCCH according to the mapping method in Option <NUM>, thereby obtaining the effect of reducing the delay in the case of Short PUCCH of two symbols.

<FIG> illustrates an exemplary mapping of the response signals to REs in Option <NUM>.

In Option <NUM>, terminal <NUM> maps the modulated symbol sequences obtained by modulating the response signals (HARQ-ACK) to REs excluding the REs to which reference signals are mapped, based on the "Frequency-first-time-second manner", as illustrated in <FIG>, as is the case with Option <NUM>. In addition, in Option <NUM>, terminal <NUM> dispersedly maps the response signals in the frequency direction in the allocated band.

To be more specific, in the mapping to REs, the response signal requiring high reliability or low latency (HARQ-ACK for URLLC in <FIG>) is mapped to the PUCCH resource first, and then the response signal not requiring very high reliability or very low latency (HARQ-ACK for eMBB in <FIG>) is mapped to the PUCCH resource, as described above. Further, in <FIG>, ACK/NACK for URLLC and ACK/NACK for eMBB are dispersedly mapped in the frequency direction.

In <FIG>, the HARQ-ACK for URLLC is mapped to all the REs in the first symbol composing PUCCH (except the REs to which DMRSs are mapped) and a part of the REs in the second symbol, and the HARQ-ACK for eMBB is mapped to the rest of the REs in the second symbol, according to the mapping method in Option <NUM>. Further, in the second symbol of PUCCH, HARQ-ACK for URLLC and HARQ-ACK for eMBB are each dispersedly mapped in the frequency direction in the assigned band of PUCCH (e.g., <NUM> Resource Blocks (REs)) in <FIG>.

According to the mapping method in Option <NUM>, the response signal requiring lower latency is mapped to the first symbol of PUCCH, as with the mapping method in Option <NUM>, thereby obtaining the effect of reducing the delay in the case of Short PUCCH of two symbols.

In addition, the mapping method in Option <NUM> allows to obtain the frequency diversity effect by mapping dispersedly in the frequency direction, thereby achieving the transmission of the higher quality response signal (i.e., the response signal with higher reliability).

The following two methods (Option <NUM> and Option <NUM>) may be applied to the mapping of the response signals to the PUCCH resource in Long PUCCH.

In Option <NUM>, a method similar to the mapping relationship between HARQ-ACK bits and CSIs (CSI Part <NUM> and CSI Part <NUM>) in PUCCH Format <NUM> or PUCCH Format <NUM> in NR (see NPL <NUM>, for example) is applied to the mapping for the response signals with different reliability, latency requirements or types of use cases (or services).

In Option <NUM>, terminal <NUM> maps the modulated symbol sequences obtained by modulating the response signals (HARQ-ACK) to REs excluding the REs to which RSs (DMRSs in <FIG>) are mapped, based on the "Frequency-first-time-second manner", as illustrated in <FIG>. In addition, as illustrated in <FIG>, terminal <NUM> maps the response signal requiring higher reliability to symbols closer to the symbol to which the reference signals (e.g., DMRSs) are mapped in PUCCH.

To be more specific, as described above, HARQ-ACK for URLLC requiring high reliability is first mapped from symbols close to the symbols to which DMRSs are mapped (the preceding and succeeding symbols) in the mapping to REs, as illustrated in <FIG>. HARQ-ACK bits for eMBB not requiring very high reliability are then mapped to the rest of the PUCCH resource, as illustrated in <FIG>.

According to the mapping method in Option <NUM>, HARQ-ACK bits requiring higher reliability are mapped to symbols with high channel estimation accuracy (symbols close to the symbols to which DMRSs are mapped). Thus, Option <NUM> makes it possible to achieve the transmission of the higher quality response signal (i.e., the response signal with higher reliability).

In Option <NUM>, terminal <NUM> maps the modulated symbol sequences obtained by modulating the response signals (HARQ-ACK) to REs excluding the REs to which RSs are mapped, based on the "Frequency-first-time-second manner", as illustrated in <FIG>. In addition, terminal <NUM> maps the response signal requiring lower latency for the latency requirement to earlier symbols of PUCCH, as illustrated in <FIG>.

To be more specific, as described above, HARQ-ACK for URLLC requiring low latency is first mapped from the earlier symbol (e.g., the first symbol) in the mapping to REs, as illustrated in <FIG>. HARQ-ACK for eMBB not requiring very low latency is then mapped to the rest of the PUCCH resource, as illustrated in <FIG>.

According to the mapping method in Option <NUM>, the response signal requiring lower latency is mapped to the first symbol of PUCCH, thereby generating the effect of latency reduction.

The mapping methods for the response signals to the PUCCH resource have been described, thus far.

As described above, terminal <NUM> preferentially maps the response signal requiring high reliability or low latency, that is, the response signal with a strict requirement, to the PUCCH resource. This enables terminal <NUM> to preferentially map the response signal requiring higher reliability or lower latency, for example, among the response signals to be multiplexed in PUCCH, to the PUCCH resource capable of achieving the high reliability or the low latency. Thus, terminal <NUM> can transmit the response signals using the PUCCH resource suitable for the requirement for the response signals, according to the present embodiment.

Option <NUM> and Option <NUM> have described mapping methods for response signals in the Long-PUCCH using four or more symbols. However, in URLLC, for example, it is undesirable to use the Long-PUCCH from the viewpoint of latency reduction. Thus, in the present embodiment, the Short-PUCCH may be limited to be the PUCCH that allows multiplexing of the response signals with different reliability, latency requirements, or types of use cases (or services) into a single PUCCH. This makes it possible to omit designs for a plurality of PUCCH formats while meeting the requirement of low latency.

In addition, the mapping methods for the response signals to the PUCCH resource are not limited to Options <NUM> to <NUM> described above. Further, any of Options <NUM> to <NUM> may be combined with each other, for example. In Option <NUM> (see <FIG>) or Option <NUM> (see <FIG>), for example, the response signals (HARQ-ACK) may be dispersedly mapped in the frequency direction, as in Option <NUM> (see <FIG>).

Next, determination methods for the PUCCH resource in the present embodiment will be described.

NR adopts the following method for a terminal to identify the PUCCH resource for transmitting response signals to downlink data. A base station indicates a semi-static PUCCH resource set by UE-specific higher layer signaling (e.g., Radio Resource Control (RRC) singling), and indicates the PUCCH resource to be actually used in the PUCCH resource set by Downlink Control Information (DCI) for assigning the downlink data (see NPL <NUM>, for example).

Herein, the PUCCH resource is configured with a parameter composed of, for example, at least one of a symbol position in a slot, the number of symbols in a slot, a position in frequency domain, the number of resources in frequency domain (e.g., the number of RBs or Physical RBs (PRBs)), whether to apply frequency hopping, and a code resource (e.g., a cyclic shift sequence or an orthogonal cover code).

The base station can also indicate a plurality of PUCCH resource sets to the terminal. The terminal can determine which PUCCH resource set to be used among the plurality of indicated PUCCH resource sets based on the number of bits of Uplink Control Information (UCI) to be transmitted using PUCCH.

In the present embodiment, terminal <NUM> determines the PUCCH resource set based on the total number of bits of the encoded response signals (HARQ-ACK) to be multiplexed to PUCCH.

In addition, in the present embodiment, different values for the parameters relating to the determination of the PUCCH resource may be respectively configured for response signals with different reliability, latency requirements, or types of use case (or services) (i.e., response signal with different requirements).

In NR, the maximum coding rate is configured for each PUCCH format, for example. The terminal determines the number of RBs to be used for transmitting PUCCH, based on the number of bits of UCI to be transmitted using PUCCH and the maximum coding rate. Note that the maximum number of RBs to be used for transmitting PUCCH is the number of RBs for the PUCCH resource to be indicated by the PUCCH resource set described above.

In the present embodiment, the maximum coding rate is configured for each PUCCH format and for each reliability, latency requirement, or type of use cases (or services) of the response signals (i.e., for each requirement for the response signals).

For example, terminal <NUM> calculates the resource amount (e.g., the number of REs) to be used for transmitting the response signals for each of the response signals with different reliability, latency requirements or types of use cases (or services) based on the number of bits of encoded response signals and the configured maximum coding rate. Then, on the basis of the number of REs to be used for transmitting each of the response signals to be multiplexed in a single PUCCH, terminal <NUM> determines the number of RBs to be used for transmitting the PUCCH.

This enables terminal <NUM>, for example, to determine the PUCCH resource set for PUCCH where the response signals with different requirements are multiplexed, on the basis of the number of bits of the response signals encoded by the encoding method configured for each response signal, as described above. For example, terminal <NUM> can calculate an appropriate resource amount according to the reliability, the latency requirement, or the type of use cases (or services) of the response signal, thereby achieving efficient PUCCH transmission from the viewpoint of the resource utilization efficiency.

Note that the maximum number of RBs to be used for transmitting PUCCH is the number of RBs for the PUCCH resource to be indicated by the PUCCH resource set as described above. Thus, when the number of RBs determined from the number of bits of the response signal and the maximum coding rate exceeds the maximum value indicated by the PUCCH resource set, for example, the actual coding rate of the response signal exceeds the configured maximum coding rate in some cases. This case causes a possibility of failing to meet the required quality of the PUCCH transmission.

Thus, terminal <NUM> may drop a part of the response signal to be transmitted using PUCCH when the actual coding rate of the response signal exceeds a predetermined threshold, in the present embodiment. This allows the resource for the dropped part of the response signal to be used for the remaining response signal in the PUCCH resource, thereby improving the quality of the PUCCH transmission.

The threshold here may include, for example, the maximum coding rate configured for each PUCCH format and for each reliability, latency requirement or type of use cases (or services) of the response signal. Besides the maximum coding rate, a threshold for dropping a part of the response signal may also be newly indicated from base station <NUM> to terminal <NUM>.

Further, terminal <NUM> may drop at least a part of the response signal to be transmitted using PUCCH when the number of RBs calculated from the number of bits of the response signal (or UCI) to be transmitted using PUCCH and the maximum coding rate exceeds a predetermined threshold (the maximum value). This allows the resource for the dropped part of the response signal to be used for the remaining response signal in the PUCCH resource, thereby improving the quality of the PUCCH transmission.

Additionally, the response signal to be dropped may be determined according to a priority configured according to the reliability, the latency requirement or the type of use cases (or services) of the response signal (i.e., a priority configured for each requirement). For example, terminal <NUM> may preferentially transmit the response signal with a high priority requirement. In other words, terminal <NUM> may preferentially drop the response signal with a low priority requirement.

As an example of the priority, in URLLC for example, when the reliability of the response signals is different from each other, the priority of the response signal to the downlink data where the target error rate of the first data transmission is high (e.g., BLER = <NUM>-<NUM>) is configured to be higher than the priority of the response signal to the downlink data where the target error rate of the first data transmission is low (e.g., BLER = <NUM>-<NUM>). In addition, when the latency requirements or the types of use cases (or services) of the response signals are different from each other, for example, the priority of URLLC is configured to be higher than the priority of eMBB.

Terminal <NUM> may drop from the response signal with low priority when at least one of the coding rates for the response signals with different reliability, latency requirements, or types of use cases (or services) exceeds the threshold. This prevents the deterioration of the transmission quality of the response signal with high priority, that is, the response signal requiring higher reliability.

When there are response signals with different reliability, latency requirements, or types of use cases (or services), information indicating a sharing or dividing ratio of the resources (e.g., REs) in PUCCH for the response signals (e.g., a resource sharing factor or a resource splitting factor) may be indicated in advance from base station <NUM> to terminal <NUM>.

The determination methods for the PUCCH resource have been described, thus far.

As described above, in the present embodiment, terminal <NUM> determines the processing mode for the response signal or PUCCH according to the requirement (e.g., the reliability, the latency requirement, or the type of use cases/services) for the response signal to the downlink data. To be more specific, terminal <NUM> applies different encoding methods for the response signals with different requirements. Terminal <NUM> then multiplexes the encoded response signals to PUCCH, and transmits the signals.

Thus, even when the response signals with different requirements are multiplexed to PUCCH, the present embodiment enables terminal <NUM> to perform processing (e.g., encoding processing) or configuration of the radio resource (e.g., determination of the mapping method or the PUCCH resource) according to the requirements for the response signals multiplexed to PUCCH respectively. For example, terminal <NUM> can improve the resource utilization efficiency in PUCCH by configuring the position or the amount of the PUCCH resource according to the reliability required for the response signal. Further, for example, terminal <NUM> can reduce the latency of the response signal by configuring the position of the PUCCH resource according to the latency requirement for the response signal.

As described above, terminal <NUM> can appropriately transmit UCI including response signals according to the present embodiment.

A base station and a terminal according to the present embodiment have the same basic configurations as base station <NUM> and terminal <NUM> according to Embodiment <NUM>, and thus <FIG> and <FIG> will be used for the description.

In the present embodiment, terminal <NUM> applies different determination methods for PUCCH resources or PUCCH resource sets to response signals with different reliability, latency requirements, or types of use cases (or services) (i.e., response signals with different requirements).

In addition, the number of PUCCHs where terminal <NUM> can transmit the response signals in a single slot is not limited to one in the present embodiment. In other words, the number of PUCCHs where terminal <NUM> can transmit the response signals in a single slot is one or more in the present embodiment.

For example, terminal <NUM> transmits response signals with different requirements respectively using different PUCCHs in a slot. A plurality of PUCCHs are multiplexed in the same slot by Time Division Multiplexing (TDM), Frequency Division Multiplexing (FDM), or Code Division Multiplexing (CDM), for example.

This enables terminal <NUM> to allocate an appropriate PUCCH resource for each response signal according to the reliability, the latency requirement or the type of use cases (or services) of the response signal. In other words, terminal <NUM> can transmit the response signals with different requirements using separate PUCCHs without multiplexing to a single PUCCH. Thus, efficient PUCCH transmission can be achieved from the viewpoint of the resource utilization efficiency.

Further, according to the present embodiment, terminal <NUM> can transmit the response signals with different latency requirements using different PUCCHs, for example. This enables to transmit the response signal requiring low latency, such as URLLC, using a Short-PUCCH, and to transmit the response signal not requiring very low latency, such as eMBB, using a Long-PUCCH, for example, thereby eliminating the bottleneck for the latency requirement.

For example, base station <NUM> indicates semi-static PUCCH resource sets by UE-specific higher layer signaling (e.g., RRC signaling) for the identification of the PUCCH resources for transmitting the response signals to the downlink data in terminal <NUM>. Terminal <NUM> determines PUCCH resource sets based on either of the following two methods (Option <NUM> and Option <NUM>), for example.

In Option <NUM>, different groups of PUCCH resource sets are respectively configured for the response signals with different reliability, latency requirements, or types of use cases (or services) (i.e., the response signals with different requirements). Thus, terminal <NUM> respectively configures the PUCCH resource sets included in the different groups for response signals with different requirements.

<FIG> illustrates exemplary configurations of the PUCCH resource sets in Option <NUM>.

The PUCCH resource set group for eMBB (e.g., group X) and the PUCCH resource set group for URLLC (e.g., group Y) are configured in <FIG>. For example, group X includes PUCCH resource sets X0, X1, X2, and X3, and group Y includes PUCCH resource sets Y0, Y1, Y2, and Y3 in <FIG>.

Terminal <NUM> determines which PUCCH resource set in each group to be used for each of the response signals with different reliability, latency requirements, or types of use cases (or services), for example, based on the number of bits of UCI (e.g., the number of HARQ-ACK bits) to be transmitted using PUCCH.

For example, in <FIG>, terminal <NUM> selects PUCCH resource set X1 from the PUCCH resource sets in group X based on the number of bits of the response signal for eMBB. Terminal <NUM> also selects PUCCH resource set Y0 from the PUCCH resource sets in group Y based on the number of bits of the response signal for URLLC in <FIG>.

The PUCCH resource to be actually used in the selected PUCCH resource set is indicated to terminal <NUM> by DCI that assigns the downlink data corresponding to each of the response signals with different reliability, latency requirements, or types of use cases (or services) (e.g., DL assignment for eMBB or DL assignment for URLLC illustrated in <FIG>). Terminal <NUM> transmits the response signal using the PUCCH resource indicated by the DCI in the selected PUCCH resource set.

According to Option <NUM>, PUCCH resource sets are individually configured for each reliability, latency requirement, or type of use cases (or services), thereby enabling more flexible allocation of PUCCH resources suitable for response signals with different reliability, latency requirements, or types of use cases (or services).

Note that the configurations of the PUCCH resource sets illustrated in <FIG> are examples and not limited thereto. For example, the number of PUCCH resource sets included in the PUCCH resource set groups for eMBB and URLLC is not limited to four, and may include other numbers. Additionally, the number of PUCCH resource sets included in each of the PUCCH resource set groups for eMBB and URLLC may be the same or different from each other. Further, although eMBB and URLLC have been described as an example of a case of different requirements in <FIG>, the case is not limited thereto, and the PUCCH resource set groups may be configured according to at least one of different reliability and different latency requirements, for example.

In Option <NUM>, the same PUCCH resource set group is configured for the response signals with different reliability, latency requirements, or types of use cases (or services) (i.e., the response signals with different requirements). Thus, terminal <NUM> respectively configures the PUCCH resource sets included in the same group for the response signals with different requirements.

<FIG> illustrates an exemplary configuration of PUCCH resource sets in Option <NUM>.

A group including PUCCH resource sets <NUM>, <NUM>, <NUM>, and <NUM> is configured in <FIG>.

Terminal <NUM> determines which PUCCH resource set in the same group to be used based on the number of bits of UCI (e.g., the number of HARQ-ACK bits) to be transmitted using PUCCH, for example, regardless of the reliability, the latency requirements, or the types of use cases (or services).

For example, in <FIG>, terminal <NUM> selects PUCCH resource set <NUM> from PUCCH resource sets <NUM> to <NUM> based on the number of bits of the response signal for eMBB. Terminal <NUM> also selects PUCCH resource set <NUM> from PUCCH resource sets <NUM> to <NUM> based on the number of bits of the response signal for URLLC in <FIG>.

The PUCCH resource to be actually used in the selected PUCCH resource set is indicated to terminal <NUM> by DCI that assigns the downlink data corresponding to each of the response signals with different reliability, latency requirements, or types of use cases (or services) (e.g., DL assignment for eMBB or DL assignment for URLLC illustrated in <FIG>). Terminal <NUM> transmits the response signal using the PUCCH resource in the selected PUCCH resource set indicated by the DCI.

According to Option <NUM>, selectable PUCCH resource sets are the same regardless of the reliability, the latency requirements, or the types of use cases (or services). This reduces the overhead relating to the indication of the PUCCH resource sets.

Further, terminal <NUM> can individually determine the PUCCH resource set to be actually used based on each number of bits of the response signals with different reliability, latency requirements, or types of use cases (or services). This enables terminal <NUM> to use the PUCCH resource suitable for each of the response signals with different reliability, latency requirements, or types of use cases (or services).

The determination methods for the PUCCH resource set have been described, thus far.

As described above, terminal <NUM> respectively applies different resource determination methods to response signals with different requirements (e.g., reliability, latency requirements, or types of use cases/services) in the present embodiment. Terminal <NUM> then transmits the response signals using the PUCCH resources configured for the respective response signals.

Thus, the present embodiment enables terminal <NUM> to individually configure the radio resource according to the requirement for the response signal, thereby improving the resource utilization efficiency or reducing the latency of the response signal. Therefore, terminal <NUM> can appropriately transmit UCI including response signals according to the present embodiment.

The present embodiment has described methods of determining different PUCCH resources or different PUCCH resource sets for response signals with different reliability, latency requirements, or types of use cases (or services). When the same PUCCH resource is determined for each response signal based on the resource determination methods in the present embodiment, however, terminal <NUM> may apply the same processing as that in Embodiment <NUM>.

Further, Option <NUM> according to the present embodiment has described a case where different PUCCH resource set groups are configured according to the reliability, the latency requirement, or the type of use cases (or services). In addition to that, different configurable values (or value ranges) may be set for the parameters relating to the PUCCH resource set according to the reliability, the latency requirement, or the type of use cases (or services).

For example, a Sequence selection is used in PUCCH Format <NUM> in NR (see NPL <NUM>, for example). Additionally, in Release <NUM> NR, the transmission bandwidth allocatable for PUCCH transmission is <NUM> RB, and a transmission sequence with a sequence length of <NUM>, corresponding to <NUM> RB = <NUM> subcarriers, is used. Further, the frequency allocation for one cell reuse is used in NR. In the one cell reuse, the main factor of the performance deterioration is inter-cell interference. In particular, a small number of symbols (<NUM> or <NUM> symbols) are used in the Short-PUCCH, thereby failing to prevent the inter-cell interference with an averaging effect of interference by using a plurality of symbols.

Thus, when high reliability is required for a response signal, the inter-cell interference needs to be prevented. Extension of the transmission bandwidth (the sequence length) is effective as a method of preventing the inter-cell interference (see NPL <NUM>, for example).

In this regard, the number of RBs or the sequence length configurable for PUCCH may be made different, for example, according to the response signals with different reliability, latency requirements, or types of use cases (or services) in PUCCH Format <NUM>.

For example, a variable number of PRBs (e.g., any of <NUM>, <NUM>, and <NUM> PRBs) may be configured in a PUCCH resource set for a response signal requiring high reliability. Meanwhile, the configurable number of PRBs may be <NUM> PRB in a PUCCH resource set for a response signal not requiring high reliability. Note that the number of PRBs configurable for each requirement is not limited to the above examples, and may be other numbers.

This enables to prevent the inter-cell interference by expanding the transmission bandwidth (the sequence length) even when high reliability is required for a response signal in PUCCH Format <NUM>.

In addition, repeated transmission (Repetition) in time domain is an effective technique for improving characteristics for PUCCH Format <NUM>.

In this regard, the configurable number of Repetitions for PUCCH may be made different, for example, according to the response signals with different reliability, latency requirements, or types of use cases (or services) in PUCCH Format <NUM>.

For example, Repetition and a variable number of Repetitions (e.g., any of <NUM>, <NUM>, and <NUM> times) may be configured in a PUCCH resource set for a response signal requiring high reliability. Meanwhile, Repetition may not be configured in a PUCCH resource set for a response signal not requiring high reliability. Note that the number of Repetitions configurable for each requirement is not limited to the above examples, and may be other numbers.

This enables to obtain an effect of improving characteristics by performing Repetition even when high reliability is required for a response signal in PUCCH Format <NUM>.

Note that the Repetition in the time domain includes a method of repeatedly transmitting the same sequence over a plurality of symbols. In this method, in-phase combination of the Repetition signals on the receiving side (e.g., base station <NUM>) is expected to bring the effect of improving characteristics by improving the power of the received signals. The Repetition in the time domain also includes a method of extending a sequence length and transmitting a part of the extended sequence in a different symbol. For example, the sequence length is extended from <NUM> to <NUM>, the first half of the sequence length of <NUM> is transmitted in the first symbol, and the second half is transmitted in the next symbol. In this method, an effect of preventing the interference can be expected by using a long sequence length.

As described above, parameters different from those in Release <NUM> NR can be configured for a PUCCH resource set for a response signal requiring high reliability in PUCCH format <NUM>. This enables PUCCH transmission achieving a requirement relating to the reliability of the response signal in URLLC that allows retransmission (e.g., the error rate of BLER = <NUM>-<NUM> or less), which is not considered in Release <NUM> NR.

Embodiment <NUM> has described a case of applying different determination methods for PUCCH resources or PUCCH resource sets to response signals with different reliability, latency requirements, or types of use cases (or services).

NR adopts the following method for a terminal to identify the slot position of PUCCH for transmitting response signals to downlink data (or the time from a slot receiving downlink data to a slot transmitting PUCCH). A base station indicates a semi-static slot position set by UE-specific higher layer signaling (e.g., RRC singling), and indicates the slot position to be actually used in the slot position set by DCI for assigning the downlink data (see NPL <NUM>, for example).

Thus, in the variation of Embodiment <NUM>, the slot position set for PUCCH for transmitting a response signal is configured for each of the response signals with different reliability, latency requirements, or types of use cases (or services) (i.e., the response signals with different requirements).

According to the variation of Embodiment <NUM>, terminal <NUM> can use an appropriate transmission slot for the response signal according to the reliability, the latency requirement or the type of use cases (or services) of the response signal. When different slot position sets are respectively configured for different latency requirements, for example, terminal <NUM> can perform more flexible slot allocation suitable for the latency requirement for each of the response signals with different latency requirements, in a case of respectively transmitting the response signals with different latency requirements using different PUCCHs.

In the present embodiment, terminal <NUM> drops all PUCCH or punctures a part of PUCCH transmitting a response signal, according to the priority of PUCCH at the time of simultaneously transmitting response signals to data transmission with different reliability, latency requirements, or types of use cases (or services) in the same slot.

The PUCCH to be dropped or partially punctured may be determined based on the priority assigned depending on the reliability, the latency requirement, or the type of use cases (or services) of ACK/NACK.

To be more specific, when the transmission timings of the response signals with different requirements are the same, terminal <NUM> drops all or punctures a part of PUCCH whose priority based on the requirement is lower.

The case where the reliability of the response signals is different from each other will be described as an example of the priorities of PUCCH. In URLLC for example, the priority of PUCCH transmitting the response signal to the downlink data where the target error rate of the first data transmission is high (e.g., BLER = <NUM>-<NUM>) is configured to be higher than the priority of PUCCH transmitting the response signal to the downlink data where the target error rate of the first data transmission is low (e.g., BLER = <NUM>-<NUM>). That is, terminal <NUM> drops all or punctures a part of PUCCH transmitting the response signal to the downlink data where the target error rate of the first data transmission is low (e.g., BLER = <NUM>-<NUM>).

Descriptions will also be given of the case where the latency requirements or the types of use cases (or services) of the response signals are different from each other. For example, <FIG> illustrates a case including two services of URLLC and eMBB. The priority of PUCCH corresponding to URLLC is configured to be higher than the priority of PUCCH corresponding to eMBB. That is, terminal <NUM> drops all or punctures a part of PUCCH corresponding to eMBB. In <FIG>, for example, terminal <NUM> transmits the response signal corresponding to URLLC using PUCCH corresponding to URLLC (URLLC PUCCH), and drops all of PUCCH corresponding to eMBB (eMBB PUCCH).

The present embodiment enables to prevent the influence on the PUCCH transmission for a response signal requiring higher reliability or low latency by the PUCCH transmission for another response signal, thereby guaranteeing the quality of the response signal requiring higher reliability or low latency.

Note that methods of puncturing a part of PUCCH include, for example, a method of puncturing a symbol where the PUCCH transmissions of different response signals are overlapped in time with each other, or a method of puncturing an RE where the PUCCH transmissions of different response signals are overlapped in time and frequency with each other.

The method of puncturing the symbol overlapping in time can be applied, for example, when terminal <NUM> is not capable of simultaneously transmitting a plurality of uplink signals, or when terminal <NUM> has to transmit either one of a plurality of uplink signals due to the sum of the transmission power exceeding the maximum transmission power while being capable of simultaneously transmitting the plurality of uplink signals.

Meanwhile, the method of puncturing an RE overlapping in time and frequency can be applied, for example, when terminal <NUM> is capable of simultaneously transmitting a plurality of uplink signals, and the simultaneous transmission of the plurality of uplink signals does not cause an excess of the maximum transmission power of terminal <NUM>.

Embodiment <NUM> has described a case of applying different encoding processes to response signals with different reliability, latency requirements, or types of use cases (or services), for example. Performing different encoding processes, however, increases the computational complexity of a terminal, and may cause the implementation to be complicated.

Thus, the present embodiment will describe a method of applying a single encoding process to response signals with different reliability, latency requirements, or types of use cases (or services).

Terminal <NUM> has a capability relating to a processing time required for receiving downlink data, decoding the downlink data, generating a response signal, and transmitting PUCCH (UE capability, hereinafter referred to as "N1"). In NR, terminal <NUM> reports "N1" to base station <NUM>.

Base station <NUM> configures a slot position of PUCCH for terminal <NUM> to transmit a response signal to the downlink data (or the time from a slot receiving the downlink data to a slot transmitting PUCCH (e.g., the response signal): "PDSCH-to-HARQ-ACK timing"), and indicates to terminal <NUM>. At this time, base station <NUM> cannot configure and indicate a value that exceeds the processing capacity (N1) of terminal <NUM> reported by terminal <NUM> (i.e., a value smaller than N1) in terms of the PDSCH-to-HARQ-ACK timing.

In the present embodiment, terminal <NUM> defines the capability (N1) for transmission of the response signals with different reliability, latency requirements, or types of use cases (or services) respectively, and reports to base station <NUM>. Terminal <NUM> also determines a transmission method and a parameter for the response signal or PUCCH to be used for the transmission of the response signal (i.e., the processing mode for the response signal or PUCCH), based on the value of the PDSCH-to-HARQ-ACK timing configured and indicated by base station <NUM> and the defined value of N1.

For example, terminal <NUM> has two or more capabilities (N1s) according to the reliability, the latency requirements, or the types of use cases (or services) in terms of the capability relating to a processing time required for receiving downlink data, decoding the downlink data, generating a response signal, and transmitting PUCCH. Terminal <NUM> reports two or more capabilities (N1s) to base station <NUM>.

As an example, terminal <NUM> may have two UE capabilities of N1 for eMBB (hereinafter referred to as "N1_X" or "N1_eMBB"), and N1 for URLLC (hereinafter referred to as "N1_Y" or "N1_URLLC"). For example, low latency is more likely to be required in URLLC than eMBB, and thus N1 for URLLC may be configured to be less than N1 for eMBB.

As described in the variation of Embodiment <NUM>, with regard to the identification of the slot position of PUCCH for transmitting response signals to the downlink data (PDSCH-to-HARQ-ACK timing), base station <NUM> indicates a semi-static slot position set by UE-specific higher layer signaling (e.g., RRC singling), and indicates which PDSCH-to-HARQ-ACK timing in the set is actually used by DCI for assigning the downlink data.

When the response signals corresponding to the data transmission with different reliability, latency requirements, or types of use cases (or services) are simultaneously transmitted in the same slot, terminal <NUM> determines the processing for the response signals based on the value of the PDSCH-to-HARQ-ACK timing for each of the response signals and the capability (N1) of terminal <NUM>.

As illustrated in <FIG>, when the smallest value among the PDSCH-to-HARQ-ACK timing values for response signals (the PDSCH-to-HARQ-ACK timing for URLLC in <FIG>) is equal to or greater than N1 for eMBB (N1_X or N1_eMBB), for example, terminal <NUM> performs a common encoding process (joint encoding) on the response signals corresponding to eMBB and URLLC and generates HARQ-ACK bits.

To be more specific, in <FIG>, terminal <NUM> can complete the processing of generating the response signal corresponding to eMBB and transmitting PUCCH including the response signal during the time from the reception of PDSCH for URLLC until the time equivalent to the PDSCH-to-HARQ-ACK timing for URLLC elapses (i.e., N1_X/N1_eMBB ≤ PDSCH-to-HARQ-ACK timing for URLLC). Thus, terminal <NUM> can perform the common encoding process on the response signals for URLLC and eMBB during the time from the reception of PDSCH for URLLC until the time equivalent to the PDSCH-to-HARQ-ACK timing for URLLC elapses.

Meanwhile, as illustrated in <FIG>, when the value of the PDSCH-to-HARQ-ACK timing for the response signal requiring high reliability or low latency or the response signal corresponding to URLLC (PDSCH-to-HARQ-ACK timing for URLLC in <FIG>) is less than N1 corresponding to eMBB (N1_X or N1_eMBB), terminal <NUM> cannot perform a common encoding process on the response signals corresponding to eMBB and URLLC.

To be more specific, in <FIG>, terminal <NUM> cannot complete the processing of generating the response signal corresponding to eMBB and transmitting PUCCH including the response signal during the time from the reception of PDSCH for URLLC until the time equivalent to the PDSCH-to-HARQ-ACK timing for URLLC elapses (i.e., N1_X/N1_eMBB > PDSCH-to-HARQ-ACK timing for URLLC).

Thus, terminal <NUM> cannot perform joint encoding on ACK/NACK for URLLC and ACK/NACK for eMBB during the time from the reception of PDSCH for URLLC until the time equivalent to the PDSCH-to-HARQ-ACK timing for URLLC elapses. In this case, terminal <NUM> uses either of the methods in Embodiment <NUM> or Embodiment <NUM>.

For example, the application of the method in Embodiment <NUM> enables to minimize the encoding process to one as a whole for the response signals with different reliability, latency requirements, or types of use cases (or services), thereby simplifying the implementation of terminal <NUM>. Meanwhile, the application of the method in Embodiment <NUM> enables terminal <NUM> to generate HARQ-ACK bits by appropriate encoding (or coding rate) according to the reliability, the latency requirement, or the type of use cases (or service) of the response signal as illustrated in <FIG>, thereby achieving efficient PUCCH transmission from the viewpoint of the resource utilization efficiency.

As described above, according to the present embodiment, the encoding process can be shared as much as possible in accordance with the processing capability of terminal <NUM>, and it is thus possible to reduce the increase of computational complexity or complexity of the implementation of terminal <NUM>.

Each embodiment of the present disclosure has been described, thus far.

Herein, an example of causing a difference in the transmission methods and the parameters of the response signals or PUCCHs is a case where the reliability of the response signals is different from each other. For example, in URLLC, the transmission methods and the parameters of the response signals or PUCCHs may be made different from each other between the response signal to the downlink data with a high target error rate in the first data transmission (e.g., BLER = <NUM>-<NUM>) and the response signal to the downlink data with a low target error rate in the first data transmission (e.g., BLER = <NUM>-<NUM>). While the former response signal requires high reliability, the latter response signal does not require very high reliability.

Other examples of causing a difference in the transmission methods and the parameters of the response signals or PUCCHs are cases where the latency requirements or the use cases (or services) of the response signals are different from each other. For example, the transmission methods and the parameters of the response signals or PUCCHs may be made different from each other between the response signal corresponding to URLLC and the response signal corresponding to eMBB. While the former response signal requires high reliability or low latency, the latter response signal does not require not very high reliability or very low latency. Further, as described above, URLLC includes the response signal to the downlink data with a high target error rate in the first data transmission (e.g., BLER = <NUM>-<NUM>) and the response signal to the downlink data with a low target error rate in the first data transmission (e.g., BLER = <NUM>-<NUM>) in some cases.

Examples of causing a difference in the transmission methods of the response signals or PUCCHs are not limited to the cases where reliability, latency requirements, or types of use cases (services) are different, and may include, for example, cases where parameters of physical layers are different from each other. For example, eMBB may be replaced with "slot-unit transmission", and URLLC may be replaced with "non-slot-unit transmission". eMBB may also be replaced with "PDSCH mapping type A" or "PUSCH mapping type A", and URLLC may also be replaced with "PDSCH mapping type B" or "PUSCH mapping type B". In addition, the present disclosure is not limited to transmissions corresponding to eMBB and URLLC, and for example, eMBB may be replaced with transmission having a long transmission duration (e.g., a slot length or a symbol length), and URLLC may be replaced with transmission having a shorter transmission duration than the transmission duration described above.

Further, in the present disclosure, the target error rate may be the target error rate of the first data transmission as described above, or may be the target error rate of retransmission when the retransmission occurs. Additionally, the target error rate may also be referred to as an "instantaneous target error rate" in the sense of the target error rate for each of the first transmission and the retransmission.

(<NUM>) The methods for determining "the reliability, the latency requirement, or the type of use cases (or services)" (i.e., the requirement) of the response signal described in the above embodiments include, for example, the following Examples <NUM> to <NUM>.

In Example <NUM>, terminal <NUM> determines the reliability, the latency requirement, or the type of use cases (or services) of the response signal based on a UE-specific scrambling sequence to be used for DCI for scheduling the downlink data transmissions corresponding to the respective response signals.

The UE-specific scrambling sequences such as a Cell-Radio Network Temporary Identifier (C-RNTI) or a Configured Scheduling-RNTI (CS-RNTI) are used for DCI for PDSCH assuming eMBB, for example. Thus, terminal <NUM> determines that the reliability of the response signal is high, the latency requirement is severe, or it is URLLC when the detected scrambling sequence is different from C-RNTI or CS-RNTI. Meanwhile, terminal <NUM> determines that the reliability of the response signal is not high, the latency requirement is not severe, or it is eMBB when the detected scrambling sequence is C-RNTI or CS-RNTI.

For example, controller <NUM> (see <FIG>, for example) of base station <NUM> determines information on the reliability, the latency requirement, or the type of use cases (or services) of the downlink data for terminal <NUM>. The determined information is outputted to downlink control signal generator <NUM> of base station <NUM>. Downlink control signal generator <NUM> generates a bit string of DCI using a scrambling sequence according to the reliability, the latency requirement, or the type of use cases (or services) of the downlink data for terminal <NUM>, as described above.

Meanwhile, decoder <NUM> (see <FIG>, for example) of terminal <NUM> outputs the detected scrambling sequence to controller <NUM>. Controller <NUM> determines the information on the reliability, the latency requirement, or the type of use cases (or services) of the downlink data based on the acquired scrambling sequence.

In Example <NUM>, terminal <NUM> determines the reliability, the latency requirement, or the type of use cases (or services) of the response signal based on an MCS table to be used for scheduling the downlink data transmissions corresponding to the respective response signals.

In Release <NUM> NR, for example, which of the MCS tables to be used can be configured, the MCS table for achieving the target BLER = <NUM>-<NUM> or the MCS table for achieving the target BLER = <NUM>-<NUM>.

For example, terminal <NUM> determines that the response signal requires high reliability when the configured MCS table in URLLC is the MCS table for achieving the target BLER = <NUM>-<NUM>. In contrast, terminal <NUM> determines that the response signal does not require high reliability when the configured MCS table in URLLC is the MCS table for achieving the target BLER = <NUM>-<NUM>.

For example, controller <NUM> of base station <NUM> determines information on the reliability, the latency requirement, or the type of use cases (or services) of the downlink data for terminal <NUM>. The determined information is outputted to downlink control signal generator <NUM>, encoder <NUM>, and modulator <NUM> of base station <NUM>. Downlink control signal generator <NUM> includes information on the MCS table to be used for downlink data transmission in a bit string of DCI. Further, encoder <NUM> and modulator <NUM> encode and modulate the downlink data using the information on the MCS table to be inputted from controller <NUM>.

Meanwhile, decoder <NUM> of terminal <NUM> decodes DCI, and outputs the decoding result to controller <NUM>. Controller <NUM> determines the information on the reliability, the latency requirement, or the type of use cases (or services) of the downlink data, based on the information on the MCS table to be acquired from DCI.

In Example <NUM>, terminal <NUM> determines the reliability, the latency requirement, or the type of use cases (or services) of the response signal based on a "PDSCH-to-HARQ-ACK timing" or the number of transmission symbols of PDSCH, indicated by DCI for scheduling the downlink data transmissions corresponding to the respective response signals.

For example, terminal <NUM> determines that the latency requirement for the response signal is severe or the response signal is for URLLC when the PDSCH-to-HARQ-ACK timing is equal to or less than a predetermined value, or the number of transmission symbols of PDSCH is equal to or less than a predetermined number of symbols. In contrast, terminal <NUM> determines that the latency requirement for the response signal is not severe or the response signal is for eMBB when the PDSCH-to-HARQ-ACK timing is greater than the predetermined value, or the number of transmission symbols of PDSCH is more than the predetermined number of symbols.

Note that the predetermined value or the predetermined number of symbols may be a value determined in advance in a standard, or a value configurable for terminal <NUM> by base station <NUM> using higher layer signaling.

For example, controller <NUM> of base station <NUM> determines the PDSCH-to-HARQ-ACK timing indicating a slot position transmitting the response signal to the downlink data for terminal <NUM> or the number of transmission symbols of PDSCH. The determined information is outputted to downlink control signal generator <NUM>, signal assigner <NUM>, and extractor <NUM> of base station <NUM>. Downlink control signal generator <NUM> includes information on the PDSCH-to-HARQ-ACK timing or the number of transmission symbols of PDSCH in a bit string of DCI.

Meanwhile, decoder <NUM> of terminal <NUM> decodes DCI, and outputs the decoding result to controller <NUM>. Controller <NUM> determines the information on the reliability, the latency requirement, or the type of use cases (or services) of the downlink data based on the information on the PDSCH-to-HARQ-ACK timing or the number of transmission symbols of PDSCH to be acquired from DCI.

In Example <NUM>, terminal <NUM> determines the reliability, the latency requirement, or the type of use cases (or services) of the response signal based on a CQI table configured for the downlink data transmissions corresponding to the respective response signals.

In Release <NUM> NR, for example, which of the CQI tables to be used can be configured, the CQI table for achieving the target BLER = <NUM>-<NUM> or the CQI table for achieving the target BLER = <NUM>-<NUM>.

For example, terminal <NUM> determines that the response signal requires high reliability when the configured CQI table in URLLC is the CQI table for achieving the target BLER = <NUM>-<NUM>. In contrast, terminal <NUM> determines that the response signal does not require high reliability when the configured CQI table in URLLC is the CQI table for achieving the target BLER = <NUM>-<NUM>.

For example, controller <NUM> of base station <NUM> determines information on the CQI table to be configured for downlink data transmission for terminal <NUM>. The determined information is outputted to higher-layer control signal generator <NUM>. Higher-layer control signal generator <NUM> includes the information on the CQI table in a higher-layer control signal.

Meanwhile, decoder <NUM> of terminal <NUM> decodes the higher-layer control signal, and outputs the decoding result to controller <NUM>. Controller <NUM> determines the information on the reliability, the latency requirement, or the type of use cases (or services) of the downlink data, based on the information on the CQI table to be acquired from the higher-layer control signal.

In Example <NUM>, terminal <NUM> determines the reliability, the latency requirement, or the type of use cases (or services) of the response signal by explicit indication provided by several bits in DCI for scheduling the downlink data transmissions corresponding to the respective response signals.

The explicit indication may be information on the reliability, the latency requirement, or the type of use cases (services) of the response signal itself, and may also be information on the reliability (e.g., the target BLER), the latency requirement, or the type of use cases (services) of PDSCH.

For example, controller <NUM> of base station <NUM> determines information on the reliability, the latency requirement, or the type of use cases (or services) of the response signal to the downlink data for terminal <NUM>. The determined information is outputted to downlink control signal generator <NUM>. Downlink control signal generator <NUM> includes the information on the reliability, the latency requirement, or the type of use cases (or services) of the response signal in a bit string of DCI.

Meanwhile, decoder <NUM> of terminal <NUM> decodes DCI, and outputs the decoding result to controller <NUM>. Controller <NUM> acquires the information on the reliability, the latency requirement, or the type of use cases (or services) of the response signal from DCI.

The methods for determining "the reliability, the latency requirement, or the type of use cases (or services)" of the response signal have been described, thus far. Note that the methods of determining "the reliability, the latency requirement, or the type of use cases (or services) of the response signal" is not limited to Examples <NUM> to <NUM> described above, and the determination method may also be based on other information relating to the requirements.

(<NUM>) Further, the above embodiments have described the case where the response signal to the downlink data transmission is transmitted using PUCCH as an example. The UCI to be transmitted using PUCCH, however, is not limited to response signals in the present disclosure. For example, the "response signal (ACK/NACK or HARQ-ACK)" may be replaced with channel state information (CSI), or UCI including a response signal and CSI in the above embodiments.

(<NUM>) Further, the present disclosure can be realized by software, hardware, or software in cooperation with hardware. Each functional block used in the description of each embodiment described above can be partly or entirely realized by an LSI such as an integrated circuit, and each process described in the each embodiment may be controlled partly or entirely by the same LSI or a combination of LSIs. The LSI may be individually formed as chips, or one chip may be formed so as to include a part or all of the functional blocks. The LSI may include a data input and output coupled thereto. The LSI here may be referred to as an IC, a system LSI, a super LSI, or an ultra LSI depending on a difference in the degree of integration. However, the technique of implementing an integrated circuit is not limited to the LSI and may be realized by using a dedicated circuit, a general-purpose processor, or a special-purpose processor. In addition, a FPGA (Field Programmable Gate Array) that can be programmed after the manufacture of the LSI or a reconfigurable processor in which the connections and the settings of circuit cells disposed inside the LSI can be reconfigured may be used. The present disclosure can be realized as digital processing or analogue processing. If future integrated circuit technology replaces LSIs as a result of the advancement of semiconductor technology or other derivative technology, the functional blocks could be integrated using the future integrated circuit technology. Biotechnology can also be applied.

The present disclosure can be realized by any kind of apparatus, device or system having a function of communication, which is referred to as a communication apparatus. Some non-limiting examples of such a communication apparatus include a phone (e. g, cellular (cell) phone, smart phone), a tablet, a personal computer (PC) (e. g, laptop, desktop, netbook), a camera (e. g, digital still/video camera), a digital player (digital audio/video player), a wearable device (e. g, wearable camera, smart watch, tracking device), a game console, a digital book reader, a telehealth/telemedicine (remote health and medicine) device, and a vehicle providing communication functionality (e.g., automotive, airplane, ship), and various combinations thereof.

The communication apparatus is not limited to be portable or movable, and may also include any kind of apparatus, device or system being non-portable or stationary, such as a smart home device (e. g, an appliance, lighting, smart meter, control panel), a vending machine, and any other "things" in a network of an "Internet of Things (IoT)".

The communication apparatus also may include an infrastructure facility, such as a base station, an access point, and any other apparatus, device or system that communicates with or controls apparatuses such as those in the above non-limiting examples.

Claim 1:
A terminal (<NUM>), comprising:
circuitry, configured to, in operation, determine a processing mode for uplink control information or an uplink control channel to be used for transmission of the uplink control information, according to a requirement for the uplink control information; and
a transmitter (<NUM>), configured to, in operation, transmit the uplink control information using the uplink control channel based on the determined processing mode,
characterized in that
different slot position sets for transmitting the uplink control information are configured for each of the uplink control information for which the requirements are different from one another.