Patent Description:
In the UMTS (Universal Mobile Telecommunications System) network, the specifications of long-term evolution (LTE) have been drafted for the purpose of further increasing high speed data rates, providing lower latency and so on (see non-patent literature <NUM>). In addition, successor systems of LTE (referred to as, for example, "LTE-A (LTE-Advanced)," "FRA (Future Radio Access)," "<NUM>," "<NUM>," "<NUM>+ (plus)," "NR (New RAT)," "LTE Rel. <NUM>," "LTE Rel. <NUM> (or later versions)," etc.) are also under study for the purpose of achieving further broadbandization and increased speed beyond LTE.

In existing LTE systems (for example, LTE Rel. <NUM> to <NUM>), downlink (DL) and/or uplink (UL) communication are carried out using <NUM>-ms subframes (also referred to as "transmission time intervals (TTIs)" and so on). These subframes are the time unit for transmitting one channel-encoded data packet, and serve as the unit of processing in, for example, scheduling, link adaptation, retransmission control (HARQ (Hybrid Automatic Repeat reQuest)) and so on.

Also, in existing LTE systems (for example, LTE Rel. <NUM> to <NUM>), a user terminal transmits uplink control information (UCI) by using an uplink control channel (for example, PUCCH (Physical Uplink Control CHannel)) or an uplink shared channel (for example, PUSCH (Physical Uplink Shared CHannel)). The format of this uplink control channel is referred to as "PUCCH format," and so on.

Non-Patent Literature <NUM>: <NPL>
<NPL>" relates to signaling aspects for PUCCH resource directed to avoid unnecessary increase in DCI overhead.

Envisaging future radio communication systems (for example, LTE Rel. <NUM> or later version, <NUM>, <NUM>+, NR, etc.), studies are underway to determine resources (for example, PUCCH resource) for an uplink control channel (for example, PUCCH) based on RRC signaling and downlink control information (DCI), when UCI is transmitted using the uplink control channel after RRC (Radio Resource Control) connection is set up.

Meanwhile, in these future radio communication systems, UCI (for example, HARQ-ACK in response to message <NUM> in random access procedures, which will be described later) may be transmitted using an uplink control channel before RRC connection is set up. However, before RRC connection is set up, RRC signaling-based reporting is not possible.

Consequently, when UCI is transmitted using an uplink control channel before RRC connection is set up, the problem lies in how a user terminal should determine resources for the uplink control channel.

The present invention has been made in view of the above, and it is therefore an object of the present invention to provide a user terminal and a radio communication method, whereby resources for an uplink control channel for use for transmitting UCI before RRC connection is set up can be determined properly.

The following paragraphs describe embodiments, aspects and examples that may be not specifically claimed, but may be useful for understanding the invention. According to one aspect of the present invention, a user terminal has a transmission section that transmits uplink control information (UCI) by using an uplink control channel, before RRC (Radio Resource Control) connection is set up, and a control section that determines a resource for the uplink control channel for use for transmitting the UCI, based on a given field value in system information.

According to the present invention, resources for an uplink control channel for use for transmitting UCI before RRC connection is set up can be determined properly.

Envisaging future radio communication systems (for example, LTE Rel. <NUM> and later versions, <NUM>, NR, etc.), formats for an uplink control channel (for example, PUCCH) for use for transmitting UCI (also referred to as "PUCCH formats (PFs)," and/or the like) are under study.

Resources (for example, PUCCH resources) for use for transmitting this uplink control channel are defined per PUCCH format. For example, the allocation of PUCCH resources after RRC (Radio Resource Control) connection is set up is performed by using RRC signaling and downlink control information (DCI).

To be more specific, after RRC connection is set up, a set of a number of PUCCH resources (PUCCH resource set) is reported (configured) from a radio base station to a user terminal via RRC signaling. One of the PUCCH resources is specified by a given field value in DCI. The user terminal transmits a PUCCH using the PUCCH resource indicated by the given field value in DCI.

<FIG> is a diagram to show examples of a parameter set for PUCCH resources and ranges of values that each parameter may assume. As shown in <FIG>, the parameter set for PUCCH resources may include at least one of the following parameters (also referred to as "fields," "information," and/or the like):.

Also, as shown in <FIG>, the range of values that each parameter can take may be defined, per PUCCH format. Every PUCCH resource in the PUCCH resource set configured for the user terminal includes at least one parameter in the above parameter set, and each parameter may assume values within the range defined for the PUCCH format that applies.

Here, PUCCH formats (PFs) <NUM> and <NUM> shown in <FIG> are PFs for use for transmitting UCI of up to two bits (for example, delivery acknowledgment information (also referred to as "HARQ-ACK (Hybrid Automatic Repeat reQuest-ACKnowledgment)," "ACK or NACK," etc.)). PF <NUM> can be allocated to one or two symbols, and therefore is also referred to as "short PUCCH," "sequence-based short PUCCH" and the like. Meanwhile, PF <NUM> can be allocated to four to fourteen symbols, and therefore, is also referred to as "long PUCCH" and the like. In PF <NUM>, a number of user terminals may be code-division-multiplexed (CDM) in the same PRB, by way of time-domain block-wise spreading using at least one of CS and OCC.

PUCCH formats (PFs) <NUM> to <NUM> are PFs for use for transmitting UCI of more than two bits (for example, channel state information (CSI) (or CSI and an HARQ-ACK and/or a scheduling request) (SR)). PF <NUM> can be allocated to one or two symbols, and therefore is also referred to as "short PUCCH" or the like. Meanwhile, PFs <NUM> and <NUM> can be allocated to four to fourteen symbols, and therefore are also referred to as "long PUCCH" and the like. In PF <NUM>, a number of user terminals may be code-division-multiplexed (CDM) by using pre-DFT (frequencydomain) block-wise spreading.

As described above, after RRC connection is set up, a PUCCH resource set to include a number of PUCCH resources can be configured by RRC signaling, on a semi-static basis, and one of the PUCCH resources can be specified by DCI.

Now, before RRC connection is set up, random access procedures are executed between a user terminal and a radio base station. The random access procedures are performed, for example, in the following procedures.

In this way, before RRC connection is set up, an HARQ-ACK for message <NUM> may be transmitted using a PUCCH. However, RRC signaling-based reporting is not possible before RRC connection is set up, and therefore the problem is how to specify the PUCCH resource to use to transmit the HARQ-ACK in response to message <NUM>.

So, the present inventors have worked on a method for properly specifying PUCCH resources for use for transmitting UCI (for example, an HARQ-ACK in response to message <NUM>) before RRC connection is set up, and arrived at the present invention.

Now, the present embodiment will be described below in detail. Note that, according to the present embodiment, although an HARQ-ACK in response to message <NUM> will be assumed as UCI to use before RRC connection is set up, this UCI may be any information that is transmitted by using a PUCCH before RRC connection is set up. Furthermore, although PUCCH formats <NUM> to <NUM> having been described with reference to <FIG> will be exemplified below, the names of PFs are not limited to these, and the names and formats may be changed as appropriate.

With the present embodiment, for example, the parameter set exemplified in <FIG> may be used for PUCCH resources. Each parameter in this parameter set can be set in values within the range defined for each PUCCH format (for example, PFs <NUM> to <NUM>) in <FIG>.

Alternatively, with the present embodiment, a parameter set to include a smaller number (a smaller number of types) of parameters than the parameter set exemplified in <FIG> may be used for PUCCH resources. <FIG> is a diagram to show other examples of a parameter set for PUCCH resources and ranges of values that each parameter may assume.

Since the UCI before RRC connection is set up is, for example, an HARQ-ACK, PUCCH formats (PFs <NUM> and <NUM>) that can communicate UCI of up to two bits may be assumed. Therefore, the parameter set shown in <FIG> does not include parameters that are needed to transmit either of PFs <NUM> to <NUM> (for example, pre-DFT OCC length, pre-DFT OCC index, etc.), not including parameters that are needed to transmit at least one of PF <NUM> and PF <NUM>.

Furthermore, the ranges of values that each parameter may assume, shown in <FIG>, may also be configured for PUCCH formats that are more limited than in <FIG>. For example, <FIG> shows the range of values that each parameter may assume, with respect to PF <NUM> and PF <NUM>.

Furthermore, the ranges of values that each parameter may assume, shown in <FIG>, may be more limited than in <FIG>. For example, the number of symbols where the PUCCH is allocated in a slot may be limited to four or fourteen for PF <NUM>. Also, the values of the starting index of the PRBs to allocate to the PUCCH may be limited to <NUM>, <NUM>, NMAX-<NUM>, and NMAX-<NUM>. Here, NMAX is the maximum number of PRBs to constitute a BWP for uplink communication (UL BWP (Uplink Bandwidth Part)) activated for initial access (initial active UL BWP), a UL BWP, or a BWP configured for a user terminal (UE BWP).

Here, a BWP (BandWidth Part) is a partial frequency band that is configured in a carrier (component carrier (CC), cell, etc.), and is also referred to as a "partial band," a "bandwidth part," and so forth. One or more BWPs (including BWPs for downlink communication (DL BWPs) and/or UL BWPs) are configured for a user terminal, and at least one BWP is activated. Furthermore, one or more UL BWPs may be defined in advance in the specification, for initial access of a user terminal, and at least one UL BWP may be activated.

Also, the frequency resource of a second hop when frequency hopping is enabled is selected from candidate values, which are indicated by at least one of the index (N<NUM>) of the starting PRB, a given value (P), and system information (for example, at least one of RMSI (Remaining Minimum System Information), OSI (Other System Information), MIB (Master Information Block), and SIB (System Information Block)).

