WO2026031212A1 - Pusch sending method and apparatus, pusch receiving method and apparatus, and communication system - Google Patents

Abstract

Provided in the embodiments of the present application are a PUSCH sending method and apparatus, a PUSCH receiving method and apparatus, and a communication system. The PUSCH sending method comprises: a terminal device receiving configuration information at least used for configuring a first time domain resource and/or a second time domain resource, wherein in the first time domain resource, a first frequency domain resource is used for an uplink and a second frequency domain resource is used for a downlink, and the second time domain resource is outside the first time domain resource; receiving a configured grant (CG) configuration, wherein for a CG, whether a CG PUSCH has a corresponding HARQ process ID is related to the first time domain resource and/or the second time domain resource; and the terminal device sending one or more CG PUSCHs having a corresponding HARQ process ID.

Description

PUSCH transmission and reception methods, apparatus, and communication systems Technical Field

This application relates to the field of communication technology.

Background Technology

In traditional technologies, for Time Division Duplex (TDD) frequency bands, uplink transmission can only occur within the uplink time slot. When a limited or small uplink time slot is allocated, there will be problems with small uplink coverage, limited capacity, and high latency. For Frequency Division Duplex (FDD) frequency bands, uplink transmission can only occur on the uplink carrier. When a limited or small uplink carrier bandwidth is allocated, there may also be problems with small uplink coverage, limited capacity, and high latency.

It should be noted that the above introduction to the technical background is only for the purpose of providing a clear and complete explanation of the technical solutions of this application and facilitating understanding by those skilled in the art. It should not be assumed that these technical solutions are known to those skilled in the art simply because they have been described in the background section of this application.

Summary of the Invention

To improve uplink capacity and coverage, and reduce uplink latency, network devices can operate in full-duplex mode at certain times in the downlink band of TDD or FDD bands. For example, network devices can simultaneously receive and transmit on different frequency domain resources within the corresponding carriers of the downlink band (in TDD or FDD bands). This operating mode is called Subband Non-overlapping Full Duplex (SBFD), but is not limited to this. For convenience, the time domain resources under this operating mode will be referred to as the first time domain resource (or SBFD symbol), and other time domain resources will be referred to as the second time domain resource (or non-SBFD symbol).

On the other hand, multiple Physical Uplink Shared Channels (PUSCHs) can be scheduled using Configured Grant (CG) information, such as Type 1 CG PUSCHs or Type 2 CG PUSCHs. The terminal device can provide one or more CG PUSCH configurations, with each CG PUSCH configuration corresponding to multiple PUSCHs. For the terminal device, the scheduled PUSCHs may be on SBFD symbols or non-SBFD symbols. Currently, there is no solution for how to allocate Hybrid Automatic Repeat ReQuest (HARQ) process IDs and how to send/receive these PUSCHs.

To address at least one of the above-mentioned problems, embodiments of this application provide a PUSCH transmission and reception method, apparatus, and communication system.

According to one aspect of the embodiments of this application, a PUSCH transmission method is provided, including:

The terminal device receives configuration information for configuring at least a first time domain resource and/or a second time domain resource; wherein, in the first time domain resource, a first frequency domain resource is used for uplink and a second frequency domain resource is used for downlink, and the second time domain resource is outside the first time domain resource;

The terminal device receives a configuration grant (CG) configuration, wherein, for a configuration grant, whether a configuration grant PUSCH has a corresponding HARQ process ID is related to the first time-domain resource and/or the second time-domain resource; and

The terminal device sends one or more configuration authorization PUSCHs from among the configuration authorization PUSCHs with corresponding HARQ process IDs.

According to another aspect of the embodiments of this application, a PUSCH transmitting apparatus is provided, comprising:

A receiver receives configuration information for configuring at least a first time-domain resource and/or a second time-domain resource; wherein, in the first time-domain resource, a first frequency-domain resource is used for uplink and a second frequency-domain resource is used for downlink, and the second time-domain resource is outside the first time-domain resource; receives configuration grant (CG) configuration, wherein, for configuration grant, whether a configuration grant PUSCH has a corresponding HARQ process ID is related to the first time-domain resource and/or the second time-domain resource; and

The transmitter sends one or more configuration authorization PUSCHs from among the configuration authorization PUSCHs with corresponding HARQ process IDs.

According to another aspect of the embodiments of this application, a PUSCH receiving method is provided, including:

The network device sends configuration information for configuring at least a first time domain resource and/or a second time domain resource; wherein, in the first time domain resource, a first frequency domain resource is used for uplink and a second frequency domain resource is used for downlink, and the second time domain resource is outside the first time domain resource;

The network device sends a configuration grant (CG) configuration, wherein, for a configuration grant, whether a configuration grant PUSCH has a corresponding HARQ process ID is related to the first time domain resource and/or the second time domain resource; and

The network device receives one or more configuration authorization PUSCHs from the configuration authorization PUSCHs that have corresponding HARQ process IDs.

According to another aspect of the embodiments of this application, a PUSCH receiving device is provided, comprising:

A transmitter that transmits configuration information for configuring at least a first time-domain resource and/or a second time-domain resource; wherein, in the first time-domain resource, a first frequency-domain resource is used for uplink and a second frequency-domain resource is used for downlink, and the second time-domain resource is outside the first time-domain resource; and transmits configuration grant (CG) configuration, wherein, for configuration grant, a Whether a configuration-authorized PUSCH has a corresponding HARQ process ID is related to the first time-domain resource and/or the second time-domain resource; and

The receiver receives one or more configuration authorization PUSCHs from the configuration authorization PUSCHs that have the corresponding HARQ process ID.

According to another aspect of the embodiments of this application, a communication system is provided, including:

A terminal device receives configuration information for configuring at least a first time-domain resource and/or a second time-domain resource; wherein, in the first time-domain resource, a first frequency-domain resource is used for uplink and a second frequency-domain resource is used for downlink, and the second time-domain resource is outside the first time-domain resource; receives configuration grant (CG) configuration, wherein, for configuration grant, whether a configuration grant PUSCH has a corresponding HARQ process ID is related to the first time-domain resource and/or the second time-domain resource; and sends one or more configuration grant PUSCHs among configuration grant PUSCHs having corresponding HARQ process IDs;

A network device that sends configuration information for configuring at least a first time domain resource and/or a second time domain resource; sends configuration authorization (CG) configuration; and receives at least one PUSCH from the terminal device.

One of the beneficial effects of this application's embodiments is that the terminal device sends one or more configuration grant PUSCHs among those with corresponding HARQ process IDs; wherein, for configuration grants, whether a configuration grant PUSCH has a corresponding HARQ process ID is related to the first time domain resource and/or the second time domain resource. Therefore, the network device can operate in full-duplex mode (simultaneous reception and transmission), and the terminal device can also utilize the corresponding resources to send and receive signals when the network device is operating in full-duplex mode. This can improve uplink transmission capacity and coverage, reduce uplink transmission latency, and increase resource allocation flexibility and resource utilization.

Specific embodiments of this application are disclosed in detail with reference to the following description and accompanying drawings, indicating how the principles of this application can be adopted. It should be understood that the embodiments of this application are not limited in scope. Within the spirit and scope of the appended claims, embodiments of this application include many changes, modifications, and equivalents.

Features described and/or illustrated for one embodiment may be used in the same or similar manner in one or more other embodiments, combined with or replacing features in other embodiments.

It should be emphasized that the term "including/comprises" as used herein refers to the presence of a feature, whole, step, or component, but does not exclude the presence or addition of one or more other features, wholes, steps, or components.

Attached Figure Description

The elements and features described in one drawing or embodiment of this application may be combined with elements and features shown in one or more other drawings or embodiments. Furthermore, similar reference numerals are used in the drawings. The figures show corresponding components and can be used to indicate corresponding components used in more than one embodiment.

The accompanying drawings, which form part of the specification, are used to provide a further understanding of the embodiments of this application and illustrate the implementation methods of this application, together with the textual description, to explain the principles of this application. Obviously, the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without creative effort. In the drawings:

Figure 1 is a schematic diagram of a communication system according to an embodiment of this application;

Figure 2 is a schematic diagram of a PUSCH transmission method according to an embodiment of this application;

Figure 3 is an example diagram of time-domain resources according to an embodiment of this application;

Figure 4 is an example diagram of uplink available PRB according to an embodiment of this application;

Figure 5 is another example diagram of uplink available PRB in an embodiment of this application;

Figure 6 is another example diagram of uplink available PRB in an embodiment of this application;

Figure 7 is an example diagram of downlink available PRB according to an embodiment of this application;

Figure 8 is another example diagram of downlink available PRB in an embodiment of this application;

Figure 9 is another example diagram of downlink available PRB in an embodiment of this application;

Figure 10 is an example diagram of PUSCH scheduling according to an embodiment of this application;

Figure 11 is another example diagram of PUSCH scheduling according to an embodiment of this application;

Figure 12 is another example diagram of PUSCH scheduling according to an embodiment of this application;

Figure 13 is another example diagram of PUSCH scheduling according to an embodiment of this application;

Figure 14 is an example diagram of PUSCH being sent according to an embodiment of this application;

Figure 15 is another example diagram of PUSCH being sent according to an embodiment of this application;

Figure 16 is another example diagram of PUSCH being sent according to an embodiment of this application;

Figure 17 is another example diagram of PUSCH being sent according to an embodiment of this application;

Figure 18 is another example diagram of PUSCH being sent according to an embodiment of this application;

Figure 19 is another example diagram of PUSCH being sent according to an embodiment of this application;

Figure 20 is another example diagram of PUSCH being sent according to an embodiment of this application;

Figure 21 is another example diagram of PUSCH being sent according to an embodiment of this application;

Figure 22 is a schematic diagram of a PUSCH receiving method according to an embodiment of this application;

Figure 23 is a schematic diagram of a PUSCH transmitting device according to an embodiment of this application;

Figure 24 is a schematic diagram of a PUSCH receiving device according to an embodiment of this application;

Figure 25 is a schematic diagram of a network device according to an embodiment of this application;

Figure 26 is a schematic diagram of a terminal device according to an embodiment of this application.

Detailed Implementation

Referring to the accompanying drawings, the foregoing and other features of this application will become apparent from the following description. Specific embodiments of this application are specifically disclosed in the description and drawings, illustrating partial implementations in which the principles of this application may be employed. It should be understood that this application is not limited to the described embodiments; rather, it includes all modifications, variations, and equivalents falling within the scope of the appended claims.

In the embodiments of this application, the terms "first," "second," etc., are used to distinguish different elements by name, but do not indicate the spatial arrangement or chronological order of these elements, and these elements should not be limited by these terms. The term "and/or" includes any one or more of the terms listed in association and all combinations thereof. The terms "comprising," "including," "having," etc., refer to the presence of the stated features, elements, components, or assemblies, but do not exclude the presence or addition of one or more other features, elements, components, or assemblies.

In the embodiments of this application, the singular forms "a," "the," etc., including the plural forms, should be broadly understood as "a kind" or "a class" rather than limited to the meaning of "an." Furthermore, the term "the" should be understood to include both the singular and plural forms, unless the context explicitly indicates otherwise. Additionally, the term "according to" should be understood as "at least partially based on…," and the term "based on" should be understood as "at least partially based on…," unless the context explicitly indicates otherwise.

In the embodiments of this application, the term "communication network" or "wireless communication network" may refer to a network that conforms to any of the following communication standards, such as Long Term Evolution (LTE), LTE-Advanced (LTE-A), Wideband Code Division Multiple Access (WCDMA), High-Speed Packet Access (HSPA), etc.

Furthermore, communication between devices in a communication system can be carried out according to communication protocols at any stage, including but not limited to the following communication protocols: 1G (generation), 2G, 2.5G, 2.75G, 3G, 4G, 4.5G and future 5G, New Radio (NR), 6G, etc., and/or other currently known or future communication protocols.

In the embodiments of this application, the term "network device" refers, for example, to a device in a communication system that connects a terminal device to a communication network and provides services to that terminal device. Network devices may include, but are not limited to, the following devices: base station (BS), access point (AP), transceiver node (TRP), broadcast transmitter, mobile management entity (MME), gateway, server, radio network controller (RNC), base station controller (BSC), etc.

Base stations can include, but are not limited to: NodeBs (or NBs), evolved NodeBs (eNodeBs or eNBs), and 5G base stations (gNBs), IAB hosts, etc. They can also include Remote Radio Heads (RRHs), Remote Radio Units (RRUs), relays, or low-power nodes (e.g., femto, pico, etc.). The term "base station" can include some or all of their functions, and each base station can provide communication coverage to a specific geographic area. The term "cell" can refer to a base station and/or its coverage area, depending on the context in which the term is used.

In the embodiments of this application, the term "User Equipment" (UE) refers to a device that accesses a communication network and receives network services through a network device, and can also be called "Terminal Equipment" (TE). Terminal equipment can be fixed or mobile, and can also be called a mobile station (MS), terminal, user, subscriber station (SS), access terminal (AT), station, mobile terminal (MT), etc.

Terminal devices may include, but are not limited to, the following devices: cellular phones, personal digital assistants (PDAs), wireless modems, wireless communication devices, handheld devices, machine-type communication devices, laptops, cordless phones, smartphones, smartwatches, digital cameras, etc.

For example, in scenarios such as the Internet of Things (IoT), terminal devices can also be machines or devices for monitoring or measurement, such as including but not limited to: machine-type communication (MTC) terminals, vehicle-mounted communication terminals, device-to-device (D2D) terminals, machine-to-machine (M2M) terminals, and so on.

Furthermore, the terms "network side" or "network equipment side" refer to one side of the network, which can be a base station or include one or more network devices as described above. The terms "user side," "terminal side," or "terminal equipment side" refer to the side of the user or terminal, which can be a UE or include one or more terminal devices as described above. Unless otherwise specified, "equipment" can refer to either network equipment or terminal equipment.

In the following description, without confusion, the terms “uplink control signal” and “uplink control information (UCI)” or “physical uplink control channel (PUCCH)” are used interchangeably, as are the terms “uplink data signal” and “uplink data information” or “physical uplink shared channel (PUSCH)”.

The terms “downlink control signal” and “downlink control information (DCI)” or “physical downlink control channel (PDCCH)” are interchangeable, as are the terms “downlink data signal” and “downlink data information (PDSCH)” or “physical downlink shared channel (PDSCH)”.

Additionally, uplink signals can include uplink data signals and/or uplink control signals and/or PRACH and/or SRS, etc., and can also be referred to as uplink transmission (UL transmission), uplink information, or uplink channel. Sending/receiving uplink transmission on uplink resources can be understood as using that uplink resource to send/receive the uplink transmission. Downlink signals can include downlink data signals and/or downlink control signals and/or synchronization signals (SS, such as PSS/SSS) and/or broadcast channel (PBCH) and/or SSB (SS/PBCH block, including PSS, SSS, and PBCH and their DMRS) and/or CSI-RS, etc., and can also be referred to as downlink transmission (DL transmission), downlink information, or downlink channel. Sending/receiving downlink transmission on downlink resources can be understood as using that downlink resource to send/receive the downlink transmission.

In the embodiments of this application, higher-layer signaling may be, for example, Radio Resource Control (RRC) signaling; RRC signaling may include, for example, RRC messages, such as broadcast/public RRC messages/signaling (e.g., Master Information Block (MIB), system information), dedicated RRC messages/signaling; or RRC information elements (RRC IE); or information fields (or information fields included in information fields) included in RRC messages or RRC information elements. Higher-layer signaling may also be, for example, Medium Access Control (MAC) signaling; or referred to as MAC control elements (MAC CE). However, this application is not limited to these. The names of signaling (e.g., RRC messages, information elements IE, information fields, higher-layer parameters, etc.) used in the embodiments of this application are only examples and may be other names, and the embodiments of this application are not intended to limit them.

