Terminal, wireless communication method, and wireless communication system

Abstract

A terminal comprising: a control unit which determines uplink control information on the basis of the presence or absence of support for transmission of first information that specifies the occasion of an unused uplink signal, the support being defined according to the fact of being an unlicensed spectrum or the fact that a specific control parameter has been set; and a transmission unit which transmits the uplink control information.

Description

Terminal, wireless communication method, and wireless communication system

[0001] The present disclosure relates to a terminal, a wireless communication method, and a wireless communication system.

[0002] Long Term Evolution (LTE) has been specified for Universal Mobile Telecommunication System (UMTS) networks to achieve higher data rates and lower latency. Furthermore, successor systems to LTE are also being considered to achieve even greater bandwidth and speed than LTE. Examples of successor systems to LTE include LTE-Advanced (LTE-A), Future Radio Access (FRA), 5th generation mobile communication system (5G), 5G plus (5G+), Radio Access Technology (New-RAT), and New Radio (NR).

[0003] In 5G, various wireless technologies and network architectures are being studied to meet the requirements of achieving a throughput of 10 Gbps or more while reducing wireless section latency to 1 ms or less (for example, Non-Patent Document 1).

[0004] In NR, Release 16 specifies the configuration of a configured grant physical uplink shared channel (CG PUSCH) (see, for example, Non-Patent Document 2). The CG PUSCH includes a Type 1 CG PUSCH and a Type 2 CG PUSCH.

[0005] Release 17 examines Extended Reality (XR), including virtual reality (VR) and mixed reality (MX), and examines XR scenarios, requirements, key performance indicators (KPIs), and evaluation methods. It also considers the target requirements for XR, including capacity, latency, mobility, and energy efficiency.

[0006] In addition, at the RAN1 #111 meeting, it was agreed to support CG enhancements for XR in Release 18. Specifically, dynamic indication of one or more unused (or unused) CG PUSCH occasions (transmission opportunities) by a terminal based on Uplink Control Information (UCI) (e.g., CG-UCI or new UCI) is being considered.

[0007] TS38.213 V16.3.0 (2020-09)TS38.331 V16.2.0 (2020-09)

[0008] There is room for consideration as to how to indicate unused CG PUSCH occasions.

[0009] One aspect of the present disclosure is to provide a terminal, a wireless communication method, and a wireless communication system that can appropriately report dynamic indication of unused CG PUSCH occasions to a base station.

[0010] A terminal according to one aspect of the present disclosure includes a control unit that determines uplink control information based on whether or not transmission of first information indicating an occasion for an unused uplink signal is supported, the first information being determined depending on whether the spectrum is unlicensed or a specific control parameter is set, and a transmission unit that transmits the uplink control information.

[0011] FIG. 1 is a diagram illustrating an example of dual connectivity (DC). FIG. 2 is a diagram illustrating an example of PUCCH carrier switching. FIG. 3 is a diagram illustrating an overview of Type 1 HARQ-ACK CB. FIG. 4 is a diagram illustrating an overview of Type 2 HARQ-ACK CB. FIG. 5 is a diagram illustrating an example of generating a Type 1 HARQ-ACK CB. FIG. 6 is a diagram illustrating an example of generating a Type 1 HARQ-ACK CB. FIG. 7 is a diagram illustrating an example of determining candidate PDSCH reception opportunities in Step A-2. FIG. 8 is a diagram illustrating an example of a CG PUSCH. FIG. 9 is a block diagram illustrating an example of the configuration of a base station according to the present embodiment. FIG. 10 is a block diagram illustrating an example of the configuration of a terminal according to the present embodiment. FIG. 11 is a diagram illustrating an example of the hardware configuration of a base station and a terminal according to an embodiment of the present disclosure. FIG. 12 is a diagram illustrating an example of the configuration of a vehicle in an embodiment of the present invention.

[0012] Hereinafter, an embodiment according to one aspect of the present disclosure will be described with reference to the drawings.

[0013] In NR, Release 17 is studying various technologies for systems called Ultra-Reliable and Low Latency Communications (URLLC) and Industrial Internet of Things (IIoT). URLLC considers enhancing the terminal feedback function for Hybrid Automatic Repeat request-Acknowledgement (HARQ-ACK). HARQ-ACK is an example of information for acknowledgment (e.g., acknowledgment) for data received by the terminal. For these URLLC considerations, it was agreed to support dynamic and semi-static PUCCH carrier switching. Note that PUCCH carrier switching may also be called by other names, such as carrier switching for control information transmission.

[0014] PUCCH carrier switching is a technique applied when a base station communicates via multiple cells. Dual connectivity, which is an example of communication via multiple cells, and PUCCH carrier switching will be described below.

[0015] <Dual Connectivity> Figure 1 is a diagram showing an example of dual connectivity (DC). In the example of Figure 1, the base station 10-1 may be a master node (MN). The base station 10-2 may be a secondary node (SN). As shown in the example of Figure 1, in DC, carriers between different base stations are aggregated.

[0016] 1, the base station 10-1 communicates with the terminal 20 via a primary cell (Pcell) and a secondary cell (Scell). In the example of Fig. 1, the terminal 20 establishes an RRC connection with the base station 10-1.

[0017] In the case of DC, since there may be a delay in communication between the base station 10-1 and the base station 10-2, it is difficult to notify the base station 10-2 of uplink control information (e.g., Uplink Control Information (UCI)) received in the Pcell of the base station 10-1 via a backhaul link (e.g., a wired or wireless link connecting the base station 10-1 and the base station 10-2) and reflect it in the scheduling of the Scell ​​under the base station 10-2. Therefore, in DC, in addition to the Pcell of the base station 10-1, one carrier under the base station 10-2 may be set as a Primary Scell ​​(PScell), and PUCCH transmission may be supported by the PScell. In this case, the terminal 20 transmits UCI to the base station 10-2 via the PScell.

[0018] In the example of FIG. 1, the terminal 20 configures an Scell ​​in addition to a Pcell for the base station 10-1. The terminal 20 also configures an Scell ​​in addition to a PScell ​​for the base station 10-2. The terminal 20 transmits UCI of each carrier under the control of the base station 10-1 on the PUCCH of the Pcell. The terminal 20 also transmits UCI of each carrier under the control of the base station 10-2 on the PUCCH of the PScell. In the example of FIG. 1, the cell group (CG) under the control of the base station 10-1 may be referred to as a Master Cell-Group (MCG). The cell group under the control of the base station 10-2 may be referred to as a Secondary Cell-Group (SCG).

[0019] When DC is performed, terminal 20 may transmit PUCCH via a Pcell, a PScell, and / or a PUCCH-Scell. Generally, it is not expected that terminal 20 transmits PUCCH via an Scell ​​other than a Pcell, a PScell, and a PUCCH-Scell.

[0020] <PUCCH Carrier Switching> PUCCH carrier switching is being studied as a method for reducing the latency of HARQ-ACK feedback in the Time Division Duplex (TDD) system.

[0021] Fig. 2 is a diagram showing an example of PUCCH carrier switching. In the example of Fig. 2, a base station and a terminal communicate via cell 1 and cell 2. In the example of Fig. 2, cell 1 is a Pcell, and cell 2 is an Scell. The example of Fig. 2 also shows downlink (DL) slots and uplink (UL) slots in each cell.

[0022] In the example of FIG. 2 , the terminal receives data at timing S101 (receives a Physical Downlink Shared Channel (PDSCH)). The terminal attempts to transmit a HARQ-ACK for the data received at timing S101 at timing S102, but at timing S102, the slot of cell 1 is a downlink (DL) slot. Therefore, when the terminal transmits a HARQ-ACK in cell 1, the transmission of the HARQ-ACK is postponed until the transmission timing of a PUCCH in an uplink (UL) slot (e.g., timing S103 in FIG. 2 ), thereby increasing the latency of the HARQ-ACK transmission. Note that the transmission timing of a PUCCH in an uplink (UL) slot may be referred to as a PUCCH occasion.

[0023] In the example of Fig. 2, at timing S102, the slot of cell 2 is a UL slot. In the example of Fig. 2, if the terminal can transmit a HARQ-ACK for the data received at S101 in the PUCCH occasion at timing S102 of cell 2, the latency of the HARQ-ACK transmission can be reduced. URLLC requires low latency, particularly in the wireless section. For this reason, 3GPP (registered trademark) is considering PUCCH carrier switching, in which a terminal switches the carrier on which it transmits PUCCH, as an extension of URLLC technology.

[0024] In the following embodiments, "the same timing" may mean the exact same timing, or may mean that all or part of a time resource (for example, one or more symbols (which may be a resource with a time unit shorter than a symbol)) is the same or overlaps.

[0025] PUCCH carrier switching may refer to the case where, when a terminal attempts to transmit a PUCCH at a specific transmission timing of a Pcell (which may be a PScell ​​or a PUCCH-Scell), the slot of the specific transmission timing of the Pcell (which may be a PScell ​​or a PUCCH-Scell) is a DL slot, and therefore the terminal switches the cell from which the PUCCH is transmitted from the Pcell (which may be a PScell ​​or a PUCCH-Scell) to one of one or more Scells in which the slot with the same timing as the specific transmission timing is a UL slot (in the case of a PScell, an Scell ​​other than the PScell, and in the case of a PUCCH-Scell, an Scell ​​other than the PUCCH-Scell). Note that, in embodiments of the present invention, the unit of the specific transmission timing is not limited to a slot. For example, the specific transmission timing may be a timing in units of a subframe or a timing in units of a symbol.

[0026] Two methods are being considered for realizing PUCCH carrier switching. The first method is a method in which a base station dynamically instructs a terminal on a carrier for transmitting the PUCCH. The second method is a method in which a base station semi-statically sets a terminal on a carrier for transmitting the PUCCH. Note that in the following embodiments, "transmitting a PUCCH" and "transmitting a PUCCH" may refer to transmitting uplink control information via a PUCCH.

[0027] The terminal may notify the base station of terminal capability information (UE capability) that defines information about the terminal's capabilities regarding PUCCH transmission.

[0028] For example, information indicating whether the terminal supports switching of settings related to transmission of control information may be defined as the terminal capability information of the terminal. Switching of settings related to transmission of control information may be, for example, switching of resources (e.g., carriers or cells) used for transmitting the control information. Switching of resources used for transmitting the control information may be referred to as "PUCCH carrier switching." Furthermore, information indicating application of dynamic PUCCH carrier switching and / or semi-static PUCCH carrier switching may be defined as the terminal capability information of the terminal.

[0029] The configuration operation of the quasi-static PUCCH carrier switching may be based on the RRC (Radio Resource Control) setting of the PUCCH cell timing pattern of the PUCCH cell to which the quasi-static PUCCH carrier switching is applied, and the configuration operation of the quasi-static PUCCH carrier switching may be supported between cells of different numerologies.

[0030] In PUCCH carrier switching, PUCCH resources may be configured for each UL BWP (Uplink Bandwidth Part) (for example, for each candidate cell and the UL BWP of the candidate cell).

[0031] In the case of PUCCH carrier switching based on dynamic instruction of control information, the K1 value (offset) from PDSCH to HARQ-ACK may be interpreted based on the numerology of the dynamically instructed target PUCCH cell. Note that the control information may be control information for scheduling PUCCH, such as Downlink control information (DCI). The numerology may also be considered as slot or Subcarrier Spacing (SCS).

[0032] In URLLC, enhancements to the HARQ-ACK Codebook (HARQ-ACK CB) feedback function of a terminal are being considered. Below, an overview of Type 1 HARQ-ACK CB and Type 2 HARQ-ACK CB is explained (see Non-Patent Document 1 for details).

[0033] Note that Type 1 HARQ-ACK CB may be referred to as semi-static HARQ-ACK CB. Type 2 HARQ-ACK CB may be referred to as dynamic HARQ-ACK CB. The terminal may be instructed which of Type 1 HARQ-ACK CB or Type 2 HARQ-ACK CB to apply by higher layer signaling such as RRC (Radio Resource Control).

[0034] <Type 1 HARQ-ACK CB> Fig. 3 is a diagram illustrating an overview of Type 1 HARQ-ACK CB. "Scheduled" shown in Fig. 3 indicates, for example, a slot scheduled by DCI. CC indicates Component Carrier.

[0035] In Type 1 HARQ-ACK CB, the terminal generates a HARQ-ACK bit for the PDSCH regardless of whether a scheduled slot (PDSCH) exists. For example, the terminal may set a NACK for an unscheduled PDSCH, as shown in the "HARQ-ACK codebook" in FIG. 3.

[0036] <Type 2 HARQ-ACK CB> Figure 4 is a diagram illustrating an overview of Type 2 HARQ-ACK CB. (x, y) in Figure 4 indicates, for example, a slot scheduled by DCI. x corresponds to the C-DAI value, and y corresponds to the T-DAI value. DAI stands for Downlink Assignment Index. DAI indicates, for example, the allocation of a scheduled PDSCH in which HARQ-ACK is bundled into the HARQ-ACK CB.

[0037] In Type 2 HARQ-ACK CB, the terminal generates HARQ-ACK bits for the scheduled PDSCH. For example, the terminal may configure HARQ-ACK for the scheduled PDSCH as shown in the "HARQ-ACK codebook" in FIG. 4.

[0038] Note that C-DAI counts up from 1. For example, in the case of a 2-bit field, C-DAI repeats 1->2->3->0->... C-DAI is counted up for each slot at each opportunity to receive DCI for each CC, and even if the slot changes, it is counted up from the final value of the previous slot. T-DAI indicates the final value of C-DAI for each slot.

[0039] Next, an example of generating a Type 1 HARQ-ACK CB will be described.

[0040] <Type 1 HARQ-ACK CB Generation> Figures 5, 6, and 7 are diagrams explaining examples of generating a Type 1 HARQ-ACK CB. In Figure 5, it is assumed that the numerology of the serving cell and the numerology of the PUCCH cell are the same. In Figure 5, the set of K1 (offset from PDSCH to HARQ-ACK) is {1, 2, 3, 4}.

[0041] In Figure 6, it is assumed that the numerology of the serving cell and the numerology of the PUCCH cell are different. In Figure 6, the set of K1 is {1, 2, 3, 4, 5}.

[0042] The terminal may generate the HARQ-ACK CB based on the following Step A, Step A-1, Step A-2, and Step B.

[0043] Step A: The terminal determines a HARQ-ACK occasion for candidate PDSCH reception. For example, the terminal determines slot n+4 of the PUCCH cell in Fig. 5. For example, the terminal determines slot n+5 of the PUCCH cell in Fig. 6.

[0044] Step A-1: ​​The terminal determines the PDSCH slot window based on the K1 set. For example, the terminal interprets the K1 set in the numerology of the PUCCH cell and determines the PDSCH slot window shown in the dotted frame in Figure 5 or 6.

[0045] Step A-2: The terminal determines candidate PDSCH reception occasions for each K1 in each slot. For example, the terminal determines candidate PDSCH reception occasions for each K1 in FIG. A,c As shown in Figure 1, candidate PDSCH reception opportunities are determined for each slot.

[0046] Note that the candidate PDSCH reception opportunities are related to a set RI (Row index) in the Time Domain Resource Allocation (TDRA) table, as will be explained in Figure 8. Candidate PDSCH reception opportunities in the TDRA table that overlap with the UL configured by TDD-UL-DL-ConfigurationCommon and TDD-UL-DL-ConfigDedicated are excluded. For candidate PDSCH reception opportunities that overlap in the time domain, the candidate PDSCH reception opportunities are determined based on specific rules.

[0047] Step B: The terminal may determine (generate) a HARQ-ACK (HARQ-ACK information bit, HARQ-ACK CB) for each element of the determined candidate PDSCH reception opportunity. For example, the terminal may determine (generate) a HARQ-ACK (HARQ-ACK information bit, HARQ-ACK CB) for each element of the determined candidate PDSCH reception opportunity. ACK In step S100, the next Type 1 HARQ-ACK CB may be generated.

[0048] Fig. 8 is a diagram illustrating an example of determining candidate PDSCH reception opportunities in Step A-2. The table shown in the upper left of Fig. 8 shows an example of TDRA. K0 indicates the offset between the DCI slot and the PDSCH slot. Start indicates the start symbol in the slot, and Length indicates the length from Start (the number of symbols allocated to the PDSCH). Mapping Type relates to the mapping type, which includes information about a symbol that can be set as the start symbol of the PDSCH in the slot.

[0049] The slot format is shown in the upper right corner of Figure 8. In the example slot format shown in Figure 8, the last two symbols are semi-statically configured as UL.

[0050] The candidate PDSCH reception opportunities based on RI 0-8 of the TDRA shown in the upper left of Figure 8 are as shown in the upper right of Figure 8. However, candidate PDSCH reception opportunities in the TDRA table that overlap with the UL are excluded.

[0051] Therefore, candidate PDSCH reception opportunities in RI2, RI3, and RI8 that overlap with the UL are excluded, and the candidate PDSCH reception opportunities in a certain slot are as shown in the lower right of Figure 8. That is, HARQ-ACKs in RI2, RI3, and RI8 are excluded from the generation set of HARQ-ACK CB.

[0052] For candidate PDSCH reception opportunities that overlap in the time domain, the candidate PDSCH reception opportunities are determined based on a specific rule. Therefore, the final candidate PDSCH reception opportunities are as shown in the lower left of Figure 8, and M A,c is M A,c = {0,1,2,3}.

[0053] <CG PUSCH> As described above, in NR, the configuration of the CG PUSCH is specified in Rel-16 (for example, Non-Patent Document 2). The CG PUSCH includes Type 1 CG PUSCH and Type 2 CG PUSCH.

[0054] Type 1 CG PUSCH The transmission parameters of Type 1 CG PUSCH are provided by "configuredGrantConfig", "pusch-Config", and "rrc-ConfiguredUplinkGrant". Activation and deactivation of Type 1 CG PUSCH depend on the RRC-configuration and are independent of Downlink Control Information (DCI).

[0055] Type 2 CG PUSCH The transmission parameters of the Type 2 CG PUSCH are provided by "configuredGrantConfig", "pusch-Config", and "activation DCI". Activation and deactivation of the Type 2 CG PUSCH depend on the RRC-configuration and DCI. One DCI can activate one CG PUSCH and deactivate multiple CG PUSCHs.

