Transmitter, receiver and communication method for uplink transmission of grant-free

Abstract

This disclosure relates to transmitters, receivers, and communication methods for improved dispatch-free uplink transmission in communication systems, particularly in multi-TRP / plane scenarios. The transmitter includes circuitry configured to: receive a dispatch-free authorization (CG) configuration for configuring the CG type of a Physical Uplink Shared Channel (PUSCH) transmission; and transmit a PUSCH transmission accompanying the CG, wherein the CG PUSCH transmission is associated with one of multiple TRPs of an active uplink bandwidth portion (BWP) of the serving cell. This significantly enhances support for CG PUSCH transmission in multi-TRP / plane scenarios.

Description

Technical Field

[0001] This disclosure relates to the field of wireless communication systems, and more specifically, to transmitters, receivers, and communication methods for improved scheduling-free uplink transmission, particularly in scenarios with multiple transmission-reception points (multi-TRPs) / planes. Background Technology

[0002] Third-generation (3G) mobile phone standards and technologies are well-known wireless communication systems. The Third Generation Partnership Project (3GPP) has developed these 3G standards and technologies. Generally speaking, 3G wireless communication has been developed to support macrocell mobile phone communication, and communication systems and networks have evolved towards broadband mobile systems. In cellular wireless communication systems, User Equipment (UE) connects to the Radio Access Network (RAN) via a radio link. The RAN includes a set of base stations that provide radio links to UEs located in the cells covered by those base stations, and includes an interface connecting to the Core Network (CN), which has the function of controlling the overall network. The RAN and CN each perform corresponding functions related to the overall network. The 3rd Generation Partnership Project (3GPP) has developed the so-called Long Term Evolution (LTE) system, namely the Evolved Universal Mobile Telecommunication System Territorial Radio Access Network (E-UTRAN), for mobile access networks of one or more macro cells supported by base stations called eNodeBs or eNBs (evolved NodeBs). More recently, LTE has further evolved into the so-called 5G or new radio (NR) system, in which one or more cells are supported by base stations called gNBs.

[0003] The 5G standard will support a variety of different services, each with very different requirements. These services include Enhanced Mobile Broadband (eMBB) technology for high-speed data transmission, Ultra-Reliable Low Latency Communication (URLLC) technology for devices requiring low latency and high link reliability, and Massive Machine-Type Communication (mMTC) technology for long-lifetime communication requiring high energy efficiency to support a large number of low-power devices.

[0004] In order to maintain the varying levels of quality of service (QoS) required to meet a wide range of services, the 5G standard must allow for a flexible and scalable design to support these different requirements simultaneously.

[0005] In NR systems, the use of Control Resource Sets (CORESETs) has been agreed upon. These are a set of physical resource blocks (PRBs) used for a certain number of Orthogonal Frequency Division Multiplexing (OFDM) symbols to carry control information from the gNB to the user. In LTE, there is a significant time interval between control (Physical Downlink Control Channel (PDCCH) area) and data (Physical Downlink Shared Channel (PDSCH)). In contrast to LTE, in NR, control information is transmitted to the user through different CORESETs within the control area. Because NR can utilize large-bandwidth carriers, a CORESET may not always occupy the entire control area.

[0006] Multiple-input multiple-output (MIMO) is a technique that uses multiple transmit and receive antennas to enhance the capability of radio links and achieve multipath propagation. MIMO refers to deploying multiple antennas on the transmitter and receiver to simultaneously transmit and receive multiple data signals on the same radio channel (in a large space) through multipath propagation, which greatly improves spectral efficiency.

[0007] A base station (BS) is the network central unit in NR, used to control one or more Transmission Points (TRPs) associated with one or more cells. A BS can refer to an eNB, NodeB, or gNodeB (also called a gNB). For example, a TRP is a transmit / receive point that provides network coverage and communicates directly with the UE. A cell consists of one or more associated TRPs; that is, the coverage area of ​​a cell is a superset of the coverage areas of all the individual TRPs associated with that cell. A cell is controlled by one base station. A cell can also be called a TRP group (TRPG).

[0008] The following is a brief overview of the progress made in the efficient use of multiple transmission receiver points (multiple TRPs / faces) for transmission.

[0009] Multi-TRP / plane transmission in MIMO

[0010] At the 3GPP RAN1#95 meeting, it was agreed to adopt two different designs for Downlink Control Information (DCI) to support multi-TRP / plane transmission in NR:

[0011] Option 1: A single NR-PDCCH schedules a single NR-PDSCH, where each layer is transmitted by a separate TRP.

[0012] Option 2: Multiple NR-PDCCHs, each NR-PDCCH scheduling its own NR-PDSCH, where each NR-PDSCH is transmitted by a separate TRP.

[0013] like Figure 1 In the second scheme shown, two NR-PDCCHs from different TRPs independently schedule two corresponding NR-PDSCHs to the UE. These NR-PDCCHs can be scheduled independently from both TRPs. Therefore, this technique is particularly advantageous when different TRPs are connected via non-ideal backhaul links. In multi-TRP / face scenarios, joint scheduling may be infeasible or severely limited due to the high latency of information exchange between TRPs (e.g., Channel State Information (CSI) / data / scheduling).

[0014] Multiple PDCCHs are also advantageous when each TRP requires independent resource allocation and other control information. Performance can be improved when each PDSCH is scheduled by a separate DCI, as completely independent scheduling and the use of different modulation and coding schemes (MCS) for the PDSCH are possible. Furthermore, different codewords can be scheduled for each TRP, thereby improving performance.

[0015] The formation of technical problems

[0016] In 3GPP Release 16, for Non-Coherent Joint Transport (NC-JT), multi-TRP / plane transport has adopted methods based on a single PDCCH and multiple PDCCHs. In the single PDCCH scenario, the single PDCCH is treated as a single PDSCH scheduled from multiple TRPs. However, in the case of multiple PDCCHs, each PDCCH schedules its own PDSCH, with each PDSCH being transmitted by a separate TRP.

[0017] Transmissions on the Physical Uplink Shared Channel (PUSCH) can be dynamically scheduled via a UL grant in the DCI (referred to as a dynamical grant (DG)), or the transmission can correspond to a scheduling-free grant type 1 or type 2 (referred to as a configured grant (CG)). A scheduling-free grant type 1 PUSCH transmission is semi-statically configured to operate upon receiving higher-layer parameters of `configuredGrantConfig` (including `rrc-ConfiguredUplinkGrant`) in the absence of a detected UL grant in the DCI. Upon receiving higher-layer parameters of `configuredGrantConfig` (excluding `rrc-ConfiguredUplinkGrant`), a scheduling-free grant type 2 PUSCH transmission is semi-persistently scheduled via a valid active UL grant in the DCI. More than one scheduling-free grant configuration of scheduling-free grant type 1 and / or scheduling-free grant type 2 can be active simultaneously in an active bandwidth portion (BWP) of the serving cell.

[0018] In 3GPP Release 16, a maximum of three cores can be configured for a single TRP, and a maximum of five cores can be configured within a single cell. For downlink transmissions, these cores are divided into two groups, each corresponding to a specific TRP. For downlink transmissions, it has been agreed that a specific TRP can be identified by a higher-layer index configured for each core (if configured). This index is further represented as CORESETPoolIndex, which is contained in another higher-layer parameter, ControlResourceSet(CORESET). If two different CORESETPoolIndex values ​​are configured for the UE for the active bandwidth portion (BWP) of the serving cell, it can be expected that the UE will communicate with at most two different TRPs. Obviously, if a PDSCH / PUSCH is dynamically scheduled by the corresponding DCI, then the PDSCH / PUSCH can be identified by the CORESETPoolIndex, where the scheduling DCI is detected in the core indicated by the CORESETPoolIndex. However, for unauthorized uplink transmissions, there may be multiple TRPs in an active UL BWP. Therefore, it is necessary to define the association between the scheduling-free authorization PUSCH and TRP.