In the embodiments of this application, "multiple" refers to at least two, or two or more.

In this application embodiment, "predefined" refers to what is specified by the protocol or determined according to the rules specified by the protocol, and does not require additional configuration. "Configuration/instruction" refers to what the network device directly or indirectly configures/instructs through higher-layer signaling and/or physical layer signaling. Configuration/instruction can be achieved by introducing higher-layer parameters into the higher-layer signaling. Higher-layer parameters refer to information fields and/or information elements/information units/information cells (IEs) in the higher-layer signaling. Physical layer signaling refers to, for example, control information (DCI) carried by the physical downlink control channel or control information carried by the sequence, but is not limited to these.

For ease of description, the following description uses a base station as an example of an access network device. In the following descriptions, "if…", "in the case of…", and "when…" are used interchangeably unless there is confusion. For resources in the frequency domain, "carrier" and "resource grid" are interchangeable; "subcarrier spacing configuration" (μ) and "subcarrier spacing (SCS)" (Δf) are interchangeable; "subcarrier spacing" and "numerology" are interchangeable; "resource block", "RB" and "PRB", "physical resource block", and "common resource block (CRB, Common RB)" are interchangeable; "configuration/indication/providing/given" are interchangeable; "index" and "identifier (ID)" are interchangeable.

The following examples illustrate the scenarios of embodiments of this application, but this application is not limited thereto.

Figure 1 is a schematic diagram of a communication system according to an embodiment of this application, illustrating the use of terminal equipment and network equipment as examples. As shown in Figure 1, for example, the communication system 100 may include a network device 101 and terminal devices 102 and 103. For simplicity, Figure 1 is illustrated using only two terminal devices and one network device as an example, but the embodiments of this application are not limited thereto.

In this embodiment of the application, network device 101 and terminal devices 102 and 103 can transmit existing services or services that can be implemented in the future. For example, these services may include, but are not limited to: enhanced mobile broadband (eMBB), massive machine-type communication (mMTC), and ultra-reliable and low-latency communication (URLLC), etc.

Terminal device 102 can send data to network device 101, for example, using authorized or unauthorized transmission methods. Network device 101 can receive data sent by one or more terminal devices 102 and provide feedback to terminal devices 102, such as ACK/NACK confirmation information. Based on the feedback information, terminal device 102 can confirm the end of the transmission process, or can initiate new data transmission, or can retransmit the data.

Network device 101 can send data to terminal device 102 and/or terminal device 103 using unicast, multicast, or broadcast. Terminal device 102 can receive data sent by one or more network devices (e.g., dual-connection or multi-connection) via a downlink or by terminal device 103 via a sidelink.

It is worth noting that Figure 1 shows that both terminal devices 102 and 103 are within the coverage area of network device 101, but this application is not limited to this. Both terminal devices 102 and 103 may be outside the coverage area of network device 101, or one terminal device 102 may be within the coverage area of network device 101 while the other terminal device 103 may be outside the coverage area of network device 101.

In the following description, transmitting or receiving a PUCCH can be understood as transmitting or receiving uplink control information carried by the PUCCH; transmitting or receiving a PUSCH can be understood as transmitting or receiving uplink data carried by the PUSCH. Furthermore, the content within parentheses indicates that it is interpretable or optional, and "/" indicates "and/or," and this application is not limited thereto. Various embodiments of this application will be described below with reference to the accompanying drawings. These embodiments are merely exemplary and not intended to limit the scope of this application.

First aspect of the embodiments

This application provides a PUSCH transmission method, which is described from the perspective of the terminal device.

Figure 2 is a schematic diagram of a PUSCH transmission method according to an embodiment of this application. As shown in Figure 2, the method includes:

201, the terminal device receives configuration information for configuring at least a first time domain resource and/or a second time domain resource; wherein, in the first time domain resource, a first frequency domain resource is used for uplink and a second frequency domain resource is used for downlink, and the second... Temporal resources are outside the first temporal resource.

202, the terminal device receives a configuration authorization (CG) configuration, wherein, for a configuration authorization, whether a configuration authorization PUSCH has a corresponding HARQ process ID is related to the first time-domain resource and/or the second time-domain resource; and

203, the terminal device sends one or more configuration authorization PUSCHs with corresponding HARQ process IDs.

It is worth noting that Figure 2 above is only an illustrative description of the embodiments of this application, but this application is not limited thereto. For example, the execution order between various operations can be appropriately adjusted, and other operations can be added or some operations can be removed. Those skilled in the art can make appropriate modifications based on the above content, and are not limited to the description in Figure 2 above.

In some embodiments, the terminal device may be an SBFD-aware device; however, this application is not limited thereto. For example, during the initial access process and/or random access process and/or during capability information reporting, the terminal device indicates to the network device that the terminal device is an SBFD-aware device (SBFD-aware UE).

For example, an SBFD-aware UE has capabilities related to SBFD operation, including one or more of the following: being able to know the SBFD configuration, such as the configuration of SBFD time-domain resources (e.g., SBFD symbols) and frequency-domain resources (e.g., UL subband/UL usable RBs, DL subbands/DL usable RBs); and being able to transmit uplink signals on (DL)SBFD symbols.

The following is an illustrative description of the time-domain resources involved in the embodiments of this application.

In some embodiments, the first time-domain resource is a time-domain resource used to support full-duplex (e.g., SBFD) operation, and the second time-domain resource is a time-domain resource not used to support full-duplex operation (or, not used for full-duplex operation, e.g., non-SBFD), and the first time-domain resource and the second time-domain resource are in different time positions.

In some embodiments, in the first time domain resource, the network device simultaneously receives and transmits in different frequency domain resources of the corresponding carrier (downlink frequency band of TDD band or FDD band), while in the second time domain resource, the network device only receives or transmits in the carrier.

In some embodiments, the first time-domain resource refers to the time-domain resource that has/corresponds to SBFD subbands, or the time-domain resource in which the SBFD subbands reside, and the second time-domain resource refers to the time-domain resource that does not have/correspond to SBFD subbands. SBFD subbands include, for example, DL subband(s) and/or uplink subband(s).

In some embodiments, time resource units include, for example, symbols and/or slots and/or sub-slots and/or mini-slots and/or symbol groups and/or slot groups and/or subframes and/or frames and/or milliseconds and/or s, etc., and are not limited thereto. For example, sub-slots and mini-slots include symbols... The number of symbols is less than or equal to the number of time slots included in the time slot. A symbol group includes one or more (continuous or discontinuous) symbols, and a time slot group includes one or more (continuous or discontinuous) time slots, but is not limited thereto.

In some embodiments, the first time-domain resource may also be referred to as an SBFD resource, and the second time-domain resource may also be referred to as a non-SBFD resource. SBFD resources include, for example, SBFD time resource units, such as SBFD time slots and/or symbols, and non-SBFD resources include, for example, non-SBFD time resource units, such as non-SBFD time slots and/or symbols.

In some embodiments, a downlink symbol is, for example, a symbol configured as a downlink by tdd-UL-DL-ConfigurationCommon, an uplink symbol is, for example, a symbol configured as an uplink by tdd-UL-DL-ConfigurationCommon, and a flexible symbol is, for example, a symbol that is neither configured as a downlink nor as an uplink by tdd-UL-DL-ConfigurationCommon, or a symbol configured as flexible by tdd-UL-DL-ConfigurationCommon, or a symbol configured as flexible by tdd-UL-DL-ConfigurationCommon when provided, or all symbols when tdd-UL-DL-ConfigurationCommon is not provided (no uplink/downlink subband configured).

In some embodiments, the SBFD symbol is, for example, a symbol having SBFD/DL/UL subbands, including, but not limited to, DL SBFD symbols and/or Flexible SBFD symbols. For example, when only one TDD-UL-DL pattern is configured, the period is the same as the TDD-UL-DL pattern period configured by dl-UL-Transmission Periodicity in TDD-UL-DL-ConfigCommon; when two TDD-UL-DL patterns are configured, the period is the same as the sum of the two TDD-UL-DL pattern periods configured by dl-UL-Transmission Periodicity in TDD-UL-DL-ConfigCommon.

In some embodiments, a non-SBFD symbol is a symbol other than an SBFD symbol, or a symbol other than an SBFD symbol and a first spacing symbol, such as a symbol that does not have SBFD/DL/UL subbands. Examples include Full-DL symbols, and/or Full-UL symbols, and/or Full-flexible symbols, and/or a first spacing symbol; wherein the first spacing symbol is a spacing symbol between the non-SBFD symbol and the SBFD symbol, but is not limited thereto.

In some embodiments, the DL SBFD symbol/SBFD DL symbol is a symbol that is configured within a DL symbol or is configured as a downlink SBFD symbol by tdd-UL-DL-ConfigurationCommon.

In some embodiments, the Flexible SBFD symbol/SBFD Flexible symbol is a symbol that is configured within a Flexible symbol, or is configured as a Flexible SBFD symbol by tdd-UL-DL-ConfigurationCommon.

In some embodiments, a Full-DL symbol/DL-only symbol/DL non-SBFD symbol/non-SBFD DL symbol is a non-SBFD symbol configured within a DL symbol, or a non-SBFD symbol configured as a downlink by tdd-UL-DL-ConfigurationCommon.

In some embodiments, it is assumed that the SBFD symbol will not be configured in the UL symbol, and the Full-UL symbol is equivalent to the UL symbol.

In some embodiments, the Full-UL symbol/UL-only symbol/UL non-SBFD symbol/non-SBFD UL symbol is a non-SBFD symbol configured within a UL symbol, or a non-SBFD symbol configured as an uplink by tdd-UL-DL-ConfigurationCommon.

In some embodiments, the Full-flexible symbol/Flexible-only symbol/Flexible non-SBFD symbol/non-SBFD Flexible symbol is a symbol that is: a non-SBFD symbol configured within a flexible symbol, or a non-SBFD symbol configured as flexible by tdd-UL-DL-ConfigurationCommon, or a non-SBFD symbol that is neither configured as downlink nor uplink by tdd-UL-DL-ConfigurationCommon, or a non-SBFD symbol configured as flexible. The meaning of the flexible symbol can also be referred to the foregoing embodiments.

In some embodiments, a time slot may include SBFD symbols and non-SBFD symbols, or only SBFD symbols, or only non-SBFD symbols.

Figure 3 is an example diagram of the time-domain resources according to an embodiment of this application. As shown in Figure 3, a period may include multiple different symbols. Figure 3 exemplarily illustrates the time-domain resources of an embodiment of this application, but is not limited thereto.

The frequency domain resources involved in the embodiments of this application will be illustrated below.

In the first time domain resource, the first frequency domain resource is used for uplink and the second frequency domain resource is used for downlink. For example, the first frequency domain resource is the uplink subband (UL subband) in an SBFD symbol, and the second frequency domain resource is the downlink subband (DL subband) in an SBFD symbol. The terms "subband" and "frequency domain resource set" are interchangeable.

In some embodiments, the first frequency domain resource and the second frequency domain resource are in a time division duplex (TDD) band (or paired spectrum), or in the downlink band of a frequency division duplex (FDD) band (or the uplink band of an FDD band), or in the supplementary uplink (SUL) band.

In some embodiments, for UL, the cell-specific frequency location of the UL subband can be configured individually for each SCS configuration (in the SCS-SpecificCarrierList for UL), or in other words, the cell-specific UL subband can be configured individually. For each SCS configuration, the reference starting PRB is determined by the SCS configuration and the offsetToCarrier corresponding to that subcarrier spacing. For example, one or at most one UL subband can be configured, but it is not limited to this.

In some embodiments, the uplink available PRBs/RBs for a UL BWP can be determined as the intersection between the (cell-specific) UL subband and the UL BWP (in the SBFD symbol), i.e., implicitly configured, for example referred to as the first uplink available PRBs.

In some embodiments, the uplink available PRBs of a UL BWP are determined based on the UL subbands configured with the same SCS as the UL BWP. For example, if a UL BWP has an SCS of 15 kHz, its corresponding UL available PRBs are the intersection of the UL BWP and the uplink subbands configured with the 15 kHz SCS. If a UL BWP has an SCS of 30 kHz, its corresponding UL available PRBs are the intersection of the UL BWP and the uplink subbands configured with the 30 kHz SCS.

Figure 4 is an example diagram of uplink usable PRBs according to an embodiment of this application. As shown in Figure 4, UL BWP and UL subband overlap, and UL usable PRBs are the intersection of the two (in the SBFD symbol).

Figure 5 is another example diagram of uplink usable PRBs in an embodiment of this application. As shown in Figure 5, the UL BWP includes the UL subband in the frequency domain, and the UL usable PRBs are the intersection between the two (in the SBFD symbol).

In Figures 4 and 5, the UL subbands represent, for example, the uplink subbands of the SCS configuration corresponding to the UL BWP, but this application is not limited thereto.

In some embodiments, the uplink available PRBs/RBs for the UL BWP can be explicitly configured in the UL BWP (in the SBFD notation), for example referred to as second uplink available PRBs.

In some embodiments, when both a first uplink available PRBs and a second uplink available PRBs are configured, the second uplink available PRBs are used.

In some embodiments, a second set of uplink available PRBs is configured based on a first set of available uplink PRBs. For example, if unavailable PRBs from the first set of available uplink PRBs are configured, the second set of available uplink PRBs includes all PRBs from the first set of available uplink PRBs except for those unavailable PRBs. As another example, if other available PRBs besides the first set of available uplink PRBs are configured, the second set of available uplink PRBs includes both the first set of available uplink PRBs and those other available PRBs.

Figure 6 is another example diagram of uplink usable PRBs in an embodiment of this application. As shown in Figure 6, UL usable PRBs are explicitly configured in the UL BWP.

In some embodiments, for DL, the cell-specific frequency location of the DL subband can be configured individually for each SCS configuration (in the SCS-SpecificCarrierList), or in other words, the cell-specific UL subband can be configured individually. For each SCS configuration, the reference starting PRB is determined by the SCS configuration and the offsetToCarrier corresponding to that subcarrier spacing. For example, one or two DL subbands can be configured, but this is not a limitation.

In some embodiments, for the downlink of a DL BWP, PRB/RB (DL usable PRBs/RBs) can be used. The intersection of the (cell-specific) DL subband and DL BWP (in the SBFD symbol) is determined, i.e., implicitly configured, for example, as the first downlink available PRBs.

In some embodiments, the downlink available PRBs of a DL BWP are determined based on the UL subband configured with the same SCS as the DL BWP. For example, if the SCS of a DL BWP is 15 kHz, then its corresponding DL available PRBs are the intersection of the DL BWP and the downlink subbands configured with the 15 kHz SCS. If the SCS of a DL BWP is 30 kHz, then its corresponding DL available PRBs are the intersection of the DL BWP and the downlink subbands configured with the 30 kHz SCS.

Figure 7 is an example diagram of downlink usable PRBs according to an embodiment of this application. As shown in Figure 7, DL BWP and DL subband overlap, and DL usable PRBs are the intersection of the two (in SBFD notation).

Figure 8 is another example diagram of downlink usable PRBs according to an embodiment of this application. As shown in Figure 8, the DL BWP includes the DL subband in the frequency domain, and the DL usable PRBs are the intersection between the two (in the SBFD symbol).

