Base stations, communication methods, and integrated circuits

Abstract

To properly transmit uplink control information.SOLUTION: A base station includes a transmitter that transmits information indicating a first uplink control channel (PUCCH) resource set for first uplink control information having a first priority and a second PUCCH resource set for second uplink control information having a second priority, and a receiver that receives at least one of the first uplink control information and the second uplink control information, and the first uplink control information and the second uplink control information are multiplexed into one slot.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] This disclosure relates to terminals and communication methods. [Background technology]

[0002] The 3GPP (3rd Generation Partnership Project) has completed the specification development for Release 15 NR (New Radio access technology) toward the realization of 5th Generation mobile communication systems (5G). NR supports ultra-reliable and low-latency communication (URLLC) in addition to the high speed and large capacity that are fundamental requirements for enhanced mobile broadband (eMBB) (see, for example, Non-Patent Documents 1-4).

[0003] According to the requirements for URLLC in Release 15 as defined by 3GPP, it is necessary to achieve a user plane delay of 0.5 ms or less one way, while ensuring a certain level of reliability and achieving a delay of 1 ms or less.

[0004] Release 15 NR achieves low latency by flexibly controlling the subcarrier interval or the number of transmitted symbols to shorten the Transmit Time Interval (TTI). Furthermore, it achieves highly reliable data transmission by setting or notifying a Modulation and Coding Scheme (MCS) or Channel Quality Indicator (CQI) to achieve a low target block error rate (BLER). For example, the target error rate (or target BLER) is set to 10 in normal mode (e.g., BLER=10). -1 ) and high-reliability mode (for example, BLER=10 -5 ) and can be set. [Advanced Technology Documents]

Non-licensed literature

[0005] [Non-licensed document 1] 3GPP TS 38.211 V15.2.0, "NR; Physical channels and modulation (Release 15)," March 2018. [Non-licensed document 2] 3GPP TS 38.212 V15.2.0, "NR; Multiplexing and channel coding (Release 15)," June 2018. [Non-licensed document 3] 3GPP TS 38.213 V15.2.0, "NR; Physical layer procedure for control (Release 15)," June 2018.

Non-licensed Document 4

Non-licensed Document 5

Non-licensed Document 6

Summary of the Invention

Problems to be Solved by the Invention

[0006] In NR, the transmission method of uplink control information has not been sufficiently studied.

[0007] Non-limiting embodiments of the present disclosure contribute to providing a terminal and a communication method capable of appropriately transmitting uplink control information.

Means for Solving the Problems

[0008] A terminal according to an embodiment of the present disclosure includes a circuit that determines a processing mode for the uplink control information or an uplink control channel used for transmitting the uplink control information according to a requirement condition for the uplink control information, and a transmitter that transmits the uplink control information using the uplink control channel based on the determined processing mode.

[0009] A communication method according to an embodiment of the present disclosure determines a processing mode for the uplink control information or an uplink control channel used for transmitting the uplink control information according to a requirement condition for the uplink control information, and transmits the uplink control information using the uplink control channel based on the determined processing mode.

[0010] These general or specific aspects may be implemented in a system, apparatus, method, integrated circuit, computer program, or recording medium, or may be implemented in any combination of a system, apparatus, method, integrated circuit, computer program, and recording medium.

Effects of the Invention

[0011] According to an embodiment of the present disclosure, uplink control information can be properly transmitted.

[0012] Further advantages and effects in an embodiment of the present disclosure will be clarified from the specification and drawings. Such advantages and / or effects are provided by several embodiments and the features described in the specification and drawings respectively, but not necessarily all are provided in order to obtain one or more identical features.

Brief Description of Drawings

[0013] [Figure 1] Block diagram showing a part of the configuration of a terminal according to Embodiment 1 [Figure 2] Block diagram showing the configuration of a base station according to Embodiment 1 [Figure 3] Block diagram showing the configuration of a terminal according to Embodiment 1 [Figure 4] Sequence diagram showing the processing of a base station and a terminal according to Embodiment 1 [Figure 5] Diagram showing an example of ACK / NACK transmission processing according to Embodiment 1 [Figure 6] Diagram showing an example of ACK / NACK mapping according to Option 1 of Embodiment 1 [Figure 7] Diagram showing an example of ACK / NACK mapping according to Option 2 of Embodiment 1 [Figure 8] Diagram showing an example of ACK / NACK mapping according to Option 3 of Embodiment 1 [Figure 9] Diagram showing an example of ACK / NACK mapping according to Option 4 of Embodiment 1 [Figure 10A] Diagram showing an example of ACK / NACK and its transmission processing according to Option 1 of Embodiment 2 [Figure 10B] Diagram showing an example of ACK / NACK and its transmission processing according to Option 1 of Embodiment 2 [Figure 11A] Diagram showing an example of ACK / NACK and its transmission processing according to Option 2 of Embodiment 2 [Figure 11B]This figure shows an example of the ACK / NACK transmission process related to Option 2 of Embodiment 2. [Figure 12] A diagram showing an example of ACK / NACK transmission processing according to Embodiment 3. [Figure 13] A diagram showing an example of the ACK / NACK transmission process according to Embodiment 4. [Figure 14] This figure shows another example of the ACK / NACK transmission process according to Embodiment 4. [Modes for carrying out the invention]

[0014] Embodiments of this disclosure will be described in detail below with reference to the drawings.

[0015] In use cases of eMBB in LTE (Long-Term Evolution) or NR, it is necessary to maximize cell throughput or frequency utilization efficiency. In such cases, the target error rate of the data should be set to a relatively high value (e.g., BLER=10). -1 It is common to operate with this setting. This is because Hybrid Automatic Repeat Request (HARQ) is applied. eMBB, for example, takes into account the combined gain from several retransmissions by HARQ and ultimately achieves highly reliable packet transmission (e.g., BLER=10 -5 It allows for the realization of ).