[0056] As mentioned above, XR is being considered in Release 17, and the target requirements for XR are to take into account capacity, latency, mobility, and energy saving. Therefore, it is assumed that CG PUSCH will be applied to XR services, and that multiple CGs will be used for one XR packet transmission.

[0057] 9 is a diagram illustrating an example of a CG PUSCH. The higher layer parameters cg-nrofSlots and cg-nrofPUSCH-InSlot are provided to a terminal. cg-nrofSlots indicates the number of consecutive slots allocated in a configured CG cycle. cg-nrofPUSCH-InSlot indicates the number of consecutive PUSCH allocations within a slot. FIG. 9 shows an example where cg-nrofSlots = 3 and cg-nrofSlots = 2. The period of the CG PUSCH configuration (the period during which the CG PUSCH is transmitted, for example, 3 slots shown in FIG. 9) is repeated in the configured CG cycle.

[0058] The first PUSCH allocation is based on higher layer configuration based on TDRA or TS38.321 in Type 1 CG PUSCH, or based on UL grant received in DCI in Type 2 CG PUSCH. The remaining PUSCH allocations have the same length and mapping type as the first PUSCH. Each PUSCH is appended without gaps after the previous PUSCH.

[0059] <CG-UCI for Unlicensed Spectrum> In the current specification, regarding the transmission of CG-UCI in the CG PUSCH, TS (technical specification) 38.212 specifies that CG-UCI is transmitted in the CG PUSCH when the upper layer parameter "cg-RetransmissionTimer" is configured. Here, cg-RetransmissionTimer is an example of a specific parameter. cg-RetransmissionTimer indicates information about the retransmission timer to be configured. cg-RetransmissionTimer is configured together with the upper layer parameter "harq-ProcID-Offset." cg-RetransmissionTimer is not configured for operation in licensed spectrum, or is not configured simultaneously with the upper layer parameter "harq-ProcID-Offset2." Note that licensed spectrum corresponds to a band that requires a license to use. On the other hand, unlicensed spectrum refers to bands that do not require a license to be used.

[0060] In other words, not configuring the cg-RetransmissionTimer may correspond to the terminal operating in a licensed spectrum. In other words, configuring the cg-RetransmissionTimer may correspond to the terminal not operating in a licensed spectrum. Not operating in a licensed spectrum may correspond to the terminal operating in an unlicensed spectrum.

[0061] Furthermore, since cg-RetransmissionTimer is set together with harq-ProcID-Offset, the setting of cg-RetransmissionTimer may correspond to the setting of harq-ProcID-Offset. Furthermore, since cg-RetransmissionTimer is not set at the same time as harq-ProcID-Offset2, the setting of cg-RetransmissionTimer may correspond to the setting of harq-ProcID-Offset2, and the setting of cg-RetransmissionTimer may correspond to the setting of harq-ProcID-Offset2.

[0062] <Multiplexing of UCI in PUSCH> For UCI reported by a terminal in a PUSCH, an offset value for determining the number of resources for multiplexing HARQ-ACK information in the PUSCH and an offset value for determining the number of resources for multiplexing a CSI (Channel State Information) report in the PUSCH are defined.

[0063] It is assumed that the CSI report is divided into two parts. Hereinafter, the two parts of the CSI report may be referred to as Part 1 CSI report and Part 2 CSI report. Alternatively, the two parts of the CSI report may be referred to as CSI part 1 and CSI part 2. Furthermore, the HARQ-ACK information may be simply referred to as HARQ-ACK. Note that the HARQ ACK, CSI part 1, and CSI part 2 may be referred to as HARQ ACK bits, CSI part 1 bits, and CSI part 2 bits. Note that the HARQ ACK bits, CSI part 1 bits, and CSI part 2 bits may each be 1-bit information or multiple-bit information.

[0064] In the current specifications, in transmitting a CG PUSCH, the multiplexed HARQ-ACK, CSI part 1, and CSI part 2 are coded separately. Furthermore, the resources for the multiplexed HARQ-ACK, CSI part 1, and CSI part 2 are determined separately.

[0065] In addition, in the current specifications, in transmitting a CG PUSCH, the CG-UCI is jointly encoded with the HARQ-ACK (for example, joint encoding), and resources are determined for the jointly encoded CG-UCI and HARQ-ACK.

[0066] Furthermore, in the current specifications, a priority is assigned to each UCI in rate matching. For example, in transmitting a CG PUSCH, among the multiplexed HARQ-ACK, CSI part 1, and CSI part 2, the priority of HARQ-ACK is higher than CSI part 1 and CSI part 2, and the priority of CSI part 1 is higher than CSI part 2. Furthermore, when CG-UCI and HARQ-ACK are coded together, the priority of CG-UCI and HARQ-ACK is higher than CSI part 1 and CSI part 2.

[0067] <Regarding new CG-UCI reporting> In Release 16, CG-UCI was introduced along with CG PUSCH in unlicensed spectrum to report CG PUSCH information.

[0068] Furthermore, in the field of XR in Release 18, it has been studied that a terminal reports a dynamic indication of unused CG PUSCH occasions by using UCI. Note that the UCI in this study may be a CG-UCI or a UCI other than CG-UCI (e.g., a dedicated UCI). Note that hereinafter, an unused CG PUSCH occasion may be referred to as an unused CG occasion, an unused CG opportunity, or an unused CG PUSCH opportunity. Note that "unused" may also include "unused." A "CG PUSCH occasion" may also be referred to as a CG PUSCH transmission occasion. A "CG PUSCH configuration" may also be referred to as a "CG configuration" or a "CG setting." Note that there may be one or more unused CG PUSCH occasions to be reported.

[0069] In addition, when reporting unused CG occasions using CG-UCI, it is being considered to clarify the relationship between the two CG-UCIs.

[0070] Here, the first of the two types of CG-UCI is a CG-UCI for HARQ process number (HPN), redundancy version (RV), new data indicator (NDI), and channel occupancy time (COT) sharing information in unlicensed spectrum. The CG-UCI for HPN, RV, NDI, and COT sharing information is described in section 6.3.2.1.3 of TS 38.212, and may be referred to as legacy CG-UCI, "legacy CG-UCI," or "legacy CG-UCI bits" below. The legacy CG-UCI or legacy CG-UCI bits may be single-bit information or multiple-bit information. The second of the two types of CG-UCI is a CG-UCI introduced to report unused CG occasions.

[0071] In other words, the two types of CG-UCI relationships are the relationship between the legacy CG-UCI and the CG-UCI introduced to report unused CG occasions. For this relationship, for example, cases where unused CG occasions are indicated by a new CG-UCI and cases where they are indicated by an existing CG-UCI are being considered.

[0072] In this embodiment, a CG-UCI that reports an instruction of an unused CG occasion (e.g., a dynamic instruction) is a new CG-UCI. Hereinafter, a CG-UCI that reports an instruction of an unused CG occasion (e.g., a dynamic instruction) is referred to as a "new CG-UCI" or "new CG-UCI bits." The new CG-UCI or new CG-UCI bits may be one-bit information or multiple-bit information.

[0073] In this embodiment, a new CG-UCI that reports an indication of an unused CG occasion (for example, a dynamic indication) in a case where the operating frequency band of a wireless communication system including a terminal and a base station is a licensed spectrum and a case where the operating frequency band is an unlicensed spectrum will be described. For example, in this embodiment, the following considerations will be described.

[0074] Consideration 1: For example, there is room for consideration regarding whether or not to support CG-UCI, which reports indications of unused CG occasions (e.g., dynamic indications) in licensed spectrum. If supported, there is also room for consideration regarding how to multiplex new CG-UCI bits in CG-PUSCH. For example, when multiplexing new CG-UCI bits in CG-PUSCH, there is a matter to consider, such as whether to encode them together with existing UCI (e.g., HARQ-ACK, CSI) or to encode them separately.

[0075] - Consideration 2: For example, in licensed spectrum, there is room for discussion as to whether new CG-UCI bits should be single-part or two-part.

[0076] Consideration 3: For example, in unlicensed spectrum, there is room for consideration regarding whether or not to support CG-UCI, which reports indications of unused CG occasions (e.g., dynamic indications).

[0077] Consideration 4: For example, when considering new CG-UCI bits and legacy CG-UCI bits in an unlicensed spectrum, there is room for consideration as to how the new CG-UCI bits and legacy CG-UCI bits should be multiplexed.

[0078] - Consideration 5: For example, in licensed spectrum, there is room for discussion as to whether new CG-UCI bits should be single-part or two-part.

[0079] For example, if the provisions based on the above considerations are not sufficient, the terminal may not be able to properly report the dynamic indication of unused CG PUSCH occasions to the base station, which may affect the operation of the base station or the terminal, and may also cause problems in terms of resource utilization efficiency.

[0080] For example, if the specifications based on the above-mentioned considerations are insufficient, it may not be possible to properly determine whether dynamic indication of unused CG PUSCH occasions is supported, and if so, to properly process coding, rate matching, etc.

[0081] In light of the above considerations, the present embodiment makes the following proposals.

[0082] Proposals 0 to 2 described below are for licensed spectrum cases and correspond to the above-mentioned considerations 1 and 2. Proposals 3 to 5 are for unlicensed spectrum cases and correspond to the above-mentioned considerations 3 to 5.

[0083] Proposal 0 considers support for reporting indications of unused CG occasions (e.g., dynamic indications) using CG-UCI in licensed spectrum. Proposals 1 and 2 consider methods for a terminal to multiplex new CG-UCI on a CG PUSCH when multiplexing of UCI other than new CG-UCI is considered on a CG PUSCH or when multiplexing is not considered. Note that Proposal 1 considers the case where new CG-UCI is single-part, and Proposal 2 considers the case where new CG-UCI is two-part.

[0084] Proposal 3 considers support for reporting indications of unused CG occasions (e.g., dynamic indications) using CG-UCI in unlicensed spectrum. Proposal 4 and Proposal 5 consider methods for a terminal to multiplex new CG-UCI and legacy CG-UCI in a CG PUSCH when multiplexing of UCI other than new CG-UCI is considered in a CG PUSCH or when multiplexing is not considered. Note that Proposal 4 considers the case where new CG-UCI is single-part, and Proposal 5 considers the case where new CG-UCI is two-part.

[0085] Proposal 0 describes support for reporting unused CG occasions via CG-UCI in licensed spectrum. Reporting unused CG occasions via CG-UCI may, for example, be replaced by reporting unused CG occasions using CG-UCI. This reporting may also correspond to reporting dynamic indication of unused CG occasions via CG-UCI.

[0086] <Option 1 of Proposal 0> Option 1 of Proposal 0 does not support the terminal reporting dynamic indication of unused CG occasions by the CG-UCI in a licensed spectrum or when the cg-RetransmissionTimer is not configured. In other words, Option 1 of Proposal 0 does not support the terminal reporting dynamic indication of unused CG occasions by the CG-UCI in a licensed spectrum. Alternatively, Option 1 of Proposal 0 does not support the terminal reporting dynamic indication of unused CG occasions by the CG-UCI when the cg-RetransmissionTimer is not configured.

[0087] For example, if the cg-RetransmissionTimer is not configured, the terminal may not assume that it is configured to report dynamic indication of unused CG occasions by the CG-UCI for any CG configuration.

[0088] Also, for example, if the cg-RetransmissionTimer is not configured, the terminal does not report dynamic indication of unused CG occasions by CG-UCI in any CG-PUSCH.

[0089] Note that, in Option 1 of Proposal 0, as a variation, it may not be supported for a terminal to report dynamic indication of unused CG occasions by CG-UCI in a specific frequency range (e.g., a range referred to as FR (Frequency Range) 1 or FR2-1) and / or a specific SCS (e.g., any SCS of 15 kHz, 30 kHz, 60 kHz, or 120 kHz). In other words, this variation may support a terminal to report dynamic indication of unused CG occasions by CG-UCI in a frequency range other than the specific frequency range and / or an SCS other than the specific SCS.

[0090] <Option 2 of Proposal 0> Option 2 of Proposal 0 supports the terminal reporting dynamic indication of unused CG occasions by the CG-UCI in a licensed spectrum or when the cg-RetransmissionTimer is not configured. In other words, Option 2 of Proposal 0 supports the terminal reporting dynamic indication of unused CG occasions by the CG-UCI in a licensed spectrum. Alternatively, Option 2 of Proposal 0 supports the terminal reporting dynamic indication of unused CG occasions by the CG-UCI when the cg-RetransmissionTimer is not configured.

[0091] For example, if the cg-RetransmissionTimer is not configured, the terminal may assume that it is configured to report dynamic indication of unused CG occasions by the CG-UCI for any CG configuration.

[0092] Also, for example, if the cg-RetransmissionTimer is not configured, the terminal may report dynamic indication of unused CG occasions by CG-UCI in any CG-PUSCH.

[0093] In addition, as a variation, Option 2 of Proposal 0 may support a terminal reporting dynamic indication of unused CG occasions via CG-UCI in a specific frequency range (e.g., a range called FR1 or FR2-1) and / or a specific SCS (e.g., any SCS of 15 kHz / 30 kHz / 60 kHz / 120 kHz).

[0094] Proposal 0 specifies whether or not to support reporting dynamic indication of unused CG occasions by CG-UCI depending on whether the operating frequency band is a licensed spectrum or whether the cg-RetransmissionTimer is not set. The terminal determines whether or not to report dynamic indication of unused CG occasions by CG-UCI based on, for example, whether or not to support specified depending on whether the operating frequency band is a licensed spectrum or whether the cg-RetransmissionTimer is not set, determines UCI depending on the determination, and transmits the UCI. This allows the dynamic indication of unused CG occasions to be reported appropriately.

[0095] <Proposal 1> Proposal 1 is based on the following two assumptions: - The spectrum is licensed, or the cg-RetransmissionTimer is not configured. - The CG-UCI for indicating unused CG PUSCH occasions is a single-part CG-UCI.

[0096] In the following description, information (e.g., information bits or information parts) of single-part CG-UCI for indicating unused CG PUSCH occasions will be referred to as "new CG-UCI bits." However, the present disclosure is not limited to the "new CG-UCI bits" being for indicating unused CG PUSCH occasions.

[0097] The terminal generates new CG-UCI bits for indicating unused CG PUSCH occasions. Note that the method for generating new CG-UCI bits is not particularly limited. For example, new CG-UCI bits may be generated by the following method.

[0098] <Generation Method 1> In generation method 1, the following options are considered for the method by which the terminal dynamically indicates unused CG PUSCH occasions using CG-UCI.

[0099] <Option 1 of Generation Method 1> When a specific higher layer parameter such as cg-RetransmissionTimer exists, the terminal dynamically indicates unused CG PUSCH occasions using a CG-UCI different from the existing CG-UCI (hereinafter referred to as a new CG-UCI). Note that the new CG-UCI may be a CG-UCI that can have new CG-UCI bits. In this case, the terminal generates new CG-UCI bits for indicating unused CG PUSCH occasions in the new CG-UCI.

[0100] In option 1, when there are both new CG-UCI and existing CG-UCI that share the spectrum, the CG PUSCH may include two CG-UCIs.

[0101] <Option 2 of Generation Method 1> If the existing CG-UCI has a UCI field for indicating unused CG PUSCH occasions (hereinafter referred to as the new UCI field) in addition to the legacy UCI field, the terminal dynamically indicates the unused CG PUSCH occasions using the existing CG-UCI. Note that the new UCI field may be a CG-UCI that can have new CG-UCI bits. In this case, the terminal generates new CG-UCI bits for indicating the unused CG PUSCH occasions in the new UCI field of the existing CG-UCI.

[0102] In option 2, the terminal transmits at most one CG-UCI along with the CG PUSCH.

[0103] <Generation Method 2> Whether or not a new CG-UCI exists as in option 1 of generation method 1 described above, or whether or not a new CG-UCI field exists in an existing CG-UCI as in option 2, may be determined (or discriminated) as in the following example.

[0104] <Option 1 of Creation Method 2> In option 1, whether a new CG-UCI exists or whether a new CG-UCI field exists in an existing CG-UCI is defined by the specification.

[0105] <Option 2 of Generation Method 2> In Option 2, whether a new CG-UCI exists or whether a new CG-UCI field exists in an existing CG-UCI is determined by a higher layer configuration (e.g., an RRC configuration and / or a dynamic instruction).

[0106] <Generation Method 3> In generation method 3, specific instructions for unused CG PUSCH occasions are described using a new CG-UCI field or a new field in an existing CG-UCI (hereinafter referred to as a "CG-UCI field").

[0107] <Generation Method 3, Option 1> The CG-UCI field indicates the number of consecutive unused (valid) CG PUSCH occasions (for example, M consecutive unused (valid) CG PUSCH occasions).

[0108] Note that "invalid CG PUSCH occasions" may include at least one of the following: CG PUSCH occasions that overlap symbols configured as DL by TDD-Config-Common and / or TDD-Config-Dedicated CG PUSCH occasions that overlap symbols configured for SSB reception CG PUSCH occasions that overlap symbols for Type 0 CSS CG PUSCH occasions that overlap symbols for CORESET#0 CG PUSCH occasions that overlap symbols indicated as DL (or flexible) by DCI 2_0 CG PUSCH occasions that overlap DL subbands (and / or guard bands) in symbols configured for SBFD operation (however, this is a duplex enhancement feature of Rel-18)

[0109] A "valid CG PUSCH occasion" may mean a CG PUSCH occasion that is not an "invalid CG PUSCH occasion."

[0110] The first indicated unused CG PUSCH occasion out of M consecutive unused CG PUSCH occasions may be one of the following: (Alt-a) The first (valid) CG PUSCH occasion that starts after the end of the current CG PUSCH occasion (i.e., the CG PUSCH transmitting CG-UCI), (Alt-b) The first (valid) CG PUSCH occasion that starts / ends X slots / symbols after the start / end symbol of the current CG PUSCH occasion, or (Alt-c) The first (valid) CG PUSCH occasion that starts / ends Y CG PUSCH occasion start / end symbols from the current CG PUSCH occasion.

[0111] The value of X in Alt-b and / or the value of Y in Alt-c may be defined by a specification, configured by the RRC, or indicated by the CG-UCI field.

