PUSCH transmission in multi-dci based multi-trp

Abstract

Methods and devices are disclosed for PUSCH transmission in multi-DCI based multi-TRP. A remote unit includes a receiver and a transmitter, the receiver receives a configuration, where the configuration indicates that two SRS resource sets are configured with either 'codebook' or 'non-codebook' usage, where each SRS resource set is associated with a different CORESETPoolIndex value, and the receiver further receives a DCI scheduling a PUSCH transmission, where the DCI includes an SRI field; and the transmitter transmits the PUSCH transmission according to either an SRS resource of the SRS resource set for codebook-based PUSCH transmission or a subset of SRS resources in the SRS resource set for non-codebook-based PUSCH transmission, where the SRS resource or the subset of SRS resources is indicated by the SRI field in the DCI, and where the SRS resource sets are associated with CORESETPoolIndex values according to the DCI.

Description

Technical Field

[0001] The subject matter disclosed herein generally relates to wireless communication, and more specifically to methods and apparatus for PUSCH transmission in multi-DCI-based multi-TRP. Background Technology

[0002] The following abbreviations are defined herein, and at least some of them are mentioned in the following descriptions: New Radio (NR), Very Large Scale Integration (VLSI), Random Access Memory (RAM), Read-Only Memory (ROM), Erasable Programmable Read-Only Memory (EPROM or Flash Memory), Optical Disc Read-Only Memory (CD-ROM), Local Area Network (LAN), Wide Area Network (WAN), User Equipment (UE), Evolved Node B (eNB), Next Generation Node B(gNB), Uplink (UL), Downlink (DL), Central Processing Unit (CPU), Graphics Processing Unit (GPU), Field Programmable Gate Array (FPGA), Orthogonal Frequency Division Multiplexing (OFDM), Radio Resource Control (RRC), User Entity / Equipment (Mobile Terminal) (UE), Physical Downlink Shared Channel (PDSCH), Physical Uplink Shared Channel (PUSCH), Physical Uplink Control Channel (PUCCH), Downlink Control Information (DCI), Channel State Information Reference Signal (CSI-RS), Sounding Reference Signal (SRS), Control Resource Set (CORESET), SRS Resource Indicator (SRI), Transmit and Receive Point (TRP), Most Significant Bit (MSB), Least Significant Bit (LSB).

[0003] There are two transmission schemes for PUSCH transmission: codebook-based PUSCH transmission and non-codebook-based PUSCH transmission.

[0004] For codebook-based PUSCH transmissions, the UE can be configured with a single SRS resource set consisting of one or more SRS resources, where usage is set to 'codebook'. Based on the SRI field in the DCI that schedules codebook-based PUSCH transmissions, only one SRS resource is indicated from the single SRS resource set. Additionally, the UE can be configured with a single power control list (e.g., an SRI-PUSCH-PowerControl list) consisting of one or more power control parameter sets. By mapping the SRI values ​​of the SRI field to the single power control list, only one power control parameter set is indicated by the SRI field in the DCI. In other words, the SRI field in the DCI indicates both an SRS resource and a power control parameter set used for codebook-based PUSCH transmissions.

[0005] For non-codebook-based PUSCH transmissions, the UE should use one or more SRS resources for SRS transmissions, with a maximum of four configurable SRS resources. One or more SRS resources (which may be referred to as a "subset of SRS resources") can be indicated based on the SRI field in the DCI used to schedule non-codebook-based PUSCH transmissions. Additionally, the UE can be configured with a single power control list consisting of one or more sets of power control parameters. A power control parameter set is indicated by the SRI field in the DCI by mapping the SRI values ​​of the SRI field to the single power control list. In other words, the SRI field in the DCI indicates both a subset of SRS resources (i.e., one or more SRS resources) and a set of power control parameters used for non-codebook-based PUSCH transmissions.

[0006] In general, only one SRS resource set is configured for both codebook-based and non-codebook-based PUSCH transmissions. The SRI field in the DCI that schedules the PUSCH transmission indicates the SRS resources in the SRS resource set (and its corresponding power control parameter set) used for codebook-based PUSCH transmissions, or indicates a subset (one or more) of the SRS resources in the SRS resource set (and its corresponding power control parameter set) used for non-codebook-based PUSCH transmissions.

[0007] Multi-TRP PUSCH transmission based on multiple DCI has been proposed. In a scenario with two TRPs (e.g., TRP0 and TRP1), when DCI schedules PUSCH transmission, DCI can be transmitted from one TRP (e.g., TRP0), while the PUSCH transmission scheduled by DCI can be transmitted to the same TRP (e.g., TRP0) or another TRP (e.g., TRP1). Considering that the UL beams of different TRPs are different, in a multi-TRP PUSCH transmission scenario based on multiple DCI, it is necessary to indicate the correct TX beam to the UE.

[0008] A higher-level parameter, CORESETPoolIndex, can be configured for each CORESET. This higher-level parameter identifies the set of time-frequency resources used for PUSCH transmission for TRP identification. For example, TRP0 can be associated with CORESETPoolIndex 0 (which can be expressed as "TRP0 is identified by CORESETPoolIndex 0"), and TRP1 can be associated with CORESETPoolIndex 1 (which can be expressed as "TRP1 is identified by CORESETPoolIndex 1"). DCI is transmitted from a CORESET, which has a CORESETPoolIndex that identifies the TRP from which the DCI is transmitted.

[0009] This invention discloses a method and apparatus for determining port and spatial relationship information and power of PUSCH transmission in a multi-DCI-based multi-TRP PUSCH transmission scenario. Summary of the Invention

[0010] Methods and apparatus for performing PUSCH transmission in multi-TRP based on multi-DCI are disclosed.

[0011] In one embodiment, the remote unit includes a receiver and a transmitter. The receiver receives a configuration indicating that two SRS resource sets are configured to use either a 'codebook' or a 'non-codebook', wherein each SRS resource set is associated with a different CORESETPoolIndex value. The receiver further receives a DCI for scheduling PUSCH transmissions, wherein the DCI includes an SRI field. The transmitter transmits PUSCH transmissions based on SRS resources in the SRS resource set used for codebook-based PUSCH transmissions or a subset of SRS resources in the SRS resource set used for non-codebook-based PUSCH transmissions, wherein the SRS resources or subsets of SRS resources are indicated by the SRI field in the DCI, and wherein the SRS resource set is associated with a CORESETPoolIndex value according to the DCI.