[0016] On the other hand, URLLC offers highly reliable packet transmission (for example, BLER=10 -5 ) must be achieved with a delay of 1ms or less. For example, in HARQ as described above, if an error occurs in data transmission, a retransmission request is made and the data is retransmitted, so the delay time increases with the number of retransmissions, and the low-latency requirement cannot be met. Therefore, in URLLC, in order to enable highly reliable packet transmission without retransmission by HARQ, a high-reliability mode as described above (the target error rate of the data is set to a relatively low value (for example, BLER=10) is used. -5Depending on the mode set, it is possible to operate in a way that ensures reliable data transmission during the first transmission.

[0017] Setting a low target error rate leads to more reliable data transmission, but it requires more wireless resources compared to setting a high target error rate. In Release 15 NR, the URLLC data size is limited to a relatively small 32 bytes, so the impact of setting a low target error rate on resource utilization efficiency was not significant.

[0018] On the other hand, Release 16 or future URLLC versions are expected to handle larger data sizes than Release 15 NR, expanding the use cases of URLLC. In this case, setting a low target error rate may require enormous radio resources to achieve highly reliable packet transmission in a single transmission, which is inefficient from a resource utilization perspective.

[0019] Therefore, in URLLC use cases dealing with relatively large data sizes, the application of high-speed HARQ retransmission control is expected, for example. High-speed HARQ retransmission control involves, for example, a high target error rate (e.g., BLER=10) in the first transmission. -1 Or BLER=10 -2 By setting parameters such as (etc.), the system is operated in a way that ensures reliable data transmission in the next retransmission (second transmission) even if an error occurs in the first transmission. In this way, high-speed HARQ retransmission control is effective in improving resource utilization efficiency while enabling low-latency and highly reliable packet transmission.

[0020] Focusing on HARQ transmission in the downlink, the terminal (UE: User Equipment) sends a response signal (ACK / NACK: Acknowledgement / Negative Acknowledgement, or HARQ-ACK) indicating the result of error detection for the downlink data to the base station (e.g., eNB or gNB).

[0021] At this time, the reliability or delay requirement necessary for the transmission of the response signal varies depending on the reliability of the downlink data transmission, the delay requirement, or the type of use case (or service) (or usage scenario).

[0022] For example, in URLLC, assume an operation where even if an error occurs in the first transmission, the data can be surely transmitted in the next transmission (retransmission). In this case, the higher the target error rate of the first data transmission, the higher the reliability of the response signal transmission (in other words, the lower the target error rate of the response signal transmission) is required. For example, if the target error rate of the first data transmission is BLER = 10 -1 in a certain case, the response signal requires an error rate of BLER = 10 -4 in the following, and if the target error rate of the first data transmission is BLER = 10 -3 in a certain case, the response signal requires an error rate of BLER = 10 -2 in the following (for example, see Non-Patent Document 5).

[0023] Also, between eMBB and URLLC, the response signal for URLLC data transmission is required to have a lower delay compared to the response signal for eMBB data transmission.

[0024] However, in Release 15 NR, in the feedback mechanism of the response signal from the terminal, the operations regarding response signals with different reliability, delay requirements, or types of use cases (or services) have not been sufficiently studied.

[0025] Also, the terminal transmits the response signal to the base station using the physical uplink control channel (PUCCH: Physical Uplink Control Channel). However, in Release 15 NR, a PUCCH that realizes the required conditions regarding the reliability required for the transmission of the response signal (for example, an error rate of BLER = 10 -4 in the following) in URLLC that allows retransmission has not been designed.

[0026] Furthermore, NR terminals are expected to support multiple use cases or services (e.g., eMBB and URLLC). Additionally, NR terminals are expected to support multiple data transmissions with different target error rates in URLLC. In this case, it is possible that within the same slot of the uplink, a terminal may simultaneously transmit response signals corresponding to data transmissions with different reliability levels, delay requests, or use cases (or services).

[0027] In Release 15 NR, the number of PUCCHs that can transmit a response signal within a single slot is limited to one. Therefore, if response signals corresponding to data transmissions with different reliability levels, delay requests, or use cases (or services) are transmitted simultaneously within the same slot, as described above, these response signals will be multiplexed and transmitted on a single PUCCH.

[0028] For example, in the method used in Release 15 NR, when response signals with different required reliability levels are multiplexed, one might consider setting the radio resources for PUCCH to match the reliability level of the response signal requiring high reliability in order to meet the requirements of that response signal. However, in this case, the radio resources for PUCCH are set for response signals requiring lower reliability (in other words, response signals that do not require high reliability) in the same way as for the response signal requiring high reliability, which is inefficient from the standpoint of resource utilization efficiency.

[0029] Furthermore, when response signals with different required reliability levels are multiplexed, the HARQ-ACK codebook (response signal bit sequence) for multiplexing the response signals sorts them in order from the response signals corresponding to the downlink data received earlier in time, regardless of reliability level, delay requirement, or type of use case (or service). For example, when response signals with different delay requirements (e.g., response signals corresponding to eMBB and URLLC) are multiplexed and transmitted in a single PUCCH, the transmission of response signals that do not require low latency (e.g., the eMBB response signal) may become a delay bottleneck.

[0030] Therefore, in one embodiment of this disclosure, a method for transmitting response signals with different reliability levels, delay requests, or use case (or service) types will be described. In other words, a method for transmitting response signals according to "required conditions" such as reliability levels, delay requests, or use case (or service) types will be described.

[0031] The following describes each embodiment in detail.

[0032] (Embodiment 1) [Overview of the communication system] Each embodiment of the present disclosure comprises a base station 100 and a terminal 200.

[0033] Figure 1 is a block diagram showing some of the configurations of terminals 200 according to each embodiment of the present disclosure. In the terminal 200 shown in Figure 1, the control unit 211 determines a processing mode (e.g., transmission method or parameter setting, etc.) for uplink control information or an uplink control channel (e.g., PUCCH) used to transmit uplink control information, according to the requirements (e.g., reliability, delay request, or type of use case (service)) for uplink control information (UCI; e.g., response signal to downlink data). The transmission unit 216 transmits uplink control information using the uplink control channel based on the determined processing mode.

[0034] [Base station configuration] Figure 2 is a block diagram showing the configuration of a base station 100 according to Embodiment 1 of the present disclosure. In Figure 2, the base station 100 includes a control unit 101, a data generation unit 102, an encoding unit 103, a retransmission control unit 104, a modulation unit 105, a higher-level control signal generation unit 106, an encoding unit 107, a modulation unit 108, a downlink control signal generation unit 109, an encoding unit 110, a modulation unit 111, a signal allocation unit 112, an IFFT (Inverse Fast Fourier Transform) unit 113, a transmission unit 114, an antenna 115, a receiving unit 116, an FFT (Fast Fourier Transform) unit 117, an extraction unit 118, a demodulation unit 119, a decoding unit 120, and a determination unit 121.

[0035] The control unit 101 determines information regarding the transmission of downlink data from the terminal 200 and outputs the determined information to the encoding unit 103, the modulation unit 105, and the signal allocation unit 112. Information regarding downlink data transmission includes, for example, the modulation encoding method (e.g., MCS) for the downlink data transmitted in the PDSCH, or the PDSCH's radio resources (hereinafter referred to as "PDSCH resources"). The control unit 101 also outputs the determined information to the downlink control signal generation unit 109.

[0036] Furthermore, the control unit 101 determines information regarding the reliability of the downlink data of terminal 200, delay requests, or the type of use case (or service) (in other words, information regarding the requirements for the response signal), and outputs the determined information to the higher-level control signal generation unit 106 or the downlink control signal generation unit 109. This information is then notified to terminal 200 (for example, control unit 211).

[0037] Furthermore, the control unit 101 determines information regarding the transmission of uplink control information (UCI) from the terminal 200 and outputs the determined information to the extraction unit 118 and the decoding unit 120. The control unit 101 also outputs information regarding the transmission of UCI to the higher-level control signal generation unit 106 or the downlink control signal generation unit 109. Information regarding the transmission of UCI includes, for example, the UCI (e.g., response signal or CSI) or the transmission method or parameters of the PUCCH used for transmitting the UCI.

[0038] Furthermore, the information output to the higher-level control signal generation unit 106 includes, for example, information regarding the PUCCH resource set, information regarding the set of semi-statically set slot positions (e.g., PDSCH-to-HARQ-ACK timing), or information regarding the maximum coding rate of UCI. In addition, the information output to the downlink control information generation unit 109 includes, for example, information for specifying the PUCCH radio resource to be actually used within the PUCCH resource set (hereinafter referred to as PUCCH resource), and information for specifying the PDSCH-to-HARQ-ACK timing to be actually used within the set of semi-statically set slot positions.

[0039] Furthermore, the control unit 101 determines the allocation of wireless resources for the lower link control signal for transmitting upper layer control signals (upper layer control signals) or lower link control information, and for the lower link data, and outputs the determined information to the signal allocation unit 112.

[0040] The data generation unit 102 generates downlink data for the terminal 200 and outputs it to the encoding unit 103.

[0041] The encoding unit 103 performs error correction encoding on the downlink data input from the data generation unit 102 based on information input from the control unit 101 (for example, information regarding the coding rate), and outputs the encoded data signal to the retransmission control unit 104.

[0042] The retransmission control unit 104, upon initial transmission, retains the encoded data signal input from the encoding unit 103 and outputs it to the modulation unit 105. Furthermore, when the retransmission control unit 104 receives a NACK for the transmitted data signal from the determination unit 121 (described later), it outputs the corresponding retained data to the modulation unit 105. Conversely, when the retransmission control unit 104 receives an ACK for the transmitted data signal from the determination unit 121, it deletes the corresponding retained data.

[0043] The modulation unit 105 modulates the data signal input from the retransmission control unit 104 based on the information input from the control unit 101 (for example, information regarding the modulation method) and outputs the modulated data signal to the signal assignment unit 112.

[0044] The higher-level control signal generation unit 106 generates a control information bit sequence (higher-level control signal) using the control information input from the control unit 101, and outputs the generated control information bit sequence to the encoding unit 107.

[0045] The encoding unit 107 performs error correction encoding on the control information bit sequence input from the higher-level control signal generation unit 106, and outputs the encoded control signal to the modulation unit 108.

[0046] The modulation unit 108 modulates the control signal input from the encoding unit 107 and outputs the modulated control signal to the signal assignment unit 112.

[0047] The downlink control signal generation unit 109 generates a control information bit sequence (downlink control signal, e.g., DCI) using the control information input from the control unit 101, and outputs the generated control information bit sequence to the encoding unit 110. Since control information may be transmitted to multiple terminals, the downlink control signal generation unit 109 may generate a bit sequence for each terminal that includes the terminal ID of each terminal. A scrambling sequence, as described later, may be used for the terminal ID.

[0048] The encoding unit 110 performs error correction encoding on the control information bit sequence input from the downlink control signal generation unit 109, and outputs the encoded control signal to the modulation unit 111.

[0049] The modulation unit 111 modulates the control signal input from the encoding unit 110 and outputs the modulated control signal to the signal assignment unit 112.

[0050] The signal assignment unit 112 maps the data signal input from the modulation unit 105, the higher-level control signal input from the modulation unit 108, or the downlink control signal input from the modulation unit 111 to the wireless resource based on the information indicating the wireless resource input from the control unit 101. The signal assignment unit 112 outputs the downlink signal to the IFFT unit 113.

[0051] The IFFT unit 113 performs transmission waveform generation processing, such as OFDM, on the signal input from the signal assignment unit 112. In the case of OFDM transmission that adds a CP (Cyclic Prefix), the IFFT unit 113 adds the CP (not shown). The IFFT unit 113 outputs the generated transmission waveform to the transmission unit 114.

[0052] The transmitting unit 114 performs RF (Radio Frequency) processing such as D / A (Digital-to-Analog) conversion and upconversion on the signal input from the IFFT unit 113, and transmits the wireless signal to the terminal 200 via the antenna 115.

[0053] The receiving unit 116 performs RF processing, such as down-conversion or A / D (Analog-to-Digital) conversion, on the uplink signal waveform received from the terminal 200 via the antenna 115, and outputs the processed uplink signal waveform to the FFT unit 117.

[0054] The FFT unit 117 performs an FFT (Fast-Fast Transform) process on the uplink signal waveform input from the receiving unit 116 to convert the time-domain signal into a frequency-domain signal. The FFT unit 117 outputs the frequency-domain signal obtained by the FFT process to the extraction unit 118.

[0055] The extraction unit 118 extracts the radio resource component transmitted by PUCCH from the signal input from the FFT unit 117 based on the information input from the control unit 101 (for example, information regarding UCI transmission). The extraction unit 118 outputs the extracted radio resource component to the demodulation unit 119.

[0056] The demodulation unit 119 equalizes and demodulates the radio resource component corresponding to the PUCCH input from the extraction unit 118, and outputs the demodulation result (demodulated sequence) to the decoding unit 120.

[0057] The decoding unit 120 performs error correction decoding on the demodulation result input from the demodulation unit 119 based on the information regarding UCI transmission (for example, information regarding UCI encoding) input from the control unit 101, and outputs the decoded bit sequence to the determination unit 121.

[0058] The determination unit 121 determines, based on the bit sequence input from the decoding unit 120, whether the response signal transmitted from the terminal 200 indicates an ACK (error) or a NACK (no error) with respect to the transmitted data signal. The determination unit 121 outputs the determination result to the retransmission control unit 104.

[0059] [Device Configuration] Figure 3 is a block diagram showing the configuration of a terminal 200 according to Embodiment 1 of the present disclosure. In Figure 3, the terminal 200 includes an antenna 201, a receiving unit 202, an FFT unit 203, an extraction unit 204, a downlink control signal demodulation unit 205, a decoding unit 206, a higher-level control signal demodulation unit 207, a decoding unit 208, a data demodulation unit 209, a decoding unit 210, a control unit 211, an encoding unit 212, a modulation unit 213, a signal assignment unit 214, an IFFT unit 215, and a transmission unit 216.

[0060] The receiving unit 202 performs RF processing, such as down-conversion or A / D (Analog-to-Digital) conversion, on the signal waveform of the downlink signal (data signal or control signal) received from the base station 100 via the antenna 201, and outputs the resulting received signal (baseband signal) to the FFT unit 203.

[0061] The FFT unit 203 performs an FFT (Fast-Fast Transform) operation on the signal (time-domain signal) input from the receiving unit 202 to convert the time-domain signal into a frequency-domain signal. The FFT unit 203 outputs the frequency-domain signal obtained by the FFT operation to the extraction unit 204.

[0062] The extraction unit 204 extracts downlink control signals (e.g., DCI), higher-level control signals, or downlink data from the signals input from the FFT unit 203 based on control information (e.g., information regarding downlink data or wireless resources for control signals) input from the control unit 211. The extraction unit 204 outputs downlink control signals to the downlink control signal demodulation unit 205, higher-level control signals to the higher-level control signal demodulation unit 207, and downlink data to the data demodulation unit 209.

[0063] The downlink control signal demodulation unit 205 equalizes and demodulates the downlink control signal input from the extraction unit 204, and outputs the demodulation result to the decoding unit 206.

[0064] The decoding unit 206 performs error correction decoding using the demodulation result input from the downlink control signal demodulation unit 205 to obtain control information. The decoding unit 206 outputs the obtained control information to the control unit 211.

[0065] The higher-level control signal demodulation unit 207 equalizes and demodulates the higher-level control signal input from the extraction unit 204, and outputs the demodulation result to the decoding unit 208.

[0066] The decoding unit 208 performs error correction decoding using the demodulation result input from the higher-level control signal demodulation unit 207 to obtain control information. The decoding unit 208 outputs the obtained control information to the control unit 211.

[0067] The data demodulation unit 209 equalizes and demodulates the downlink data input from the extraction unit 204, and outputs the decoding result to the decoding unit 210.

[0068] The decoding unit 210 performs error correction decoding using the demodulation results input from the data demodulation unit 209. The decoding unit 210 also performs error detection on the downlink data and outputs the error detection results to the control unit 211. Furthermore, the decoding unit 210 outputs downlink data that it determines to be error-free as received data.

[0069] The control unit 211 determines the transmission method or parameters (e.g., MCS or radio resources, etc.) for the UCI (e.g., ACK / NACK or CSI) or the PUCCH used for transmitting the UCI, based on the information regarding the transmission of the terminal 200 contained in the control information input from the decoding unit 206 or decoding unit 208. The control unit 211 outputs the determined information to the encoding unit 212, the modulation unit 213, and the signal allocation unit 214.

[0070] Furthermore, the control unit 211 generates a response signal (ACK / NACK) using the error detection result input from the decoding unit 210 and outputs it to the encoding unit 212.

[0071] Furthermore, the control unit 211 outputs to the extraction unit 204 information regarding the wireless resource of the downlink data or control signal, which is included in the control information input from the decoding unit 206 or decoding unit 208.

[0072] The encoding unit 212 performs error-corrected encoding of the response signal (ACK / NACK bit sequence) based on the information input from the control unit 211, and outputs the encoded response signal (bit sequence) to the modulation unit 213. For example, as will be described later, the encoding unit 212 may generate encoded bit sequences by applying different encoding methods to response signals with different requirements such as reliability, delay requirements, or use case (or service) type.

[0073] The modulation unit 213 modulates the response signal input from the encoding unit 212 based on the information input from the control unit 211, and outputs the modulated response signal (modulation symbol sequence) to the signal assignment unit 214. For example, if the encoding unit 212 inputs encoded bit sequences to which different encoding methods are applied, the modulation unit 213 modulates each encoded bit sequence.

[0074] The signal assignment unit 214 maps the response signal (modulation symbol sequence) input from the modulation unit 213 to the PUCCH radio resource instructed by the control unit 211. The signal assignment unit 214 outputs the mapped response signal to the IFFT unit 215.

[0075] The IFFT unit 215 applies a transmission waveform generation process, such as OFDM, to the signal input from the signal assignment unit 214. In the case of OFDM transmission with added CP (Cyclic Prefix), the IFFT unit 215 adds CP (not shown). Alternatively, if the IFFT unit 215 generates a single-carrier waveform, a DFT (Discrete Fourier Transform) unit may be added before the signal assignment unit 214 (not shown). The IFFT unit 215 outputs the generated transmission waveform to the transmission unit 216.

[0076] The transmitting unit 216 performs RF (Radio Frequency) processing such as D / A (Digital-to-Analog) conversion and upconversion on the signal input from the IFFT unit 215, and transmits the radio signal to the base station 100 via the antenna 201.

[0077] [Operation of base station 100 and terminal 200] The operation of the base station 100 and terminal 200 having the above configuration will be described in detail below.

[0078] Figure 4 shows the processing flow of the base station 100 and terminal 200 according to this embodiment.

[0079] The base station 100 transmits information about PUCCH to the terminal 200 (ST101). The terminal 200 receives the information about PUCCH notified by the base station 100 (ST102). The information about PUCCH includes, for example, information about the PUCCH resource set or information about the coding rate of PUCCH.

[0080] The base station 100 transmits a DCI containing information about downlink data to the terminal 200 (ST103). The terminal 200 obtains, for example, scheduling information for downlink data or PUCCH information based on the DCI notified by the base station 100 (ST104).

[0081] The base station 100 transmits downlink data to the terminal 200 (ST105). The terminal 200 receives downlink data (PDSCH) based on, for example, the DCI notified by the base station 100 (ST106).

[0082] Terminal 200 controls the operation related to the response signal or the transmission of the response signal according to the requirements for the response signal (in other words, reliability, delay requirements, or type of use case (service)) (ST107). For example, terminal 200 determines the processing mode for the response signal or PUCCH according to the requirements for the response signal. In determining the processing mode for the response signal or PUCCH, for example, the encoding method for the response signal, the method for determining the PUCCH resource, or parameters related to PUCCH transmission may be determined.

[0083] Terminal 200 transmits a UCI (including, for example, a response signal) to base station 100 using PUCCH based on the determined action (ST108). Base station 100 receives the UCI transmitted from terminal 200 (ST109).

[0084] Next, we will explain in detail how to control the operation related to UCI transmission in terminal 200 (for example, the processing of ST107 in Figure 4).

[0085] [Encoding method] Terminal 200 generates HARQ-ACK bits by applying different encoding methods to response signals with different reliability, delay requests, or use case (or service) types (in other words, response signals with different requirements).

[0086] Then, terminal 200 multiplexes the encoded response signal, which has been encoded using a different encoding method, onto PUCCH and transmits it.

[0087] For example, terminal 200 applies different coding rates to response signals with different reliability levels, delay requests, or use case (or service) types.

[0088] For example, terminal 200 encodes a response signal requiring high reliability using a low coding rate (e.g., a coding rate below a threshold) to generate HARQ-ACK bits. By applying a low coding rate, the reliability of the response signal can be improved.

[0089] On the other hand, terminal 200 encodes response signals that do not require high reliability using a high coding rate (for example, a coding rate higher than the threshold) to generate HARQ-ACK bits. By applying a high coding rate, the increase in the number of bits in the response signal can be suppressed, improving resource utilization efficiency.

[0090] As an example of how differences in encoding processing of response signals can occur, we will explain the case where the confidence level of the response signals differs. For example, in URLLC, if the target error rate for the first data transmission is high (e.g., BLER=10), -1 ) Response signal for downlink data and low target error rate for the first data transmission (e.g., BLER=10 -5 ) A difference in encoding processing may be introduced between the response signal for downlink data and the other signal.