Also, the index of the initial CS may be limited to given values. For example, by limiting the index of the initial CS for PF <NUM> to <NUM>, <NUM> or <NUM>, the CS distance between a number of user terminals can be maximized. For example, in the event one bit is used, the CS distance can be maximized among UEs #<NUM> to #<NUM> by configuring UE #<NUM>={<NUM>, <NUM>}, UE #<NUM>={<NUM>, <NUM>} and UE #<NUM>={<NUM>, <NUM>}. In the event of two bits, UEs #<NUM> to #<NUM> can be prevented from collisions by configuring UE #<NUM>={<NUM>, <NUM>, <NUM>, <NUM>}, UE #<NUM>={<NUM>, <NUM>, <NUM>, <NUM>} and UE #<NUM>={<NUM>, <NUM>, <NUM>, <NUM>}.

Note that the given value (P) shown in <FIG> is a value determined based on the initial active UL BWP (or its size).

For example, a table to associate between initial active UL BWPs (or their sizes) and given values (P) may be provided, so that the user terminal may determine frequency resource of the second hop when the above frequency hopping is enabled, by using the given values (P) that corresponds to the initial active UL BWP (or its size). In this table, for example, the given values P corresponding to initial active UL BWPs #<NUM>, #<NUM>, #<NUM>, and #<NUM> may be determined <NUM>, <NUM>, <NUM>, and <NUM>, respectively.

Also, the value of the starting index of the PRBs to allocate to the PUCCH in <FIG> may be determined by taking into account the given value (P). For example, in <FIG>, the range of values that the starting index may assume in PF <NUM> may be defined as "<NUM>, P, NMAX-P-<NUM>, NMAX-<NUM>. " A similar range may be applied to PF <NUM>.

Also, as shown in <FIG>, the user terminal assumes that the pair of PRB indices (PRB numbers) for the first hop and the second hop is defined for each PUCCH format (PF). Since the required quality (for example, SNR (Signal to Noise Ratio)) varies between PF <NUM> and PF <NUM>, the use of code-division-multiplexing (CDM) might lead to a deterioration of the quality of communication. Meanwhile, different PRB indices are defined for every PF, so that PF <NUM> and PF <NUM> can be frequency-division-multiplexed (FDM).

Note that in <FIG>, the index of the starting PRB allocated to the PUCCH is defined as X<NUM>, but may be defined as X<NUM>=X<NUM>+<NUM> or X<NUM>=X<NUM>-<NUM>, or may be defined to be other values. By this means, the PUCCH resources for initial access can be limited to part of the PRBs, so that it is possible to provide frequency resources for other uses (for example, for at least one of UL data, DL data, a UL control channel and a DL control channel).

Note that given values X<NUM> and X<NUM> in <FIG> may be defined in the specification. Alternatively, these given values X<NUM> and X<NUM> may be selected from one or more candidate values, based on a given field value in broadcast information.

With the present embodiment, a user terminal specifies the PUCCH resource for use for transmitting UCI (for example, an HARQ-ACK in response to message <NUM>, which has been described above) before RRC connection is set up, based on a given field value in system information (for example, RMSI). In the following description, RMSI will be described as an example, but information that can be acquired before RRC connection is set up (for example, other system information such as OSI, MIB, SIB and other higher layer control information) may replace RMSI.

With the present embodiment, a given number of PUCCH resources may be defined in advance. For example, if a given field in RMSI is comprised of x bits, <NUM>x types of PUCCH resources may each include, for example, at least one parameter in the parameter set exemplified in <FIG> or <FIG>, and each parameter's value may be specified within the ranges exemplified in <FIG> or <FIG>. The given number of PUCCH resources may be defined in advance in the specification, or may be derived based on broadcast information or the like.

In a first example of the present invention, a PUCCH resource set to include one or more PUCCH resources is reported to (configured in) a user terminal by a given field value of RMSI. Based on a given field value in DCI, the user terminal determines one PUCCH resource in the PUCCH resource set configured using the RMSI, and transmits UCI by using the determined PUCCH resource.

The DCI may be, for example, DCI to schedule message <NUM> or message <NUM>, which has been described above.

<FIG> is a diagram to show examples of how to specify PUCCH resources, according to the first example. In <FIG>, PUCCH resources #<NUM> to #<NUM> are configured in a user terminal by using RMSI. As shown in <FIG>, each given field value in DCI may indicate one of PUCCH resources #<NUM> to #<NUM>, configured using RMSI.

In <FIG>, the user terminal determines one of PUCCH resources #<NUM> to #<NUM>, configured using RMSI, based on a given field value in DCI, and transmits UCI by using the determined PUCCH resource.

<FIG> is a diagram to show other examples of how to specify PUCCH resources, according to the first example. In <FIG>, PUCCH resources #<NUM> to #<NUM> are configured in a user terminal by using RMSI. As shown in <FIG>, each given field value in DCI is associated with a number of PUCCH resources in a PUCCH resource set, configured using RMSI.

In <FIG>, the user terminal determines one of PUCCH resources #<NUM> to #<NUM>, configured using RMSI, based on given field values in DCI and implicit index values, and transmits UCI by using the determined PUCCH resource.

The user terminal may derive an implicit index value based on, for example, at least one of a control channel element (CCE), the user terminal's identifier (UE-ID, and, for example, RNTI), and the number of PRBs to allocate to the PDSCH that transmits message <NUM> or <NUM>, which has been described above.

As shown in <FIG>, if each given field value in DCI is associated with X (X><NUM>, and X=<NUM> here) implicit index values, the user terminal can derive the implicit indices by using, for example, the following equations:<MAT><MAT><MAT>.

In <FIG>, among PUCCH resources #<NUM> to #<NUM> configured using RMSI, the user terminal transmits UCI by using PUCCH resources indicated by given field values in DCI.

Note that the PUCCH resources in the PUCCH resource set configured by RMSI may be limited based on given rules (for example, the PFs and/or the ranges may be limited as shown in <FIG>, a given number of PUCCH resources may be defined in advance, and so on).

In the second example, a given field value in RMSI may indicate a single PUCCH resource, among a given number of PUCCH resources determined in advance. A user terminal may determine the PUCCH resource set based on the PUCCH resource (or the index of the PUCCH resource) a given field value of RMSI indicates.

The user terminal determines one PUCCH resource in the PUCCH resource set based on a given field value in DCI, and transmits UCI by using the determined PUCCH resource.