[0012] In one embodiment, different CORESETPoolIndex values ​​are configured for each SRS resource set in two SRS resource sets via RRC signaling. Alternatively, in two SRS resource sets configured to use a 'codebook', the SRS resource set with the lower index and the SRS resource set with the higher index are associated with CORESETPoolIndex 0 and CORESETPoolIndex 1, respectively; and in two SRS resource sets configured to use a 'non-codebook', the SRS resource set with the lower index and the SRS resource set with the higher index are associated with CORESETPoolIndex 0 and CORESETPoolIndex 1, respectively. Alternatively, in two SRS resource sets configured to use 'codebook', the SRS resource set with the lower index and the SRS resource set with the higher index are associated with CORESETPoolIndex 1 and CORESETPoolIndex 0, respectively; and in two SRS resource sets configured to use 'non-codebook', the SRS resource set with the lower index and the SRS resource set with the higher index are associated with CORESETPoolIndex 1 and CORESETPoolIndex 0, respectively.

[0013] In another embodiment, the configuration further indicates two SRI-PUSCH-PowerControl lists, each of which is associated with a different CORESETPoolIndex value, and the transmitter further transmits PUSCH transmissions according to a set of power control parameters of the SRI-PUSCH-PowerControl lists, wherein the SRI-PUSCH-PowerControl lists are also associated with CORESETPoolIndex values ​​according to DCI.

[0014] In some embodiments, the CORESETPoolIndex value associated with the SRS resource set is the CORESETPoolIndex value of the CORESET transmitting the DCI. In this case, the SRS resources of the SRS resource set used for codebook-based PUSCH transmission or a subset of the SRS resources of the SRS resource set used for non-codebook-based PUSCH transmission are indicated by all bits in the SRI field of the DCI; and the power control parameter set is determined by mapping the SRI value indicated by all bits in the SRI field of the DCI to the SRI-PUSCH-PowerControl list associated with the CORESETPoolIndex value.

[0015] In some embodiments, the CORESETPoolIndex value associated with the SRS resource set is indicated by a single bit of the SRI field in the DCI. In this case, the SRS resources of the SRS resource set used for codebook-based PUSCH transmissions or a subset of the SRS resources of the SRS resource set used for non-codebook-based PUSCH transmissions are indicated by all bits except one bit of the SRI field in the DCI, and the power control parameter set is determined by mapping the SRI value indicated by all bits except one bit of the SRI field in the DCI to the SRI-PUSCH-PowerControl list associated with the CORESETPoolIndex value. Preferably, the single bit is the MSB of the SRI field.

[0016] In another embodiment, a method includes receiving a configuration indicating that two SRS resource sets are configured to use either a 'codebook' or a 'non-codebook', wherein each SRS resource set is associated with a different CORESETPoolIndex value; receiving a DCI for scheduling PUSCH transmissions, wherein the DCI includes an SRI field; and transmitting PUSCH transmissions based on SRS resources in the SRS resource set for codebook-based PUSCH transmissions or a subset of SRS resources in the SRS resource set for non-codebook-based PUSCH transmissions, wherein the SRS resources or subsets of SRS resources are indicated by the SRI field in the DCI, and wherein the SRS resource set is associated with a CORESETPoolIndex value according to the DCI.

[0017] In one embodiment, the basic unit includes a transmitter and a receiver. The transmitter transmits a configuration indicating that two SRS resource sets are configured to use either a 'codebook' or a 'non-codebook', wherein each SRS resource set is associated with a different CORESETPoolIndex value, and the transmitter further transmits a DCI for scheduling PUSCH transmissions, wherein the DCI includes an SRI field. The receiver receives PUSCH transmissions based on SRS resources in the SRS resource set used for codebook-based PUSCH transmissions or a subset of SRS resources in the SRS resource set used for non-codebook-based PUSCH transmissions, wherein the SRS resources or subsets of SRS resources are indicated by the SRI field in the DCI, and wherein the SRS resource set is associated with a CORESETPoolIndex value according to the DCI.

[0018] In yet another embodiment, a method includes a transport configuration, wherein the configuration indicates the configuration of two SRS resource sets using either a 'codebook' or a 'non-codebook', wherein each SRS resource set is associated with a different CORESETPoolIndex value; a transport scheduling DCI for PUSCH transports, wherein the DCI includes an SRI field; and receiving PUSCH transports based on SRS resources in the SRS resource set used for codebook-based PUSCH transports or a subset of SRS resources in the SRS resource set used for non-codebook-based PUSCH transports, wherein the SRS resources or subsets of SRS resources are indicated by the SRI field in the DCI, and wherein the SRS resource set is associated with a CORESETPoolIndex value according to the DCI. Attached Figure Description

[0019] A more detailed description of the embodiments briefly described above will be presented by referring to the specific embodiments illustrated in the accompanying drawings. It should be understood that these drawings depict only some embodiments and are therefore not intended to be limiting; the embodiments will be described and illustrated with additional features and details using the drawings, wherein:

[0020] Figure 1 This describes an example of multi-DCI-based multi-TRP PUSCH transmission according to the first embodiment;

[0021] Figure 2 This describes an example of multi-DCI-based multi-TRP PUSCH transmission according to the second embodiment;

[0022] Figure 3 This is a schematic flowchart illustrating an embodiment of the method;

[0023] Figure 4 This is a schematic flowchart illustrating another embodiment of the method; and

[0024] Figure 5 This is a schematic block diagram illustrating a device according to one embodiment. Detailed Implementation

[0025] As those skilled in the art will understand, certain aspects of the embodiments may be embodied as a system, device, method, or program product. Therefore, embodiments may take the form of a completely hardware embodiment, a completely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, which are generally referred to herein as “circuit,” “module,” or “system.” Furthermore, embodiments may take the form of a program product embodied in one or more computer-readable storage devices that store machine-readable code, computer-readable code, and / or program code, hereinafter referred to as “code.” The storage device may be tangible, non-transitory, and / or non-transferable. The storage device may not embody signals. In certain embodiments, the storage device uses only signals to access the code.

[0026] Certain functional units described in this specification may be designated as “modules” to more specifically emphasize their independent implementation. For example, a module may be implemented as hardware circuitry, including custom-designed very large-scale integration (VLSI) circuitry or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. Modules may also be implemented in programmable hardware devices such as field-programmable gate arrays, programmable array logic, programmable logic devices, etc.

[0027] Modules can also be implemented in code and / or software for execution by various types of processors. For example, the identified code module may include one or more physical or logical blocks of executable code, which may be organized, for example, as objects, procedures, or functions. However, the executable programs of the identified modules do not need to be physically located together, but may include different instructions stored in different locations that, when logically combined, comprise the module and achieve the module's stated purpose.

[0028] In practice, a code module may comprise a single instruction or many instructions, and may even be distributed across several different code segments, different programs, and several memory devices. Similarly, operational data may be identified and described within the module herein, and may be represented in any suitable form and organized within any suitable type of data structure. This operational data may be collected as a single dataset or may be distributed across different locations, including across different computer-readable storage devices. In the case of a module or a portion thereof being implemented in software, the software portion is stored on one or more computer-readable storage devices.