[0091] Specifically, if the target error rate for the first data transmission is high, a high level of reliability is required for the response signal to ensure data retransmission, and therefore a low coding rate encoding method is applied to the response signal. On the other hand, if the target error rate for the first data transmission is low, data errors are less likely to occur, so a relatively high level of reliability is not required for the response signal, and therefore a high coding rate encoding method is applied to the response signal.

[0092] Other examples that may lead to differences in the encoding process for response signals include different delay requirements for the response signals, or different types of use cases (or services) for the response signals (e.g., URLLC or eMBB).

[0093] As an example, Figure 5 shows an example where different encoding methods (encoding processes) are applied to the response signals for URLLC and eMBB. In Figure 5, terminal 200 applies encoding process 1 to the response signal for eMBB downlink data (eMBB PDSCH) and encoding process 2 to the response signal for URLLC downlink data (URLLC PDSCH).

[0094] For example, since URLLC requires high reliability, encoding process 2 for the response signal applies an encoding method with a low coding rate. On the other hand, since eMBB does not require the same high reliability as URLLC, encoding process 1 for the response signal applies an encoding method with a high coding rate.

[0095] In Figure 5, terminal 200 applies different encoding methods to the URLLC response signal and the eMBB response signal to generate HARQ-ACK bits, and multiplexes the generated HARQ-ACK bits into a single PUCCH and transmits them to base station 100.

[0096] Thus, according to this embodiment, the terminal 200 can apply an appropriate encoding method (e.g., coding rate) for each response signal according to the reliability of the response signal, the delay requirement, or the type of use case (or service). Thereby, even when the required conditions of the response signals multiplexed on one PUCCH are different, each response signal is encoded using an encoding method according to the required conditions of each response signal, so that efficient PUCCH transmission is possible from the viewpoint of resource utilization efficiency.

[0097] Note that the different encoding processes for each ACK / NACK are not limited to being determined based on the reliability or the type of use case (service) described above. For example, it may be determined based on at least one of the reliability, the delay requirement, or the type of use case (service).

[0098] [Mapping Method] Next, a method for mapping response signals (in other words, response signals with different required conditions) having different reliability, delay requirements, or types of use cases (or services) to PUCCH resources will be described.

[0099] For example, the terminal 200 maps to the PUCCH in the order of response signals that require higher reliability or in the order of response signals that require lower latency in the delay requirement. Specifically, the terminal 200 first maps the response signals that require higher reliability or lower latency to the PUCCH resources. Next, the terminal 200 maps the response signals that do not require high reliability or low latency to the PUCCH resources.

[0100] Hereinafter, as an example, the mapping methods of response signals in Short-PUCCH (e.g., PUCCH Format 2) composed of 1 or 2 symbols and Long-PUCCH (e.g., PUCCH Format 3 or PUCCH Format 4) composed of 4 or more symbols will be described respectively.

[0101] <In the case of Short PUCCH> Two methods (Option 1 and Option 2) can be applied to map the response signal to the PUCCH resource in Short PUCCH.

[0102] [Option 1] Figure 6 shows an example of mapping the response signal to the RE (Resource Element) in Option 1.

[0103] As shown in Figure 6, in Option 1, terminal 200 maps the sequence of modulated symbols after modulating the response signal (HARQ-ACK) to the Resource Elements (REs) excluding the Resource Element (RE) to which the Reference Signal (RS, e.g., DMRS: Demodulation RS) is mapped, based on the "Frequency-first-time-second format". In other words, in PUCCH, terminal 200 maps the response signal in the order from frequency to time.

[0104] Specifically, in the mapping to RE, as described above, response signals requiring high reliability or low latency (HARQ-ACK for URLLC in Figure 6) are first mapped to the PUCCH resource, followed by response signals that do not require high reliability or low latency as much (HARQ-ACK for eMBB in Figure 6) which are then mapped to the PUCCH resource.

[0105] With the mapping method of Option 1, in Figure 6, the HARQ-ACK for URLLC is mapped to all REs of the first symbol constituting PUCCH (except for the RE to which DMRS is mapped) and to some REs of the second symbol, while the HARQ-ACK for eMBB is mapped to the remaining REs of the second symbol.

[0106] According to the mapping method of Option 1, for example, response signals requiring lower latency are mapped to the first symbol of the PUCCH, thus achieving a latency reduction effect in the case of a two-symbol Short PUCCH.

[0107] [Option 2] Figure 7 shows an example of mapping the response signal to RE in Option 2.

[0108] As shown in Figure 7, in Option 2, terminal 200 maps the sequence of modulated symbols after modulating the response signal (HARQ-ACK) to REs, excluding the RE to which the reference signal is mapped, based on the "Frequency-first-time-second format" as in Option 1. Furthermore, in Option 2, terminal 200 maps the response signals so that they are distributed within the allocated bandwidth in the frequency direction.

[0109] Specifically, in the mapping to RE, as described above, response signals requiring high reliability or low latency (HARQ-ACK for URLLC in Figure 7) are first mapped to the PUCCH resource, followed by response signals that do not require high reliability or low latency as much (HARQ-ACK for eMBB in Figure 7) which are then mapped to the PUCCH resource. In addition, in Figure 7, the ACK / NACK for URLLC and the ACK / NACK corresponding to eMBB are mapped in a distributed manner in the frequency direction.