In Figures 7 and 8, the DL subband represents, for example, the downlink subband of the SCS configuration corresponding to the DL BWP, but this application is not limited thereto.

In some embodiments, the downlink available PRBs/RBs for the DL BWP can be explicitly configured in the DL BWP (in the SBFD symbol), for example referred to as second downlink available PRBs.

In some embodiments, when both a first downlink available PRBs and a second downlink available PRBs are configured, the second downlink available PRBs are used.

In some embodiments, a second set of downlink available PRBs is configured based on a first set of available downlink PRBs. For example, if unavailable PRBs from the first set of available downlink PRBs are configured, the second set of available downlink PRBs includes all PRBs from the first set of available downlink PRBs except for those unavailable PRBs. As another example, if other available PRBs besides the first set of available downlink PRBs are configured, the second set of available downlink PRBs includes both the first set of available downlink PRBs and those other available PRBs.

Figure 9 is another example diagram of downlink usable PRBs according to an embodiment of this application. As shown in Figure 9, DL usable PRBs are explicitly configured in the DL BWP.

The time-frequency resources have been illustrated above. The PUSCH of the embodiments of this application will be illustrated below.

In this embodiment, the terminal device may provide one or more CG PUSCH configurations (or CG configurations), each CG PUSCH configuration independently provides time-frequency domain resource allocation, and periodically or semi-persistently schedules PUSCH. Configuration Grant PUSCH (CG PUSCH) may also be called configuration uplink grant or configuration PUSCH grant; CG configuration is, for example, ConfiguredGrantConfig, but this application is not limited thereto.

In some embodiments, configuration authorization includes a first configuration authorization (configuration authorization Type 1) and/or a second configuration authorization (configuration authorization Type 2). For the first configuration authorization, PUSCH transmission is half-processed. The static configuration is performed after receiving the first higher-layer parameter (configuredGrantConfig including rrc-ConfiguredUplinkGrant), without needing to detect the uplink grant in the DCI; for the second configuration grant, after receiving the second higher-layer parameter (configuredGrantConfig not including rrc-ConfiguredUplinkGrant), the PUSCH transmission is semi-persistently scheduled by the uplink grant in the valid active DCI (used to activate the second grant configuration).

In some embodiments, the configuration authorization has multiple consecutive configuration authorization PUSCHs in a period, and/or, the configuration authorization has multiple non-consecutive configuration authorization PUSCHs in a period. For example, the configuration authorization is a Multi-PUSCH configuration authorization, which can be the first configuration authorization or the second configuration authorization described above. The corresponding CG PUSCH configuration includes information indicating the number of configuration authorization PUSCHs in a period (or the number of consecutive slots for CG PUSCH transmission occasions in a period), such as nrofSlotsInCG-Period.

In some embodiments, for a Type 1 CG PUSCH, frequency domain resource allocation (FDRA) can be provided via RRC; for a Type 2 CG PUSCH, frequency domain resource allocation (FDRA) can be provided via RRC and/or MAC CE and/or DCI. This application is not limited thereto.

The following explanation focuses on a single CG PUSCH configuration. The positions of CG PUSCHs within the same or different cycles corresponding to a single CG PUSCH configuration can be categorized as follows:

--All are within the SBFD symbol, that is, none overlap with the non-SBFD symbol;

--All are within the non-SBFD symbol, that is, none overlap with the SBFD symbol;

--PUSCH in SBFD symbols and PUSCH in non-SBFD symbols, excluding PUSCH that overlap with both SBFD symbols and non-SBFD symbols;

--Including PUSCHs that overlap with both SBFD and non-SBFD symbols, including or excluding PUSCHs in SBFD symbols and/or in non-SBFD symbols.

It is worth noting that the above division has been made for ease of description, but this application is not limited to this. For example, it may include only some of the above cases, or it may combine two or more of them, or it may add other cases.

In some embodiments, frequency domain resource allocation (FDRA) may be provided separately for PUSCHs that overlap with SBFD symbols and PUSCHs in non-SBFD symbols. Specifically, PUSCHs that overlap with SBFD symbols include PUSCHs in SBFD symbols and/or a subset of PUSCHs in SBFD symbols and another subset of PUSCHs in non-SBFD symbols.

For example, separate FDRA configurations/indications/interpretations can be provided for SBFD symbols and non-SBFD symbols. For instance, for CG Type 1, the CG configuration includes a frequency domain. For CG Type 2, the DCI used to activate the CG includes an FDRA field in the Allocation field. Accordingly, the UE determines the frequency domain resources of the PUSCH overlapping with SBFD symbols and the frequency domain resources of the PUSCH in non-SBFD symbols based on the same information field. For another example, for CG Type 1, the CG configuration includes two Frequency Domain Allocation fields. For CG Type 2, the DCI used to activate the CG includes two FDRA fields, with each field indicating the frequency domain resources of the PUSCH overlapping with SBFD symbols and the frequency domain resources of the PUSCH in non-SBFD symbols, respectively.

For example, an FDRA configuration/indications is provided for a symbol type (SBFD symbol or non-SBFD symbol), and then RB offset(s) configuration/indication/determination is used to determine the resources for other symbol types. For instance, for CG Type 1, the CG configuration includes a frequency domain allocation field, and for CG Type 2, the DCI used to activate the CG includes an FDRA field indicating the frequency domain resources of the PUSCH in the non-SBFD symbol. For PUSCHs that overlap with SBFD symbols, the UE determines the frequency domain resources based on the RB offset(s) between the UL usable PRBs (the starting PRB) and the corresponding UL BWP (the starting PRB). Alternatively, the UE determines the frequency domain resources of the PUSCH overlapping with the SBFD symbol based on the RB offset(s) between the starting PRB of the PUSCH overlapping with the SBFD symbol and the starting PRB of the frequency domain resources of the PUSCH in the non-SBFD symbol, which is indicated by the base station (e.g., via higher-layer signaling or the DCI).

Figure 10 is an example diagram of PUSCH scheduling according to an embodiment of this application. As shown in Figure 10, for example, the resources of PUSCH 1 and PUSCH 4 can be provided by FDRA configuration/indications, and the resources of PUSCH 2 and PUSCH 3 can be determined by RB offset(s) configuration/indication/determination.

For example, a common FDRA configuration/indication can be provided. For PUSCHs that overlap with RBs other than those available in the UL in the SBFD symbol, only the allocated PRBs within the UL available PRBs are considered valid. For instance, for CG Type 1, the CG configuration includes a frequency Domain Allocation field, and for CG Type 2, the DCI used to activate the CG includes an FDRA field, which applies to all PUSCHs corresponding to the corresponding CG configuration. That is, the frequency domain resources indicated for all CG PUSCHs are the same, but for PUSCHs that overlap with the SBFD symbol, the resources other than those available in the UL are invalid.

Figure 11 is another example diagram of PUSCH scheduling according to an embodiment of this application. As shown in Figure 11, for example, the resources of PUSCH 1 to PUSCH 4 can all be provided by FDRA configuration/indications, but some resources of PUSCH 2 and PUSCH 3 outside of UL available PRBs are invalid.

In some embodiments, a common frequency domain resource allocation (FDRA) can be provided for PUSCHs that overlap with SBFD symbols and for PUSCHs in non-SBFD symbols. For example, for CG Type 1, the CG configuration includes a frequency domain allocation field, and for CG Type 2, the DCI used to activate the CG includes an FDRA. The frequency domain applies to all PUSCHs corresponding to the corresponding CG configuration, meaning that the frequency domain resources indicated for all CG PUSCHs are the same.

For example, the gNB does not schedule any PUSCH in an SBFD symbol of a time slot to overlap with a PRB other than the UL available PRB, or the UE does not expect any PUSCH in an SBFD symbol of a time slot to overlap with a PRB other than the UL available PRB.

Figure 12 is another example diagram of PUSCH scheduling in an embodiment of this application. As shown in Figure 12, any PUSCH (e.g., PUSCH 2 and PUSCH 3) in the SBFD symbol does not overlap with any PRB other than the UL available PRB.

For example, gNB can schedule a PUSCH that overlaps with an SBFD symbol to overlap with a PRB other than the UL available PRB.

Figure 13 is another example diagram of PUSCH scheduling according to an embodiment of this application. As shown in Figure 13, PUSCHs (e.g., PUSCH 2 and PUSCH 3) in the SBFD symbol are scheduled to overlap with PRBs other than those available in the UL. Whether these PUSCHs are actually sent can be determined by the terminal device, for example.

The above provides an illustrative explanation of PUSCH scheduling. The following section explains how terminal devices send PUSCH. This description uses the terminal device's "sending PUSCH" as an example, but it can also be replaced with the network device's "receiving PUSCH" scenario.

In this embodiment, the X information can be used to indicate the link direction (DL/UL) of the SBFD symbol, and can be tdd-UL-DL-ConfigurationDedicated, but is not limited to this; for example, it can also be other information. The Y information can be used to indicate the link direction of a (flexible) non-SBFD symbol, and can be tdd-UL-DL-ConfigurationDedicated, but is not limited to this; for example, it can also be other information.

In some embodiments, PUSCH transmissions are restricted to the first time domain resource (SBFD symbol). The terminal device can only transmit PUSCHs within the first time domain resource and cannot/is not allowed to transmit PUSCHs that overlap with the second time domain resource (among PUSCHs with corresponding HARQ-process IDs). PUSCHs that overlap with the second time domain resource cannot/are not allowed to be transmitted. For example, the PUSCH transmissions are restricted to SBFD symbols only (hereinafter referred to as case 1). In this case, the terminal device can perform the following operation 1.

Operation 1:

The terminal device sends the following PUSCH: not overlapping with SSB symbols, and/or, not overlapping with second time domain resources (non-SBFD symbols), and/or, within the first time domain resources (SBFD symbols) and not overlapping with PRBs other than those in the uplink usable PRB (UL usable PRB) (or the first frequency domain resources), and/or, not overlapping with symbols indicated as downlink by the indication information (X information).

And/or,

The terminal device does not send the following PUSCH: overlapping with SSB symbols, and/or overlapping with second time domain resources (non-SBFD symbols), and/or overlapping with PRBs in first time domain resources (SBFD symbols) and other than uplink usable PRBs, and/or overlapping with symbols indicated as downlink by indication information (X information);

And/or,

The terminal device does not expect a PUSCH to exist in the first time domain resource (SBFD symbol) and overlap with a PRB other than the uplink usable PRB (UL usable PRB), and/or, the terminal device does not expect a PUSCH to exist that overlaps with both the first time domain resource (SBFD symbol) and the second time domain resource (non-SBFD symbol).

For example, assuming that a PUSCH in an SBFD symbol may overlap with RBs other than UL usable RBs, the UE will not transmit PUSCHs that overlap with SSB and/or non-SBFD symbols and/or PUSCHs that overlap with SBFD symbols and RBs other than UL usable RBs (including PUSCHs in SBFD symbols that overlap with SSB), and/or the UE will only transmit PUSCHs in SBFD symbols that do not overlap with SSB and RBs other than UL usable RBs.

For example, assuming that the PUSCH in the SBFD symbol must be within the UL usable RBs (e.g., the gNB does not schedule PUSCHs that overlap with the SBFD symbol and with RBs other than the UL usable RBs, or the UE does not expect the existence of PUSCHs that overlap with the SBFD symbol and with RBs other than the UL usable RBs), then the UE will not send PUSCHs that overlap with the SSB and/or non-SBFD symbols, and/or the UE will only send PUSCHs that are in the SBFD symbol and do not overlap with the SSB.

Figure 14 is an example diagram of PUSCH being transmitted according to an embodiment of this application. As shown in Figure 14, the terminal device only transmits PUSCH (i.e., PUSCH 2) that is in the SBFD symbol and does not overlap with the SSB, while PUSCH 1, PUSCH 3 and PUSCH 4 are not transmitted.

In some embodiments, PUSCH transmissions are restricted to the second time-domain resource (non-SBFD symbols). That is, the terminal device can only transmit PUSCHs within the second time-domain resource; it cannot/is not allowed to transmit PUSCHs that overlap with the first time-domain resource (among PUSCHs with corresponding HARQ-process IDs). For example, PUSCH transmissions are restricted to non-SBFD symbols only (hereinafter referred to as case 2). In this case, the terminal device can perform the following operation 2.

Operation 2:

The terminal device sends the following PUSCH: not overlapping with SSB, and/or, not overlapping with the first time domain resource (SBFD symbol), and/or, not overlapping with the second time domain resource (non-SBFD symbol) used for downlink, and/or, not overlapping with the symbol indicated as downlink by the indication information (Y information);

And/or,

The terminal device does not send the following PUSCH: overlapping with SSB, and/or overlapping with the first time domain resource (SBFD symbol), and/or overlapping with the second time domain resource (non-SBFD symbol) used for downlink, and/or overlapping with the symbol indicated as downlink by the indication information (Y information);

And/or,

Terminal devices do not expect the existence of PUSCHs that overlap with both the first time-domain resource (SBFD symbol) and the second time-domain resource (non-SBFD symbol).

For example, the UE does not transmit PUSCHs that overlap with SBFD symbols and/or SSB and/or DL non-SBFD symbols and/or symbols indicated as downlink by Y information, and/or the UE only transmits PUSCHs in non-SBFD symbols that do not overlap with SSB and/or DL non-SBFD symbols and/or symbols indicated as downlink by Y information.

Figure 15 is another example diagram of PUSCH transmission according to an embodiment of this application. As shown in Figure 15, the terminal device transmits a PUSCH (i.e., PUSCH 4) that is in a non-SBFD symbol and does not overlap with SSB and/or DL non-SBFD symbols and/or does not overlap with symbols indicated as downlink by the Y information, while PUSCH 1, PUSCH 2 and PUSCH 3 are not transmitted.

In some embodiments, multiple PUSCH transmissions can occur in both a first time domain resource and a second time domain resource. That is, among multiple PUSCHs, the terminal device can/is permitted to transmit PUSCHs in the first time domain resource (if any) and/or PUSCHs in the second time domain resource (if any), but cannot/is not permitted to transmit PUSCHs that overlap with both the first and second time domain resources (if any). (Among PUSCHs with corresponding HARQ-process IDs) PUSCHs that overlap with both the first and second time domain resources cannot/are not permitted to be transmitted. For example, the PUSCH transmissions can be across SBFD symbols and non-SBFD symbols, and each has either all SBFD or all non-SBFD symbols (hereinafter referred to as case 3). In this case, the terminal device can perform the following operation 3.

Operation 3:

The terminal device sends the following PUSCH: not overlapping with SSB and/or the second time domain resource (DL non-SBFD symbol) used for downlink, and/or, not overlapping with both the first time domain resource (SBFD symbol) and the second time domain resource (non-SBFD symbol), and/or, within the first time domain resource (SBFD symbol) and not overlapping with a PRB other than the uplink usable PRB (UL usable PRB) (or the first frequency domain resource), and/or, not overlapping with the symbol indicated as downlink by the indication information;

And/or,

Terminal devices do not send the following PUSCH: overlapping with SSB, and/or with the second time domain resource (DL) used for downlink. The symbols overlap with non-SBFD symbols, and/or overlap with both the first time domain resource (SBFD symbols) and the second time domain resource (non-SBFD symbols), and/or overlap with PRBs in the first time domain resource (SBFD symbols) and other than the uplink usable PRB (or the first frequency domain resource), and/or overlap with symbols indicated as downlink by the indication information;