[0019] For dynamically licensed PUSCH transmissions, if the serving cell's activated BWP is configured with two different CORESETPoolIndex values ​​for the UE in the higher-layer parameter ControlResourceSet, then out-of-order scheduling of two non-overlapping dynamically licensed PUSCHs is allowed. These PUSCHs are associated with TRPs having different CORESETPoolIndex values. With the introduction of scheduling-free licensed PUSCHs in scenarios based on multiple DCIs, designing the scheduling order is crucial.

[0020] When a scheduling-free uplink grant is active, CG PUSCH transmission can proceed if the UE cannot find its Cell Radio Network Temporary Identifier (C-RNTI) / configured Scheduling RNTI (CS-RNTI) on the PDCCH. Otherwise, if the UE finds its C-RNTI / CS-RNTI on the PDCCH, the PDCCH allocation will override the scheduling-free uplink grant. Further research was conducted on the processing time for the UE to check this coverage and verify the scheduling-free grant. For single TRP operations in 3GPP Release 16, it was agreed that CG PUSCH transmissions could take precedence over DGPUSCH transmissions in certain conflicting situations. Specifically, if a PDCCH containing a dynamic grant ends less than N² symbols before the start of a valid CGPUSCH transmission with a different HARQ process ID, the CG PUSCH transmission will not be canceled. In scenarios with multiple TRPs based on multiple DCIs, it is expected that the UE will transmit multiple PUSCHs. With the introduction of CG PUSCH transmissions, processing time limits should be defined for this coverage situation.

[0021] Therefore, it is necessary to identify scheduling-free authorized PUSCHs and address other potential issues with scheduling-free authorized uplink transmissions in multiple TRP / plane transmissions based on multiple PDCCHs.

[0022] Related technologies

[0023] In the 3GPP RAN1#94b meeting, it was stipulated that for a single TRP operation, two dynamically authorized PUSCHs cannot overlap in time. In other words, the two PUSCHs are scheduled sequentially or only sequential operations are allowed (e.g., ...). Figure 2 (As shown in case (c)). The specific agreement reached at the meeting is as follows:

[0024] protocol:

[0025] - The following TP is adopted for Section 6.1 of 38.214.

[0026] -----TP Start-----

[0027] The UE should transmit the corresponding PUSCH as indicated by the configured DCI when it detects a PDCCH with the format 0_0 or 0_1. For any two HARQ process IDs in a given scheduled cell, if the UE is scheduled to start a first PUSCH transmission starting from symbol j via a PDCCH ending at symbol i, it is not expected that the UE will be scheduled to transmit a PUSCH earlier than the end symbol of the first PUSCH via a PDCCH that does not end earlier than symbol i.

[0028] For multi-TRPs based on multiple PDCCHs in 3GPP Release 16, out-of-order operations across TRPs may be unavoidable when backhaul is not ideal. Within a single TRP, in 3GPP Release 15, in-order operations should still be maintained. In TS38.214V16.0.0, out-of-order operations across TRPs (such as...) Figure 2 Cases (a) and (b) are shown below:

[0029] If the UE is configured via the higher-layer parameter PDCCH-Config, which contains two different CORESETPoolIndex values ​​in the ControlResourceSet of the active BWP of the serving cell, and the PDCCHs that schedule two non-overlapping PUSCHs are associated with different ControlResourceSets having different CORESETPoolIndex values, then for any two HARQ process IDs in a given scheduling cell, if the UE is scheduled to start a first PUSCH transmission starting from symbol j via the PDCCH associated with the CORESETPoolIndex value in symbol i, then the UE can be scheduled to transmit a PUSCH that starts earlier than the end of the first PUSCH via the PDCCH associated with a different CORESETPoolIndex value that ends later than symbol i.

[0030] It should be noted here and in the context that unordered operations include Figure 2 Cases (a) and (b) in the text, while sequential operations include Figure 2 Case (c) in the middle.

[0031] In the 3GPP RAN1#96 meeting, the priority between CG and DG was designed, and the detailed conclusions and protocols are as follows:

[0032] in conclusion:

[0033] - It is recommended to support the processing of scenario 1 as listed in 3GPP Release 16 WI R1-1814342.

[0034] For scenario 2 as listed in 3GPP Release 16 WI R1-1814342, in the event of a conflict, it is recommended that, in certain circumstances, scheduling-free authorization take precedence over dynamic authorization.

[0035] protocol:

[0036] For scenario 2 listed in R1-1814342, if the conflict between scheduling-free granting and dynamic granting occurs at the physical layer, the options for determining the priority between scheduling-free granting and dynamic granting include at least (to be further investigated in the WI phase):

[0037] - The priority of the PHY is determined by the MAC layer to achieve PHY priority sorting.

[0038] Note: This may or may not have any effect on RAN1.

[0039] - PHY priority is determined by using PHY channels / signals / parameters to achieve PHY priority sorting.

[0040] Whether a conflict should have a higher priority than dynamic authorization can be configured as part of the scheduling-free authorization configuration.

[0041] - Other options are not excluded.

[0042] The PDSCH identifier was designed at the 3GPP RAN1#99 meeting, and the detailed protocol is as follows:

[0043] protocol:

[0044] - If the UE is configured by using the higher-layer parameter PDCCH-Config, which contains two different CORESETPoolIndex values ​​in the ControlResourceSet of the active BWP of the serving cell, the UE can expect to receive multiple PDCCHs, which are scheduled as all / partial / non-overlapping PDSCHs in the time and frequency domains based on the UE's capability.

[0045] Note: This allows the UE to not configure joint HARQ ACK feedback or separate HARQ ACK feedback - for a CORESET lacking a CORESETPoolIndex, the UE can assume that the CORESET is assigned a CORESETPoolIndex of 0.

[0046] Technical issues

[0047] For unauthorized uplink transmissions, there may be multiple TRPs within an active UL BWP. Therefore, it is necessary to define the association between unauthorized PUSCHs and TRPs. With the introduction of unauthorized PUSCHs in scenarios based on multiple DCIs, designing the scheduling order is crucial. With the introduction of CG PUSCH transmissions, processing time constraints for this coverage scenario should be defined.

[0048] Technical solution

[0049] A first aspect of this application provides a transmitter for communicating in a new radio (NR) communication system, the transmitter comprising: one or more interfaces for communicating with multiple transmit-receive points (multi-TRPs) within the NR communication system; and circuitry configured to: receive a scheduling-free authorization (CG) configuration for configuring the CG type of a Physical Uplink Shared Channel (PUSCH) transmission; and transmit a PUSCH transmission accompanying the CG, wherein the CG PUSCH transmission is associated with one of multiple TRPs of an active uplink bandwidth portion (BWP) of a serving cell.

[0050] A second aspect of this application provides a receiver for communicating in a new radio (NR) communication system, the receiver comprising: one or more interfaces for communicating with multiple transmit receiving points (multi-TRPs) within the NR communication system; and circuitry configured to: transmit a scheduling-free authorization (CG) configuration for configuring the CG type of a physical uplink shared channel (PUSCH) transmission; and receive a PUSCH transmission accompanying the CG, wherein the CG PUSCH transmission is associated with one of multiple TRPs of an active uplink bandwidth portion (BWP) of the serving cell.