[0110] According to the mapping method of Option 2, in FIG. 7, for URLLC, the HARQ-ACK is mapped to all the REs in the first symbol constituting the PUCCH (excluding the REs to which the DMRS is mapped) and some REs in the second symbol, and for eMBB, the HARQ-ACK is mapped to the remaining REs in the second symbol. Also, in FIG. 7, in the second symbol of the PUCCH, the HARQ-ACK for URLLC and the HARQ-ACK for eMBB are mapped in a frequency-wise dispersed manner within the allocated band of the PUCCH (e.g., 4 RBs (Resource Block)).

[0111] According to the mapping method of Option 2, similar to the mapping method of Option 1, since the response signal requiring lower latency is mapped to the first symbol of the PUCCH, in the case of a 2-symbol Short PUCCH, the effect of reducing latency can be obtained.

[0112] Also, according to the mapping method of Option 2, by means of frequency-wise dispersed mapping, a frequency diversity effect can be obtained, so that transmission of a higher-quality response signal (in other words, a more reliable response signal) can be realized.

[0113] <In the case of Long PUCCH> As for the mapping of the response signal to the PUCCH resource in Long-PUCCH, the following two methods (Option 3 and Option 4) can be applied.

[0114] [Option 3] In Option 3, a method similar to the mapping relationship between the HARQ-ACK bits and CSI (CSI Part 1 and CSI Part 2) in NR's PUCCH Format 3 or PUCCH Format 4 (for example, refer to Non-Patent Document 2) is applied to the mapping for response signals with different reliability, latency requirements, or types of use cases (or services).

[0115] Figure 8 shows an example of mapping the response signal to RE in Option 3.

[0116] As shown in Figure 8, in Option 3, terminal 200 maps the modulated symbol sequence after modulating the response signal (HARQ-ACK) to REs, excluding the RE to which RS (DMRS in Figure 8) is mapped, based on the "Frequency-first-time-second format". Also, as shown in Figure 8, terminal 200 maps response signals requiring higher reliability to symbols closer to the symbols to which the reference signal (e.g., DMRS) is mapped in PUCCH.

[0117] Specifically, as shown in Figure 8, in the mapping to RE, as described above, first, the HARQ-ACK for URLLC, which requires a high level of confidence, is mapped sequentially to symbols close to the symbol to which DMRS is mapped (the symbols before and after it). Subsequently, as shown in Figure 8, the HARQ-ACK bits for eMBB, which do not require a high level of confidence, are mapped to the remaining PUCCH resources.

[0118] According to the Option 3 mapping method, the HARQ-ACK bit, which requires higher reliability, is mapped to a symbol with high channel estimation accuracy (a symbol close to the symbol to which DMRS is mapped). Therefore, Option 3 enables the transmission of higher quality response signals (in other words, higher reliability response signals).

[0119] [Option 4] Figure 9 shows an example of mapping the response signal to RE in Option 4.

[0120] As shown in Figure 9, in Option 4, terminal 200 maps the modulated symbol sequence after modulating the response signal (HARQ-ACK) to REs, excluding the RE to which RS is mapped, based on the "Frequency-first-time-second format". Also, as shown in Figure 9, terminal 200 maps response signals that require lower latency in the delay request to earlier symbols of PUCCH.

[0121] Specifically, as shown in Figure 9, in the mapping to RE, as described above, HARQ-ACKs for URLLCs, which require low latency, are first mapped to symbols with earlier timing (e.g., the first symbol). Subsequently, as shown in Figure 9, HARQ-ACKs for eMBBs, which do not require low latency as much, are mapped to the remaining PUCCH resources.

[0122] According to the Option 4 mapping method, response signals requiring lower latency are mapped to the first symbol of PUCCH, resulting in a reduction in latency.

[0123] The above explains how to map response signals to PUCCH resources.

[0124] In this way, terminal 200 preferentially maps response signals that require high reliability or low latency, that is, response signals with stringent requirements, to PUCCH resources. As a result, terminal 200 can, for example, preferentially map response signals that require higher reliability or lower latency among the response signals multiplexed to PUCCH to PUCCH resources that can achieve high reliability or low latency. Therefore, according to this embodiment, terminal 200 can transmit response signals using PUCCH resources that are suitable for the requirements of the response signals.

[0125] Option 3 and Option 4 describe methods for mapping response signals to Long-PUCCHs using four or more symbols. On the other hand, in URLLC, for example, using Long-PUCCHs is undesirable from the standpoint of reducing latency. Therefore, in this embodiment, allowing multiplexing of response signals with different reliability levels, delay requests, or use cases (or services) into a single PUCCH may be limited to Short-PUCCHs. This makes it possible to satisfy the low-latency requirement while eliminating the need to design for multiple PUCCH formats.

[0126] Furthermore, the method of mapping the response signal to the PUCCH resource is not limited to Options 1-4 described above. Alternatively, any combination of Options 1-4 may be used. For example, in Option 3 (see Figure 8) or Option 4 (see Figure 9), the response signal (HARQ-ACK) may be mapped in a frequency-dispersed manner, as in Option 2 (see Figure 7).

[0127] [How to determine PUCCH resources] Next, the method for determining the PUCCH resource in this embodiment will be described.

[0128] In NR, regarding the identification of PUCCH resources for transmitting response signals to downlink data from a terminal, the base station employs a method in which it notifies a quasi-static set of PUCCH resources (PUCCH resource set) through terminal-specific higher-layer signals (e.g., RRC (Radio Resource Control) singling), and notifies the PUCCH resource to be actually used within the PUCCH resource set through DCI (Downlink Control Information) which allocates downlink data (see, for example, Non-Patent Document 3).

[0129] Here, the PUCCH resource consists of at least one of the following parameters: symbol position in a slot, number of symbols in a slot, frequency domain position, number of resources in the frequency domain (e.g., number of RBs or number of PRBs (Physical RBs)), whether or not frequency hopping is applied, or code resources (e.g., cyclic shift sequence or quadrature code).

[0130] Furthermore, the base station can notify the terminal of multiple PUCCH resource sets. The terminal can decide which of the notified PUCCH resource sets to use based on the number of bits in the Uplink Control Information (UCI) transmitted using PUCCH.

[0131] In this embodiment, terminal 200 determines the PUCCH resource set based on the total number of bits after encoding of the response signal (HARQ-ACK) multiplexed to PUCCH.

[0132] Furthermore, in this embodiment, different values ​​may be set for the parameters related to determining the PUCCH resource for response signals with different reliability levels, delay requests, or use case (or service) types (in other words, response signals with different request conditions).

[0133] For example, in NR, a maximum coding rate is set for each PUCCH format. The terminal determines the number of RBs to use for transmitting PUCCH based on the number of bits in the UCI transmitted using PUCCH and the maximum coding rate. However, the number of RBs used for transmitting PUCCH is limited to the number of RBs of the PUCCH resource notified by the PUCCH resource set mentioned above.

[0134] In this embodiment, the maximum coding rate is set for each PUCCH format and for each type of response signal reliability, delay request, or use case (or service) (in other words, for each requirement of the response signal).

[0135] For example, terminal 200 calculates the amount of resources (e.g., RE count) to use for transmitting each response signal, based on the number of bits after encoding the response signal and the set maximum encoding rate, for each response signal with different reliability, delay request, or use case (or service) types. Then, terminal 200 determines the RB count to use for transmitting a PUCCH based on the RE count used for transmitting each response signal multiplexed in a single PUCCH.

[0136] As a result, terminal 200 can determine the PUCCH resource set in PUCCH where response signals with different requirements are multiplexed, based on the number of bits after encoding using the encoding method set for each response signal, as described above. For example, terminal 200 can calculate an appropriate amount of resources according to the reliability of the response signal, the delay request, or the type of use case (or service), thus enabling efficient PUCCH transmission from the perspective of resource utilization efficiency.

[0137] Furthermore, as mentioned above, the number of RBs used for PUCCH transmission is limited by the number of RBs of the PUCCH resource notified by the PUCCH resource set. Therefore, for example, if the number of RBs determined by the number of bits in the response signal and the maximum coding rate exceeds the upper limit notified by the PUCCH resource set, the actual coding rate of the response signal may exceed the set maximum coding rate. In this case, it may not be possible to meet the quality requirements for PUCCH transmission.

[0138] Therefore, in this embodiment, if the actual coding rate of the response signal exceeds a predetermined threshold, the terminal 200 may drop a portion of the response signal transmitted using PUCCH. As a result, the resources used for the portion of the response signal that was dropped in the PUCCH resource are used for the remaining response signal, thereby improving the quality of PUCCH transmission.

[0139] Here, the threshold may be, for example, the maximum coding rate set for each PUCCH format and for each type of response signal, such as the reliability, delay request, or use case (or service). In addition to the maximum coding rate, a threshold for dropping some response signals may be newly notified from the base station 100 to the terminal 200.

[0140] Furthermore, if the terminal 200 drops at least a portion of the response signal transmitted using PUCCH if the number of RBs calculated from the number of bits of the response signal (or UCI) transmitted using PUCCH and the maximum coding rate exceeds a predetermined threshold (upper limit), the terminal 200 may drop at least a portion of the response signal transmitted using PUCCH. This allows the resources used for the dropped portion of the response signal in the PUCCH resource to be used for the remaining response signal, thereby improving the quality of PUCCH transmission.

[0141] Furthermore, the response signals to be dropped may be determined according to the reliability of the response signal, the delay request, or the priority set according to the type of use case (or service) (in other words, the priority set for each request condition). For example, terminal 200 may preferentially send response signals for high-priority request conditions. In other words, terminal 200 may preferentially drop response signals for low-priority request conditions.

[0142] As an example of prioritization, if the reliability of the response signals differs, for example, in URLLC, the target error rate for the first data transmission is high (e.g., BLER=10 -1 The priority of the response signal for downlink data is the target error rate for the first data transmission (e.g., BLER=10). -5 ) The priority of the response signal is set higher than that of the downlink data. Alternatively, if the delay requirements for the response signal are different or the type of use case (or service) is different, for example, the priority of URLLC is set higher than that of eMBB.

[0143] If the coding rate of at least one of the response signals with different reliability, delay requirements, or use case (or service) types exceeds a threshold, terminal 200 may drop the lower-priority response signals first. This helps to minimize the degradation of transmission quality of higher-priority response signals, i.e., response signals requiring higher reliability.

[0144] Furthermore, if there are response signals with different reliability levels, delay requests, or use cases (or services), the base station 100 may pre-notify the terminal 200 of information indicating how to share or divide resources (e.g., RE) within PUCCH for different response signals (e.g., resource sharing factor or resource splitting factor).

[0145] The above explains how to determine PUCCH resources.