And/or,

The terminal device does not expect a PUSCH to exist in the first time domain resource (SBFD symbol) and overlap with a PRB other than the uplink usable PRB (UL usable PRB) (or the first frequency domain resource), and/or the terminal device does not expect a PUSCH to exist that overlaps with both the first time domain resource (SBFD symbol) and the second time domain resource (non-SBFD symbol).

For example, assuming that a PUSCH in an SBFD symbol may overlap with RBs other than UL usable RBs, and that a PUSCH may overlap with both SBFD symbols and non-SBFD symbols, then the UE will not transmit PUSCHs that overlap with SSB and/or non-SBFD symbols and/or PUSCHs that are in an SBFD symbol and overlap with RBs other than UL usable RBs (including PUSCHs that are in an SBFD symbol and overlap with SSB) and/or PUSCHs that overlap with both SBFD symbols and non-SBFD symbols, and/or, the UE will only transmit PUSCHs that do not overlap with SSB and/or DL non-SBFD symbols, do not overlap with both SBFD symbols and non-SBFD symbols, and when overlapping with an SBFD symbol, do not overlap with RBs other than UL usable RBs.

Figure 16 is another example diagram of PUSCH transmission according to an embodiment of this application. As shown in Figure 16, the terminal device only transmits PUSCH (i.e., PUSCH 4) that does not overlap with SSB and/or DL non-SBFD symbols, does not overlap with both SBFD symbols and non-SBFD symbols, and does not overlap with RBs other than UL usable RBs when it overlaps with SBFD symbols. PUSCH 1, PUSCH 2 and PUSCH 3 are not transmitted.

For example, assuming that the PUSCH in the SBFD symbol is definitely within the UL usable RBs (e.g., the gNB does not schedule PUSCHs that overlap with the SBFD symbol and RBs other than the UL usable RBs, or the UE does not expect the existence of PUSCHs that overlap with the SBFD symbol and RBs other than the UL usable RBs), the PUSCH may overlap with both the SBFD symbol and the non-SBFD symbol. In this case, the UE will not send PUSCHs that overlap with the SSB and/or the non-SBFD symbol and/or both the SBFD symbol and the non-SBFD symbol, and/or the UE will only send PUSCHs that do not overlap with the SSB and/or the DL non-SBFD symbol and do not overlap with both the SBFD symbol and the non-SBFD symbol.

Figure 17 is another example diagram of PUSCH being sent according to an embodiment of this application. As shown in Figure 17, the terminal device only sends PUSCH 2 and PUSCH 4, where part of the RB of PUSCH 2 is considered invalid; while PUSCH 1 and PUSCH 3 are not sent.

For example, suppose that the PUSCH in the SBFD symbol must be within the UL usable RBs (e.g., the gNB does not schedule PUSCHs that overlap with the SBFD symbol and with RBs outside the UL usable RBs, or the UE does not). If the UE expects a PUSCH that overlaps with both SBFD symbols and RBs other than UL usable RBs, and the PUSCH does not overlap with both SBFD symbols and non-SBFD symbols (e.g., the UE does not expect a PUSCH that overlaps with both SBFD symbols and non-SBFD symbols), then the UE will not send a PUSCH that overlaps with SSB and/or non-SBFD symbols, and/or the UE will only send a PUSCH that does not overlap with SSB and/or DL non-SBFD symbols.

Figure 18 is another example diagram of PUSCH being sent according to an embodiment of this application. As shown in Figure 18, the terminal device only sends PUSCH 2, PUSCH 3 and PUSCH 4, while PUSCH 1 is not sent.

For example, assuming that a PUSCH in an SBFD symbol may overlap with RBs other than UL usable RBs, and that the PUSCH will not overlap with both SBFD and non-SBFD symbols (e.g., the UE does not expect the existence of a PUSCH that overlaps with both SBFD and non-SBFD symbols), then the UE will not transmit PUSCHs that overlap with SSB and/or non-SBFD symbols and/or PUSCHs in an SBFD symbol and overlap with RBs other than UL usable RBs (including PUSCHs in an SBFD symbol and overlap with SSB), and/or, the UE will only transmit PUSCHs that do not overlap with SSB and/or DL non-SBFD symbols, and when overlapping with an SBFD symbol, do not overlap with RBs other than UL usable RBs.

Figure 19 is another example diagram of PUSCH being sent according to an embodiment of this application. As shown in Figure 19, the terminal device only sends PUSCH 3 and PUSCH 4, while PUSCH 1 and PUSCH 2 are not sent.

In some embodiments, multiple PUSCH transmissions can be performed in both a first time domain resource and a second time domain resource, including cases where the PUSCH transmission overlaps with both the first time domain resource (SBFD symbols) and the second time domain resource (non-SBFD symbols). In other words, a PUSCH that overlaps with both the first and second time domain resources can be transmitted. That is, among multiple PUSCHs, the terminal device can/is permitted to transmit PUSCHs (if any) in the first time domain resource and/or PUSCHs (if any) in the second time domain resource and/or PUSCHs (if any) that overlap with both the first and second time domain resources. For example, the PUSCH transmissions can be across SBFD symbols and non-SBFD symbols, including a PUSCH overlapping with both SBFD symbols and non-SBFD symbols (hereinafter referred to as case 4). In this case, the terminal device can perform the following operation 4.

Operation 4:

The terminal device sends the following PUSCH: not overlapping with SSB and/or the second time domain resource (DL non-SBFD symbol) used for downlink, and/or overlapping with the first time domain resource (SBFD symbol) and not overlapping with PRB other than the uplink usable PRB (UL usable PRB), and/or not overlapping with the symbol indicated as downlink by the indication information;

And/or,

The terminal device does not send the following PUSCH: overlapping with SSB, and/or overlapping with the second time domain resource (DL non-SBFD symbol) used for downlink, and/or overlapping with the first time domain resource (SBFD symbol) and with the uplink available PRB. PRB overlaps other than (UL usable PRB), and/or overlaps with symbols indicated as downlink by the indicated information;

And/or,

Terminal devices do not expect PUSCHs to overlap with the first time domain resource (SBFD symbol) and with PRBs other than the uplink usable PRB (UL usable PRB).

For example, assuming that a PUSCH overlapping with an SBFD symbol may overlap with RBs other than UL usable RBs (e.g., alternatively, with the boundary of UL usable RBs), the UE will not transmit PUSCHs that overlap with SSB and/or DL non-SBFD symbols and/or overlap with SBFD symbols and RBs other than UL usable RBs, and/or the UE will only transmit PUSCHs that do not overlap with SSB and/or DL non-SBFD symbols, and, when overlapping with an SBFD symbol, do not overlap with RBs other than UL usable RBs.

Figure 20 is another example diagram of PUSCH being sent according to an embodiment of this application. As shown in Figure 20, the terminal device only sends PUSCH 4, while PUSCH 1, PUSCH 2, and PUSCH 3 are not sent.

For example, assuming that a PUSCH overlapping with an SBFD symbol is necessarily within a UL usable RB (e.g., the gNB does not schedule PUSCHs that overlap with SBFD symbols and RBs other than UL usable RBs, or the UE does not expect the existence of PUSCHs that overlap with SBFD symbols and RBs other than UL usable RBs), then the UE will not send PUSCHs that overlap with SSB and/or DL non-SBFD symbols, and/or the UE will only send PUSCHs that do not overlap with SSB and/or DL non-SBFD symbols.

Figure 21 is another example diagram of PUSCH being sent according to an embodiment of this application. As shown in Figure 21, the terminal device only sends PUSCH2, PUSCH3, and PUSCH4, where some RBs of PUSCH2 and PUSCH3 are considered invalid; while PUSCH1 is not sent.

The above illustrations depict the scenarios in which PUSCH is sent. Cases 1 to 4 and operations 1 to 4 are merely classifications for illustrative purposes, and this application is not limited to these classifications. Further explanation of this application follows.

In some embodiments, the capabilities of the terminal device include whether it supports one or more of cases 1 to 4, or one or more of operations 1 to 4. For example, the terminal device supports cases 1 and 2, or operations 1 and 2, and optionally supports cases 3 and/or 4, or operations 3 and/or 4. When the terminal device supports operations 3 and/or 4, it reports the corresponding capability information; otherwise, it does not report it.

In some embodiments, the terminal device's capability includes whether it supports transmitting PUSCH or uplink signals that overlap with both SBFD and non-SBFD symbols. For example, the terminal device may optionally support transmitting PUSCH or uplink signals that overlap with both SBFD and non-SBFD symbols. When the terminal device supports this capability, it reports the corresponding capability information; otherwise, it does not report it. When it does not support this capability, case 4/operation 4 is also not supported.

In some embodiments, it is possible to predefine which cases (e.g., cases 1 to 4 mentioned above) are allowed/applied. For example, when the CG PUSCH configuration includes a PUSCH that overlaps with the SBFD symbol and with RBs other than UL usable RBs, case 2 is applied and the aforementioned operation 2 is performed. As another example, the base station can indicate which of the above cases are allowed/applied, for example, by configuring/indicating through RRC signaling and/or MAC CE and/or DCI.

For example, which case (such as the aforementioned case 1 to case 4) is allowed/applied is limited by the UE's capabilities. For instance, if the terminal device does not support case 3/operation 3, then case 3/operation 3 is not allowed/applied. If the terminal device does not support case 4/operation 4 or does not support sending PUSCH or uplink signals that overlap with both SBFD symbols and non-SBFD symbols, then case 4/operation 4 is not allowed/applied.

In some embodiments, the terminal device determines, based on higher-layer signaling and/or DCI and/or reference PUSCH and/or the terminal device's capabilities, the PUSCH with the corresponding HARQ process ID among a plurality of PUSCHs, and/or sends one or more PUSCHs with the corresponding HARQ process ID among a plurality of PUSCHs.

In some embodiments, the reference PUSCH is a pre-defined or indicated PUSCH in the CG PUSCH, or a pre-defined or indicated PUSCH in the following PUSCH: a PUSCH that does not overlap with SSB and/or the second time domain resource (DL non-SBFD symbol) used for downlink, and/or a PUSCH that does not overlap with both the first time domain resource (SBFD symbol) and the second time domain resource (non-SBFD symbol), and/or a PUSCH that overlaps with the first time domain resource (SBFD symbol) and does not overlap with a PRB other than the uplink usable PRB (UL usable PRB), and/or a PUSCH that does not overlap with a symbol indicated by the indicated information as downlink.

For example, a reference PUSCH is predefined as follows: the first PUSCH in a CG PUSCH, or the first PUSCH that does not overlap with an SSB and/or a DL non-SBFD symbol and/or does not overlap with both an SBFD symbol and a non-SBFD symbol and/or does not overlap with RBs other than UL usable PRBs when it overlaps with an SBFD symbol.

For example, if the reference PUSCH is in the SBFD symbol, then the PUSCH overlapping with the non-SBFD symbol does not have a HARQ process ID, and/or (is determined to be case 1), the aforementioned operation 1 is performed.

For example, if the referenced PUSCH is in a non-SBFD symbol, then the PUSCH overlapping with the SBFD symbol does not have a HARQ process ID, and/or (is determined to be case 2), the aforementioned operation 2 is performed.

For example, if the reference PUSCH overlaps with both the SBFD symbol and the non-SBFD symbol, or starts from the SBFD symbol and ends at the non-SBFD symbol (which is determined to be case 4), then the aforementioned operation 4 is performed.

In some embodiments, the terminal device does not expect the reference PUCSH to overlap with both the SBFD symbol and the non-SBFD symbol.

The following is an illustrative description of option 1 of the embodiments of this application.

It is worth noting that the following explanation will use individual configurations as examples. Configurations one through four can be carried by the same signaling along with the configuration information shown in Figure 2, or they can be carried by different signaling (including high-level signaling). The signaling (or DCI) may be carried by the layer signaling or not (e.g., the default configuration); this application is not limited thereto.

In some embodiments, when the following configurations or information are carried by higher-layer signaling, they are respectively included in an IE (e.g., ServingCellConfigCommonSIB) or IE (e.g., ServingCellConfigCommon) for configuring cell-specific parameters of a cell, and/or in an IE for configuring a cell (e.g., ServingCellConfig), and/or in an IE for configuring common parameters of a UL BWP (e.g., BWP-UplinkCommon), and/or in an IE for configuring dedicated (UE-specific) parameters of a UL BWP (e.g., BWP-UplinkDedicated), and/or in an IE for configuring UE-specific (applied to a BWP) PUSCH parameters (e.g., PUSCH-Config), and/or in the aforementioned CG configuration IE (ConfiguredGrantConfig).

In some embodiments, the terminal device receives a first configuration or a second configuration from the network device; the first configuration instructs the PUSCH to send data in either the first time domain resource or the second time domain resource, and the second configuration instructs the PUSCH to send data in both the first and second time domain resources.

In some embodiments, the first configuration is used by default when the second configuration is not received and/or the terminal device does not support case 3/operation 3 (and/or case 4/operation 4).

For example, the first configuration indicates that PUSCH transmissions are restricted to SBFD symbols only or non-SBFD symbols only; the second configuration indicates that PUSCH transmissions can be in SBFD symbols and non-SBFD symbols.

In this configuration, since the first configuration includes the aforementioned cases 1 and 2, the terminal device needs to uniquely determine whether to use operation 1 or operation 2 for the CG PUSCH. Similarly, since the second configuration includes the aforementioned cases 3 and 4, the terminal device needs to uniquely determine whether to use operation 3 or operation 4 for the CG PUSCH.

In some embodiments, under the first configuration, such as when the terminal device is provided with a first configuration by higher-layer signaling or defaults to the first configuration, based on the reference PUSCH and/or the first information provided by MAC signaling and/or DCI (determining whether it is case 1 or case 2), the PUSCH with the corresponding HARQ process ID among the multiple PUSCHs is determined (if the conditions that the PUSCH with the corresponding HARQ process ID should meet are different for case 1 and case 2), and/or, the PUSCHs among the multiple PUSCHs that will be sent or not sent (that is, using operation 1 or operation 2).

The first configuration instruction instructs the terminal device not to send PUSCHs that overlap with the first time domain resources (i.e., all PUSCH transmissions are in the first time domain resources, corresponding to case 1) or not to send PUSCHs that overlap with the second time domain resources (i.e., all PUSCH transmissions are in the second time domain resources, corresponding to case 2).

For example, if the reference PUSCH is in the SBFD symbol, then the PUSCH overlapping with the non-SBFD symbol does not have a HARQ process ID, and/or, (as determined in case 2), performs the aforementioned operation 1.

For example, if the reference PUSCH is in a non-SBFD symbol, then the PUSCH overlapping with the SBFD symbol does not have a HARQ process ID, and/or (is determined to be case 2) performs the aforementioned operation 2.

For example, if the first information indicates that the terminal device does not send a PUSCH that overlaps with the first time domain resource among the multiple PUSCHs, then the aforementioned operation 1 is executed; if the first information indicates that the terminal device does not send a PUSCH that overlaps with the second time domain resource among the multiple PUSCHs, then the aforementioned operation 2 is executed.

In some embodiments, under the second configuration, for example, when the terminal device is provided with a second configuration by higher-layer signaling, based on the reference PUSCH and/or the second information provided by the higher-layer signaling and/or DCI, (determining whether it is case 3 or case 4), the PUSCH with the corresponding HARQ process ID among the multiple PUSCHs is determined (if the conditions that the PUSCH with the corresponding HARQ process ID should meet are different for case 3 and case 4), and/or, the PUSCHs among the multiple PUSCHs that will be sent or not sent (that is, adopting operation 3 or operation 4).