[0051] A third aspect of this application provides a communication method applied to a transmitter in a new radio (NR) communication system, the method comprising: communicating with multiple transmit-receive points (multi-TRPs) within the NR communication system; receiving a scheduling-free authorization (CG) configuration for configuring the CG type of a Physical Uplink Shared Channel (PUSCH) transmission; and transmitting a PUSCH transmission accompanying the CG, wherein the CG PUSCH transmission is associated with one of multiple TRPs of an active uplink bandwidth portion (BWP) of the serving cell.

[0052] A fourth aspect of this application provides a communication method applied to a receiver in a new radio (NR) communication system, the method comprising: communicating with multiple transmit receiving points (multi-TRPs) within the NR communication system; sending a scheduling-free authorization (CG) configuration for configuring the CG type of a Physical Uplink Shared Channel (PUSCH) transmission; and receiving a PUSCH transmission accompanying the CG, wherein the CG PUSCH transmission is associated with one of multiple TRPs of an active uplink bandwidth portion (BWP) of the serving cell.

[0053] For example, the disclosed transmitter can be implemented by the UE, and the disclosed receiver can be implemented by a base station such as a gNodeB or a TRP. In other cases, the transmitter / receiver can be implemented by a base station such as a gNodeB or, for example, a TRP.

[0054] The disclosed method can be implemented in user equipment, base stations, or TRPs.

[0055] The disclosed methods can be programmed as computer-executable instructions stored in a non-transitory computer-readable medium, which, when loaded onto a computer, instructs the computer's processor to execute the disclosed methods.

[0056] Non-transitory computer-readable media may include at least one of the following: hard disk, CD-ROM, optical storage device, magnetic storage device, read-only memory, programmable read-only memory, erasable programmable read-only memory, electrically erasable programmable read-only memory, and flash memory.

[0057] The disclosed methods can be programmed into a computer program product that enables a computer to execute the disclosed methods.

[0058] Beneficial effects

[0059] This application significantly enhances support for CG PUSCH transmission in scenarios with multiple TRPs / planes based on multiple DCIs. The solution includes the association between CG PUSCH and TRPs, the scheduling order among multiple PUSCHs, and the priority between CG PUSCH and Dynamically Granted (DG) PUSCH. First, several methods are defined to identify the association between CG PUSCH and TRPs, enabling the UE to initiate the CG PUSCH procedure. Second, by relaxing time constraints, the scheduling order when introducing CG PUSCH in multi-TRP operations is defined. Third, the conflict issues between CG PUSCH and DG PUSCH in different scenarios are resolved. Attached Figure Description

[0060] To more clearly illustrate the embodiments or related technologies of this application, the accompanying drawings described in the embodiments are briefly introduced below. It is obvious that these drawings only present some embodiments of this application, and those skilled in the art can derive other drawings based on these drawings without making any presuppositions.

[0061] Figure 1 The following is a schematic diagram illustrating the transmission of multiple TRPs / planes based on multiple DCIs.

[0062] Figure 2 The following is a schematic diagram illustrating an example of UL scheduling.

[0063] Figure 3 The following is a schematic diagram illustrating the out-of-order operation of PUSCH transmissions of DG and CG type 1.

[0064] Figure 4 The following is a schematic diagram illustrating the out-of-order operation of PUSCH transmissions of DG and CG type 2.

[0065] Figure 5 The following is a schematic diagram illustrating the out-of-order operation of PUSCH transmissions for CG type 1 and CG type 2.

[0066] Figure 6 The following is a schematic diagram illustrating the out-of-order operation of two CG type 2 PUSCH transfers.

[0067] Figure 7 The following is a schematic diagram illustrating the overlap between CG PUSCH transmission and two DG PUSCH transmissions.

[0068] Figure 8 The following is a schematic diagram illustrating the overlap between DG PUSCH transmission and two CG PUSCH transmissions.

[0069] Figure 9 The following is a schematic diagram illustrating the overlap of two DG PUSCH transmissions and two CG PUSCH transmissions.

[0070] Figure 10 This is a block diagram of an example system for wireless communication according to an embodiment of this application. Detailed Implementation

[0071] The embodiments of this application will now be described in detail with reference to the accompanying drawings, focusing on their technical solutions, structural features, achieved objectives, and effects. Specifically, the terminology used in the embodiments of this application is only used to describe certain embodiments and is not intended to limit the content of this application.

[0072] For ease of understanding, it should be noted that in some cases, the term "transmitter" can be implemented by the UE, while the term "receiver" can be implemented by a base station such as a gNodeB or, for example, a TRP. In other cases, the transmitter / receiver can be implemented by a base station such as a gNodeB or, for example, a TRP. However, this should not be considered a limitation on the interpretation of this invention.

[0073] The technical problem statement emphasizes that when transmitting data in a scenario with multiple TRPs / faces based on multiple DCIs, the transmitter and receiver must identify the CG PUSCH before transmission. The main idea of ​​this application is to provide a novel design for transmission with multiple TRPs / faces based on multiple DCIs, thereby enabling the transmitter / receiver to support configured grant (CG) uplink transmission.

[0074] This application proposes several solutions to support CG PUSCH transport, including the association between CG PUSCH and TRP, the scheduling order among multiple PUSCHs, and the priority between CG PUSCH and dynamic grant (DG) PUSCH.

[0075] First, several methods are defined to identify the association between CG PUSCH and TRP, enabling the UE to initiate the CGPUSCH procedure. Second, by relaxing time constraints, several methods are proposed to define the scheduling order when introducing CGPUSCH in multi-TRP operations, including the cases where DG PUSCH and CG PUSCH are transmitted together and the cases of two CG PUSCHs. Third, several solutions are proposed to address conflicts between CG PUSCH and DG PUSCH in different scenarios. Incorporating these methods will significantly enhance support for CG PUSCH transmission in scenarios with multiple DCIs and multiple TRPs / faces.

[0076] CG The relationship between PUSCH and TRP

[0077] The higher-level parameter `ConfiguredGrantConfig` is used to configure two types of dispatch-free licensed PUSCH transport: Dispatch-free license type 1 and Dispatch-free license type 2. Dedicated configuration methods are designed for specific types of dispatch-free licenses. For CG activation, CG type 1 is configured via RRC, while CG type 2 is configured via DCI addressing to CS-RNTI.

[0078] In 3GGP Release 16, for an active UL BWP of a serving cell, a UE can configure up to two TRPs. Therefore, it is necessary to identify the PUSCH transmission accompanying the CG used for the TRP before performing UL transmission. Based on the above description, this application proposes several methods to design the association between the PUSCH transmission accompanying the CG and the TRP.

[0079] (1) CG type 1

[0080] (i) Radio Resource Control (RRC) Configuration

[0081] Upon receiving the higher-level parameter `configuredGrantConfig` containing `rrc-ConfiguredUplinkGrant`, PUSCH transmission for CG type 1 is semi-statically configured. After receiving the CG type 1 configuration from the higher layer, the UE begins transmission without detecting UL authorization in the DCI. By adding a TRP-related parameter to the higher-level parameter `configuredGrantConfig`, the UE can determine which TRP to transmit the CG data to. Therefore, CG type 1 PUSCH transmission is associated with a dedicated TRP, indicated by TRP-related parameters such as `CORESETPoolIndex`.

[0082] Based on the above analysis, this application proposes to associate a CG type 1 PUSCH transfer with a dedicated TRP by adding a TRP-related parameter (e.g., CORESETPoolIndex) to the high-level parameter configuredGrantConfig. This dedicated TRP is indicated by the TRP-related parameter.