[0146] Thus, in this embodiment, terminal 200 determines the processing method for the response signal or PUCCH according to the requirements for the response signal of the downlink data (for example, reliability, delay requirement, or type of use case (service)). Specifically, terminal 200 applies different encoding methods to response signals with different requirements. Then, terminal 200 multiplexes the encoded response signal onto PUCCH and transmits it.

[0147] As a result, according to this embodiment, even when response signals with different requirements are multiplexed into the PUCCH, the terminal 200 can perform processing (e.g., encoding processing) or setting up wireless resources (e.g., mapping method or PUCCH resource determination) according to the requirements of the response signals multiplexed into the PUCCH. For example, the terminal 200 can improve the resource utilization efficiency in the PUCCH by setting the location or amount of PUCCH resources according to the reliability required for the response signal. Also, for example, the terminal 200 can reduce the delay of the response signal by setting the location of PUCCH resources according to the delay requirement for the response signal.

[0148] Based on the above, according to this embodiment, terminal 200 can appropriately transmit UCI including response signals.

[0149] (Embodiment 2) Since the base station and terminal according to this embodiment have the same basic configuration as the base station 100 and terminal 200 according to Embodiment 1, they will be explained with reference to Figures 2 and 3.

[0150] In this embodiment, terminal 200 determines the PUCCH resource or PUCCH resource set differently for response signals with different reliability levels, delay requests, or use cases (or services) (in other words, response signals with different request conditions).

[0151] Furthermore, in this embodiment, the number of PUCCHs to which terminal 200 can transmit a response signal within a single slot is not limited to one. In other words, in this embodiment, the number of PUCCHs to which terminal 200 can transmit a response signal within a single slot is one or more.

[0152] For example, terminal 200 transmits each response signal with different requirements using different PUCCHs within the slot. For example, multiple PUCCHs are multiplexed within the same slot using time division multiplexing (TDM), frequency division multiplexing (FDM), or code division multiplexing (CDM).

[0153] This allows terminal 200 to allocate appropriate PUCCH resources to each response signal according to the reliability of the response signal, the delay request, or the type of use case (or service). In other words, terminal 200 can transmit response signals with different requirements using separate PUCCHs instead of multiplexing them onto a single PUCCH. This enables efficient PUCCH transmission from the perspective of resource utilization efficiency.

[0154] Furthermore, according to this embodiment, the terminal 200 can transmit different response signals for delay requests using different PUCCHs. For example, by transmitting response signals that require low latency, such as URLLC, using a Short-PUCCH, and response signals that do not require low latency as much, such as eMBB, using a Long-PUCCH, the bottleneck for delay requests can be eliminated.

[0155] For example, with regard to identifying PUCCH resources for transmitting response signals to downlink data from terminal 200, base station 100 notifies of a quasi-static set of PUCCH resources (e.g., PUCCH resource set) by terminal-specific higher-layer signals (e.g., RRC signaling). Terminal 200 determines the PUCCH resource set based on, for example, one of the following two methods (Option 1 and Option 2):

[0156] [Option 1] In Option 1, different groups of PUCCH resource sets are configured for response signals with different reliability levels, delay requests, or use case (or service) types (in other words, response signals with different request conditions). Therefore, terminal 200 configures the PUCCH resource set belonging to a different group for response signals with different request conditions.

[0157] Figure 10A shows an example of the PUCCH resource set configuration in Option 1.

[0158] In Figure 10A, groups of PUCCH resource sets for eMBBs (e.g., group X) and groups of PUCCH resource sets for URLLCs (e.g., group Y) are configured. For example, in Figure 10A, group X includes PUCCH resource sets X0, X1, X2, and X3, and group Y includes PUCCH resource sets Y0, Y1, Y2, and Y3.

[0159] Terminal 200 determines which PUCCH resource set to use within each group based on the number of bits in the UCI to be transmitted using PUCCH (e.g., the number of HARQ-ACK bits) for each response signal with different reliability, delay requests, or use case (or service) types.

[0160] For example, in Figure 10A, terminal 200 selects PUCCH resource set X1 from among the PUCCH resource sets in group X based on the number of bits in the response signal to the eMBB. Also in Figure 10A, terminal 200 selects PUCCH resource set Y0 from among the PUCCH resource sets in group Y based on the number of bits in the response signal to the URLLC.

[0161] Furthermore, terminal 200 is notified of the PUCCH resource to be used from the selected PUCCH resource set by DCI (for example, DL assignment for eMBB or DL ​​assignment for URLLC shown in Figure 10B), which assigns downlink data corresponding to each response signal with different reliability, delay requests, or use case (or service) types. Terminal 200 transmits the response signal using the PUCCH resource notified by DCI from the selected PUCCH resource set.

[0162] According to Option 1, a PUCCH resource set is configured individually for each reliability level, delay request, or use case (or service) type, allowing for more flexible allocation of PUCCH resources suitable for response signals with different reliability levels, delay requests, or use case (or service) types.

[0163] Note that the example of PUCCH resource set configuration shown in Figure 10A is just one example and is not limited to this. For example, the number of PUCCH resource sets included in the group of PUCCH resource sets for eMBB and URLLC is not limited to four, but may be any other number. Also, the number of PUCCH resource sets included in each group of PUCCH resource sets for eMBB and URLLC may be the same or different. Furthermore, although Figure 10A describes eMBB and URLLC as an example of different requirements, it is not limited to this, and for example, groups of PUCCH resource sets may be configured according to at least one of different reliability levels or different delay requirements.

[0164] [Option 2] In Option 2, the same group of PUCCH resource sets is configured for response signals with different reliability levels, delay requests, or use case (or service) types (in other words, response signals with different request conditions). Therefore, terminal 200 configures the PUCCH resource sets included in the same group for response signals with different request conditions.

[0165] Figure 11A shows an example of the PUCCH resource set configuration in Option 2.

[0166] In Figure 11A, groups containing PUCCH resource sets 0, 1, 2, and 3 are configured.

[0167] Terminal 200 determines which PUCCH resource set to use within the same group based on the number of bits in the UCI to be transmitted using PUCCH (e.g., the number of HARQ-ACK bits), regardless of, for example, reliability, delay request, or type of use case (or service).

[0168] For example, in Figure 11A, terminal 200 selects PUCCH resource set 1 from PUCCH resource sets 0 to 3 based on the number of bits in the response signal to the eMBB. Also in Figure 11A, terminal 200 selects PUCCH resource set 0 from PUCCH resource sets 0 to 3 based on the number of bits in the response signal to the URLLC.

[0169] Furthermore, terminal 200 is notified of the PUCCH resource to be used from the selected PUCCH resource set by DCI (for example, DL assignment for eMBB or DL ​​assignment for URLLC shown in Figure 11B), which assigns downlink data corresponding to each response signal with different reliability, delay requests, or use case (or service) types. Terminal 200 transmits the response signal using the PUCCH resource notified by DCI from the selected PUCCH resource set.

[0170] According to Option 2, the selectable PUCCH resource set is the same regardless of reliability, delayed request, or use case (or service) type. Therefore, the overhead associated with notifying the PUCCH resource set can be reduced.

[0171] Furthermore, terminal 200 can individually determine the PUCCH resource set to use based on the number of bits in each response signal, which differs in reliability, delay request, or use case (or service) type. Therefore, terminal 200 can use PUCCH resources that are suitable for each response signal, which differs in reliability, delay request, or use case (or service) type.

[0172] The above explains how to determine the PUCCH resource set.

[0173] Thus, in this embodiment, terminal 200 applies different resource determination methods to response signals with different requirements (e.g., reliability, delay request, or type of use case (service)). Then, terminal 200 transmits the response signal using the PUCCH resource set for each response signal.

[0174] As a result, according to this embodiment, the terminal 200 can individually set wireless resources according to the requirements for the response signal, thereby improving resource utilization efficiency or reducing the delay of the response signal. Therefore, according to this embodiment, the terminal 200 can appropriately transmit UCI including the response signal.

[0175] In this embodiment, a method for determining different PUCCH resources or different sets of PUCCH resources for response signals with different reliability levels, delay requests, or use cases (or service types) has been described. However, if the PUCCH resources determined for each response signal based on the resource determination method in this embodiment are the same, the terminal 200 may apply the same processing as in Embodiment 1.

[0176] Furthermore, Option 1 in this embodiment describes the case where different groups of PUCCH resource sets are configured for each type of reliability, delayed request, or use case (or service). In contrast, it is also possible to create differences in the values ​​(or ranges of values) that can be set for each type of reliability, delayed request, or use case (or service) regarding the parameters of the PUCCH resource set.

[0177] For example, in NR's PUCCH Format 0, Sequence selection is used (see, for example, Non-Patent Document 1). Also, in Release 15 NR, the transmission bandwidth that can be allocated to PUCCH transmission is 1RB, and a transmission sequence with a sequence length of 12, corresponding to 1RB = 12 subcarriers, is used. Furthermore, NR uses frequency allocation with 1-cell repetition. In 1-cell repetition, inter-cell interference is the main cause of performance degradation. In particular, in Short-PUCCH, because the number of symbols used (1 or 2 symbols) is small, it is not possible to suppress inter-cell interference by using multiple symbols to average out the interference.

[0178] Therefore, when high reliability is required for the response signal, suppression of inter-cell interference is necessary. Expanding the transmission bandwidth (sequence length) is an effective method for suppressing inter-cell interference (see, for example, Non-Patent Document 6).

[0179] Therefore, for example, with respect to PUCCH Format 0, the configurable number of RBs or sequence length of PUCCH may be varied depending on the type of response signal, such as reliability, delay request, or use case (or service).

[0180] For example, in a PUCCH resource set for a response signal requiring high reliability, a variable number of PRBs (e.g., 1, 2, and 4 PRBs) may be set. On the other hand, in a PUCCH resource set for a response signal that does not require high reliability, the number of configurable PRBs may be limited to 1 PRB. Note that the number of configurable PRBs for each requirement is not limited to the above examples and may be other numbers.

[0181] This allows for the suppression of inter-cell interference by increasing the transmission bandwidth (sequence length), even when high reliability is required for the response signal in PUCCH Format 0.

[0182] Furthermore, for PUCCH Format 0, time-domain repetition is also an effective technique for improving its characteristics.

[0183] Therefore, for PUCCH Format 0, the number of configurable repetitions for PUCCH may be varied depending on the type of response signal, such as reliability, delay request, or use case (or service).

[0184] For example, in a PUCCH resource set for a response signal requiring high reliability, the Repetition setting may be enabled, allowing for a variable number of repetitions (e.g., 1, 2, or 4). On the other hand, in a PUCCH resource set for a response signal not requiring high reliability, the Repetition setting may not be enabled. Note that the number of repetitions that can be set for each requirement is not limited to the above example and may be other numbers.

[0185] This allows for characteristic improvement through repetition, even when high reliability is required for the response signal in PUCCH Format 0.