The second configuration is used to instruct the terminal device to send PUSCHs (if any) that overlap with both the first and second time domain resources from among the multiple PUSCHs, or to instruct the terminal device not to send PUSCHs (if any) that overlap with both the first and second time domain resources from among the multiple PUSCHs.

For example, if the second information instructs the terminal device not to send any PUSCHs that overlap with both the first and second time domain resources (if any), then the aforementioned operation 3 is performed; if the first information instructs the terminal device to send any PUSCHs that overlap with both the first and second time domain resources (if any), then the aforementioned operation 4 is performed.

The following is an illustrative description of optional 2 of the embodiments of this application.

In some embodiments, the terminal device receives a first configuration or a second configuration from the network device; the first configuration indicates that PUSCH transmissions are all in the first time domain resource or all in the second time domain resource, and the second configuration indicates that PUSCH transmissions can be in the first time domain resource and the second time domain resource, and each PUSCH transmission is either in the first time domain resource or the second time domain resource.

For example, the first configuration is the same as the first configuration in Option 1, and the second configuration includes case 3. For the first configuration, refer to the method described in Option 1; for the second configuration, the terminal device performs the aforementioned operation 3.

The following is an illustrative description of option 3 of the embodiments of this application.

In some embodiments, the terminal device receives a first configuration, a second configuration, or a third configuration from the network device; the first configuration indicates that PUSCH transmissions are all in the first time domain resource, the second configuration indicates that PUSCH transmissions are all in the second time domain resource, and the third configuration indicates that PUSCH transmissions can be in both the first and second time domain resources.

For example, for the first configuration (corresponding to case 1 above), the terminal device performs operation 1 above; for the second configuration (corresponding to case 2 above), the terminal device performs operation 2 above. The third configuration is the same as the second configuration in Option 1. For the third configuration, refer to the method described in Option 1 for the corresponding second configuration.

The following is an illustrative description of optional 4 of the embodiments of this application.

The terminal device receives a first configuration, a second configuration, a third configuration, or a fourth configuration from the network device; the first configuration indicates that all PUSCH transmissions are in the first time domain resource, the second configuration indicates that all PUSCH transmissions are in the second time domain resource, the third configuration indicates that PUSCH transmissions can be in both the first and second time domain resources and that each PUSCH transmission is either in the first or second time domain resource, and the fourth configuration indicates that multiple PUSCH transmissions can be made in both the first and second time domain resources and that any PUSCHs overlapping with both the first and second time domain resources can be transmitted.

For example, for the first configuration (corresponding to case 1 above), the terminal device performs operation 1 above; for the second configuration (corresponding to case 2 above), the terminal device performs operation 2 above; for the third configuration (corresponding to case 3 above), the terminal device performs operation 3 above; and for the second configuration (corresponding to case 4 above), the terminal device performs operation 4 above.

The above illustrations depict various implementation methods of the embodiments of this application, but this application is not limited thereto. For example, in each option, if the UE is not provided with a certain configuration by signaling, one of the other configurations can be used by default. Furthermore, the above optional methods can be partially combined. Still others can be used as needed. For simplicity, options 2 to 5 have been briefly described above; this application is not limited thereto, and specific implementations can also be referred to option 1 and the foregoing embodiments.

The following is an illustrative explanation of the HARQ process ID.

In some embodiments, the terminal device assigns a HARQ process ID to the configuration grant PUSCH that is sent. Alternatively, a HARQ process ID may be assigned to a configuration grant PUSCH that is not sent, or no HARQ process ID may be assigned to a configuration grant PUSCH that is not sent.

For example, in case 1, the PUSCH that overlaps with the second time-domain resource is not sent; it may or may not be assigned a HARQ process ID, that is, it may or may not have a HARQ process ID. Similarly, in case 2, the PUSCH that overlaps with the first time-domain resource is not sent; it may or may not be assigned a HARQ process ID, that is, it may or may not have a HARQ process ID.

In some embodiments, among multiple configuration authorization PUSCHs, the configuration authorization PUSCH sent by the terminal device has a corresponding HARQ process ID, while the configuration authorization PUSCH not sent by the terminal device does not have a corresponding HARQ process ID.

For example, in case 1, the PUSCH sent in operation 1 has a corresponding HARQ process ID, so it is not sent. The PUSCH sent in operation 2 does not have a corresponding HARQ process ID. For example, in case 2, the PUSCH sent in operation 2 has a corresponding HARQ process ID, while the PUSCH not sent does not.

In some embodiments, whether a configuration-authorized PUSCH has a corresponding HARQ process ID is related to a first time-domain resource and/or a second time-domain resource, including:

If a configuration-granted PUSCH overlaps with a second time-domain resource (DL non-SBFD symbol) used for downlink, then the configuration-granted PUSCH does not have a corresponding HARQ process ID, and/or,

If a configuration-granted PUSCH overlaps with a first temporal domain resource (SBFD symbol), then the configuration-granted PUSCH does not have a corresponding HARQ process ID, and/or,

If a configuration-granted PUSCH overlaps with both second-time-domain resources (non-SBFD symbols), then the configuration-granted PUSCH does not have a corresponding HARQ process ID, and/or,

If a configuration-granted PUSCH overlaps with both the first time-domain resource (SBFD symbol) and the second time-domain resource (non-SBFD symbol), then the configuration-granted PUSCH does not have a corresponding HARQ process ID, and/or,

If a configuration-granted PUSCH overlaps with a first time-domain resource (SBFD symbol) and also overlaps with a frequency-domain resource other than an uplink usable PRB (UL usable PRB), the configuration-granted PUSCH does not have a corresponding HARQ process ID.

In some embodiments, the terminal device determines the HARQ process ID associated with the configuration grant PUSCH (corresponding to the first symbol of the uplink transmission) based at least on the first time domain resource and/or the second time domain resource. This may include determining the HARQ process ID of the first configuration grant PUSCH (corresponding to the first symbol of the uplink transmission) in the period and each subsequent valid configuration grant PUSCH (corresponding to the first symbol of the uplink transmission) in the period.

In some embodiments, the PUSCH with the corresponding HARQ process ID is as follows:

It does not overlap with SSB, and/or, does not overlap with the second time domain resource (DL non-SBFD symbol) used for downlink, and/or, does not overlap with both the first time domain resource (SBFD symbol) and the second time domain resource (non-SBFD symbol), and/or, overlaps with the first time domain resource (SBFD symbol) and does not overlap with PRBs other than the uplink usable PRB (UL usable PRB), and/or, does not overlap with the symbol indicated by the indication information as downlink.

For example, for configuration authorization PUSCHs that the UE needs to send, a corresponding HARQ process ID must be assigned. For configuration authorization PUSCHs that the UE does not send, a HARQ process ID can be assigned, or no HARQ process ID can be assigned.

For example, a PUSCH assigned a HARQ process ID must not overlap with SSB and/or DL non-SBFD symbols, and/or, when a PUSCH is within a non-SBFD symbol, it must not overlap with a symbol indicated as downlink by Y information, and/or, when a PUSCH overlaps with an SBFD symbol and/or is within an SBFD symbol, it must not overlap with RBs other than UL usable RBs and/or with symbols indicated as downlink by X information and/or with SBFD symbols and non-SBFD symbols. The symbols all overlap.

For example, a PUSCH assigned a HARQ process ID includes the first PUSCH in each cycle, and the following PUSCHs after the first PUSCH: do not overlap with SSB and/or DL non-SBFD symbols, and/or, when the PUSCH is within a non-SBFD symbol, do not overlap with a symbol indicated as downlink by the Y information, and/or, when the PUSCH overlaps with an SBFD symbol and/or is within an SBFD symbol, do not overlap with RBs other than UL usable RBs and/or do not overlap with a symbol indicated as downlink by the X information and/or do not overlap with both SBFD symbols and non-SBFD symbols.

In some embodiments, the terminal device also determines the HARQ process ID corresponding to the configuration-authorized PUSCH based on the PUSCH sending restriction corresponding to the configuration authorization.

In some examples, PUSCH transmission restrictions include: the terminal device does not transmit configuration grant PUSCHs that overlap with the second time domain resource (e.g., corresponding to the aforementioned case 1, but not limited thereto), and/or, the terminal device does not transmit configuration grant PUSCHs that overlap with the first time domain resource (e.g., corresponding to the aforementioned case 2, but not limited thereto), and/or, the terminal device does not transmit configuration grant PUSCHs that overlap with both the first and second time domain resources (e.g., corresponding to the aforementioned case 1/case 2/case 3, but not limited thereto).

In some embodiments, PUSCH transmission restrictions are indicated and/or determined based on at least one of the following: RRC signaling, MAC signaling, DCI, reference PUSCH, or the capabilities of the terminal device. Specific methods may refer to, for example, the foregoing configurations and information, but are not limited thereto.

In some embodiments, under different PUSCH transmission restrictions, the configuration-authorized PUSCHs with corresponding HARQ process IDs need to meet the same conditions. For example, for two or more of the aforementioned cases 1 to 4, the conditions that PUSCHs with corresponding HARQ process IDs need to meet can be the same (or defined the same), such as meeting the intersection of the conditions corresponding to the PUSCHs sent in the corresponding operation (including not overlapping with SSBs, etc.).

In some embodiments, under different PUSCH transmission restrictions, the conditions that a configuration-authorized PUSCH with a corresponding HARQ process ID needs to meet are different. For example, for the two cases mentioned above (cases 1 to 4), the conditions that a PUSCH with a corresponding HARQ process ID needs to meet are different (or defined differently). For example, they need to meet the conditions corresponding to the PUSCH sent in the corresponding operation (including not overlapping with SSB, etc.).

In some embodiments, the terminal device determines the HARQ process ID corresponding to the configuration authorization PUSCH based on RRC signaling and/or MAC signaling and/or DCI and/or reference PUSCH and/or the terminal device's capabilities, and/or sends one or more configuration authorization PUSCHs with the corresponding HARQ process ID.

In some embodiments, the HARQ process ID associated with the configuration grant PUSCH (the corresponding uplink transmission (first symbol)) is determined based on a first parameter (e.g., ID_OFFSET); wherein, for the first symbol in a cycle A configuration authorization PUSCH, with the first parameter = 0, refers to the valid configuration authorization PUSCH after the first configuration authorization PUSCH in the same period, with the first parameter = K (1≤K<nrofSlotsInCG-Period), where nrofSlotsInCG-Period is the number of configuration authorization PUSCHs in one period.

Table 1 shows an example of a HARQ process ID in an embodiment of this application, including an example of how to determine the HARQ process ID associated with the configuration grant PUSCH (the corresponding uplink transmission (first symbol)) based on a first parameter.

Table 1

The conditions in Table 1 include, for example: not overlapping with SSB and/or DL non-SBFD symbols, and/or, when PUSCH is within a non-SBFD symbol, not overlapping with a symbol indicated as downlink by the Yth information, and/or, when PUSCH overlaps with an SBFD symbol and/or is within an SBFD symbol, not overlapping with RBs other than UL usable RBs and/or not overlapping with a symbol indicated as downlink by the Xth information and/or not overlapping with both SBFD symbols and non-SBFD symbols.

Tables 2, 3, and 4 illustrate further examples of HARQ process IDs in embodiments of this application, each including a specific definition example of a valid configured PUSCH grant as described in Table 1.

Table 2

Table 3

Table 4

Tables 1 to 4 provide exemplary descriptions of the HARQ process ID in embodiments of this application, but are not limited thereto.

In some embodiments, a valid configuration grant PUSCH does not overlap with an SSB symbol, and/or does not overlap with a second time-domain resource (DL non-SBFD symbol) used for downlink, and/or does not overlap with both the first time-domain resource (SBFD symbol) and the second time-domain resource (non-SBFD symbol), and/or overlaps with the first time-domain resource (SBFD symbol) and does not overlap with frequency-domain resources other than the uplink usable PRB (UL usable PRB) (or the first frequency-domain resource), and/or does not overlap with a symbol indicated as downlink by the indication information (x/y), and/or begins with an SBFD symbol and ends with a non-SBFD symbol, and/or begins with a non-SBFD symbol and ends with an SBFD symbol.

In some embodiments, the following configuration grant PUSCHs in a cycle are not valid configuration grant PUSCHs: overlapping with an SSB symbol, and/or overlapping with a second time-domain resource (DL non-SBFD symbol) used for downlink, and/or overlapping with both a first time-domain resource (SBFD symbol) and a second time-domain resource (non-SBFD symbol), and/or overlapping with a first time-domain resource (SBFD symbol) and a frequency-domain resource other than an uplink usable PRB (UL usable PRB) (or a first frequency-domain resource), and/or overlapping with a symbol indicated as downlink by an indication message, and/or not starting with an SBFD symbol and ending with a non-SBFD symbol, and/or not starting with a non-SBFD symbol and ending with an SBFD symbol.

The above description only covers the steps or processes relevant to this application, but this application is not limited thereto. The methods in the embodiments of this application may also include other steps or processes, and for details of these steps or processes, please refer to related technologies.

The above embodiments are merely illustrative examples of embodiments of this application, but this application is not limited thereto, and appropriate modifications can be made based on the above embodiments. For example, the above embodiments can be used alone, or one or more of the above embodiments can be combined.

As can be seen from the above embodiments, the terminal device sends one or more configuration grant PUSCHs with corresponding HARQ process IDs. Specifically, whether a configuration grant PUSCH has a corresponding HARQ process ID depends on the first time domain resources and/or the second time domain resources. Therefore, the network device can operate in full-duplex mode (simultaneous reception and transmission), and the terminal device can also utilize the corresponding resources to send and receive signals when the network device is operating in full-duplex mode. This improves uplink transmission capacity and coverage, reduces uplink transmission latency, and enhances resource allocation flexibility and resource utilization.

Second aspect of the embodiments

This application provides a PUSCH receiving method, which is described from the perspective of the network device. The content that is the same as that in the first aspect of the embodiment will not be repeated.

Figure 22 is a schematic diagram of a PUSCH receiving method according to an embodiment of this application. As shown in Figure 22, the method includes:

2201, The network device sends configuration information for configuring at least a first time domain resource and/or a second time domain resource; wherein, in the first time domain resource, a first frequency domain resource is used for uplink and a second frequency domain resource is used for downlink, and the second time domain resource is outside the first time domain resource;

2202, the network device sends a configuration grant (CG) configuration; wherein, for the configuration grant, whether a configuration grant PUSCH has a corresponding HARQ process ID is related to the first time domain resource and/or the second time domain resource; and

2203, the network device receives one or more configuration authorization PUSCHs with corresponding HARQ process IDs.

It is worth noting that Figure 22 above is only an illustrative description of the embodiments of this application, but this application is not limited thereto. For example, the execution order between various operations can be appropriately adjusted, and other operations can be added or some operations can be removed. Those skilled in the art can make appropriate modifications based on the above content, and are not limited to the description in Figure 22 above.

In some embodiments, on the first time domain resource, the network device can transmit a downlink signal to a terminal device on a first frequency domain resource and receive an uplink signal transmitted by another terminal device on a frequency domain resource other than the first frequency domain resource, and/or receive an uplink signal transmitted by a terminal device on a second frequency domain resource and transmit a downlink signal to another terminal device on a frequency domain resource other than the second frequency domain resource. This enables the network device to support the simultaneous existence/occurrence/continuation of downlink and uplink.