[0112] Additionally, the minimum / maximum values ​​of X and / or Y may be defined by specification and may be defined differently for different subcarrier spacings, different frequency ranges, etc.

[0113] The count of X slots / symbols may or may not include: slots / symbols configured as DL by TDD-Config-Common and / or TDD-Config-Dedicated slots / symbols configured for SSB reception slots / symbols for Type 0 CSS slots / symbols for CORESET#0

[0114] In the count of Y CG PUSCH occasions, invalid CG PUSCH occasions may or may not be taken into account.

[0115] When counting Y CG PUSCH occasions, only CG PUSCH occasions of the same CG configuration as the CG PUSCH transmitting CG-UCI may be counted, only CG PUSCH occasions of the same CG period as the CG PUSCH transmitting CG-UCI may be counted, or CG PUSCH occasions of any CG configuration may be counted.

[0116] <Generation Method 3, Option 2> The CG-UCI field indicates whether each of N consecutive (valid) CG PUSCH occasions is used.

[0117] Alt-a / Alt-b / Alt-c of option 1 of generation method 3 above can be reused to determine the first indicated unused CG PUSCH occasion out of X consecutive CG PUSCH occasions.

[0118] In this case, the value of N may be defined by the specification (eg, N=1), may be set by the RRC, or may be indicated by the CG-UCI field.

[0119] For example, when N=1, the CG-UCI field may indicate whether to use the first (valid) CG PUSCH occasion of any of the following: - The CG-UCI field indicates whether to use the first (valid) CG PUSCH occasion that starts after the end of the current CG PUSCH occasion (i.e., the CG PUSCH that transmits the CG-UCI). - The CG-UCI field indicates whether to use the first (valid) CG PUSCH occasion that starts / ends X slots / symbols after the start / end symbol of the current CG PUSCH occasion, where the value of X may be defined by the specification, configured by the RRC, or indicated by a field in the CG-UCI. - The CG-UCI field indicates whether to use the first (valid) CG PUSCH occasion that starts / ends Y CG PUSCH occasion start / end symbols after the current CG PUSCH occasion, where the value of Y may be defined by the specification, configured by the RRC, or indicated by the CG-UCI field.

[0120] <Generation Method 3, Option 3> The CG-UCI field indicates the time window associated with the unused CG PUSCH occasion.

[0121] The association between the time window and the dynamic indication of unused CG PUSCH occasions may be one of the following: (Example 1) All CG PUSCH occasions within the time window may be unused. (Example 2) All CG PUSCH occasions of the same CG configuration (as the CG PUSCH transmitting CG-UCI) within the time window may be unused. (Example 3) All CG PUSCHs of a certain CG configuration may be unused within the time window. In this case, the specific CG configuration may be defined by the specification (e.g., a CG configuration having multiple CG PUSCH occasions in one CG period), configured by the RRC (e.g., a group of CG configuration indices configured by the RRC), or indicated by the CG-UCI field.

[0122] (Dynamic Indication of Time Window) The start of the time window may be one of the following: (Alt-a) First slot / symbol after the end of the current CG PUSCH occasion (i.e., the CG PUSCH transmitting CG-UCI) (Alt-b) First slot / symbol X slots / symbols from the start / end symbol of the current CG PUCCH occasion (Alt-c) First slot / symbol Y CG PUSCH occasion start / end symbols from the current CG PUSCH occasion

[0123] The value of X in Alt-b and / or the value of Y in Alt-c may be defined by the specification, configured by the RRC, or indicated by the CG-UCI field.

[0124] The minimum / maximum values ​​of X and / or Y may be defined by specification and may be defined differently for different subcarrier spacings, different frequency ranges, etc.

[0125] The duration of the time window may be defined by the specification, may be set by the RRC, or may be indicated by the CG-UCI field.

[0126] The count of the time window duration may or may not include: slots / symbols configured as DL by TDD-Config-Common and / or TDD-Config-Dedicated slots / symbols configured for SSB reception slots / symbols for Type 0 CSS slots / symbols for CORESET#0

[0127] <Generation Method 3, Option 4> The CG-UCI field indicates, in bitmap format, whether a CG PUSCH occasion is used for every N slots / slot group / CG period.

[0128] The value of N may be defined by the specification (eg, N=1), may be set by the RRC, or may be indicated by the CG-UCI field.

[0129] The count for the value of N may or may not include: slots / symbols configured as DL by TDD-Config-Common and / or TDD-Config-Dedicated slots / symbols configured for SSB reception slots / symbols for Type 0 CSS slots / symbols for CORESET#0

[0130] The maximum value of N may be defined by a specification, may be set by the RRC, or may be determined based on the periodicity of the CG-UCI.

[0131] The count of N slots / slot groups / CG periods may or may not include: slots / slot groups / CG periods configured as DL by TDD-Config-Common and / or TDD-Config-Dedicated slots / slot groups / CG periods configured for SSB reception slots / slot groups / CG periods for Type 0 CSS slots / slot groups / CG periods for CORESET#0

[0132] The count of N slots / slot groups / CG periods may or may not include slots / slot groups / CG periods with each / any CG PUSCH that overlaps with: - slots / slot groups / CG periods configured as DL by TDD-Config-Common and / or TDD-Config-Dedicated - slots / slot groups / CG periods configured for SSB reception - slots / slot groups / CG periods for Type 0 CSS - slots / slot groups / CG periods for CORESET#0

[0133] The first slot / slot group / CG period among the N slots / slot groups / CG periods may be determined as follows: (Alt-a) The first slot / slot group / CG period after the slot / slot group / CG period (or start / end symbol) of the current CG PUSCH occasion (i.e., the CG PUSCH transmitting CG UCI), (Alt-b) The first slot / slot group / CG period after X slots / symbols / slot group / CG periods of the slot / slot group / CG period (or start / end symbol) of the current CG PUSCH occasion, (Alt-c) The first slot / slot group / CG period after Y CG PUSCH occasions from the current CG PUSCH occasion.

[0134] The value of X in Alt-b and / or the value of Y in Alt-c may be defined by the specification, configured by the RRC, or indicated by the CG-UCI field.

[0135] The minimum / maximum values ​​of X and / or Y may be defined by a specification, configured by RRC, or indicated by the CG-UCI field, and may also be defined separately for different subcarrier spacings, different frequency ranges, etc.

[0136] <Generation Method 3, Option 5> The CG-UCI field indicates the number of CG periods in which CG PUSCH occasions are not used.

[0137] The first indicated CG period for an unused CG PUSCH occasion may be determined as follows: (Alt-a) The first CG period (of the same CG configuration) after the end of the current CG PUSCH occasion (i.e., the CG PUSCH transmitting the CG UCI), (Alt-b) The first CG period (of the same CG configuration) after X slots / symbols / slot groups / symbols after the start / end symbol of the current CG PUSCH occasion, (Alt-c) The first CG period (of the same CG configuration) after Y CG PUSCH occasion start / end symbols from the current CG PUSCH occasion.

[0138] The value of X in Alt-b and / or the value of Y in Alt-c may be defined by the specification, configured by the RRC, or indicated by the CG-UCI field.

[0139] The minimum / maximum values ​​of X and / or Y may be defined by a specification, configured by RRC, or indicated by a CG-UCI field. They may be defined separately for different subcarrier spacings, different frequency ranges, etc. Also, the minimum / maximum values ​​of X and / or Y may be defined separately for different subcarrier spacings, different frequency ranges, etc.

[0140] The count of X slots / slot groups / CG periods may or may not include: slots / slot groups / CG periods configured as DL by TDD-Config-Common and / or TDD-Config-Dedicated slots / slot groups / CG periods configured for SSB reception slots / slot groups / CG periods for Type 0 CSS slots / slot groups / CG periods for CORESET#0

[0141] The count of X slots / slot groups / CG periods may or may not include slots / slot groups / CG periods with each / any CG PUSCH that overlaps with: - slots / slot groups / CG periods configured as DL by TDD-Config-Common and / or TDD-Config-Dedicated - slots / slot groups / CG periods configured for SSB reception - slots / slot groups / CG periods for Type 0 CSS - slots / slot groups / CG periods for CORESET#0

[0142] <Generation Method 4> In Generation Method 4, specific indication contents when the CG-UCI field indicates unused CG PUSCH occasions in two stages (or two parts) will be described. Note that Generation Method 4 is related to Proposal 2 and Proposal 5, which will be described later.

[0143] (Alt-1) Presence flag + detailed indication (fixed size) In Alt-1, Part 1 CG-UCI (first part of the CG-UCI field) indicates whether or not Part 2 CG-UCI (second part of the CG-UCI field) is present, and Part 2 CG-UCI indicates details of unused CG PUSCH occasions. In Alt-1, the size of Part 1 CG-UCI is 1 bit, and the size of Part 2 CG-UCI is a fixed multiple bits.

[0144] In this case, the Part 1 CG-UCI may be a one-bit flag that indicates whether or not the Part 2 CG-UCI exists together with the existing CG PUSCH field. For example, a one-bit value of the Part 1 CG-UCI may indicate that the Part 2 CG-UCI exists if it is "0," and indicate that the Part 2 CG-UCI does not exist if it is "1" (i.e., there is no information about unused CG PUSCH occasions reported together with the existing CG PUSCH occasions).

[0145] Part 2 CG-UCI has a fixed-size field that indicates details of unused CG PUSCH occasions. The specific content of Part 2 CG-UCI may be any of those described in the above generation method 3.

[0146] (Alt-2) Field size + detailed instruction (variable size) Alt-2 indicates whether Part 2 CG-UCI is present and the bit size of Part 2 CG-UCI in Part 1 CG-UCI of the CG-UCI field, and indicates details of unused CG PUSCH occasions in Part 2 CG-UCI. In Alt-2, the size of Part 1 CG-UCI is fixed at X bits (where X is multiple), and the size of Part 2 CG-UCI is variable.

[0147] For example, when X=2, if Part 1 CG-UCI is "00", it may indicate that Part 2 CG-UCI does not exist (i.e., there is no information about unused CG PUSCH occasions to be reported together with existing CG PUSCH occasions). If Part 1 CG-UCI is "01", it may indicate that the size of Part 2 CG-UCI is the first candidate value (e.g., N1). If Part 2 CG-UCI is "10", it may indicate that the size of Part 2 CG-UCI is the second candidate value (e.g., N2). If Part 1 CG-UCI is "11", it may indicate that the size of Part 2 CG-UCI is the third candidate value (e.g., N3).

[0148] Part 2 CG-UCI has a variable-size field that indicates details of unused CG PUSCH occasions. The specific content of Part 2 CG-UCI may be any of those described in the above generation method 3.

[0149] (Note) A terminal that encodes / decodes the two-part CG-UCI can refer to the encoding / decoding of CSI Part 1 and CSI Part 2 on the PUSCH disclosed in Sections 5.2.3 and 5.2.4 of TS38.214.

[0150] In the case of Alt-1 and Alt-2, the base station first decodes the Part 1 CG-UCI, and then decodes the Part 2 CG-UCI (if present) based on the information in the Part 1 CG-UCI (e.g., whether or not the Part 2 CG-UCI is present in Alt-1, and the size of the Part 2 CG-UCI in Alt-2), and then decodes the UL-SCH.

[0151] Here, two methods are considered for whether or not to multiplex the new CG-UCI bits with other UCI.

[0152] First, if no other UCI (e.g., HARQ-ACK, CSI, etc.) other than the new CG-UCI bits is multiplexed in the CG-PUSCH, the terminal performs rate matching of the CG-UCI with respect to the new CG-UCI bits, as described in Section 6.3.2.4.1.4 of TS 38.212.

[0153] In rate matching of new CG-UCI bits, the CG-UCI offset parameter may be set by the existing betaOffsetCG-UCI-r16 or by the new RRC parameter betaOffsetCG-UCI-unused-occasion-r18. In the following, the offset parameter of CG-UCI is expressed as β CG-UCI offset It is written as follows.

[0154] Second, when UCI other than the new CG-UCI bits (e.g., HARQ-ACK, CSI, etc.) is multiplexed in the CG-PUSCH, several options are considered for multiplexing UCI in the CG-PUSCH. These options will be described below.

[0155] As described above, Proposal 1 is based on the premise that the CG-UCI for indicating unused CG PUSCH occasions is a single-part CG-UCI. Either Option 1-1 or Option 1-2 below is applied to the single-part CG-UCI for indicating unused CG PUSCH occasions.

[0156] <Option 1-1 of Proposal 1> In Option 1-1, the same rules as for the legacy CG-UCI bits (for HPN, RV, NDI, and COT sharing information) apply to the single-part CG-UCI for indicating unused CG PUSCH occasions. Here, the rules for the legacy CG-UCI bits stipulate that the legacy CG-UCI bits are jointly encoded and rate-matched together with the HARQ-ACK bits. Furthermore, the rules for the legacy CG-UCI bits stipulate that the coded part containing the legacy CG-UCI bits and the HARQ-ACK bits has a higher priority than CSI part 1 and CSI part 2 in rate matching. For example, based on the rules for the legacy CG-UCI bits, the priority relationship between the legacy CG-UCI bits, HARQ-ACK, CSI part 1 bits, and CSI part 2 bits is expressed as follows:・[legacy CG-UCI bits and HARQ-ACK if any] > [CSI part 1 bits if any] > [CSI part 2 bits if any]

[0157] Here, how to express the above-mentioned priority relationships will be explained.

[0158] For example, in the above-mentioned priority relationship expressions, "[ ]" means one coding part. For example, the contents (e.g., pieces of information or information bits) within [ ] are jointly encoded as one coding part.

[0159] For example, [A and B] means that content A (e.g., a part of information or information bit) and content B are coded together as one coded part. Also, for example, [A and B if any] means that content A and content B, if present, are coded together as one coded part. In other words, [A and B if any] means that if content B does not exist, only content A is coded as one coded part. Also, for example, [C if any] means that if content C exists, it is coded as one coded part. In other words, [C if any] means that if content C does not exist, there is no coded part corresponding to [C if any].

[0160] Furthermore, among the above-mentioned ways of expressing priority relationships, a relationship indicated using ">" means that the former takes precedence over the latter when performing rate matching, that is, the former has a higher priority than the latter. For example, [A and B] > [C] means that in rate matching, the coding part corresponding to [A and B] takes precedence over the coding part corresponding to [C]. Also, for example, [C if any] > [D] means that in rate matching, if content C exists, the coding part corresponding to [C if any] takes precedence over the coding part corresponding to [D]. In other words, [C if any] > [D] means that in rate matching, if content C does not exist, there is no coding part corresponding to [C if any], so the coding part corresponding to [D] may take precedence over [C if any].

[0161] In addition, if the total number of coded parts is greater than the number of polar encoders for UCI multiplexed in PUSCH, coded parts with lower priorities do not need to be transmitted until the total number of coded parts to be transmitted does not exceed the limit of the polar encoder.

[0162] For example, in the case of a UCI relationship based on the above-described rule for legacy CG-UCI bits, [legacy CG-UCI bits and HARQ-ACK if any] means that the legacy CG-UCI bits and, if present, the HARQ-ACK are coded together as one coding part. Furthermore, [legacy CG-UCI bits and HARQ-ACK if any] > [CSI part 1 bits if any] > [CSI part 2 bits if any] means that, in rate matching, [legacy CG-UCI bits and HARQ-ACK if any] takes precedence over [CSI part 1 bits if any] and [CSI part 2 bits if any], and [CSI part 1 bits if any] takes precedence over [CSI part 2 bits if any]. For example, if no HARQ-ACK exists, the coding part with the highest priority is the coding part in which only the legacy CG-UCI bits are coded.

[0163] For example, if the same rule as for the above-mentioned legacy CG-UCI bits is applied to the new CG-UCI bits, the relationship between the new CG-UCI bits corresponding to the single-part CG-UCI for indicating unused CG PUSCH occasions, the HARQ-ACK, the CSI part 1 bits, and the CSI part 2 bits is expressed as follows: [new CG-UCI bits and HARQ-ACK if any] > [CSI part 1 bits if any] > [CSI part 2 bits if any]

[0164] For example, in this relationship, [new CG-UCI bits and HARQ-ACK if any] means that the new CG-UCI bits and, if present, the HARQ-ACK are coded together as one coding part, and [new CG-UCI bits and HARQ-ACK if any] > [CSI part 1 bits if any] > [CSI part 2 bits if any] means that in rate matching, [new CG-UCI bits and HARQ-ACK if any] takes precedence over [CSI part 1 bits if any] and [CSI part 2 bits if any], and [CSI part 1 bits if any] takes precedence over [CSI part 2 bits if any].

[0165] According to Option 1-1 of Proposal 1, the same rules as for the legacy CG-UCI bits are applied to the new CG-UCI bits, so that transmission of the new CG-UCI bits, i.e., reporting of dynamic indication by CG-UCI of unused CG PUSCH occasions, can be performed with minimal changes to the specifications and in a simple manner.

[0166] <Option 1-2 of Proposal 1> In Option 1-2, a new rule that differs from the multiplexing rule for legacy CG-UCI bits (for HPN, RV, NDI, and COT sharing information) is specified for single-part CG-UCI (i.e., new CG-UCI bits) for indicating unused CG PUSCH occasions, and the new rule is applied.

[0167] The new rule is not particularly limited, but for example, one of the rules Option 1-2A to Option 1-2C described below may be applied.

[0168] <Option 1-2A> In Option 1-2A, new CG-UCI bits, HARQ-ACK bits, CSI part 1 bits, and CSI part 2 bits are all coded separately. In other words, two or more of these four bits are not coded together. In Option 1-2A, the relationship between the priority of new CG-UCI bits and the priority of other UCI in rate matching may be one of the following four relationships, Alt a-1 to Alt a-4.・Alt a-1: [HARQ-ACK bits if any] > [CSI part 1 bits if any] > [CSI part 2 bits if any] > [new CG-UCI bits] ・Alt a-2: [HARQ-ACK bits if any] > [CSI part 1 bits if any] > [new CG-UCI bits] > [CSI part 2 bits if any] ・Alt a-3: [HARQ-ACK bits if any] > [new CG-UCI bits] > [CSI part 1 bits if any] > [CSI part 2 bits if any] ・Alt a-4: [new CG-UCI bits] > [HARQ-ACK bits if any] > [CSI part 1 bits if any] > [CSI part 2 bits if any]