[0029] Any combination of one or more computer-readable media may be used. A computer-readable medium may be a computer-readable storage medium. A computer-readable storage medium may be a storage device for storing code. A storage device may be, for example (but not necessarily), an electronic, magnetic, optical, electromagnetic, infrared, holographic, microelectromechanical, or semiconductor system, device, or apparatus, or any suitable combination of the foregoing.

[0030] A non-exhaustive list of more specific examples of storage devices will include the following: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable optical disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium can be any tangible medium that can contain or store programs for use by or in conjunction with an instruction execution system, device, or apparatus.

[0031] The code used to perform the operations of the embodiments may include any number of lines and may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Python, Ruby, Java, Smalltalk, C++, and conventional procedural programming languages ​​such as the "C" programming language, and / or machine languages ​​such as assembly language. The code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0032] References to “an embodiment,” “embodiment,” or similar language throughout this specification mean that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment. Therefore, unless otherwise expressly stated, the phrases “in an embodiment,” “in an embodiment,” and similar language appearing throughout this specification do not necessarily refer to the same embodiment, but rather to “one or more, but not all, embodiments.” Unless otherwise expressly stated, the terms “comprising,” “including,” “having,” and variations thereof mean “including, but not limited to,” “including ...

[0033] Furthermore, the features, structures, or characteristics described in the various embodiments can be combined in any suitable manner. In the following description, numerous specific details are provided as examples of programming, software modules, user selection, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of the embodiments. However, those skilled in the art will recognize that the embodiments can be practiced without one or more of these specific details or using other methods, components, materials, etc. In other instances, well-known structures, materials, or operations have not been shown or described in detail to avoid obscuring aspects of the embodiments.

[0034] The following description of various embodiments is based on schematic flowcharts and / or schematic block diagrams of methods, apparatus, systems, and program products according to embodiments. It will be understood that each block in the schematic flowcharts and / or schematic block diagrams, and combinations of blocks in the schematic flowcharts and / or schematic block diagrams, can be implemented by code. This code can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine, such that instructions executable via the processor of the computer or other programmable data processing apparatus create means for implementing the functions specified in one or more blocks of the schematic flowcharts and / or schematic block diagrams.

[0035] The code may also be stored in a storage device that can instruct a computer, other programmable data processing device or other means to operate in a particular manner, such that the instructions stored in the storage device produce an article of art including instructions that perform the functions specified in one or more schematic flowcharts and / or schematic block diagrams.

[0036] Code can also be loaded onto a computer, other programmable data processing apparatus or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer-implemented process, so that the code executing on the computer or other programmable device provides a process for implementing the function specified in one or more flowchart and / or block diagram boxes.

[0037] The schematic flowcharts and / or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, systems, methods, and program products according to various embodiments. In this regard, each block in the schematic flowcharts and / or block diagrams may represent a module, segment, or portion of code, which includes one or more executable instructions for implementing a specified logical function.

[0038] It should also be noted that in some alternative implementations, the functions marked in the boxes may not occur in the order indicated in the figures. For example, depending on the functions involved, two boxes shown consecutively may be executed substantially simultaneously, or these boxes may sometimes be executed in reverse order. Other steps and methods that are functionally, logically, or effectively equivalent to one or more boxes or portions thereof in the illustrated figures are conceivable.

[0039] While various arrow and line types may be used in flowcharts and / or block diagrams, they are not intended to limit the scope of the corresponding embodiments. In practice, some arrows or other connectors may be used to indicate only the logical flow of the depicted embodiment. For example, an arrow may indicate a wait or monitoring period of unspecified duration between enumerated steps of a depicted embodiment. It should also be noted that each box in the block diagram and / or flowchart, and combinations of boxes in the block diagram and / or flowchart, may be implemented by a system based on dedicated hardware, or a combination of dedicated hardware and code, performing the specified function or action.

[0040] The description of elements in each figure may refer to elements in previous figures. In all figures, similar numerals refer to similar elements, including alternative embodiments of similar elements.

[0041] In NR version 16, two TRPs are supported. Therefore, the invention is discussed using the example of two TRPs, although the invention is not limited to two TRPs for scenarios based on multi-DCI multi-TRP PUSCH transmission.

[0042] Since the UL beam and path loss to different TRPs are different, a single SRS resource set should be enhanced for either codebook-based PUSCH transmission or non-codebook-based PUSCH transmission configuration.

[0043] In the example of two TRPs (e.g., TRP0 and TRP1), a DCI from a CORESET transfer having a CORESETPoolIndex value that identifies one TRP (e.g., TRP0) (which may be referred to as "DCI from one TRP") can be scheduled to a PUSCH transfer to the same TRP (e.g., TRP0) or another TRP (e.g., TRP1).

[0044] The first embodiment relates to a scenario where a DCI from a TRP can be scheduled to be transmitted to a PUSCH transmission within the same TRP.

[0045] Each TRP is identified by a CORESETPoolIndex value. According to the first embodiment, PUSCH transmissions are always transmitted to the TRP identified by the CORESETPoolIndex value, which is associated with the TRP from which the PUSCH transmission is scheduled. In other words, a PUSCH transmission is associated with a CORESETPoolIndex value that is the same as the CORESETPoolIndex value associated with the TRP from which the DCI is scheduled.

[0046] A path loss reference RS is configured for SRS resource sets that use either a 'codebook' or 'non-codebook' approach. However, the path loss between different TRPs and the UE varies. Therefore, in a multi-DCI-based PUSCH transmission scenario, each TRP is configured with one SRS resource set using either a 'codebook' or 'non-codebook' approach. When two TRPs exist, two SRS resource sets are configured with either a 'codebook' or 'non-codebook' approach, each SRS resource set being associated with a different CORESETPoolIndex value associated with one of the two TRPs.

[0047] To reuse the traditional DCI format as much as possible, the bit width of the SRI field in the DCI used for scheduling PUSCH transmissions remains the same as in the traditional DCI format. Therefore, an association should be established between the SRS resource set configured to use either 'codebook' or 'non-codebook' and the TRP to ensure the UE correctly interprets the SRI field. This association can be established by explicitly or implicitly associating each SRS resource set with a different CORESETPoolIndex value.

[0048] Option 1 is an explicit method. Each SRS resource set configured to use either 'codebook' or 'non-codebook' can be configured with a CORESETPoolIndex value via RRC signaling. Therefore, each SRS resource set configured to use either 'codebook' or 'non-codebook' is associated with a CORESETPoolIndex value. The RRC signaling for an SRS resource set in TS 38.331 can be updated as follows:

[0049]

[0050] In other words, a CORESETPoolIndex that can be configured to be 0 or 1 is added to the updated RRC signaling.

[0051] Option 2 is an implicit method of association. In two SRS resource sets, the SRS resource set with the lower ID configured to use a 'codebook' and the SRS resource set with the higher ID configured to use a 'codebook' are associated with CORESETPoolIndex 0 and CORESETPoolIndex 1, respectively. Similarly, in two SRS resource sets, the SRS resource set with the lower ID configured to use a 'non-codebook' and the SRS resource set with the higher ID configured to use a 'non-codebook' are associated with CORESETPoolIndex 0 and CORESETPoolIndex 1, respectively. In Option 2, the network (gNB) should ensure that, through implementation, the SRS resource set with the lower ID is associated with CORESETPoolIndex 0, and the SRS resource set with the higher ID is associated with CORESETPoolIndex 1.

[0052] Option 3 is another implicit approach. In two SRS resource sets, the SRS resource set with the lower ID configured to use a 'codebook' and the SRS resource set with the higher ID configured to use a 'codebook' are associated with CORESETPoolIndex 1 and CORESETPoolIndex 0, respectively. Similarly, in two SRS resource sets, the SRS resource set with the lower ID configured to use a 'non-codebook' and the SRS resource set with the higher ID configured to use a 'non-codebook' are associated with CORESETPoolIndex 1 and CORESETPoolIndex 0, respectively. In Option 3, the gNB should ensure that, through implementation, the SRS resource set with the higher ID is associated with CORESETPoolIndex 0, and the SRS resource set with the lower ID is associated with CORESETPoolIndex 1.

[0053] Additionally, the power control parameters for PUSCH transmission are also determined by the SRI field in the DCI by mapping the SRI value of the SRI field to the SRI-PUSCH-PowerControl list. Since the interpretation of the SRI field is based on the CORESETPoolIndex value associated with the DCI, in a two-TRP scenario, two SRI-PUSCH-PowerControl lists are configured via RRC signaling, with each SRI-PUSCH-PowerControl list associated with a different CORESETPoolIndex value. For example, the RRC signaling in TS 38.331 can be updated as follows:

[0054]

[0055] In the updated RRC signaling above, the list named SRS-PUSCH-PowerControl is associated with CORESETPoolIndex 0, and the list named SRS-PUSCH-PowerControl-r17 is associated with CORESETPoolIndex 1.

[0056] Each of SRS-PUSCH-PowerControl and SRS-PUSCH-PowerControl-r17 consists of one or more SRI-PUSCH-PowerControl IDs that can be renamed to a power control parameter set. When mapping SRI values ​​to a list of SRI-PUSCH-PowerControls, it indicates the power control parameter set with an ID equal to the SRI value.

[0057] According to the first embodiment, when the UE receives a UL DCI for scheduling PUSCH transmission, the UE interprets the SRI field in the DCI based on an SRS resource set. The SRS resource set is configured with either a 'codebook' or 'non-codebook' associated with the same CORESETPoolIndex value as the CORESET from which the UL DCI is received. That is, the SRI field in the DCI indicates the SRS resources of the SRS resource set associated with the same CORESETPoolIndex value. Spatial relationship information and ports for PUSCH transmission are determined based on the indicated SRS resources for codebook-based PUSCH transmission or a subset of SRS resources for non-codebook-based PUSCH transmission. Furthermore, a power control parameter set is indicated by mapping the SRI value of the SRI field to a SRI-PUSCH-PowerControl list associated with the same CORESETPoolIndex value as the CORESET from which the UL DCI is received. The indicated power control parameter set determines the power of the scheduled PUSCH transmission.

[0058] Figure 1An example of the first embodiment is illustrated. Two TRPs (TRP0 and TRP1) are shown. TRP0 is identified by CORESETPoolIndex 0 and TRP1 is identified by CORESETPoolIndex 1. Two SRS resource sets (SRS resource set 0 and SRS resource set 1) are configured to use 'codebook'. SRS resource set 0, consisting of SRS resources 0 and 1, is associated with CORESETPoolIndex 0. SRS resource set 1, consisting of SRS resources 2 and 3, is associated with CORESETPoolIndex 1. This association can be established according to option 2 above (the SRS resource set (SRS resource set 0) configured to use 'codebook' or 'non-codebook' with the lower ID is associated with CORESETPoolIndex 0, and the SRS resource set (SRS resource set 1) configured to use 'codebook' or 'non-codebook' with the higher ID is associated with CORESETPoolIndex 1). Additionally, two SRI-PUSCH-PowerControl lists (SRI-PUSCH-PowerControl list 0 and SRI-PUSCH-PowerControl list 1) are configured for PUSCH power control. SRI-PUSCH-PowerControl list 0, consisting of power control parameter sets 0 and 1, is associated with CORESETPoolIndex 0, and SRI-PUSCH-PowerControl list 1, consisting of power control parameter sets 2 and 3, is associated with CORESETPoolIndex 1.

[0059] A DCI (DCI 1) from TRP0 schedules a PUSCH transmission (PUSCH 1). DCI1 has an SRI field including a bit '0', indicating that the SRI value in DCI 1 is '0'. Another DCI (DCI 2) from TRP1 schedules another PUSCH transmission (PUSCH 2). DCI 2 has another SRI field including a bit '0', indicating that the SRI value in DCI 2 is also '0'. According to the first embodiment, SRS resource 0 in SRS resource set 0 (which is associated with CORESETPoolIndex 0, which is the same as the CORESETPoolIndex value of TRP0 from which the UE receives DCI 1) is indicated by the SRI value '0' in DCI 1 of PUSCH 1. SRS resource 2 in SRS resource set 1 (which is associated with CORESETPoolIndex 1, which is the same as the CORESETPoolIndex value of TRP1 that identifies the UE from which it receives DCI 2) is indicated by the SRI value '0' in DCI 2 of PUSCH 2.

[0060] Additionally, power control parameter set 0 is indicated by mapping the SRI value '0' in DCI 1 to the SRI-PUSCH-PowerControl list 0 of PUSCH 1 (which is associated with CORESETPoolIndex 0, which is the same as the CORESETPoolIndex value that identifies the TRP0 from which the UE receives DCI 1). Power control parameter set 2 is indicated by mapping the SRI value '0' in DCI 2 to the SRI-PUSCH-PowerControl list 1 of PUSCH 2 (which is associated with CORESETPoolIndex 1, which is the same as the CORESETPoolIndex value that identifies the TRP1 from which the UE receives DCI 2).

[0061] In general, PUSCH 1 is transmitted to TRP0 using the port and spatial relationship information of SRS resource 0 and the power determined by power control parameter set 0. PUSCH 2 is transmitted to TRP1 using the port and spatial relationship information of SRS resource 2 and the power determined by power control parameter set 2.