In some embodiments, the network device may also send various configuration information/instruction information to the terminal device; the network device may also receive feedback information/reporting information from the terminal device, but this application is not limited thereto.

In some embodiments, the configuration grant has multiple consecutive configuration grant PUSCHs in a period, and/or the configuration grant has multiple non-consecutive configuration grant PUSCHs in a period.

In some embodiments, the network device determines the first configuration grant PUSCH in the cycle and the HARQ process ID of each subsequent valid configuration grant PUSCH.

In some embodiments, an effective configuration grant PUSCH does not overlap with an SSB symbol, and/or does not overlap with a second time-domain resource (DL non-SBFD symbol) used for downlink, and/or does not overlap with both a first time-domain resource (SBFD symbol) and a second time-domain resource (non-SBFD symbol), and/or overlaps with a first time-domain resource (SBFD symbol) and does not overlap with frequency-domain resources other than uplink usable PRB (UL usable PRB) (or the first frequency-domain resource). Overlap, and/or, not overlap with the symbol indicated as the downlink by the indicated information (x/y), and/or, starting from the SBFD symbol and ending at the non-SBFD symbol, and/or, starting from the non-SBFD symbol and ending at the SBFD symbol.

In some embodiments, the following configuration grant PUSCHs in a cycle are not valid configuration grant PUSCHs: overlapping with an SSB symbol, and/or overlapping with a second time-domain resource (DL non-SBFD symbol) used for downlink, and/or overlapping with both a first time-domain resource (SBFD symbol) and a second time-domain resource (non-SBFD symbol), and/or overlapping with a first time-domain resource (SBFD symbol) and a frequency-domain resource other than an uplink usable PRB (UL usable PRB) (or the first frequency-domain resource), and/or overlapping with a symbol indicated as downlink by the indication information, and/or not starting with an SBFD symbol and ending with a non-SBFD symbol, and/or not starting with a non-SBFD symbol and ending with an SBFD symbol.

In some embodiments, the configuration authorization PUSCH is determined based on a first parameter; wherein, for the first configuration authorization PUSCH in a cycle, the first parameter is zero, and for the valid configuration authorization PUSCH after the first configuration authorization PUSCH in the same cycle, the first parameter is a value greater than or equal to 1 and less than the number of configuration authorization PUSCHs in a cycle.

In some embodiments, the network device also determines the valid configuration authorization PUSCH based on the PUSCH sending limit corresponding to the configuration authorization.

In some embodiments, PUSCH sending restrictions include:

The terminal device does not send configuration grant PUSCHs that overlap with the second time domain resources (alternatively, the network device does not receive PUSCHs that overlap with the second time domain resources from among multiple PUSCHs); and/or

The terminal device does not send configuration grant PUSCHs that overlap with the first time domain resource (or alternatively, the terminal device does not receive PUSCHs that overlap with the first time domain resource from among multiple PUSCHs); and/or

The terminal device does not send configuration grant PUSCHs that overlap with both the first and second time domain resources (the network device does not accept PUSCHs that overlap with both the first and second time domain resources among multiple PUSCHs).

In some embodiments, PUSCH transmission restrictions are determined based on at least one of the following: RRC signaling, MAC signaling, DCI, reference PUSCH, or the capabilities of the terminal device.

In some embodiments, under different PUSCH sending restrictions, the configuration-authorized PUSCH with the corresponding HARQ process ID needs to meet the same conditions.

In some embodiments, under different PUSCH sending restrictions, the conditions that a configuration-authorized PUSCH with a corresponding HARQ process ID needs to meet are different.

In some embodiments, configuration authorization PUSCHs that overlap with second time-domain resources are not sent;

The network device receives the following configuration authorization PUSCH: not overlapping with SSB symbols, and/or not with the second time domain. Resource (non-SBFD symbol) overlap, and/or, within the first time domain resource (SBFD symbol) and not overlapping with a PRB outside the first frequency domain resource (UL usable PRB) (or the first frequency domain resource), and/or, not overlapping with a symbol indicated as downlink by the indicated information (x information).

And/or,

Network devices do not accept the following configuration authorization PUSCHs: overlapping with SSB symbols, and/or overlapping with second time domain resources (non-SBFD symbols), and/or overlapping with PRBs in first time domain resources (SBFD symbols) and other than uplink usable PRBs (UL usable PRBs) (or the first frequency domain resources), and/or overlapping with symbols indicated as downlink by indication information (x information);

And/or,

The terminal device does not expect (or alternatively, the network device does not schedule) a PUSCH that exists in the first time domain resource (SBFD symbol) and overlaps with a PRB other than the uplink usable PRB (UL usable PRB) (or the first frequency domain resource), and/or, the terminal device does not expect (or alternatively, the network device does not schedule) a configuration grant PUSCH that overlaps with both the first time domain resource (SBFD symbol) and the second time domain resource (non-SBFD symbol).

In some embodiments, configuration authorization PUSCHs that overlap with first temporal domain resources are not sent;

The network device receives the following configuration authorization PUSCH: not overlapping with SSB, and/or, not overlapping with the first time domain resource (SBFD symbol), and/or, not overlapping with the second time domain resource (non-SBFD symbol) used for downlink, and/or, not overlapping with the symbol indicated as downlink by the indication information (y information);

And/or,

Network devices do not accept the following configuration authorization PUSCHs: overlapping with SSB, and/or overlapping with the first time domain resource (SBFD symbol), and/or overlapping with the second time domain resource (non-SBFD symbol) used for downlink, and/or overlapping with the symbol indicated as downlink by the indication information (y information);

And/or,

Terminal devices do not expect (or alternatively, network devices do not schedule) the existence of configuration grant PUSCHs that overlap with both the first time domain resource (SBFD symbol) and the second time domain resource (non-SBFD symbol).

In some embodiments, configuration grant PUSCHs that overlap with both the first time domain resource and the second time domain resource are not sent;

The network device receives the following configuration grant PUSCH: It does not overlap with SSB and/or the second time-domain resource (DL non-SBFD symbol) used for downlink, and/or, it does not overlap with both the first time-domain resource (SBFD symbol) and the second time-domain resource (non-SBFD symbol), and/or, it is within the first time-domain resource (SBFD symbol) and does not overlap with a PRB other than the uplink usable PRB (UL usable PRB) (or the first frequency-domain resource), and/or, it does not overlap with the symbol indicated as downlink by the indication information. overlapping signs;

And/or,

Network devices do not accept the following configuration authorization PUSCHs: overlapping with SSB, and/or overlapping with the second time domain resource (DL non-SBFD symbol) used for downlink, and/or overlapping with both the first time domain resource (SBFD symbol) and the second time domain resource (non-SBFD symbol), and/or overlapping with a PRB in the first time domain resource (SBFD symbol) and other than the uplink usable PRB (UL usable PRB) (or the first frequency domain resource), and/or overlapping with a symbol indicated as downlink by the indication information;

And/or,

The terminal device does not expect (or alternatively, the network device does not schedule) a PUSCH that exists in the first time domain resource (SBFD symbol) and overlaps with a PRB other than the uplink usable PRB (UL usable PRB) (or the first frequency domain resource), and/or, the terminal device does not expect (or alternatively, the network device does not schedule) a configuration grant PUSCH that overlaps with both the first time domain resource (SBFD symbol) and the second time domain resource (non-SBFD symbol).

In some embodiments, configuration grant PUSCHs that overlap with both the first time domain resource and the second time domain resource can be sent;

The network device receives the following configuration authorization PUSCH: does not overlap with SSB and/or the second time domain resource (DL non-SBFD symbol) used for downlink, and/or overlaps with the first time domain resource (SBFD symbol) and does not overlap with PRB other than the uplink usable PRB (UL usable PRB) (or the first frequency domain resource), and/or does not overlap with the symbol indicated as downlink by the indication information;

And/or,

Network devices do not accept the following configuration authorization PUSCHs: overlapping with SSB, and/or overlapping with the second time domain resource (DL non-SBFD symbol) used for downlink, and/or overlapping with the first time domain resource (SBFD symbol) and with a PRB other than the uplink usable PRB (UL usable PRB) (or the first frequency domain resource), and/or overlapping with a symbol indicated as downlink by the indication information;

And/or,

Terminal devices do not expect (or alternatively, network devices do not schedule) configuration authorization PUSCHs that overlap with the first temporal domain resource (SBFD symbol) and with PRBs other than the uplink usable PRB (UL usable PRB).

In some embodiments, the configuration authorization PUSCH received by the network device has a corresponding HARQ process ID, while the configuration authorization PUSCH received by the network device does not have a corresponding HARQ process ID.

In some embodiments, the network device determines the HARQ process ID corresponding to the configuration authorized PUSCH based on RRC signaling and/or MAC signaling and/or DCI and/or reference PUSCH and/or the capabilities of the terminal device, and/or Receive one or more configuration authorization PUSCHs from the configuration authorization PUSCHs that have the corresponding HARQ process ID.

In some embodiments, when a network device is provided with a first configuration by RRC signaling and/or MAC signaling, it determines, based on a reference PUSCH and/or the first information provided by the MAC signaling and/or DCI, a configuration authorization PUSCH with a corresponding HARQ process ID, and/or a configuration authorization PUSCH that will be sent or not sent.

The first configuration indicates that the configuration authorization PUSCH is sent in either the first time domain resource or the second time domain resource, and the first information indicates that the terminal device does not send (or alternatively, the network device does not receive) the configuration authorization PUSCH that overlaps with the first time domain resource or the configuration authorization PUSCH that overlaps with the second time domain resource.

In some embodiments, the referenced PUSCH is a pre-defined or indicated PUSCH in the configuration authorization PUSCH, or a pre-defined or indicated PUSCH in the following PUSCH:

A PUSCH that does not overlap with an SSB and/or a second time-domain resource (DL non-SBFD symbol) used for downlink, and/or a PUSCH that does not overlap with both the first time-domain resource (SBFD symbol) and the second time-domain resource (non-SBFD symbol), and/or a PUSCH that overlaps with the first time-domain resource (SBFD symbol) and does not overlap with a PRB other than the uplink usable PRB (UL usable PRB) (or the first frequency-domain resource), and/or a PUSCH that does not overlap with a symbol indicated as downlink by the indication information.

In some embodiments, when a network device is provided with a second configuration by RRC signaling and/or MAC signaling, it determines, based on a reference PUSCH and/or the second information provided by the RRC signaling and/or MAC signaling and/or DCI, a configuration authorization PUSCH with a corresponding HARQ process ID, and/or a configuration authorization PUSCH that will be sent or not sent.

The second configuration indicates that the configuration authorization PUSCH can be sent in the first time domain resource and/or the second time domain resource; the second information is used to instruct the terminal device to send (or alternatively, the network device to receive) a configuration authorization PUSCH that overlaps with both the first and second time domain resources, or to instruct the terminal device not to send (or alternatively, the network device not to receive) a configuration authorization PUSCH that overlaps with both the first and second time domain resources.

The above description only covers the steps or processes relevant to this application, but this application is not limited thereto. The methods in the embodiments of this application may also include other steps or processes, and for details of these steps or processes, please refer to related technologies.

The above embodiments are merely illustrative examples of embodiments of this application, but this application is not limited thereto, and appropriate modifications can be made based on the above embodiments. For example, the above embodiments can be used alone, or one or more of the above embodiments can be combined.

As can be seen from the above embodiments, the network device receives one or more configuration authorization PUSCHs with corresponding HARQ process IDs; wherein, for configuration authorization, whether a configuration authorization PUSCH has a corresponding HARQ process... The ID is related to the first time domain resources and/or the second time domain resources. As a result, network devices can operate in full-duplex mode (simultaneous reception and transmission), and terminal devices can also use the corresponding resources to send and receive signals when the network devices are operating in full-duplex mode. This can improve uplink transmission capacity and coverage, reduce uplink transmission latency, and increase the flexibility of resource allocation and resource utilization.

Third aspect of the embodiments

This application provides a PUSCH transmitting device. This device may be, for example, a terminal device, or one or more components or parts configured within a terminal device; details identical to those in the first aspect of the embodiment will not be repeated.

Figure 23 is a schematic diagram of a PUSCH transmitting device according to an embodiment of this application. Since the principle of this device in solving the problem is the same as the method of the embodiment of the first aspect, its specific implementation can refer to the embodiment of the first aspect, and the contents that are the same will not be repeated. As shown in Figure 23, the PUSCH transmitting device 2300 includes: a receiver 2301 and a transmitter 2302; it may also include a processor 2303.

In some embodiments, receiver 2301 receives configuration information for configuring at least a first time-domain resource and/or a second time-domain resource; wherein, in the first time-domain resource, a first frequency-domain resource is used for uplink and a second frequency-domain resource is used for downlink, and the second time-domain resource is outside the first time-domain resource; receives configuration grant (CG) configuration; wherein, for configuration grant, whether a configuration grant PUSCH has a corresponding HARQ process ID is related to the first time-domain resource and/or the second time-domain resource; and

The transmitter 2302 sends one or more configuration authorization PUSCHs from the configuration authorization PUSCHs with corresponding HARQ process IDs.

In some embodiments, whether a configuration-authorized PUSCH has a corresponding HARQ process ID is related to a first time-domain resource and/or a second time-domain resource, including:

If a configuration-granted PUSCH overlaps with a second time-domain resource (DL non-SBFD symbol) used for downlink, then the configuration-granted PUSCH does not have a corresponding HARQ process ID, and/or,

If a configuration-granted PUSCH overlaps with a first temporal domain resource (SBFD symbol), then the configuration-granted PUSCH does not have a corresponding HARQ process ID, and/or,

If a configuration-granted PUSCH overlaps with both second-time-domain resources (non-SBFD symbols), then the configuration-granted PUSCH does not have a corresponding HARQ process ID, and/or,

If a configuration-granted PUSCH overlaps with both the first time-domain resource (SBFD symbol) and the second time-domain resource (non-SBFD symbol), then the configuration-granted PUSCH does not have a corresponding HARQ process I, and/or,

If a configuration grant PUSCH overlaps with the first time domain resource (SBFD symbol) and is adjacent to an uplink available PRB (UL) For frequency domain resources overlapping outside of usable PRBs, the configured authorized PUSCH does not have a corresponding HARQ process ID.

In some embodiments, the configuration grant has multiple consecutive configuration grant PUSCHs in a period, and/or the configuration grant has multiple non-consecutive configuration grant PUSCHs in a period.

In some embodiments, processor 2303 determines the first configuration grant PUSCH in the cycle and the HARQ process ID of each subsequent valid configuration grant PUSCH.

In some embodiments, a valid configuration grant PUSCH does not overlap with an SSB symbol, and/or does not overlap with a second time-domain resource (DL non-SBFD symbol) used for downlink, and/or does not overlap with both the first time-domain resource (SBFD symbol) and the second time-domain resource (non-SBFD symbol), and/or overlaps with the first time-domain resource (SBFD symbol) and does not overlap with frequency-domain resources other than the uplink usable PRB (UL usable PRB) (or the first frequency-domain resource), and/or does not overlap with a symbol indicated as downlink by the indication information (x/y), and/or begins with an SBFD symbol and ends with a non-SBFD symbol, and/or begins with a non-SBFD symbol and ends with an SBFD symbol.

