WO2023112290A1

WO2023112290A1 - Terminal and communication method

Info

Publication number: WO2023112290A1
Application number: PCT/JP2021/046649
Authority: WO
Inventors: 優元 ▲高▼橋; 聡永田; チーピンピ; ジンワン; ランチン
Original assignee: 株式会社Ｎｔｔドコモ
Priority date: 2021-12-16
Filing date: 2021-12-16
Publication date: 2023-06-22

Abstract

This terminal comprises: a control unit that controls the transmission of a confirmation response on the basis of at least one permitted matter among a retransmission method for changing cells and retransmitting a signal, and utilizing a confirmation response format including a confirmation response for each cell; and a transmission unit that transmits the confirmation response according to the control of the control unit.

Description

Terminal and communication method

The present disclosure relates to terminals and communication methods.

In the Universal Mobile Telecommunication System (UMTS) network, Long Term Evolution (LTE) was specified with the aim of achieving even higher data rates and lower delays. In addition, a successor system to LTE is being considered for the purpose of further broadening and speeding up LTE. Successor systems to LTE include, for example, LTE-Advanced (LTE-A), Future Radio Access (FRA), 5th generation mobile communication system (5G), 5G plus (5G+), Radio Access Technology (New-RAT), New There is a system called Radio (NR).

For example, in NR, extension of the feedback function and/or retransmission function between terminals and base stations is under consideration (for example, Non-Patent Document 1).

However, there is room for further study on methods for reducing delays in communication between terminals and base stations.

One aspect of the present disclosure is to provide a terminal and communication method capable of reducing delay in communication between the terminal and the base station.

A terminal according to an aspect of the present disclosure is based on at least one of a retransmission scheme for switching cells and retransmitting a signal, and use of an acknowledgment format including an acknowledgment in each of the cells. a control unit for controlling transmission of an acknowledgment; and a transmission unit for transmitting the acknowledgment under the control of the control unit.

A communication method according to an aspect of the present disclosure is a retransmission scheme in which a terminal switches cells and retransmits a signal, and the use of an acknowledgment format including an acknowledgment in each of the cells. Based on at least one of controlling transmission of an acknowledgment and transmitting said acknowledgment.

It is a figure which shows the example of dual connectivity. FIG. 3 illustrates an example of PUCCH cell switching; FIG. 10 is a diagram illustrating an example of cross-carrier PDSCH retransmissions; FIG. 10 illustrates an example of cross-carrier PUSCH retransmission; FIG. 2 is a diagram illustrating an example of a HARQ process pool framework; It is a figure which shows an example of two proposals in one Embodiment. FIG. 10 is a diagram showing an example of Type 3 HARQ-ACK CB; FIG. 10 is a diagram showing an example of Type 3 HARQ-ACK CB; FIG. 4 is a diagram illustrating an example of DL operation of a terminal regarding collision of HARQ processes; FIG. 4 is a diagram illustrating an example of UL operation of a terminal regarding collision of HARQ processes; FIG. 4 is a diagram illustrating an example of DL operation of a terminal in a HARQ process-sharing cell group; FIG. 3 is a diagram illustrating an example of UL operation of a terminal in a HARQ process-sharing cell group; FIG. 4 is a diagram showing a first example of Type 3 HARQ-ACK CB in one embodiment; FIG. 10 is a diagram showing a second example of Type 3 HARQ-ACK CB in one embodiment; FIG. 10 is a diagram illustrating DL operation example 1 of a terminal when HARQ processes/entities are separated for each cell; FIG. 10 is a diagram illustrating DL operation example 2 of a terminal when HARQ processes/entities are separated for each cell; FIG. 4 is a diagram illustrating an example 1 of UL operation of a terminal when HARQ processes/entities are separated for each cell; 1 is a block diagram showing an example of the configuration of a base station according to this embodiment; FIG. FIG. 2 is a block diagram showing an example of a configuration of a terminal according to this embodiment; FIG. It is a figure which shows an example of the hardware configuration of the base station and terminal which concern on this Embodiment. It is a figure which shows the structural example of a vehicle.

(one embodiment)
An embodiment according to one aspect of the present disclosure will be described below with reference to the drawings.

In NR, in Release 17 (hereinafter referred to as Rel-17), extended reality (XR) such as virtual reality (VR), augmented reality (AR), mixed reality (MX), etc. was studied, and the XR scenario , requirements, Key Performance Indicators (KPIs) and evaluation methods are being considered. The target requirements of XR are to consider capacity, latency (delay), mobility, and energy saving aspects.

Also, in Rel-18, consideration is being given to the expansion of XR.

For example, Rel-18 is considering mechanisms for more effective resource allocation and/or scheduling for services using XR. As an example of such a mechanism, an extension to dynamic grants is being considered. Extensions to dynamic grants illustratively include Hybrid Automatic Repeat request-Acknowledgement (HARQ-ACK) feedback and/or retransmission extensions. HARQ-ACK is an example of information related to acknowledgment (eg, acknowledgment) for data received by the terminal. Note that HARQ-ACK feedback may also be referred to as HARQ feedback.

Here, we describe how to reduce latency, which is an important KPI for Ultra-Reliable and Low Latency Communications (URLLC) and/or XR services.

For example, in Rel-17, the introduction of PUCCH (Physical Uplink Control Channel) cell switching is being considered to reduce HARQ-ACK feedback delays. Note that PUCCH cell switching may also be referred to as PUCCH carrier switching. PUCCH cell switching may also be called by other names such as cell switching for control information transmission.

PUCCH cell switching is a technology applied when a base station communicates through multiple cells. Dual connectivity, which is an example of communication via multiple cells, and PUCCH cell switching will be described below.

<Dual Connectivity>
FIG. 1 is a diagram illustrating an example of dual connectivity (DC). In the example of FIG. 1, base station 10-1 may be a Master Node (MN). Base station 10-2 may be a secondary node (SN). As shown in the example of FIG. 1, DC bundles carriers between different base stations.

In the example of FIG. 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, terminal 20 has established an RRC connection with base station 10-1.

In the case of DC, since there may be a communication delay between the base station 10-1 and the base station 10-2, the uplink control information (for example, UCI) received by the Pcell of the base station 10-1 is transferred to the backhaul Notify the base station 10-2 via a link (for example, a wired or wireless link connecting the base station 10-1 and the base station 10-2) and reflect it in the scheduling of Scell under the base station 10-2. It is difficult to let Therefore, in the DC, in addition to the Pcell of the base station 10-1, one carrier under the control of the base station 10-2 may be set as the Primary Scell (PScell), and PUCCH transmission may be supported by the PScell. In this case, terminal 20 transmits UCI to base station 10-2 via PScell.

In the example of FIG. 1, the terminal 20 sets Scell in addition to Pcell for the base station 10-1. Also, the terminal 20 sets Scell in addition to PScell for the base station 10-2. The terminal 20 transmits the UCI of each carrier under the control of the base station 10-1 using the PUCCH of the Pcell. Also, the terminal 20 transmits the UCI of each carrier under the control of the base station 10-2 on PUCCH of the PScell. In the example of FIG. 1, a cell group (CG) under the base station 10-1 may be called a Master Cell-Group (MCG). A cell group under the base station 10-2 may be called a Secondary Cell-Group (SCG).

When DC is performed, terminal 20 may transmit PUCCH via Pcell, PScell, and/or PUCCH-Scell. Generally, it is not assumed that terminal 20 transmits PUCCH via Scell other than Pcell, PScell, and PUCCH-Scell.

　Transmission of PUCCH corresponds to transmission of a signal mapped to the radio resource configured for PUCCH. Hereinafter, other channels may also be described in the same manner as PUCCH transmission.

<PUCCH cell switching>
PUCCH cell switching is being considered as a method to reduce HARQ-ACK feedback latency in Time Division Duplex (TDD) schemes.

FIG. 2 is a diagram showing an example of PUCCH cell switching. In the example of FIG. 2, the base station and the terminal are communicating via cell 1 and cell 2. FIG. In the example of FIG. 2, cell 1 is Pcell and cell 2 is Scell. The example of FIG. 2 also shows downlink (DL) slots and uplink (UL) slots in each cell.

In the example of FIG. 2, the terminal receives data (receives Physical Downlink shared Channel (PDSCH)) at the timing of S101. The terminal attempts to transmit HARQ-ACK for the data received in S101 at the timing of S102, but at the timing of S102, the cell 1 slot is a downlink (DL) slot. Therefore, when the terminal transmits HARQ-ACK in cell1, the transmission of HARQ-ACK is suspended until the transmission timing of PUCCH in the uplink (UL) slot (for example, the timing of S103 in FIG. 2). HARQ-ACK transmission latency increases. Note that the PUCCH transmission timing in the uplink (UL) slot may be referred to as a PUCCH transmission opportunity.

In the example of FIG. 2, the slot of cell 2 is the UL slot at the timing of S102. In the example of FIG. 2, if the terminal can transmit HARQ-ACK for the data received in S101 at the PUCCH transmission opportunity of cell 2 at the timing of S102, the latency of HARQ-ACK transmission can be reduced. URLLC particularly requires low delay in the radio section. Therefore, in 3GPP, as an extension of the URLLC technique, PUCCH cell switching, in which a terminal switches the carrier for PUCCH transmission, is under consideration.