[0062] In codebook-based PUSCH transmission Figure 1In the example, the SRI field in DCI has a bit width of one bit, the same as the traditional DCI format. For non-codebook-based PUSCH transmissions, the SRI field in DCI also has the same bit width as the traditional DCI format; however, the bit width of the SRI field in DCI depends on the number of configured SRS resources and the maximum number of UL transport layers.

[0063] The second embodiment relates to a situation where a DCI from a TRP can be scheduled to a PUSCH transmission to the same TRP or another TRP.

[0064] According to the second embodiment, PUSCH transmissions are not always transmitted to the same TRP from which the UE receives the DCI that schedules the PUSCH transmission. In other words, in an example with two TRPs (e.g., TRP0 and TRP1), a DCI transmitted from TRP0 can schedule a PUSCH transmission to either TRP0 or TRP1. Therefore, the DCI that schedules the PUSCH transmission should indicate which TRP (TRP0 or TRP1) the scheduled PUSCH transmission is transmitted to.

[0065] Similar to the first embodiment, in the second embodiment, an association is established between the SRS resource set configured to use 'codebook' or 'non-codebook' and the TRP so that the UE can correctly interpret the SRI field.

[0066] Associations can be established using the same options 1 to 3 described in the first embodiment.

[0067] Since the UE cannot know which TRP the scheduled PUSCH transmission is delivered to based on the CORESET (i.e., TRP) it receives from the scheduling DCI, the scheduling DCI needs to indicate to the UE which TRP the scheduled PUSCH transmission is delivered to. This is achieved by adding an extra bit to the scheduling DCI. In the example of two TRPs, only one extra bit is sufficient to indicate both TRPs. Because each SRS resource set is configured to use either a 'codebook' or 'non-codebook' and is associated with a CORESETPoolIndex value, an extra bit can be added to the SRI field of the scheduling DCI to indicate the associated CORESETPoolIndex value.

[0068] An extra bit can be added to any bit of the SRI field of the scheduling DCI. For example, the added bit can be the MSB (most significant bit) or LSB (least significant bit) of the SRI field of the scheduling DCI, while the remaining bits of the SRI field are the same as in the conventional DCI format. Preferably, the MSB of the SRI field of the scheduling DCI according to the second embodiment is the added bit.

[0069] Additionally, the power control parameters for scheduled PUSCH transmissions are also determined by the SRI field in the scheduling DCI. Added bits (preferably the MSB of the SRI field) are used to indicate the associated CORESETPoolIndex value. The remaining bits of the SRI field are mapped to a SRI-PUSCH-PowerControl list associated with the indicated CORESETPoolIndex value to indicate the set of power control parameters. Similar to the first embodiment, in a two-TRP scenario, two SRI-PUSCH-PowerControl lists are configured by RRC signaling, where each SRI-PUSCH-PowerControl list is associated with a different CORESETPoolIndex value. For example, similar to the updated RRC signaling in the first embodiment, a list named SRS-PUSCH-PowerControl is associated with CORESETPoolIndex 0, and a list named SRS-PUSCH-PowerControl-r17 is associated with CORESETPoolIndex 1. Each of SRS-PUSCH-PowerControl and SRS-PUSCH-PowerControl-r17 consists of one or more power control parameter sets. When the SRI value (the remaining bits in the SRI field excluding the extra bits) is mapped to the SRI-PUSCH-PowerControl list, it indicates the power control parameter set with an ID equal to the SRI value.

[0070] According to the second embodiment, when the UE receives the UL DCI for scheduling PUSCH transmissions, the UE interprets the bits added to the SRI field (e.g., the MSB of the SRI field) in the DCI to indicate the CORESETPoolIndex value of the TRP that identifies the PUSCH transmission scheduled to be transmitted to it. Additionally, the remaining bits of the SRI field (excluding the added bits) are interpreted according to the SRS resource set, which is configured with either a 'codebook' or 'non-codebook' associated with the same CORESETPoolIndex value indicated by the added bits. Spatial relationship information and ports for the scheduled PUSCH transmissions are determined based on the indicated SRS resources for codebook-based PUSCH transmissions or a subset of indicated SRS resources for non-codebook-based PUSCH transmissions. Furthermore, a power control parameter set is indicated by mapping the remaining bits of the SRI field (excluding the added bits) to a SRI-PUSCH-PowerControl list associated with the same CORESETPoolIndex value indicated by the added bits. The indicated set of power control parameters determines the power of the scheduled PUSCH transmission.

[0071] Figure 2 An example of the second embodiment is illustrated. Two TRPs (TRP0 and TRP1) are shown. TRP0 is identified by CORESETPoolIndex 0 and TRP1 is identified by CORESETPoolIndex 1. Two SRS resource sets (SRS resource set 0 and SRS resource set 1) are configured to use a 'codebook'. SRS resource set 0, consisting of SRS resources 0 and 1, is associated with CORESETPoolIndex 0. SRS resource set 1, consisting of SRS resources 2 and 3, is associated with CORESETPoolIndex 1. This association can be established according to option 1 above (SRS resource set 0 is explicitly configured to be associated with CORESETPoolIndex 0, and SRS resource set 1 is explicitly configured to be associated with CORESETPoolIndex 1). Additionally, two SRI-PUSCH-PowerControl lists (SRI-PUSCH-PowerControl list 0 and SRI-PUSCH-PowerControl list 1) are configured for PUSCH power control. SRI-PUSCH-PowerControl list 0, consisting of power control parameter sets 0 and 1, is associated with CORESETPoolIndex 0, and SRI-PUSCH-PowerControl list 1, consisting of power control parameter sets 2 and 3, is associated with CORESETPoolIndex 1.

[0072] A DCI (DCI 1) from TRP0 schedules a PUSCH transmission (PUSCH 1). DCI 1 has an SRI field including bits '11', where the MSB of the SRI value is '1' in DCI 1, indicating that PUSCH 1 is associated with CORESETPoolIndex 1. Another DCI (DCI 2) from TRP1 schedules another PUSCH transmission (PUSCH 2). DCI 2 has an SRI field including bits '00', where the MSB of the SRI value is '0' in DCI 2, indicating that PUSCH 2 is associated with CORESETPoolIndex 0. According to a second embodiment, SRS resource 3 in SRS resource set 1 (which is associated with CORESETPoolIndex 1, which is the same as the CORESETPoolIndex value indicated by the MSB of the SRI field in DCI 1) is indicated for PUSCH 1 by the remaining bits '1' of the SRI field in DCI 1. SRS resource 0 in SRS resource set 0 (which is associated with CORESETPoolIndex 0, which is the same as the CORESETPoolIndex value indicated by the MSB of the SRI field in DCI 2) is indicated for PUSCH 2 by the remaining bit '0' of the SRI field in DCI 2.