In some embodiments, the following configuration grant PUSCHs in a cycle are not valid configuration grant PUSCHs: overlapping with SSB symbols, and/or overlapping with a second time-domain resource (DL non-SBFD symbol) used for downlink, and/or overlapping with both a first time-domain resource (SBFD symbol) and a second time-domain resource (non-SBFD symbol), and/or overlapping with a first time-domain resource (SBFD symbol) and a frequency-domain resource other than an uplink usable PRB (UL usable PRB), and/or overlapping with a symbol indicated as downlink by the indication information, and/or not starting with an SBFD symbol and ending with a non-SBFD symbol, and/or not starting with a non-SBFD symbol and ending with an SBFD symbol.

In some embodiments, the configuration authorization PUSCH is determined based on a first parameter; wherein, for the first configuration authorization PUSCH in a cycle, the first parameter is zero, and for the valid configuration authorization PUSCH after the first configuration authorization PUSCH in the same cycle, the first parameter is a value greater than or equal to 1 and less than the number of configuration authorization PUSCHs in a cycle.

In some embodiments, the processor 2303 further determines the HARQ process ID corresponding to the configuration-authorized PUSCH based on the PUSCH sending restrictions corresponding to the configuration authorization;

Among them, the PUSCH sending restrictions include:

The terminal device does not send configuration grant PUSCHs that overlap with second time-domain resources; and/or

The terminal device does not send configuration grant PUSCHs that overlap with the first time domain resources; and/or

The terminal device does not send configuration authorization PUSCHs that overlap with both the first and second time domain resources.

In some embodiments, PUSCH transmission restrictions are determined based on at least one of the following: RRC signaling, MAC signaling, DCI, reference PUSCH, or the capabilities of the terminal device.

In some embodiments, under different PUSCH sending restrictions, there are corresponding HARQ process IDs. The same conditions must be met to configure and authorize PUSCH.

In some embodiments, under different PUSCH sending restrictions, the conditions that a configuration-authorized PUSCH with a corresponding HARQ process ID needs to meet are different.

In some embodiments, configuration authorization PUSCHs that overlap with second time-domain resources are not sent;

Transmitter 2302 transmits the following PUSCH: not overlapping with SSB symbols, and/or, not overlapping with second time-domain resources (non-SBFD symbols), and/or, within first time-domain resources (SBFD symbols) and not overlapping with PRBs other than uplink usable PRBs (UL usable PRBs) (or the first frequency-domain resources), and/or, not overlapping with symbols indicated as downlink by the indicated information (x information).

And/or,

Transmitter 2302 does not transmit the following PUSCH: overlapping with SSB symbols, and/or overlapping with second time domain resources (non-SBFD symbols), and/or overlapping with PRBs in the first time domain resources (SBFD symbols) and outside of uplink usable PRBs (UL usable PRBs) (or the first frequency domain resources), and/or overlapping with symbols indicated as downlink by indication information (x information);

And/or,

The terminal device does not expect a PUSCH to exist in the first time domain resource (SBFD symbol) and overlap with a PRB other than the uplink usable PRB (UL usable PRB) (or the first frequency domain resource), and/or the terminal device does not expect a PUSCH to exist that overlaps with both the first time domain resource (SBFD symbol) and the second time domain resource (non-SBFD symbol).

In some embodiments, configuration authorization PUSCHs that overlap with first temporal domain resources are not sent;

Transmitter 2302 transmits the following PUSCH: not overlapping with SSB, and/or, not overlapping with the first time domain resource (SBFD symbol), and/or, not overlapping with the second time domain resource (non-SBFD symbol) used for downlink, and/or, not overlapping with the symbol indicated as downlink by the indication information (y information);

And/or,

Transmitter 2302 does not transmit the following PUSCH: overlapping with SSB, and/or overlapping with first time domain resources (SBFD symbols), and/or overlapping with second time domain resources (non-SBFD symbols) used for downlink, and/or overlapping with symbols indicated as downlink by indication information (y information);

And/or,

Terminal devices do not expect the existence of PUSCHs that overlap with both the first time-domain resource (SBFD symbol) and the second time-domain resource (non-SBFD symbol).

In some embodiments, configuration grant PUSCHs that overlap with both the first and second time domain resources are not... send;

Transmitter 2302 transmits the following PUSCH: not overlapping with SSB and/or the second time domain resource (DL non-SBFD symbol) used for downlink, and/or, not overlapping with both the first time domain resource (SBFD symbol) and the second time domain resource (non-SBFD symbol), and/or, in the first time domain resource (SBFD symbol) and not overlapping with a PRB other than the uplink usable PRB (UL usable PRB) (or the first frequency domain resource), and/or, not overlapping with a symbol indicated as downlink by the indication information;

And/or,

Transmitter 2302 does not transmit the following PUSCH: overlapping with SSB, and/or, overlapping with the second time domain resource (DL non-SBFD symbol) used for downlink, and/or, overlapping with both the first time domain resource (SBFD symbol) and the second time domain resource (non-SBFD symbol), and/or, overlapping with a PRB in the first time domain resource (SBFD symbol) and other than the uplink usable PRB (UL usable PRB) (or the first frequency domain resource), and/or, overlapping with a symbol indicated as downlink by the indication information;

And/or,

The terminal device does not expect a PUSCH to exist in the first time domain resource (SBFD symbol) and overlap with a PRB other than the uplink usable PRB (UL usable PRB) (or the first frequency domain resource), and/or the terminal device does not expect a PUSCH to exist that overlaps with both the first time domain resource (SBFD symbol) and the second time domain resource (non-SBFD symbol).

In some embodiments, a configuration grant PUSCH that overlaps with both the first time domain resource and the second time domain resource can be sent;

Transmitter 2302 transmits the following PUSCH: not overlapping with SSB and/or the second time domain resource (DL non-SBFD symbol) used for downlink, and/or overlapping with the first time domain resource (SBFD symbol) and not overlapping with PRB other than the uplink usable PRB (UL usable PRB) (or the first frequency domain resource), and/or not overlapping with the symbol indicated by the indication information as downlink;

And/or,

Transmitter 2302 does not transmit the following PUSCH: overlapping with SSB, and/or overlapping with the second time domain resource (DL non-SBFD symbol) used for downlink, and/or overlapping with the first time domain resource (SBFD symbol) and with a PRB other than the uplink usable PRB (UL usable PRB) (or the first frequency domain resource), and/or overlapping with the symbol indicated as downlink by the indication information;

And/or,

Terminal devices do not expect overlap with first time domain resources (SBFD symbols) and uplink available PRBs (UL symbols). PUSCH overlapping with PRB outside of usable PRB.

In some embodiments, the configuration authorization PUSCH that is sent has a corresponding HARQ process ID, while the configuration authorization PUSCH that is not sent does not have a corresponding HARQ process ID.

In some embodiments, the processor 2303 determines the HARQ process ID corresponding to the configuration authorization PUSCH based on RRC signaling and/or MAC signaling and/or DCI and/or reference PUSCH and/or the capabilities of the terminal device, and/or the transmitter 2302 sends one or more configuration authorization PUSCHs with the corresponding HARQ process ID.

In some embodiments, when a first configuration is provided by RRC signaling and/or MAC signaling, the determiner 2303 determines, based on a reference PUSCH and/or first information provided by MAC signaling and/or DCI, a configuration authorization PUSCH with a corresponding HARQ process ID, and/or a configuration authorization PUSCH that will be sent or not sent.

The first configuration indicates that the configuration authorization PUSCH is sent in either the first time domain resource or the second time domain resource, and the first information indicates that the terminal device does not send configuration authorization PUSCH that overlaps with the first time domain resource or configuration authorization PUSCH that overlaps with the second time domain resource.

In some embodiments, the referenced PUSCH is a pre-defined or indicated PUSCH in the configuration authorization PUSCH, or a pre-defined or indicated PUSCH in the following PUSCH:

A PUSCH that does not overlap with an SSB and/or a second time-domain resource (DL non-SBFD symbol) used for downlink, and/or a PUSCH that does not overlap with both the first time-domain resource (SBFD symbol) and the second time-domain resource (non-SBFD symbol), and/or a PUSCH that overlaps with the first time-domain resource (SBFD symbol) and does not overlap with a PRB other than the uplink usable PRB (UL usable PRB) (or the first frequency-domain resource), and/or a PUSCH that does not overlap with a symbol indicated as downlink by the indication information.

In some embodiments, when a second configuration is provided by RRC signaling and/or MAC signaling, the processor 2303 determines, based on a reference PUSCH and/or second information provided by RRC signaling and/or MAC signaling and/or DCI, a configuration authorization PUSCH with a corresponding HARQ process ID, and/or a configuration authorization PUSCH that will be sent or not sent.

The second configuration indicates that the configuration grant PUSCH can be sent in the first time domain resource and/or the second time domain resource; the second information is used to instruct the terminal device to send a configuration grant PUSCH that overlaps with both the first and second time domain resources, or to instruct the terminal device not to send a configuration grant PUSCH that overlaps with both the first and second time domain resources.

It is worth noting that the above description only covers the components or modules relevant to this application, but this application is not limited thereto. The PUSCH transmitting device 2300 of this application embodiment may also include other components or modules, and for details regarding these components or modules, please refer to related technologies.

Furthermore, for simplicity, Figure 23 only illustrates the connection relationships or signal flow between the various components or modules, but those skilled in the art should understand that various related technologies such as bus connections can be used. The aforementioned components or modules can be implemented using hardware facilities such as processors, memory, transmitters, and receivers; this application does not limit this implementation.

The above embodiments are merely illustrative examples of embodiments of this application, but this application is not limited thereto, and appropriate modifications can be made based on the above embodiments. For example, the above embodiments can be used alone, or one or more of the above embodiments can be combined.

As can be seen from the above embodiments, the terminal device sends one or more configuration grant PUSCHs with corresponding HARQ process IDs; wherein, for configuration grants, whether a configuration grant PUSCH has a corresponding HARQ process ID is related to the first time domain resource and/or the second time domain resource. Therefore, the network device can operate in full-duplex mode (simultaneous reception and transmission), and the terminal device can also utilize the corresponding resources to send and receive signals when the network device is operating in full-duplex mode. This can improve uplink transmission capacity and coverage, reduce uplink transmission latency, and increase resource allocation flexibility and resource utilization.

Fourth aspect of the embodiment

This application provides a PUSCH receiving device. This device may be, for example, a network device, or one or more components or parts configured within a network device; details identical to those in the third aspect of the embodiment will not be repeated.

Figure 24 is a schematic diagram of a PUSCH receiving device according to an embodiment of this application. Since the principle of this device in solving the problem is the same as the method of the embodiments of the first and second aspects, its specific implementation can refer to the embodiments of the first and second aspects, and the contents that are the same will not be repeated.

As shown in Figure 24, the PUSCH receiver 2400 includes:

Transmitter 2401 transmits configuration information for configuring at least a first time-domain resource and/or a second time-domain resource; wherein, in the first time-domain resource, a first frequency-domain resource is used for uplink and a second frequency-domain resource is used for downlink, and the second time-domain resource is outside the first time-domain resource; transmits configuration grant (CG) configuration; wherein, for the configuration grant, whether a configuration grant PUSCH has a corresponding HARQ process ID is related to the first time-domain resource and/or the second time-domain resource; and

Receiver 2402 receives one or more configuration authorization PUSCHs with corresponding HARQ process IDs.

It is worth noting that the above description only covers the components or modules relevant to this application, but this application is not limited thereto. The PUSCH receiving device 2400 of this application embodiment may also include other components or modules (such as processors, etc.), and for details of these components or modules, please refer to related technologies.

Furthermore, for simplicity, Figure 24 only illustrates the connection relationships or signal flow between the various components or modules, but those skilled in the art should understand that various related technologies such as bus connections can be used. The aforementioned components or modules can be implemented using hardware facilities such as processors, memory, transmitters, and receivers; this application does not limit this implementation.

The above embodiments are merely illustrative examples of embodiments of this application, but this application is not limited thereto, and appropriate modifications can be made based on the above embodiments. For example, the above embodiments can be used alone, or one or more of the above embodiments can be combined.

As can be seen from the above embodiments, the network device sends one or more PUSCHs with corresponding HARQ process IDs; wherein, for configuration authorization, whether a configuration authorization PUSCH has a corresponding HARQ process ID is related to the first time domain resource and/or the second time domain resource. Therefore, the network device can operate in full-duplex mode (simultaneous reception and transmission), and the terminal device can also utilize the corresponding resources to send and receive signals when the network device is operating in full-duplex mode. This can improve uplink transmission capacity and coverage, reduce uplink transmission latency, and increase resource allocation flexibility and resource utilization.

Fifth aspect of the embodiment

This application also provides a communication system, which can be referred to FIG1. The contents that are the same as those in the embodiments of the first to fourth aspects will not be repeated.

In some embodiments, the communication system 100 may include at least:

A terminal device receives configuration information for configuring at least a first time-domain resource and/or a second time-domain resource; wherein, in the first time-domain resource, a first frequency-domain resource is used for uplink and a second frequency-domain resource is used for downlink, and the second time-domain resource is outside the first time-domain resource; receives configuration grant (CG) configuration, wherein, for configuration grant, whether a configuration grant PUSCH has a corresponding HARQ process ID is related to the first time-domain resource and/or the second time-domain resource; and sends one or more configuration grant PUSCHs among configuration grant PUSCHs having corresponding HARQ process IDs;

A network device that sends configuration information for configuring at least a first time domain resource and/or a second time domain resource; sends configuration authorization (CG) configuration; and receives PUSCH from an end device.

This application also provides a network device, such as a base station, but this application is not limited to this and may also include other network devices.

Figure 25 is a schematic diagram of the configuration of a network device according to an embodiment of this application. As shown in Figure 25, the network device 2500 may include: a processor 2510 (e.g., a central processing unit CPU) and a memory 2520; the memory 2520 is coupled to the processor. The memory 2520 can store various data; in addition, it stores an information processing program 2530, and executes the program 2530 under the control of the processor 2510.

For example, processor 2510 can be configured to execute a program to implement the method as described in the embodiments of the second aspect.

In addition, as shown in Figure 25, network device 2500 may also include: transceiver 2540 and antenna 2550, etc.; the functions of the above components are similar to those in the prior art, and will not be described in detail here. It is worth noting that network device 2500 does not necessarily include all the components shown in Figure 25; furthermore, network device 2500 may also include components not shown in Figure 25, which can be referred to in the prior art.

This application also provides a terminal device, but the application is not limited thereto and may also include other devices.

Figure 26 is a schematic diagram of a terminal device according to an embodiment of this application. As shown in Figure 26, the terminal device 2600 may include a processor 2610 and a memory 2620; the memory 2620 stores data and programs and is coupled to the processor 2610. It is worth noting that this figure is exemplary; other types of structures may also be used to supplement or replace this structure to implement telecommunications functions or other functions.

For example, processor 2610 can be configured to execute a program to implement the method as described in the embodiments of the first aspect.

As shown in Figure 26, the terminal device 2600 may further include: a communication module 2630, an input device 2640, a display 2650, and a power supply 2660. The functions of these components are similar to those in the prior art and will not be described in detail here. It is worth noting that the terminal device 2600 does not necessarily include all the components shown in Figure 26; these components are not essential. Furthermore, the terminal device 2600 may also include components not shown in Figure 26, which can be referred to in the prior art.

This application also provides a computer-readable program, wherein when the program is executed in a network device, the program causes the computer to perform the method described in the second aspect of the embodiment in the network device.

This application also provides a storage medium storing a computer-readable program, wherein the computer-readable program causes a computer in a network device to perform the methods described in the second aspect of the embodiments.