<FIG> is a diagram to show the first example of how to determine a PUCCH resource set, according to the second example. In <FIG>, a given number of PUCCH resources (here, sixteen types of PUCCH resources #<NUM> to #<NUM>) are defined in advance in the specification. In <FIG>, one index is assigned (associated, linked, etc.) to one PUCCH resource. The given field values in RMSI may indicate indices that are associated with PUCCH resources.

For example, in <FIG>, a given field value of RMSI indicates an index "<NUM>," which is associated with PUCCH resource #<NUM>. The user terminal determines the PUCCH resource set based on this index. As shown in <FIG>, the user terminal may determine a PUCCH resource set to include PUCCH resources #<NUM> to #<NUM>, with <NUM>y indices that are contiguous from the index "<NUM>. " Here, y is the number of bits of the given field in DCI.

Based on given rules, the user terminal may associate each given field value in DCI with a PUCCH resource in the PUCCH resource set. For example, in <FIG>, the given field values "<NUM>," "<NUM>," "<NUM>," and "<NUM>" in DCI may be associated with PUCCH resources #<NUM>, #<NUM>, #<NUM>, and #<NUM> in the PUCCH resource set, respectively.

The user terminal may determine the PUCCH resources associated with (indicated by) the given field values in the DCI (which is, for example, DCI to schedule message <NUM> or <NUM>), and transmit UCI by using the PUCCH resources determined.

Note that the user terminal may determine one PUCCH resource in a PUCCH resource set that is determined based on a given field value in RMSI, without using the above-described given field values in DCI, but instead by using y-bit implicit indices. The implicit index values may be derived based on, for example, at least one of a CCE, a UE-ID, and the number of PRBs allocated to message <NUM> or <NUM>, which has been described above.

For example, the user terminal can derive the implicit indices by using the following equation:<MAT><MAT><MAT>.

Furthermore, the user terminal may determine one PUCCH resource in a PUCCH resource set that is determined based on a given field value in RMSI, by using the above-described given field values in DCI and the implicit indices. For example, some of the parameters in the parameter set shown in <FIG> (for example, at least one of the starting index of PRBs, the index of the initial CS and the index of time-domain OCC) may be explicitly specified (may be part of the PUCCH resources specified). The rest of the parameters may be derived implicitly.

<FIG> are diagrams to show second examples of how to determine a PUCCH resource set, according to the second example. In <FIG>, similar to <FIG>, a given field value of RMSI indicates an index associated with one of PUCCH resources #<NUM> to #<NUM>, defined in advance in the specification (here, index "<NUM>" associated with PUCCH resource #<NUM>).

As shown in <FIG>, the number of PUCCH resources in the PUCCH resource set determined based on the given field value of RMSI is determined based on the number y of bits of the given field in DCI. For example, the number of the PUCCH resources may be <NUM>y.

The number y of bits of the given field in DCI may vary depending on DCI format. For example, in the event DCI (also referred to as "fallback DCI" and so on) is allocated to a search space that is common to one or more user terminals (common search space), the above number of bits may be y=<NUM>. Also, in the event DCI is allocated to a user terminal-specific search space (also referred to as "non-fallback DCI" and so on), the above number of bits may be y=<NUM>. Therefore, the UE, when receiving fallback DCI, may refer to the applicable one bit of the fallback DCI, and, when receiving non-fallback DCI, may refer to the applicable two bits of the non-fallback DCI, and determine the PUCCH resource set. The number of bits above may assume other values.

For example, as shown in <FIG>, when the given field in the DCI is one bit, the user terminal may determine a PUCCH resource set that includes two PUCCH resources #<NUM> and #<NUM>, based on PUCCH resource #<NUM> indicated by the given field value of RMSI. In <FIG>, the DCI-induced overhead can be reduced.

For example, as shown in <FIG>, when the given field in the DCI is two bits, the user terminal may determine a PUCCH resource set that includes four PUCCH resources #<NUM> to #<NUM>, based on PUCCH resource #<NUM> indicated by the given field value of RMSI. In <FIG>, more types of PUCCH resources can be specified dynamically than in <FIG>, so that an effect of improving performance can be achieved.

<FIG> are diagrams to show third examples of how to determine a PUCCH resource set according to the second example. In <FIG>, similar to <FIG> and <FIG>, a given field value of RMSI indicates an index associated with one of PUCCH resources #<NUM> to #<NUM>, defined in advance in the specification (here, index "<NUM>" associated with PUCCH resource #<NUM>).

As shown in <FIG>, the number of bits of the above-described field in DCI may be y=<NUM>. In this case, the user terminal may determine a PUCCH resource set that includes one PUCCH resource #<NUM> indicated by the given field value of RMSI.

As shown in <FIG>, DCI in which the above given field value is y (y=<NUM>) bits (that is, DCI not including the above given field value) may be DCI to be allocated to a common search space (fallback DCI). Meanwhile, as shown in <FIG>, DCI in which the above given field value is y (y=<NUM>) bits may be DCI to be allocated to a user terminal-specific search space (non-fallback DCI). Therefore, the UE, when receiving fallback DCI, may not refer to the bit of the fallback DCI, and, when receiving non-fallback DCI, may refer to the applicable one bit of the non-fallback DCI, and determine the PUCCH resource set. The number of bits above may assume other values.

<FIG> is a diagram to show a fourth example of determineing PUCCH resources according to the second example. As shown in <FIG>, PUCCH resources #<NUM> to #<NUM> defined in advance in the specification may be comprised of PUCCH resources for short PUCCH (for example, PF <NUM>) and PUCCH resources for long PUCCH (for example, PF <NUM>).

For example, in <FIG>, PUCCH resources for short PUCCH and PUCCH resources for long PUCCH have neighboring index values. By this means, if the given field in DCI is y (y≥<NUM>) bits, PUCCH resources that are determined based on the given field value of RMSI include, equally, PUCCH resources for short PUCCH (in <FIG>, PUCCH resources #<NUM> and #<NUM>) and PUCCH resources for long PUCCH (in <FIG>, PUCCH resources #<NUM> and #<NUM>).

Accordingly, whether the given field value in RMSI indicates short PUCCH or long PUCCH, the given field value in DCI can specify short PUCCH or long PUCCH.

<FIG> provide diagrams that each show a fifth example of how to determine a PUCCH resource set according to the second example. <FIG> are different from <FIG> in that PUCCH resources #<NUM> to #<NUM>, which are defined in the specification in advance, include, unevenly, PUCCH resources for short PUCCH (for example, PF <NUM>) and PUCCH resources for long PUCCH (for example, PF <NUM>).

For example, in <FIG>, more PUCCH resources for short PUCCH are allocated to PUCCH resources having smaller index values, and more PUCCH resources for long PUCCH are allocated to PUCCH resources having smaller index values.

In <FIG>, the given field value of RMSI is subject to control, so that it is possible to control the number of PUCCH resources for short PUCCH and PUCCH resources for long PUCCH included in a PUCCH resource set.

For example, in <FIG>, the given field value of RMSI is set to "<NUM>," so that the user terminal can determine a PUCCH resource set that includes three PUCCH resources #<NUM> to #<NUM> for short PUCCH and one PUCCH resource #<NUM> for long PUCCH.

Meanwhile, in <FIG>, the given field value of RMSI is set to "<NUM>," so that the user terminal can determine a PUCCH resource set that includes one PUCCH resource #<NUM> for short PUCCH and three PUCCH resources #<NUM> to #<NUM> for long PUCCH.

However, the diagrams to show the fifth example of how to determine a PUCCH resource set according to the second example shown in <FIG> are not limited to these. For example, index <NUM> in <FIG> may be short PUCCH, and index <NUM> may be long PUCCH. By this means, short PUCCH can always be allocated in a specific cell, and, furthermore, long PUCCH can always be allocated in a specific cell.

Assuming a cell where the coverage is relatively small (small cell), the cell may be designed so as to allow all UEs to establish connections using short PUCCH, so that, by making the contents of the PUCCH resource set all short PUCCHs, resources for short PUCCH can be allocated to the UE from more candidates, and the communication quality of PUCCH can be improved.

Also, assuming a cell where the coverage is larger than that of a small cell (large cell), the cell may be designed on the assumption that the majority of UEs establish connections by using long PUCCH, so that, by making the contents of the PUCCH resource set all long PUCCHs, resources for long PUCCH can be allocated to UEs from more candidates, and the communication quality of PUCCH can be improved.

<FIG> is a diagram to show examples of possible given field values of RMSI according to the second example. As shown in <FIG>, the user terminal may assume that the indices of PUCCH resources to be specified by a given field value in RMSI are limited.

Based on the number y of bits of a given field in the DCI, for example, using the following equation, the user terminal may determine the indices of PUCCH resources specified by a given field value in RMSI. Here, m is a given subscript. Index=(<NUM>^y)·m, where m=<NUM>, <NUM>, <NUM>, <NUM>,.

For example, in <FIG>, y=<NUM> holds, and therefore indices #<NUM>, #<NUM>, #<NUM>, and #<NUM> of the PUCCH resources specified by a given field value in RMSI may be determined based on the above equation.

Alternatively, the user terminal may determine, on a fixed basis, the indices of PUCCH resources specified by a given field value in RMSI, regardless of the number y of bits of the given field in DCI.

As shown in <FIG>, the indices of PUCCH resources specified by a given field value in RMSI are limited, so that it is possible to reduce the number of bits of the given field, and reduce the overhead of RMSI. Also, the indices of PUCCH resources specified by a given field value in RMSI are limited, so that it is possible to allocate more candidate PUCCH resources while keeping the number of bits of RMSI the same, and improve the communication quality of PUCCH. For example, in the event the given field in RMSI is kept at four bits, limiting the indices that can be assigned by the RMSI to <NUM>, <NUM>, <NUM>, <NUM> and so forth would make it possible to allocate PUCCH resources to the UE from four times as many PUCCH resource candidates (in this case, <NUM> candidates).

In the second example, a PUCCH resource set to include one or more PUCCH resources is determined based on one PUCCH resource indicated by a given field value in RMSI. Therefore, the overhead of RMSI can be reduced compared to the case in which the PUCCH resource set is reported (configured) by using RMSI.

A third example is different from the second example, in which a given field value of RMSI indicates one PUCCH resource, in that the given field value indicates a number of PUCCH resources among a given number of PUCCH resources determined in advance.

In the third example, the user terminal may determine a PUCCH resource set that includes a number of PUCCH resources indicated by a given field value of RMSI. The user terminal determines one PUCCH resource in the PUCCH resource set based on a given field value in DCI, and transmits UCI by using the determined PUCCH resource.

<FIG> is a diagram to show the first example of how to determine a PUCCH resource set according to the second example. In <FIG>, a given number of PUCCH resources (here, <NUM> types of PUCCH resources #i-a to #i-d (<NUM>≤i≤<NUM>)) are defined in advance in the specification.

In <FIG>, one index is assigned (associated, linked. etc.) to a number of PUCCH resources. The given field values in RMSI may show indices that are associated with a number of PUCCH resources.

For example, in <FIG>, a given field value of RMSI indicates an index "<NUM>," which is associated with PUCCH resources #<NUM>-a to #<NUM>-d. The user terminal determines the PUCCH resource set based on this index. As shown in <FIG>, the user terminal may determine a PUCCH resource set that includes <NUM>y PUCCH resources #<NUM>-a to #<NUM>-d, associated with this index "<NUM>. " Here, y is the number of bits of the given field in DCI.

Based on given rules, the user terminal may associate each given field value in DCI with a PUCCH resource in the PUCCH resource set. For example, in <FIG>, the given field values "<NUM>," "<NUM>," "<NUM>," and "<NUM>" in DCI may be associated with PUCCH resources #<NUM>-a, #<NUM>-b, #<NUM>-c, and #<NUM>-d in the PUCCH resource set, respectively.

The user terminal may determine the PUCCH resources associated with (indicated by) the given field values in DCI (which is, for example, DCI to schedule message <NUM> or <NUM>), and transmit UCI by using the PUCCH resources determined.

Note that the user terminal may determine one PUCCH resource in a PUCCH resource set that is determined based on a given field value in RMSI, without using the above-described given field values in DCI, but instead by using y-bit implicit indices. The implicit index value can be derived in the same manner as in the second example.

<FIG> is a diagram to show a second example of how to determine PUCCH resources according to the third example. In <FIG>, as in <FIG>, a given field value in RMSI indicates an index associated with a number of PUCCH resources.

As shown in <FIG>, the number of PUCCH resources in the PUCCH resource set determined based on a given field value of RMSI is determined based on the number y of bits of the given field in DCI. For example, the number of the PUCCH resources may be <NUM>y.

The number y of bits of the given field in DCI may vary depending on DCI format. For example, in the event DCI (also referred to as "fallback DCI" and so on) is allocated to a common search space, the above number of bits may be y=<NUM>. Also, in the event DCI is allocated to a user terminal-specific search space (also referred to as "non-fallback DCI" and so on), the above number of bits may be y=<NUM>.

For example, as shown in <FIG>, if the given field in DCI is one bit, the user terminal may determine a PUCCH resource set that includes two PUCCH resources (for example, PUCCH resources #<NUM>-a and #<NUM>-b) associated with the index indicated by the given field value in RMSI (for example, "<NUM>"). 12A, the DCI-induced overhead can be reduced.

Furthermore, as shown in FIG. 12B, if the given field in DCI is two bits, the user terminal may determine a PUCCH resource set that includes four PUCCH resources (for example, PUCCH resources #<NUM>-a to #<NUM>-b) associated with the index indicated by the given field value in RMSI (for example, "<NUM>"). 12B, more types of PUCCH resources can be specified dynamically than in FIG. 12A, so that an effect of improving performance can be achieved.

<FIG> is a diagram to show a third example of how to determine a PUCCH resource set according to the second example. As shown in <FIG>, a number of PUCCH resources associated with the same index may be comprised of PUCCH resources for short PUCCH (for example, PF <NUM>) and PUCCH resources for long PUCCH (for example, PF <NUM>). In <FIG>, for the same index, PUCCH resources for short PUCCH and PUCCH resources for long PUCCH are associated at the same ratio.

For example, in <FIG>, a PUCCH resource for short PUCCH and a PUCCH resource for long PUCCH are associated with the same index. Also, in <FIG>, within multiple PUCCH resources associated with the same index, neighboring indices are assigned to PUCCH resources for short PUCCH and resources for long PUCCH.

By this means, if the given field in DCI is y (y≥<NUM>) bits, PUCCH resources that are determined based on the given field value of RMSI include, equally, PUCCH resources for short PUCCH (in <FIG>, PUCCH resources #<NUM>-a and #<NUM>-c) and PUCCH resources for long PUCCH (in <FIG>, PUCCH resources #<NUM>-b and #<NUM>-d).

Accordingly, whether the given field value of RMSI indicates short PUCCH or long PUCCH, the given field value in DCI can specify the short PUCCH or long PUCCH.

<FIG> is a diagram to show a fourth example of how to determine a PUCCH resource set according to the second example. <FIG> is different from <FIG> in that PUCCH resources for short PUCCH and PUCCH resources for long PUCCH may be associated with the same index, not only at the same ratio, but also at different ratios.

In <FIG>, the given field value in RMSI is subject to control, so that it is possible to control the number of PUCCH resources for short PUCCH and PUCCH resources for long PUCCH included in a PUCCH resource set.

For example, in <FIG>, the given field value of RMSI is set to "<NUM>," so that the user terminal can determine a PUCCH resource set that includes three PUCCH resources #2a to #2c for short PUCCH and one PUCCH resource #<NUM>-d for long PUCCH.

Meanwhile, in <FIG>, the given field value of RMSI is set to "<NUM>," so that the user terminal can determine a PUCCH resource set that includes one PUCCH resource #<NUM>-a for short PUCCH and three PUCCH resources #<NUM>-b to #<NUM>-d for long PUCCH.

With a fourth example of the present invention, a number of sets that each include a given number of PUCCH resources are selected. A given field value of RMSI may indicate a PUCCH resource in a set that is determined according to given rules.

As explained in the second example, a table that associates one PUCCH resource in each set, with an index, may be used. For example, the tables exemplified in <FIG> may be provided per set. A user terminal may look up the table of a set that is selected based on given rules, and determine a PUCCH resource set based on the index that is indicated by a given field value in RMSI.

Alternatively, as explained with the third example, a table that associates a number of PUCCH resources in each set, with indices, may be used. For example, the tables exemplified in <FIG> may be provided per set. A user terminal may look up the table of a set that is selected based on given rules, and determine a PUCCH resource set based on the index that is indicated by a given field value in RMSI.

As for the given rules, for example, at least one of following rules (<NUM>) to (<NUM>) may be used.

Rule (<NUM>) may be whether or not the center frequency fc is equal to or lower than (or lower than) a given threshold (for example, <NUM>). For example, when the center frequency fc is lower than a given threshold, a set to include more PUCCH resources for long PUCCH may be selected. On the other hand, when the center frequency fc exceeds a given threshold, a set to include more PUCCH resources for short PUCCH may be selected. This is because, in a high frequency band (for example, fc is greater than <NUM>), the path loss is large, and the coverage is likely to be small.

Rule (<NUM>) may be whether a carrier is a time division duplexing (TDD) carrier or a frequency division duplexing (FDD) carrier. For example, when an FDD carrier is used, a set to include more PUCCH resources for long PUCCH may be selected. On the other hand, when a TDD carrier is used, a set to include more PUCCH resources for short PUCCH may be selected. This is because a TDD carrier is assumed to have low latency and a high frequency, and the coverage is likely to be small.

Rule (<NUM>) may be based on RACH format (or the timing of random access preamble). For example, a set may be selected depending on whether the RACH format is dense or rural. Also, if a random access preamble is shorter than a given threshold (= the RACH format is dense), a set to include more PUCCH resources for short PUCCH may be selected. If the random access preamble is shorter than a given threshold (= the RACH format is rural), a set to include more PUCCH resources for long PUCCH may be selected.

In a fifth example of the present invention, the transmission bandwidth of UCI that is transmitted in PUCCH resources determined as described above will be described. Note that, in the fifth example, an HARQ-ACK in response to message <NUM> will be exemplified as this UCI, but this is by no means limiting.

An HARQ-ACK in response to message <NUM> may be transmitted in the initial active UL BWP described above. The DCI to schedule message <NUM> may indicate a PRB index in the initial active UL BWP. Note that the initial active UL BWP is configured by RMSI.

Alternatively, an HARQ-ACK in response to message <NUM> may be transmitted in an uplink BWP (current active UL BWP) that is for non-initial access and that corresponds to the downlink BWP that is currently in the active state (current active DL BWP).

The BWP adaptation may support PRACH in any UL BWP configuration. The same mechanism as initial access may be used to determine the PUCCH resource for an HARQ-ACK in response to message <NUM>. Also, an HARQ-ACK in response to message <NUM> for non-initial access may be transmitted based on user-specific RRC signaling and DCI, similar to a user-specific HARQ-ACK.

With a sixth example of the present invention, how to determine the timing (slot index) for transmitting UCI in PUCCH resources determined as described above will be described. Note that, in the sixth example, an HARQ-ACK in response to message <NUM> will be exemplified as this UCI, but this is by no means limiting.

The user terminal may determine a slot for transmitting this UCI by using at least one of a given field value of RMSI and a given field value in DCI. Alternatively, the user terminal may determine the slot for transmitting this UCI based on an implicit method. For example, the user terminal may determine the slot by using one of following methods (<NUM>) to (<NUM>).

Alternatively, (<NUM>) a given field value in DCI (for example, DCI to schedule message <NUM>) indicates the period (the number of slots) between message <NUM> and the HARQ-ACK in response to message <NUM>. For example, as shown in <FIG>, a given field value (also referred to as an "index," a "slot indicator," and so on) in DCI may be associated with the number of slots from message <NUM>.

Alternatively, (<NUM>) the period (the number of slots) between message <NUM> and the HARQ-ACK in response to message <NUM> may be indicated implicitly. For example, the user terminal may derive this period based on at least one of the CCE index, the UE-ID and the number of PRBs to allocate to the PDSCH for transmitting above message <NUM>. For example, these parameters may be modulooperated with the type X of the number of slots determined in advance.

Alternatively, (<NUM>) X types of patterns for the number of slots determined in advance may vary depending on PUCCH format. For example, when transmitting an HARQ-ACK in response to message <NUM> in short PUCCH, as shown in <FIG>, a table configured with a relatively small number of slots from message <NUM> may be used. This is because short PUCCH is required low latency and required to transmit HARQ-ACK at an early timing.

On the other hand, when transmitting an HARQ-ACK in response to message <NUM> in long PUCCH, as shown in <FIG>, a table in which the number of slots from message <NUM> is set larger than in <FIG> may be used. This is because low latency is not required for long PUCCH.

Alternatively, (<NUM>) the number of slots from message <NUM> may be determined, on a fixed basis, by PUCCH format. As shown in <FIG>, for example, when an HARQ-ACK in response to message <NUM> is transmitted in short PUCCH, the number of slots from message <NUM> may be zero, and, when this HARQ-ACK is transmitted in long PUCCH, the number of the slots may be four.

Note that the number of slots from message <NUM> may or may not be exact. The user terminal has only to transmit an HARQ-ACK in response to message <NUM> in an uplink slot that is available after an indicated number of slots. The user terminal can recognize in which slot the HARQ-ACK is transmitted, from the configuration information that is broadcast in SIB1 (for example, <NUM> HARQ-ACK by tdd-UL-DL-configuration).

Although cases of determineing PUCCH resources for use for transmitting UCI before RRC connection is set up have been described with the above examples, the present embodiment can be applied, even after RRC connection is established, as long as given conditions are fulfilled. For example, when fallback of PUCCH format is triggered, even after RRC connection is established, PUCCH resources (also referred to as "fallback PUCCH resources" and so on) can be determined based on the PUCCH resource determineion method (also referred to as "method for determineing PUCCH resources for initial access" and so on) according to present embodiment.

Furthermore, switching to the method for determineing PUCCH resources for initial access may be performed based on at least one of PUCCH format fallback (switching) command information and configuration information from the radio base station. At least one of the command information and the configuration information may be reported by a given bit (for example, one bit) in specific DCI.

At least one of the PUCCH format (PF) and PUCCH resources (PF/PUCCH resource) determined by the method according to the present embodiment can be assumed to be a PF/PUCCH resource to fulfill given quality (error detection rate). Consequently, when a fallback is commanded to the user terminal due to the deterioration of the communication quality of the user terminal, it is possible to improve the quality of UCI by determineing the PF/PUCCH resources by the method according to the present embodiment.

Now, the structure of a radio communication system according to the present embodiment will be described below. In this radio communication system, the radio communication methods according to the above-described embodiments are employed. Note that the radio communication methods according to the herein-contained embodiments may be each used alone, or at least two of them may be combined and used.

<FIG> is a diagram to show an exemplary schematic structure of a radio communication system according to the present embodiment. A radio communication system <NUM> can adopt carrier aggregation (CA) and/or dual connectivity (DC) to group a number of fundamental frequency blocks (component carriers) into one, where the LTE system bandwidth (for example, <NUM>) constitutes one unit. Note that the radio communication system <NUM> may be referred to as "SUPER <NUM>," "LTE-A, (LTE-Advanced)" "IMT-Advanced," "<NUM>," "<NUM>," "FRA (Future Radio Access)," "NR (New RAT (New Radio Access Technology))," and the like.

The radio communication system <NUM> shown in <FIG> includes a radio base station <NUM> that forms a macro cell C1, and radio base stations 12a to 12c that are placed within the macro cell C1 and that form small cells C2, which are narrower than the macro cell C1. Also, user terminals <NUM> are placed in the macro cell C1 and in each small cell C2. A structure in which different numerologies are applied between cells/within cells may be adopted here.

Here, a numerology refers to a communication parameter in the frequency direction and/or the time direction (for example, at least one of subcarrier spacing, the bandwidth, the length of a symbol, the length of CP (CP length), the length of a subframe, the time length of a TTI (TTI length), the number of symbols per TTI, the radio frame configuration, the filtering process, the windowing process, etc.). In the radio communication system <NUM>, for example, subcarrier spacings such as <NUM>, <NUM>, <NUM>, <NUM> and <NUM> may be supported.

The user terminals <NUM> can connect with both the radio base station <NUM> and the radio base stations <NUM>. The user terminals <NUM> may use the macro cell C1 and the small cells C2, which use different frequencies, at the same time, by means of CA or DC. Also, the user terminals <NUM> can execute CA or DC by using a number of cells (CCs) (for example, two or more CCs). Furthermore, the user terminals can use licensed-band CCs and unlicensed-band CCs as a number of cells.

Furthermore, the user terminals <NUM> can communicate based on time division duplexing (TDD) or frequency division duplexing (FDD) in each cell. A TDD cell and an FDD cell may be referred to as a "TDD carrier (frame structure type <NUM>)" and an "FDD carrier (frame structure type <NUM>)," respectively.

Furthermore, in each cell (carrier), a single numerology may be used, or a number of different numerologies may be used.

Between the user terminals <NUM> and the radio base station <NUM>, communication can be carried out using a carrier of a relatively low frequency band (for example, <NUM>) and a narrow bandwidth (referred to as, for example, an "existing carrier," a "legacy carrier," and/or the like). Meanwhile, between the user terminals <NUM> and the radio base stations <NUM>, a carrier of a relatively high frequency band (for example, <NUM>, <NUM>, <NUM> to <NUM> and so on) and a wide bandwidth may be used, or the same carrier as that used in the radio base station <NUM> may be used.

A structure may be employed here in which wire connection (for example, means in compliance with the CPRI (Common Public Radio Interface) such as optical fiber, the X2 interface and so on) or wireless connection is established between the radio base station <NUM> and the radio base station <NUM> (or between two radio base stations <NUM>).

Note that the radio base station <NUM> is a radio base station having a relatively wide coverage, and may be referred to as a "macro base station," a "central node," an "eNB (eNodeB)," a "gNB (gNodeB)," a "transmitting/receiving point (TRP)," and so on. Also, the radio base stations <NUM> are radio base stations each having a local coverage, and may be referred to as "small base stations," "micro base stations," "pico base stations," "femto base stations," "HeNBs (Home eNodeBs)," "RRHs (Remote Radio Heads)," "eNBs," "gNBs," "transmitting/receiving points" and so on. Hereinafter, the radio base stations <NUM> and <NUM> will be collectively referred to as "radio base stations <NUM>," unless specified otherwise.

The user terminals <NUM> are terminals that support various communication schemes such as LTE, LTE-A, <NUM>, NR and so on, and may not be limited to mobile communication terminals, and may be stationary communication terminals. Furthermore, the user terminals <NUM> can perform device-to-device (D2D) communication with other user terminals <NUM>.

In the radio communication system <NUM>, as radio access schemes, OFDMA (orthogonal Frequency Division Multiple Access) can be applied to the downlink (DL), and SC-FDMA (Single-Carrier Frequency Division Multiple Access) can be applied to the uplink (UL). OFDMA is a multi-carrier communication scheme to perform communication by dividing a frequency bandwidth into a number of narrow frequency bandwidths (subcarriers) and mapping data to each subcarrier. SC-FDMA is a single-carrier communication scheme to mitigate interference between terminals by dividing the system bandwidth into bands formed with one or continuous resource blocks per terminal, and allowing a number of terminals to use mutually different bands. Note that the uplink and downlink radio access schemes are not limited to the combination of these, and OFDMA may be used in the UL.

Also, in the radio communication system <NUM>, a multi-carrier waveform (for example, OFDM waveform) or a single-carrier waveform (for example, DFT-s-OFDM waveform) may be used.

In the radio communication system <NUM>, a DL shared channel (PDSCH (Physical Downlink Shared CHannel), also referred to as a "DL data channel" or the like), which is shared by each user terminal <NUM>, a broadcast channel (PBCH (Physical Broadcast CHannel)), downlink L1/L2 control channels and so on are used as DL channels. At least one of user data, higher layer control information, SIBs (System Information Blocks) and so forth is communicated by the PDSCH. Also, the MIB (Master Information Blocks) is communicated by the PBCH.

The L1/L2 control channels include DL control channels (such as PDCCH (Physical Downlink Control CHannel), EPDCCH (Enhanced Physical Downlink Control CHannel), etc.), PCFICH (Physical Control Format Indicator CHannel), PHICH (Physical Hybrid-ARQ Indicator CHannel) and so on. Downlink control information (DCI), including PDSCH and PUSCH scheduling information, is communicated by the PDCCH. The number of OFDM symbols to use for the PDCCH is communicated by the PCFICH. The EPDCCH is frequency-division-multiplexed with the PDSCH and used to communicate DCI and so on, like the PDCCH. HARQ retransmission control information (ACK/NACK) in response to the PUSCH can be communicated in at least one of the PHICH, the PDCCH and the EPDCCH.

In the radio communication system <NUM>, a UL shared channel (PUSCH (Physical Uplink Shared CHannel), also referred to as an "uplink shared channel" or the like), which is shared by each user terminal <NUM>, an uplink control channel (PUCCH (Physical Uplink Control CHannel)), a random access channel (PRACH (Physical Random Access CHannel)) and so on are used as UL channels. User data, higher layer control information and so on are communicated by the PUSCH. Uplink control information (UCI), including at least one of retransmission control information (ACK/NACK) in response to DL signals, channel state information (CSI) and so on, is communicated by the PUSCH or the PUCCH. By means of the PRACH, random access preambles for establishing connections with cells can be communicated.

<FIG> is a diagram to show an exemplary overall structure of a radio base station according to the present embodiment. A radio base station <NUM> has a number of transmitting/receiving antennas <NUM>, amplifying sections <NUM>, transmitting/receiving sections <NUM>, a baseband signal processing section <NUM>, a call processing section <NUM> and a communication path interface <NUM>. Note that one or more transmitting/receiving antennas <NUM>, amplifying sections <NUM> and transmitting/receiving sections <NUM> may be provided.

User data to be transmitted from the radio base station <NUM> to a user terminal <NUM> in DL is input from the higher station apparatus <NUM>, to the baseband signal processing section <NUM>, via the communication path interface <NUM>.

In the baseband signal processing section <NUM>, the user data is subjected to transmission processes, including a PDCP (Packet Data Convergence Protocol) layer process, division and coupling of the user data, RLC (Radio Link Control) layer transmission processes such as RLC retransmission control, MAC (Medium Access Control) retransmission control (for example, an HARQ (Hybrid Automatic Repeat reQuest) transmission process), scheduling, transport format selection, channel coding, an inverse fast Fourier transform (IFFT) process, a precoding process and so forth, and the result is forwarded to each transmitting/receiving section <NUM>. Furthermore, downlink control signals are also subjected to transmission processes such as channel coding and an inverse fast Fourier transform, and forwarded to the transmitting/receiving sections <NUM>.

Baseband signals that are precoded and output from the baseband signal processing section <NUM> on a per antenna basis are converted into a radio frequency band in the transmitting/receiving sections <NUM>, and then transmitted. The radio frequency signals having been subjected to frequency conversion in the transmitting/receiving sections <NUM> are amplified in the amplifying sections <NUM>, and transmitted from the transmitting/receiving antennas <NUM>.

A transmitting/receiving section <NUM> can be constituted by a transmitters/receiver, a transmitting/receiving circuit or transmitting/receiving apparatus that can be described based on general understanding of the technical field to which the present invention pertains. Note that a transmitting/receiving section <NUM> may be structured as a transmitting/receiving section in one entity, or may be constituted by a transmitting section and a receiving section.

Meanwhile, as for UL signals, radio frequency signals that are received in the transmitting/receiving antennas <NUM> are amplified in the amplifying sections <NUM>. The transmitting/receiving sections <NUM> receive the UL signals amplified in the amplifying sections <NUM>.

In the baseband signal processing section <NUM>, UL data that is included in the UL signals that are input is subjected to a fast Fourier transform (FFT) process, an inverse discrete Fourier transform (IDFT) process, error correction decoding, a MAC retransmission control receiving process, and RLC layer and PDCP layer receiving processes, and forwarded to the higher station apparatus <NUM> via the communication path interface <NUM>. The call processing section <NUM> performs call processing (such as setting up and releasing communication channels), manages the state of the radio base stations <NUM> and manages the radio resources.

The communication path interface section <NUM> transmits and receives signals to and from the higher station apparatus <NUM> via a given interface. Also, the communication path interface <NUM> may transmit and receive signals (backhaul signaling) with neighboring radio base stations <NUM> via an inter-base station interface (which is, for example, optical fiber in compliance with the CPRI (Common Public Radio Interface), the X2 interface, etc.).

Furthermore, the transmitting/receiving sections <NUM> transmit DL signals (including at least one of DL data signals, DL control signals and DL reference signals) to the user terminal <NUM>, and receive UL signals (including at least one of UL data signals, UL control signals and UL reference signals) from the user terminal <NUM>.

Also, the transmitting/receiving sections <NUM> receive UCI from the user terminal <NUM> by using an uplink shared channel (for example, PUSCH) or an uplink control channel (for example, short PUCCH and/or long PUCCH). This UCI may include at least one of an HARQ-ACK in response to a DL data channel (for example, PDSCH), CSI, an SR, beam identification information (for example, a beam index (BI)), and a buffer status report (BSR).

Also, the transmitting/receiving sections <NUM> may transmit control information about an uplink control channel (for example, short PUCCH, long PUCCH, and/or the like) (for example, at least one of the format, the number of PUCCH units in a slot, the size of a PUCCH unit, the method of multiplexing RS, the location where RS is allocated, whether or not RS is present, the density of RS, whether or not SRS is present, and the resource for an uplink control channel) by physical layer signaling (L1 signaling) and/or higher layer signaling.

Also, the transmitting/receiving sections <NUM> may transmit information about fallback (for example, the command information and/or configuration information described above).

<FIG> is a diagram to show an exemplary functional structure of a radio base station according to the present embodiment. Note that, although <FIG> primarily shows functional blocks that pertain to characteristic parts of the present embodiment, the radio base station <NUM> has other functional blocks that are necessary for radio communication as well. As shown in <FIG>, the baseband signal processing section <NUM> has a control section <NUM>, a transmission signal generation section <NUM>, a mapping section <NUM>, a received signal processing section <NUM> and a measurement section <NUM>.

The control section <NUM> controls the whole of the radio base station <NUM>. The control section <NUM> controls, for example, the generation of DL signals by the transmission signal generation section <NUM>, the mapping of DL signals by the mapping section <NUM>, the receiving processes (for example, demodulation) for UL signals by the received signal processing section <NUM> and the measurements by the measurement section <NUM>.

To be more specific, the control section <NUM> schedules user terminals <NUM>. To be more specific, the control section <NUM> may control scheduling and/or retransmission for the DL data and/or uplink shared channels based on UCI (for example, CSI and/or BI) from the user terminal <NUM>.

Also, the control section <NUM> may exert control so that the format of an uplink control channel (for example, long PUCCH and/or short PUCCH) is controlled, and control information related to this uplink control channel is transmitted.

Furthermore, the control section <NUM> may control PUCCH resources. To be more specific, the control section <NUM> may determine one or more PUCCH resources to configure in the user terminal <NUM>, from a given number of PUCCH resources that are defined in advance in the specification. In addition, the control section <NUM> may control at least one of generation and transmission of system information (for example, RMSI) indicating at least one of the determined PUCCH resources.

The control section <NUM> may control the received signal processing section <NUM> to perform receiving processes for the UCI from the user terminal <NUM> based on the format of the uplink control channel.

The transmission signal generation section <NUM> generates DL signals (including DL data signals, DL control signals, DL reference signals and so on) as commanded by the control section <NUM>, and outputs these signals to the mapping section <NUM>.

The transmission signal generation section <NUM> can be constituted by a signal generator, a signal generating circuit or signal generating apparatus that can be described based on general understanding of the technical field to which the present invention pertains.

The mapping section <NUM> maps the DL signal generated in the transmission signal generation section <NUM> to a radio resource, as commanded by the control section <NUM>, and outputs this to the transmitting/receiving sections <NUM>. The mapping section <NUM> can be constituted by a mapper, a mapping circuit or mapping apparatus that can be described based on general understanding of the technical field to which the present invention pertains.

The received signal processing section <NUM> performs receiving processes (for example, demapping, demodulation, decoding, etc.) of UL signals transmitted from the user terminals <NUM> (including, for example, a UL data signal, a UL control signal, a UL reference signal, etc.). To be more specific, the received signal processing section <NUM> may output the received signals, the signals after the receiving processes and so on, to the measurement section <NUM>. In addition, the received signal processing section <NUM> performs UCI receiving processes based on the uplink control channel format specified by the control section <NUM>.

Also, the measurement section <NUM> may measure the channel quality in UL based on, for example, the received power (for example, RSRP (Reference Signal Received Power)) and/or the received quality (for example, RSRQ (Reference Signal Received Quality)) of UL reference signals. The measurement results may be output to the control section <NUM>.

<FIG> is a diagram to show an exemplary overall structure of a user terminal according to the present embodiment. A user terminal <NUM> has a number of transmitting/receiving antennas <NUM> for MIMO communication, amplifying sections <NUM>, transmitting/receiving sections <NUM>, a baseband signal processing section <NUM> and an application section <NUM>.

Radio frequency signals that are received in multiple transmitting/receiving antennas <NUM> are amplified in the amplifying sections <NUM>. The transmitting/receiving sections <NUM> receive DL signals amplified in the amplifying sections <NUM>. The received signals are subjected to frequency conversion and converted into the baseband signal in the transmitting/receiving sections <NUM>, and output to the baseband signal processing section <NUM>.

In the baseband signal processing section <NUM>, the baseband signal that is input is subjected to an FFT process, error correction decoding, a retransmission control receiving process, and so on. The DL data is forwarded to the application section <NUM>. The application section <NUM> performs processes related to higher layers above the physical layer and the MAC layer, and so on. Also, the broadcast information is also forwarded to application section <NUM>.

Meanwhile, UL data is input from the application section <NUM> to the baseband signal processing section <NUM>. The baseband signal processing section <NUM> performs a retransmission control transmission process (for example, an HARQ transmission process), channel coding, rate matching, puncturing, a discrete Fourier transform (DFT) process, an IFFT process and so on, and the result is forwarded to each transmitting/receiving section <NUM>. UCI is also subjected to at least one of channel coding, rate matching, puncturing, a DFT process and an IFFT process, and the result is forwarded to each transmitting/receiving section <NUM>.

Baseband signals that are output from the baseband signal processing section <NUM> are converted into a radio frequency band in the transmitting/receiving sections <NUM>, and transmitted. The radio frequency signals that are subjected to frequency conversion in the transmitting/receiving sections <NUM> are amplified in the amplifying sections <NUM>, and transmitted from the transmitting/receiving antennas <NUM>.

Furthermore, the transmitting/receiving sections <NUM> receive DL signals (including DL data signals, DL control signals and DL reference signals) of the numerologies configured in the user terminal <NUM>, and transmit UL signals (including UL data signals, UL control signals and UL reference signals) of these numerologies.

Also, the transmitting/receiving sections <NUM> transmit UCI to the radio base station <NUM> by using an uplink shared channel (for example, PUSCH) or an uplink control channel (for example, short PUCCH and/or long PUCCH).

A transmitting/receiving sections <NUM> can be constituted by a transmitter/receiver, a transmitting/receiving circuit or transmitting/receiving apparatus that can be described based on general understanding of the technical field to which the present invention pertains. Furthermore, a transmitting/receiving sections <NUM> may be structured as one transmitting/receiving section, or may be formed with a transmitting section and a receiving section.

<FIG> is a diagram to show an exemplary functional structure of a user terminal according to the present embodiment. Note that, although <FIG> primarily shows functional blocks that pertain to characteristic parts of the present embodiment, the user terminal <NUM> has other functional blocks that are necessary for radio communication as well. As shown in <FIG>, the baseband signal processing section <NUM> provided in the user terminal <NUM> has a control section <NUM>, a transmission signal generation section <NUM>, a mapping section <NUM>, a received signal processing section <NUM>, and a measurement section <NUM>.

The control section <NUM> controls, for example, the generation of UL signals in the transmission signal generation section <NUM>, the mapping of UL signals in the mapping section <NUM>, the DL signal receiving processes in the received signal processing section <NUM>, the measurements in the measurement section <NUM> and so on.

In addition, the control section <NUM> controls the uplink control channel to use to transmit UCI from the user terminal <NUM> based on explicit indications from the radio base station <NUM> or based on implicit determineion in the user terminal <NUM>.

Also, the control section <NUM> may control the format of the uplink control channel (for example, long PUCCH and/or short PUCCH). The control section <NUM> may control the uplink control channel's format based on control information from the radio base station <NUM>. In addition, the control section <NUM> may control the PUCCH format (the uplink control channel format) to use to transmit UCI based on information that relates to fallback.

Furthermore, the control section <NUM> may determine the PUCCH resource to use in the PUCCH format based on higher layer signaling and/or downlink control information (third example).

To be more specific, when UCI is transmitted by using the uplink control channel before RRC (Radio Resource Control) connection is set up, the control section <NUM> may determine the resource for the uplink control channel to use to transmit the UCI based on a given field value in system information (for example, RMSI).

Furthermore, the control section <NUM> may determine the resource for the uplink control channel from a number of resources indicated by a given field value in system information, based on a given field value in downlink control information (first example).

Also, the control section <NUM> determines a resource set that includes one or more resources, based on an index indicated by a given field value in system information, and determine the resource for the uplink control channel, from the resource set, based on a given field value in downlink control information (second and third example).

The resource set may include resources with a given number of indices that are contiguous from the above index (second example). Alternatively, the resource set may include a given number of resources associated with the index (third example).

Also, the control section <NUM> may look up the table of a set ( or a table of the set) that is selected based on given rules, and determine a PUCCH resource set based on the index that is indicated by a given field value in RMSI (fourth example).

The control section <NUM> may control the random access procedures. To be more specific, the control section <NUM> may control the timing for transmitting an HARQ-ACK in response to message <NUM> (sixth example).

In the transmission signal generation section <NUM>, UL signals (including UL data signals, UL control signals, UL reference signals, UCI, etc.) are generated (including, for example, encoding, rate matching, puncturing, modulation, etc.) as commanded by the control section <NUM>, and output to the mapping section <NUM>. The transmission signal generation section <NUM> can be constituted by a signal generator, a signal generating circuit or signal generating apparatus that can be described based on general understanding of the technical field to which the present invention pertains.

The mapping section <NUM> maps the UL signals generated in the transmission signal generation section <NUM> to radio resources as commanded by the control section <NUM>, and output the result to the transmitting/receiving sections <NUM>. The mapping section <NUM> can be constituted by a mapper, a mapping circuit or mapping apparatus that can be described based on general understanding of the technical field to which the present invention pertains.

The received signal processing section <NUM> performs receiving processes (for example, demapping, demodulation, decoding, etc.) of DL signals (including DL data signals, scheduling information, DL control signals, DL reference signals, etc.). The received signal processing section <NUM> outputs the information received from the radio base station <NUM>, to the control section <NUM>. The received signal processing section <NUM> outputs, for example, broadcast information, system information, high layer control information related to higher layer signaling such as RRC signaling, physical layer control information (L1/L2 control information) and so on, to the control section <NUM>.

The received signal processing section <NUM> can be constituted by a signal processor, a signal processing circuit or signal processing apparatus that can be described based on general understanding of the technical field to which the present invention pertains. Also, the received signal processing section <NUM> can constitute the receiving section according to the present invention.

The measurement section <NUM> measures channel states based on reference signals (for example, CSI-RS) from the radio base station <NUM>, and outputs the measurement results to the control section <NUM>. Note that channel state measurements may be conducted per CC.

The measurement section <NUM> can be constituted by a signal processor, a signal processing circuit or signal processing apparatus, and a measurer, a measurement circuit or measurement apparatus that can be described based on general understanding of the technical field to which the present invention pertains.

Note that the block diagrams that have been used to describe the above embodiment show blocks in functional units. These functional blocks (components) may be implemented in arbitrary combinations of hardware and/or software. Also, the method for implementing each functional block is not particularly limited. That is, each functional block may be realized by one piece of apparatus that is physically and/or logically aggregated, or may be realized by directly and/or indirectly connecting two or more physically and/or logicallyseparate pieces of apparatus (by using cables and/or radio, for example) and using these multiple pieces of apparatus.

For example, the radio base station, user terminals and so on according to one embodiment of the present invention may function as a computer that executes the processes of the radio communication method of the present invention. <FIG> is a diagram to show an exemplary hardware structure of a radio base station and a user terminal according to one embodiment of the present invention. Physically, the above-described radio base stations <NUM> and user terminals <NUM> may be formed as a computer apparatus that includes a processor <NUM>, a memory <NUM>, a storage <NUM>, communication apparatus <NUM>, input apparatus <NUM>, output apparatus <NUM>, a bus <NUM> and so on.

Note that, in the following description, the term "apparatus" may be replaced by "circuit," "device," "unit" and so on. The hardware structure of a radio base station <NUM> and a user terminal <NUM> may be designed to include one or more of each apparatus shown in the drawings, or may be designed not to include part of the apparatus.

For example, although only one processor <NUM> is shown, a number of processors may be provided. Furthermore, processes may be implemented with one processor, or processes may be implemented simultaneously or in sequence, or by using different techniques, on one or more processors.

The functions of the radio base station <NUM> and the user terminal <NUM> are implemented by, for example, allowing hardware such as the processor <NUM> and the memory <NUM> to read given software (programs), and allowing the processor <NUM> to do calculations, control communication that involves the communication apparatus <NUM>, control the reading and/or writing of data in the memory <NUM> and the storage <NUM>, and so on.

The processor <NUM> may control the whole computer by, for example, running an operating system. The processor <NUM> may be constituted by a central processing unit (CPU), which includes interfaces with peripheral apparatus, control apparatus, computing apparatus, a register, and so on.

Furthermore, the processor <NUM> reads programs (program codes), software modules, data, and so forth from the storage <NUM> and/or the communication apparatus <NUM>, into the memory <NUM>, and executes various processes according to these. As for the programs, programs to allow computers to execute at least part of the operations of the above-described embodiment may be used. For example, the control section <NUM> of a user terminal <NUM> may be implemented by control programs that are stored in the memory <NUM> and that operate on the processor <NUM>, and other functional blocks may be implemented likewise.

The memory <NUM> is a computer-readable recording medium, and may be constituted by, for example, at least one of a ROM (Read Only Memory), an EPROM (Erasable Programmable ROM), an EEPROM (Electrically EPROM), a RAM (Random Access Memory), and other appropriate storage media. The memory <NUM> may be referred to as a "register," a "cache," a "main memory" (primary storage apparatus), and so on. The memory <NUM> can store executable programs (program codes), software modules and so on for implementing the radio communication methods according to embodiments of the present invention.

The storage <NUM> is a computer-readable recording medium, and may be constituted by, for example, at least one of a flexible disk, a floppy (registered trademark) disk, a magneto-optical disk (for example, a compact disc (CD-ROM (Compact Disc ROM) or the like), a digital versatile disc, a Blu-ray (registered trademark) disk, etc.), a removable disk, a hard disk drive, a smart card, a flash memory device (for example, a card, a stick, a key drive, etc.), a magnetic stripe, a database, a server, and/or other appropriate storage media.

The communication apparatus <NUM> is hardware (transmitting/receiving device) for allowing inter-computer communication by using cable and/or wireless networks, and may be referred to as, for example, a "network device," a "network controller," a "network card," a "communication module," and so on. The communication apparatus <NUM> may be configured in include a high frequency switch, a duplexer, a filter, a frequency synthesizer and so on, in order to implement, for example, frequency division duplex (FDD) and/or time division duplex (TDD). For example, the above-described transmitting/receiving antennas <NUM> (<NUM>), amplifying sections <NUM> (<NUM>), transmitting/receiving sections <NUM> (<NUM>), communication path interface <NUM> and so on may be implemented by the communication apparatus <NUM>.

The input apparatus <NUM> is an input device for receiving input from outside (for example, a keyboard, a mouse, a microphone, a switch, a button, a sensor and so on). The output apparatus <NUM> is an output device for allowing sending output to outside (for example, a display, a speaker, an LED (Light Emitting Diode) lamp, and so on).

Furthermore, these pieces of apparatus, including the processor <NUM>, the memory <NUM> and so on, are connected by the bus <NUM>, so as to communicate information.

Also, the radio base station <NUM> and the user terminal <NUM> may be structured to include hardware such as a microprocessor, a digital signal processor (DSP), an ASIC (Application-Specific Integrated Circuit), a PLD (Programmable Logic Device), an FPGA (Field Programmable Gate Array) and so on, and part or all of the functional blocks may be implemented by these pieces of hardware.

Note that, the terminology used in this specification and the terminology that is needed to understand this specification may be replaced by other terms that communicate the same or similar meanings. For example, a "channel" and/or a "symbol" may be replaced by a "signal" (or "signaling"). Also, a signal may be a message. A reference signal may be abbreviated as an "RS," and may be referred to as a "pilot," a "pilot signal" and so on, depending on which standard applies. Furthermore, a "component carrier (CC)" may be referred to as a "cell," a "frequency carrier," a "carrier frequency," and so on.

Furthermore, a radio frame may be comprised of one or more periods (frames) in the time domain. One or more periods (frames) that constitute a radio frame may be each referred to as a "subframe. " Furthermore, a subframe may be comprised of one or more slots in the time domain. A subframe may be a fixed time duration (for example, <NUM>), which does not depend on numerology.

Furthermore, a slot may be comprised of one or more symbols in the time domain (OFDM (Orthogonal Frequency Division Multiplexing) symbols, SC-FDMA (Single Carrier Frequency Division Multiple Access) symbols, and so on). Also, a slot may be a time unit based on numerology. Also, a slot may include a number of minislots. Each minislot may be comprised of one or more symbols in the time domain. Also, a minislot may be referred to as a "subslot.

A radio frame, a subframe, a slot, a minislot, and a symbol all refer to a unit of time in signal communication. A radio frame, a subframe, a slot, a minislot and a symbol may be each called by other applicable names. For example, one subframe may be referred to as a "transmission time interval (TTI)," or a number of contiguous subframes may be referred to as a "TTI," or one slot or mini-slot may be referred to as a "TTI. " That is, a subframe and/or a TTI may be a subframe (<NUM>) in existing LTE, may be a shorter period than <NUM> (for example, one to thirteen symbols), or may be a longer period of time than <NUM>. Note that the unit to represent a TTI may be referred to as a "slot," a "minislot" and so on, instead of a "subframe.

Here, a TTI refers to the minimum time unit for scheduling in radio communication, for example. For example, in LTE systems, a radio base station schedules the radio resources (such as the frequency bandwidth and transmission power each user terminal can use) to allocate to each user terminal in TTI units.

A TTI may be the transmission time unit of channel-encoded data packets (transport blocks), code blocks and/or codewords, or may be the unit of processing in scheduling, link adaptation, and so on. Note that, when a TTI is given, the period of time (for example, the number of symbols) in which transport blocks, code blocks and/or codewords are actually mapped may be shorter than the TTI.

Note that, when one slot or one minislot is referred to as a "TTI," one or more TTIs (that is, one or more slots or one or more minislots) may be the minimum time unit of scheduling. Also, the number of slots (the number of minislots) to constitute this minimum time unit for scheduling may be controlled.

A TTI having a time length of <NUM> may be referred to as a "normal TTI" (TTI in LTE Rel. <NUM> to <NUM>), a "long TTI," a "normal subframe," a "long subframe," and so on. A TTI that is shorter than a normal TTI may be referred to as a "shortened TTI," a "short TTI," a "partial TTI" (or a "fractional TTI"), a "shortened subframe," a "short subframe," a "minislot," a "sub-slot," and so on.

A resource block (RB) is the unit of resource allocation in the time domain and the frequency domain, and may include one or a number of contiguous subcarriers in the frequency domain. Also, an RB may include one or more symbols in the time domain, and may be one slot, one minislot, one subframe or one TTI in length. One TTI and one subframe each may be comprised of one or more resource blocks. Note that one or more RBs may be referred to as a "physical resource block (PRB (Physical RB))," a "subcarrier group (SCG)," a "resource element group (REG)," a "PRB pair," an "RB pair," and so on.

Note that the structures of radio frames, subframes, slots, minislots, symbols, and so on described above are simply examples. For example, configurations pertaining to the number of subframes included in a radio frame, the number of slots included in a subframe or a radio frame, the number of minislots included in a slot, the number of symbols and RBs included in a slot or a minislot, the number of subcarriers included in an RB, the number of symbols in a TTI, the symbol duration, the length of cyclic prefixes (CPs), and so on can be variously changed.

Also, the information and parameters described in this specification may be represented in absolute values or in relative values with respect to given values, or may be represented using other applicable information. For example, a radio resource may be indicated by a given index.

For example, data, instructions, commands, information, signals, bits, symbols and chips, all of which may be referenced throughout the herein-contained description, may be represented by voltages, currentdetermineromagnetic waves, magnetic fields or particles, optical fields or photons, or any combination of these.

Also, information, signals, and so on can be output from higher layers to lower layers, and/or from lower layers to higher layers. Information, signals, and so on may be input and/or output via a number of network nodes.

The information, signals, and so on that are input and/or output may be stored in a specific location (for example, in a memory), or may be managed in a control table. The information, signals, and so on that are input may be transmitted to other pieces of apparatus.

The method of reporting information is by no means limited to those used in the examples/embodiments described in this specification, and other methods may be used as well. For example, reporting of information may be implemented by using physical layer signaling (for example, downlink control information (DCI), uplink control information (UCI)), higher layer signaling (for example, RRC (Radio Resource Control) signaling, broadcast information (the master information block (MIB), system information blocks (SIBs) and so on), MAC (Medium Access Control) signaling, etc.), and other signals and/or combinations of these.

Note that physical layer signaling may be referred to as "L1/L2 (Layer <NUM>/Layer <NUM>) control information (L1/L2 control signals)," "L1 control information (L1 control signal)," and so on. Also, RRC signaling may be referred to as "RRC messages," and can be, for example, an "RRC connection setup message," "RRC connection reconfiguration message," and so on.

Also, reporting of given information (for example, reporting of information to the effect that "X holds") does not necessarily have to be sent explicitly, and can be sent in an implicit way (for example, by not reporting this piece of information, or by reporting another piece of information).

Decisions may be made in values represented by one bit (<NUM> or <NUM>), may be made in Boolean values that represent true or false, or may be made by comparing numerical values (for example, comparison against a given value).

Software, whether referred to as "software," "firmware," "middleware," "microcode," or "hardware description language," or called by other names, should be interpreted broadly, to mean instructions, instruction sets, code, code segments, program codes, programs, subprograms, software modules, applications, software applications, software packages, routines, subroutines, objects, executable files, execution threads, procedures, functions, and so on.

Also, software, instructions, information and so on may be transmitted and received via communication media. For example, when software is transmitted from a website, a server or other remote sources by using wired technologies (coaxial cables, optical fiber cables, twisted-pair cables, digital subscriber lines (DSL) and so on), and/or wireless technologies (infrared radiation, microwaves, and so on), these wired technologies and/or wireless technologies are also included in the definition of communication media.

As used herein, the terms "base station (BS)," "radio base station," "eNB," "gNB," "cell," "sector," "cell group," "carrier," and "component carrier" may be used interchangeably. A base station may be referred to as a "fixed station," a "NodeB," an "eNodeB (eNB)," an "access point," a "transmission point," a "receiving point," a "transmitting/receiving point," a "femto cell," a "small cell," and so on.

A base station can accommodate one or more (for example, three) cells (also referred to as "sectors"). When a base station accommodates a number of cells, the entire coverage area of the base station can be partitioned into multiple smaller areas, and each smaller area can provide communication services through base station subsystems (for example, indoor small base stations (RRHs (Remote Radio Heads))). The term "cell" or "sector" refers to part or all of the coverage area of a base station and/or a base station subsystem that provides communication services within this coverage.

As used herein, the terms "mobile station (MS)," "user terminal," "user equipment (UE)," and "terminal" may be used interchangeably.

A mobile station may be referred to as a "subscriber station," a "mobile unit," a "subscriber unit," a "wireless unit," a "remote unit," a "mobile device," a "wireless device," a "wireless communication device," a "remote device," a "mobile subscriber station," a "access terminal," a "mobile terminal," a "wireless terminal," a "remote terminal," a "handset," a "user agent," a "mobile client," a "client," or some other suitable terms.

A base station and/or a mobile station may be referred to as "transmitting apparatus," "receiving apparatus," and the like.

Furthermore, the radio base stations in this specification may be interpreted as user terminals. For example, each example/embodiment of the present invention may be applied to a configuration in which communication between a radio base station and a user terminal is replaced with communication among a number of user terminals (D2D (Device-to-Device)). In this case, user terminals <NUM> may have the functions of the radio base stations <NUM> described above. In addition, terms such as "uplink" and "downlink" may be interpreted as "side. " For example, an "uplink channel" may be interpreted as a "side channel.

Certain actions which have been described in this specification to be performed by base stations may, in some cases, be performed by their upper nodes. In a network comprised of one or more network nodes with base stations, it is clear that various operations that are performed so as to communicate with terminals can be performed by base stations, one or more network nodes (for example, MMEs (Mobility Management Entities), S-GWs (Serving-Gateways), and so on may be possible, but these are not limiting) other than base stations, or combinations of these.

The examples/embodiments illustrated in this specification may be used individually or in combinations, which may be switched depending on the mode of implementation. Also, the order of processes, sequences, flowcharts, and so on that have been used to describe the examples/embodiments herein may be reordered as long as inconsistencies do not arise.

The examples/embodiments illustrated in this specification may be applied to systems that use LTE (Long Term Evolution), LTE-A (LTE-Advanced), LTE-B (LTE-Beyond), SUPER <NUM>, IMT-Advanced, <NUM> (4th generation mobile communication system), <NUM> (5th generation mobile communication system), FRA (Future Radio Access), New-RAT (Radio Access Technology), NR (New Radio), NX (New radio access), FX (Future generation radio access), GSM (registered trademark) (Global System for Mobile communications), CDMA <NUM>, UMB (Ultra Mobile Broadband), IEEE <NUM> (Wi-Fi (registered trademark)), IEEE <NUM> (WiMAX (registered trademark)), IEEE <NUM>, UWB (Ultra-WideBand), Bluetooth (registered trademark), other adequate radio communication methods, and/or nextgeneration systems that are enhanced based on these.

The phrase "based on" as used in this specification does not mean "based only on" unless otherwise specified.

Reference to elements with designations such as "first," "second," and so on as used herein does not generally limit the number/quantity or order of these elements. These designations are used herein only for convenience, as a method for distinguishing between two or more elements. It follows that reference to the first and second elements does not imply that only two elements may be employed, or that the first element must precede the second element in some way.

For example, to "judge" and "determine" as used herein may be interpreted to mean making judgements and determinations related to calculating, computing, processing, deriving, investigating, looking up (for example, searching a table, a database, or some other data structure), ascertaining, and so on. Furthermore, to "judge" and "determine" as used in the present disclosure may be interpreted as meaning making judgements and determinations related to receiving (for example, receiving information), transmitting (for example, transmitting information), inputting, outputting, accessing (for example, accessing data in a memory) and so on. In addition, to "judge" and "determine" as used in the present disclosure may be interpreted as meaning making judgements and determinations related to resolving, selecting, choosing, establishing, comparing, and so on. In other words, to "judge" and "determine" as used in the present disclosure may be interpreted as meaning making judgements and determinations with regard to some action.

As used herein, the terms "connected" and "coupled," or any variation of these terms, mean all direct or indirect connections or coupling between two or more elements, and may include the presence of one or more intermediate elements between two elements that are "connected" or "coupled" to each other. The coupling or connection between the elements may be physical, logical, or a combination of these.

As used herein, when two elements are connected, these elements may be considered "connected" or "coupled" to each other by using one or more electrical wires, cables, and/or printed electrical connections, and, as a number of nonlimiting and non-inclusive examples, by using electromagnetic energy having wavelengths of the radio frequency region, the microwave region and/or the optical region (both visible and invisible).

In the present specification, the phrase "A and B are different" may mean "A and B are different from each other. " The terms such as "leave," "coupled" and the like may be interpreted likewise.

Claim 1:
A terminal (<NUM>) comprising:
a receiving section (<NUM>) configured to receive a contention resolution message in a random access procedure; and
a control section (<NUM>) configured to control to transmit a Hybrid Automatic Repeat reQuest-Acknowledge, HARQ-ACK, in response to the contention resolution message by using a PUCCH in an initial active Uplink Bandwidth Part, UL BWP,
characterized in that the control section (<NUM>) is configured to assume that a pair of a Physical Resource Block, PRB, index of the PUCCH in a first hop and a PRB index of the PUCCH in a second hop is defined differently for each PUCCH format, and
wherein the control section (<NUM>) is configured to determine the PRB index in the first hop and the PRB index in the second hop, based on a size of the initial active UL BWP.