[0073] Additionally, SRI-PUSCH-PowerControl 3 is indicated to PUSCH 1 by mapping the remaining '1' bits of the SRI field in DCI 1 to SRI-PUSCH-PowerControl list 1 (which is associated with CORESETPoolIndex 1, the same as the CORESETPoolIndex value indicated by the MSB of the SRI field in DCI 1). SRI-PUSCH-PowerControl 0 is indicated to PUSCH 2 by mapping the remaining '0' bits of the SRI field in DCI 2 to SRI-PUSCH-PowerControl list 0 (which is associated with CORESETPoolIndex 0, the same as the CORESETPoolIndex value indicated by the MSB of the SRI field in DCI 2).

[0074] In general, PUSCH 1 is transmitted to TRP1 using the port and spatial relationship information of SRS resource 3 and the power determined by power control parameter set 3. PUSCH 2 is transmitted to TRP0 using the port and spatial relationship information of SRS resource 0 and the power determined by power control parameter set 0.

[0075] In codebook-based PUSCH transmission Figure 2 In the example, the SRI field in DCI is two bits wide, one bit wider than the traditional DCI format. For non-codebook-based PUSCH transmissions, the SRI field in DCI is also one bit wider than the traditional DCI format.

[0076] In both the first and second embodiments described by the examples of two TRPs, two SRS resource sets configured to use either 'codebook' or 'non-codebook' are configured to be associated with two different CORESETPoolIndex values. Additionally, two SRI-PUSCH-PowerControl lists are also configured to be associated with two different CORESETPoolIndex values. If three or more TRPs are supported, the same number of SRS resource sets and the same number of SRI-PUSCH-PowerControl lists as the number of supported TRPs can be configured to be associated with the same number of CORESETPoolIndex values.

[0077] Figure 3This is a schematic flowchart illustrating an embodiment of method 300 according to this application. In some embodiments, method 300 is performed by a device such as a remote unit. In some embodiments, method 300 may be performed by a processor executing program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc. Method 300 may include 302 receiving a configuration indicating that two SRS resource sets are configured to use 'codebook' or 'non-codebook', wherein each SRS resource set is associated with a different CORESETPoolIndex value; 304 receiving a DCI for scheduling PUSCH transmissions, wherein the DCI includes an SRI field; and 306 transmitting PUSCH transmissions according to SRS resources in the SRS resource set for codebook-based PUSCH transmissions or a subset of SRS resources in the SRS resource set for non-codebook-based PUSCH transmissions, wherein the SRS resources or subsets of SRS resources are indicated by the SRI field in the DCI, and wherein the SRS resource set is associated with a CORESETPoolIndex value according to the DCI. When the configuration in step 302 further indicates two SRI-PUSCH-PowerControl lists, each of which is associated with a different CORESETPoolIndex value, the PUSCH transfer in step 306 is further transferred according to the power control parameter set of the SRI-PUSCH-PowerControl lists, wherein the SRI-PUSCH-PowerControl lists are also associated with CORESETPoolIndex values ​​according to DCI.

[0078] Figure 4 This is a schematic flowchart illustrating an embodiment of method 400 according to this application. In some embodiments, method 400 is executed by a device such as a basic unit. In some embodiments, method 400 may be executed by a processor that executes program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0079] Method 400 may include 402 transmission configuration, wherein the configuration indicates the configuration of two SRS resource sets using 'codebook' or 'non-codebook', wherein each SRS resource set is associated with a different CORESETPoolIndex value; 404 transmission scheduling DCI for PUSCH transmission, wherein the DCI includes an SRI field; and 406 receiving PUSCH transmissions based on SRS resources in the SRS resource set for codebook-based PUSCH transmissions or a subset of SRS resources in the SRS resource set for non-codebook-based PUSCH transmissions, wherein the SRS resources or subsets of SRS resources are indicated by the SRI field in the DCI, and wherein the SRS resource set is associated with a CORESETPoolIndex value according to the DCI. When the configuration in step 402 further indicates two SRI-PUSCH-PowerControl lists, each of which is associated with a different CORESETPoolIndex value, the PUSCH transmission in step 406 is further received according to the power control parameter set of the SRI-PUSCH-PowerControl list, wherein the SRI-PUSCH-PowerControl list is also associated with the CORESETPoolIndex value according to the DCI.

[0080] Figure 5 This is a schematic block diagram illustrating a device according to one embodiment.

[0081] refer to Figure 5 The UE (e.g., a remote unit) includes a processor, memory, and transceiver. The processor is implemented in... Figure 3 The functions, processes, and / or methods proposed in [the document]. A gNB (i.e., a basic unit) includes a processor, memory, and a transceiver. The processor is implemented in [the document / system]. Figure 4 The functions, processes, and / or methods proposed herein. The layers of the radio interface protocol can be implemented by the processor. A memory is connected to the processor to store various information used to drive the processor. A transceiver is connected to the processor to transmit and / or receive radio signals. Furthermore, a transceiver can be implemented as a transmitter for transmitting radio signals and a receiver for receiving radio signals.

[0082] Memory can be located inside or outside the processor and is connected to the processor in a variety of well-known ways.

[0083] In the above embodiments, the components and features of the embodiments are combined in a predetermined form. Unless otherwise expressly stated, each component or feature should be considered as an option. Each component or feature may be implemented without being associated with other components or features. Furthermore, embodiments can be configured by associating some components and / or features. The order of operations described in the embodiments may be changed. Some components or features of any embodiment may be included in another embodiment or replaced with components and features corresponding to another embodiment. Obviously, claims not expressly referenced in the claims are combined to form embodiments or included in new claims.

[0084] The embodiments can be implemented using hardware, firmware, software, or a combination thereof. In the case of hardware implementation, the exemplary embodiments described herein can be implemented using one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, etc., according to the hardware implementation method.

[0085] The embodiments may be practiced in other specific forms. The described embodiments are to be regarded in all respects as illustrative only and not restrictive. Therefore, the scope of the invention is indicated by the appended claims, and not by the foregoing description. All modifications within the meaning and equivalent scope of the claims are to be included within their scope.

Claims