[0186] Furthermore, in time-domain repetition, there is a method of repeatedly transmitting the same sequence across multiple symbols. With this method, by combining the repetition signals in phase at the receiving end (e.g., base station 100), an improvement in characteristics due to increased power of the received signal can be expected. Another method of time-domain repetition is to expand the sequence length and transmit a portion of the expanded sequence with different symbols. For example, the sequence length is expanded from 12 to 24, with the first half of the 24-length sequence transmitted with the first symbol and the second half transmitted with the next symbol. With this method, an interference suppression effect can be expected due to the use of a longer sequence length.

[0187] As mentioned above, for PUCCH format 0, by allowing different parameters to be set for the PUCCH resource set for response signals requiring high reliability compared to Release 15 NR, the requirements regarding the reliability of URLLC response signals that allow retransmission, which are not considered in Release 15 NR (for example, BLER=10 -4 This enables PUCCH transmission with the following error rates.

[0188] (Variation of Embodiment 2) Embodiment 2 describes a case where the method for determining the PUCCH resource or PUCCH resource set differs for response signals with different reliability levels, delay requests, or use cases (or services).

[0189] In NR, regarding the identification of the slot position of a PUCCH for sending a response signal for downlink data (or the time from the slot that received the downlink data to the slot that sends the PUCCH), the base station notifies the terminal of a quasi-static set of slot positions by terminal-specific higher-layer signals (e.g., RRC signaling), and the DCI that allocates the downlink data notifies the terminal of the slot position to be actually used within that set of slot positions (see, for example, Non-Patent Document 3).

[0190] Therefore, in the variation of Embodiment 2, the set of slot positions for PUCCH for transmitting response signals can also be set for each response signal with different reliability, delay requirements, or use case (or service) types (in other words, response signals with different requirements).

[0191] According to the variation of Embodiment 2, the terminal 200 can use an appropriate transmission slot for the response signal depending on the reliability of the response signal, the delay request, or the type of use case (or service). For example, if different sets of slot positions are set for different delay requests, the terminal 200 can assign a more flexible slot suitable for each of the different response signals for a delay request, even when transmitting different response signals for delay requests using different PUCCHs.

[0192] (Embodiment 3) Since the base station and terminal according to this embodiment have the same basic configuration as the base station 100 and terminal 200 according to Embodiment 1, they will be explained with reference to Figures 2 and 3.

[0193] In this embodiment, when terminal 200 simultaneously transmits response signals for data transmissions with different reliability levels, delay requests, or use cases (or services) within the same slot, it drops all of the PUCCHs that transmit response signals, or punctures some of them, according to the priority of the PUCCHs.

[0194] PUCCH, which drops or partially punctures a request, may be determined based on the reliability of the ACK / NACK, the delay request, or the type of use case (or service) to which priority is assigned.

[0195] Specifically, if terminal 200 receives response signals with different requirements at the same time, it will drop or partially puncture all PUCCHs with lower priority based on the requirements.

[0196] As an example of PUCCH priority, we will explain the case where the reliability of the response signal differs. For example, in URLLC, the target error rate for the first data transmission is high (e.g., BLER=10). -1 The priority of PUCCH, which transmits a response signal for downlink data, is given to those with a low target error rate for the first data transmission (e.g., BLER=10). -5) is set to have a higher priority than PUCCH, which sends a response signal for downlink data. In other words, terminal 200 has a low target error rate for the first data transmission (for example, BLER=10 -5 ) Drop all or partially puncture the PUCCHs that send response signals to downlink data.

[0197] Furthermore, we will explain the case where the response signal delay request or the type of use case (or service) is different. For example, Figure 12 shows the existence of two services, URLLC and eMBB. The priority of the PUCCH corresponding to URLLC is set higher than the priority of the PUCCH corresponding to eMBB. In other words, terminal 200 drops all or partially punctures the PUCCHs corresponding to eMBB. For example, in Figure 12, terminal 200 uses the PUCCH corresponding to URLLC (URLLC PUCCH) to send a response signal corresponding to URLLC and drops all the PUCCHs corresponding to eMBB (eMBB PUCCH).

[0198] According to this embodiment, a PUCCH transmission for a response signal requiring higher reliability or lower latency will not be affected by a PUCCH transmission for another response signal, thus ensuring the quality of the response signal requiring higher reliability or lower latency.

[0199] Furthermore, when puncturing a portion of a PUCCH, for example, in the PUCCH transmission of different response signals, there are methods such as puncturing symbols that overlap in time, or puncturing REs that overlap in both time and frequency.

[0200] The method of puncturing time-overlapping symbols can be applied, for example, when terminal 200 cannot transmit multiple uplink signals simultaneously, or when terminal 200 has the capability to transmit multiple uplink signals simultaneously, but the sum of the transmitted power exceeds the maximum transmitted power, and therefore must transmit only one of the signals.

[0201] Furthermore, the method of puncturing REs with overlapping time and frequency can be applied, for example, to terminal 200 if it has the capability to transmit multiple uplink signals simultaneously and if transmitting multiple uplink signals simultaneously does not exceed the maximum transmit power of terminal 200.

[0202] (Embodiment 4) For example, Embodiment 1 described a case where different encoding processes are applied to response signals with different reliability levels, delay requests, or use cases (or service types). However, applying different encoding processes can increase the processing load on the terminal, potentially complicating the implementation.

[0203] Therefore, this embodiment describes a method for applying a single encoding process to response signals with different reliability levels, delay requests, or use cases (or services).

[0204] Since the base station and terminal according to this embodiment have the same basic configuration as the base station 100 and terminal 200 according to Embodiment 1, they will be explained with reference to Figures 2 and 3.

[0205] Terminal 200 has the capability (UE capability; hereinafter referred to as "N1") to process data from the time of receiving downlink data to decoding the downlink data, generating a response signal, and transmitting a PUCCH signal. In NR, terminal 200 reports "N1" to base station 100.

[0206] The base station 100 sets the slot position of the PUCCH for the terminal 200 to send a response signal for downlink data (or the time from the slot that received the downlink data to the slot that sends the PUCCH (e.g., response signal): "PDSCH-to-HARQ-ACK timing") and notifies the terminal 200. At this time, the base station 100 cannot set or notify the terminal 200 of a value for PDSCH-to-HARQ-ACK timing that exceeds the processing capacity (N1) of the terminal 200 reported by the terminal 200 (in other words, a value smaller than N1).

[0207] In this embodiment, terminal 200 defines its ability (N1) to transmit response signals of different reliability levels, delay requests, or use cases (or services), and reports this to base station 100. Furthermore, terminal 200 determines the transmission method and parameters (in other words, the processing mode for the response signal or PUCCH) of the response signal or PUCCH used to transmit the response signal, based on the PDSCH-to-HARQ-ACK timing value set and notified by base station 100 and the defined N1 value.

[0208] For example, terminal 200 has two or more capabilities (N1) regarding the processing time required from receiving downlink data to decoding the data, generating a response signal, and transmitting a PUCCH, depending on the reliability, delay requirement, or type of use case (or service). Terminal 200 reports two or more capabilities (N1) to base station 100.

[0209] For example, terminal 200 may have two UE capabilities: 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, since URLLC is likely to require lower latency than eMBB, N1 for URLLC may be set to a smaller value than N1 for eMBB.

[0210] As described in the variation of Embodiment 2, regarding the identification of the PUCCH slot position (PDSCH-to-HARQ-ACK timing) for transmitting a response signal to downlink data, the base station 100 notifies a set of quasi-static slot positions by terminal-specific higher-layer signals (e.g., RRC signaling), and the DCI, which allocates the downlink data, notifies which PDSCH-to-HARQ-ACK timing from the set will actually be used.

[0211] If, within the same slot, response signals corresponding to data transmissions with different reliability levels, delay requests, or use cases (or services) are transmitted simultaneously, terminal 200 determines how to process each response signal based on the PDSCH-to-HARQ-ACK timing value for each response signal and the capabilities (N1) of terminal 200.

[0212] For example, as shown in Figure 13, if the minimum value of the PDSCH-to-HARQ-ACK timing for each response signal (PDSCH-to-HARQ-ACK timing for URLLC in Figure 13) is greater than or equal to N1 (N1_X or N1_eMBB) for eMBB, the terminal 200 performs a common encoding process (joint encoding) on ​​the response signal corresponding to eMBB and the response signal corresponding to URLLC to generate HARQ-ACK bits.

[0213] Specifically, in Figure 13, between the time terminal 200 receives a PDSCH for URLLC and the time corresponding to the PDSCH-to-HARQ-ACK timing for URLLC has elapsed, terminal 200 can complete the process of generating a response signal corresponding to the eMBB and transmitting a PUCCH containing that response signal (in other words, N1_X / N1_eMBB ≤ PDSCH-to-HARQ-ACK timing for URLLC). Therefore, between the time terminal 200 receives a PDSCH for URLLC and the time corresponding to the PDSCH-to-HARQ-ACK timing for URLLC has elapsed, terminal 200 can perform common encoding processing on the URLLC response signal and the eMBB response signal.

[0214] On the other hand, as shown in Figure 14, if the PDSCH-to-HARQ-ACK timing value for a response signal requiring high reliability or low latency, or a response signal corresponding to URLLC (PDSCH-to-HARQ-ACK timing for URLLC in Figure 14) is less than N1 (N1_X or N1_eMBB) corresponding to eMBB, terminal 200 cannot perform common encoding processing for the response signal corresponding to eMBB and the response signal corresponding to URLLC.

[0215] Specifically, in Figure 14, between the time terminal 200 receives a PDSCH for URLLC and the time corresponding to the PDSCH-to-HARQ-ACK timing for URLLC has elapsed, terminal 200 cannot complete the process of generating a response signal corresponding to the eMBB and transmitting a PUCCH containing that response signal (in other words, N1_X / N1_eMBB > PDSCH-to-HARQ-ACK timing for URLLC).

[0216] Therefore, terminal 200 cannot encode the URLLC ACK / NACK and the eMBB ACK / NACK together between the time terminal 200 receives the PDSCH for URLLC and the time corresponding to the PDSCH-to-HARQ-ACK timing for URLLC has elapsed. In this case, terminal 200 uses either the method of Embodiment 3 or Embodiment 1.

[0217] For example, when using the method of Embodiment 3, the encoding process can be reduced to a single process for response signals with different reliability levels, delay requests, or use cases (or services), which has the advantage of simplifying the implementation of the terminal 200. Also, when using the method of Embodiment 1, as shown in Figure 14, the terminal 200 can generate HARQ-ACK bits with appropriate encoding (or encoding rate) according to the reliability level, delay request, or use case (or service) of the response signal, enabling efficient PUCCH transmission from the perspective of resource utilization efficiency.

[0218] Thus, according to this embodiment, the encoding process can be standardized as much as possible according to the processing capacity of the terminal 200, thereby reducing the increase in processing load or implementation complexity of the terminal 200.