[0083] (ii) Predefined rules

[0084] To simplify the association between CG Type 1 and TRP, CG Type 1 PUSCH transmissions can be directly associated with a predefined TRP. In this way, if a CG Type 1 transmission is active, the UE directly transmits uplink data to a predefined TRP without adding higher-layer parameters. Based on the above description, embodiments of this application propose associating CG Type 1 PUSCH transmissions with a dedicated TRP, for example, with a CORESETPoolIndex value of 0.

[0085] (2) CG type 2

[0086] (i) RRC Configuration

[0087] After receiving the CG Type 2 configuration from a higher layer, the UE begins transmission when it detects UL authorization in the activated DCI. Therefore, by adding a TRP-related parameter to the higher-layer parameter configuredGrantConfig, the CG Type 2 PUSCH transmission is associated with a dedicated TRP, which is indicated by TRP-related parameters such as CORESETPoolIndex.

[0088] Based on the above analysis, this application proposes to associate a CG type 2 PUSCH transfer with a dedicated TRP by adding a TRP-related parameter (e.g., CORESETPoolIndex) to the high-level parameter configuredGrantConfig. This dedicated TRP is indicated by the TRP-related parameter.

[0089] (ii) CORESETPoolIndex

[0090] After receiving the higher-level parameter configuredGrantConfig, which does not include rrc-ConfiguredUplinkGrant, CG type 2 PUSCH transports are semi-persistently scheduled by DCI indicating whether the unscheduled uplink grant type 2 is activated or deactivated.

[0091] The maximum number of cores configured for each UE's BWP is five. These cores can be divided into multiple groups, each associated with a dedicated TRP. The UE monitors PDCCH candidates in a UE-specific search space set (whose time-domain and frequency-domain resources are indicated by the corresponding core). Upon successful detection of an active DCI, the UE schedules a dedicated CG type 2 for the TRP. In this way, the UE can identify dedicated PUSCH transmissions of CG type 2 for the TRP.

[0092] Based on the relationship between CG type 2 and CORESET, this application proposes associating the PUSCH transmission of CG type 2 with the TRP based on the value of CORESETPoolIndex in the ControlResourceSet, wherein a valid active DCI of CG type 2 is successfully detected in the ControlResourceSet. Specifically, if CORESETPoolIndex is not configured, the UE can assume that the value of CORESETPoolIndex is 0.

[0093] Scheduling order among multiple PUSCH

[0094] Based on the above description, in a multi-TRP scenario based on multiple DCIs, each CG type 1 / CG type 2 PUSCH transmission is associated with a dedicated TRP. In 3GPP Release 16, when deploying a multi-TRP scenario based on multiple DCIs, out-of-order scheduling of two DG PUSCHs from different TRPs is permitted. Since CG PUSCH transmissions are introduced in multi-TRP operations based on multiple DCIs, out-of-order scheduling among multiple PUSCHs, including CG PUSCHs, should be supported. To design scheduling rules, it is recommended to address four scenarios.

[0095] (1) DG PUSCH and CG Type 1 PUSCH

[0096] If the complete scheduling information for transmitting DG PUSCH is carried by the corresponding PDCCH, the UE detects the DCI and provides the scheduling offset K2 for the DG PUSCH transmission. During the DG PUSCH scheduling process, if the CG type 1 PUSCH transmission is semi-statically configured by higher-layer parameters, the time-domain parameters, frequency-domain parameters, and associated TRPs applied to that transmission are provided. If the scheduling information for these two PUSCHs indicates that the DG PUSCH transmission will completely overlap / partially overlap / not overlap with the CG type 1 PUSCH transmission in the time and / or frequency domains, the UE can schedule the CG type 1 PUSCH transmission in a multi-TRP scenario based on multiple DCIs, with its start earlier than the end of the DG PUSCH transmission.

[0097] Based on the above analysis, this application proposes the following operation for multi-TRP scenarios based on multiple DCIs: when scheduling CG type 1 PUSCH transmissions and DG PUSCH transmissions across TRPs, i.e., when CG type 1 PUSCH transmissions and DG PUSCH transmissions are associated with different CORESETpoolIndex values:

[0098] Reference Figure 3 If the UE is scheduled to start a DGPUSCH transmission starting from symbol j by using the PDCCH ending at symbol i, then the UE can be scheduled to transmit a PUSCH transmission of type CG 1, which starts earlier than the end of the DG PUSCH transmission.

[0099] like Figure 3 The diagram illustrates an example of scheduling order. DG PUSCH transmissions and CG Type 1 PUSCH transmissions are allowed to be out of order. CG Type 1 PUSCH transmissions are scheduled to begin before the end of DG PUSCH transmissions. In multi-TRP scenarios based on multiple DCIs, CG Type 1 PUSCH transmissions are allowed to completely overlap / partially overlap / not overlap with DG PUSCH transmissions.

[0100] (2) DG PUSCH and CG type 2 PUSCH

[0101] If the complete scheduling information for transmitting DG PUSCH is carried by the corresponding PDCCH, the UE detects the DCI and provides the scheduling offset K2 for the DG PUSCH transmission. During the DG PUSCH scheduling process, if the UE receives a UL grant in a valid active DCI that schedules CG type 2 PUSCH transmissions, the UE provides the time-domain parameters, frequency-domain parameters, and associated TRPs applied to that transmission. If the scheduling information for these two PUSCHs indicates that the DG PUSCH transmission will completely overlap / partially overlap / not overlap with the CG type 2 PUSCH transmission in the time and / or frequency domains, the UE can schedule the CG type 2 PUSCH transmission in a multi-TRP scenario based on multiple DCIs, with its start earlier than the end of the DG PUSCH transmission.

[0102] Based on the above analysis, this application proposes the following operation for multi-TRP scenarios based on multiple DCIs: when scheduling CG type 2 PUSCH transmissions and DG PUSCH transmissions across TRPs, i.e., when CG type 2 PUSCH transmissions and DG PUSCH transmissions are associated with different CORESETpoolIndex values:

[0103] Reference Figure 4 If the UE is scheduled to begin a DG PUSCH transmission starting from symbol j by using a PDCCH associated with a TRP identifier (e.g., the value of CORESETpoolIndex) ending at symbol i, then the UE can be scheduled to transmit CG type 2 PUSCH transmissions respectively scheduled by using PDCCHs associated with different TRP identifiers (e.g., different CORESETpoolIndex values), which start earlier than the end of the DG PUSCH transmission.

[0104] like Figure 4 The diagram illustrates an example of scheduling order. DG PUSCH transmissions and CG Type 2 PUSCH transmissions are allowed to be out of order. CG Type 2 PUSCH transmissions are scheduled to begin before the end of a DG PUSCH transmission. In multi-TRP scenarios based on multiple DCIs, CG Type 2 PUSCH transmissions are allowed to completely overlap / partially overlap / not overlap with DG PUSCH transmissions.

[0105] (3) PUSCH of CG type 1 and PUSCH of CG type 2

[0106] More than one dispatch-free authorization configuration of type 1 and / or type 2 can be active simultaneously in an active BWP of the serving cell. This means that in multi-TRP operations based on multiple DCIs, both CG type 1 PUSCH and CG type 2 PUSCH can be scheduled simultaneously.

[0107] When the UE receives the activation DCI for a CG type 2 PUSCH transmission, the UE begins scheduling the CG type 2 PUSCH. During the activation of the CG type 2 PUSCH, the CG type 1 PUSCH is activated. If the scheduling information for these two PUSCHs indicates that the CG type 1 PUSCH transmission will completely overlap / partially overlap / not overlap with the CG type 2 PUSCH transmission in the time domain and / or frequency domain, then the UE can schedule the CG type 1 PUSCH transmission in a multi-TRP scenario based on multiple DCIs, with its start date preceding the end date of the CG type 2 PUSCH transmission.