1. A remote unit, comprising: A receiver receives a configuration indicating that two SRS resource sets are configured to use either a 'codebook' or a 'non-codebook', wherein each SRS resource set is configured with a different CORESETPoolIndex value, and the receiver further receives a DCI for scheduling PUSCH transmissions, wherein the DCI includes an SRI field; and A transmitter that transmits a PUSCH transmission based on SRS resources of a first SRS resource set for codebook-based PUSCH transmission or a subset of SRS resources of a second SRS resource set for non-codebook-based PUSCH transmission, wherein the SRS resources or the subset of SRS resources are indicated by the SRI field in the DCI. The first SRS resource set or the second SRS resource set is determined by representing an SRS resource set associated with the same CORESETPoolIndex value as the CORESET in which the DCI is received; The SRI field is interpreted based on the determined first SRS resource set or second SRS resource set.

2. The remote unit according to claim 1, wherein, The different CORESETPoolIndex values ​​are configured for each SRS resource set in the two SRS resource sets via RRC signaling.

3. The remote unit according to claim 1, wherein, The SRS resource set with the lower index of the two SRS resource sets configured to use either 'codebook' or 'non-codebook' is associated with CORESETPoolIndex 0, and the SRS resource set with the higher index of the two SRS resource sets configured to use either 'codebook' or 'non-codebook' is associated with CORESETPoolIndex 1.

4. The remote unit according to claim 1, wherein, The SRS resource set with the lower index of the two SRS resource sets configured to use either 'codebook' or 'non-codebook' is associated with CORESETPoolIndex 1, and the SRS resource set with the higher index of the two SRS resource sets configured to use either 'codebook' or 'non-codebook' is associated with CORESETPoolIndex 0.

5. The remote unit according to claim 1, wherein, The configuration further indicates two SRI-PUSCH-PowerControl lists, each of which is associated with a different CORESETPoolIndex value, and the transmitter further transmits the PUSCH transmission according to a set of power control parameters of the SRI-PUSCH-PowerControl list, wherein the SRI-PUSCH-PowerControl list is also associated with the CORESETPoolIndex value according to the DCI.

6. The remote unit according to claim 5, wherein, The CORESETPoolIndex value associated with the SRS resource set is the CORESETPoolIndex value of the CORESET that transmits the DCI.

7. The remote unit according to claim 6, wherein, The SRS resources of the SRS resource set used for codebook-based PUSCH transmission or the subset of the SRS resources of the SRS resource set used for non-codebook-based PUSCH transmission are indicated by all bits in the SRI field of the DCI.

8. The remote unit according to claim 6, wherein, The power control parameter set is determined by mapping the SRI value indicated by all bits in the SRI field of the DCI to the SRI-PUSCH-PowerControl list associated with the CORESETPoolIndex value.

9. The remote unit according to claim 5, wherein, The CORESETPoolIndex value associated with the SRS resource set is indicated by a bit of the SRI field in the DCI.

10. The remote unit according to claim 9, wherein, The bit is the MSB of the SRI field.

11. The remote unit according to claim 9, wherein, The SRS resources of the SRS resource set used for codebook-based PUSCH transmission or the subset of the SRS resources of the SRS resource set used for non-codebook-based PUSCH transmission are indicated by all bits in the SRI field of the DCI except for the one bit mentioned above.

12. The remote unit according to claim 9, wherein, The power control parameter set is determined by mapping the SRI value indicated by all bits except the one bit in the SRI field of the DCI to the SRI-PUSCH-PowerControl list associated with the CORESETPoolIndex value.

13. A method executed by a remote unit, comprising: Receive configuration, wherein the configuration indicates that two SRS resource sets are configured to use 'codebook' or 'non-codebook', wherein each SRS resource set is configured with a different CORESETPoolIndex value; Receive the DCI for scheduled PUSCH transmissions, wherein the DCI includes an SRI field; and The PUSCH transmission is transmitted based on SRS resources of a first SRS resource set for codebook-based PUSCH transmission or a subset of SRS resources of a second SRS resource set for non-codebook-based PUSCH transmission, wherein the SRS resources or the subset of SRS resources are indicated by the SRI field in the DCI. The first SRS resource set or the second SRS resource set is determined by representing an SRS resource set associated with the same CORESETPoolIndex value as the CORESET in which the DCI is received; The SRI field is interpreted based on the determined first SRS resource set or second SRS resource set.

14. The method according to claim 13, wherein, The different CORESETPoolIndex values ​​are configured for each SRS resource set in the two SRS resource sets via RRC signaling.

15. The method according to claim 13, wherein, The SRS resource set with the lower index of the two SRS resource sets configured to use either 'codebook' or 'non-codebook' is associated with CORESETPoolIndex 0, and the SRS resource set with the higher index of the two SRS resource sets configured to use either 'codebook' or 'non-codebook' is associated with CORESETPoolIndex 1.

16. The method according to claim 13, wherein, The SRS resource set with the lower index of the two SRS resource sets configured to use either 'codebook' or 'non-codebook' is associated with CORESETPoolIndex 1, and the SRS resource set with the higher index of the two SRS resource sets configured to use either 'codebook' or 'non-codebook' is associated with CORESETPoolIndex 0.

17. The method according to claim 13, wherein, The configuration further indicates two SRI-PUSCH-PowerControl lists, each of which is associated with a different CORESETPoolIndex value, and further transmits the PUSCH transmission according to a set of power control parameters of the SRI-PUSCH-PowerControl list, wherein the SRI-PUSCH-PowerControl list is also associated with the CORESETPoolIndex value according to the DCI.

18. The method according to claim 17, wherein, The CORESETPoolIndex value associated with the SRS resource set is the CORESETPoolIndex value of the CORESET that transmits the DCI.

19. The method according to claim 18, wherein, The SRS resources of the SRS resource set used for codebook-based PUSCH transmission or the subset of the SRS resources of the SRS resource set used for non-codebook-based PUSCH transmission are indicated by all bits in the SRI field of the DCI.

20. The method according to claim 18, wherein, The power control parameter set is determined by mapping the SRI value indicated by all bits in the SRI field of the DCI to the SRI-PUSCH-PowerControl list associated with the CORESETPoolIndex value.

21. The method according to claim 17, wherein, The CORESETPoolIndex value associated with the SRS resource set is indicated by a bit of the SRI field in the DCI.

22. The method according to claim 21, wherein, The bit is the MSB of the SRI field.

23. The method according to claim 21, wherein, The SRS resources of the SRS resource set used for codebook-based PUSCH transmission or the subset of the SRS resources of the SRS resource set used for non-codebook-based PUSCH transmission are indicated by all bits in the SRI field of the DCI except for the one bit mentioned above.

24. The method according to claim 21, wherein, The power control parameter set is determined by mapping the SRI value indicated by all bits except the one bit in the SRI field of the DCI to the SRI-PUSCH-PowerControl list associated with the CORESETPoolIndex value.