In the following embodiments, the "same timing" may be completely the same timing, or may be a time resource (for example, one or more symbols (a resource in time units shorter than a symbol) may be the same or overlap.

PUCCH cell switching means that when the terminal attempts to transmit PUCCH at a specific transmission timing of Pcell (may be PScell or PUCCH-Scell), Pcell (may be PScell or PUCCH-Scell ) is a DL slot, the terminal selects a cell that transmits PUCCH from Pcell (may be PScell or PUCCH-Scell) from the specific transmission timing Any Scell out of one or more Scells whose timing slot is the UL slot (in the case of PScells, Scells other than PScells, and in the case of PUCCH-Scells, other than PUCCH-Scells Scell).

It should be noted that, in the embodiment of the present disclosure, the unit of transmission timing is not limited to slots. For example, the transmission timing may be timing in units of subframes or may be timing in units of symbols. Cell switching may also be referred to as carrier switching, cell switching, or carrier switching.

As described above, in PUCCH cell switching, for example, HARQ-ACK transmission delay can be reduced by switching the cell in which HARQ-ACK is transmitted. Based on the same motivation as PUCCH cell switching, a retransmission method called cross-carrier PDSCH/PUSCH retransmission is being considered. PDSCH/PUSCH is an abbreviation for Physical Downlink Shared Channel and/or Physical Uplink Shared Channel. PDSCH is an example of a downlink (DL) data channel, and PUSCH is an example of an uplink (UL) data channel.

In the following description, cross-carrier PDSCH/PUSCH retransmission includes cross-carrier PDSCH retransmission and cross-carrier PUSCH retransmission. Cross-carrier PDSCH/PUSCH retransmission may be a retransmission method applied to both PDSCH and PUSCH, or may be a retransmission method applied to either PDSCH or PUSCH.

Also, cross-carrier PDSCH/PUSCH retransmission may be replaced with names such as cross-carrier retransmission, cross-CC retransmission, and carrier switching. Also, expressions such as carrier, CC, and cell may be interchanged.

<Cross-carrier PDSCH/PUSCH retransmission>
In the current mechanism (regulations for processing methods or processing procedures), PDSCH/PUSCH initial transmission and retransmission (re-transmission or retransmission) are performed in the same serving cell. need to be This mechanism causes a large delay in retransmitting data in TDD cells.

In order to reduce the delay in such retransmission, for example, Rel-18 is studying a retransmission method called cross-carrier PDSCH/PUSCH retransmission. Cross-carrier PDSCH/PUSCH retransmission is being considered under the same motivation as PUCCH cell switching described above.

FIG. 3A is a diagram showing an example of cross-carrier PDSCH retransmission. FIG. 3B is a diagram illustrating an example of cross-carrier PUSCH retransmissions. FIG. 3A and FIG. 3B show frame configurations defined in each of two CCs (component carriers) CC0 and CC1. Note that this frame configuration may be set by the UL/DL configuration, for example. In FIGS. 3A and 3B, "D" indicates a DL frame and "U" indicates a UL frame.

In the example of FIG. 3A, in frame #0, which is the DL frame, the terminal receives the initial transmission of PDSCH (“initial PDSCH” in FIG. 3A), and the NACK for the initial transmission of PDSCH is frame #2, which is the UL frame. , is transmitted from the terminal to the base station.

In the case of the current mechanism, initial transmission and retransmission are performed in the same serving cell as each other, so the earliest timing at which retransmission for NACK is performed (“Earliest re-tx PDSCH from CC0 without carrier switching for PDSCH” in FIG. 3A). is DL frame #8 of CC0.

On the other hand, when cross-carrier PDSCH retransmission is performed, as shown in FIG. 3A, the earliest timing at which retransmission for NACK is performed (“Earliest re-tx PDSCH from CC1 if supporting carrier switching for PDSCH” in FIG. 3A) is , CC1 DL frame #3.

In the example of FIG. 3B, the initial transmission of PUSCH ("initial PUSCH" in FIG. 3B) is performed in frame #0, which is the UL frame.

In the case of the current mechanism, since initial transmission and retransmission are performed in the same serving cell as each other, the earliest timing at which retransmission is performed (“Earliest re-tx PUSCH from CC0 without carrier switching for PUSCH” in FIG. 3B) is It is done in UL frame #8 of CC0.

On the other hand, when cross-carrier PUSCH retransmission is performed, as shown in FIG. 3B, the earliest timing at which retransmission is performed ("Earliest re-tx PUSCH from CC1 if supporting carrier switching for PUSCH" in FIG. 3B) is CC1 UL frame #3.

As shown in FIGS. 3A, 3B, when cross-carrier PDSCH/PUSCH retransmissions are applied (or supported, enabled), initial transmissions and retransmissions are performed in different serving cells. Since it may be performed, the timing of retransmission can be appropriately set, and the delay caused in retransmission can be reduced. For example, the application of cross-carrier PDSCH/PUSCH retransmission can reduce delay more effectively for TDD carrier aggregation (CA) with different UL/DL configuration scenarios. As such, improved reliability and efficiency of the system are obtained.

There is room for further study on the relationship between cross-carrier PDSCH/PUSCH retransmission and HARQ process control as described above. For example, the HARQ process pool framework for cross-carrier PDSCH/PUSCH retransmissions is open for consideration. A HARQ process pool is, for example, a set having one or more HARQ process numbers (HARQ process numbers (HPN)).

Figure 4 is a diagram showing an example of the HARQ process pool framework. FIG. 4 shows HARQ process pools set for each of three cells, cell #0, cell #1, and cell #2. In Figure 4, a HARQ process pool with HPN of 0-15 is set for cell #0, a HARQ process pool with HPN of 0-8 is set for cell #1, and a HARQ process pool with HPN of 0-8 is set for cell #2. For that, a HARQ process pool with HPN of 0-15 is configured. As shown in FIG. 4, HPNs are set separately for each of the three cells. In this case, HARQ processes/entities are distinct for each cell.

The HARQ process pool shown in FIG. 4 is an example, and the present disclosure is not limited to this. For example, the number of HPNs in each cell is not limited to the example shown in FIG.

For example, in the current mechanism where initial transmission and retransmission are performed in the same serving cell as each other, a HARQ process pool framework as shown in FIG. be.

On the other hand, in cross-carrier PDSCH/PUSCH retransmission, there is room for discussion as to what HARQ process pool framework is applied. For example, for cross-carrier PDSCH/PUSCH retransmissions, whether the HARQ process pool framework as shown in FIG. 4 is applied and/or whether HARQ processes/entities are differentiated in each cell. There is room for consideration as to whether

Therefore, in the present embodiment, the following two proposals (proposals A and proposal B) will be explained.
Proposal A: HARQ processes/entities are shared within a group of cells.
Proposal B: HARQ processes/entities are different (distinct or isolated) per cell.

In other words, proposal A is equivalent to supporting sharing of HARQ processes/entities within a group of cells. Supporting HARQ process/entity sharing within a group of cells may also be referred to as supporting HARQ process/entity sharing. Also, supported may be replaced by other expressions such as enabled, activated, applied, instructed, and the like. Also, the HARQ process/entity may be abbreviated as HARQ process or HARQ entity.

It should be noted that hereinafter, a group of cells in which HARQ processes/entities are shared may be referred to as HARQ process/entity sharing cell group. Also, HARQ process/entity shared cell group may be replaced by other notations such as cell group, shared cell group, and HARQ process/entity shared group, HARQ process shared cell group.

FIG. 5 is a diagram showing an example of two proposals in this embodiment. FIG. 5 shows an example of HPNs set in three cells, cell #0 to cell #2, for Proposal A and Proposal B, respectively.

In Proposal A of FIG. 5, HARQ processes/entities are shared within a group containing 3 cells, and HPNs from 0 to 40 are set for the group containing 3 cells. In the case of Proposal A in FIG. 5, the group of cells including cell #0 to cell #2 corresponds to the HARQ process/entity sharing cell group.

In Proposal B of Figure 5, the HARQ processes/entities are different for each of the three cells, so HPNs from 0 to 15 are set for cell #0, and HPNs from 0 to 8 are set for cell #1. is set and an HPN from 0 to 15 is set for cell #2.

In the example of Figure 5, in the case of Proposal A, the HARQ process/entity is shared, so for example, the HARQ process of HPN#0 in cell #0 and the HARQ process of HPN#0 in cell #1 are the same HARQ process. On the other hand, in the case of Proposal B, for example, the HPN#0 HARQ process in cell #0 and the HPN#0 HARQ process in cell #1 are different HARQ processes.

Note that in Proposal A, for PDSCH/PUSCH transmitted in the first cell, retransmissions may be scheduled in any cell within the same cell group for HARQ process/entity sharing.

For example, if the new data indicator (NDI) indicates that the scheduled PDSCH/PUSCH is a retransmission, the retransmission has the same HPN in a cell within the same HARQ process/entity shared cell group. , are retransmissions for the first PDSCH/PUSCH.

In Proposal A, the following items A-1 to A-5 (hereinafter referred to as Proposals A-1 to A-5) are stipulated in the specifications, for example. Each item will be described later.
A-1: Regarding cell group indication and/or configuration for grouping HARQ processes/entities A-2: HARQ processes within a cell group for grouping HARQ processes/entities Total number A-3: Impact on HPN field in DCI A-4: Impact on HARQ-ACK feedback and/or HARQ-ACK CB generation A-5: Clarification of operation for HARQ process collision transformation

In Proposal B, for PDSCH/PUSCH transmitted in the first cell, retransmission may be scheduled in a cell different from the first cell. Note that in this case, the first cell for retransmission may be indicated explicitly or implicitly.

In Proposal B, the following items B-1 to B-4 are stipulated in the specifications, for example. Each item will be described later.
B-1: Restriction on relationship between initial transmission cell and retransmission cell B-2: Regarding DCI for scheduling cross-CC retransmission B-3: Impact on HARQ-ACK feedback and/or HARQ-ACK CB generation About B-4: Clarification of HARQ process collision behavior

According to proposal A and proposal B, HARQ processes are appropriately set between carriers (also called between cells or between CCs), so even if carriers (also called cells or CCs) are switched in retransmission, , the proper operation of the HARQ process can reduce the delay in communication between the terminal and the base station.

In addition, according to Proposal B, similar to the existing mechanism, HARQ processes / entities are set separately for each cell, so even if cross-carrier PDSCH / PUSCH retransmission is applied, implementation is easy. It can be carried out.

Each proposal will be explained below.

<Proposal A: Proposal A-1>
Proposal A-1 describes cell group indication and configuration for grouping of HARQ processes/entities when HARQ processes/entities are shared within a group of cells. In other words, we describe here the indication of cells included in the same group for HARQ process/entity sharing. Two options are described below.

<Option 1 of Proposal A-1>
A base station configures one or more cell groups for HARQ process/entity sharing.

When a shared cell group is configured, HARQ process/entity sharing is applicable within the same cell group. And for PDSCH/PUSCH transmitted in the first cell, retransmissions may be scheduled in any cell within the same cell group for HARQ process/entity sharing.

In this case, the terminal does not have to assume that a certain cell is configured in multiple HARQ process/entity shared cell groups. In other words, the terminal may assume that a cell is configured in one HARQ process/entity shared cell group. For example, if a certain cell (eg, cell #1) is configured (belongs to) one HARQ process/entity shared cell group #1, cell #1 has a different HARQ than HARQ process/entity shared cell group #1. It is not set (does not belong) to process/entity shared cell group #2.

Also, if a certain cell (eg, cell #1) is not included in the HARQ process/entity sharing cell group, the HARQ process/entity of this cell #1 is not shared with other cells. In other words, PDSCH/PUSCH transmissions in cell #1 are retransmitted in cell #1. Also in other words, retransmissions scheduled in cell #1 are made for the first transmission in cell #1.

<Option 2 of Proposal A-1>
A base station configures multiple cell groups for HARQ process/entity sharing. Then, in Option 2, the activation or deactivation of multiple configured cell groups is indicated. For example, the activation or deactivation instruction may be performed by a MAC (Media Access Control) CE (control element) or may be performed by a DCI.

It should be noted that the number of cell groups to be activated may be one, or two or more. Also, the number of cell groups to be deactivated may be one, or two or more.

For example, if a cell group is activated, HARQ process sharing is applied within the same cell group. And for PDSCH/PUSCH transmitted in the first cell, retransmissions may be scheduled in any cell within the same cell group for HARQ process/entity sharing.

HARQ process sharing is not applied within a cell group unless a cell group is activated. In this case, PDSCH/PUSCH transmissions on a cell (eg, cell #1) are retransmitted on cell #1. That is, in this case, PDSCH/PUSCH transmission in cell #1 is not retransmitted in cells other than cell #1. Also, the retransmission scheduled in cell #1 is for the first transmission in cell #1. That is, retransmissions scheduled in cell #1 are not performed for the first transmission in a cell other than cell #1.

<Variation between Option 1 and Option 2 of Proposal A-1>
Variation 1: HARQ process/entity shared cell groups may be commonly indicated for PDSCH and PUSCH transmissions. Alternatively, HARQ process/entity sharing cell groups may be configured in common for PDSCH and PUSCH transmissions.

For example, if a HARQ process/entity sharing cell group includes cell #1, cell #2, and cell #3, cross-carrier retransmissions within the cell group are possible in both PDSCH scheduling and PUSCH scheduling. . In other words, cell #1, cell #2, and cell #3 are included for both the HARQ process/entity sharing cell group for PDSCH scheduling and the HARQ process/entity sharing cell group for PUSCH scheduling. A group is commonly set.

Variation 2: HARQ process/entity sharing cell groups may be indicated separately for PDSCH transmission and PUSCH transmission. Alternatively, HARQ process/entity sharing cell groups may be configured separately for PDSCH transmission and PUSCH transmission.

For example, in the HARQ process/entity sharing cell group for PDSCH scheduling, a group including cell #1, cell #2, and cell #3 is set, and in the HARQ process/entity sharing cell group for PUSCH scheduling, A group including cell #2 and cell #3 may be configured.

In variation 2, a HARQ process/entity sharing cell group for PDSCH scheduling and a HARQ process/entity sharing cell group for PUSCH scheduling are set individually, but these cell groups may match. and may not match.

<Supplement to Proposal A-1>
Cells within the same HARQ process/entity sharing group may or may not be restricted. In other words, cells meeting certain restrictions may be included in the same HARQ process/entity sharing group, and cells not meeting the restrictions may not be included in the same HARQ process/entity sharing group. Note that the expression that a limitation is provided may be replaced with expressions such as a limitation being specified, a limitation being indicated, a limitation being set, and a limitation being applied. For example, a base station may configure HARQ process/entity sharing groups based on established restrictions. Also, for this restriction, any of the following Alteration (Alt) may be employed.

(Alt.1)
No restrictions are placed on cells within a HARQ process/entity sharing group. If no restrictions are placed, the cells included in the HARQ process/entity sharing group can be any cell.

(Alt.2)
Restrictions based on at least one of frequency, FR range, band, and PUCCH cell group may be provided.

For example, cells within the same HARQ process/entity sharing group may be restricted to the same FR range or may be restricted to different FR ranges. Alternatively, cells within the same HARQ process/entity sharing group may be restricted to within any one of FR1, FR2-1 and FR2-2. For example, it may not be allowed for cells in FR1 and cells in FR2-1 to be included in the same HARQ process/entity sharing group.

For example, cells within the same HARQ process/entity sharing group may be restricted to be intra-band CCs or inter-band CCs. CCs in different inter-bands may not be allowed to be included in the same HARQ process/entity sharing group if there is a restriction that cells in the same HARQ process/entity sharing group are intra-band CCs. good.

For example, cells of the same HARQ process/entity sharing group may be restricted to be included in the same PUCCH cell group, or cells of the same HARQ process/entity sharing group may be restricted to be included in different PUCCH cell groups. may be provided.

for example. Cells within the same HARQ process/entity sharing group may be restricted to be within the same MCG, and cells within the same HARQ process/entity sharing group may be restricted to be within the SCG.

(Alt.3)
Restrictions on numerology may be provided.

For example, a restriction may be placed that cells within the same HARQ process/entity sharing group have the same reference SCS (subcarrier spacing) configuration, or cells within the same HARQ process/entity sharing group have different reference SCS configurations. A limit may be set.

For example, a restriction may be placed that the SCS of the active DL BWP (bandwidth part) of cells within the same HARQ process/entity sharing group is the same, or the active DL of cells within the same HARQ process/entity sharing group A restriction may be provided that the SCS of the BWP is different. Also, for example, a restriction may be placed that the SCSs of the active UL BWPs of cells within the same HARQ process/entity sharing group are the same, or that the SCSs of the active UL BWPs of cells within the same HARQ process/entity sharing group A restriction may be placed that the SCS is different.

For example, there may be a restriction that the SCS of active DL BWPs of cells within the same HARQ process/entity sharing group is equal to a certain value, or that the SCS of active UL BWPs of cells within the same HARQ process/entity sharing group A restriction may be placed that the SCS is equal to a certain value.

Note that the restriction that the SCS of the DL BWP (or the SCS of the UL BWP) is equal to a particular value is the restriction that the SCS of the DL BWP (or the SCS of the UL BWP) is greater than a particular value, or the restriction that the DL BWP SCS is greater than a particular value. may be replaced by a restriction that the SCS of UL (or SCS of UL BWP) be less than a certain value. Alternatively, the restriction that the DL BWP SCS (or UL BWP SCS) is within a particular may be replaced by a restriction that the SCS of the UL (or the SCS of the UL BWP) be outside the specified range.

(Alt.4)
Limitations on bandwidth may be provided.

For example, there may be a restriction that the bandwidth of active DL BWPs of cells within the same HARQ process/entity sharing group be the same, or the bandwidth of active DL BWPs of cells within the same HARQ process/entity sharing group. may be different. Also, for example, there may be a restriction that the bandwidths of the active UL BWPs of cells within the same HARQ process/entity sharing group are the same, or the bandwidth of the active UL BWPs of cells within the same HARQ process/entity sharing group Different bandwidth limits may be provided.

Alternatively, there may be a restriction that the bandwidth of the active DL BWP of cells within the same HARQ process/entity sharing group is equal to a certain value, e.g., the active UL of cells within the same HARQ process/entity sharing group A limit may be placed that the bandwidth of the BWP is equal to a certain value. Note that the restriction that the DL BWP bandwidth (or UL BWP bandwidth) is equal to a certain value is the restriction that the DL BWP bandwidth (or UL BWP bandwidth) is less than a certain value, or , may be replaced by a restriction that the DL BWP bandwidth (or the UL BWP bandwidth) is greater than a certain value. or the restriction that the DL BWP bandwidth (or the UL BWP bandwidth) is equal to a certain value is the restriction that the DL BWP bandwidth (or the UL BWP bandwidth) is within a certain range, or , may be replaced by a restriction that the DL BWP bandwidth (or the UL BWP bandwidth) is outside a certain range.

(Alt.5)
Restrictions on CBG configuration (Code block group configuration) may be provided.

For example, a restriction may be placed that the CBG transmission configuration is not provided to any cell within the same HARQ process/entity sharing group. Alternatively, there may be a restriction that the CBG transmission configuration is provided to each cell within the same HARQ process/entity sharing group.

(Alt.6)
Restrictions may be placed on the configuration of multi-PDSCH/PUSCH scheduling.

For example, there may be a restriction that multi-PDSCH/PUSCH scheduling is not configured in any cell of the HARQ process/entity sharing group. Alternatively, there may be a restriction that multiple PDSCH/PUSCH scheduling is configured for all cells of a HARQ process/entity sharing group. Alternatively, there may be a restriction that the maximum number of PDSCHs/PUSCHs scheduled in each cell of a HARQ process/entity sharing group is the same across cells.

(Alt.7)
Restrictions on multi-transmission reception point (MTRP) configurations may be provided.

For example, each cell in a HARQ process/entity sharing group contains both a first CORESET (control resource set) with a coresetPoolIndex value of '0' and a second CORESET with a coresetPoolIndex value of '1'. may For example, each cell of the HARQ process/entity sharing group may include only CORESETs with a coresetPoolIndex value of '0', or only CORESETs with no coresetPoolIndex value specified. For example, each cell of a HARQ process/entity sharing group may include only CORESET with a coresetPoolIndex value of '1'.

(Alt.8)
A limit may be placed on the total number of cells in a group.

For example, a restriction may be placed that the number of cells in the same HARQ process sharing group is X or less. Here, X may be defined by specifications or may be set by RRC (radio resource control).

For example, a restriction may be provided that the number of cell groups for shared HARQ entities is Y or less in each of the Master Cell-Group (MCG), Secondary Cell-Group (SCG), and PUCCH cell group. Alternatively, the number of groups for shared HARQ entities may be limited to Y or less per SCG cell group. Alternatively, there may be a restriction that the number of groups for shared HARQ entities is equal to or less than Y per PUCCH cell group. Here, Y may be defined by the specification or set by RRC.

In the above, Proposal A-1 explained the instructions and settings for the HARQ process sharing group. By setting the HARQ process sharing group described in Proposal A-1, for example, the base station can set an appropriate HARQ process sharing group, communication including retransmission under HARQ process sharing can be performed efficiently, and the terminal and the communication delay between the base station can be reduced.

<Proposal A: Proposal A-2>
Proposal A-2 describes the number (eg, total number) of HARQ processes in a HARQ process sharing cell group when HARQ processes/entities are shared within a group of cells.

　The total number of HARQ processes in one HARQ process-sharing cell group is set by RRC. For example, the maximum total number of HARQ processes within one HARQ process-sharing cell group is set.

For the total number to be set (for example, the maximum total number), either of the following two options may be applied.

<Option 1 of Proposal A-2>
A value less than or equal to the sum of the maximum number of HARQ processes for each cell in the HARQ process sharing cell group may be set to the total number of HARQ processes (eg, maximum total number) in the HARQ process sharing cell group.

An example of option 1 in HARQ process-sharing cell group #1 that includes cell #1 and cell #2 will be described. If the maximum number of HARQ processes for cell #1 is '16' and the maximum number of HARQ processes for cell #2 is '32', then the total maximum number of HARQ processes for HARQ process sharing cell group #1 is 16 + 32 = is 48. In the example of Option 1, the total number of HARQ processes in HARQ process-sharing cell group #1 is set to a value of "48" or less.

<Option 2 of Proposal A-2>
A value less than or equal to X*N may be set to the total number of HARQ processes in the HARQ process sharing cell group, where N is the number of cells in the HARQ process sharing cell group. Here, X may be defined by the specification.

For example, X may be defined as the minimum or maximum value among the maximum number of HARQ processes for each cell in the HARQ process sharing cell group.

So far, proposal A-2 has explained the determination of the number of HARQ processes in a HARQ process-sharing cell group when HARQ processes/entities are shared within a group of cells. According to proposal A-2, for example, a base station can set an appropriate number of HARQ processes for a HARQ process sharing cell group, so communication including retransmission based on HARQ process sharing can be performed efficiently. , the communication delay between the terminal and the base station can be reduced.

<Proposal A: Proposal A-3>
Proposal A-3 describes the HPN field in DCIs containing DL grants and/or DCIs containing UL grants. Note that hereinafter, a DCI including a DL grant is referred to as a DL grant DCI, and a DCI including a UL grant is referred to as a UL grant DCI. Note that a DCI that includes a DL grant may be referred to as a DCI that carries a DL grant.

In the following description, the number of HARQ processes configured in each of the configured HARQ process-sharing cell groups and the HARQ processes configured in one or more serving cells that are not included in any of the HARQ process-sharing cell groups is denoted as M. Also, N is the maximum number of HARQ processes configured in one or more serving cells that are not included in any of the HARQ process-sharing cell groups. Clearly, M is greater than or equal to N.

HARQ process sharing cell group #1 including cell #1 and cell #2, HARQ process sharing cell group #2 including cell #3, cell #4 and cell #5, or HARQ process sharing cell group An example of option 2 in cell #6, which does not include

For example, a total of 24 HARQ processes are configured in HARQ process-sharing cell group #1, 32 HARQ processes are configured in HARQ process-sharing cell group #2, and 16 HARQ processes are configured in cell #6. then M=max{24, 32, 16} and N=16.

The field length of the HPN field may be determined by any of Alt 1 to Alt 3 below.

(Alt.1)
The HPN field length of each DL grant DCI format is determined based on M. For example, the HPN field length is _log2M . For example, the HPN field length of DCI format 1_0 (hereinafter referred to as DCI 1_0, other DCI formats are the same), DCI 1_1, and DCI 1_2 may be log2(32)=5 bits.

Also, for example, the HPN field length of each UL grant DCI format is determined based on M. The HPN field length of DCI 0_0, DCI 0_1 and DCI 0_2 may be log2(32) = 5 bits.

(Alt.2)
The HPN field length for non fallback DL grant DCI is determined based on M. Also, the HPN field length of non fallback UL grant DCI is determined based on M. For example, the HPN field length is _log2M .

Also, the HPN field length of the fallback DL grant DCI is determined based on N. Also, the HPN field length of the fallback UL grant DCI is determined based on N. For example, the HPN field length is _log2N .

　The method of determining the HPN field length of the DL grant DCI may be the same as or different from the method of determining the HPN field length of the UL grant.

(Alt.3)
An RRC parameter is set per DCI format to indicate whether the DCI HPN field is M-based or N-based. An example in which the indicated RRC parameter is "Harq-Process-Sharing" will be described below.

For example, for DCI 1_1, the HPN field length may be based on M if the value of 'Harq-Process-Sharing' is set to '1'. In this case, the HPN field length may be based on _log2M . Otherwise, the HPN field length may be based on N, for example, if the value of "Harq-Process-Sharing" is set to something other than "1" (eg, "0"). In this case, the HPN field length may be based on _log2N .

Note that in Alt 2 and Alt 3 above, if a DCI format has an HPN field length based on N and M is greater than N, then either of the following two sub-options apply for that DCI format: may

Sub-option A: DCI format is not used for scheduling PDSCH/PUSCH in cells configured (included) in HARQ process-sharing cell groups. For example, cross-carrier PDSCH/PUSCH retransmissions are not enabled.

Sub-option B: DCI format may schedule PDSCH/PUSCH in cells of HARQ process sharing cell group, but schedule HARQ process with minimum or maximum HPN value N in this HARQ process sharing cell group You can For example, cross-carrier PDSCH/PUSCH retransmissions are enabled.

In the above, Proposal A-3 explained the setting of the HPN field in the DL grant DCI and/or the UL grant DCI. According to proposal A-3, since the size of the HARQ process-sharing DCI format is set appropriately, an increase in DCI size can be suppressed, DCI overhead can be reduced, and communication between the terminal and the base station can be reduced. Delay can be reduced.

<Proposal A: Proposal A-4>
Proposal A-4 describes the relationship between HARQ process sharing in a HARQ process sharing cell group and the type of HARQ-ACK referred to as type 3 HARQ-ACK feedback. First, the type 3 HARQ-ACK feedback CB (Type 3 HARQ-ACK CB (an example of an acknowledgment format)) will be described.

<Type 3 HARQ-ACK CB>
The Rel-16 legacy Type 3 HARQ-ACK CB contains HARQ-ACK information for the configured HARQ processes in all configured serving cells.

Fig. 6 is a diagram showing an example of Type 3 HARQ-ACK CB. As shown in FIG. 6, in Type 3 HARQ-ACK CB, first, HARQ-ACKs for HARQ processes of each CC are arranged in ascending order of HPN (HARQ Process Number). The HARQ-ACKs for the HARQ processes of each CC are then ordered in ascending order of CC number. For example, Type 3 HARQ-ACK CB includes HARQ-ACK information of HARQ process in CC#0 and HARQ-ACK information of HARQ process in CC#1. The HARQ-ACK information of the HARQ process in CC#0 includes the HARQ-ACK information of each HPN in CC#0. Also, the HARQ-ACK information of the HARQ process in CC#1 includes HARQ-ACK information of each HPN in CC#1.

In Rel-17, as an example of extending Type 3 HARQ-ACK, support for Type 3 HARQ-ACK CB with a smaller CB size is being considered.

The size of the Enhanced Type 3 HARQ-ACK Codebook (e-Type 3 HARQ-ACK CB) is smaller than the Type 3 HARQ-ACK CB size specified in Rel-16. The e-Type 3 HARQ-ACK CB size is defined by the RRC configuration. Also, the configuration of the codebook (CB) is based on the HARQ process. For example, the order in the CB follows the HARQ ID and serving cell.

e-Type 3 HARQ-ACK CB is triggered by DCI 1_1 and DCI 1_2. In the following, DCI that triggers e-Type 3 HARQ-ACK CB may be referred to as "e-Type 3 HARQ-ACK CB triggering DCI" or "triggering DCI".

For e-Type 3 HARQ-ACK CB, one or more small CBs are configured in RRC. Triggering DCI indicates a set small CB. Each configured small CB may contain a subset of HARQ processes of the configured CC or a subset of the configured HARQ processes (specific to the CC). Terminal 20 can include a partial subset in e-Type 3 HARQ-ACK CB and transmit it.

An e-Type 3 HARQ-ACK CB with a smaller size may contain HARQ processes for a subset of the configured CCs. Also, the CB of the e-Type 3 HARQ-ACK CB may contain a subset of the configured HARQ processes.

Dynamic selection is supported based on indications in the triggering DCI that trigger one of at least one e-Type 3 HARQ-ACK CB.

For relationships with extended Type 3 HARQ when HARQ processes/entities are shared within a group of cells, either of the following two options may apply.

<Option 1 of Proposal A-4>
The terminal does not assume that the HARQ process shared cell group is configured and the extended Type 3 HARQ-ACK triggering is enabled for any DL grant DCI format at the same time. . In other words, extended Type 3 HARQ triggering is not allowed to be enabled for any DL grant DCI format when HARQ process sharing cell group is configured. Alternatively, if extended Type 3 HARQ triggering is enabled for certain DL grant DCI formats, HARQ process sharing cell groups are not allowed to be configured.

<Option 2 of Proposal A-4>
It is allowed that the HARQ process sharing cell group is configured and the extended Type 3 HARQ trigger is enabled for any DL grant DCI format at the same time.

In generating an extended Type 3 HARQ-ACK CB, HARQ-ACK information (e.g., bits) corresponding to HARQ processes of cells not included in the HARQ process-sharing cell group is replaced with Type 3 HARQ-ACK CB The HARQ-ACK information (eg, bits) corresponding to the HARQ processes of the HARQ process-sharing cell group may be ordered first, and then ordered. This ordered Type 3 HARQ-ACK CB will be explained using FIG.

Fig. 7 is a diagram showing an example of Type 3 HARQ-ACK CB. FIG. 7 shows the arrangement order of HARQ-ACKs included in Type 3 HARQ-ACK CB.

In the example shown in FIG. 7, the HARQ-ACK information ("HARQ-ACK for HARQ processes on CC #0") corresponding to the HARQ process of CC #0 corresponding to the cell not included in the HARQ process sharing cell group is placed first. Next, HARQ-ACK information (“HARQ-ACK for HARQ processes on CC #1”) corresponding to the HARQ process of CC #1 corresponding to the cell not included in the HARQ process shared cell group is arranged. In the example of FIG. 7, the order of cells not included in the HARQ process-sharing cell group is defined by cell identification numbers (#0, #1, etc.). Also, HARQ-ACK bits corresponding to HARQ processes of cells not included in the HARQ process-sharing cell group may include HARQ-ACK information for each HPN in the order of HPN.

After the HARQ-ACK bits corresponding to the HARQ processes corresponding to cells not included in the HARQ process-sharing cell group are placed, the HARQ-ACK bits corresponding to the HARQ processes in HARQ process-sharing cell group #0 ("HARQ-ACK for HARQ processes in HARQ process sharing cell group #0") is placed. Next, HARQ-ACK bits corresponding to HARQ processes in HARQ process sharing cell group #1 (“HARQ-ACK for HARQ processes in HARQ process sharing cell group #1”) are arranged. In the example of FIG. 7, the order between HARQ process-sharing cell groups is defined by group identification numbers (#0, #1, etc.). Also, the HARQ-ACK bits corresponding to the HARQ processes of the HARQ process-sharing cell group may include HARQ-ACK information for each HPN in the order of HPN.

So far, proposal A-4 explained the relationship between HARQ process sharing in HARQ process sharing cell groups and type 3 HARQ-ACK CB. According to proposal A-4, appropriate communication control (retransmission control) is performed depending on whether the HARQ process sharing cell group is set and whether type 3 HARQ-ACK CB is enabled . Then, for example, when a HARQ process-shared cell group is configured and type 3 HARQ-ACK CB is enabled, a type 3 HARQ-ACK CB is generated considering the configured HARQ process-shared cell group, Even if HARQ process sharing cell group setting and type 3 HARQ-ACK CB enabling are executed at the same time, operation error can be avoided.

<Proposal A: Proposal A-5>
Proposal A-5 describes the relationship between HARQ process sharing and HARQ process collision in a HARQ process sharing cell group. First, let's discuss HARQ process collisions.

<HARQ process collision>
Rel-15/16 defines rules for collisions of HARQ processes within one serving cell. For example, in Rel-15/16, according to the rules defined for DL, the terminal transmits another PDSCH for a specific HARQ process until the expected transmission of HARQ-ACK for a specific HARQ process ends. Not expected to receive. This rule will be described with reference to FIG.

FIG. 8 is a diagram showing an example of terminal DL operation regarding HARQ process collision. FIG. 8 shows an example of PDSCH transmission in CC#1 and Pcell (PDSCH reception in the terminal) and HARQ-ACK transmission for the received PDSCH.

In FIG. 8, the terminal receives PDSCH#1 of HPN#0 and PDSCH#2 of HPN#1 on CC#1. The terminal then transmits HARQ-ACKs for the received PDSCHs #1 and #2 in Pcell under timing control based on parameter K1.

Then, in the example of FIG. 8, the HARQ-ACK ("HARQ-ACK for PDSCH#2") for PDSCH#2 of the HARQ process of HPN#1 (an example of a specific HARQ process) is transmitted by Pcell. A case in which PDSCH#3 of a HARQ process (an example of a specific HARQ process) of HPN#1 (an example of a specific HARQ process) is transmitted in CC#1 is shown earlier. As described above, this case is a case that the terminal does not assume and is an error case.

Also, for example, according to the rules specified for UL in Rel-15/16, the terminal does not transmit another PUSCH for a particular HARQ process until the expected transmission of the last PUSCH for that particular HARQ process is completed. We do not assume that PUSCH transmissions are scheduled by DCI (eg, DCI 0_0, 0_1, or 0_2). This rule will be described with reference to FIG.

FIG. 9 is a diagram showing an example of UL operation of a terminal regarding collision of HARQ processes. FIG. 9 shows an example of PDCCH transmission in CC#1 (PDCCH reception in the terminal) and PUSCH transmission based on the received PDCCH.

In FIG. 9, the terminal receives PDCCH#1 on CC#1, and transmits PUSCH#1 of HPN#0 on CC#1 based on control information (for example, DCI) included in PDCCH#1. do. In the case of FIG. 9, the terminal receives PDCCH#2 on CC#1 and transmits PUSCH#2 of HPN#0 based on control information included in PDCCH#2. In this case, before the transmission of PUSCH#1 of the HARQ process of HPN#0 (an example of a specific HARQ process) ends, the terminal transmits PUSCH#1 to the HARQ process of HPN#0 using DCI of PDCCH#2. (another PUSCH for that particular HARQ process) is scheduled. As described above, this case is not assumed by the terminal and is an error case.

Below, an example of terminal operation based on the relationship between HARQ process sharing in a HARQ process sharing cell group and the above-mentioned HARQ process collision in Proposal A-5 will be described for each of DL and UL.

<Proposal A-5: Example of terminal operation in DL>
The terminal behavior in DL in the light of HARQ process collisions is described when HARQ processes/entities are shared within a group of cells. If HARQ processes/entities are shared within a group of cells, the terminal may wait until the expected transmission of HARQ-ACKs for the first PDSCH of a particular HARQ process in the first serving cell is terminated for the second HARQ-ACK. may not be expected to receive the second PDSCH for that particular HARQ process in that serving cell. Note that the first serving cell and the second serving cell are included in the same HARQ process sharing cell group.

In other words, the terminal, after completing the assumed transmission of HARQ-ACK for the first PDSCH of a particular HARQ process in the first serving cell, may transmit the second HARQ process in the second serving cell. PDSCHs may be assumed to be received.

The operation of this terminal will be described below using FIG.

FIG. 10 is a diagram showing an example of DL operation of a terminal in a HARQ process-sharing cell group. FIG. 10 shows an example of PDSCH transmission in CC#1, CC#2, and Pcell (PDSCH reception in the terminal) and HARQ-ACK transmission for the received PDSCH. Note that CC#1 and CC#2 are included in the HARQ process sharing cell group. Then, HPNs from 0 to 24 are set for the HARQ process-sharing cell group.

In FIG. 10, the terminal receives PDSCH#1 of HPN#0 and PDSCH#2 of HPN#1 on CC#1. The terminal then transmits HARQ-ACKs for the received PDSCHs #1 and #2 in Pcell under timing control based on parameter K1. In addition, in the example of FIG. 10, HARQ-ACK indicating that reception was not successful for PDSCH#2 of HPN#1 is transmitted.

In FIG. 10, the terminal receives PDSCH#3 corresponding to retransmission of PDSCH#2 of HPN#1 in CC#2, and HARQ-ACK for PDSCH#3 under timing control based on parameter K1. Send in Pcell.

In the example of FIG. 10, HARQ-ACK ("HARQ-ACK for PDSCH#3") is transmitted in Pcell, before PDSCH#4 of HARQ process (an example of a specific HARQ process) of HPN#1 in CC#1 (an example of the second serving cell) The cases to be sent are indicated. As described above, this case is not assumed by the terminal and is an error case.

<Proposal A-5: Example of terminal operation in UL>
The operation of a terminal in UL when HARQ processes/entities are shared within a group of cells is described. If the HARQ process/entity is shared within a group of cells, the terminal may wait (in the first serving cell) until after the expected transmission of the last PUSCH for a particular HARQ process (in the second It is not assumed that another PUSCH transmission for that particular HARQ process will be scheduled by the DCI) in the serving cell. Note that the first serving cell and the second serving cell are included in the same HARQ process sharing cell group.

In other words, the terminal may, after the expected transmission of the last PUSCH for a particular HARQ process (on the first serving cell), terminate another PUSCH for that particular HARQ process (on the second serving cell). , PUSCH transmissions may be assumed to be scheduled by the DCI.

The operation of this terminal will be described below using FIG.

FIG. 11 is a diagram showing an example of UL operation of a terminal in a HARQ process-sharing cell group. FIG. 11 shows an example of PDCCH transmission in CC#1 and CC#2 (PDCCH reception in the terminal) and PUSCH transmission based on the received PDCCH. Note that CC#1 and CC#2 are included in the HARQ process sharing cell group. Then, HPNs from 0 to 24 are set for the HARQ process-sharing cell group. Note that CC#1 and CC#2 do not have to be included in the HARQ process-sharing cell group.

In FIG. 11, the terminal receives PDCCH#1 on CC#1, and transmits PUSCH#1 of HPN#0 on CC#1 based on control information (for example, DCI) included in PDCCH#1. do. Then, the terminal receives PDCCH#2 and #3 on CC#2 and CCs PUSCH#2 corresponding to retransmission of HPN#0 of CC#1 based on the control information included in PDCCH#3. Send with #2.

In the example of FIG. 11 , the terminal uses CC#2 (an example of the first serving cell) before the transmission of PUSCH corresponding to the retransmission of the HPN#0 HARQ process (an example of a specific HARQ process) ends. , PDCCH#2 schedule PUSCH#3 (another PUSCH for that particular HARQ process) for the HARQ process of HPN#0 in CC#2 (an example of a second serving cell). As described above, this case is not assumed by the terminal and is an error case.

So far, proposal A-5 explained the relationship between HARQ process sharing in a HARQ process sharing cell group and HARQ process collision. According to Proposal A-5, since the behavior of the terminal regarding HARQ process collision when HARQ process sharing is applied (supported) is clarified, terminal error behavior due to HARQ process collision is avoided. can.

<Proposal B: Proposal B-1>
Proposal B-1 describes the configuration and/or limitation for cross-CC retransmissions when HARQ processes/entities are separated per cell. For example, any of the following options 1 to 2 may be adopted for setting and/or limiting cross-CC retransmissions. Note that, hereinafter, a CC used for initial transmission may be referred to as an initial CC, and a CC used for retransmission may be referred to as a retransmission CC.

<Option 1 of Proposal B-1>
Option 1 places no restrictions on cross-CC retransmissions. For example, no restrictions are placed so that retransmissions for initial transmissions on the initial CC (and BWP if active) are performed on any retransmission CC (and BWP if active). In other words, in option 1, the retransmitting CC in cross-CC retransmission can be any of the available CCs.

<Option 2 of Proposal B-1>
Option 2 places a limit on cross-CC retransmissions. For example, initial CC (and BWP) and/or retransmission CC (and BWP) limits may be defined by the specification. Alternatively, the initial CC (and BWP) and/or retransmission CC (and BWP) limits may be set by RRC. An example of the restriction in option 2 is described below.

<Option 2-1 of Proposal B-1>
Option 2-1 defines restrictions based on CC (and BWP) attributes.

Option 2-1 Example 1: Restriction based on at least one of frequency, FR range, band, and PUCCH cell group

For example, the retransmission CC (and BWP) may be restricted to a lower carrier frequency (of the active BWP) than the initial CC (and BWP). Alternatively, the retransmission CC (and BWP) may be restricted to a higher carrier frequency (of the active BWP) than the initial CC (and BWP).

For example, the initial CC and retransmission CC may be restricted to the same FR range. Alternatively, the initial CC and retransmission CC may be restricted to different FR ranges.

For example, at least one or both of the initial CC and retransmission CC may be restricted to FR1. Alternatively, the initial CC and/or the retransmission CC may be restricted to FR2. Note that this restriction may be applied when different CCs are used for initial transmission and retransmission. In other words, this restriction may not apply if the same CC is used for initial transmission and retransmission.

For example, the initial CC and the retransmission CC may be restricted to the same band. Alternatively, the initial CC and retransmission CC may be restricted to different bands.

For example, the initial CC and the retransmission CC may be restricted to the same PUCCH cell group, or the initial CC and the retransmission CC may be restricted to the same MCG, The restriction may be that the initial CC and the retransmission CC are in the same SCG. Alternatively, the initial CC and the retransmission CC may be restricted to different PUCCH cell groups, or the initial CC and the retransmission CC may be restricted to different MCGs. However, the restriction may be that the initial CC and the retransmission CC are in different SCGs.

Example 2 of Option 2-1: Restrictions on numerology

For example, the retransmission CC (and BWP) may be restricted to have the same SCS as the initial CC (and BWP), or the retransmission CC (and BWP) is smaller than the initial CC (and BWP). It may be restricted to have SCS, or the retransmission CC (and BWP) may be restricted to have a larger SCS than the initial CC (and BWP). Here, SCS is mentioned as an example of numerology, but numerology considered in the restriction is not limited to SCS.

　Option 2-1 Example 3: Restrictions on bandwidth

For example, the retransmission CC (and BWP) may be restricted to have the same (active BWP) bandwidth as the initial CC (and BWP), or the retransmission CC (and BWP) (and BWP) may be a restriction that, having a bandwidth (of active BWP) less than the initial CC (and BWP) is greater than (active BWP) It may be limited to having a bandwidth.

Option 2-1 Example 4: Restrictions on CBG configuration

For example, the retransmission CC may be restricted to have the same CBG configuration as the initial CC. That is, the CBG configuration may either be provided on the initial CC and the retransmission CC at the same time, or it may be provided on neither the initial CC nor the retransmission CC.

For example, if the initial CC is provided with a CBG configuration, the CC that can be a retransmission CC corresponding to the initial CC is the CC provided with the CBG configuration.

<Option 2-2 of Proposal B-1>
In Option 2-2, RRC sets the relationship between the initial CC (and BWP) and the retransmission CC (and BWP).

Example 1 of Option 2-2: RRC sets that the initial transmission on CC#1 is retransmitted on CC#2, CC#3, and CC#4. In other words, a CC index relationship is established between the initial CC and the retransmission CC.

Note that as a variation, the initial transmission on CC#1 (of a specific BWP) can be CC#2 (of a specific BWP), CC#3 (of a specific BWP), and CC#4 (of a specific BWP) It may be set to be resent at . In other words, a CC index relationship may be established between the initial CC and the retransmission CC, or a relationship including the CC index and the BWP of each CC may be established.

Example 2 of Option 2-2: CC#1 is used to retransmit the initial transmission and data on CC#2, CC#3, and CC#4.

Note that as a variation, using (specific BWP of) CC#1, (specific BWP of) CC#2, (specific BWP of) CC#3, and (specific BWP of CC#4) You may resend the initial transmission with .

Example 3 of option 2-2: It is set that the initial transmission on the CC of band #1 is retransmitted on at least one CC of band #2 or band #3. In other words, a band index relationship is set between the initial CC and the retransmission CC.

Example 4 of option 2-2: It is set to retransmit the initial transmission and data on any CC of band #2 and band #3 using the CC of band #1.

So far, proposal B-1 has explained the settings and restrictions for cross-CC retransmission. According to proposal B-1, in scheduling and the like, the base station can appropriately set the initial CC and the retransmission CC, so that cross-CC retransmission can be performed efficiently, and the Communication delay can be reduced.

<Proposal B: Proposal B-2>
Proposal B-2 describes the scheduling of cross-CC retransmissions when the HARQ processes/entities are separated per cell.

<Proposal B-2-1>
Proposal B-2-1 describes a DCI format for scheduling cross-CC retransmissions when HARQ processes/entities are separated per cell.

The DCI format for scheduling cross-CC retransmission for PDSCH may be an existing DL grant DCI format (at least one of DCI 1_1, DCI 1_2, and DCI 1_0). Alternatively, the DCI format for scheduling cross-CC retransmissions for PDSCH may be the newly defined DL grant DCI format. Alternatively, the DCI format for scheduling cross-CC retransmissions for the PDSCH may be selected from existing DL grant DCI formats and newly defined DL grant DCI formats.

The DCI format for scheduling cross-CC retransmissions for PUSCH may be: an existing UL grant DCI format (at least one of DCI 0_1, DCI 0_2, and DCI 0_0). Alternatively, the DCI format for scheduling cross-CC retransmissions for PUSCH may be the newly defined UL grant DCI format. Alternatively, the DCI format for scheduling cross-CC retransmissions for PUSCH may be selected from existing UL grant DCI formats and newly defined UL grant DCI formats.

Note that if existing DCI formats are used, support for scheduling cross-CC retransmissions may be enabled or disabled by RRC configuration for each DCI format individually. Also, when newly defined DCI formats are used, support for scheduling cross-CC retransmissions may be enabled or disabled by RRC configuration separately for each DCI format.

<Proposal B-2-2>
Proposal B-2-2 describes how to indicate the CC used for initial transmission for cross-CC retransmission (initial CC) when HARQ processes/entities are separated per cell. The following options are considered for instruction methods:

<Option 1 of proposal B-2-2>
Option 1 reuses the existing RNTI (Radio Network Temporary ID). Also, a new DCI field is added to the DCI format to indicate the initial CC. For Option 1 of Proposal B-2-2, any of Options 1-1 to 1-3 below may be applied.

Option 1-1: The CC index of the initial CC is directly indicated. Option 1 may be any of the following cases.

In option 1-1, the DCI field length is determined by the largest CC index among the initial CCs that allow cross-CC retransmission. In other words, the DCI field length is determined as the maximum CC index notification size among the initial CCs for which cross-CC retransmission is possible. In this case, if the indicated initial CC is the same as the indicated scheduling CC, scheduling to indicate the initial CC may be equivalent to legacy scheduling. Note that legacy scheduling may be, for example, scheduling defined in a version (release) in which cross-CC retransmission is not supported (not applied). Also, legacy scheduling may be, for example, scheduling when cross-CC retransmission is not supported (not applied).

Option 1-2: The index of the initial CC is indicated in the set CC list (eg CC list for scheduling CC).

In option 1-2, the DCI field length is determined by the maximum number of CCs in all configured CC lists. For example, the maximum number of CCs in all configured CC lists is denoted as N_max_init.

Using N_max_init, the DCI field length may be determined as log ₂ (N_max_init+1). And one codepoint may be used to indicate legacy scheduling. For example, codepoint "00" indicates legacy scheduling. Also, '01' may indicate that the scheduling PDSCH/PUSCH is for retransmission on CC#i. Here, CC#i may be the first CC in the configured CC list for the current scheduling CC.

　The configured CC list described above is set by one of the following Alts.

(Alt.1)
A CC list is configured for each scheduling CC and/or retransmission CC.

For example, a list with CC#2 (hereinafter referred to as list {CC#2}) is configured for CC#0. With this configuration, retransmissions for an initial transmission on CC#2 are may be performed by

(Alt.2)
A CC list is configured for each set of scheduling CCs and/or set of retransmission CCs.

For example, the list {CC#2, #4} is set to the set {CC#0, #1}. In this case, retransmissions for initial transmissions on CC#2 and/or CC#4 may occur on CC#0 and/or CC#1. Note that the set {CC#0, #1} in this example is the set of retransmission CCs.

(Alt.3)
A CC list is commonly configured for each of the available scheduling CCs and/or available retransmission CCs.

For example, if list {CC#2, #4} is configured, retransmissions for initial transmissions on CC#2 and/or CC#4 may be done by any available scheduling CC. and may be done by any available retransmission CC.

Note that in Alt 2 and Alt 3 described above, the scheduling CC may not be used for retransmission for an initial CC in the configured CC list. For example, it may not be used for retransmissions, subject to the restrictions described in Proposal B-1 above. In this case, the base station may perform scheduling that avoids such scheduling.

Option 1-3: Information is added to the DCI to indicate whether the scheduling is for legacy scheduling or for cross-CC retransmissions. For example, this information may be a 1-bit flag or 2-bit or more information. In this option 1-3, the following cases occur.
Case 1: The case where the added information indicates that the scheduling is legacy scheduling (for example, the case where the 1-bit flag indicates '0')
Case 2: The added information indicates that the scheduling is cross-CC retransmission (e.g., the 1-bit flag is '1').

In Case 1, legacy interpretation is performed for the DCI field. Legacy interpretation corresponds to the interpretation of the fields defined by legacy scheduling.

Case 2 is further divided into Case 2-1 and Case 2-2.
Case 2-1: Case where one initial CC is available for scheduling CC for cross-CC retransmission (case where two or more initial CCs are available)
Case 2-2: Case where there are multiple available initial CCs in the scheduling CC for cross-CC retransmission

In the case of case 2-1, ie, when there is one initial CC available for the scheduling CC for cross-CC retransmission, the initial CC used may be the one initial CC.

For example, in the case of cross-CC retransmission, only the initial transmission on CC#0 is retransmitted on CC#2. In other words, only retransmissions for initial transmissions on CC#0 are performed on CC#2. For example, in CC#2, retransmissions other than retransmissions for the initial transmission in CC#0 may not be performed. Also, retransmission of the initial transmission on CC#0 may not be performed on CCs other than CC#2. Note that in this case, the index indicating the initial CC does not have to be explicitly indicated.

For case 2-2, ie, when there are multiple available initial CCs in the scheduling CC for cross-CC retransmission, some existing DCI fields may be reinterpreted to determine the initial CC. It should be noted that the reinterpretation may correspond to interpretation different from the conventional interpretation. Conventional interpretation corresponds, for example, to interpretation of information defined by legacy scheduling.

Note that for this case 2-2, similar to option 1-1 and option 1-2 above, the reinterpreted field may either directly indicate the index of the initial CC or may indicate the index of

Fields for reinterpretation (for example, DCI fields) are not particularly limited, but may be fields that are not used in the case of cross-CC retransmission, for example. Illustratively, the following fields may be used for reinterpretation fields.
UL grant DCI DFI (Downlink Feedback Information) flag field, if set Uplink-Shared channel (UL-SCH) indicator field in UL grant DCI, if set New data indicator field BWP switching BWP indicator field, assuming the indication is not supported in DCI for cross-CC retransmissions Type 3 HARQ-ACK triggering is not supported in DCI for PDSCH retransmissions with cross-CC retransmissions One-shot HARQ-ACK request assuming
CSI request field, assuming that CSI report triggering is not supported in the DCI for PUSCH retransmission with cross-CC retransmission SRS request DCI for PUSCH retransmission with cross-CC retransmission S, RS request fields, assuming that the SCell dormancy indication is not supported in DCI for cross-CC retransmissions. SCell dormancy indication field TPC command field, assuming no TPC coordination by DCI for cross-CC retransmission CBG enabled for scheduling CC, but initial CC CBG transmission field, if not enabled for

Also, the fields for reinterpretation may be part of the fields that can be saved, eg, in case of cross-CC retransmissions. Fields that can be saved in the case of cross-CC retransmissions are, for example, the size of the fields (e.g. number of bits) used in the case of cross-CC retransmissions may be smaller than in the case of non-cross-CC retransmissions. is a field. Illustratively, some of the fields below may be used for reinterpretation fields.
LSB and/or MSB bits of the FDRA field when the FDRA (Frequency Domain Resource Allocation) granularity is larger than the legacy scheduling of cross-CC retransmissions or when "dynamic switch of resource allocation type" is not supported X bits (X is an integer greater than or equal to 1)
・Assuming that the differential MCS (delta-MCS) for the MCS (Modulation and Coding Scheme) of the initial transmission is indicated, X bits of the LSB and /MSB bits of the MCS field

A field for reinterpretation may also be, for example, a field that allows reuse of the initial transmission. In other words, when the information indicated in the initial transmission is reused, the field notifying the information may be used as the reinterpretation field. Illustratively, the following fields may be used for reinterpretation fields.
・Mapping field from VRB (Virtual Resource Block) to PRB (Physical Resource Block), assuming that the mapping always follows the initial transmission instruction ・Assuming that PRB bundling always follows the initial transmission instruction PRB bundling size indicator, if PHY priority indicator field, assuming PHY priority is always the same as initial transmission; MCS, assuming always the same as initial transmission , MCS field TPMI/SRI field, assuming that MCS is always the same as the initial transmission

If the fields for reinterpretation are fields that can reuse the initial transmission, after determining the corresponding initial transmission, the parameters corresponding to these fields are determined.

As described above, Option 1 of Proposal B-2-2 showed an example in which the existing RNTI is reused for indicating the CC (initial CC) used for initial transmission for cross-CC retransmission. .

<Option 2 of proposal B-2-2>
In option 2, if the DCI is for scheduling cross-CC retransmissions, the new RNTI is used for the indication of the CC used for the initial transmission for cross-CC retransmissions (initial CC). In this case, the following two cases occur.
Case 1: Existing RNTI is used Case 2: New RNTI is used

In Case 1, ie, when the existing RNTI is used, DCI is for legacy scheduling.

For case 2, ie, when new RNTI is used, DCI is for cross-CC retransmissions. Case 2 is further divided into two cases.
Case 2-1: A case where one initial CC is available for the scheduling CC for cross-CC retransmission (a case where two or more initial CCs are available)
Case 2-2: Multiple available initial CCs for scheduling CCs for cross-CC retransmissions

For case 2-2, ie, when there are multiple available initial CCs in the scheduling CC for cross-CC retransmission, the initial CC may be indicated explicitly. Similar to Option 1-1 and Option 1-2 described above, the DCI may directly indicate the index of the initial CC or may indicate the index within the configured CC list.

<Option 3 of Proposal B-2-2>
Option 3 reuses the existing RNTI. The existing field is then reinterpreted to indicate the initial CC.

Option 3 is similar to option 1 in that the existing RNTI is reused. However, Option 1 adds a new DCI field to indicate the initial CC, whereas Option 3 uses an existing field (eg, the DCI field) to indicate the initial CC and reinterprets it.

For example, some combination of patterns of values in one or more specific fields of a DCI is used to indicate whether the DCI is a DCI for legacy scheduling or a DCI for cross-CC retransmission scheduling. be.

A specific field may be a field that is not used in the case of cross-CC retransmission. Alternatively, certain fields may be part of the fields saved in case of cross-CC retransmissions. Alternatively, the particular field may be a field that allows reuse of the fields of the initial transmission, as shown in option 1-3 case 2-2 above. Alternatively, the particular field is two or more of a field that is not used in case of cross-CC retransmission, a portion of the field that is saved in case of cross-CC retransmission, and a field that can reuse the fields of the initial transmission. It may be a combination.

For example, in the case of the TPMI (Transmitted Precoding Matrix Indicator)/SRI (SRS (Sounding Reference Signal) Resource Indicator) field, the pattern of all "0" indicates whether the DCI containing the field is a legacy scheduling DCI or a cross It may be used to indicate either DCI for CC retransmission scheduling. In addition, a pattern of all "0" may be used for the MCS field, and a pattern of all "0" may be used for "TDRA (Time Domain Resource Allocation)".

When some combination of patterns of values in one or more specific fields of a DCI is used to indicate whether the DCI is a DCI for legacy scheduling or a DCI for cross-CC retransmission scheduling , the following cases occur:
Case 1: Case where the value of a specific field does not match the pattern Case 2: Case where the value of a specific field matches the pattern

For Case 1, ie, when the value of a particular field does not match the pattern, DCI may be for legacy scheduling.

For Case 2, ie, if the value of the particular field matches the pattern, DCI may be for cross-CC retransmissions. Case 2 is further divided into the following cases.
Case 2-1: A case where one initial CC is available for the scheduling CC for cross-CC retransmission (a case where two or more initial CCs are available)
Case 2-2: Multiple available initial CCs for scheduling CCs for cross-CC retransmissions

For case 2-2, i.e., when there are multiple available initial CCs in the scheduling CC for cross-CC retransmission, the initial CC is explicitly indicated by reinterpreting one or more existing fields. good too.

For example, a reinterpretation as shown in option 1-3 case 2-2 above may be reused to indicate the initial CC index directly, or to indicate the index within the configured CC list. .

<Proposal B-2-3>
Proposal B-2-3 describes HPN indication of initial transmission for cross-CC retransmissions when HARQ processes/entities are separated per cell. For Proposal B-2-3, the following options are considered.

<Option 1 of proposal B-2-3>
For Option 1, the HPN of the initial transmission on the initial CC is the same as the HPN of the retransmissions on the retransmission CC. For this option 1, the HPN of the initial transmission on the initial CC may not be explicitly indicated.

<Option 2 of Proposal B-2-3>
In Option 2, the HPN of the initial transmission on the initial CC can be the same as or different from the HPN of the retransmissions on the retransmission CC. For this option 2, the DCI explicitly indicates the HPN of the initial transmission on the initial CC. For Option 2, two further options are considered.

Option 2-1: The HPN of the initial transmission on the initial CC is indicated by a new DCI field added for DCI scheduling cross-CC retransmissions.

Option 2-2: If the terminal determines that the received DCI is for cross-CC retransmission scheduling, the HPN of the initial transmission on the initial CC may be reinterpreted by the existing DCI field.

In addition, in order to determine whether the DCI is for cross-CC retransmission scheduling or for legacy scheduling, a method similar to the method shown in proposal B-2-2 above may be used.

Also, the field used for reinterpreting the HPN of the initial transmission in the initial CC may be the same as the "reinterpretation field" shown in Option 1-3 of Proposal B-2-3 above.

So far, proposal B-2 has explained the scheduling of cross-CC retransmissions. According to proposal B-2, in scheduling and the like, the base station can appropriately set the initial CC and the retransmission CC, so cross-CC retransmission can be performed efficiently, and communication between the terminal and the base station can be performed. Communication delay can be reduced. Proposal B-2 also defines DCI and DCI fields for signaling information for cross-CC retransmissions. By this means, information for cross-CC retransmission can be appropriately reported from the base station to the terminal, and cross-CC retransmission can be performed.

<Proposal B: Proposal B-3>
Proposal B-3 describes the relationship between the type of HARQ-ACK, called type 3 HARQ-ACK feedback, and cross-CC retransmissions when HARQ processes/entities are separated per cell. The following options are considered.

<Option 1 of Proposal B-3>
The terminal shall enable cross-CC retransmission on any DL grant DCI format if (enhanced) Type 3 HARQ triggering is enabled for any DL grant DCI format. Do not assume that Alternatively, if cross-CC retransmission is enabled for any DL grant DCI format, the UE may specify that (extended) Type 3 HARQ triggers are enabled for any DL grant DCI format. Don't assume there is. In other words, if (extended) Type 3 HARQ triggers are enabled for any DL grant DCI format, cross-CC retransmissions are not allowed to be enabled for any DL grant DCI format . Alternatively, (extended) Type 3 HARQ triggers are not allowed to be enabled for any DL grant DCI format if cross-CC retransmission is enabled for any DL grant DCI format .

<Option 2 of Proposal B-3>
Cross-CC retransmissions are allowed to be enabled in any DL grant DCI format if (extended) Type 3 HARQ-ACK triggering is enabled in any DL grant DCI format.

In Option 2, either Option 2-1 or Option 2-2 below may be applied to generate an (extended) Type 3 HARQ-ACK CB.

Option 2-1: HARQ-ACK information for cross-CC retransmissions scheduled by DCI is included in the (extended) Type 3 HARQ-ACK CB at the HARQ process ID position of the HARQ-ACK bit of the initial CC be This option 2-1 will be described with reference to FIG.

FIG. 12 is a diagram showing a first example of Type 3 HARQ-ACK CB in this embodiment. FIG. 12 shows an example of option 2-1 discussed above. FIG. 12 shows an example of PDSCH transmission in CC#0, CC#1, and Pcell (PDSCH reception in the terminal) and HARQ-ACK transmission for the received PDSCH. Also, FIG. 12 shows a configuration example of Type 3 HARQ-ACK CB transmitted in Pcell.

In option 2-1, in Type 3 HARQ-ACK CB, it is included in the HARQ process ID position of the HARQ-ACK bit of the initial CC, so as in the example of FIG. HARQ-ACK information is included in the HPN#1 position of "HARQ-ACK for HARQ process on CC#0" of Type 3 HARQ-ACK CB. Similarly, the HARQ-ACK information of the HARQ process of HPN#1 of CC#1 is included in the HPN#1 position of "HARQ-ACK for HARQ process on CC#1" of Type 3 HARQ-ACK CB.

Also, even if CC#1 retransmits HPN#1 of CC#0 by cross-CC retransmission, HARQ-ACK information for retransmission of HPN#1 performed by CC#1 corresponds to the initial CC. Included in the position corresponding to CC#0, that is, the position of HPN#1 in "HARQ-ACK for HARQ process on CC#0".

　For the HARQ process ID of the HARQ-ACK bit of the retransmission CC, legacy scheduling of the retransmission CC using the HARQ process ID may be applied. Note that option 2-1 is reasonable since the retransmission is for the HARQ process on the first CC.

Option 2-2: HARQ-ACK information for cross-CC retransmissions scheduled by DCI is included in the HARQ-ACK bits of retransmission CCs and/or scheduling CCs in (extended) Type 3 HARQ-ACK CBs be In other words, the DCI-scheduled cross-CC retransmission HARQ-ACK information is the location of the corresponding HARQ process location of the retransmission CC and/or scheduling CC in the (extended) Type 3 HARQ-ACK CB. exists in This option 2-2 will be described with reference to FIG.

FIG. 13 is a diagram showing a second example of Type 3 HARQ-ACK CB in this embodiment. FIG. 13 shows an example of Option 2-2 discussed above. Similar to FIG. 12, FIG. 13 shows an example of PDSCH transmission (PDSCH reception in the terminal) in CC#0, CC#1, and Pcell, and HARQ-ACK transmission for the received PDSCH. Also, FIG. 13 shows a configuration example of Type 3 HARQ-ACK CB transmitted in Pcell.

In option 2-2, in the Type 3 HARQ-ACK CB, since it is included in the HARQ-ACK bit of the retransmission CC and/or scheduling CC, as in the example of FIG. 13, the HARQ process of HPN#0 of CC#0 HARQ-ACK information is included in the HPN#1 position of "HARQ-ACK for HARQ process on CC#0" of Type 3 HARQ-ACK CB. Similarly, the HARQ-ACK information of the HARQ process of HPN#1 of CC#0 is included in the HPN#1 position of "HARQ-ACK for HARQ process on CC#0" of Type 3 HARQ-ACK CB.

Also, when CC#1 retransmits HPN#1 of CC#0 by cross-CC retransmission, HARQ-ACK information for retransmission of HPN#1 performed by CC#1 corresponds to the retransmission CC. Included in the position corresponding to CC#1, that is, the position of HPN#1 in "HARQ-ACK for HARQ process on CC#1".

For the HARQ process ID of the HARQ-ACK bit of the initial CC, legacy scheduling of the initial CC using the HARQ process ID may be applied. Note that there may be legacy scheduling that uses the same HARQ process for the scheduling CC, so it may not be reasonable.

Here, there is a first PDSCH that corresponds to HPN #m and is initially transmitted in the first serving cell #i and that corresponds to HPN #n and is retransmitted in the second serving cell #j. and there is a second PDSCH that corresponds to HPN #n and whose initial transmission is performed in the second serving cell #j. Note that m may be the same as or different from n.

In this case, if HPN #n of serving cell #j is requested for (extended) Type 3 HARQ-ACK reports, any of the following options 2-2A, 2-2B, and 2-2C: may apply.

Option 2-2A: HARQ-ACK of retransmission of the first PDSCH in serving cell #j corresponding to HPN #n is placed at HPN #n position of (extended) Type 3 HARQ-ACK CB (mapped). In this case, the HARQ-ACK of the initial transmission of the second PDSCH in the serving cell #i corresponding to HPN#n may be skipped.

Option 2-2B: HARQ-ACK of the second PDSCH initial transmission in serving cell #i corresponding to HPN #n is placed at HPN #n position of (extended) Type 3 HARQ-ACK CB ( mapped). In this case, HARQ-ACK for retransmission of the first PDSCH in serving cell #j corresponding to HPN #n may be skipped.

Option 2-2C: Which of the retransmission HARQ-ACK of the first PDSCH and the HARQ-ACK of the initial transmission of the second PDSCH is arranged is any one of the following, or two or more may be determined by a combination of
Information indicating any of the PDSCH start slot, PDSCH end slot, PDSCH start symbol, and PDSCH end symbol (for example, index)
- PHY priority indicated in scheduling DCI - PDSCH is DG PDSCH - PDSCH is SPS PDSCH

Note that in option 2-2C, HARQ-ACKs of PDSCHs other than HARQ-ACKs of retransmission of the first PDSCH and HARQ-ACKs of initial transmission of the second PDSCH may be skipped.

So far, proposal B-3 explained the relationship between type 3 HARQ-ACK CB and cross-CC retransmission. According to proposal B-3, appropriate communication control (retransmission control) is performed according to type 3 HARQ-ACK CB and cross-CC retransmission. Then, for example, when type 3 HARQ-ACK CB and cross-CC retransmission are enabled, type 3 HARQ-ACK CB considering cross-CC retransmission is generated, so appropriate HARQ-ACK transmission It can be performed.

<Proposal B: Proposal B-4>
Proposal B-4 describes terminal behavior in the context of HARQ process collisions when HARQ processes/entities are separated per cell. HARQ process collision is the same as the example shown in Proposal A-5.

<Proposal B-4: Terminal operation example 1 in DL>
First, an operation example 1 of a terminal in DL in consideration of collision of HARQ processes when HARQ processes/entities are separated for each cell will be described.

A terminal may transmit a second HARQ process for a particular HARQ process in a particular serving cell before the expected transmission of HARQ-ACK for the first PDSCH with the particular HARQ process in the particular serving cell ends. PDSCH reception is allowed. Here, the first PDSCH of the serving cell is for retransmission of a PDSCH originally transmitted in another serving cell.

The operation of this terminal will be described below using FIG.

FIG. 14 is a diagram showing DL operation example 1 of a terminal when HARQ processes/entities are separated for each cell. FIG. 14 shows an example of PDSCH transmission in CC#1, CC#2, and Pcell (PDSCH reception in the terminal) and HARQ-ACK transmission for the received PDSCH. In addition, since the HARQ process/entity is separated for each cell, the HPN is set individually for CC#1 and CC#2. For example, CC#1 is set with HPNs from 0 to 16, and CC#2 is set with HPNs from 0 to 8.

In FIG. 14, the terminal receives PDSCH#1 of HPN#0 and PDSCH#2 of HPN#1 on CC#1. The terminal then transmits HARQ-ACKs for the received PDSCHs #1 and #2 in Pcell under timing control based on parameter K1. In addition, in the example of FIG. 14, HARQ-ACK indicating that reception was not successful for PDSCH#2 of HPN#1 is transmitted.

In FIG. 14 , the terminal receives PDSCH#3 corresponding to retransmission of PDSCH#2 of HPN#1 of CC#1 in CC#2, and performs HARQ-ACK for PDSCH#3 with timing control based on parameter K1. Send in Pcell under .

In the example of FIG. 14, HARQ-ACK ("HARQ-ACK for PDSCH #3") is transmitted in Pcell, PDSCH#4 of HARQ process (an example of a specific HARQ process) of HPN#1 is transmitted in CC#2 (an example of a specific serving cell) case is shown. As mentioned above, this case is the terminal allowed case.

<Proposal B-4: Terminal operation example 2 in DL>
Next, an operation example 2 of a terminal in DL in consideration of collision of HARQ processes when HARQ processes/entities are separated for each cell will be described.

The terminal receives the second PDSCH of the particular HARQ process in the second serving cell until the expected transmission of HARQ-ACK for the first PDSCH of the particular HARQ process in the first serving cell is terminated. should not be expected to do so. Here, the first PDSCH of the serving cell is for retransmission of a PDSCH originally transmitted in another serving cell.

The operation of this terminal will be described below using FIG.

FIG. 15 is a diagram showing DL operation example 2 of a terminal when HARQ processes/entities are separated for each cell. Similar to FIG. 14, FIG. 15 shows an example of PDSCH transmission in CC#1, CC#2, and Pcell (PDSCH reception in the terminal) and HARQ-ACK transmission for the received PDSCH. In addition, since the HARQ process/entity is separated for each cell, the HPN is set individually for CC#1 and CC#2. For example, CC#1 is set with HPNs from 0 to 16, and CC#2 is set with HPNs from 0 to 8.

In FIG. 15, the terminal receives PDSCH#1 of HPN#0 and PDSCH#2 of HPN#1 on CC#1. The terminal then transmits HARQ-ACKs for the received PDSCHs #1 and #2 in Pcell under timing control based on parameter K1. Note that in the example of FIG. 15, HARQ-ACK indicating that reception was not successful for PDSCH#2 of HPN#1 is transmitted.

In FIG. 15 , the terminal receives PDSCH#3, which corresponds to retransmission of PDSCH#2 of HPN#1 of CC#1, in CC#2, and performs HARQ-ACK for PDSCH#3 using timing control based on parameter K1. Send in Pcell under .

In the example of FIG. 15, HARQ-ACK (“HARQ-ACK for PDSCH#3") is transmitted in Pcell, before PDSCH#4 of HARQ process (an example of a specific HARQ process) of HPN#1 in CC#1 (an example of the second serving cell) The cases to be sent are indicated. As described above, this case is not assumed by the terminal and is an error case.

<Proposal B-4: Terminal operation example 1 in UL>
Next, an operation example 1 of a terminal in UL in consideration of collision of HARQ processes when HARQ processes/entities are separated for each cell will be described.

The terminal may transmit another PUSCH for a particular HARQ process (in a second serving cell) until after the expected transmission of the last PUSCH for that particular HARQ process (in a first serving cell). are allowed to be scheduled by DCI.

The operation of this terminal will be described below using FIG.

FIG. 16 is a diagram showing UL operation example 1 of a terminal when HARQ processes/entities are separated for each cell. FIG. 16 shows an example of PDCCH transmission in CC#1 and CC#2 (PDCCH reception in the terminal) and PUSCH transmission based on the received PDCCH. In addition, since the HARQ process/entity is separated for each cell, the HPN is set individually for CC#1 and CC#2. For example, CC#1 is set with HPNs from 0 to 16, and CC#2 is set with HPNs from 0 to 8.

In FIG. 16, the terminal receives PDCCH#1 on CC#1, and transmits PUSCH#1 of HPN#0 on CC#1 based on control information (for example, DCI) included in PDCCH#1. do. Then, the terminal receives PDCCH#2 and #3 on CC#2 and CCs PUSCH#2 corresponding to retransmission of HPN#0 of CC#1 based on the control information included in PDCCH#3. Send with #2.

In the example of FIG. 16, the terminal terminates transmission of PUSCH#2 corresponding to retransmission of the HARQ process (an example of a specific HARQ process) of HPN#0 in CC#2 (an example of the first serving cell). Previously, due to DCI of PDCCH#2, in CC#2 (an example of the second serving cell), PUSCH#3 for the HARQ process of HPN#0 of CC#1 (another PUSCH for the specific HARQ process) This is a scheduled case. As mentioned above, this case is the terminal allowed case.

In addition, in the example of FIG. 16, since the HARQ processes/entities are separated for each cell, CC#1 and CC#2 are individually set with HPN. Therefore, PUSCH#2 corresponding to retransmission of the HARQ process of HPN#0 of CC#1 and PUSCH#3 corresponding to the HARQ process of HPN#0 are different HARQ processes, and are allowed in the terminal.

<Proposal B-4: Terminal operation example 2 in UL>
Next, an operation example 2 of a terminal in UL in consideration of collision of HARQ processes when HARQ processes/entities are separated for each cell will be described.

The terminal may transmit another PUSCH for a particular HARQ process (in a second serving cell) until after the expected transmission of the last PUSCH for that particular HARQ process (in a first serving cell). is scheduled by DCI.

In other words, in the terminal operation example 2 on the UL, the terminal does not assume the case that was allowed in the above-described terminal operation example 1 on the UL.

A terminal operation example 2 in UL will be described with reference to FIG. Before the transmission of PUSCH#2 corresponding to the retransmission of the HPN#0 HARQ process (an example of a specific HARQ process) ends in CC#2 (an example of a first serving cell) shown in FIG. DCI of PDCCH#2 schedules PUSCH#3 (another PUSCH for the specific HARQ process) for HARQ process of HPN#0 of CC#1 in CC#2 (an example of a second serving cell) No case is assumed by the terminal in example 2 of terminal operation in the UL.

<Supplement>
Which of each proposal and each option of each proposal described above is used (or applied) may be set by higher layer signals (information or parameters). Higher layer signals (information or parameters) may be referred to as, for example, RRC parameters and MAC CE.

Alternatively, which of the above proposals and each option of each proposal is to be used (or whether to be applied) may be notified by the terminal as terminal capability information (eg, UE capability). Alternatively, which of the above options to use (or apply to) may be stated in the specification. Alternatively, which of each option described above is used (or applied) may be set (or determined) by a combination of two or more of these. For example, which of the options described above is used (or whether it is applied) may be determined by the setting of upper layer parameters and the reported terminal capability information (eg, UE capability).

<Terminal Capability>
For example, the terminal capability information (UE capability) may include provisions regarding any one or more of the following. Then, terminal capability information that defines one or more of the following may be notified (reported).
Regarding whether the terminal supports cross-carrier PDSCH/PUSCH retransmissions Regarding whether the terminal supports HARQ process/entity sharing for groups of cells Regarding whether the terminal supports the use of HARQ process/entity sharing cell groups - Regarding whether the terminal supports cross-carrier PDSCH/PUSCH retransmission on CCs within the FR and/or between CCs - Regarding whether the terminal supports CCs within a PUCCH cell group and/or between PUCCH cell groups Regarding whether the terminal supports cross-carrier PDSCH/PUSCH retransmission of CCs of the and/or regarding whether to support cross-carrier PDSCH/PUSCH retransmissions for CCs of different bandwidths regarding whether the terminal supports cross-carrier PDSCH/PUSCH retransmissions for CCs of the same numerology and/or CCs of different numerologies - Regarding whether the terminal supports cross-carrier PDSCH/PUSCH retransmission of CCs that have the relationship set in RRC for the relationship between the initial CC and the retransmission CC - If the terminal uses the existing RNTI, the existing DCI Regarding whether the format supports scheduled cross-carrier PDSCH/PUSCH retransmissions: The terminal supports cross-carrier PDSCH/PUSCH retransmissions scheduled by an existing DCI format using a new RNTI (e.g., an RNTI different from the existing RNTI). whether the terminal supports cross-carrier PDSCH/PUSCH retransmissions scheduled by a new DCI format (e.g., a DCI format different from the existing DCI format); whether the terminal is (enhanced) Regarding whether to support simultaneous activation of Type 3 HARQ-ACK feedback trigger and cross-carrier PDSCH/PUSCH retransmission activation

<Example of wireless communication system>
The radio communication system according to the present embodiment includes base station 10 shown in FIG.17 and terminal 20 shown in FIG.18. The number of base stations 10 and the number of terminals 20 are not particularly limited. For example, as shown in FIG. 1, a system in which two base stations 10 (base station 10-1 and base station 10-2) communicate with one terminal 20 may be used. The wireless communication system may be a wireless communication system according to New Radio (NR). Exemplarily, the wireless communication system may be a wireless communication system according to a scheme called URLLC and/or IIoT.

The wireless communication system may be a wireless communication system that conforms to a system called 5G, Beyond 5G, 5G Evolution, or 6G.

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). Also, the base station 10 may be regarded as a device included in the network to which the terminal 20 connects.

The radio communication system may include Next Generation-Radio Access Network (NG-RAN). NG-RAN includes multiple NG-RAN Nodes, specifically gNBs (or ng-eNBs), and is connected to a 5G-compliant core network (5GC, not shown). Note that NG-RAN and 5GC may be simply referred to as "networks".

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 uses Massive MIMO (Multiple-Input Multiple-Output) to generate beams (BM) with higher directivity by controlling radio signals transmitted from a plurality of antenna elements. You can respond. Also, at least one of the base station 10 and the terminal 20 may support carrier aggregation (CA) that uses a plurality of component carriers (CC) in a bundle. Also, at least one of the base station 10 and the terminal 20 may support dual connectivity (DC), etc., in which communication is performed between the terminal 20 and each of the plurality of base stations 10 .

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

In FR1, Sub-Carrier Spacing (SCS) of 15 kHz, 30 kHz or 60 kHz may be used, and a bandwidth (BW) of 5 MHz to 100 MHz may be used. FR2 is, for example, a higher frequency than FR1. FR2 may use an SCS of 60 kHz or 120 kHz and a bandwidth (BW) of 50 MHz to 400 MHz. Also, FR2 may include a 240 kHz SCS.

The wireless communication system in this embodiment may support a frequency band higher than the frequency band of FR2. For example, the wireless communication system in this embodiment can support frequency bands exceeding 52.6 GHz and up to 114.25 GHz. Such high frequency bands may be referred to as "FR2x."

Also, Cyclic Prefix-Orthogonal Frequency Division Multiplexing (CP-OFDM)/Discrete Fourier Transform - Spread - Orthogonal Frequency Division Multiplexing (DFT-S-OFDM) with larger Sub-Carrier Spacing (SCS) than the above example is applied. may Also, DFT-S-OFDM may be applied to both uplink and downlink, or may be applied to either one.

In a wireless communication system, a time division duplex (TDD) slot configuration pattern may be set. For example, in the slot setting pattern, slots for transmitting downlink (DL) signals, slots for transmitting uplink (UL) signals, slots in which DL signals, UL signals and guard symbols are mixed, and signals to be transmitted are flexible A pattern may be defined that indicates the order of two or more of the slots to be changed to .

Further, in a radio communication system, channel estimation of PUSCH (or PUCCH (Physical Uplink Control Channel)) can be performed using a demodulation reference signal (DMRS) for each slot. can be used to perform channel estimation for PUSCH (or PUCCH). Such channel estimation may be called joint channel estimation. Alternatively, it may be called by another name such as cross-slot channel estimation.

The terminal 20 may transmit the DMRS assigned to each of the multiple slots so that the base station 10 can perform joint channel estimation using DMRS.

In addition, 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, enhanced functionality of terminal feedback for HARQ-ACK may be added.

Next, the configurations of the base station 10 and the terminal 20 will be explained. It should be noted that the configurations of the base station 10 and the terminal 20 described below are examples of functions related to the present embodiment. The base station 10 and terminal 20 may have functions not shown. Also, the functional division and/or the name of the functional unit are not limited as long as the function executes the operation according to the present embodiment.

<Configuration of base station>
FIG. 17 is a block diagram showing an example of the configuration of base station 10 according to this embodiment. The base station 10 includes a transmitter 101, a receiver 102, and a controller 103, for example. The base station 10 wirelessly communicates with the terminal 20 (see FIG. 18).

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

A DL signal may include, for example, a downlink data signal and control information (eg, Downlink Control Information (DCI)). In addition, the DL signal may include information (for example, UL grant) indicating scheduling regarding signal transmission of the terminal 20 . Also, the DL signal may include higher layer control information (for example, Radio Resource Control (RRC) control information). Also, the DL signal may include a reference signal.

Channels used for transmitting DL signals include, for example, data channels and control channels. 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 PDCCH, and transmits downlink data signals using PDSCH.

Examples of reference signals included in DL signals include demodulation reference signals (DMRS), phase tracking reference signals (PTRS), channel state information-reference signals (CSI-RS), sounding reference signals (SRS ), and Positioning Reference Signal (PRS) for position information. For example, reference signals such as DMRS and PTRS are used for demodulation of downlink data signals and transmitted using PDSCH.

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

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

For example, the control unit 103 acquires information such as data and control information from the upper layer and outputs it to the transmission unit 101 . Also, the control unit 103 outputs the data and control information received from the receiving unit 102 to the upper layer.

For example, the control unit 103, based on the signal received from the terminal 20 (e.g., data and control information, etc.) and / or data and control information obtained from the upper layer, resource (or channel) used for transmission and reception of the DL signal and/or allocates resources used for transmission and reception of UL signals. Information about the allocated resources may be included in control information to be transmitted to the terminal 20 .

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

For example, the control unit 103 performs scheduling in UL and DL. Scheduling includes resource allocation, generation of control information, retransmission control, and the like. Scheduling may also include control over HARQ process/entity sharing (eg, determination of HARQ process/entity sharing cell groups).

<Device configuration>
FIG. 18 is a block diagram showing an example of the configuration of terminal 20 according to this embodiment. Terminal 20 includes, for example, receiver 201 , transmitter 202 , and controller 203 . The terminal 20 communicates with the base station 10 by radio, for example.

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

The transmission unit 202 transmits the UL signal to the base station 10. For example, the transmitter 202 transmits UL signals under the control of the controller 203 .

The UL signal may include, for example, an uplink data signal and control information (eg, UCI). For example, information about the processing capability of terminal 20 (eg, UE capability) may be included. Also, the UL signal may include a reference signal.

Channels used to transmit UL signals include, for example, data channels and control channels. For example, the data channel includes PUSCH (Physical Uplink Shared Channel), and the control channel includes PUCCH (Physical Uplink Control Channel). For example, the terminal 20 receives control information from the base station 10 using PUCCH, and transmits uplink data signals using PUSCH.

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

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

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

For example, the control unit 203 controls transmission of information to be fed back to the base station 10 . Information fed back to the base station 10 may include, for example, HARQ-ACK, channel state information (CSI), or scheduling request (SR). good. Information to be fed back to the base station 10 may be included in the UCI. UCI is transmitted on PUCCH resources.

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

Note that the channels used for DL signal transmission and the channels used for UL signal transmission are not limited to the above examples. For example, the channel used for DL signal transmission and the channel used for UL signal transmission may include RACH (Random Access Channel) and PBCH (Physical Broadcast Channel). RACH may be used, for example, to transmit Downlink Control Information (DCI) containing Random Access Radio Network Temporary Identifier (RA-RNTI).

Also, the control unit 203 performs communication control (for example, retransmission control) based on the HARQ process in UL and DL and generates HARQ-ACK information. The generated HARQ-ACK information may be included in the UL signal.

This concludes the explanation of the present disclosure. Note that the division of items in the above description is not essential to the present disclosure, and the items described in two or more items may be used in combination as necessary, and the items described in one item may be may apply (unless inconsistent) to the items listed in

<Hardware configuration, etc.>
The block diagrams used in the description of the above embodiments show blocks for each function. These functional blocks (components) are implemented by any combination of at least one of hardware and software. Also, the method of realizing each functional block is not particularly limited. That is, each functional block may be implemented using one device physically or logically coupled, or directly or indirectly using two or more physically or logically separated devices (e.g. , wired, wireless, etc.) and may be implemented using these multiple devices. A functional block may be implemented by combining software in the one device or the plurality of devices.

Functions include judging, determining, determining, calculating, calculating, processing, deriving, examining, searching, checking, receiving, transmitting, outputting, accessing, resolving, selecting, choosing, establishing, comparing, assuming, expecting, assuming, Broadcasting, notifying, communicating, forwarding, configuring, reconfiguring, allocating, mapping, assigning, etc. can't For example, a functional block (component) that makes transmission work is called a transmitting unit or transmitter. In either case, as described above, the implementation method is not particularly limited.

For example, a base station, a terminal, etc. 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. 19 is a diagram showing an example of hardware configurations of a base station and a terminal according to this embodiment. The base station 10 and 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.

In the following explanation, the term "apparatus" can be read as a circuit, device, unit, or the like. The hardware configuration of the base station 10 and terminal 20 may be configured to include one or more of each device shown in the figure, or may be configured without some devices.

Each function of the base station 10 and the terminal 20 is performed by the processor 1001 by loading predetermined software (program) onto hardware such as the processor 1001 and the memory 1002, and the processor 1001 performs calculations and controls communication by the communication device 1004. , and controlling at least one of reading and writing of data in the memory 1002 and the storage 1003 .

The processor 1001, for example, operates an operating system and controls the entire computer. The processor 1001 may be configured by a central processing unit (CPU) including an interface with peripheral devices, a control device, an arithmetic device, registers, and the like. For example, the control unit 103 and the control unit 203 described above may be implemented by the processor 1001 .

Also, the processor 1001 reads programs (program codes), software modules, data, etc. from at least one of the storage 1003 and the communication device 1004 to the memory 1002, and executes various processes according to them. As the program, a program that causes a computer to execute at least part of the operations described in the above embodiments is used. 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 other functional blocks may be similarly implemented. Although it has been explained that the above-described various processes are executed by one processor 1001, they may be executed simultaneously or sequentially by two or more processors 1001. FIG. Processor 1001 may be implemented by one or more chips. Note that the program may be transmitted from a network via an electric communication line.

The memory 1002 is a computer-readable recording medium, and is composed of at least one of, for example, ROM (Read Only Memory), EPROM (Erasable Programmable ROM), EEPROM (Electrically Erasable Programmable ROM), and RAM (Random Access Memory). may be The memory 1002 may also be called a register, cache, main memory (main storage device), or the like. The memory 1002 can store executable programs (program code), software modules, etc. for implementing a wireless communication method according to an embodiment of the present disclosure.

The storage 1003 is a computer-readable recording medium, for example, an optical disk such as a CD-ROM (Compact Disc ROM), a hard disk drive, a flexible disk, a magneto-optical disk (for example, a compact disk, a digital versatile disk, a Blu-ray disk), smart card, flash memory (eg, card, stick, key drive), floppy disk, magnetic strip, and/or the like. Storage 1003 may also be called an auxiliary storage device. The storage medium described above may be, for example, a database, server, or other suitable medium including at least one of memory 1002 and storage 1003 .

The communication device 1004 is hardware (transmitting/receiving device) for communicating between computers via at least one of a wired network and a wireless network, and is also called a network device, a network controller, a network card, a communication module, or the like. The communication device 1004 includes a high-frequency switch, a duplexer, a filter, a frequency synthesizer, and the like, for example, to realize at least one of frequency division duplex (FDD) and time division duplex (TDD). may consist of For example, the transmitting unit 101 , the receiving unit 102 , the receiving unit 201 , the transmitting unit 202 and the like described above may be implemented by the communication device 1004 .

The input device 1005 is an input device (for example, keyboard, mouse, microphone, switch, button, sensor, etc.) that receives input from the outside. The output device 1006 is an output device (eg, display, speaker, LED lamp, etc.) that outputs to the outside. Note that the input device 1005 and the output device 1006 may be integrated (for example, a touch panel).

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 devices.

In addition, the base station 10 and the terminal 20 include hardware such as microprocessors, digital signal processors (DSPs), ASICs (Application Specific Integrated Circuits), PLDs (Programmable Logic Devices), and FPGAs (Field Programmable Gate Arrays). , and part or all of each functional block may be implemented by the hardware. For example, processor 1001 may be implemented using at least one of these pieces of hardware.

<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 includes physical layer signaling (e.g., DCI (Downlink Control Information), UCI (Uplink Control Information)), higher layer signaling (e.g., RRC (Radio Resource Control) signaling, MAC (Medium Access Control) signaling, It may be implemented by broadcast information (MIB (Master Information Block), SIB (System Information Block)), other signals, or a combination thereof. RRC signaling may also be called an RRC message, and may be, for example, an RRC connection setup message, an RRC connection reconfiguration message, or the like.

<Applicable system>
Embodiments described in the present disclosure are LTE (Long Term Evolution), LTE-A (LTE-Advanced), 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, 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.20, UWB (Ultra-WideBand), Bluetooth (registered trademark), or any other suitable system, and any extensions, modifications, creations or provisions based thereon It may be applied to at least one of the generation systems. Also, a plurality of systems may be applied in combination (for example, a combination of at least one of LTE and LTE-A and 5G, etc.).

<Processing procedure, etc.>
The processing procedures, sequences, flowcharts, etc. of each aspect/embodiment described in this disclosure may be rearranged as long as there is no contradiction. For example, the methods described in this disclosure present elements of the various steps using a sample order, and are not limited to the specific order presented.

<Base station operation>
Certain operations that are described in this disclosure 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 with a base station, various operations performed for communication with a terminal may be performed by the base station and other network nodes other than the base station (e.g. MME or S-GW, etc. (including but not limited to). Although the case where there is one network node other than the base station is exemplified above, it may be a combination of a plurality of other network nodes (for example, MME and S-GW).

<Direction of input/output>
Information and the like (see the item <information, signal>) can be output from a higher layer (or a lower layer) to a lower layer (or a higher layer). It may be input and output via multiple network nodes.

<Handling of input/output information, etc.>
Input/output information and the like may be stored in a specific location (for example, memory), or may be managed using a management table. Input/output information and the like can be overwritten, updated, or appended. The output information and the like may be deleted. The entered information and the like may be transmitted to another device.

<Determination method>
The determination may be made by a value represented by one bit (0 or 1), by a true/false value (Boolean: true or false), or by numerical comparison (for example, a predetermined value).

<Variation of mode, etc.>
Each aspect/embodiment described in the present disclosure may be used alone, may be used in combination, or may be used by switching according to execution. In addition, the notification of predetermined information (for example, notification of “being X”) is not limited to being performed explicitly, but may be performed implicitly (for example, not notifying the predetermined information). good too.

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 in this disclosure. The present disclosure can be practiced with modifications and variations without departing from the spirit and scope of the present disclosure as defined by the claims. Accordingly, the description of the present disclosure is for illustrative purposes and is not meant to be limiting in any way.

<Software>
Software, whether referred to as software, firmware, middleware, microcode, hardware description language or otherwise, includes instructions, instruction sets, code, code segments, program code, programs, subprograms, and software modules. , applications, software applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, functions, and the like.

In addition, software, instructions, information, etc. may be transmitted and received via a transmission medium. For example, the software uses wired technology (coaxial cable, fiber optic cable, twisted pair, Digital Subscriber Line (DSL), etc.) and/or wireless technology (infrared, microwave, etc.) to access websites, Wired and/or wireless technologies are included within the definition of transmission medium when sent from a server or other remote source.

<Information, signal>
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. that may be referred to throughout the above description may refer to voltages, currents, electromagnetic waves, magnetic fields or magnetic particles, light fields or photons, or any of these. may be represented by a combination of

The terms explained in this disclosure and terms necessary for understanding this disclosure may be replaced with terms having the same or similar meanings. For example, the channel and/or symbols may be signaling. A signal may also be a message. A component carrier (CC) may also be referred to as a carrier frequency, cell, frequency carrier, or the like.

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

<Name of parameter and channel>
In addition, the information, parameters, etc. described in the present disclosure may be expressed using absolute values, may be expressed using relative values from a predetermined value, or may be expressed using other corresponding information. may be represented. For example, radio resources may be indexed.

The names used for the parameters described above are not restrictive names in any respect. Further, the formulas, etc., using these parameters may differ from those expressly disclosed in this disclosure. Since the various channels (e.g., PUCCH, PDCCH, etc.) and information elements can be identified by any suitable names, the various names assigned to these various channels and information elements are in no way restrictive names. isn't it.

<Base station>
In the present disclosure, "base station (BS)", "radio base station", "fixed station", "NodeB", "eNodeB (eNB)", "gNodeB (gNB)", ""accesspoint","transmissionpoint","receptionpoint","transmission/receptionpoint","cell","sector","cellgroup"," Terms such as "carrier", "component carrier" may be used interchangeably. A base station may also be referred to by terms such as macrocell, small cell, femtocell, picocell, and the like.

A base station can accommodate one or more (eg, three) cells. When a base station serves multiple cells, the overall coverage area of the base station can be partitioned into multiple smaller areas, each smaller area being a base station subsystem (e.g., an indoor small base station (RRH: The term "cell" or "sector" refers to part or all of the coverage area of at least one of the base stations and base station subsystems serving communication services in this coverage. point to

<Mobile station>
In this disclosure, terms such as “Mobile Station (MS),” “user terminal,” “User Equipment (UE),” “terminal,” etc. may be used interchangeably. .

A mobile station is defined by those skilled in the art as 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 It may also be called a terminal, remote terminal, handset, user agent, mobile client, client, or some other suitable term.

<Base station/mobile station>
At least one of a base station and a mobile station may be called a transmitter, a receiver, a communication device, and the like. At least one of the base station and the mobile station may be a device mounted on a mobile object, the mobile object itself, or the like. The moving body refers to a movable object, and the movement speed is arbitrary. Naturally, it also includes the case where the moving body is stopped. The mobile body includes, for example, a vehicle, a transport vehicle, an automobile, a motorcycle, a bicycle, a connected car, an excavator, a bulldozer, a wheel loader, a dump truck, a forklift, a train, a bus, a cart, a rickshaw, and a ship (ship and other watercraft). , airplanes, rockets, satellites, drones, multi-copters, quad-copters, balloons, and any objects aboard them. Further, the mobile object may be a mobile object that autonomously travels based on an operation command. It may be a vehicle (e.g., car, airplane, etc.), an unmanned moving body (e.g., drone, self-driving car, etc.), or a robot (manned or unmanned). good. Note that at least one of the base station and the mobile station includes devices that do 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.

Also, the base station in the present disclosure may be read as a terminal. For example, regarding a configuration in which communication between a base station and a terminal is replaced with communication between a plurality of terminals (for example, D2D (Device-to-Device), V2X (Vehicle-to-Everything), etc.) , the embodiments of the present disclosure may be applied. In this case, the terminal 20 may have the functions of the base station 10 described above. Also, words such as "up" and "down" may be replaced with words corresponding to inter-terminal communication (for example, "side"). For example, uplink channels, downlink channels, etc. may be read as side channels.

Similarly, a terminal in the present disclosure may be read as a base station. In this case, the base station 10 may have the functions of the terminal 20 described above.

A configuration example of the vehicle 2001 is shown in FIG. As shown in FIG. 20, a 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 vehicle 2001, and may be applied to communication module 2013, for example.

The driving unit 2002 is configured by, for example, an engine, a motor, or a hybrid of the engine and the motor. The steering unit 2003 includes at least a steering wheel (also referred to as steering wheel), 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.

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

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

The information service unit 2012 includes various devices such as car navigation systems, audio systems, speakers, televisions, and radios for providing various types of information such as driving information, traffic information, and entertainment information, and one or more devices for controlling these devices. ECU. The information service unit 2012 uses information acquired from an external device via the communication module 2013 or the like to provide passengers of the vehicle 2001 with various multimedia information and multimedia services.

Driving support system unit 2030 includes millimeter wave radar, LiDAR (Light Detection and Ranging), camera, positioning locator (e.g., GNSS, etc.), map information (e.g., high-definition (HD) map, automatic driving vehicle (AV) map, etc. ), gyro systems (e.g., IMU (Inertial Measurement Unit), INS (Inertial Navigation System), etc.), AI (Artificial Intelligence) chips, AI processors, etc., to prevent accidents and reduce the driver's driving load. and one or more ECUs for controlling these devices. In addition, the driving support system unit 2030 transmits and receives various information via the communication module 2013, and realizes a driving support function or an automatic driving function.

The communication module 2013 can communicate with the microprocessor 2031 and components of the vehicle 2001 via communication ports. For example, the communication module 2013 communicates with the vehicle 2001 through the communication port 2033, the drive unit 2002, the steering unit 2003, the accelerator pedal 2004, the brake pedal 2005, the shift lever 2006, the front wheels 2007, the rear wheels 2008, the axle 2009, the electronic Data is transmitted and received between the microprocessor 2031 and memory (ROM, RAM) 2032 in the control unit 2010 and the sensors 2021-29.

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 an external device via wireless communication. Communication module 2013 may be internal or external to electronic control unit 2010 . The external device may be, for example, a base station, a mobile station, or the like.

The communication module 2013 transmits the current signal from the current sensor input to the electronic control unit 2010 to an external device via wireless communication. In addition, the communication module 2013 receives the rotation speed signal of the front and rear wheels obtained by the rotation speed sensor 2022, the air pressure signal of the front and rear wheels obtained by the air pressure sensor 2023, and the 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, and a shift lever. A shift lever operation signal obtained by the sensor 2027 and a detection signal for detecting obstacles, vehicles, pedestrians, etc. obtained by the object detection sensor 2028 are also transmitted to an external device via wireless communication.

The communication module 2013 receives various information (traffic information, signal information, inter-vehicle information, etc.) transmitted from external devices, and displays it on the information service unit 2012 provided in the vehicle 2001 . Communication module 2013 also stores various information received from external devices in memory 2032 available to microprocessor 2031 . Based on the information stored in the memory 2032, the microprocessor 2031 controls the drive unit 2002, the steering unit 2003, the accelerator pedal 2004, the brake pedal 2005, the shift lever 2006, the front wheels 2007, the rear wheels 2008, and the axle 2009 provided in the vehicle 2001. , sensors 2021 to 2029 and the like may be controlled.

<Meaning and Interpretation of Terms>
As used in this disclosure, the terms "determining" and "determining" may encompass a wide variety of actions. "Judgement", "determining" are, for example, judging, calculating, computing, processing, deriving, investigating, looking up, searching, inquiring (eg, lookup in a table, database, or other data structure), ascertaining as "judged" or "determined", and the like. Also, “judgment” and “decision” are used for receiving (e.g., receiving information), transmitting (e.g., transmitting information), input, output, access (accessing) (for example, accessing data in memory) may include deeming that something has been "determined" or "decided". In addition, "judgment" and "decision" are considered to be "judgment" and "decision" by resolving, selecting, choosing, establishing, comparing, etc. can contain. In other words, "judgment" and "decision" may include considering that some action is "judgment" and "decision". Also, "judgment (decision)" may be read as "assuming", "expecting", "considering", or the like.

The terms "connected", "coupled", or any variation thereof, mean any direct or indirect connection or coupling between two or more elements, It can include the presence of one or more intermediate elements between two elements being "connected" or "coupled." Couplings or connections between elements may be physical, logical, or a combination thereof. For example, "connection" may be read as "access". As used in this disclosure, two elements are defined using at least one of one or more wires, cables, and printed electrical connections and, as some non-limiting and non-exhaustive examples, in the radio frequency domain. , electromagnetic energy having wavelengths in the microwave and optical (both visible and invisible) regions, and the like.

<Reference signal>
The reference signal may be abbreviated as RS (Reference Signal), or may be referred to as Pilot according to the applicable standard.

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

<“First”, “Second”>
Any reference to elements using the "first,""second," etc. designations 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, reference to a first and second element does not imply that only two elements can be employed or that the first element must precede the second element in any way.

<Means>
The “means” in the configuration of each device described above may be replaced with “unit”, “circuit”, “device”, or the like.

<Open format>
Where "include,""including," and variations thereof are used in this disclosure, these terms are inclusive, as is the term "comprising." is intended. Furthermore, the term "or" as used in this disclosure is not intended to be an exclusive OR.

<Time unit such as TTI, frequency unit such as RB, radio frame configuration>
A radio frame may consist of one or more frames in the time domain. Each frame or frames in the time domain may be referred to as a subframe. A subframe may also consist of one or more slots in the time domain. A subframe may be a fixed time length (eg, 1 ms) independent of numerology.

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

A slot may consist of one or more symbols (OFDM (Orthogonal Frequency Division Multiplexing) symbol, SC-FDMA (Single Carrier Frequency Division Multiple Access) symbol, etc.) in the time domain. A slot may be a unit of time based on numerology.

A slot may contain multiple mini-slots. Each minislot may consist of one or more symbols in the time domain. A minislot may also be referred to as a subslot. A minislot may consist of fewer symbols than a slot. PDSCH (or PUSCH) transmitted in time units larger than minislots may be referred to as PDSCH (or PUSCH) mapping type A. PDSCH (or PUSCH) transmitted using minislots may be referred to as PDSCH (or PUSCH) mapping type B.

Radio frames, subframes, slots, minislots and symbols all represent time units when transmitting signals. Radio frames, subframes, slots, minislots and symbols may be referred to by other corresponding designations.

For example, one subframe may be called a Transmission Time Interval (TTI), multiple consecutive subframes may be called a TTI, and one slot or minislot may be called a TTI. may That is, at least one of the subframe and TTI may be a subframe (1 ms) in existing LTE, a period shorter than 1 ms (eg, 1-13 symbols), or a period longer than 1 ms may be Note that the unit representing the TTI may be called a slot, mini-slot, or the like instead of a subframe.

Here, TTI refers to, for example, the minimum scheduling time unit in wireless communication. For example, in the LTE system, a base station performs scheduling to allocate radio resources (frequency bandwidth, transmission power, etc. that can be used by each user terminal) to each user terminal on a TTI basis. Note that the definition of TTI is not limited to this.

A TTI may be a transmission time unit such as a channel-encoded data packet (transport block), code block, or codeword, or may be a processing unit such as scheduling and link adaptation. Note that when a TTI is given, the time interval (for example, the number of symbols) in which transport blocks, code blocks, codewords, etc. are actually mapped may be shorter than the TTI.

When one slot or one minislot is called a TTI, one or more TTIs (that is, one or more slots or one or more minislots) may be the minimum scheduling time unit. Also, the number of slots (the number of mini-slots) constituting the minimum time unit of the scheduling may be controlled.

A TTI having a time length of 1 ms may be called a normal TTI (TTI in LTE Rel. 8-12), normal TTI, long TTI, normal subframe, normal subframe, long subframe, slot, or the like. A TTI that is shorter than a regular TTI may also be called a shortened TTI, a short TTI, a partial or fractional TTI, a shortened subframe, a short subframe, a minislot, a subslot, a slot, and so on.

Note that the long TTI (e.g., normal TTI, subframe, etc.) may be replaced with a TTI having a time length exceeding 1 ms, and the short TTI (e.g., shortened TTI, etc.) is less than the TTI length of the long TTI and 1 ms A TTI having the above TTI length may be read instead.

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 the RB may be the same regardless of the neumerology, eg twelve. The number of subcarriers included in an RB may be determined based on neumerology.

Also, the time domain of an RB may include one or more symbols and may be 1 slot, 1 minislot, 1 subframe, or 1 TTI long. One TTI, one subframe, etc. may each consist of one or more resource blocks.

One or more RBs are physical resource blocks (PRBs), sub-carrier groups (SCGs), resource element groups (REGs), PRB pairs, RB pairs, etc. may be called.

Also, a resource block may be composed of one or more resource elements (RE: Resource Element). For example, 1 RE may be a radio resource region of 1 subcarrier and 1 symbol.

A Bandwidth Part (BWP) (which may also be referred to as a partial bandwidth, etc.) may represent a subset of contiguous common resource blocks (RBs) for a numerology on a carrier. good. Here, the common RB may be identified by an RB index based on the common reference point of the carrier. PRBs may be defined in a BWP and numbered within that BWP.

The BWP may include a BWP for UL (UL BWP) and a BWP for DL (DL BWP). One or multiple BWPs may be configured for a UE within one carrier.

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 "cell", "carrier", etc. in the present disclosure may be read as "BWP".

The above structures such as radio frames, subframes, slots, minislots and symbols are only examples. For example, the number of subframes contained in a radio frame, the number of slots per subframe or radio frame, the number of minislots contained within a slot, the number of symbols and RBs contained in a slot or minislot, the number of Configurations such as the number of subcarriers and the number of symbols in a TTI, symbol length, cyclic prefix (CP) length, etc. can be varied.

<Maximum transmission power>
“Maximum transmit power” as described in this disclosure may mean the maximum value of transmit power, may mean the nominal UE maximum transmit power, or may refer to the rated maximum transmit power ( the rated UE maximum transmit power).

<article>
In this disclosure, where articles have been added by translation, such as a, an, and the in English, the disclosure may include the plural nouns following these articles.

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

One aspect of the present disclosure is useful for wireless communication systems.

10 base station 20

terminal

101, 202

transmitter

102, 201

receiver

103, 203 controller

Claims

A control for controlling transmission of acknowledgments based on at least one of a retransmission method of switching cells and retransmitting signals, and use of an acknowledgment format including acknowledgments in each of the cells, which is permitted. Department and
a transmitting unit that transmits the acknowledgment under the control of the control unit;
terminal with
both the retransmission scheme and the use of the acknowledgment format are allowed;
A terminal according to claim 1 .
The control unit
When retransmission of a signal transmitted in a first cell is performed in a second cell, an acknowledgment indicating a reception result of the signal retransmitted in the second cell, in the acknowledgment format, placed at a position associated with the first cell;
A terminal according to claim 2.
The control unit
When retransmission of a signal transmitted in a first cell is performed in a second cell, an acknowledgment indicating a reception result of the signal retransmitted in the second cell, in the acknowledgment format, placed at a position associated with the second cell;
A terminal according to claim 2.
In the retransmission scheme, the control unit uses the same HARQ process as the first signal in the first cell after transmission of a first acknowledgment for the first signal received in the first cell. controlling reception of the second signal;
wherein the first signal is a retransmission of a third signal transmitted in a second cell;
A terminal according to claim 1 .
the terminal
controlling the transmission of acknowledgments based on at least one of a retransmission scheme for switching cells to retransmit signals and the use of an acknowledgment format including acknowledgments in each of said cells allowed;
sending said acknowledgment;
Communication method.