This application also provides a computer-readable program, wherein when the program is executed in a terminal device, the program causes the computer to perform the method described in the first aspect of the embodiment in the terminal device.

This application also provides a storage medium storing a computer-readable program, wherein the computer-readable program causes a computer in a terminal device to perform the method described in the first aspect of the embodiments.

The apparatuses and methods described above in this application can be implemented in hardware or in combination with software. This application relates to computer-readable programs that, when executed by a logic component, enable the logic component to implement the apparatuses or components described above, or to implement the various methods or steps described above. Logic components include, for example, field-programmable logic devices (FPGAs), microprocessors, and processors used in computers. This application also relates to storage... The storage media for the above programs include hard disks, magnetic disks, optical discs, DVDs, flash memory, etc.

The methods/apparatus described in conjunction with the embodiments of this application can be directly embodied in hardware, software modules executed by a processor, or a combination of both. For example, one or more and/or combinations of one or more functional block diagrams shown in the figures can correspond to various software modules in a computer program flow, or to various hardware modules. These software modules can correspond to the various steps shown in the figures, respectively. These hardware modules can be implemented, for example, using a field-programmable gate array (FPGA) to embed these software modules.

The software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art. A storage medium can be coupled to the processor, enabling the processor to read information from and write information to the storage medium; or the storage medium can be an integral part of the processor. The processor and storage medium can reside in an ASIC. The software module can be stored in the memory of a mobile terminal or in a memory card that can be inserted into the mobile terminal. For example, if the device (such as a mobile terminal) uses a high-capacity MEGA-SIM card or a high-capacity flash memory device, the software module can be stored in the MEGA-SIM card or the high-capacity flash memory device.

One or more and/or one or more combinations of functional blocks described in the accompanying drawings can be implemented as a general-purpose processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic device, discrete hardware component, or any suitable combination thereof for performing the functions described herein. One or more and/or one or more combinations of functional blocks described in the accompanying drawings can also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in communication with a DSP, or any other such configuration.

The present application has been described above with reference to specific embodiments. However, those skilled in the art should understand that these descriptions are exemplary and not intended to limit the scope of protection of the present application. Those skilled in the art can make various modifications and variations to the present application based on its spirit and principles, and these modifications and variations are also within the scope of the present application.

Regarding the implementation methods including the above embodiments, the following notes are also disclosed:

1. A method for sending a PUSCH, comprising:

The terminal device receives configuration information for configuring at least a first time domain resource and/or a second time domain resource; wherein, in the first time domain resource, a first frequency domain resource is used for uplink and a second frequency domain resource is used for downlink, and the second time domain resource is outside the first time domain resource;

The terminal device receives a configuration authorization (CG) configuration, wherein, for configuration authorization, a configuration authorization PUSCH is provided. Whether a corresponding HARQ process ID exists depends on the first time-domain resource and/or the second time-domain resource; and

The terminal device sends one or more configuration authorization PUSCHs from among the configuration authorization PUSCHs with corresponding HARQ process IDs.

2. A PUSCH receiving method, comprising:

The network device sends configuration information for configuring at least a first time domain resource and/or a second time domain resource; wherein, in the first time domain resource, a first frequency domain resource is used for uplink and a second frequency domain resource is used for downlink, and the second time domain resource is outside the first time domain resource;

The network device sends a configuration grant (CG) configuration, wherein, for a configuration grant, whether a configuration grant PUSCH has a corresponding HARQ process ID is related to a first time domain resource and/or a second time domain resource; and

The network device receives one or more configuration authorization PUSCHs from the configuration authorization PUSCHs that have corresponding HARQ process IDs.

3. A terminal device comprising a memory and a processor, the memory storing a computer program and the processor being configured to execute the computer program to implement the PUSCH transmission method as described in Appendix 1.

4. A network device comprising a memory and a processor, the memory storing a computer program and the processor being configured to execute the computer program to implement the PUSCH receiving method as described in Appendix 2.

5. A computer program product comprising at least a computer program that, when executed by a processor, causes a terminal device to perform the PUSCH transmission method as described in Appendix 1.

6. A computer program product comprising at least a computer program that, when executed by a processor, causes a network device to perform the PUSCH receiving method as described in Appendix 2.

Claims (20)

A PUSCH transmitting device, comprising: A receiver receives configuration information for configuring at least a first time-domain resource and/or a second time-domain resource; wherein, in the first time-domain resource, a first frequency-domain resource is used for uplink and a second frequency-domain resource is used for downlink, and the second time-domain resource is outside the first time-domain resource; and receives configuration grant configuration, wherein, for configuration grant, whether a configuration grant PUSCH has a corresponding HARQ process ID is related to the first time-domain resource and/or the second time-domain resource; and The transmitter sends one or more configuration authorization PUSCHs from the configuration authorization PUSCHs that have the corresponding HARQ process ID. According to the apparatus of claim 1, whether a configuration authorization PUSCH has a corresponding HARQ process ID is related to the first time domain resource and/or the second time domain resource, including: If a configuration-granted PUSCH overlaps with a second time-domain resource used for downlink, then the configuration-granted PUSCH does not have a corresponding HARQ process ID, and/or, If a configuration-authorized PUSCH overlaps with a first time-domain resource, then the configuration-authorized PUSCH does not have a corresponding HARQ process ID, and/or, If a configuration-granted PUSCH overlaps with both second-time-domain resources, then the configuration-granted PUSCH does not have a corresponding HARQ process ID, and/or, If a configuration-authorized PUSCH overlaps with both the first and second time-domain resources, then the configuration-authorized PUSCH does not have a corresponding HARQ process ID, and/or, If a configuration-granted PUSCH overlaps with a first time-domain resource and also overlaps with a frequency-domain resource other than an uplink available PRB, the configuration-granted PUSCH does not have a corresponding HARQ process ID. The apparatus according to claim 1, wherein the configuration grant has a plurality of consecutive configuration grant PUSCHs in a period, and/or the configuration grant has a plurality of non-consecutive configuration grant PUSCHs in a period; The device further includes: The processor determines the first configuration grant PUSCH and the HARQ process ID for each subsequent valid configuration grant PUSCH in the cycle. The apparatus of claim 3, wherein the effective configuration grant PUSCH does not overlap with SSB symbols, and/or does not overlap with second time-domain resources used for downlink, and/or does not overlap with first time-domain resources and second time-domain resources. Both time-domain resources overlap, and/or overlap with the first time-domain resource but not with frequency-domain resources other than the uplink available PRB, and/or not overlap with symbols indicated as downlink by the indication information, and/or start from the SBFD symbol and end at the non-SBFD symbol, and/or start from the non-SBFD symbol and end at the SBFD symbol. The apparatus of claim 3, wherein the following configuration grant PUSCHs in the cycle are not valid configuration grant PUSCHs: overlapping with SSB symbols, and/or overlapping with second time-domain resources used for downlink, and/or overlapping with both first and second time-domain resources, and/or overlapping with first time-domain resources and frequency-domain resources other than uplink available PRBs, and/or overlapping with symbols indicated as downlink by indication information, and/or not starting from an SBFD symbol and ending at a non-SBFD symbol, and/or not starting from a non-SBFD symbol and ending at an SBFD symbol. According to the apparatus of claim 3, the HARQ process ID of the configuration authorization PUSCH is determined based on a first parameter; wherein, for the first configuration authorization PUSCH in a cycle, the first parameter is zero, and for the valid configuration authorization PUSCHs after the first configuration authorization PUSCH in the same cycle, the first parameter is a value greater than or equal to 1 and less than the number of configuration authorization PUSCHs in a cycle. The apparatus according to claim 3, wherein the processor further determines the valid configuration authorization PUSCH based on the PUSCH transmission limit corresponding to the configuration authorization. The PUSCH transmission restrictions include: The terminal device does not send a configuration grant PUSCH that overlaps with the second time-domain resource; and/or The terminal device does not send configuration grant PUSCHs that overlap with the first time-domain resources; and/or The terminal device does not send configuration authorization PUSCHs that overlap with both the first time domain resource and the second time domain resource. The apparatus of claim 7, wherein the PUSCH transmission restriction is indicated and/or determined according to at least one of the following: RRC signaling, MAC signaling, downlink control information, reference PUSCH, or the capability of the terminal device. According to the apparatus of claim 7, under different PUSCH transmission restrictions, the configuration-authorized PUSCH with the corresponding HARQ process ID needs to meet the same conditions. or, Under different PUSCH sending restrictions, the conditions that need to be met for a configuration-authorized PUSCH with the corresponding HARQ process ID are different. The apparatus according to claim 1, wherein the configuration authorization overlapping with the second time-domain resource PUSCH is not sent; The transmitter sends a configuration grant PUSCH that does not overlap with an SSB symbol, and/or does not overlap with a second time-domain resource, and/or, in a first time-domain resource and not overlap with a PRB other than an uplink available PRB, and/or, does not overlap with a symbol indicated as downlink by the indication information. And/or, The transmitter does not send configuration grant PUSCHs that overlap with SSB symbols, and/or overlap with second time domain resources, and/or overlap with PRBs in first time domain resources other than uplink available PRBs, and/or overlap with symbols indicated as downlink by the indication information. And/or, The terminal device does not expect a PUSCH that exists in the first time domain resource and overlaps with a PRB other than the uplink available PRB, and/or the terminal device does not expect a configuration grant PUSCH that overlaps with both the first and second time domain resources. The apparatus according to claim 1, wherein the configuration grant PUSCH that overlaps with the first time-domain resource is not sent; The transmitter sends a configuration grant PUSCH that does not overlap with an SSB, and/or does not overlap with a first time domain resource, and/or does not overlap with a second time domain resource used for downlink, and/or does not overlap with a symbol indicated as downlink by an indication message; And/or, The transmitter does not send configuration grant PUSCHs that overlap with SSBs, and/or overlap with first time domain resources, and/or overlap with second time domain resources used for downlink, and/or overlap with symbols indicated as downlink by indication information; And/or, Terminal devices do not expect configuration authorization PUSCHs that overlap with both the first and second time domain resources. According to the apparatus of claim 1, configuration grant PUSCHs that overlap with both the first time-domain resource and the second time-domain resource are not sent; The transmitter sends a configuration grant PUSCH that does not overlap with an SSB and/or a second time-domain resource used for downlink, and/or does not overlap with both a first time-domain resource and a second time-domain resource, and/or overlaps with a PRB other than an uplink available PRB in the first time-domain resource, and/or does not overlap with a symbol indicated as downlink by the indication information. And/or, The transmitter does not send configuration grant PUSCHs that overlap with SSBs, and/or overlap with second time-domain resources used for downlink, and/or overlap with both first and second time-domain resources, and/or overlap with PRBs in the first time-domain resource and other than uplink available PRBs, and/or overlap with symbols indicated as downlink by the indication information. And/or, The terminal device does not expect a PUSCH that exists in the first time domain resource and overlaps with a PRB other than the uplink available PRB, and/or the terminal device does not expect a configuration grant PUSCH that overlaps with both the first and second time domain resources. According to the apparatus of claim 1, a configuration grant PUSCH that overlaps with both the first time domain resource and the second time domain resource can be sent; The transmitter sends a configuration grant PUSCH that does not overlap with an SSB and/or a second time-domain resource used for downlink, and/or overlaps with a first time-domain resource and does not overlap with a PRB other than an uplink available PRB, and/or does not overlap with a symbol indicated as downlink by the indication information. And/or, The transmitter does not send configuration grant PUSCHs that overlap with SSBs, and/or overlap with second time-domain resources used for downlink, and/or overlap with first time-domain resources and with PRBs other than uplink available PRBs, and/or overlap with symbols indicated as downlink by indication information. And/or, Terminal devices do not expect configuration authorization PUSCHs that overlap with first time domain resources and with PRBs other than those available uplink PRBs. According to the apparatus of claim 1, the sent configuration authorization PUSCH has a corresponding HARQ process ID, and the unsent configuration authorization PUSCH does not have a corresponding HARQ process ID. The apparatus according to claim 1, wherein the apparatus further comprises: The processor, based on higher-layer signaling and/or downlink control information and/or referencing the capabilities of the PUSCH and/or the terminal device, determines the HARQ process ID corresponding to the authorized PUSCH, and/or... The transmitter sends one or more configuration authorization PUSCHs from the configuration authorization PUSCHs that have corresponding HARQ process IDs. The apparatus according to claim 15, wherein, When the processor is provided with a first configuration by higher-layer signaling, it determines, based on a reference PUSCH and/or first information provided by MAC signaling and/or downlink control information, the configuration authorization PUSCH with the corresponding HARQ process ID, and/or the configuration authorization PUSCH that will be sent or not sent. Wherein, the first configuration indicates that the configuration authorization PUSCH is sent in either the first time domain resource or the second time domain resource, and the first information indicates that the terminal device does not send configuration authorization PUSCH that overlaps with the first time domain resource or configuration authorization PUSCH that overlaps with the second time domain resource. The apparatus of claim 15, wherein the reference PUSCH is a predetermined or indicated PUSCH among the configuration-authorized PUSCHs, or a predetermined or indicated PUSCH among the following: A PUSCH that does not overlap with an SSB and/or a second time-domain resource used for downlink, and/or a PUSCH that does not overlap with both a first time-domain resource and a second time-domain resource, and/or a PUSCH that overlaps with a first time-domain resource but does not overlap with a PRB other than an uplink available PRB, and/or a PUSCH that does not overlap with a symbol indicated as downlink by the indicated information. The apparatus according to claim 15, wherein, When the processor is provided with a second configuration by higher-layer signaling, it determines, based on a reference PUSCH and/or second information provided by RRC signaling and/or MAC signaling and/or downlink control information, the configuration authorization PUSCH with the corresponding HARQ process ID, and/or the configuration authorization PUSCH that will be sent or not sent. Wherein, the second configuration indicates that the configuration authorization PUSCH can be sent in the first time domain resource and/or the second time domain resource; the second information is used to instruct the terminal device to send a configuration authorization PUSCH that overlaps with both the first and second time domain resources, or to instruct the terminal device not to send a configuration authorization PUSCH that overlaps with both the first and second time domain resources. A PUSCH receiving device, comprising: A transmitter that transmits configuration information for configuring at least a first time-domain resource and/or a second time-domain resource; wherein, in the first time-domain resource, a first frequency-domain resource is used for uplink and a second frequency-domain resource is used for downlink, and the second time-domain resource is outside the first time-domain resource; and transmits configuration authorization configuration, wherein, for configuration authorization, whether a configuration authorization PUSCH has a corresponding HARQ process ID is related to the first time-domain resource and/or the second time-domain resource; and The receiver receives one or more configuration authorization PUSCHs from the configuration authorization PUSCHs that have the corresponding HARQ process ID. A communication system, comprising: A terminal device receives configuration information for configuring at least a first time-domain resource and/or a second time-domain resource; wherein, in the first time-domain resource, a first frequency-domain resource is used for uplink and a second frequency-domain resource is used for downlink, and the second time-domain resource is outside the first time-domain resource; receives configuration authorization configuration, wherein, for configuration authorization, whether a configuration authorization PUSCH has a corresponding HARQ process ID is related to the first time-domain resource and/or the second time-domain resource; and sends one or more configuration authorization PUSCHs among the configuration authorization PUSCHs with corresponding HARQ process IDs; A network device that sends configuration information for configuring at least a first time domain resource and/or a second time domain resource; sends configuration authorization configuration; and receives at least one PUSCH from the terminal device.