[0169] In rate matching, β CG-UCI offset may be set by the existing "betaOffsetCG-UCI-r16" or a new RRC parameter. As an example, the new RRC parameter may be written as "betaOffsetCG-UCI-unused-occasion-r18". CG-UCI offsetis set by the existing "betaOffsetCG-UCI-r16", there is a possibility that the specification will be affected in that "betaOffsetCG-UCI-r16" will be set when "cg-RetransmissionTimer" is not set.

[0170] In Option 1-2A, new CG-UCI bits, HARQ-ACK bits, CSI part 1 bits, and CSI part 2 bits are all coded individually, allowing for coding appropriate for each bit (e.g., setting the offset size).

[0171] <Option 1-2B> In Option 1-2B, the new CG-UCI bits are coded together with the CSI part 1 bits and coded separately from the HARQ-ACK bits and CSI part 2 bits. In Option 1-2B, the priority of the new CG-UCI bits and CSI part 1 bits may follow the priority of the existing CSI part 1 bits in rate matching. In other words, the priority of the new CG-UCI bits and CSI part 1 bits is lower than the HARQ ACK bits and higher than the CSI part 2 bits. In other words, the priority relationship in Option 1-2B may be as follows: [HARQ-ACK bits if any] > [new CG-UCI bits and CSI part 1 bits if any] > [CSI part 2 bits if any]

[0172] <Option 1-2C> In Option 1-2C, the new CG-UCI bits are coded together with the CSI part 2 bits and coded separately from the HARQ-ACK bits and CSI part 1 bits. In Option 1-2C, the priority of the new CG-UCI bits and CSI part 2 bits may follow the priority of the existing CSI part 2 bits in rate matching. In other words, the priority of the new CG-UCI bits and CSI part 2 bits is lower than that of the HARQ ACK bits and lower than that of the CSI part 1 bits. In other words, the priority relationship in Option 1-2C may be as follows: [HARQ-ACK bits if any] > [CSI part 1 bits if any] > [new CG-UCI bits and CSI part 2 bits if any]

[0173] Note that, in the above-described Option 1-2A to Option 1-2C, when new CG-UCI bits and a certain UCI (e.g., a first UCI) are jointly encoded, examples have been shown in which the priorities of the new CG-UCI bits and the first UCI follow the priority of the existing first UCI. However, the present disclosure is not limited to this. For example, when new CG-UCI bits and a certain UCI (e.g., the first UCI) are jointly encoded, the priorities of the new CG-UCI bits and the first UCI may differ from the priority of the existing first UCI. For example, when new CG-UCI bits and HARQ-ACK are jointly encoded, the priorities of the new CG-UCI bits and HARQ-ACK may be lower than CSI part 1 bits and may be lower than CSI part 2. Furthermore, for example, when new CG-UCI bits and CSI part 1 bits are coded together, the priorities of the new CG-UCI bits and CSI part 1 bits may be higher than HARQ-ACK. In other words, the relationship of priorities may be different between the case where new CG-UCI bits and a certain UCI are coded together and the case where they are coded separately.

[0174] In addition, in the rate matching in the above-mentioned options 1-2A to 1-2C, β CG-UCI offset may be set by the existing "betaOffsetCG-UCI-r16" or a new RRC parameter. As an example, the new RRC parameter may be written as "betaOffsetCG-UCI-unused-occasion-r18".

[0175] As described above, according to Proposal 1, appropriate rules are applied to the coding and rate matching of single-part new CG-UCI bits, so that transmission of new CG-UCI bits, i.e., reporting of dynamic indication by CG-UCI of unused CG PUSCH occasions, can be performed appropriately.

[0176] <Proposal 2> Proposal 2 is based on the following two assumptions: - The spectrum is licensed, or the cg-RetransmissionTimer is not configured. - The CG-UCI for indicating unused CG PUSCH occasions is a two-part CG-UCI.

[0177] In the following description, the two-part CG-UCI for indicating unused CG PUSCH occasions, i.e., the two parts, are referred to as "new CG-UCI part 1 bit" and "new CG-UCI part 2 bits." Here, when performing rate matching, "new CG-UCI part 1 bit" has a higher priority than "new CG-UCI part 2 bits." In Proposal 2, these two parts may be collectively referred to as "new CG-UCI bits." Furthermore, the number of bits of each of "new CG-UCI part 1 bit" and "new CG-UCI part 2 bits" may be 1, 2 or more, or may be different from each other.

[0178] The terminal generates new CG-UCI bits. The generation method may be the same as the method described in Proposal 1 (e.g., generation method 4).

[0179] Here, two methods are considered for whether or not to multiplex the new CG-UCI bits with other UCI.

[0180] First, when UCI other than the new CG-UCI bits (e.g., HARQ-ACK, CSI, etc.) is not multiplexed in the CG-PUSCH, the terminal performs separate coding and separate rate matching on the new CG-UCI part 1 bits and the new CG-UCI part 2 bits.

[0181] In rate matching of new CG-UCI part 1 bits and new CG-UCI part 2 bits, the CG-UCI offset parameter β CG-UCI offset may be applied. In this case, β CG-UCI offset may be set by the existing betaOffsetCG-UCI-r16 or by a new RRC parameter, betaOffsetCG-UCI-unused-occasion-r18.

[0182] In addition, in rate matching of new CG-UCI part 1 bits and new CG-UCI part 2 bits, the CG-UCI offset parameter βCG-UCI-part1 is used for new CG-UCI part 1 bits. offset is applied, and the CG-UCI offset parameter βCG-UCI-part2 is applied to the new CG-UCI part 2 bits. offset may be applied. In this case, βCG-UCI-part1 offset and βCG-UCI-part2 offsetmay be set individually. For example, βCG-UCI-part1 offset and βCG-UCI-part2 offset may be set by different RRC parameters or by a common RRC parameter. For example, the offset parameter βCG-UCI-part1 for the new CG-UCI part 1 bits is offset is set by the RRC parameter "betaOffsetCG-UCI-part1-unused-occasion-r18", and the offset parameter βCG-UCI-part2 for the new CG-UCI part 2 bits is offset may be set by an RRC parameter called "betaOffsetCG-UCI-part2-unused-occasion-r18". Alternatively, one of the two offset parameters may be set from the other offset parameter. For example, a specific calculation may be performed on one offset parameter to set the other offset parameter.

[0183] Second, when UCI other than the new CG-UCI bits (e.g., HARQ-ACK, CSI, etc.) is multiplexed in the CG-PUSCH, several options are considered for multiplexing UCI in the CG-PUSCH. These options will be described below.

[0184] As described above, Proposal 2 assumes that the CG-UCI for indicating unused CG PUSCH occasions is a two-part CG-UCI. Either Option 2-1 or Option 2-7 below is applied to the two-part CG-UCI for indicating unused CG PUSCH occasions.

[0185] <Option 2-1 of Proposal 2> In Option 2-1, each UCI including two-part CG-UCI is encoded separately. Note that in Option 2-1, the priority of two-part CG-UCI, that is, the relationship of the priorities including the priority of new CG-UCI part 1 bits and the priority of new CG-UCI part 2 bits, may be any of the relationships in Option 2-1A to Option 2-1K below.

[0186] ・Option 2-1A: [new CG-UCI part 1 bits] > [new CG-UCI part 2 bits] > [HARQ-ACK if any] > [CSI part 1 bits if any] > [CSI part 2 bits if any] ・Option 2-1B: [new CG-UCI part 1 bits] > [HARQ-ACK if any] > [new CG-UCI part 2 bits] > [CSI part 1 bits if any] > [CSI part 2 bits if any] ・Option 2-1C: [new CG-UCI part 1 bits] > [HARQ-ACK if any] > [CSI part 1 bits if any] > [new CG-UCI part 2 bits] > [CSI part 2 bits if any] ・Option 2-1D: [new CG-UCI part 1 bits] > [HARQ-ACK if any] > [CSI part 1 bits if any] > [CSI part 2 bits if any] > [new CG-UCI part 2 bits] ・Option 2-1E: [HARQ-ACK if any] > [new CG-UCI part 1 bit] > [new CG-UCI part 2 bits] > [CSI part 1 bit if any] > [CSI part 2 bits if any] ・Option 2-1F: [HARQ-ACK if any] > [new CG-UCI part 1 bit] > [CSI part 1 bit if any] > [new CG-UCI part 2 bits] > [CSI part 2 bits if any] ・Option 2-1G: [HARQ-ACK if any] > [new CG-UCI part 1 bit] > [CSI part 1 bit if any] > [CSI part 2 bits if any] > [new CG-UCI part 2 bits] ・Option 2-1H:[HARQ-ACK if any] > [CSI part 1 bits if any] > [new CG-UCI part 1 bits] > [new CG-UCI part 2 bits] > [CSI part 2 bits if any] ・Option 2-1J: [HARQ-ACK if any] > [CSI part 1 bits if any] > [new CG-UCI part 1 bits] > [CSI part 2 bits if any] > [new CG-UCI part 2 bits] ・Option 2-1K: [HARQ-ACK if any] > [CSI part 1 bits if any] > [CSI part 2 bits if any] > [new CG-UCI part 1 bits] > [new CG-UCI part 2 bits]

[0187] In Option 2-1, new CG-UCI part 1 bits, new CG-UCI part 2 bits, HARQ-ACK bits, CSI part 1 bits, and CSI part 2 bits are all coded individually, allowing for coding appropriate for each bit (for example, setting the offset size).

[0188] <Option 2-2 of Proposal 2> In Option 2-2, new CG-UCI part 1 bits are coded together with HARQ-ACK bits. In other words, the rules for legacy CG-UCI bits apply to new CG-UCI part 1 bits. In Option 2-2, new CG-UCI part 2 bits are coded separately from other UCI bits. Note that the priority of the two-part CG-UCI in Option 2-2, that is, the relationship of the priorities including the priority of new CG-UCI part 1 bits and the priority of new CG-UCI part 2 bits, may be any of the relationships in Option 2-2A to Option 2-2E below.

[0189] ・オプション2-2A: [new CG-UCI part 1 bits, and HARQ-ACK if any] > [CSI part 1 bits if any] > [CSI part 2 bits if any] > [new CG-UCI part 2 bits] ・オプション2-2B: [new CG-UCI part 1 bits, and HARQ-ACK if any] > [CSI part 1 bits if any] > [new CG-UCI part 2 bits] > [CSI part 2 bits if any] ・オプション2-2C: [new CG-UCI part 1 bits, and HARQ-ACK if any] > [new CG-UCI part 2 bits] > [CSI part 1 bits if any] > [CSI part 2 bits if any] ・オプション2-2D: [new CG-UCI part 1 bits, and HARQ-ACK if any] > [CSI part 1 bits if any] > [CSI part 2 bits and / or new CG-UCI part 2 bits] ・オプション2-2E: [new CG-UCI part 1 bits, and HARQ-ACK if any] > [CSI part 1 bits and / or new CG-UCI part 2 bits] > [CSI part 2 bits if any]

[0190] Note that in the above-mentioned Option 2-2D, [CSI part 2 bits and / or new CG-UCI part 2 bits] means that it may be either [CSI part 2 bits and new CG-UCI part 2 bits] or [CSI part 2 bits or new CG-UCI part 2 bits]. [CSI part 2 bits and new CG-UCI part 2 bits] indicates that CSI part 2 bits and new CG-UCI part 2 bits are coded together. [CSI part 2 bits or new CG-UCI part 2 bits] indicates that one of CSI part 2 bits and new CG-UCI part 2 bits may be coded, and the other may be discarded (or dropped).

[0191] In the above-described Option 2-2E, [CSI part 1 bit and / or new CG-UCI part 2 bits] means that it may be [CSI part 1 bit and new CG-UCI part 2 bits] or [CSI part 1 bit or new CG-UCI part 2 bits], as in Option 2-2D. Furthermore, [CSI part 1 bit or new CG-UCI part 2 bits] indicates that one of CSI part 1 bits and new CG-UCI part 2 bits may be coded, and the other may be discarded (or dropped).

[0192] In option 2-2, new CG-UCI part 1 bits are coded together with HARQ-ACK bits, which reduces the total number of coded parts and allows the coded part including new CG-UCI part 1 bits to be transmitted with the same priority as HARQ-ACK bits, thereby enabling appropriate reporting of dynamic indication by CG-UCI for unused CG PUSCH occasions.

[0193] <Option 2-3 of Proposal 2> In Option 2-3, new CG-UCI part 1 bits are coded together with HARQ-ACK bits. That is, the rules for legacy CG-UCI bits apply to new CG-UCI part 1 bits. In Option 2-3, new CG-UCI part 2 bits are coded together with CSI part 1 bits or CSI part 2 bits. Note that the priority of the two-part CG-UCI in Option 2-3, that is, the relationship between the priority of the coding part including new CG-UCI part 1 bits and the priority of the coding part including new CG-UCI part 2 bits, may be any of the relationships in Option 2-3A to Option 2-3B below.

[0194] ・Option 2-3A: [new CG-UCI part 1 bits, and HARQ-ACK if any] > [new CG-UCI part 2 bits and CSI part 1 bits if any] > [CSI part 2 bits if any] ・Option 2-3B: [new CG-UCI part 1 bits, and HARQ-ACK if any] > [CSI part 1 bits if any] > [new CG-UCI part 2 bits and CSI part 2 bits if any]

[0195] In option 2-3, the new CG-UCI part 1 bits are coded together with the HARQ-ACK bits, and the new CG-UCI part 2 bits are coded together with the CSI part 1 bits or CSI part 2 bits. This further reduces the total number of coded parts, and also allows the coded part including the new CG-UCI part 1 bits to be transmitted with the same priority as the HARQ-ACK bits, allowing for appropriate reporting of dynamic indication by the CG-UCI for unused CG PUSCH occasions.

[0196] <Option 2-4 of Proposal 2> In Option 2-4, new CG-UCI part 1 bits are coded together with CSI part 1 bits, and new CG-UCI part 2 bits are coded separately from other UCI bits. Note that the priority of the two-part CG-UCI in Option 2-4, that is, the relationship between the priority of the coding part including new CG-UCI part 1 bits and the priority of the coding part including new CG-UCI part 2 bits, may be any of the relationships in Option 2-4A to Option 2-4B below.

[0197] -Option 2-4A: [HAR-ACK bits if any] > [new CG-UCI part 1 bits and CSI part 1 bits if any] > [new CG-UCI part 2 bits] > [CSI part 2 bits if any] -Option 2-4B: [HAR-ACK bits if any] > [new CG-UCI part 1 bits and CSI part 1 bits if any] > [CSI part 2 bits if any] > [new CG-UCI part 2 bits]

[0198] In options 2-4, new CG-UCI part 1 bits are coded together with CSI part 1 bits, which reduces the total number of coding parts and allows for proper reporting of dynamic indication by CG-UCI for unused CG PUSCH occasions.

[0199] <Option 2-5 of Proposal 2> In Option 2-5, new CG-UCI part 1 bits are coded together with CSI part 1 bits, and new CG-UCI part 2 bits are coded together with CSI part 2 bits. Note that the relationship between the priorities of the two-part CG-UCI in Option 2-5, that is, the priorities of the coding parts including new CG-UCI part 1 bits and the coding parts including new CG-UCI part 2 bits, may be as follows: [HARQ-ACK if any] > [new CG-UCI part 1 bits and CSI part 1 bits if any] > [new CG-UCI part 2 bits and CSI part 2 bits if any]

[0200] In options 2-5, new CG-UCI part 1 bits are coded together with CSI part 1 bits, and new CG-UCI part 2 bits are coded together with CSI part 2 bits, which further reduces the total number of coding parts and allows for proper reporting of dynamic indication by CG-UCI for unused CG PUSCH occasions.

[0201] <Option 2-6 of Proposal 2> In option 2-6, new CG-UCI part 1 bits are coded together with CSI part 2 bits. In option 2-6, new CG-UCI part 2 bits are coded separately from other UCI bits. Note that the relationship between the priorities of the two-part CG-UCI in option 2-6, that is, the priority of the coding part including new CG-UCI part 1 bits and the coding part including new CG-UCI part 2 bits, may be as follows: [HAR-ACK bits if any] > [CSI part 1 bits if any] > [new CG-UCI part 1 bits and CSI part 2 bits if any] > [new CG-UCI part 2 bits]

[0202] In options 2-6, new CG-UCI part 1 bits are coded together with CSI part 2 bits, which reduces the total number of coding parts and allows for proper reporting of dynamic indication by CG-UCI for unused CG PUSCH occasions.

[0203] <Option 2-7 of Proposal 2> In Option 2-7, new CG-UCI part 1 bits are coded separately from other UCI bits. In Option 2-7, new CG-UCI part 2 bits are coded together with HARQ-ACK bits, CSI part 1 bits, or CSI part 2 bits. Note that the relationship between the priorities of the two-part CG-UCI in Option 2-7, that is, the priority of the coding part including new CG-UCI part 1 bits and the priority of the coding part including new CG-UCI part 2 bits, may be any of the following relationships:

[0204] ・オプション2-7A: [HARQ-ACK bits if any] > [CSI part 1 bits if any] > [new CG-UCI part 1 bits]> [new CG-UCI part 2 bits and CSI part 2 bits if any] ・オプション2-7B: [HARQ-ACK bits if any] > [new CG-UCI part 1 bits]> [new CG-UCI part 2 bits and CSI part 1 bits if any] > [CSI part 2 bits if any] ・オプション2-7C: [HARQ-ACK bits if any] > [new CG-UCI part 1 bits]> [CSI part 1 bits if any] > [new CG-UCI part 2 bits and CSI part 2 bits if any] ・オプション2-7D: [HARQ-ACK bits if any] > [new CG-UCI part 1 bits]> [new CG-UCI part 2 bits and CSI part 1 bits if any] > [CSI part 2 bits if any] ・オプション2-7E: [new CG-UCI part 1 bits] > [HARQ-ACK bits if any] > [CSI part 1 bits if any] > [new CG-UCI part 2 bits and CSI part 2 bits if any] ・オプション2-7F: [new CG-UCI part 1 bits] > [HARQ-ACK bits if any] > [new CG-UCI part 2 bits and CSI part 1 bits if any] > [CSI part 2 bits if any] ・オプション2-7G: [new CG-UCI part 1 bits] > [new CG-UCI part 2 bits and HARQ-ACK bits if any] > [CSI part 1 bits if any] > [CSI part 2bits if any]