25. A base station unit, comprising: A transmitter, the transmitter transmitting a configuration indicating the configuration of two SRS resource sets using either a 'codebook' or 'non-codebook', wherein each SRS resource set is configured with a different CORESETPoolIndex value, and the transmitter further transmitting a DCI for scheduling PUSCH transmissions, wherein the DCI includes an SRI field; and A receiver that receives the PUSCH transmission based on SRS resources of a first SRS resource set for codebook-based PUSCH transmission or a subset of SRS resources of a second SRS resource set for non-codebook-based PUSCH transmission, wherein the SRS resources or the subset of SRS resources are indicated by the SRI field in the DCI. The first SRS resource set or the second SRS resource set is determined by representing an SRS resource set associated with the same CORESETPoolIndex value as the CORESET in which the DCI is received; The SRI field is interpreted based on the determined first SRS resource set or second SRS resource set.

26. The base station unit according to claim 25, wherein, The different CORESETPoolIndex values ​​are configured for each SRS resource set in the two SRS resource sets via RRC signaling.

27. The base station unit according to claim 25, wherein, The SRS resource set with the lower index of the two SRS resource sets configured to use either 'codebook' or 'non-codebook' is associated with CORESETPoolIndex 0, and the SRS resource set with the higher index of the two SRS resource sets configured to use either 'codebook' or 'non-codebook' is associated with CORESETPoolIndex 1.

28. The base station unit according to claim 25, wherein, The SRS resource set with the lower index of the two SRS resource sets configured to use either 'codebook' or 'non-codebook' is associated with CORESETPoolIndex 1, and the SRS resource set with the higher index of the two SRS resource sets configured to use either 'codebook' or 'non-codebook' is associated with CORESETPoolIndex 0.

29. The base station unit according to claim 25, wherein, The configuration further indicates two SRI-PUSCH-PowerControl lists, each of which is associated with a different CORESETPoolIndex value, and the receiver further receives the PUSCH transmission according to a set of power control parameters of the SRI-PUSCH-PowerControl list, wherein the SRI-PUSCH-PowerControl list is also associated with the CORESETPoolIndex value according to the DCI.

30. The base station unit according to claim 29, wherein, The CORESETPoolIndex value associated with the SRS resource set is the CORESETPoolIndex value of the CORESET that transmits the DCI.

31. The base station unit of claim 30, wherein the SRS resources of the SRS resource set for codebook-based PUSCH transmission or the subset of the SRS resources of the SRS resource set for non-codebook-based PUSCH transmission are indicated by all bits in the SRI field of the DCI.

32. The base station unit according to claim 30, wherein, The power control parameter set is determined by mapping the SRI value indicated by all bits in the SRI field of the DCI to the SRI-PUSCH-PowerControl list associated with the CORESETPoolIndex value.

33. The base station unit according to claim 29, wherein, The CORESETPoolIndex value associated with the SRS resource set is indicated by a bit of the SRI field in the DCI.

34. The base station unit according to claim 33, wherein, The bit is the MSB of the SRI field.

35. The base station unit according to claim 33, wherein, The SRS resources of the SRS resource set used for codebook-based PUSCH transmission or the subset of the SRS resources of the SRS resource set used for non-codebook-based PUSCH transmission are indicated by all bits in the SRI field of the DCI except for the one bit mentioned above.

36. The base station unit according to claim 33, wherein, The power control parameter set is determined by mapping the SRI value indicated by all bits except the one bit in the SRI field of the DCI to the SRI-PUSCH-PowerControl list associated with the CORESETPoolIndex value.

37. A method performed by a base station unit, comprising: The transmission configuration indicates that two SRS resource sets are configured to use either a 'codebook' or a 'non-codebook', wherein each SRS resource set is configured with a different CORESETPoolIndex value; The DCI for transport scheduling PUSCH transmissions, wherein the DCI includes an SRI field; and The PUSCH transmission is received based on SRS resources of a first SRS resource set for codebook-based PUSCH transmission or a subset of SRS resources of a second SRS resource set for non-codebook-based PUSCH transmission, wherein the SRS resources or the subset of SRS resources are indicated by the SRI field in the DCI. The first SRS resource set or the second SRS resource set is determined by representing an SRS resource set associated with the same CORESETPoolIndex value as the CORESET in which the DCI is received; The SRI field is interpreted based on the determined first SRS resource set or second SRS resource set.

38. The method according to claim 37, wherein, The different CORESETPoolIndex values ​​are configured for each SRS resource set in the two SRS resource sets via RRC signaling.

39. The method according to claim 37, wherein, The SRS resource set with the lower index of the two SRS resource sets configured to use either 'codebook' or 'non-codebook' is associated with CORESETPoolIndex 0, and the SRS resource set with the higher index of the two SRS resource sets configured to use either 'codebook' or 'non-codebook' is associated with CORESETPoolIndex 1.

40. The method of claim 37, wherein, The SRS resource set with the lower index of the two SRS resource sets configured to use either 'codebook' or 'non-codebook' is associated with CORESETPoolIndex 1, and the SRS resource set with the higher index of the two SRS resource sets configured to use either 'codebook' or 'non-codebook' is associated with CORESETPoolIndex 0.

41. The method according to claim 37, wherein, The configuration further indicates two SRI-PUSCH-PowerControl lists, each of which is associated with a different CORESETPoolIndex value, and further transmits the PUSCH transmission according to a set of power control parameters of the SRI-PUSCH-PowerControl list, wherein the SRI-PUSCH-PowerControl list is also associated with the CORESETPoolIndex value according to the DCI.

42. The method according to claim 41, wherein, The CORESETPoolIndex value associated with the SRS resource set is the CORESETPoolIndex value of the CORESET that transmits the DCI.

43. The method according to claim 42, wherein, The SRS resources of the SRS resource set used for codebook-based PUSCH transmission or the subset of the SRS resources of the SRS resource set used for non-codebook-based PUSCH transmission are indicated by all bits in the SRI field of the DCI.

44. The method according to claim 42, wherein, The power control parameter set is determined by mapping the SRI value indicated by all bits in the SRI field of the DCI to the SRI-PUSCH-PowerControl list associated with the CORESETPoolIndex value.

45. The method according to claim 41, wherein, The CORESETPoolIndex value associated with the SRS resource set is indicated by a bit of the SRI field in the DCI.

46. ​​The method according to claim 45, wherein, The bit is the MSB of the SRI field.

47. The method according to claim 45, wherein, The SRS resources of the SRS resource set used for codebook-based PUSCH transmission or the subset of the SRS resources of the SRS resource set used for non-codebook-based PUSCH transmission are indicated by all bits in the SRI field of the DCI except for the one bit mentioned above.

48. The method according to claim 45, wherein, The power control parameter set is determined by mapping the SRI value indicated by all bits except the one bit in the SRI field of the DCI to the SRI-PUSCH-PowerControl list associated with the CORESETPoolIndex value.

Images