[0108] Based on the above analysis, this application proposes the following operation for multi-TRP scenarios based on multiple DCIs: when scheduling PUSCH transmissions of CG type 1 and CG type 2 across TRPs, i.e., when PUSCH transmissions of CG type 1 and CG type 2 are associated with different CORESETpoolIndex values, the following operation is recommended:

[0109] Reference Figure 5 If the UE is scheduled to start a CG type 2 PUSCH transmission starting from symbol j by using the PDCCH ending at symbol i, then the UE can be scheduled to transmit a CG type 1 PUSCH transmission scheduled by higher-layer signaling, which starts earlier than the end of the CG type 2 PUSCH transmission.

[0110] like Figure 5 The diagram illustrates an example of scheduling order. It allows for unordered PUSCH transmissions of CG type 1 and CG type 2. PUSCH transmissions of CG type 1 are scheduled to begin before the end of a PUSCH transmission of CG type 2. In multi-TRP scenarios based on multiple DCIs, PUSCH transmissions of CG type 1 and CG type 2 are allowed to completely overlap / partially overlap / not overlap.

[0111] (4) Two CG PUSCH of the same type

[0112] As mentioned above, more than one CG type 1 and / or CG type 2 no-schedule authorization configuration can be active simultaneously. This means that in multi-TRP operations based on multiple DCIs, two CG PUSCHs of the same type (i.e., type 1 or type 2) can be scheduled simultaneously.

[0113] During the activation of the first CG PUSCH (i.e., CG type 1 PUSCH or CG type 2 PUSCH) 1, the second CGPUSCH (i.e., CG type 1 PUSCH or CG type 2 PUSCH) 2 is also activated. If the scheduling information of these two PUSCHs indicates that CG PUSCH 2 will completely overlap / partially overlap / not overlap with CG PUSCH 1 in the time domain and / or frequency domain, then the UE can schedule CG PUSCH 2 transmission in a multi-TRP scenario based on multiple DCIs, with its start date earlier than the end date of CG PUSCH 1.

[0114] (i) Two type 1 CG PUSCH

[0115] Based on the above analysis, this application proposes the following operation for multi-TRP scenarios based on multiple DCIs, when scheduling a PUSCH transmission of CG type 1 and another PUSCH transmission of CG type 1 across TRPs, i.e., when these two PUSCH transmissions of CG type 1 are associated with different CORESETpoolIndex values:

[0116] If the UE is scheduled to begin a CG type 1 PUSCH 1 transmission starting from symbol j via higher-layer signaling ending at symbol i, the UE can be scheduled to transmit a CG type 1 PUSCH 2 transmission scheduled via another higher-layer signaling ending after symbol i, the start of which precedes the end of the CG type 1 PUSCH 1 transmission.

[0117] (ii) Two types of CG PUSCH

[0118] Based on the above analysis, this application proposes the following operation for multi-TRP scenarios based on multiple DCIs, when scheduling a CG type 2 PUSCH transmission and another CG type 2 PUSCH transmission across TRPs, i.e., these two CG type 2 PUSCH transmissions are associated with different CORESETpoolIndex values:

[0119] Reference Figure 6 If the UE is scheduled to begin a CG type 2 PUSCH 1 transmission starting from symbol j by a PDCCH that ends at symbol i and is associated with a CORESETpoolIndex value, then the UE can be scheduled to transmit a CG type 2 PUSCH 2 transmission scheduled by another PDCCH that ends after symbol i and is associated with a different CORESETpoolIndex value, which begins earlier than the end of the CG type 2 PUSCH 1 transmission.

[0120] like Figure 6 The diagram illustrates an example of scheduling order. Unordered scheduling between two CG type 2 PUSCH transfers is allowed. A CG type 2 PUSCH 1 transfer is scheduled to begin before the end of a CG type 2 PUSCH 2 transfer. In a multi-TRP scenario based on multiple DCIs, complete overlap, partial overlap, and non-overlap between CG type 2 PUSCH 1 and CG type 2 PUSCH 2 transfers are allowed.

[0121] Priority between un-scheduled licensed CG and dynamically licensed DG

[0122] For a single TRP operation, if a PDCCH containing a DG PUSCH ends less than N² symbols before the start of a valid CG PUSCH transmission with a different HARQ process ID, the CG PUSCH transmission will not be canceled. In multi-TRP scenarios, it is expected that the UE will transmit multiple full / partial PUSCHs in the time domain. With the introduction of CG PUSCH transmissions in multi-TRP operations, processing time limits for this coverage case should be defined.

[0123] Considering that multiple configurations may be active at the same time, several methods are proposed to cover different overlapping situations.

[0124] (1) One CG PUSCH overlaps with two DG PUSCH

[0125] For multiple TRP operations, two TRPs are used for an active UL BWP serving the cell, and each TRP is associated with a PUSCH transport (e.g., DG PUSCH, CG type 1 PUSCH, CG type 2 PUSCH). If two dynamically scheduled PUSCHs overlap with a CG PUSCH transport (e.g., CG type 1 PUSCH, CG type 2 PUSCH), then the priority between the CGPUSCH and these DG PUSCHs should be defined. Two approaches to defining UE behavior are proposed, depending on whether the association between PUSCH and TRP is considered.

[0126] (i) PUSCH associated with the same TRP

[0127] Two PDCCHs associated with different CORESETpoolIndex values ​​schedule two DG PUSCH transmissions. These two DG PUSCHs are associated with different TRPs based on their CORESETpoolIndex values. Based on the above description, each CG PUSCH transmission is associated with a dedicated TRP. This means that one DG PUSCH is associated with the same TRP as the CG PUSCH. To simplify UE behavior, it is recommended to only consider DG PUSCHs associated with the same TRP as the CG PUSCH.

[0128] Based on the above analysis, this application proposes that, for the case of multiple TRPs based on multiple DCIs, when the CG PUSCH transmission overlaps with two DG PUSCHs, the UE transmission of the DG PUSCH scheduled by the PDCCH is not expected. This PDCCH ends before the start of the CGPUSCH transmission in less than N2 symbols and is associated with the CG PUSCH to the same TRP (i.e., the value of CORESETpoolIndex). The value of N2 on the symbol is determined according to the UE processing capability defined in Section 6.4 of 38.214V16.1.0.

[0129] like Figure 7 As shown, the CG PUSCH overlaps with two DG PUSCHs, and PDCCH 1 is associated with the CG PUSCH to the same TRP. For these two overlapping DG PUSCHs, the UE only considers DG PUSCH 1. Since duration 1 is less than N2 symbols, the UE cancels DG PUSCH 1 and transmits the CG PUSCH.

[0130] (ii) Short-duration PDCCH

[0131] In multi-TRP scenarios based on multiple DCIs, when a CG PUSCH transmission overlaps with two DG PUSCHs, each PDCCH scheduling a DGPUSCH has a dedicated duration from the end of the corresponding PDCCH to the start of the CG PUSCH transmission. The following priorities are proposed:

[0132] If the shorter of the two durations is less than N2 symbols, then UE transmission is not expected to be scheduled via DG PUSCH transmission through the shorter duration PDCCH.

[0133] If both durations are more than N2 symbols, then UE transmission of CG PUSCH is not expected.

[0134] like Figure 7As shown, one CG PUSCH overlaps with two DG PUSCHs. Duration 2 is shorter than duration 1, and duration 2 is less than N2 symbols. The UE cancels DG PUSCH 2 and transmits DG PUSCH 1 and CG PUSCH.