[0205] In Option 2-7, the new CG-UCI part 1 bits are coded separately from the other UCI bits, and the new CG-UCI part 2 bits are coded together with the HARQ-ACK bits, CSI part 1 bits, or CSI part 2 bits. This allows appropriate coding (e.g., offset setting) for the new CG-UCI part 1 bits, which enables appropriate reporting of dynamic indication by CG-UCI for unused CG PUSCH occasions.

[0206] As described above, according to Proposal 2, appropriate rules are applied to the coding and rate matching of the two parts of new CG-UCI bits, so that the transmission of new CG-UCI bits, i.e., the reporting of dynamic indication by CG-UCI of unused CG PUSCH occasions, can be performed appropriately.

[0207] <Proposal 3> Proposal 3 describes support for reporting unused CG occasions by CG-UCI in unlicensed spectrum.

[0208] <Option 1 of Proposal 3> Option 1 of Proposal 3 does not support the terminal reporting dynamic indication of unused CG occasions via CG-UCI in unlicensed spectrum or when the cg-RetransmissionTimer is configured. In other words, Option 1 of Proposal 3 does not support the terminal reporting dynamic indication of unused CG occasions via CG-UCI in unlicensed spectrum. Alternatively, Option 1 of Proposal 3 does not support the terminal reporting dynamic indication of unused CG occasions via CG-UCI when the cg-RetransmissionTimer is configured.

[0209] For example, if the cg-RetransmissionTimer is configured, the terminal may not assume that it is configured to report dynamic indication of unused CG occasions by the CG-UCI for any CG configuration.

[0210] Also, for example, when the cg-RetransmissionTimer is configured, the terminal does not report dynamic indication of unused CG occasions by CG-UCI in any CG-PUSCH.

[0211] Note that, in Option 1 of Proposal 3, as a variation, it may not be supported for a terminal to report dynamic indication of unused CG occasions by CG-UCI in a specific frequency range (e.g., a range called FR2-2) and / or a specific SCS (e.g., either SCS of 480 kHz or 960 kHz). In other words, in this variation, it may be supported for a terminal to report dynamic indication of unused CG occasions by CG-UCI in a frequency range other than the specific frequency range and / or an SCS other than the specific SCS.

[0212] <Option 2 of Proposal 3> Option 2 of Proposal 3 supports the terminal reporting dynamic indication of unused CG occasions by the CG-UCI in unlicensed spectrum or when the cg-RetransmissionTimer is configured. In other words, Option 2 of Proposal 3 supports the terminal reporting dynamic indication of unused CG occasions by the CG-UCI in unlicensed spectrum. Alternatively, Option 2 of Proposal 3 supports the terminal reporting dynamic indication of unused CG occasions by the CG-UCI when the cg-RetransmissionTimer is configured.

[0213] For example, if the cg-RetransmissionTimer is configured, the terminal may assume that it is configured to report dynamic indication of unused CG occasions by CG-UCI for any CG configuration.

[0214] Also, for example, when the cg-RetransmissionTimer is configured, the terminal may report dynamic indication of unused CG occasions by CG-UCI in any CG-PUSCH.

[0215] In addition, as a variation, Option 2 of Proposal 3 may support terminals reporting dynamic indication of unused CG occasions via CG-UCI in a specific frequency range (e.g., a range called FR2-2) and / or a specific SCS (e.g., either an SCS of 480 kHz or 960 kHz).

[0216] According to Proposal 3, whether or not to support reporting dynamic indication of unused CG occasions by CG-UCI is specified depending on whether the operating frequency band is an unlicensed spectrum or whether the cg-RetransmissionTimer is set. The terminal determines whether or not to report dynamic indication of unused CG occasions by CG-UCI based on, for example, whether or not to support specified depending on whether the operating frequency band is an unlicensed spectrum or whether the cg-RetransmissionTimer is set, and determines and transmits UCI according to the determination. This allows dynamic indication of unused CG occasions to be reported appropriately.

[0217] <Proposal 4> Proposal 4 is based on the following two assumptions: ・Unlicensed spectrum or cg-RetransmissionTimer is set. ・CG-UCI for indicating unused CG PUSCH occasions is single-part CG-UCI.

[0218] The terminal generates new CG-UCI bits. The generation method may be the same as that described in Proposal 1.

[0219] Here, several methods are considered for whether or not to multiplex the new CG-UCI bits and the legacy CG-UCI bits.

[0220] First, when new CG-UCI bits are included in an existing CG-UCI as a new field (i.e., option 2 of generation method 1 described in Proposal 1), the terminal may generate one extended CG-UCI. Here, the method of generating the extended CG-UCI is not particularly limited. For example, the terminal may generate one extended CG-UCI by adding new CG-UCI bits to legacy CG-UCI bits. Alternatively, the terminal may generate one extended CG-UCI by adding legacy CG-UCI bits to new CG-UCI bits. Here, the legacy CG-UCI bits may be, for example, CG-UCI for HPN, RV, NDI, and COT sharing information.

[0221] Second, if the new CG-UCI bits are based on a CG-UCI that is different from the existing CG-UCI (i.e., option 1 of generation method 1 described in Proposal 1), the terminal performs processing by distinguishing the new CG-UCI bits from other CG-UCI (e.g., the existing CG-UCI).

[0222] For example, when other UCI (e.g., HARQ-ACK, CSI, etc.) that is other than the new CG-UCI bits and other than the legacy CG-UCI bits is not multiplexed in the CG-PUSCH, the terminal may perform coding and rate matching by distinguishing between the new CG-UCI bits and the legacy CG-UCI bits.

[0223] In this case, the relationship between the priority of new CG-UCI bits and the priority of legacy CG-UCI bits may be either Alt. 1 or Alt. 2 as follows: Alt. 1: [legacy CG-UCI bits] > [new CG-UCI bits] Alt. 2: [new CG-UCI bits] > [legacy CG-UCI bits]

[0224] For example, when UCI other than new CG-UCI bits (e.g., HARQ-ACK, CSI, etc.) is multiplexed in the CG-PUSCH, several options are considered for multiplexing UCI in the CG-PUSCH. These options will be described below.

[0225] <Option 4-1 of Proposal 4> In Option 4-1, for single-part CG-UCI indicating unused CG PUSCH occasions, the single-part CG-UCI bits (i.e., new CG-UCI bits) are coded together with legacy CG-UCI bits (for HPN, RV, NDI, and COT sharing information). The rules for legacy CG-UCI bits may be applied to coded parts including new CG-UCI bits and legacy CG-UCI bits. According to the rules for legacy CG-UCI bits, the legacy CG-UCI bits are coded and rate-matched together with HARQ-ACK bits. According to the rules for legacy CG-UCI bits, the coded part including legacy CG-UCI bits, new CG-UCI bits, and HARQ-ACK bits has a higher priority than CSI part 1 and CSI part 2 in rate matching.

[0226] The relationship between new CG-UCI bits, legacy CG-UCI bits, HARQ-ACK, CSI part 1 bits, and CSI part 2 bits is expressed as follows: [legacy CG-UCI bits and new CG-UCI bits, and HARQ-ACK if any] > [CSI part 1 bits if any] > [CSI part 2 bits if any]

[0227] This option 4-1 allows transmission of CG-UCI with new CG-UCI bits added while minimizing changes to specifications.

[0228] According to Option 4-1 of Proposal 4, the same rules as for the legacy CG-UCI bits are applied to the new CG-UCI bits. This means that the new CG-UCI bits can be transmitted, i.e., dynamic indications of unused CG PUSCH occasions can be reported by CG-UCI, in a simple manner with minimal changes to the specifications.

[0229] <Option 4-2 of Proposal 4> In Option 4-2, single-part CG-UCI for indicating unused CG PUSCH occasions is coded separately from legacy CG-UCI bits. Note that Option 4-2 is further divided into the following options, Option 4-2A to Option 4-2C. Note that in the following options 4-2A to Option 4-2C, the legacy CG-UCI bits and HARQ-ACK bits are coded together.

[0230] <Option 4-2A> In Option 4-2A, the new CG-UCI bits, the legacy CG-UCI bits and HARQ-ACK bits that are coded together, the CSI part 1 bits, and the CSI part 2 bits are coded separately from each other. In Option 4-2A, the relationship between the priority of the new CG-UCI bits and the priority of other UCI in rate matching may be any of the following four relationships, Alt a-1 to Alt a-4.・Alt a-1: [legacy CG-UCI bits and HARQ-ACK if any] > [CSI part 1 bits if any] > [CSI part 2 bits if any] > [new CG-UCI bits] ・Alt a-2: [legacy CG-UCI bits and HARQ-ACK if any] > [CSI part 1 bits if any] > [new CG-UCI bits] > [CSI part 2 bits if any] ・Alt a-3: [legacy CG-UCI bits and HARQ-ACK if any] > [new CG-UCI bits] > [CSI part 1 bits if any] > [CSI part 2 bits if any] ・Alt a-4: [new CG-UCI bits] > [legacy CG-UCI bits and HARQ-ACK if any] > [CSI part 1 bits if any] > [CSI part 2 bits if any]

[0231] In the case of new CG-UCI bits, β CG-UCI offset may be set by the existing "betaOffsetCG-UCI-r16" or a new RRC parameter. As an example, the new RRC parameter may be written as "betaOffsetCG-UCI-unused-occasion-r18".

[0232] In option 4-2A, the new CG-UCI bits are coded separately from other UCI bits, allowing coding appropriate for each (for example, setting the offset size).

[0233] <Option 4-2B> In Option 4-2B, the new CG-UCI bits are coded together with the CSI part 1 bits, and the new CG-UCI bits are coded separately from the legacy CG-UCI bits and HARQ-ACK bits coded together with the new CG-UCI bits and the CSI part 2 bits, and rate matching is performed separately. In Option 4-2B, the priority of the new CG-UCI bits and CSI part 1 bits may follow the priority of the existing CSI part 1 bits in rate matching. In other words, the priority of the coding part including the new CG-UCI bits and CSI part 1 bits is lower than the HARQ ACK bits and higher than the CSI part 2 bits. In other words, the relationship in Option 4-2B may be as follows: [legacy CG-UCI bits and HARQ-ACK if any] > [new CG-UCI bits and CSI part 1 bits if any] > [CSI part 2 bits if any]

[0234] <Option 4-2C> In Option 4-2C, new CG-UCI bits are coded together with CSI part 2 bits, and are coded separately from the legacy CG-UCI bits and HARQ-ACK bits coded together and the CSI part 1 bits. In Option 4-2C, the priority of new CG-UCI bits and CSI part 2 bits may follow the priority of the existing CSI part 2 bits in rate matching. In other words, the priority of the coding part including new CG-UCI bits and CSI part 2 bits is lower than HARQ ACK bits and lower than CSI part 1 bits. In other words, the relationship in Option 4-2C may be as follows: [legacy CG-UCI bits and HARQ-ACK if any] > [CSI part 1 bits if any] > [new CG-UCI bits and CSI part 2 bits if any]

[0235] As described above, according to Proposal 4, appropriate rules are applied to the coding and rate matching of single-part new CG-UCI bits, so that transmission of new CG-UCI bits, i.e., reporting of dynamic indication by CG-UCI of unused CG PUSCH occasions, can be performed appropriately.

[0236] <Proposal 5> Proposal 5 is based on the following two assumptions: ・Unlicensed spectrum or cg-RetransmissionTimer is set. ・CG-UCI for indicating unused CG PUSCH occasions is two-part CG-UCI.

[0237] In the following description, the two-part CG-UCI for indicating unused CG PUSCH occasions, i.e., the two parts, are referred to as "new CG-UCI part 1 bit" and "new CG-UCI part 2 bits." Here, when performing rate matching, "new CG-UCI part 1 bit" has a higher priority than "new CG-UCI part 2 bits." In Proposal 5, these two parts are sometimes collectively referred to as "new CG-UCI bits." Furthermore, the number of bits of each of "new CG-UCI part 1 bit" and "new CG-UCI part 2 bits" may be 1, 2 or more, or may be different from each other.

[0238] Here, several methods are considered regarding whether or not to multiplex the new CG-UCI bits with other UCI.

[0239] For example, when UCI other than the new CG-UCI bits and the legacy CG-UCI bits (e.g., HARQ-ACK, CSI, etc.) is not multiplexed in the CG-PUSCH, the new CG-UCI bits and the legacy CG-UCI bits may be coded and rate-matched using any of the following methods: Alt. 1 to Alt. 3.

[0240] <Alt.1> In Alt.1, new CG-UCI part 1 bits and legacy CG-UCI bits may be coded together as one coding part and rate-matched. Then, new CG-UCI part 2 bits may be coded and rate-matched as another coding part. In this case, the priority relationship in rate matching is, for example, as follows: [new CG-UCI part 1 bits and legacy CG-UCI bits] > [new CG-UCI part 2 bits]

[0241] <Alt.2> In Alt.2, new CG-UCI part 1 bits may be coded as one coding part and rate-matched. Then, new CG-UCI part 2 bits and legacy CG-UCI bits may be coded and rate-matched together as another coding part. In this case, the priority relationship in rate matching may be, for example, either Alt.2A or Alt.2B below. Alt.2A: [new CG-UCI part 1 bits] > [new CG-UCI part 2 bits and legacy CG-UCI bits] Alt.2B: [new CG-UCI part 2 bits and legacy CG-UCI bits] > [new CG-UCI part 1 bits]

[0242] <Alt.3> In Alt.3, legacy CG-UCI bits, new CG-UCI part 1 bits, and new CG-UCI part 2 bits may be coded as three coding parts, and rate matching may be performed. In this case, the priority relationship in rate matching may be, for example, one of Alt.3A, Alt.3B, or Alt.3C below. Alt.3A: [legacy CG-UCI bits] > [new CG-UCI part 1 bits] > [new CG-UCI part 2 bits] Alt.3B: [new CG-UCI part 1 bits] > [legacy CG-UCI bits] > [new CG-UCI part 2 bits] Alt.3C: [new CG-UCI part 1 bits] > [new CG-UCI part 2 bits] > [legacy CG-UCI bits]

[0243] For example, when UCI other than new CG-UCI bits (e.g., HARQ-ACK, CSI, etc.) is multiplexed in the CG-PUSCH, several options are considered for multiplexing UCI in the CG-PUSCH. These options will be described later. Note that in the following options 5-1 to 5-7, the legacy CG-UCI bits and HARQ-ACK bits are coded together.

[0244] <Option 5-1 of Proposal 5> In Option 5-1, each UCI including two-part CG-UCI is coded separately. Note that the priority of two-part CG-UCI in Option 5-1, that is, the relationship of the priorities including the priority of new CG-UCI part 1 bits and the priority of new CG-UCI part 2 bits, may be any of the relationships in Option 5-1A to Option 5-1K below.