[0219] The embodiments of this disclosure have been described above.

[0220] (1) In the above embodiment, differences were made in the method of transmitting the response signal or PUCCH and the parameters depending on the reliability of the response signal, the delay request, or the type of use case (or service).

[0221] One example of a difference that may arise in the method and parameters of transmitting the response signal or PUCCH is when the reliability of the response signal differs. For example, in URLLC, the target error rate for the first data transmission is high (e.g., BLER=10). -1 ) Response signal for downlink data and low target error rate for the first data transmission (e.g., BLER=10 -5 The method and parameters of transmitting the response signal or PUCCH can be made different for the response signal to the downlink data. The former response signal requires a high level of reliability, while the latter does not require such high reliability.

[0222] Furthermore, differences in the transmission method and parameters of response signals or PUCCHs can arise when the delay requirements for the response signals differ or when the use cases (or services) differ. For example, differences in the transmission method and parameters of response signals or PUCCHs can be introduced between response signals corresponding to URLLC and response signals corresponding to eMBB. The former response signal requires high reliability or low latency, while the latter does not require such high reliability or low latency. Also, as mentioned above, URLLC has a high target error rate for the first data transmission (e.g., BLER=10). -1 ) Response signal for downlink data and low target error rate for the first data transmission (e.g., BLER=10 -5This may include a response signal to the downlink data.

[0223] Furthermore, examples of differences in the method of transmitting response signals or PUCCH are not limited to reliability, delay requirements, or the type of use case (service), but may also include differences in physical layer parameters. For example, eMBB may be replaced with "slot-based transmission" and URLLC with "non-slot-based transmission". Alternatively, eMBB may be replaced with "PDSCH mapping type A" or "PUSCH mapping type A", and URLLC may be replaced with "PDSCH mapping type B" or "PUSCH mapping type B". Moreover, the examples are not limited to transmissions corresponding to eMBB and URLLC; for example, eMBB may be replaced with a transmission with a longer transmission interval (e.g., slot length or symbol length), and URLLC may be replaced with a transmission with a shorter transmission interval than the aforementioned transmission interval.

[0224] Furthermore, in this disclosure, the target error rate may be the target error rate for the first data transmission, as described above, or, if retransmission occurs, the target error rate for the retransmission. Also, the target error rate may be referred to as the "instantaneous target error rate" in the sense of the target error rates for both the first transmission and the retransmission.

[0225] (2) The methods for determining the "reliability, delay request, or type of use case (or service)" of the response signal (in other words, the requirement conditions) as described in the above embodiment include, for example, the following methods as shown in Examples 1 to 5.

[0226] [Example 1: Scramble series] In Example 1, terminal 200 determines the reliability of the response signal, the delay request, or the type of use case (service) based on a terminal-specific scrambling sequence used in DCI to schedule downlink data transmission corresponding to each response signal.

[0227] For example, in DCI for PDSCH assuming eMBB, terminal-specific scrambling sequences such as C-RNTI (Cell-Radio Network Temporary Identifier) ​​or CS-RNTI (Configured Scheduling-RNTI) are used. Therefore, if terminal 200 detects a scrambling sequence different from C-RNTI or CS-RNTI, it determines that the response signal has high reliability, strict delay requirements, or is URLLC. Also, if terminal 200 detects a scrambling sequence that is C-RNTI or CS-RNTI, it determines that the response signal does not have high reliability, strict delay requirements, or is eMBB.

[0228] For example, the control unit 101 of the base station 100 (see, for example, Figure 2) determines information regarding the reliability of the downlink data of the terminal 200, the delay request, or the type of use case (service). The determined information is output to the downlink control signal generation unit 109 of the base station 100. As described above, the downlink control signal generation unit 109 generates a DCI bit sequence using a scrambling sequence corresponding to the reliability of the downlink data of the terminal 200, the delay request, or the type of use case (or service).

[0229] Meanwhile, the decoding unit 206 of the terminal 200 (see, for example, Figure 3) outputs the detected scrambling sequence to the control unit 211. Based on the obtained scrambling sequence, the control unit 211 determines information regarding the reliability of the downlink data, delay requests, or the type of use case (service).

[0230] [Example 2: MCS Table] In Example 2, terminal 200 determines the reliability of the response signal, the delay request, or the type of use case (service) based on the MCS table used for scheduling downlink data transmission corresponding to each response signal.

[0231] For example, in Release 15 NR, the target BLER = 10 -1 The MCS table to achieve this, and the target BLER=10-5 You can configure which MCS table to use to achieve the desired result.

[0232] For example, terminal 200 has an MCS table set in URLLC with target BLER=10 -1 If the MCS table is designed to achieve the target BLER=10, it is determined that the required reliability of the response signal is high. On the other hand, terminal 200 determines that the MCS table set in URLLC is designed to achieve the target BLER=10 -5 If the MCS table is designed to achieve a certain objective, it is determined that the required reliability of the response signal is not high.

[0233] For example, the control unit 101 of the base station 100 determines information regarding the reliability of the downlink data of the terminal 200, the delay request, or the type of use case (service). The determined information is output to the downlink control signal generation unit 109, the encoding unit 103, and the modulation unit 105 of the base station 100. The downlink control signal generation unit 109 includes information regarding the MCS table used for downlink data transmission in the DCI bit sequence. The encoding unit 103 and the modulation unit 105 then encode and modulate the downlink data using the MCS table information input from the control unit 101.

[0234] Meanwhile, the decoding unit 206 of terminal 200 decodes the DCI and outputs the decoding result to the control unit 211. Based on the information about the MCS table obtained from the DCI, the control unit 211 determines information about the reliability of the downlink data, delay requests, or the type of use case (service).

[0235] [Example 3: PDSCH-to-HARQ-ACK timing or number of PDSCH transmitted symbols] In Example 3, terminal 200 determines the reliability of the response signal, the delay request, or the type of use case (service) based on the "PDSCH-to-HARQ-ACK timing" or the number of transmitted symbols of the PDSCH notified by DCI, which schedules the downlink data transmission corresponding to each response signal.

[0236] For example, terminal 200 determines that the response signal has a strict delay requirement or is a response signal for URLLC if the PDSCH-to-HARQ-ACK timing is less than or equal to a predetermined value, or if the number of transmitted symbols of the PDSCH is less than or equal to a predetermined number of symbols. On the other hand, terminal 200 determines that the response signal has a less strict delay requirement or is a response signal for eMBB if the PDSCH-to-HARQ-ACK timing is greater than a predetermined value, or if the number of transmitted symbols of the PDSCH is greater than a predetermined number of symbols.

[0237] The above-mentioned predetermined value or predetermined number of symbols may be a value predetermined in the standard, or a value that the base station 100 can set on the terminal 200 via a higher layer signal.

[0238] For example, the control unit 101 of the base station 100 determines the PDSCH-to-HARQ-ACK timing or the number of PDSCH transmission symbols, which indicates the slot position for transmitting a response signal to the downlink data of the terminal 200. The determined information is output to the downlink control signal generation unit 109, the signal allocation unit 112, and the extraction unit 118 of the base station 100. The downlink control signal generation unit 109 includes the information regarding the PDSCH-to-HARQ-ACK timing or the number of PDSCH transmission symbols in the DCI bit sequence.

[0239] Meanwhile, the decoding unit 206 of the terminal 200 decodes the DCI and outputs the decoding result to the control unit 211. Based on the information obtained from the DCI regarding the PDSCH-to-HARQ-ACK timing or the number of transmitted symbols of the PDSCH, the control unit 211 determines information regarding the reliability of the downlink data, delay requests, or the type of use case (service).

[0240] [Example 4: CQI Table] In Example 4, terminal 200 determines the reliability of the response signal, the delay request, or the type of use case (service) based on the CQI table configured for downlink data transmission corresponding to each response signal.

[0241] For example, in Release 15 NR, the target BLER = 10 -1 CQI table to achieve, and target BLER=10 -5 You can configure which CQI table to use to achieve the desired result.

[0242] For example, terminal 200 has a CQI table set in URLLC with target BLER=10 -1 If the CQI table is designed to achieve the target BLER=10, it is judged that the required reliability of the response signal is high. On the other hand, if the CQI table set in URLLC is designed to achieve the target BLER=10 -5 If the CQI table is designed to achieve a certain objective, then it is determined that the required reliability of the response signal is not high.

[0243] For example, the control unit 101 of the base station 100 determines information regarding the CQI table set for downlink data transmission of the terminal 200. The determined information is output to the higher-level control signal generation unit 106. The higher-level control signal generation unit 106 includes the information regarding the CQI table in the higher-level control signal.

[0244] Meanwhile, the decoding unit 208 of the terminal 200 decodes the higher-level control signal and outputs the decoding result to the control unit 211. Based on the information in the CQI table obtained from the higher-level control signal, the control unit 211 determines information regarding the reliability of the downlink data, delay requests, or the type of use case (service).

[0245] [Example 5: Explicit notification by DCI] In Example 5, terminal 200 determines the reliability of the response signal, the delay request, or the type of use case (service) by an explicit notification of a few bits in the DCI that schedules the downlink data transmission corresponding to each response signal.

[0246] Explicit notifications may include information regarding the reliability of the response signal itself, the delay request, or the type of use case (service), or they may include information regarding the reliability of the PDSCH (e.g., target BLER), the delay request, or the type of use case (service).

[0247] For example, the control unit 101 of the base station 100 determines information regarding the reliability of the response signal to the downlink data of the terminal 200, the delay request, or the type of use case (service). The determined information is output to the downlink control signal generation unit 109. The downlink control signal generation unit 109 includes the information regarding the reliability of the response signal, the delay request, or the type of use case (service) in the bit sequence of the DCI.

[0248] Meanwhile, the decoding unit 206 of the terminal 200 decodes the DCI and outputs the decoding result to the control unit 211. The control unit 211 obtains information from the DCI regarding the reliability of the response signal, the delay request, or the type of use case (service).

[0249] The above describes how to determine the "reliability, delay request, or use case (or service) type" of a response signal. Note that the method for determining the "reliability, delay request, or use case (or service) type" of a response signal is not limited to Examples 1 to 5 above; other methods based on information related to the requirements are also acceptable.

[0250] (3) In the above embodiment, the case in which a response signal to downlink data transmission is transmitted using PUCCH was described as an example. However, the UCI transmitted using PUCCH in this disclosure is not limited to a response signal. For example, in the above embodiment, the "response signal (ACK / NACK or HARQ-ACK)" may be replaced with channel status information (CSI), or it may be replaced with a UCI that includes both the response signal and CSI.

[0251] (4) Furthermore, the present disclosure can be implemented as software, hardware, or software in conjunction with hardware. Each functional block used in the description of the above embodiments may be implemented in part or in whole as an integrated circuit (LSI), and each process described in the above embodiments may be controlled in part or in whole by a single LSI or a combination of LSIs. An LSI may consist of individual chips, or it may consist of a single chip that includes some or all of the functional blocks. An LSI may have data inputs and outputs. Depending on the degree of integration, LSIs may be called ICs, system LSIs, super LSIs, or ultra LSIs. The method of integrated circuit implementation is not limited to LSIs, and may be implemented with dedicated circuits, general-purpose processors, or dedicated processors. In addition, an FPGA (Field Programmable Gate Array) that can be programmed after LSI manufacturing, or a reconfigurable processor that can reconfigure the connections and settings of circuit cells inside the LSI may be used. The present disclosure may be implemented as digital processing or analog processing. Furthermore, if advancements in semiconductor technology or other derived technologies lead to the emergence of integrated circuit technologies that replace LSIs, then naturally, it would be possible to use those technologies to integrate functional blocks. The application of biotechnology, for example, is a possibility.

[0252] This disclosure is applicable to all types of devices, systems, and equipment with communication capabilities (collectively referred to as communication devices). Non-exclusive examples of communication devices include telephones (mobile phones, smartphones, etc.), tablets, personal computers (PCs) (laptops, desktops, notebooks, etc.), cameras (digital still / video cameras, etc.), digital players (digital audio / video players, etc.), wearable devices (wearable cameras, smartwatches, tracking devices, etc.), game consoles, digital book readers, telehealth and telemedicine devices, vehicles or mobile transport with communication capabilities (automobiles, airplanes, ships, etc.), and combinations of the above-mentioned devices.

[0253] Communication devices are not limited to portable or movable devices, but also include all kinds of non-portable or fixed devices, devices, and systems, such as smart home devices (appliances, lighting equipment, smart meters or measuring instruments, control panels, etc.), vending machines, and any other "things" that may exist on an IoT (Internet of Things) network.

[0254] Communication includes data communication via cellular systems, wireless LAN systems, and communication satellite systems, as well as data communication using combinations of these.

[0255] Furthermore, the communication device also includes devices such as controllers and sensors that are connected to or linked to a communication device that performs the communication functions described in this disclosure. For example, this includes controllers and sensors that generate control signals and data signals used by the communication device that performs the communication functions of the communication device.

[0256] Furthermore, communication equipment includes infrastructure facilities such as base stations, access points, and any other devices, devices, and systems that communicate with or control the aforementioned non-limited types of equipment.

[0257] A terminal in one embodiment of the present disclosure comprises: a circuit that determines a processing mode for the uplink control information or the uplink control channel used to transmit the uplink control information in accordance with the requirements for the uplink control information; and a transmitter that transmits the uplink control information using the uplink control channel based on the determined processing mode.

[0258] In a terminal according to one embodiment of the present disclosure, the circuit applies different encoding methods to the uplink control information with different requirements, and the transmitter multiplexes and transmits the encoded uplink control information on the uplink control channel.

[0259] In a terminal according to an embodiment of the present disclosure, the required conditions include reliability or delay requirements, and are mapped to the uplink control channel in the order of the uplink control information for which higher reliability is required, or in the order of the uplink control information for which lower delay is required in the delay requirement.

[0260] In a terminal according to an embodiment of the present disclosure, the uplink control information is mapped to the uplink control channel in the order from the frequency direction to the time direction.

[0261] In a terminal according to an embodiment of the present disclosure, the uplink control information is mapped dispersedly in the frequency direction.

[0262] In a terminal according to an embodiment of the present disclosure, the uplink control information for which higher reliability is required is mapped to a symbol closer to the symbol to which the reference signal is mapped in the uplink control channel.

[0263] In a terminal according to an embodiment of the present disclosure, the uplink control information for which lower delay is required in the delay requirement is mapped to an earlier symbol of the uplink control channel.

[0264] In a terminal according to an embodiment of the present disclosure, the resource set of the uplink control channel is determined based on the total number of encoded bits of the uplink control information multiplexed on the uplink control channel.

[0265] In a terminal according to an embodiment of the present disclosure, a maximum coding rate is set for each of the required conditions for the uplink control information.

[0266] In a terminal according to an embodiment of the present disclosure, when the coding rate of the uplink control information exceeds a predetermined threshold, at least a part of the uplink control information is dropped in the uplink control channel.

[0267] In one embodiment of the present disclosure, the predetermined threshold is the maximum coding rate.

[0268] In one embodiment of the present disclosure, the predetermined threshold is notified to the terminal from the base station.

[0269] In one embodiment of the present disclosure, the dropped uplink control information is determined according to the priority set for each of the request conditions.

[0270] In a terminal according to one embodiment of the present disclosure, if the number of resource blocks calculated from the number of bits of the uplink control information and the maximum coding rate exceeds a predetermined threshold, at least a portion of the uplink control information is dropped in the uplink control channel.

[0271] In one embodiment of the present disclosure, in the uplink control channel, information indicating the proportion of resources shared between the uplink control information with different requirements is notified from the base station to the terminal.

[0272] In one embodiment of the present disclosure, a different resource determination method is applied to the uplink control information with different requirements in the uplink control channel.

[0273] In one embodiment of the present disclosure, the number of uplink control channels that transmit the uplink control information within a slot is one or more, and the transmitter transmits the uplink control information with different requirements using different uplink control channels within the slot.

[0274] In a terminal according to one embodiment of the present disclosure, the circuit sets resource sets belonging to different groups for the uplink control information with different requirements.

[0275] In a terminal according to one embodiment of the present disclosure, the circuit sets resource sets included in the same group for the uplink control information with different requirements.

[0276] In one embodiment of the present disclosure, the parameters relating to the resource set differ for each of the uplink control information items with different requirements.

[0277] In one embodiment of the present disclosure, the parameter is the number of resource blocks or the sequence length of the uplink control channel.

[0278] In one embodiment of the present disclosure, the parameter is the repetition count of the uplink control information.

[0279] In one embodiment of the present disclosure, a slot position for transmitting the uplink control information is set for each uplink control information with different requirements.

[0280] In a terminal according to one embodiment of the present disclosure, if the transmission of the uplink control information with different requirements occurs at the same time, the circuit drops or partially punctures all of the uplink control channels with lower priority based on the requirements.

[0281] In a terminal according to one embodiment of the present disclosure, the uplink control information is a response signal to downlink data, the terminal's capability regarding the processing time required from the reception of the downlink data to the transmission of the response signal is defined for each requirement, timing information indicating the time from the reception of the downlink data to the transmission of the response signal is notified from the base station to the terminal, and the circuit determines the processing mode based on the timing information and the capability.

[0282] In an embodiment of the present disclosure, a communication method determines a processing mode for the uplink control information or an uplink control channel used to transmit the uplink control information according to a requirement condition for the uplink control information, and transmits the uplink control information using the uplink control channel based on the determined processing mode.

[0283] The entire disclosure content of the specification, drawings, and abstract included in the Japanese application of Japanese Patent Application No. 2018-144982 filed on August 1, 2018 is incorporated herein by reference.

Industrial Applicability

[0284] An embodiment of the present disclosure is useful for a mobile communication system.

Description of Signs

[0285] 100 Base station 101, 211 Control unit 102 Data generation unit 103, 107, 110, 212 Encoding unit 104 Retransmission control unit 105, 108, 111, 213 Modulation unit 106 Higher layer control signal generation unit 109 Downlink control signal generation unit 112, 214 Signal allocation unit 113, 215 IFFT unit 114, 216 Transmission unit 115, 201 Antenna 116, 202 Reception unit 117, 203 FFT unit 118, 204 Extraction unit 119 Demodulation unit 120, 206, 208, 210 Decoding unit 121 Determination unit 200 Terminal 205 Downlink control signal demodulation unit 207 Higher layer control signal demodulation unit 209 Data demodulation unit

Claims

1. A transmitter that transmits information indicating a first uplink control channel (PUCCH) resource set for a first response signal to downlink data, which is a first priority, and a second PUCCH resource set for a second response signal to downlink data, The system comprises a receiver that receives the first response signal and the second response signal, The first response signal and the second response signal are multiplexed into one slot. The receiver receives the first response signal and the second response signal, which are transmitted using the number of bits and maximum coding rate of the first response signal and the number of resource blocks determined based on the number of bits and maximum coding rate of the second response signal. Base station.

2. The receiver receives the first response signal and the second response signal, which are encoded by different encoding methods. The base station according to claim 1.

3. The receiver receives the first response signal and the second response signal in a resource within the PUCCH resource set, which is determined based on the sum of the number of bits after encoding the first response signal and the number of bits after encoding the second response signal. The base station according to claim 1.

4. The maximum coding rate of the first response signal and the maximum coding rate of the second response signal are different. The base station according to claim 1.

5. A first set of slot positions is determined for the response signals included in the first response signal, and a second set of slot positions is determined for the response signals included in the second response signal. Based on the first information in the downlink control information, the priority of either the first priority or the second priority is determined, and based on the priority of either the first priority or the second priority, the set of first slot positions or the set of second slot positions is determined. Based on the second information in the down-control information, one slot position is determined from either the first set of slot positions or the second set of slot positions. The base station according to claim 1.

6. The base station is, Information is transmitted indicating a first uplink control channel (PUCCH) resource set for a first response signal to downlink data, which is the first priority, and a second PUCCH resource set for a second response signal to downlink data, which is the second priority. Having received the first response signal and the second response signal, The first response signal and the second response signal are multiplexed into one slot. The first response signal and the second response signal are received using the number of bits and maximum coding rate of the first response signal and the number of resource blocks determined based on the number of bits and maximum coding rate of the second response signal. Communication method.

7. The first response signal and the second response signal are received, which are encoded by different encoding methods. The communication method according to claim 6.

8. In a resource within the PUCCH resource set, which is determined based on the sum of the number of bits after encoding the first response signal and the number of bits after encoding the second response signal, the first response signal and the second response signal are received. The communication method according to claim 6.

9. The maximum coding rate of the first response signal and the maximum coding rate of the second response signal are different. The communication method according to claim 6.

10. A first set of slot positions is determined for the response signals included in the first response signal, and a second set of slot positions is determined for the response signals included in the second response signal. Based on the first information in the downlink control information, the priority of either the first priority or the second priority is determined, and based on the priority of either the first priority or the second priority, the set of first slot positions or the set of second slot positions is determined. Based on the second information in the down-control information, one slot position is determined from either the first set of slot positions or the second set of slot positions. The communication method according to claim 6.

11. The process involves transmitting information indicating a first uplink control channel (PUCCH) resource set for a first response signal to downlink data, which is the first priority, and a second PUCCH resource set for a second response signal to downlink data, The process of receiving the first response signal and the second response signal is controlled, The first response signal and the second response signal are multiplexed into one slot. The receiving process receives the first response signal and the second response signal, which are transmitted using the number of resource blocks determined based on the number of bits and maximum coding rate of the first response signal and the number of bits and maximum coding rate of the second response signal. Integrated circuit.

Images