[0135] (2) One DG PUSCH overlaps with two CG PUSCH

[0136] For operations involving multiple TRPs, if a dynamically scheduled PUSCH overlaps with two CG PUSCH transmissions, where each CG PUSCH transmission can be either a CG type 1 PUSCH or a CG type 2 PUSCH, then the priority between the DG PUSCH and these CGPUSCHs should be defined. Two approaches to defining UE behavior are proposed, depending on whether the association between PUSCH and TRP is considered.

[0137] (i) PUSCH associated with the same TRP

[0138] In this scenario, based on the value of CORESETpoolIndex, the DG PUSCH scheduled by PDCCH is associated with a dedicated TRP. Based on the above description, each CG PUSCH transmission is associated with a dedicated TRP. This means that one CGPUSCH is associated with the same TRP as a DG PUSCH. To simplify UE behavior, it is recommended to only consider CG PUSCHs associated with the same TRP as the DG PUSCH.

[0139] Based on the above analysis, this application proposes that, for multi-TRP scenarios based on multiple DCIs, when one DGPUSCH overlaps with two CG PUSCHs, the UE is not expected to transmit DCG PUSCH transmissions scheduled by the PDCCH. The PDCCH terminates less than N2 symbols before the start of a CG PUSCH transmission associated with the DGPUSCH to the same TRP (i.e., the value of CORESETpoolIndex). The value of N2 on the symbol is determined according to the UE processing capability defined in Section 6.4 of 38.214V16.1.0.

[0140] like Figure 8 As shown, the DG PUSCH overlaps with two CG PUSCHs, and CG PUSCH 1 is associated with the DG PUSCH to the same TRP. For these two overlapping CG PUSCHs, the UE only considers CG PUSCH 1. The duration is less than N2 symbols. The UE cancels the DG PUSCH and transmits CG PUSCH 1.

[0141] (ii) Long-duration CG PUSCH

[0142] In multi-TRP scenarios based on multiple DCIs, when a DG PUSCH transmission overlaps with two CG PUSCHs, each CG PUSCH has a dedicated duration from the end of the PDCCH that schedules the DG PUSCH to the start of the corresponding CG PUSCH. The following priorities are proposed:

[0143] If both durations are less than N2 symbols, then UE transmission of DG PUSCH scheduled by PDCCH is not expected.

[0144] If both durations exceed N2 symbols, then UE transmission of longer-duration CG PUSCH transmissions is not expected.

[0145] like Figure 8 As shown, one DG PUSCH overlaps with two CG PUSCHs. Both duration 1 and duration 2 are less than N² symbols, so the UE cancels the DG PUSCH and transmits both CG PUSCHs.

[0146] (3) Two DG PUSCHs overlap with two CG PUSCHs

[0147] For multiple TRP operations, if two dynamically scheduled PUSCHs overlap with two CG PUSCH transmissions, where each CG PUSCH transmission can be a CG type 1 PUSCH or a CG type 2 PUSCH, then the priority between these DG PUSCHs and these CG PUSCHs should be defined. Two approaches to defining UE behavior are proposed, depending on whether the association between PUSCHs and TRPs is considered.

[0148] (i) PUSCH pairs associated with the same TRP

[0149] In this scenario, the two DG PUSCHs are associated with two TRPs based on the CORESETpoolIndex value. Based on the above description, each CG PUSCH transmission is associated with a dedicated TRP. CG PUSCHs and DGPUSCHs associated with the same TRP are considered a pair. To simplify UE behavior, it is recommended to define the priority between CG PUSCHs and DGPUSCHs associated with the same TRP.

[0150] In multi-TRP scenarios based on multiple DCIs, when two DG PUSCH transmissions overlap with two CG PUSCH transmissions, DG PUSCHs and CG PUSCHs associated with the same TRP are considered a pair. The following priority is proposed:

[0151] For the first pair with a CORESETPoolIndex value, UE transmission is not expected to terminate via a DG PUSCH transmission scheduled by a PDCCH that ends less than N2 symbols before the start of the corresponding CG PUSCH transmission. The value of N2 on the symbol is determined according to the UE processing capability defined in Section 6.4 of 38.214V16.1.0.

[0152] For the second pair with different CORESETPoolIndex values, it is not expected that the UE transmission will be a DG PUSCH transmission scheduled by PDCCH that ends less than N2 symbols before the start of the corresponding CGPUSCH transmission.

[0153] like Figure 9 As shown, DG PUSCH 1 and CG PUSCH 1 are considered the first pair. DG PUSCH 2 and CG PUSCH 2 are considered the second pair. Both duration 1 and duration 2 are less than N2 symbols, so the UE transmits CG PUSCH 1 and CG PUSCH 2.

[0154] (ii) PUSCH pairs in the time domain

[0155] In multi-TRP scenarios based on multiple DCIs, when two DG PUSCH transmissions overlap with two CG PUSCH transmissions, the DG PUSCH scheduled by the first-ending PDCCH and the first-starting CG PUSCH are considered a pair. Furthermore, the DG PUSCH scheduled by the second-ending PDCCH and the second-starting CG PUSCH are considered another pair. The following priorities are proposed:

[0156] For the first pair, it is not expected that UE transmissions will be DG PUSCH transmissions scheduled by PDCCH that end less than N2 symbols before the start of the corresponding CG PUSCH transmission in that pair.

[0157] For the second pair, it is not expected that UE transmissions will be DG PUSCH transmissions scheduled by PDCCH that end less than N2 symbols before the start of the corresponding CG PUSCH transmission in that pair.

[0158] Figure 10 This is a block diagram of an example system 700 for wireless communication according to an embodiment of this application. The embodiments described herein can be implemented in this system using any appropriately configured hardware and / or software. Figure 10The system 700 is shown, which includes a radio frequency (RF) circuit 710, a baseband circuit 720, a processing unit 730, a memory / storage device 740, a display 750, a camera 760, a sensor 770, and an input / output (I / O) interface 780, which are coupled to each other as shown.

[0159] Processing unit 730 may include circuitry, such as, but not limited to, one or more single-core or multi-core processors. The processor may include any combination of general-purpose processors and special-purpose processors (e.g., graphics processors and application processors). The processor may be coupled to a memory / storage device and configured to execute instructions stored in the memory / storage device to enable various applications and / or operating systems to run on the system.

[0160] Baseband circuitry 720 may include circuitry, such as, but not limited to, one or more single-core or multi-core processors. The processor may include a baseband processor. The baseband circuitry may handle various radio control functions that enable communication with one or more radio networks via RF circuitry. Radio control functions may include, but are not limited to, signal modulation, encoding, decoding, RF shifting, etc. In some embodiments, the baseband circuitry may provide communication compatible with one or more wireless technologies. For example, in some embodiments, the baseband circuitry may support communication with 5G NR, LTE, Evolved Universal Terrestrial Radio Access Network (EUTRAN) and / or other Wireless Wide Area Networks (WMAN), Wireless Local Area Networks (WLAN), and Wireless Personal Area Networks (WPAN). Embodiments in which the baseband circuitry is configured to support wireless communication using more than one wireless protocol may be referred to as multi-mode baseband circuitry. In various embodiments, baseband circuitry 720 may include circuitry for operating with signals that are not strictly considered to be in the baseband frequency range. For example, in some embodiments, the baseband circuitry may include circuitry for operating with signals having an intermediate frequency between the baseband frequency and the radio frequency.