[0245] ・オプション5-1A: [new CG-UCI part 1 bits] > [new CG-UCI part 2 bits] > [legacy CG-UCI bits and HARQ-ACK if any] > [CSI part 1 bits if any] > [CSI part 2 bits if any] ・オプション5-1B: [new CG-UCI part 1 bits] > [legacy CG-UCI bits and HARQ-ACK if any] > [new CG-UCI part 2 bits] > [CSI part 1 bits if any] > [CSI part 2 bits if any] ・オプション5-1C: [new CG-UCI part 1 bits] >[legacy CG-UCI bits and HARQ-ACK if any] > [CSI part 1 bits if any] > [new CG-UCI part 2 bits] > [CSI part 2 bits if any] ・オプション5-1D: [new CG-UCI part 1 bits] >[HARQ-ACK and legacy CG-UCI bits] > [CSI part 1 bits if any] > [CSI part 2 bits if any] > [new CG-UCI part 2 bits] ・オプション5-1E: [legacy CG-UCI bits and HARQ-ACK if any] > [new CG-UCI part 1 bits] > [new CG-UCI part 2 bits] > [CSI part 1 bits if any] > [CSI part 2 bits if any] ・オプション5-1F: [legacy CG-UCI bits and HARQ-ACK if any] > [new CG-UCI part 1 bits] > [CSI part 1 bits if any] > [new CG-UCI part 2 bits] > [CSI part 2 bits if any] ・オプション5-1G: [legacy CG-UCIOption 5-1H: [legacy CG-UCI bits and HARQ-ACK if any] > [CSI part 1 bits if any] > [new CG-UCI part 1 bits] > [new CG-UCI part 2 bits] > [CSI part 2 bits if any] ・Option 5-1J: [legacy CG-UCI bits and HARQ-ACK if any] > [CSI part 1 bits if any] > [new CG-UCI part 1 bits] > [CSI part 2 bits if any] > [new CG-UCI part 2 bits] ・Option 5-1K: [legacy CG-UCI bits and HARQ-ACK if any] > [CSI part 1 bits if any] > [CSI part 2 bits if any] > [new CG-UCI part 1 bits] > [new CG-UCI part 2 bits]

[0246] In Option 5-1, new CG-UCI part 1 bits and new CG-UCI part 2 bits are coded separately, allowing for coding appropriate for each bit (for example, setting the offset size).

[0247] <Option 5-2 of Proposal 5> In Option 5-2, the new CG-UCI part 1 bits are coded together with the HARQ-ACK bits. That is, the rules for the legacy CG-UCI bits apply to the new CG-UCI part 1 bits. In this case, in Option 5-2, the new CG-UCI part 1 bits, legacy CG-UCI bits, and HARQ-ACK bits are coded together. In Option 5-2, the new CG-UCI part 2 bits are coded separately from the other UCI bits. Note that the priority of the two-part CG-UCI in Option 5-2, that is, the relationship between the priorities including the priority of the new CG-UCI part 1 bits and the priority of the new CG-UCI part 2 bits, may be any of the relationships in Option 5-2A to Option 5-2E below.

[0248] ・オプション5-2A: [legacy CG-UCI bits and new CG-UCI part 1 bits, and HARQ-ACK if any] > [CSI part 1 bits if any] > [CSI part 2 bits if any] > [new CG-UCI part 2 bits] ・オプション5-2B: [legacy CG-UCI bits and new CG-UCI part 1 bits, and HARQ-ACK if any] > [CSI part 1 bits if any] > [new CG-UCI part 2 bits] > [CSI part 2 bits if any] ・オプション5-2C: [legacy CG-UCI bits and new CG-UCI part 1 bits, and HARQ-ACK if any] > [new CG-UCI part 2 bits] > [CSI part 1 bits if any] > [CSI part 2 bits if any] ・オプション5-2D: [legacy CG-UCI bits and new CG-UCI part 1 bits, and HARQ-ACK if any] > [CSI part 1 bits if any] > [new CG-UCI part 2 bits and CSI part 2 bits if any] ・オプション5-2E: [legacy CG-UCI bits and new CG-UCI part 1 bits, and HARQ-ACK if any] > [new CG-UCI part 2 bits and CSI part 1 bits if any] > [CSI part 2 bits if any]

[0249] In option 5-2, new CG-UCI part 1 bits are coded together with HARQ-ACK bits, which reduces the total number of coded parts and allows the coded part including new CG-UCI part 1 bits to be transmitted with the same priority as HARQ-ACK bits, thereby enabling appropriate reporting of dynamic indication by CG-UCI for unused CG PUSCH occasions.

[0250] <Option 5-3 of Proposal 5> In Option 5-3, new CG-UCI part 1 bits are coded together with HARQ-ACK bits. That is, the rules for legacy CG-UCI bits apply to new CG-UCI part 1 bits. In this case, in Option 5-2, new CG-UCI part 1 bits, legacy CG-UCI bits, and HARQ-ACK bits are coded together. In Option 5-3, new CG-UCI part 2 bits are coded together with CSI part 1 bits or CSI part 2 bits. Note that the priority of the two-part CG-UCI in Option 5-3, that is, the relationship between the priority of the coding part including new CG-UCI part 1 bits and the priority of the coding part including new CG-UCI part 2 bits, may be any of the relationships in Option 5-3A to Option 5-3B below.

[0251] ・Option 5-3A: [legacy CG-UCI bits and new CG-UCI part 1 bits, and HARQ-ACK if any] > [new CG-UCI part 2 bits and CSI part 1 bits if any] > [CSI part 2 bits if any] ・Option 5-3B: [legacy CG-UCI bits and new CG-UCI part 1 bits, and HARQ-ACK if any] > [CSI part 1 bits if any] > [new CG-UCI part 2 bits and CSI part 2 bits if any]

[0252] In option 5-3, the new CG-UCI part 1 bits are coded together with the HARQ-ACK bits, and the new CG-UCI part 2 bits are coded together with the CSI part 1 bits or CSI part 2 bits. This further reduces the total number of coded parts, and also allows the coded part including the new CG-UCI part 1 bits to be transmitted with the same priority as the HARQ-ACK bits, allowing for appropriate reporting of dynamic indication by CG-UCI for unused CG PUSCH occasions.

[0253] <Option 5-4 of Proposal 5> In Option 5-4, new CG-UCI part 1 bits are coded together with CSI part 1 bits, and new CG-UCI part 2 bits are coded separately from other UCI bits. Note that the priority of the two-part CG-UCI in Option 5-4, that is, the relationship between the priority of the coded part including new CG-UCI part 1 bits and the priority of the coded part including new CG-UCI part 2 bits, may be any of the relationships in Option 5-4A to Option 5-4B below.・Option 5-4A: [legacy CG-UCI bits and HARQ-ACK if any] > [new CG-UCI part 1 bits and CSI part 1 bits if any] > [new CG-UCI part 2 bits] > [CSI part 2 bits if any] ・Option 5-4B: [legacy CG-UCI bits and HARQ-ACK if any] > [new CG-UCI part 1 bits and CSI part 1 bits if any] > [CSI part 2 bits if any] > [new CG-UCI part 2 bits]

[0254] In option 5-4, new CG-UCI part 1 bits are coded together with CSI part 1 bits, which reduces the total number of coding parts and allows for proper reporting of dynamic indication by CG-UCI for unused CG PUSCH occasions.

[0255] <Option 5-5 of Proposal 5> In Option 5-5, new CG-UCI part 1 bits are coded together with CSI part 1 bits, and new CG-UCI part 2 bits are coded together with CSI part 2 bits. Note that the relationship between the priorities of the two-part CG-UCI in Option 5-5, that is, the priorities of the coding part including new CG-UCI part 1 bits and the coding part including new CG-UCI part 2 bits, may be as follows: [legacy CG-UCI bits and HARQ-ACK if any] > [CSI part 1 bits and / or new CG-UCI part 1 bits] > [new CG-UCI part 2 bits and CSI part 2 bits if any]

[0256] Note that in the above-mentioned Option 5-5, [CSI part 1 bits and / or new CG-UCI part 1 bits] means that it may be either [CSI part 1 bits and new CG-UCI part 1 bits] or [CSI part 1 bits or new CG-UCI part 1 bits]. [CSI part 1 bits and new CG-UCI part 1 bits] indicates that CSI part 1 bits and new CG-UCI part 1 bits are coded together. [CSI part 1 bits or new CG-UCI part 1 bits] indicates that one of CSI part 1 bits and new CG-UCI part 1 bits may be coded, and the other may be discarded (or dropped).

[0257] In option 5-5, new CG-UCI part 1 bits are coded together with CSI part 1 bits, and new CG-UCI part 2 bits are coded together with CSI part 2 bits. This further reduces the total number of coding parts, allowing for proper reporting of dynamic indication by CG-UCI for unused CG PUSCH occasions.

[0258] <Option 5-6 of Proposal 5> In option 5-6, new CG-UCI part 1 bits are coded together with CSI part 2 bits. In option 5-6, new CG-UCI part 2 bits are coded separately from other UCI bits. Note that the relationship between the priorities of the two-part CG-UCI in option 5-6, that is, the priority of the coding part including new CG-UCI part 1 bits and the coding part including new CG-UCI part 2 bits, may be as follows: [legacy CG-UCI bits and HARQ-ACK if any] > [CSI part 1 bits if any] > [new CG-UCI part 1 bits and CSI part 2 bits if any] > [new CG-UCI part 2 bits]

[0259] In option 5-6, new CG-UCI part 1 bits are coded together with CSI part 2 bits, which reduces the total number of coding parts and allows for proper reporting of dynamic indication by CG-UCI for unused CG PUSCH occasions.

[0260] <Option 5-7 of Proposal 5> In Option 5-7, new CG-UCI part 1 bits are coded separately from other UCI bits. In Option 5-7, new CG-UCI part 2 bits are coded together with HARQ-ACK bits, CSI part 1 bits, or CSI part 2 bits. Note that the relationship between the priorities of the two-part CG-UCI in Option 5-7, that is, the priority of the coding part including new CG-UCI part 1 bits and the priority of the coding part including new CG-UCI part 2 bits, may be any of the following relationships:

[0261] ・オプション5-7A: [legacy CG-UCI bits and HARQ-ACK if any] > [ CSI part 1 bits if any] > [new CG-UCI part 1 bits]> [new CG-UCI part 2 bits and CSI part 2 bits if any] ・オプション5-7B: [legacy CG-UCI bits and HARQ-ACK if any] > [new CG-UCI part 1 bits]> [new CG-UCI part 2 bits and CSI part 1 bits if any] > [ CSI part 2 bits if any] ・オプション5-7C: [legacy CG-UCI bits and HARQ-ACK if any] > [new CG-UCI part 1 bits]> [ CSI part 1 bits if any] > [new CG-UCI part 2 bits and CSI part 2 bits if any] ・オプション5-7D: [legacy CG-UCI bits and HARQ-ACK if any] > [new CG-UCI part 1 bits]> [new CG-UCI part 2 bits and CSI part 1 bits if any] > [ CSI part 2 bits if any] ・オプション5-7E: [new CG-UCI part 1 bits]>[legacy CG-UCI bits and HARQ-ACK if any] > [ CSI part 1 bits if any] > [new CG-UCI part 2 bits and CSI part 2 bits if any] ・オプション5-7F: [new CG-UCI part 1 bits]>[legacy CG-UCI bits and HARQ-ACK if any] > [new CG-UCI part 2 bits and CSI part 1 bits if any] > [ CSI part 2 bits if any] ・オプション5-7G: [newCG-UCI part 1 bits]>[legacy CG-UCI bits and new CG-UCI part 2 bits, and HARQ-ACK if any] > [CSI part 1 bits if any] > [CSI part 2 bits if any]

[0262] In options 5-7, new CG-UCI part 1 bits are coded separately from other UCI bits, and new CG-UCI part 2 bits are coded together with HARQ-ACK bits, CSI part 1 bits, or CSI part 2 bits. This allows appropriate coding (e.g., offset setting) for new CG-UCI part 1 bits, which enables appropriate reporting of dynamic indication by CG-UCI for unused CG PUSCH occasions.

[0263] As described above, according to Proposal 5, appropriate rules are applied to the coding and rate matching of the two parts of the new CG-UCI bits, so that the transmission of the new CG-UCI bits, i.e., the reporting of dynamic indication by the CG-UCI of unused CG PUSCH occasions, can be performed appropriately.

[0264] <Capability> At least one of the following may be reported as a capability from the terminal to the BS. Information specifying whether, in a licensed spectrum, the terminal supports reporting dynamic indication of unused CG occasions by CG-UCI; Information specifying whether, in a licensed spectrum, the terminal supports jointly encoding CG-UCI with HARQ-ACK; Information specifying whether, in a licensed spectrum, the terminal supports jointly encoding CG-UCI with CSI part 1; Information specifying whether, in a licensed spectrum, the terminal supports jointly encoding CG-UCI with CSI part 2; Information specifying whether, in an unlicensed spectrum, the terminal supports reporting dynamic indication of unused CG occasions by CG-UCI; Information specifying whether, in an unlicensed spectrum, the terminal supports jointly encoding CG-UCI with HARQ-ACK; Information specifying whether, in an unlicensed spectrum, the terminal supports jointly encoding CG-UCI with CSI part 1. Information specifying whether the terminal supports joint coding of CG-UCI with CSI part 2 in unlicensed spectrum

[0265] Note that some of the above may be reported together. For example, in a licensed spectrum, if a terminal reports that it supports jointly encoding CG-UCI with other UCIs as a capability, this report may include that the terminal supports jointly encoding CG-UCI with HARQ-ACK, supports jointly encoding CG-UCI with CSI part 1, and supports jointly encoding CG-UCI with CSI part 2.

[0266] In addition, in the above description, the capability of a terminal in a licensed spectrum and the capability of a terminal in an unlicensed spectrum may be aggregated. For example, if a terminal reports that it supports jointly encoding CG-UCI with HARQ-ACK as a capability, this report may include that the terminal supports jointly encoding CG-UCI with HARQ-ACK in both the licensed spectrum and the unlicensed spectrum.

[0267] Regarding the above-mentioned capabilities, the capabilities of a terminal in a licensed spectrum may be interpreted as the capabilities of a terminal when the cg-RetransmissionTimer is not set, and the capabilities of a terminal in an unlicensed spectrum may be interpreted as the capabilities of a terminal when the cg-RetransmissionTimer is set.

[0268] In addition, in the above-mentioned proposals and their options, the fact that they are coded individually corresponds to the fact that rate matching is also performed individually.

[0269] In the above-mentioned examples of the relationship between the priorities of each proposal and its options, the expression [A and B] may be read as [A and / or B] or [A or B].

[0270] Note that, in the above-described proposals and their options, examples of priority relationships have been given, including a priority relationship including new CG-UCI bits and a priority relationship including new CG-UCI part 1 bits and new CG-UCI part 2 bits. However, for example, cases in which new CG-UCI bits do not exist and cases in which at least one of new CG-UCI part 1 bits and new CG-UCI part 2 bits does not exist may also be defined. In other words, in the above-described examples of priority relationships in the proposals and their options, the term "new CG-UCI bits" may be replaced with "new CG-UCI bits if any," and the terms "new CG-UCI part 1 bits" and "new CG-UCI part 2 bits" may be replaced with "new CG-UCI part 1 bits if any" and "new CG-UCI part 2 bits if any."

[0271] <Example of Wireless Communication System> A wireless communication system according to this embodiment includes a base station 10 shown in FIG. 10 and a terminal 20 shown in FIG. 11. The number of base stations 10 and the number of terminals 20 are not particularly limited. For example, as shown in FIG. 1, the system may be one in which two base stations 10 (base station 10-1 and base station 10-2) communicate with one terminal 20. The wireless communication system may be a wireless communication system conforming to New Radio (NR). For example, the wireless communication system may be a wireless communication system conforming to a method called URLLC and / or IIoT.

[0272] The wireless communication system may be a wireless communication system conforming to a method called 5G, Beyond 5G, 5G Evolution, or 6G.

[0273] The base station 10 may be called an NG-RAN Node, ng-eNB, eNodeB (eNB), or gNodeB (gNB). The terminal 20 may be called User Equipment (UE). The base station 10 may also be considered as a device included in a network to which the terminal 20 is connected.

[0274] The wireless communication system may include a Next Generation-Radio Access Network (hereinafter, referred to as NG-RAN). The NG-RAN includes multiple NG-RAN nodes, specifically, gNBs (or ng-eNBs), and is connected to a 5G core network (5GC, not shown). Note that the NG-RAN and 5GC may be simply referred to as a "network."

[0275] The base station 10 performs wireless communication with the terminal 20. For example, the wireless communication performed complies with NR. At least one of the base station 10 and the terminal 20 may support Massive MIMO (Multiple-Input Multiple-Output), which generates a more directional beam (BM) by controlling radio signals transmitted from multiple antenna elements. Furthermore, at least one of the base station 10 and the terminal 20 may support Carrier Aggregation (CA), which aggregates and uses multiple component carriers (CC). Furthermore, at least one of the base station 10 and the terminal 20 may support Dual Connectivity (DC), which performs communication between the terminal 20 and each of multiple base stations 10.

[0276] The wireless communication system may support multiple frequency bands. For example, the wireless communication system supports Frequency Range (FR) 1 and FR2. The frequency bands of each FR are, for example, as follows: FR1: 410 MHz to 7.125 GHz FR2: 24.25 GHz to 52.6 GHz

[0277] FR1 may use a sub-carrier spacing (SCS) of 15 kHz, 30 kHz, or 60 kHz, and may use a bandwidth (BW) of 5 MHz to 100 MHz. FR2, for example, is a higher frequency than FR1. FR2 may use an SCS of 60 kHz or 120 kHz, and may use a bandwidth (BW) of 50 MHz to 400 MHz. FR2 may also include an SCS of 240 kHz.

[0278] The wireless communication system according to this embodiment may support a frequency band higher than the FR2 frequency band. For example, the wireless communication system according to this embodiment may support a frequency band exceeding 52.6 GHz up to 114.25 GHz. Such a high frequency band may be called "FR2x" (e.g., FR2-1 or FR2-2).

[0279] Alternatively, Cyclic Prefix-Orthogonal Frequency Division Multiplexing (CP-OFDM) / Discrete Fourier Transform-Spread-Orthogonal Frequency Division Multiplexing (DFT-S-OFDM) having a larger Sub-Carrier Spacing (SCS) than the above-mentioned example may be applied. Furthermore, DFT-S-OFDM may be applied to both the uplink and the downlink, or to either one of them.

[0280] In a wireless communication system, a slot configuration pattern for time division duplexing (TDD) may be set. For example, the slot configuration pattern may specify a pattern indicating an order of two or more slots among a slot for transmitting a downlink (DL) signal, a slot for transmitting an uplink (UL) signal, a slot in which a DL signal, a UL signal, and a guard symbol are mixed, and a slot in which a signal to be transmitted is changed to flexible.

[0281] In addition, in a wireless communication system, a demodulation reference signal (DMRS) can be used for each slot to perform channel estimation of a PUSCH (or a PUCCH (Physical Uplink Control Channel)), and further, a DMRS allocated to each of multiple slots can be used to perform channel estimation of a PUSCH (or a PUCCH). Such channel estimation may be called joint channel estimation, or may be called by another name such as cross-slot channel estimation.

[0282] The terminal 20 may transmit, in multiple slots, the DMRS allocated to each of the multiple slots so that the base station 10 can perform joint channel estimation using the DMRS.

[0283] Furthermore, in the wireless communication system, an enhanced function may be added to the feedback function from the terminal 20 to the base station 10. For example, an enhanced function may be added to the feedback of the terminal regarding HARQ-ACK.

[0284] Next, the configurations of the base station 10 and the terminal 20 will be described. Note that the configurations of the base station 10 and the terminal 20 described below are examples of functions related to this embodiment. The base station 10 and the terminal 20 may have functions not shown. Furthermore, the functional divisions and / or names of the functional units are not limited as long as the functions perform the operations related to this embodiment.

[0285] <Configuration of Base Station> Fig. 10 is a block diagram showing an example of the configuration of base station 10 according to this embodiment. Base station 10 includes, for example, a transmitting unit 101, a receiving unit 102, and a control unit 103. Base station 10 communicates with terminal 20 (see Fig. 11) wirelessly.

[0286] The transmitter 101 transmits a downlink (DL) signal to the terminal 20. For example, the transmitter 101 transmits the DL signal under the control of the controller 103.

[0287] The DL signal may include, for example, a downlink data signal and control information (e.g., Downlink Control Information (DCI)). The DL signal may also include information indicating scheduling related to signal transmission of the terminal 20 (e.g., an UL grant). The DL signal may also include control information of higher layers (e.g., control information of Radio Resource Control (RRC)). The DL signal may also include a reference signal.

[0288] The channels used for transmitting DL signals include, for example, a data channel and a control channel. For example, the data channel may include a PDSCH (Physical Downlink Shared Channel), and the control channel may include a PDCCH (Physical Downlink Control Channel). For example, the base station 10 transmits control information to the terminal 20 using the PDCCH and transmits downlink data signals using the PDSCH.

[0289] The reference signal included in the DL signal may include at least one of a demodulation reference signal (Demodulation Reference Signal (DMRS)), a Phase Tracking Reference Signal (PTRS), a Channel State Information-Reference Signal (CSI-RS), a Sounding Reference Signal (SRS), and a Positioning Reference Signal (PRS) for position information. For example, reference signals such as DMRS and PTRS are used for demodulating downlink data signals and are transmitted using the PDSCH.

[0290] The receiving unit 102 receives an uplink (UL) signal transmitted from the terminal 20. For example, the receiving unit 102 receives the UL signal under the control of the control unit 103.

[0291] The control unit 103 controls the communication operations of the base station 10 , including the transmission processing of the transmission unit 101 and the reception processing of the reception unit 102 .

[0292] For example, the control unit 103 acquires information such as data and control information from the upper layer and outputs it to the transmitting unit 101. The control unit 103 also outputs the data, control information, etc. received from the receiving unit 102 to the upper layer.

[0293] For example, the control unit 103 allocates resources (or channels) used for transmitting and receiving DL signals and / or resources used for transmitting and receiving UL signals based on signals (e.g., data and control information, etc.) received from the terminal 20 and / or data and control information, etc. acquired from a higher layer. Information on the allocated resources may be included in control information transmitted to the terminal 20.

[0294] The control unit 103 sets PUCCH resources as an example of allocation of resources used for transmitting and receiving UL signals. Information related to PUCCH configuration such as a PUCCH cell timing pattern (PUCCH configuration information) may be notified to the terminal 20 by RRC.

[0295] For example, the base station 10 in this embodiment receives uplink control information (UCI) in the receiving section 102. The received uplink control information may include dynamic indication of unused CG PUSCH occasions by CG-UCI.

[0296] 11 is a block diagram showing an example of the configuration of terminal 20 according to this embodiment. Terminal 20 includes, for example, a receiving unit 201, a transmitting unit 202, and a control unit 203. Terminal 20 communicates with base station 10, for example, wirelessly.

[0297] The receiving unit 201 receives a DL signal transmitted from the base station 10. For example, the receiving unit 201 receives the DL signal under the control of the control unit 203.

[0298] The transmitting unit 202 transmits the UL signal to the base station 10. For example, the transmitting unit 202 transmits the UL signal under the control of the control unit 203.

[0299] The UL signal may include, for example, an uplink data signal and control information (e.g., UCI). For example, information related to the processing capabilities of the terminal 20 (e.g., UE capability or simply capability) may be included. The UL signal may also include a reference signal.

[0300] Channels used for transmitting UL signals include, for example, data channels and control channels. For example, the data channels include a PUSCH (Physical Uplink Shared Channel), and the control channels include a PUCCH (Physical Uplink Control Channel). For example, the terminal 20 receives control information from the base station 10 using the PUCCH and transmits uplink data signals using the PUSCH.

[0301] The reference signals included in the UL signal may include, for example, at least one of DMRS, PTRS, CSI-RS, SRS, and PRS. For example, the reference signals such as DMRS and PTRS are used for demodulating the uplink data signal and are transmitted using an uplink channel (for example, PUSCH).

[0302] The control unit 203 controls the communication operations of the terminal 20 , including the reception processing in the receiving unit 201 and the transmission processing in the transmitting unit 202 .

[0303] For example, the control unit 203 acquires information such as data and control information from the upper layer and outputs it to the transmitting unit 202. Also, the control unit 203 outputs, for example, the data and control information received from the receiving unit 201 to the upper layer.

[0304] For example, the control unit 203 controls transmission of information to be fed back to the base station 10. The information to be fed back to the base station 10 may include, for example, HARQ-ACK, Channel State Information (CSI), or a Scheduling Request (SR). The information to be fed back to the base station 10 may be included in UCI. The UCI is transmitted in PUCCH resources.

[0305] The control unit 203 sets PUCCH resources based on configuration information (for example, configuration information such as a PUCCH cell timing pattern and / or DCI notified by RRC) received from the base station 10. The control unit 203 determines the PUCCH resources to be used for transmitting information to be fed back to the base station 10. Under the control of the control unit 203, the transmission unit 202 transmits the information to be fed back to the base station 10 in the PUCCH resources determined by the control unit 203.

[0306] Note that the channel used for transmitting the DL signal and the channel used for transmitting the UL signal are not limited to the above-mentioned example. For example, the channel used for transmitting the DL signal and the channel used for transmitting the UL signal may include a Random Access Channel (RACH) and a Physical Broadcast Channel (PBCH). The RACH may be used to transmit Downlink Control Information (DCI) including a Random Access Radio Network Temporary Identifier (RA-RNTI), for example.

[0307] For example, in terminal 20 according to the present embodiment, control unit 203 determines uplink control information based on whether or not transmission of first information (e.g., new CG-UCI bits, or new CG-UCI part 1 bits and new CG-UCI part 2 bits) indicating an unused uplink signal occasion (an example of an unused CG occasion) is supported, which is specified depending on whether the spectrum is licensed or a specific control parameter (e.g., cg-RetransmissionTimer) is not set. Then, transmission unit 202 transmits the uplink control information.

[0308] Furthermore, when transmission of the first information is supported and the first information is represented by one first information part (e.g., new CG-UCI bits), the control unit 203 determines the encoding part by encoding together the first information part and a second information part (e.g., HARQ-ACK, CSI, etc.) representing second information different from the first information, and determines uplink control information including the encoding part.

[0309] Furthermore, when transmission of the first information is supported and the first information is represented by a plurality of first information parts (e.g., new CG-UCI part 1 bit and new CG-UCI part 2 bits), the control unit 203 determines the encoding part by jointly encoding a second information part representing second information different from the first information and at least one of the first information parts, and determines uplink control information including the encoding part.

[0310] In addition, when transmission of first information is supported and the first information is represented by one or more first information parts, the control unit 203 determines the encoding part by separately encoding the second information part representing second information different from the first information and the first information part, and determines uplink control information including the encoding part.

[0311] For example, in the terminal 20 according to the present embodiment, the control unit 203 determines the uplink control information based on whether or not transmission of first information indicating an occasion for an unused uplink signal is supported, which is specified depending on whether the spectrum is unlicensed or whether a specific control parameter is set. Then, the transmitting unit 202 transmits the uplink control information.

[0312] The RRC signaling may be referred to as an RRC message or an RRC information element.

[0313] The present disclosure has been described above.

[0314] <Hardware Configuration, etc.> The block diagrams used to explain the above embodiments show functional blocks. These functional blocks (components) are realized by any combination of at least one of hardware and software. Furthermore, the method for realizing each functional block is not particularly limited. That is, each functional block may be realized using a single device that is physically or logically coupled, or may be realized using two or more physically or logically separated devices that are directly or indirectly connected (for example, using wires, wirelessly, etc.) and these multiple devices. The functional block may also be realized by combining software with the single device or the multiple devices.

[0315] Functions include, but are not limited to, judgment, determination, assessment, calculation, computation, processing, derivation, investigation, search, confirmation, reception, transmission, output, access, resolution, selection, selection, establishment, comparison, assumption, expectation, consideration, broadcasting, notifying, communicating, forwarding, configuring, reconfiguring, allocating, mapping, and assignment. For example, a functional block (component) that performs transmission is called a transmitting unit or transmitter. As mentioned above, there are no particular limitations on how these functions are implemented.

[0316] For example, a base station, a terminal, or the like according to an embodiment of the present disclosure may function as a computer that performs processing of the wireless communication method of the present disclosure. Fig. 12 is a diagram illustrating an example of the hardware configuration of a base station and a terminal according to an embodiment of the present disclosure. The base station 10 and the terminal 20 described above may be physically configured as a computer device including a processor 1001, a memory 1002, a storage 1003, a communication device 1004, an input device 1005, an output device 1006, a bus 1007, and the like.

[0317] In the following description, the term "apparatus" can be interpreted as a circuit, a device, a unit, etc. The hardware configuration of the base station 10 and the terminal 20 may be configured to include one or more of the apparatuses shown in the drawings, or may be configured to exclude some of the apparatuses.

[0318] Each function in the base station 10 and the terminal 20 is realized by loading specified software (programs) onto hardware such as the processor 1001 and the memory 1002, causing the processor 1001 to perform calculations, control communication by the communication device 1004, and control at least one of reading and writing data in the memory 1002 and the storage 1003.

[0319] The processor 1001 controls the entire computer by running, for example, an operating system. The processor 1001 may be configured by a central processing unit (CPU) including an interface with peripheral devices, a control device, an arithmetic unit, a register, etc. For example, the above-mentioned control unit 103 and control unit 203 may be realized by the processor 1001.

[0320] The processor 1001 also reads programs (program codes), software modules, data, etc. from at least one of the storage 1003 and the communication device 1004 into the memory 1002 and executes various processes in accordance with these. The programs used are those that cause a computer to execute at least some of the operations described in the above-described embodiments. For example, the control unit 203 of the terminal 20 may be implemented by a control program stored in the memory 1002 and running on the processor 1001, and similar implementations may be made for other functional blocks. While the above-described various processes have been described as being executed by one processor 1001, they may also be executed simultaneously or sequentially by two or more processors 1001. The processor 1001 may be implemented by one or more chips. The programs may also be transmitted from a network via a telecommunications line.

[0321] The memory 1002 is a computer-readable recording medium and may be configured by, for example, at least one of a read-only memory (ROM), an erasable programmable ROM (EPROM), an electrically erasable programmable ROM (EEPROM), a random access memory (RAM), etc. The memory 1002 may also be called a register, a cache, a main memory (primary storage device), etc. The memory 1002 can store executable programs (program codes), software modules, etc. for implementing a wireless communication method according to an embodiment of the present disclosure.

[0322] Storage 1003 is a computer-readable recording medium, and may be composed of at least one of, for example, an optical disk such as a CD-ROM (Compact Disc ROM), a hard disk drive, a flexible disk, a magneto-optical disk (e.g., a compact disk, a digital versatile disk, a Blu-ray (registered trademark) disk), a smart card, a flash memory (e.g., a card, a stick, a key drive), a floppy (registered trademark) disk, a magnetic strip, etc. Storage 1003 may also be referred to as an auxiliary storage device. The above-mentioned storage medium may be, for example, a database, a server, or other appropriate medium including at least one of memory 1002 and storage 1003.

[0323] The communication device 1004 is hardware (transmission / reception device) for communicating between computers via at least one of a wired network and a wireless network, and is also referred to as, for example, a network device, a network controller, a network card, a communication module, etc. The communication device 1004 may be configured to include a high-frequency switch, a duplexer, a filter, a frequency synthesizer, etc. to realize at least one of frequency division duplex (FDD) and time division duplex (TDD). For example, the above-mentioned transmitter 101, receiver 102, receiver 201, transmitter 202, etc. may be realized by the communication device 1004.

[0324] The input device 1005 is an input device (e.g., a keyboard, a mouse, a microphone, a switch, a button, a sensor, etc.) that receives input from the outside. The output device 1006 is an output device (e.g., a display, a speaker, an LED lamp, etc.) that outputs to the outside. The input device 1005 and the output device 1006 may be integrated into one device (e.g., a touch panel).

[0325] Furthermore, each device, such as the processor 1001 and the memory 1002, is connected by a bus 1007 for communicating information. The bus 1007 may be configured using a single bus, or may be configured using different buses between each device.

[0326] Furthermore, the base station 10 and the terminal 20 may be configured to include hardware such as a microprocessor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a programmable logic device (PLD), or a field programmable gate array (FPGA), and some or all of the functional blocks may be realized by the hardware. For example, the processor 1001 may be implemented using at least one of these pieces of hardware.

[0327] (Supplementary Notes on the Embodiments) Although the embodiments of the present disclosure have been described above, the disclosed invention is not limited to such embodiments, and those skilled in the art will understand various modifications, alterations, alternatives, and substitutions. While specific numerical examples have been used to facilitate understanding of the invention, unless otherwise specified, these numerical values ​​are merely examples, and any appropriate values ​​may be used. The division of items in the above description is not essential to the present disclosure; matters described in two or more items may be used in combination as needed, and matters described in one item may apply to matters described in another item (unless inconsistent). Boundaries between functional units or processing units in functional block diagrams do not necessarily correspond to boundaries between physical components. The operations of multiple functional units may be performed by a single physical component, or the operations of a single functional unit may be performed by multiple physical components. The order of processing procedures described in the embodiments may be reversed as long as there is no contradiction. For convenience of processing description, base stations and terminals have been described using functional block diagrams, but such devices may be implemented in hardware, software, or a combination thereof. The software operated by the processor of a base station in accordance with an embodiment of the present disclosure, and the software operated by the processor of a terminal in accordance with an embodiment of the present disclosure may each be stored in random access memory (RAM), flash memory, read-only memory (ROM), EPROM, EEPROM, register, hard disk (HDD), removable disk, CD-ROM, database, server, or any other suitable storage medium.

[0328] <Notification of Information, Signaling> Notification of information is not limited to the embodiments described in the present disclosure and may be performed using other methods. For example, notification of information may be performed by physical layer signaling (e.g., Downlink Control Information (DCI), Uplink Control Information (UCI)), higher layer signaling (e.g., Radio Resource Control (RRC) signaling, Medium Access Control (MAC) signaling, broadcast information (Master Information Block (MIB), System Information Block (SIB))), other signals, or a combination thereof. Furthermore, RRC signaling may be referred to as an RRC message, and may be, for example, an RRC Connection Setup message, an RRC Connection Reconfiguration message, or the like.

[0329] <Applicable Systems> The embodiments described in the present disclosure are applicable to LTE (Long Term Evolution), LTE-Advanced (LTE-A), SUPER 3G, IMT-Advanced, 4G (4th generation mobile communication system), 5G (5th generation mobile communication system), 6th generation mobile communication system (6G), xth generation mobile communication system (xG) (xG (x is, for example, an integer or a decimal)), FRA (Future Radio Access), NR (new Radio), New radio access (NX), Future generation radio access (FX), W-CDMA (registered trademark), GSM (registered trademark), CDMA2000, UMB (Ultra Mobile Broadband), IEEE 802.11 (Wi-Fi (registered trademark)), IEEE 802.16 (WiMAX (registered trademark)), IEEE 802.17 (WiMAX (registered trademark)), IEEE 802.19 (WiMAX (registered trademark)), IEEE 802.20 (WiMAX (registered trademark)), IEEE 802.21 (Wi-Fi (registered trademark)), IEEE 802.22 (WiMAX (registered trademark)), IEEE 802.23 (WiMAX (registered trademark)), IEEE 802.24 (WiMAX (registered trademark)), IEEE 802.25 (WiMAX (registered trademark)), IEEE 802.26 (WiMAX (registered trademark)), IEEE 802.27 (WiMAX (registered trademark)), IEEE 802.28 (WiMAX (registered trademark)), IEEE 802.29 (WiMAX (registered trademark)), IEEE 802.30 (WiMAX (registered trademark)), IEEE 802.31 (Wi-Fi (registered trademark)), IEEE 802.32 (WiMAX (registered trademark)), IEEE 802.33 (WiMAX (registered trademark)), IEEE 802.34 (WiMAX (registered trademark The present invention may be applied to at least one of systems using 802.20, UWB (Ultra-Wide Band), Bluetooth (registered trademark), or other suitable systems, and next-generation systems that are extended, modified, created, or defined based on these systems. The present invention may also be applied to a combination of multiple systems (e.g., a combination of LTE and / or LTE-A with 5G).

[0330] <Processing Procedures, etc.> The processing procedures, sequences, flowcharts, etc. of each aspect / embodiment described in this disclosure may be rearranged unless inconsistent. For example, the methods described in this disclosure present elements of various steps using an example order, and are not limited to the particular order presented.

[0331] <Operation of Base Station> In the present disclosure, specific operations described as being performed by a base station may also be performed by its upper node in some cases. In a network consisting of one or more network nodes having a base station, it is clear that various operations performed for communication with a terminal may be performed by at least one of the base station and another network node other than the base station (for example, an MME or an S-GW, etc., but are not limited to these). Although the above example illustrates a case where there is one other network node other than the base station, a combination of multiple other network nodes (for example, an MME and an S-GW) may also be used.

[0332] <Direction of Input / Output> Information, etc. (see <Information, Signal>) can be output from a higher layer (or a lower layer) to a lower layer (or a higher layer). It may also be input / output via multiple network nodes.

[0333] <Handling of Input / Output Information, etc.> Input / output information, etc. may be stored in a specific location (for example, memory) or may be managed using a management table. Input / output information, etc. may be overwritten, updated, or added. Output information, etc. may be deleted. Input information, etc. may be sent to another device.

[0334] <Determination method> The determination may be made based on a value represented by one bit (0 or 1), a Boolean value (true or false), or a comparison of numerical values ​​(e.g., comparison with a predetermined value).

[0335] <Variations of Aspects, etc.> Each aspect / embodiment described in the present disclosure may be used alone, in combination, or switched depending on the implementation. In addition, notification of predetermined information (e.g., notification that "X is true") is not limited to being done explicitly, but may be done implicitly (e.g., by not notifying the predetermined information).

[0336] Although the present disclosure has been described in detail above, it is clear to those skilled in the art that the present disclosure is not limited to the embodiments described herein. The present disclosure can be implemented in modified and altered forms without departing from the spirit and scope of the present disclosure as defined by the claims. Therefore, the description of the present disclosure is intended to be illustrative and does not have any limiting meaning on the present disclosure.

[0337] <Software> Software shall be construed broadly to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software modules, applications, software applications, software packages, routines, subroutines, objects, executable files, threads of execution, procedures, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise.

[0338] Software, instructions, information, etc. may also be transmitted or received over a transmission medium. For example, if software is transmitted from a website, server, or other remote source using wired technologies (such as coaxial cable, fiber optic cable, twisted pair, Digital Subscriber Line (DSL)), and / or wireless technologies (such as infrared, microwave), then these wired and / or wireless technologies are included within the definition of transmission media.

[0339] Information, Signals, etc., described in this disclosure may be represented using any of a variety of different technologies. For example, data, instructions, commands, information, signals, bits, symbols, chips, etc., which may be referred to throughout the above description, may be represented by voltages, currents, electromagnetic waves, magnetic fields or magnetic particles, optical fields or photons, or any combination thereof.

[0340] Note that terms described in this disclosure and terms necessary for understanding this disclosure may be replaced with terms having the same or similar meanings. For example, at least one of a channel and a symbol may be a signal (signaling). Furthermore, a signal may be a message. Furthermore, a component carrier (CC) may be called a carrier frequency, a cell, a frequency carrier, etc.

[0341] <System, Network> As used in this disclosure, the terms "system" and "network" are used interchangeably.

[0342] <Parameter and Channel Names> Furthermore, the information, parameters, and the like described in the present disclosure may be expressed using absolute values, relative values ​​from a predetermined value, or other corresponding information. For example, a radio resource may be indicated by an index.

[0343] The names used for the above-described parameters are not intended to be limiting in any way. Furthermore, the mathematical expressions using these parameters may differ from those explicitly disclosed in this disclosure. The various channels (e.g., PUCCH, PDCCH, etc.) and information elements may be identified by any suitable names, and the various names assigned to these various channels and information elements are not intended to be limiting in any way.

[0344] <Base Station> In the present disclosure, terms such as "base station (BS)," "radio base station," "fixed station," "NodeB," "eNodeB (eNB)," "gNodeB (gNB)," "access point," "transmission point," "reception point," "transmission / reception point," "cell," "sector," "cell group," "carrier," and "component carrier" may be used interchangeably. A base station may also be referred to by terms such as a macrocell, a small cell, a femtocell, and a picocell.

[0345] A base station can accommodate one or more (e.g., three) cells. When a base station accommodates multiple cells, the overall coverage area of ​​the base station can be partitioned into multiple smaller areas, and each smaller area can also be provided with communication services by a base station subsystem (e.g., a remote radio head (RRH)). The terms "cell" or "sector" refer to part or the entire coverage area of ​​a base station and / or base station subsystem that provides communication services within that coverage area.

[0346] In the present disclosure, the base station transmitting information to a terminal may be interpreted as the base station instructing the terminal to control or operate based on the information.

[0347] Mobile Station In this disclosure, the terms "Mobile Station (MS)," "user terminal," "User Equipment (UE)," "terminal," and the like may be used interchangeably.

[0348] A mobile station may also be referred to by those skilled in the art as a subscriber station, mobile unit, subscriber unit, wireless unit, remote unit, mobile device, wireless device, wireless communication device, remote device, mobile subscriber station, access terminal, mobile terminal, wireless terminal, remote terminal, handset, user agent, mobile client, client, or some other suitable terminology.

[0349] <Base Station / Mobile Station> At least one of the base station and the mobile station may be referred to as a transmitting device, a receiving device, a communication device, etc. At least one of the base station and the mobile station may be a device mounted on a mobile object, the mobile object itself, etc. The mobile object refers to a movable object, and may move at any speed. Naturally, this also includes cases where the mobile object is stationary. Examples of the mobile object include, but are not limited to, vehicles, transport vehicles, automobiles, motorcycles, bicycles, connected cars, excavators, bulldozers, wheel loaders, dump trucks, forklifts, trains, buses, handcars, rickshaws, ships and other watercraft, airplanes, rockets, satellites, drones (registered trademark), multicopters, quadcopters, balloons, and objects mounted thereon. The mobile object may also be an autonomous mobile object operating based on an operational command. It may be a vehicle (e.g., a car, an airplane, etc.), an unmanned mobile object (e.g., a drone, an autonomous vehicle, etc.), or a robot (manned or unmanned). At least one of the base station and the mobile station may be a device that does not necessarily move during communication operations. For example, at least one of the base station and the mobile station may be an IoT (Internet of Things) device such as a sensor.

[0350] Furthermore, a base station in the present disclosure may be read as a terminal. For example, the embodiments of the present disclosure may be applied to a configuration in which communication between a base station and a terminal is replaced with communication between multiple terminals (which may be called, for example, D2D (Device-to-Device) or V2X (Vehicle-to-Everything)). In this case, the terminal may be configured to have the functions of the base station described above. Furthermore, terms such as "uplink" and "downlink" may be read as terms corresponding to communication between terminals (for example, "side"). For example, terms such as an uplink channel and a downlink channel may be read as a side channel.

[0351] Similarly, the term "terminal" in the present disclosure may be read as "base station." In this case, the base station may be configured to have the functions of the terminal described above.

[0352] Fig. 13 shows an example configuration of a vehicle 2001. As shown in Fig. 13, the vehicle 2001 includes a drive unit 2002, a steering unit 2003, an accelerator pedal 2004, a brake pedal 2005, a shift lever 2006, front wheels 2007, rear wheels 2008, an axle 2009, an electronic control unit 2010, various sensors 2021 to 2029, an information service unit 2012, and a communication module 2013. Each aspect / embodiment described in the present disclosure may be applied to a communication device mounted on the vehicle 2001, and may be applied to the communication module 2013, for example.

[0353] The drive unit 2002 is configured, for example, by an engine, a motor, or a hybrid of an engine and a motor. The steering unit 2003 includes at least a steering wheel (also called a handle) and is configured to steer at least one of the front wheels and the rear wheels based on the operation of the steering wheel operated by the user.

[0354] The electronic control unit 2010 is composed of a microprocessor 2031, a memory (ROM, RAM) 2032, and a communication port (IO port) 2033. Signals are input to the electronic control unit 2010 from various sensors 2021 to 2029 provided in the vehicle 2001. The electronic control unit 2010 may also be called an ECU (Electronic Control Unit).

[0355] The signals from the various sensors 2021 to 2029 include a current signal from a current sensor 2021 that senses the current of the motor, a rotation speed signal of the front and rear wheels obtained by a rotation speed sensor 2022, an air pressure signal of the front and rear wheels obtained by an air pressure sensor 2023, a vehicle speed signal obtained by a vehicle speed sensor 2024, an acceleration signal obtained by an acceleration sensor 2025, an accelerator pedal depression amount signal obtained by an accelerator pedal sensor 2029, a brake pedal depression amount signal obtained by a brake pedal sensor 2026, a shift lever operation signal obtained by a shift lever sensor 2027, and a detection signal for detecting obstacles, vehicles, pedestrians, etc. obtained by an object detection sensor 2028.

[0356] The information service unit 2012 is composed of various devices, such as a car navigation system, an audio system, speakers, a television, and a radio, for providing (outputting) various types of information, such as driving information, traffic information, and entertainment information, and one or more ECUs that control these devices. The information service unit 2012 provides various types of multimedia information and multimedia services to the occupants of the vehicle 2001 by using information acquired from external devices via the communication module 2013, etc.

[0357] The information service unit 2012 may include input devices (e.g., keyboards, mice, microphones, switches, buttons, sensors, touch panels, etc.) that accept input from the outside, and may also include output devices (e.g., displays, speakers, LED lamps, touch panels, etc.) that output to the outside.

[0358] The driving assistance system unit 2030 is composed of various devices that provide functions for preventing accidents and reducing the driving burden on the driver, such as millimeter-wave radar, LiDAR (Light Detection and Ranging), cameras, positioning locators (e.g., GNSS, etc.), map information (e.g., high-definition (HD) maps, autonomous vehicle (AV) maps, etc.), gyro systems (e.g., IMU (Inertial Measurement Unit), INS (Inertial Navigation System), etc.), AI (Artificial Intelligence) chips, and AI processors, as well as one or more ECUs that control these devices. In addition, the driving assistance system unit 2030 transmits and receives various information via the communication module 2013 to realize the driving assistance function or the autonomous driving function.

[0359] The communication module 2013 can communicate, via the communication port, with the microprocessor 2031 and the components of the vehicle 2001. For example, the communication module 2013 transmits and receives data, via the communication port 2033, to and from the drive unit 2002, steering unit 2003, accelerator pedal 2004, brake pedal 2005, shift lever 2006, front wheels 2007, rear wheels 2008, axle 2009, microprocessor 2031 and memory (ROM, RAM) 2032 in the electronic control unit 2010, and sensors 2021 to 2029, which are provided in the vehicle 2001.

[0360] The communication module 2013 is a communication device that can be controlled by the microprocessor 2031 of the electronic control unit 2010 and can communicate with an external device. For example, it transmits and receives various information to and from the external device via wireless communication. The communication module 2013 may be located either inside or outside the electronic control unit 2010. The external device may be, for example, a base station, a mobile station, or the like.

[0361] The communication module 2013 may transmit at least one of signals from the above-mentioned various sensors 2021 to 2029 input to the electronic control unit 2010, information obtained based on the signals, and information based on input from the outside (user) obtained via the information service unit 2012 to an external device via wireless communication. The electronic control unit 2010, the various sensors 2021 to 2029, the information service unit 2012, etc. may be referred to as input units that accept input. For example, the PUSCH transmitted by the communication module 2013 may include information based on the above-mentioned input.

[0362] The communication module 2013 receives various information (traffic information, traffic signal information, vehicle-to-vehicle information, etc.) transmitted from external devices and displays it on an information service unit 2012 provided in the vehicle 2001. The information service unit 2012 may be called an output unit that outputs information (for example, outputs information to a device such as a display or speaker based on the PDSCH (or data / information decoded from the PDSCH) received by the communication module 2013). The communication module 2013 also stores the various information received from external devices in a memory 2032 that can be used by the microprocessor 2031. Based on the information stored in the memory 2032, the microprocessor 2031 may control the drive unit 2002, steering unit 2003, accelerator pedal 2004, brake pedal 2005, shift lever 2006, front wheels 2007, rear wheels 2008, axles 2009, sensors 2021 to 2029, and the like provided in the vehicle 2001.

[0363] <Meaning and Interpretation of Terms> As used in this disclosure, the terms "determining" and "determining" may encompass a wide variety of actions. "Determining" and "determining" may include, for example, judging, calculating, computing, processing, deriving, investigating, looking up, searching, inquiring (e.g., searching a table, database, or other data structure), ascertaining something that is considered to be a "judging" or "determining," and the like. "Determining" and "determining" may also include receiving (e.g., receiving information), transmitting (e.g., sending information), input, output, accessing (e.g., accessing data in memory), and the like that are considered to be a "judging" or "determining." Furthermore, "judgment" and "decision" can include regarding resolving, selecting, choosing, establishing, comparing, etc. as having been "judged" or "decided." In other words, "judgment" and "decision" can include regarding some action as having been "judged" or "decided." Furthermore, "judgment (decision)" can be interpreted as "assuming," "expecting," "considering," etc.

[0364] The terms "connected," "coupled," or any variation thereof, refer to any direct or indirect connection 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 elements may be physical, logical, or a combination thereof. For example, "connected" may be read as "access." As used in this disclosure, two elements may be considered to be "connected" or "coupled" to each other using one or more wires, cables, and / or printed electrical connections, as well as electromagnetic energy having wavelengths in the radio frequency range, microwave range, and optical (both visible and invisible) range, as some non-limiting and non-exhaustive examples.

[0365] <Reference Signal> A reference signal can also be abbreviated as RS (Reference Signal), and may also be called a pilot depending on the applicable standard.

[0366] <Meaning of "based on"> As used in this disclosure, the phrase "based on" does not mean "based only on," unless expressly stated otherwise. In other words, the phrase "based on" means both "based only on" and "based at least on."

[0367] "First," "Second" Any reference to an element using designations such as "first," "second," etc., used in this disclosure does not generally limit the quantity or order of those elements. These designations may be used in this disclosure as a convenient method of distinguishing between two or more elements. Thus, a reference to a first and a second element does not imply that only two elements may be employed or that the first element must precede the second element in some way.

[0368] <Means> The "means" in the configuration of each device above may be replaced with "section," "circuit," "device," etc.

[0369] Open Format: When the terms "include," "including," and variations thereof are used in this disclosure, these terms are intended to be inclusive, similar to the term "comprising." Furthermore, when the term "or" is used in this disclosure, it is not intended to be an exclusive or.

[0370] <Time Units such as TTI, Frequency Units such as RB, and Radio Frame Configuration> A radio frame may be composed of one or more frames in the time domain. Each of the one or more frames in the time domain may be called a subframe. A subframe may further be composed of one or more slots in the time domain. A subframe may have a fixed time length (e.g., 1 ms) that is independent of numerology.

[0371] Numerology may be a communication parameter that applies to the transmission and / or reception of a signal or channel, and may indicate, for example, at least one of subcarrier spacing (SCS), bandwidth, symbol length, cyclic prefix length, transmission time interval (TTI), number of symbols per TTI, radio frame structure, specific filtering operations performed by the transceiver in the frequency domain, and specific windowing operations performed by the transceiver in the time domain.

[0372] A slot may be composed of one or more symbols in the time domain (such as an Orthogonal Frequency Division Multiplexing (OFDM) symbol or a Single Carrier Frequency Division Multiple Access (SC-FDMA) symbol). A slot may be a time unit based on numerology.

[0373] A slot may include multiple minislots. Each minislot may consist of one or multiple symbols in the time domain. A minislot may also be called a subslot. A minislot may consist of fewer symbols than a slot. A PDSCH (or PUSCH) transmitted in a time unit larger than a minislot may be called PDSCH (or PUSCH) mapping type A. A PDSCH (or PUSCH) transmitted using a minislot may be called PDSCH (or PUSCH) mapping type B.

[0374] The radio frame, subframe, slot, minislot, and symbol all represent time units for transmitting signals, and may be referred to by other names corresponding to the radio frame, subframe, slot, minislot, and symbol.

[0375] For example, one subframe may be called a transmission time interval (TTI), multiple consecutive subframes may be called a TTI, or one slot or one minislot may be called a TTI. That is, at least one of the subframe and the TTI may be a subframe (1 ms) in existing LTE, a period shorter than 1 ms (for example, 1-13 symbols), or a period longer than 1 ms. Note that the unit representing the TTI may be called a slot, minislot, etc. instead of a subframe.

[0376] Here, TTI refers to, for example, the smallest time unit for scheduling in wireless communication. For example, in an LTE system, a base station performs scheduling to allocate radio resources (such as frequency bandwidth and transmission power that can be used by each user terminal) to each user terminal in TTI units. Note that the definition of TTI is not limited to this.

[0377] The TTI may be a transmission time unit for a channel-encoded data packet (transport block), a code block, a code word, etc., or may be a processing unit for scheduling, link adaptation, etc. When a TTI is given, the time interval (e.g., the number of symbols) to which a transport block, a code block, a code word, etc. is actually mapped may be shorter than the TTI.

[0378] When one slot or one minislot is called a TTI, one or more TTIs (i.e., one or more slots or one or more minislots) may be the minimum time unit for scheduling. Also, the number of slots (minislots) constituting the minimum time unit for scheduling may be controlled.

[0379] A TTI having a time length of 1 ms may be called a regular TTI (TTI in LTE Rel. 8-12), normal TTI, long TTI, regular subframe, normal subframe, long subframe, slot, etc. A TTI shorter than a regular TTI may be called a shortened TTI, short TTI, partial or fractional TTI, shortened subframe, short subframe, minislot, subslot, slot, etc.

[0380] In addition, a long TTI (e.g., a normal TTI, a subframe, etc.) may be interpreted as a TTI having a time length of more than 1 ms, and a short TTI (e.g., a shortened TTI, etc.) may be interpreted as a TTI having a TTI length shorter than the TTI length of a long TTI and greater than or equal to 1 ms.

[0381] A resource block (RB) is a resource allocation unit in the time domain and the frequency domain, and may include one or more consecutive subcarriers in the frequency domain. The number of subcarriers included in an RB may be the same regardless of numerology, for example, 12. The number of subcarriers included in an RB may be determined based on numerology.

[0382] The time domain of an RB may include one or more symbols and may have a length of one slot, one minislot, one subframe, or one TTI. One TTI, one subframe, etc. may each be composed of one or more resource blocks.

[0383] Note that one or more RBs may also be called a physical resource block (PRB), a sub-carrier group (SCG), a resource element group (REG), a PRB pair, an RB pair, etc.

[0384] Furthermore, a resource block may be composed of one or more resource elements (REs). For example, one RE may be a radio resource region of one subcarrier and one symbol.

[0385] A Bandwidth Part (BWP) (which may also be referred to as a fractional bandwidth) may represent a subset of contiguous common resource blocks (RBs) for a given numerology on a given carrier, where the common RBs may be identified by their index relative to a Common Reference Point of the carrier. PRBs may be defined in a BWP and numbered within the BWP.

[0386] The BWP may include a BWP for UL (UL BWP) and a BWP for DL ​​(DL BWP). One or more BWPs may be configured for a UE within one carrier.

[0387] At least one of the configured BWPs may be active, and the UE may not expect to transmit or receive a given signal / channel outside the active BWP. Note that the terms "cell," "carrier," etc. in this disclosure may be read as "BWP."

[0388] The above-described structures of radio frames, subframes, slots, minislots, symbols, etc. are merely examples, and various changes may be made to the number of subframes included in a radio frame, the number of slots per subframe or radio frame, the number of minislots included in a slot, the number of symbols and RBs included in a slot or minislot, the number of subcarriers included in an RB, the number of symbols in a TTI, the symbol length, the cyclic prefix (CP) length, etc.

[0389] <Maximum Transmit Power> The "maximum transmit power" in the present disclosure may refer to the maximum value of transmit power, the nominal UE maximum transmit power, or the rated UE maximum transmit power.

[0390] Articles In this disclosure, where articles are added by translation, such as a, an, and the in English, the disclosure may include that the nouns following these articles are in the plural form.

[0391] <"Different"> In the present disclosure, the term "A and B are different" may mean "A and B are different from each other." Note that the term may also mean "A and B are each different from C." Terms such as "separate" and "coupled" may also be interpreted in the same way as "different."

[0392] One aspect of the present disclosure is useful in wireless communication systems.

[0393] 10 Base station 20 Terminal 101, 202 Transmitter 102, 201 Receiver 103, 203 Controller

Claims

1. A control unit that determines uplink control information relating to unused transmission opportunities supported only on the license band, A transmitting unit that transmits the aforementioned uplink control information, A terminal equipped with the following features.

2. The uplink control information is not supported in the unlicensed band. The terminal according to claim 1.

3. The license band is a frequency that is not shared. The terminal according to claim 1.

4. The terminal is Determine uplink control information regarding unused transmission opportunities supported only on licensed bands. The above-mentioned uplink control information is transmitted. Wireless communication method.

5. A terminal that determines uplink control information relating to unused transmission opportunities supported only on licensed bands and transmits the uplink control information, A base station that receives the aforementioned uplink control information, A wireless communication system equipped with [the following features].