[0161] RF circuit 710 can use modulated electromagnetic radiation through a non-solid medium to achieve communication with a wireless network. In various embodiments, the RF circuit may include switches, filters, amplifiers, etc., to facilitate communication with the wireless network. In various embodiments, RF circuit 710 may include circuitry for operating with signals that are not strictly considered to be in the radio frequency range. For example, in some embodiments, the RF circuitry may include circuitry for operating with signals having an intermediate frequency between the baseband frequency and the radio frequency.

[0162] In various embodiments, the transmitter circuitry, control circuitry, or receiver circuitry discussed above with respect to user equipment, eNB, gNB, or TRP may be implemented, in whole or in part, in one or more RF circuitry, baseband circuitry, and / or processing units. As used herein, “circuit” may refer to, be part of, or include: application-specific integrated circuits (ASICs), electronic circuitry executing one or more software or firmware programs, processors and / or memory (shared, dedicated, or grouped), combined logic circuitry, and / or other suitable hardware components that provide the described functionality. In some embodiments, the electronic device circuitry system may be implemented in one or more software or firmware modules, or the functionality associated with such circuitry system may be implemented by one or more software or firmware modules. In some embodiments, some or all of the components of the baseband circuitry, processing units, and / or memory / storage devices may be implemented together on a system-on-a-chip (SOC).

[0163] The memory / storage device 740 can be used to load and store, for example, data and / or instructions for the system. One embodiment of the memory / storage device may include any combination of suitable volatile memory (e.g., dynamic random access memory (DRAM)) and / or non-volatile memory (e.g., flash memory). In various embodiments, the I / O interface 780 may include one or more user interfaces and / or peripheral component interfaces, the user interfaces being designed to enable a user to interact with the system, and the peripheral component interfaces being designed to enable peripheral components to interact with the system. The user interface may include, but is not limited to, a physical keyboard or keypad, a touchpad, a speaker, a microphone, etc. The peripheral component interface may include, but is not limited to, a non-volatile memory interface, a universal serial bus (USB) interface, an audio jack, and a power interface.

[0164] In various embodiments, sensor 770 may include one or more sensing devices for determining environmental conditions and / or location information relevant to the system. In some embodiments, the sensor may include, but is not limited to, a gyroscope sensor, an accelerometer, a proximity sensor, an ambient light sensor, and a positioning unit. The positioning unit may also be part of or interact with baseband circuitry and / or RF circuitry to communicate with components of a positioning network (e.g., Global Positioning System (GPS) satellites). In various embodiments, display 750 may include displays such as liquid crystal displays and touchscreen displays. In various embodiments, system 700 may be a mobile computing device, such as, but not limited to, laptops, tablets, netbooks, ultrabooks, smartphones, etc. In various embodiments, the system may have more or fewer components and / or different architectures. Where appropriate, the methods described herein may be implemented as a computer program. The computer program may be stored on a storage medium such as a non-transitory storage medium.

[0165] Some embodiments of this application are combinations of "technologies / processes" that can be adopted in 3GPP specifications to develop end products.

[0166] Those skilled in the art will understand that each unit, algorithm, and step described and disclosed in the embodiments of this application is implemented using electronic hardware or a combination of software and electronic hardware for computers. Whether these functions operate in hardware or software depends on the application conditions and the design requirements of the technical solution. Those skilled in the art can implement the functions of each specific application in different ways, and such implementation should not exceed the scope of this application. Those skilled in the art should understand that the working processes of the systems, devices, and units in the above embodiments can be referred to, as the working processes of the above systems, devices, and units are basically the same. For ease of description and brevity, these working processes will not be described in detail.

[0167] It should be understood that the systems, apparatuses, and methods disclosed in the embodiments of this application can be implemented in other ways. The embodiments described above are merely illustrative. The division of units is based solely on logical function, and other divisions may exist in implementation. Multiple units or components may be combined or integrated into another system. Some features may also be omitted or skipped. On the other hand, the mutual coupling, direct coupling, or communication coupling shown or discussed may be indirect coupling or electrical, mechanical, or other forms of communication coupling through some interface, apparatus, or unit.

[0168] The units described as separate components may or may not be physically separate. The units shown may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units may be used depending on the purpose of the embodiment. Furthermore, the functional units in various embodiments may be integrated into one processing unit, or they may be physically independent, or two or more units may be integrated into one processing unit.

[0169] If software functional units are implemented and sold or used as independent products, they can be stored in a readable storage medium within a computer. Based on this understanding, the technical solutions proposed in this application can be implemented essentially or partially as software products. Alternatively, a portion of a technical solution beneficial to the prior art can be implemented as a software product. Software products in a computer are stored in a storage medium and include multiple commands for a computing device (e.g., a personal computer, server, or network device) to execute all or part of the steps disclosed in the embodiments of this application. This storage medium includes a USB flash drive, a portable hard drive, read-only memory (ROM), random access memory (RAM), a floppy disk, or other media capable of storing program code.

[0170] Although this application has been described in conjunction with what are considered to be the most practical and preferred embodiments, it should be understood that this application is not limited to the disclosed embodiments, but is intended to cover various arrangements made without departing from the broadest interpretation of the appended claims.

Claims

1. A transmitter for communication in a new radio (NR) communication system, characterized in that, The transmitter includes: One or more interfaces for communicating with multiple Transmitter-Receiver Points (TRPs) within the NR communication system; and The circuit is configured as follows: Receive scheduling-free authorized CG configuration, which is used to configure the CG type for Physical Uplink Shared Channel (PUSCH) transmission; and Send a PUSCH transmission accompanying the CG, wherein the CG PUSCH transmission is associated with one of a plurality of TRPs of an active uplink bandwidth portion (BWP) of the serving cell. The circuit is characterized in that it is configured as follows: Receive scheduling information about the CG PUSCH transmission and another CGPUSCH transmission, which are scheduled across the multiple TRPs and associated with different TRP identifiers, wherein the scheduling information shows that the end of the activation control of the CG PUSCH transmission is later than the end of the activation control of the other CG PUSCH transmission, allowing the CG PUSCH transmission to start earlier than the end of the other CGPUSCH transmission.

2. The transmitter according to claim 1, characterized in that, The CG configuration is received via Radio Resource Control (RRC).

3. The transmitter according to claim 1, characterized in that, The circuit is configured as follows: In response to the CG configuration indicating a PUSCH transmission of CG type 1, the PUSCH transmission of CG type 1 is associated with the TRP indicated by the TRP related parameters.

4. The transmitter according to claim 1, characterized in that, The circuit is configured as follows: In response to the CG configuration indicating a PUSCH transmission of CG type 1, the PUSCH transmission of CG type 1 is associated with a predefined TRP.

5. The transmitter according to claim 1, characterized in that, The circuit is configured as follows: In response to the CG configuration indicating a PUSCH transmission of CG type 2, the PUSCH transmission of CG type 2 is associated with the TRP indicated by the TRP related parameters.

6. The transmitter according to any one of claims 3 and 5, characterized in that, The CG configuration includes the TRP-related parameters.

7. The transmitter according to claim 1, characterized in that, The circuit is configured as follows: The PUSCH transmission of CG type 2 indicated by the downlink control information DCI configured in the control resource set CORESET of the control region is associated with the TRP associated with the CORESET.

8. The transmitter according to claim 1, characterized in that, The circuit is configured as follows: Receive scheduling information regarding the CG PUSCH transmission and dynamically licensed DGPUSCH transmission scheduled across the multiple TRPs, wherein the scheduling information indicates that the activation control of the CG PUSCH transmission is later than the end of the Physical Downlink Control Channel (PDCCH) that schedules the DGPUSCH transmission, allowing the CG PUSCH transmission associated with the first TRP identifier to begin earlier than the end of the DGPUSCH transmission associated with a second TRP identifier different from the first TRP identifier.

9. The transmitter according to claim 8, characterized in that, The CG PUSCH transmission is one of CG type 1 PUSCH transmission and CG type 2 PUSCH transmission.

10. The transmitter according to claim 8, characterized in that, The DG PUSCH transmission is scheduled via a PDCCH associated with the first TRP identifier, and the CG PUSCH transmission is a CG type 2 PUSCH transmission, which is scheduled via another PDCCH associated with the second TRP identifier.

11. The transmitter according to claim 1, characterized in that, The circuit is configured as follows: Receive scheduling information regarding CG type 1 PUSCH transmissions and CG type 2 PUSCH transmissions scheduled across the plurality of TRPs, wherein the scheduling information indicates that the end of the activation control for the CG type 1 PUSCH transmission is later than the end of the activation control for the CG type 2 PUSCH transmission, allowing the CG type 1 PUSCH transmission associated with a first TRP identifier to begin earlier than the end of the CG type 2 PUSCH transmission associated with a second TRP identifier different from the first TRP identifier.

12. The transmitter according to claim 1, characterized in that, The CG PUSCH transmission and the other CGPUSCH transmission are two PUSCH transmissions of either CG type 1 or CG type 2.

13. The transmitter according to claim 1, characterized in that, The CG PUSCH transport and the other CGPUSCH transport are CG type 2 PUSCH transports, which are scheduled through two PDCCHs associated with two different TRP identifiers.

14. The transmitter according to claim 1, characterized in that, The circuit is configured as follows: In response to the case where the CG PUSCH transmission overlaps with two DG PUSCH transmissions, no DGPUSCH transmission scheduled by PDCCH is sent. The PDCCH ends before the start of the CG PUSCH transmission with fewer than a predetermined number of symbols and is associated with the same TRP identifier as the CG PUSCH.

15. The transmitter according to claim 1, characterized in that, The circuit is configured as follows: In response to the overlap between the CG PUSCH transmission and two DG PUSCH transmissions, the PUSCH transmission is sent based on the following rules: If the shorter of the first and second durations is less than the predetermined number of symbols, then no DG PUSCH transmission scheduled by the shorter duration PDCCH is sent; and If both the first duration and the second duration exceed the predetermined number of symbols, then no CGPUSCH transmission is sent. The first duration is from the end of the PDCCH of one of the two DG PUSCH transmissions to the start of the CG PUSCH transmission, and the second duration is from the end of the PDCCH of the other of the two DG PUSCH transmissions to the start of the CG PUSCH transmission.

16. The transmitter according to claim 1, characterized in that, The circuit is configured as follows: In response to the overlap of a DG PUSCH transmission with two CG PUSCH transmissions, no DGPUSCH transmission scheduled by PDCCH is sent, which terminates with fewer than a predetermined number of symbols before the start of the CG PUSCH transmission associated with the DG PUSCH to the same TRP.

17. The transmitter according to claim 1, characterized in that, The circuit is configured as follows: In response to the overlap between a DG PUSCH transmission and two CG PUSCH transmissions, the PUSCH transmission is sent based on the following rules: If both the first duration and the second duration are less than the predetermined number of symbols, then no DG PUSCH transmission will be sent; and If either the first duration or the second duration exceeds the predetermined number of symbols, then a longer-duration CG PUSCH transmission will not be sent. The first duration is from the end of the PDCCH that schedules the DG PUSCH transmission to the start of one of the two CGPUSCH transmissions, and the second duration is from the end of the PDCCH that schedules the DG PUSCH transmission to the start of the other of the two CGPUSCH transmissions.

18. The transmitter according to claim 1, characterized in that, The circuit is configured as follows: In response to the overlap of two DG PUSCH transmissions and two CG PUSCH transmissions, wherein one of the two DG PUSCH transmissions and one of the two CG PUSCH transmissions are considered a first pair, and the other of the two DG PUSCH transmissions and the other of the two CG PUSCH transmissions are considered a second pair, DG PUSCH transmissions in the first pair that end with less than a predetermined number of symbols before the start of the corresponding CG PUSCH transmission in the first pair are not sent, and DG PUSCH transmissions in the second pair that end with less than a predetermined number of symbols before the start of the corresponding CG PUSCH transmission in the second pair are not sent.

19. The transmitter according to claim 18, characterized in that, The CGPUSCH transport and the DG PUSCH transport associated with the same TRP identifier are considered a pair.

20. The transmitter according to claim 18, characterized in that, The DG PUSCH transmission scheduled by the first-ending PDCCH and the first-starting CG PUSCH transmission are considered the first pair, and the DG PUSCH transmission scheduled by the second-ending PDCCH and the second-starting CG PUSCH transmission are considered the second pair.

21. A receiver for communication in a new radio (NR) communication system, characterized in that, The receiver includes: One or more interfaces for communicating with multiple Transmitter-Receiver Points (TRPs) within the NR communication system; and The circuit is configured as follows: Send the scheduling-free authorization CG configuration, which is used to configure the CG type for Physical Uplink Shared Channel (PUSCH) transmission; and Receive the PUSCH transmission accompanying the CG, wherein the CG PUSCH transmission is associated with one of a plurality of TRPs of an active uplink bandwidth portion (BWP) of the serving cell. The circuit is characterized in that it is configured as follows: The transmission transmits scheduling information about the CG PUSCH transmission and another CGPUSCH transmission, which are scheduled across the multiple TRPs and associated with different TRP identifiers, wherein the scheduling information shows that the end of the activation control of the CG PUSCH transmission is later than the end of the activation control of the other CG PUSCH transmission, allowing the CG PUSCH transmission to start earlier than the end of the other CGPUSCH transmission.

22. A communication method applied to a transmitter in a new radio (NR) communication system, characterized in that, The method includes: It communicates with multiple Transmitter Receiving Points (TRPs) within the NR communication system; Receive scheduling-free authorized CG configuration, which is used to configure the CG type for Physical Uplink Shared Channel (PUSCH) transmission; Send a PUSCH transmission accompanying the CG, wherein the CG PUSCH transmission is associated with one of a plurality of TRPs of an active uplink bandwidth portion (BWP) of the serving cell; and Receive scheduling information about the CG PUSCH transmission and another CGPUSCH transmission, which are scheduled across the multiple TRPs and associated with different TRP identifiers, wherein the scheduling information shows that the end of the activation control of the CG PUSCH transmission is later than the end of the activation control of the other CG PUSCH transmission, allowing the CG PUSCH transmission to start earlier than the end of the other CGPUSCH transmission.

23. A communication method applied to a receiver in a new radio (NR) communication system, characterized in that, The method includes: It communicates with multiple Transmitter Receiving Points (TRPs) within the NR communication system; Send the scheduling-free authorization CG configuration, which is used to configure the CG type for Physical Uplink Shared Channel (PUSCH) transmission; Receive the PUSCH transmission accompanying the CG, wherein the CG PUSCH transmission is associated with one of a plurality of TRPs of an active uplink bandwidth portion (BWP) of the serving cell; and The transmission transmits scheduling information about the CG PUSCH transmission and another CGPUSCH transmission, which are scheduled across the multiple TRPs and associated with different TRP identifiers, wherein the scheduling information shows that the end of the activation control of the CG PUSCH transmission is later than the end of the activation control of the other CG PUSCH transmission, allowing the CG PUSCH transmission to start earlier than the end of the other CGPUSCH transmission.

Images