Communication method and related apparatus

Abstract

A communication method and a related apparatus, applicable to the technical field of communications. On the basis of configuration information of two types of carriers, i.e., carriers configured with SBFD and carriers not configured with SBFD, as well as scheduling information, a first communication apparatus may determine whether UCI needs to be multiplexed onto a PUSCH for transmission, thereby supplementing multiplexing rules between different types of carriers that are not specified in the prior art.

Description

Communication methods and related devices

[0001] This application claims priority to Chinese Patent Application No. 202510389373.0, filed on March 27, 2025, entitled "Communication Method and Related Apparatus", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of communication technology, and in particular to communication methods and related devices. Background Technology

[0003] For carrier aggregation (CA) scenarios (also known as multi-carrier scenarios), it is currently supported to configure subband full duplex (SBFD) operation on one of the carriers. Taking a scenario with two carriers as an example, there will be one carrier configured with SBFD and another carrier without SBFD.

[0004] In multi-carrier scenarios, if SBFD operation is configured on one of the carriers, and the configuration is set to configuration 1, how to multiplex UCI to PUSCH across multiple carriers for repeated, periodic, or semi-persistent transmissions of valid symbol types that are SBFD symbols is a hot topic of research for those skilled in the art. Summary of the Invention

[0005] This application provides a communication method and related apparatus that enables multiplexing of UCI to PUSCH in a multi-carrier system with SBFD configured on a single carrier.

[0006] In a first aspect, embodiments of this application provide a communication method, which can be applied to a first communication device. The first communication device may be, for example, a terminal device, or a module in the terminal device (wherein the module in the terminal device includes a communication module and a computing module), or a circuit or chip in the terminal device responsible for communication functions (such as a modem chip, also known as a baseband chip, or a system-on-chip (SoC) chip containing a modem core or a system-in-package (SIP) chip), or the first communication device may also be a logic module or software capable of implementing all or part of the functions of the terminal device. The method includes: receiving configuration information and scheduling information from a second communication device, wherein the configuration information includes identification information of multiple carriers, sub-band full-duplex (SBFD) configuration information of at least one first carrier among the multiple carriers, and configuration information of at least one second carrier, wherein the at least one second carrier is a carrier among the multiple carriers other than the at least one first carrier that is not configured with SBFD; the scheduling information includes uplink physical shared channel (PUSCH) scheduling information and uplink physical control channel (PUCCH) scheduling information, wherein the PUCCH scheduling information is used to schedule the PUCCH carrying uplink control information (UCI). A multiplexing result is determined based on the configuration information and the scheduling information, wherein the multiplexing result is used to characterize whether the UCI is multiplexed onto the PUSCH for transmission.

[0007] In this application, the first communication device can determine whether UCI needs to be multiplexed onto the PUSCH for transmission based on the configuration information and scheduling information of two types of carriers, one with SBFD configured and the other without SBFD configured, thus supplementing the multiplexing rules between different types of carriers not specified in the prior art. This solution provides multiplexing rules for UCI and PUSCH between different types of carriers, and performs UCI multiplexing according to the multiplexing rules, thereby improving the SBFD system design.

[0008] In one possible implementation, the scheduling information of the PUCCH is used to indicate that a PUCCH exists on the at least one first carrier, the scheduling information of the PUSCH is used to indicate that a PUSCH exists on the at least one second carrier, the PUCCH and PUSCH partially or completely overlap in time, the configuration information of the at least one first carrier is used to indicate that an SBFD symbol is configured on the at least one first carrier, and the configuration information of the at least one second carrier is used to indicate that the SBFD symbol is not configured on the at least one second carrier.

[0009] In the above embodiments, a UCI and PUSCH multiplexing scenario between carriers is provided. For example, the first carrier is CC1, which is configured with SBFD and has PUCCH; the second carrier is CC2, which is not configured with SBFD but has PUSCH; the PUCCH and PUSCH overlap in time. The scenario illustrated in this solution can be used for subsequent UCI multiplexing according to the multiplexing rules between different types of carriers, thus improving the SBFD system design.

[0010] In another possible implementation, the scheduling information of the PUSCH is used to indicate that a PUSCH exists on the at least one first carrier, the scheduling information of the PUCCH is used to indicate that a PUCCH exists on the at least one second carrier, the PUCCH and PUSCH partially or completely overlap in time, the configuration information of the at least one first carrier is used to indicate that an SBFD symbol is configured on the at least one first carrier, and the configuration information of the at least one second carrier is used to indicate that the SBFD symbol is not configured on the at least one second carrier.

[0011] In the above embodiments, a UCI and PUSCH multiplexing scenario between carriers is provided. For example, the first carrier is CC1, which is configured with SBFD and has PUSCH; the second carrier is CC2, which is not configured with SBFD but has PUCCH; the PUCCH and PUSCH overlap in time. The scenario illustrated in this solution can be used for subsequent UCI multiplexing according to the multiplexing rules between different types of carriers, thus improving the SBFD system design.

[0012] In another possible implementation, determining the multiplexing result based on the configuration information and the scheduling information includes: multiplexing the UCI carried on the PUCCH onto the PUSCH for transmission based on the configuration information and the scheduling information.

[0013] In the above embodiments, a scheme is provided that, without distinguishing the valid symbol type of the PUCCH on the first carrier, the UCI can be placed on the PUSCH and transmitted along with data, or the UCI can be multiplexed onto the PUSCH for transmission, according to existing rules based on the different UCI content carried on the PUCCH. Since this scheme does not require distinguishing the valid symbol type of the PUCCH, it only needs to determine whether the UCI needs to be multiplexed onto the PUSCH for transmission based on existing multiplexing rules. This scheme increases the probability of successful UCI transmission when it is necessary to multiplex the UCI onto the PUSCH for transmission.

[0014] In another possible implementation, determining the multiplexing result based on the configuration information and the scheduling information includes: not multiplexing the UCI onto the PUSCH based on the configuration information and the scheduling information.

[0015] Alternatively, determining the multiplexing result based on the configuration information and the scheduling information includes: discarding the UCI carried on the PUCCH or discarding the PUSCH based on the configuration information and the scheduling information.

[0016] In the above embodiments, a scheme is provided that, without distinguishing the valid symbol type of the PUCCH on the first carrier, and according to existing rules, UCI can be transmitted without multiplexing it onto the PUSCH, and only the PUSCH or only the PUCCH can be transmitted. Since this scheme does not need to distinguish the valid symbol type of the PUCCH, it only needs to determine whether UCI needs to be multiplexed onto the PUSCH for transmission based on existing multiplexing rules. This scheme can guarantee the successful transmission of either PUSCH or UCI even when UCI does not need to be multiplexed onto the PUSCH.

[0017] In another possible implementation, determining the multiplexing result includes: when the effective symbol type of the PUCCH on the at least one first carrier is a non-SBFD symbol, multiplexing the UCI carried on the PUCCH onto the PUSCH for transmission.

[0018] In the above implementation, when the first carrier is CC1, CC1 is configured with SBFD and has PUCCH; the second carrier is CC2, CC2 is not configured with SBFD and has PUSCH; and in a multiplexing scenario where PUCCH and PUSCH overlap in time, a scheme is provided to multiplex the UCI carried on PUCCH to PUSCH for transmission when the effective symbol type of PUCCH on the first carrier is distinguished and at least one of the effective symbol types of PUCCH on the first carrier is a non-SBFD symbol. By distinguishing the effective symbol type, it is possible to more accurately determine whether to multiplex the UCI carried on PUCCH to PUSCH for transmission.

[0019] In another possible implementation, determining the multiplexing result includes: when the effective symbol type of the PUCCH on the at least one first carrier is SBFD symbol, not multiplexing the UCI onto the PUSCH for transmission or not transmitting the PUSCH.

[0020] In the above implementation, when the first carrier is CC1, CC1 is configured with SBFD and has PUCCH; the second carrier is CC2, CC2 is not configured with SBFD and has PUSCH; and in a multiplexing scenario where PUCCH and PUSCH overlap in time, a scheme is provided that, when distinguishing the valid symbol type of PUCCH on the first carrier and at least one of the valid symbol types of PUCCH on the first carrier is SBFD symbol, the UCI is not multiplexed onto the PUSCH for transmission or the PUSCH is not transmitted. By distinguishing the valid symbol type, it is possible to more accurately determine whether to multiplex the UCI carried on the PUCCH onto the PUSCH for transmission.

[0021] In another possible implementation, determining the multiplexing result includes: when the effective symbol type of the PUSCH on the at least one first carrier is a non-SBFD symbol, multiplexing the UCI carried on the PUCCH onto the PUSCH for transmission.

[0022] In the above implementation, when the first carrier is CC1, CC1 is configured with SBFD and has PUSCH; the second carrier is CC2, CC2 is not configured with SBFD and has PUCCH; and in a multiplexing scenario where PUCCH and PUSCH overlap in time, a scheme is provided to multiplex the UCI carried on PUCCH to PUSCH for transmission when the effective symbol type of PUCCH on the first carrier is distinguished and the effective symbol type of at least one PUSCH on the first carrier is a non-SBFD symbol. By distinguishing the effective symbol type, it is possible to more accurately determine whether to multiplex the UCI carried on PUCCH to PUSCH for transmission.

[0023] In another possible implementation, determining the multiplexing result includes: when the effective symbol type of the PUSCH on the at least one first carrier is SBFD symbol, not multiplexing the UCI onto the PUSCH for transmission or not transmitting the PUSCH.

[0024] In the above implementation, when the first carrier is CC1, CC1 is configured with SBFD and has PUSCH; the second carrier is CC2, CC2 is not configured with SBFD and has PUCCH; and in a multiplexing scenario where PUCCH and PUSCH overlap in time, a scheme is provided that, when the effective symbol type of PUCCH on the first carrier is distinguished and at least one of the effective symbol types of PUSCH on the first carrier is SBFD symbol, the UCI is not multiplexed onto the PUSCH for transmission or the PUSCH is not transmitted. By distinguishing the effective symbol type, it is possible to more accurately determine whether to multiplex the UCI carried on the PUCCH onto the PUSCH for transmission.

[0025] In another possible implementation, the step of multiplexing the UCI carried on the PUCCH onto the PUSCH for transmission includes: determining the effective symbol type of the PUCCH or PUSCH on the at least one first carrier; and multiplexing the UCI carried on the PUCCH onto the PUSCH for transmission according to the effective symbol type of the PUCCH or PUSCH.

[0026] In the above implementation, UCI multiplexing between different types of carriers can be performed first, and then valid symbol type determination can be performed on carriers configured with SBFD. This scheme can prioritize maximizing the probability of successful UCI multiplexing.

[0027] In another possible implementation, after multiplexing the UCI carried on the PUCCH onto the PUSCH for transmission, the method further includes: determining the effective symbol type of the PUSCH on the at least one first carrier.

[0028] In the above implementation, since the UCI carried on the PUCCH between different types of carriers is multiplexed onto the PUSCH, only the PUSCH remains. Therefore, this scheme only needs to determine the valid symbol type of the PUSCH to obtain the final result.

[0029] Secondly, embodiments of this application provide a communication method that can be applied to a second communication device. The second communication device may be, for example, a network device, or a module in the network device (wherein the module in the network device includes a communication module and a computing module), or a circuit or chip in the network device responsible for communication functions (such as a modem chip, also known as a baseband chip, or a system-on-chip (SoC) chip containing a modem core or a system-in-package (SIP) chip). Alternatively, the second communication device may also be a logic module or software capable of implementing all or part of the functions of the network device. The method includes: sending configuration information and scheduling information to a first communication device, wherein the configuration information includes identification information of multiple carriers, sub-band full-duplex (SBFD) configuration information of at least one first carrier among the multiple carriers, and configuration information of at least one second carrier, wherein the at least one second carrier is a carrier among the multiple carriers other than the at least one first carrier that is not configured with SBFD; the scheduling information includes uplink physical shared channel (PUSCH) scheduling information and uplink physical control channel (PUCCH) scheduling information, wherein the PUCCH scheduling information is used to schedule the PUCCH carrying uplink control information (UCI). A multiplexing result is determined based on the configuration information and the scheduling information, wherein the multiplexing result is used to characterize whether the received PUSCH multiplexes the UCI.

[0030] In this application, the second communication device can determine whether the first communication device should multiplex UCI onto the PUSCH for transmission based on the configuration information and scheduling information of two types of carriers, one with SBFD configured and the other without SBFD configured. This supplements the multiplexing rules between different types of carriers not specified in the prior art. This solution provides multiplexing rules for UCI and PUSCH between different types of carriers, and UCI multiplexing is performed according to the multiplexing rules, thus improving the SBFD system design.

[0031] In one possible implementation, the scheduling information of the PUCCH is used to indicate that a PUCCH exists on the at least one first carrier, the scheduling information of the PUSCH is used to indicate that a PUSCH exists on the at least one second carrier, the PUCCH and PUSCH partially or completely overlap in time, the configuration information of the at least one first carrier is used to indicate that an SBFD symbol is configured on the at least one first carrier, and the configuration information of the at least one second carrier is used to indicate that the SBFD symbol is not configured on the at least one second carrier.

[0032] In another possible implementation, the scheduling information of the PUSCH is used to indicate that a PUSCH exists on the at least one first carrier, the scheduling information of the PUCCH is used to indicate that a PUCCH exists on the at least one second carrier, the PUCCH and PUSCH partially or completely overlap in time, the configuration information of the at least one first carrier is used to indicate that an SBFD symbol is configured on the at least one first carrier, and the configuration information of the at least one second carrier is used to indicate that the SBFD symbol is not configured on the at least one second carrier.

[0033] In another possible implementation, determining the multiplexing result based on the configuration information and the scheduling information includes: multiplexing the UCI carried on the PUCCH onto the PUSCH for transmission based on the configuration information and the scheduling information.

[0034] In another possible implementation, determining the multiplexing result based on the configuration information and the scheduling information includes: not multiplexing the UCI onto the PUSCH based on the configuration information and the scheduling information.

[0035] In another possible implementation, determining the multiplexing result includes: when the effective symbol type of the PUCCH on the at least one first carrier is a non-SBFD symbol, multiplexing the UCI carried on the PUCCH onto the PUSCH for transmission.

[0036] In another possible implementation, determining the multiplexing result includes: when the effective symbol type of the PUCCH on the at least one first carrier is SBFD symbol, not multiplexing the UCI onto the PUSCH for transmission or not transmitting the PUSCH.

[0037] In another possible implementation, determining the multiplexing result includes: when the effective symbol type of the PUSCH on the at least one first carrier is a non-SBFD symbol, multiplexing the UCI carried on the PUCCH onto the PUSCH for transmission.

[0038] In another possible implementation, determining the multiplexing result includes: when the effective symbol type of the PUSCH on the at least one first carrier is SBFD symbol, not multiplexing the UCI onto the PUSCH for transmission or not transmitting the PUSCH.

[0039] In another possible implementation, the step of multiplexing the UCI carried on the PUCCH onto the PUSCH for transmission includes: determining the effective symbol type of the PUCCH or PUSCH on the at least one first carrier; and multiplexing the UCI carried on the PUCCH onto the PUSCH for transmission according to the effective symbol type of the PUCCH or PUSCH.

[0040] In another possible implementation, after multiplexing the UCI carried on the PUCCH onto the PUSCH for transmission, the method further includes: determining the effective symbol type of the PUSCH on the at least one first carrier.

[0041] Thirdly, embodiments of this application provide a communication device that can be used in the first communication device of the first aspect. The first communication device can be a terminal device, a device in the terminal device (e.g., a chip, a chip system, or a circuit), or a device that can be matched with the terminal device. It can also be a logic module or software that can realize all or part of the functions of the terminal device.

[0042] In one possible implementation, the communication device may include modules or units that perform the methods / operations / steps / actions described in the first aspect. These modules or units may be hardware circuits, software, or a combination of hardware circuits and software.

[0043] Fourthly, embodiments of this application provide a communication device that can be used in the communication device of the second aspect. The communication device can be a network device, a device in a network device (e.g., a chip, a chip system, or a circuit), or a device that can be used in conjunction with a network device, or a logic module or software that can implement all or part of the functions of a network device.

[0044] In one possible implementation, the communication device may include modules or units that perform the methods / operations / steps / actions described in the second aspect. These modules or units may be hardware circuits, software, or a combination of hardware circuits and software.

[0045] Fifthly, embodiments of this application provide a communication device, which includes at least one processor and a communication interface; the communication interface is used for inputting and / or outputting information, and the at least one processor is used to call a computer program stored in at least one memory to implement the method described in any one of the first to second aspects.

[0046] In one possible implementation of the fifth aspect, the communication device further includes at least one of the aforementioned memories. Optionally, the memory and processor are integrated together.

[0047] In a sixth aspect, embodiments of this application provide a communication device, which includes a logic circuit and an interface, the logic circuit and the interface being coupled; the interface is used to input and / or output information, and the logic circuit is used to implement the method described in any of the embodiments of the first to second aspects.

[0048] In one possible implementation of the sixth aspect, the communication device is a chip or chip system.

[0049] In a seventh aspect, embodiments of this application provide a communication system, which includes a first communication device and a second communication device, and the first communication device and the second communication device are communicatively connected. The first communication device is used to implement the method of any embodiment of the first aspect, and the second communication device is used to implement the method of any embodiment of the second aspect.

[0050] Eighthly, embodiments of this application provide a computer-readable storage medium for storing instructions or computer programs; when the instructions or computer programs are executed, they implement the method of any one of the embodiments of the first to second aspects.

[0051] Ninthly, this application provides a computer program product including computer instructions that, when executed on at least one processor, can implement the methods described in any of the first to second aspects or any possible implementations thereof. Exemplarily, the computer program product can be a software installation package, which can be downloaded and executed on a computing device when the aforementioned methods are required.

[0052] The beneficial effects of the technical solutions provided in the second to ninth aspects of this application can be referred to the beneficial effects of the technical solutions in the first aspect, and will not be repeated here. Attached Figure Description

[0053] The accompanying drawings used in the description of the embodiments will be briefly introduced below.

[0054] Figure 1 is a schematic diagram of the architecture of a communication system provided in an embodiment of this application;

[0055] Figure 2 is a schematic diagram of the architecture of another communication system provided in an embodiment of this application;

[0056] Figure 3 is a schematic diagram of an O-RAN system provided in an embodiment of this application;

[0057] Figure 4 is a diagram showing the network element function division and protocol layer structure of an open radio access network (O-RAN) system provided in an embodiment of this application;

[0058] Figure 5 is a schematic diagram of a duplex system provided in an embodiment of this application;

[0059] Figure 6 is a schematic diagram of a time-domain configuration method provided in an embodiment of this application;

[0060] Figure 7 is a schematic diagram of a frequency domain configuration method provided in an embodiment of this application;

[0061] Figure 8 is a flowchart illustrating a communication method provided in an embodiment of this application;

[0062] Figure 9A is a schematic diagram of a multiplexing method provided in an embodiment of this application, in which UCI carried on PUCCH is multiplexed onto PUSCH for transmission;

[0063] Figure 9B is a schematic diagram of another multiplexing method provided by an embodiment of this application, which multiplexes the UCI carried on the PUCCH onto the PUSCH for transmission;

[0064] Figure 9C is a schematic diagram of another multiplexing method provided by an embodiment of this application, which multiplexes the UCI carried on the PUCCH onto the PUSCH for transmission;

[0065] Figure 10A is a schematic diagram of another multiplexing method provided by an embodiment of this application, which multiplexes the UCI carried on the PUCCH onto the PUSCH for transmission;

[0066] Figure 10B is a schematic diagram of another multiplexing method provided by an embodiment of this application, which multiplexes the UCI carried on the PUCCH onto the PUSCH for transmission;

[0067] Figure 10C is a schematic diagram of another multiplexing method provided by an embodiment of this application, which multiplexes the UCI carried on the PUCCH onto the PUSCH for transmission;

[0068] Figure 11A is a schematic diagram of a multiplexing method provided in an embodiment of this application, in which UCI carried on PUCCH is multiplexed onto PUSCH for transmission;

[0069] Figure 11B is a schematic diagram of another multiplexing method provided by an embodiment of this application, which multiplexes the UCI carried on the PUCCH onto the PUSCH for transmission;

[0070] Figure 12A is a schematic diagram of another multiplexing method provided by an embodiment of this application, which multiplexes the UCI carried on the PUCCH onto the PUSCH for transmission;

[0071] Figure 12B is a schematic diagram of another multiplexing method provided by an embodiment of this application, which multiplexes the UCI carried on the PUCCH onto the PUSCH for transmission;

[0072] Figure 13 is a schematic diagram of the structure of a communication device 130 provided in an embodiment of this application;

[0073] Figure 14 is a structural schematic diagram of another communication device 140 provided in an embodiment of this application. Detailed Implementation

[0074] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0075] The system architecture used in the embodiments of this application is described below. It should be noted that the system architecture and business scenarios described in this application are for the purpose of more clearly illustrating the technical solutions of this application, and do not constitute a limitation on the technical solutions provided in this application. As those skilled in the art will know, with the evolution of system architecture and the emergence of new business scenarios, the technical solutions provided in this application are also applicable to similar technical problems.

[0076] Please refer to Figure 1, which is a schematic diagram of the architecture of a communication system provided in an embodiment of this application. As shown in Figure 1(a), the communication system includes a first communication device 101 and a second communication device 102. Optionally, the communication system further includes a third communication device 103.

[0077] Optionally, the first communication device 101, the second communication device 102, and the third communication device 103 can be of the same type or different types. For example, as shown in Figure 1(b), the first communication device 101 is a terminal device, the second communication device 102 is a network device, and the third communication device 103 is a core network device. As shown in Figure 1(c), the first communication device 101 is a terminal device, the second communication device 102 is a terminal device, and the third communication device 103 is a network device. The architecture of the communication system will now be described in detail, taking the example of the first communication device 101 as a terminal device, the second communication device 102 as a network device, and the third communication device 103 as a core network device.

[0078] It is understood that when the communication system includes only the first communication device 101 and the second communication device 102, the communication system only shows one terminal device and one network device. In actual use, an architecture of at least one terminal device and / or at least one network device can be adopted as needed (e.g., the architecture shown in (c) of Figure 1). For example, a single terminal device (e.g., represented as terminal device 1) can transmit PUSCH to a single network device (e.g., represented as network device 1), a single terminal device (e.g., represented as terminal device 2) can transmit PUSCH to network device 1, network device 1 can send configuration information A and scheduling information A to terminal device 1, and network device 2 can also send configuration information B and scheduling information B to terminal device 2.

[0079] It is understood that when the communication system includes a first communication device 101, a second communication device 102, and a third communication device 103, such as the architecture shown in Figure 1(b), the communication system illustrates one network device and one terminal device. In actual use, an architecture with at least one terminal device and / or at least one network device can be adopted as needed. For example, the communication system shown in Figure 2 includes one network device and multiple terminal devices, or includes multiple network devices and one terminal device. In this system, a single terminal device can transmit PUSCH data to a single network device, and a single network device can send configuration information and scheduling information to a single terminal device.

[0080] In this system, terminal devices connect to network devices wirelessly, while network devices connect to core network devices wirelessly or via wired connections. Core network devices and network devices can be independent physical devices, or they can integrate the functions of core network devices and the logical functions of network devices onto a single physical device. Alternatively, a single physical device can integrate some core network device functions and some network device functions. Terminal devices can be fixed in location or mobile.

[0081] Optionally, network devices and terminal devices can be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; they can also be deployed on water; and they can also be deployed in the air on aircraft, balloons, and satellites. The embodiments of this application do not limit the application scenarios of the network devices and terminal devices.

[0082] In this embodiment, the terminal devices involved may include various handheld devices, vehicle-mounted devices, wearable devices, computing devices, or other processing devices connected to a wireless modem with wireless communication capabilities. The terminal device 220 shown in Figure 2 may also be referred to as user equipment (UE), mobile station (MS), mobile terminal (MT), etc., or a device used to provide voice or data connectivity to users, or an Internet of Things (IoT) device. For example, terminal devices include handheld devices and vehicle-mounted devices with wireless connectivity. Currently, terminal devices can include: mobile phones, tablets, laptops, PDAs, mobile internet devices (MIDs), wearable devices (such as smartwatches, smart bracelets, pedometers, smart glasses, etc.), in-vehicle devices (such as cars, bicycles, electric vehicles, airplanes, ships, trains, high-speed trains, etc.), satellite terminals, virtual reality (VR) devices, augmented reality (AR) devices, point-of-sale (POS) machines, customer-premises equipment (CPE), light user equipment (UE), reduced capability user equipment (REDCAP UE), wireless terminals in industrial control, smart home devices (such as refrigerators, televisions, air conditioners, electricity meters, etc.), intelligent robots, robotic arms, workshop equipment, wireless terminals in autonomous driving, wireless terminals in telemedicine, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, or wireless terminals in smart homes, and flying equipment (such as intelligent robots, hot air balloons, drones, airplanes), etc. Terminal devices can also be vehicle devices, such as vehicle devices, vehicle modules, vehicle chips, on-board units (OBUs) or telematics boxes (T-BOXs). Terminal devices can also be other devices with terminal functions. For example, a terminal device can also be a device that performs terminal functions in D2D communication.

[0083] It should be noted that the embodiments of this application can be applied to downlink signal transmission, uplink signal transmission, and device-to-device (D2D) signal transmission. For downlink signal transmission, the transmitting device is a network device, and the corresponding receiving device is a terminal device. For uplink signal transmission, the transmitting device is a terminal device, and the corresponding receiving device is a network device. For D2D signal transmission, the transmitting device is a terminal device, and the corresponding receiving device is also a terminal device. The embodiments of this application do not limit the direction of signal transmission.

[0084] Communication between network devices and terminal devices, as well as between terminal devices, can be achieved through licensed spectrum, unlicensed spectrum, or a combination of both. Communication between network devices and terminal devices, as well as between terminal devices, can also be achieved through spectrum below 6th generation (6G), spectrum above 6G, or a combination of both. The embodiments of this application do not limit the spectrum resources used between network devices and terminal devices.

[0085] Typically, network device 210 can be a node in a radio access network (RAN), such as a wireless relay device and / or a wireless backhaul device (not shown in Figure 2). Network device 210 may also be referred to as an access network device or a RAN node (or device), forming part of a communication system to help terminal devices achieve wireless access. Network device 210 can also be a 3rd generation partnership project (3GPP) related cellular system, such as a 4th generation (4G) mobile communication system, a 5th generation (5G) mobile communication system, an NTN (non-terrestrial network) system, or a future-oriented evolution system (such as a 6G mobile communication system). Network device 210 can also be an open RAN (O-RAN or ORAN), a cloud radio access network (CRAN), or a wireless fidelity (WIFI) system, or a communication system integrating two or more of the above systems.

[0086] In the communication system 2000, multiple network devices 210 can be nodes of the same type or different types. In some scenarios, the roles of network devices 210 and terminal devices 220 are relative. For example, in Figure 2, network element 220i can be a helicopter or drone, which can be configured as a mobile base station. For terminal devices 220j accessing the RAN 200 through network element 220i, network element 220i is a base station; however, for base station 210a, network element 220i is a terminal device. Network devices 210 and terminal devices 220 are sometimes referred to as communication devices. For example, in Figure 2, network elements 210a and 210b can be understood as communication devices with base station functions, and network elements 220a-220j can be understood as communication devices with terminal device functions. Terminal devices 220 are connected to network devices 210 wirelessly. Network devices 210 are connected to the core network wirelessly or via wired connection. The core network equipment and network equipment 210 in the core network can be different physical devices, or they can be the same physical device that integrates core network logical functions and wireless access network logical functions.

[0087] In one possible scenario, network equipment can be a base station, an evolved NodeB (eNodeB), a transmitting and receiving point (TRP), a transmitting point (TP), a next-generation NodeB (gNB), a base station in a future mobile communication system, a satellite, or an access point (AP) in a Wi-Fi system, an integrated access and backhaul (IAB) node, or a network device in a mobile switching center non-terrestrial network (NTN) communication system, i.e., it can be deployed on a high-altitude platform or satellite, etc. Network equipment can be a macro base station (as shown in Figure 2, 210a), a micro base station or indoor station (as shown in Figure 2, 210b), a relay node or donor node, or a wireless controller in a cloud radio access network (CRAN) scenario. Network equipment can also function as a base station in device-to-device (D2D) communication, vehicle-to-everything (V2X) communication, drone communication, and machine-to-machine (M2M) communication. Alternatively, network equipment can also be servers, wearable devices, vehicles, or in-vehicle equipment. For example, the access network equipment in vehicle-to-everything (V2X) technology can be a roadside unit (RSU).

[0088] In another possible scenario, multiple network devices collaborate to assist terminal devices in achieving wireless access, with each network device performing a portion of the base station's functions. For example, these network devices can be central units (CUs), distributed units (DUs), CU-control plane (CPs), CU-user plane (UPs), or radio units (RUs). CUs and DUs can be configured separately or included in the same network element, such as the baseband unit (BBU). The CU and DU nodes separate the gNB's protocol layers; some protocol layer functions are centrally controlled by the CU, while the remaining partial or complete protocol layer functions are distributed in the DU, which is centrally controlled by the CU. As one implementation, the CU deploys the Radio Resource Control (RRC) layer, PDCP layer, and Service Data Adaptation Protocol (SDAP) layer in the protocol stack; the DU deploys the Radio Link Control (RLC) layer, Media Access Control (MAC) layer, and Physical Layer (PHY) in the protocol stack. Thus, the CU has the processing capabilities of RRC, PDCP, and SDAP. The DU has the processing capabilities of RLC, MAC, and PHY. It is understood that the above functional division is merely an example and does not constitute a limitation on the CU and DU. The RU can be included in radio equipment or radio units, such as in a remote radio unit (RRU), active antenna unit (AAU), or remote radio head (RRH). It is understood that the network device can be a CU node, a DU node, or a device including both CU and DU nodes. Furthermore, the CU can be classified as a network device in the access network RAN ​​or as a network device in the core network CN; there is no restriction on this.

[0089] In this application, the core network equipment refers to equipment in the core network (CN) that provides service support for terminal equipment. Examples of core network equipment include: access and mobility management function (AMF) entities, session management function (SMF) entities, user plane function (UPF) entities, etc., which are not listed here. The AMF entity is responsible for access management and mobility management of the terminal equipment; the SMF entity is responsible for session management, such as user session establishment; and the UPF entity can be a user plane functional entity, primarily responsible for connecting to external networks. It should be noted that in this application, entities can also be referred to as network elements or functional entities. For example, an AMF entity can also be called an AMF network element or an AMF functional entity, and an SMF entity can also be called an SMF network element or an SMF functional entity, etc.

[0090] Optionally, the method provided in this application embodiment can also be applied to an O-RAN system. Please refer to Figure 3, which is a schematic diagram of an O-RAN system provided in this application embodiment. The O-RAN system may also include other components besides those shown in Figure 3, and this application does not limit this. Optionally, the network device shown in Figure 3 can be an access network device, such as an eNB, gNB, or next-generation access network device. The access network device communicates with the core network (CN) via a backhaul link and with the terminal device via an air interface.

[0091] The BBU in the access network equipment communicates with the core network via a backhaul link, and the RU in the access network equipment communicates with at least one terminal device via an air interface. The BBU communicates with at least one RU via a fronthaul link. The BBU and RU may or may not be co-located. The BBU includes at least one control unit (CU) and at least one distributed unit (DU), which can communicate via at least one midhaul link.

[0092] Further optionally, please refer to Figure 4, which is a diagram illustrating the network element functional division and protocol layer structure of an open radio access network (O-RAN) system provided in an embodiment of this application. As shown in Figure 4, in some examples, the CU is a logical node carrying the RRC layer, Service Data Adaptation Protocol (SDAP) layer, Packet Data Convergence Protocol (PDCP) layer, and other control functions of the access network equipment. The CU is connected to network nodes such as the core network through some interfaces, which may be interfaces such as E2 interfaces. Optionally, the CU may have some functions of the core network, such as the PDCP layer and higher layers. The CU is connected to the DU (e.g., RLC layer and lower layers) through some interfaces, which may be interfaces such as F1 interfaces. In some examples, these interfaces (e.g., the F1 interface) can provide control plane (C-Plane) and user plane (U-Plane) functions (e.g., interface management, system information management, UE context management, RRC message transmission, etc.). F1AP is the application protocol of the F1 interface, and in some examples, the signaling procedures of F1 are defined. The F1 interface supports the control plane F1-C and the user plane F1-U.

[0093] In some examples, the CU can be split into CU-CP (control unit-control plane) and CU-UP (control unit-user plane). CU-CP is a logical node carrying the RRC layer and PDCP-C (control plane part of PDCP) layer, used to implement the CU's control plane functions. CU-CP can interact with network elements in the core network used to implement control plane functions. These network elements in the core network can be access and mobility function (AMF) network elements, such as the access and mobility management function (AMF) in a 5G mobile communication system. AMF network elements are responsible for mobility management in the mobile network, such as terminal device location updates, terminal device registration with the network, and terminal device handover. CU-UP is a logical node carrying the SDAP layer and the PDCP-U (user plane part of PDCP) layer for user plane data, used to implement the CU's user plane functions. CU-UP can interact with network elements in the core network used to implement user plane functions. These network elements in the core network, such as the UPF (user plane function) in a 5G system, are responsible for data forwarding and receiving in terminal devices. It should be understood that the above configurations of CU and DU are merely examples, and the functions of CU and DU can be configured as needed. This application does not impose excessive limitations on this. For example, CU or DU can be configured to have more protocol layer functions, or CU or DU can be configured to have some protocol layer processing functions. Another example is to place some functions of the RLC layer and the protocol layer functions above the RLC layer in the CU, and place the remaining functions of the RLC layer and the protocol layer functions below the RLC layer in the DU. Yet another example is that the functions of CU or DU can be divided according to service type or other system requirements, such as by latency, placing functions that need to meet low latency requirements in the DU, and functions that do not need to meet this latency requirement in the CU.

[0094] In some examples, a DU is a logical node that carries the radio link control (RLC) layer, medium access control (MAC) layer, higher physical layer (PHY) layer, and other functions. In some examples, a DU can control at least one RU. The DU connects to the RU through interfaces, which can be fronthaul interfaces.

[0095] In some examples, the CU may not have a PDCP layer, i.e., it only includes the RRC layer. CU-CP does not have PDCP-C. CU-UP may not have PDCP-U, or may not have CU-UP at all. In some examples, the DU may not have an RLC layer, only a MAC and a higher PHY layer. Furthermore, in some examples, it may not have a CU and may only include the DU.

[0096] In some examples, the higher PHY layer includes parts of the PHY layer that handle processing, such as forward error correction (FEC) encoding and decoding, scrambling, modulation, and demodulation.

[0097] In some examples, the RU is a logical node that carries both lower physical layer (PHY) and radio frequency chain (RF chain) processing. In some examples, the RU can be a 3GPPTRP, a remote radio head (RRH), or other similar functionalities. In some examples, the Low-PHY includes PHY processing functions such as Fast Fourier Transform (FFT), Inverse Fast Fourier Transform (IFFT), digital beamforming, and filtering. The RU communicates with one or more terminal devices via a wireless link.

[0098] Optionally, the DU and RU may or may not be co-located. The DU and RU exchange control plane information via a fronthaul link through a lower-layer split-control, user plane information (LLS-CUS) and synchronization interface. The LLS-CUS may include LLS-C and LLS-U interfaces that respectively provide the control plane (C-Plane) and user plane (U-Plane). In some examples, the control plane (C-Plane) refers to real-time control between the DU and RU. The DU and RU exchange management information via an LLS-M interface on the fronthaul link; the management plane (M-Plane) refers to non-real-time management operations between the DU and RU.

[0099] Optionally, the DU and RU can cooperate to implement the functions of the PHY layer. A DU can be connected to one or more RUs. The functions of the DU and RU can be configured in various ways depending on the design. For example, the DU can be configured to implement baseband functions, and the RU can be configured to implement mid-RF functions. Alternatively, the DU can be configured to implement higher-level functions in the PHY layer, and the RU can be configured to implement lower-level functions in the PHY layer, or to implement both lower-level and RF functions. Higher-level functions in the physical layer may include a portion of the physical layer's functions that are closer to the MAC layer, while lower-level functions in the physical layer may include another portion of the physical layer's functions that are closer to the mid-RF side.

[0100] In different systems, CU (or CU-CP and CU-UP), DU, or RU may have different names, but those skilled in the art will understand their meaning. For example, in an ORAN system, CU can also be called O-CU (Open CU), DU can also be called O-DU, CU-CP can also be called O-CU-CP, CU-UP can also be called O-CU-UP, and RU can also be called O-RU. For ease of description, this application uses CU, CU-CP, CU-UP, DU, and RU as examples. The network device deployment methods listed here are only examples; as standard technologies evolve, network devices may have other deployment forms.

[0101] The following is a brief introduction to the terminology related to this application.

[0102] 1. Uplink multiplexing in new radio (NR)

[0103] In the NR standard, uplink channels include, but are not limited to, the physical uplink control channel (PUCCH) and the physical uplink shared channel (PUSCH).

[0104] The PUCCH can carry uplink control information (UCI), including scheduling requests (SR), hybrid automatic repeat request acknowledgements (HARQ-ACK), and channel state information (CSI). The PUSCH is used to carry uplink data and / or aperiodic CSI. For multiple uplink carriers within the same PUCCH group, if a PUCCH and a PUSCH overlap at the same time, regardless of whether they are on the same uplink carrier, the PUCCH and PUSCH cannot be transmitted simultaneously. Depending on the UCI content carried on the PUCCH, the UCI can be placed on the PUSCH and transmitted with the data (called UCI piggyback, or UCI multiplexing onto the PUSCH), or the UCI can be discarded, and only the PUSCH is transmitted.

[0105] 2. Duplex in NR

[0106] Currently, NR includes frequency division duplex (FDD) and time division duplex (TDD).

[0107] Please refer to Figure 5, which is a schematic diagram of a duplex provided in an embodiment of this application. As shown in Figure 5(a), which is a schematic diagram of FDD, downlink transmission can be performed on the downlink portion bandwidth (DL BWP) and uplink transmission can be performed on the uplink portion bandwidth (UL BWP) of slot 0. The DL BWP and UL BWP are located on different carriers and are separated in the frequency domain.

[0108] As shown in Figure 5(b), which is a schematic diagram of TDD, the DL BWP and UL BWP have the same center frequency. The bandwidths of the DL BWP and UL BWP can be the same or different. At any given time, the terminal device can only perform uplink or downlink transmission. For example, only downlink transmission can be performed in slot 0, only uplink transmission can be performed in slot 4, and slot 3 is a flexible time slot, which can be used for either uplink or downlink transmission, but not both simultaneously. The smallest granularity of uplink / downlink transmission handover is a symbol. For example, slot 3 is a flexible time slot, consisting of 14 or 12 orthogonal frequency division multiplexing (OFDM) symbols. The first M symbols are downlink symbols, the last N symbols are uplink symbols, and the middle 14-MN (or 12-MN) symbols are flexible symbols, where 0 <= M <= 14, 0 <= N <= 14, and M+N <= 14. Downlink symbols are used for downlink transmission, uplink symbols are used for uplink transmission, and flexible symbols can be used for both uplink and downlink. The specific transmission direction is notified to the terminal device by the network device through radio resource control (RRC) signaling or downlink control information (DCI) scheduling.

[0109] Compared to FDD, TDD occupies less frequency domain resources. However, TDD cannot perform uplink and downlink transmissions simultaneously. For example, only downlink transmission can be performed in slot 0, and uplink transmission cannot be performed, which will lead to an increase in uplink transmission latency.

[0110] To address the latency issue of TDD, a flexible duplex technology, also known as complementary TDD (C-TDD) or full duplex, such as subband full duplex (SBFD), has been developed. The core idea of ​​flexible duplex is that uplink and downlink transmission resources can be configured simultaneously on a specific symbol or time slot within a TDD system. For example, as shown in Figure 5(c), within a time slot such as slot 0, a frequency domain resource exists within the DL BWP that can be used for uplink transmission. This allows uplink transmission to occur on slot 0, reducing uplink latency. This frequency domain resource is typically called the uplink subband. Downlink transmission can also occur on slot 0. Network devices can perform both uplink and downlink transmissions simultaneously on slot 0 (limited to either the uplink or downlink subband). Terminal devices can perform uplink and downlink transmissions simultaneously in slot 0 (i.e., full-duplex terminal devices), or they can perform only uplink or downlink transmissions (half-duplex terminal devices). Compared to TDD, SBFD provides more uplink resources, which can increase uplink coverage.

[0111] In order to perform resource transmission, network devices will send TDD configuration and SBFD configuration to terminal devices, including:

[0112] TDD configuration includes, but is not limited to: time slot indices for downlink time slots, uplink time slots, and flexible time slots; and symbol indices for uplink symbols, downlink symbols, and flexible symbols within flexible time slots. Downlink symbols in downlink time slots and flexible time slots are used for downlink data transmission; uplink symbols in uplink time slots and flexible time slots are used for uplink data transmission; and flexible symbols in flexible time slots can be used for both uplink and downlink data transmission.

[0113] SBFD configuration includes, but is not limited to, the following parameters: SBFD slot / symbol position, and SBFD sub-band position within the SBFD slot.

[0114] SBFD slot / symbol positions are some or all of the slots / symbols in the DL slot / symbol or flexible slot / symbol configured in the TDD configuration, that is, converting some or all of the downlink slots / symbols or flexible slots / symbols into SBFD symbols. SBFD subbands can be the frequency domain positions of UL subbands and / or DL ​​subbands.

[0115] For terminal devices in RRC-connected state, the base station can configure the time and frequency domain positions of the SBFD subband within a TDD carrier using RRC parameters. Please refer to Figure 6, which is a schematic diagram of a time-domain configuration method provided in an embodiment of this application. As shown in Figure 6, the base station configures the SBFD subband time-domain position semi-statically using RRC parameters (e.g., TDD-UL-DL-Pattern). The base station configures DL symbols, UL symbols, and flexible symbols using the TDD-UL-DL-ConfigCommon parameter. SBFD symbols can be configured on DL symbols and / or flexible symbols. The configured SBFD symbols can start from any symbol within a slot or end at any symbol within a slot. The SBFD subband time-domain period can be the same as the period configured in dl-UL-TransmissionPeriodicity in TDD-UL-DL-Pattern, or an integer multiple of the period configured in dl-UL-TransmissionPeriodicity in TDD-UL-DL-Pattern. A time slot can contain SBFD symbols and non-SBFD symbols.

[0116] Please refer to Figure 7, which is a schematic diagram of a frequency domain configuration method provided in an embodiment of this application. As shown in Figure 7, the base station configures the frequency domain positions of the UL sub-band and DL sub-band within a carrier in a semi-static manner at the RRC parameter resource block level (RB-level). The frequency domain positions of the sub-bands are the same on different SBFD symbols within a TDD carrier. Only one UL sub-band can be configured within one TDD carrier, and the UL sub-band can be located in the middle of the carrier or on one side of the carrier.

[0117] As mentioned above, uplink transmission is not possible on downlink symbols in a TDD system. Compared to TDD, SBFD systems add uplink available resources, namely the uplink subband resources configured on downlink symbols. These resources can only be used for downlink transmission in a TDD system, but can be used for uplink transmission in an SBFD system. Therefore, for users who support SBFD, the available resources on SBFD symbols and non-SBFD symbols are different.

[0118] Currently, there are two conclusions regarding repetitive, periodic, or semi-persistent transmissions in SBFD systems, as detailed below:

[0119] Conclusion 1: For transmissions spanning two types of symbols across different time slots (transmissions within the same time slot are either all on SBFD symbols or all on non-SBFD symbols), such as repetitive transmissions, periodic transmissions, or semi-persistent transmissions, the following two configurations are defined, as follows:

[0120] Configuration 1: This type of transmission occurs only on SBFD symbols or only on non-SBFD symbols.

[0121] Configuration 2: This type of transmission can be performed on both SBFD and non-SBFD symbols.

[0122] In addition, for uplink transmission, PUCCH and PUSCH will be transmitted across two types of symbols in different time slots.

[0123] Conclusion 2: For the transmission of Configuration 1, a valid symbol type is defined. For the transmission using Configuration 1, the valid symbol type determines whether the repetitive transmission / periodic transmission / semi-persistent transmission is performed on SBFD symbols or on non-SBFD symbols.

[0124] Furthermore, for carrier aggregation (CA) scenarios (also known as multi-carrier scenarios), it is currently supported to configure SBFD operation on one of the TDD carriers. Taking a scenario with two carriers as an example, there will be one TDD carrier with SBFD configured and another TDD / FDD carrier without SBFD configured. In a multi-carrier scenario, if SBFD operation is configured on one of the TDD carriers, and the configuration is set to configuration 1, how can UCI to PUSCH multiplexing be performed across multiple carriers for repeated transmissions / periodic transmissions / semi-persistent transmissions of valid symbol types that are SBFD symbols?

[0125] In view of this, embodiments of this application provide a communication method and related apparatus. A first communication apparatus can determine whether UCI needs to be multiplexed onto the PUSCH for transmission based on configuration information and scheduling information of two types of carriers: those configured with SBFD and those without SBFD, thus supplementing the multiplexing rules between different types of carriers not specified in the prior art. Embodiments of this application provide multiplexing rules for UCI and PUSCH between different types of carriers, and UCI multiplexing is performed according to these rules, improving the SBFD system design.

[0126] In the communication method described below (as shown in Figure 8), the specific description of the first communication device and the second communication device can be found in Figure 1, and will not be detailed here. For ease of description, in the embodiments of this application, specific examples may be given using the first communication device as a terminal device and the second communication device as a network device, but this should not be construed as a limitation on the embodiments of this application.

[0127] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0128] Please refer to Figure 8, which is a flowchart illustrating a communication method provided in an embodiment of this application. Optionally, this method can be applied to a communication system, such as the communication system shown in Figure 1.

[0129] The method shown in Figure 8 may include steps S801-S803. It should be understood that, for ease of description, this application describes the steps in the order of S801-S803, but does not limit the execution to this order. This application's embodiments do not limit the order of execution, the execution time, or the number of executions of one or more of the above steps. Steps S801-S803 are as follows:

[0130] Step S801: The second communication device sends configuration information and scheduling information to the first communication device.

[0131] Accordingly, the first communication device receives the configuration information and scheduling information.

[0132] The configuration information includes identification information of multiple carriers, subband full-duplex SBFD configuration information of at least one first carrier among the multiple carriers, and configuration information of at least one second carrier. The at least one second carrier is a carrier among the multiple carriers that is not configured with SBFD except for at least one first carrier. The scheduling information includes uplink physical shared channel (PUSCH) scheduling information and uplink physical control channel (PUCCH) scheduling information. The PUCCH scheduling information is used to schedule the PUCCH that carries uplink control information (UCI).

[0133] For example, the identification information of multiple carriers includes the identification information of carrier 1 (e.g., represented as CC1), the identification information of carrier 2 (e.g., represented as CC2), the identification information of carrier 3 (e.g., represented as CC3), and the identification information of carrier 4 (e.g., represented as CC4).

[0134] Optionally, at least one first carrier among the multiple carriers may include only one first carrier (e.g., the first carrier is CC1), or it may include multiple first carriers (e.g., the multiple first carriers include CC1 and CC2).

[0135] Accordingly, when only one first carrier is included among multiple carriers, at least one second carrier is one of the multiple carriers other than the first carrier (e.g., a second carrier is CC2), or it can be at least one of the multiple carriers other than the first carrier (e.g., multiple second carriers are CC3 and CC4).

[0136] It should be noted that, for the sake of describing the scheme of the embodiments of this application, the embodiments of this application use the example that at least one first carrier among multiple carriers includes only one first carrier (e.g., the first carrier is CC1), and the carriers other than the first carrier among multiple carriers include only one second carrier (e.g., the second carrier is CC2) to describe the following content. However, it should not be construed as limiting the number of first carriers and second carriers, and this will not be elaborated on further.

[0137] It should be understood that the type of at least one second carrier that is not configured with SBFD among the multiple carriers in this application, other than at least one first carrier, can be an FDD carrier, a TDD carrier, or a carrier with other names. This application does not limit the type of the second carrier.

[0138] Step S802: The first communication device determines the multiplexing result based on the configuration information and scheduling information.

[0139] The multiplexing result is used to characterize whether the received PUSCH has multiplexed the UCI.

[0140] The following is an example of a UCI and PUSCH multiplexing scenario between two different carriers:

[0141] Scenario 1: The scheduling information of PUCCH is used to indicate that there is a PUCCH on at least one first carrier, the scheduling information of PUSCH is used to indicate that there is a PUSCH on at least one second carrier, the PUCCH and PUSCH have partial or complete overlap in time, the configuration information of at least one first carrier is used to indicate that an SBFD symbol is configured on at least one first carrier, and the configuration information of at least one second carrier is used to indicate that no SBFD symbol is configured on at least one second carrier.

[0142] For example, CC1 is configured with SBFD and has PUCCH; CC2 is not configured with SBFD and has PUSCH; PUCCH and PUSCH overlap in time.

[0143] In the above scenario, the following exemplarily describes two different implementation methods for determining the multiplexing result based on configuration information and scheduling information for two first communication devices without distinguishing between valid symbol types, as follows:

[0144] In the first implementation method, the first communication device multiplexes the UCI carried on the PUCCH onto the PUSCH for transmission based on the configuration information and scheduling information.

[0145] It should be noted that in the embodiments of this application, "multiplexing the UCI carried on the PUCCH onto the PUSCH for transmission" means that the UCI originally carried on the PUCCH is no longer sent through the PUCCH, but it does not mean that it can be successfully sent on the PUSCH. Certain conditions must be met for successful transmission, which will not be elaborated on further.

[0146] In one possible design, the first communication device determines the valid symbol type of the PUCCH on at least one first carrier, and multiplexes the UCI carried on the PUCCH onto the PUSCH for transmission according to the valid symbol type of the PUCCH (that is, the first communication device may first determine the valid symbol type on CC1, and then perform UCI multiplexing between CC1 and CC2).

[0147] For example, please refer to Figure 9A. Figure 9A is a schematic diagram of a multiplexing method provided by an embodiment of this application, in which UCI carried on PUCCH is multiplexed onto PUSCH for transmission. As shown in Figure 9A, PUCCH1 and PUCCH2 are located in CC1 configured with SBFD operation. According to preset rules, the valid symbol type is first determined. As shown in Figure 9A, the valid symbol types of PUCCH1 and PUCCH2 are SBFD symbols and non-SBFD symbols, respectively. The first time slot from left to right is the SBFD time slot, that is, all symbols in this time slot are SBFD symbols. Therefore, PUCCH1 is valid, and PUCCH2 is invalid (can be discarded). The second time slot is the non-SBFD time slot, that is, all symbols in this time slot are non-SBFD symbols. Therefore, PUCCH2 is valid, and PUCCH1 is invalid (can be discarded).

[0148] Then, UCI multiplexing is performed between CC1 and CC2, at which point the valid symbol type of PUCCH is no longer distinguished. In the first time slot, UCI1, originally carried on PUCCH1, is multiplexed onto the PUSCH of CC2. In the second time slot, UCI2, originally carried on PUCCH2, is multiplexed onto the PUSCH of CC2.

[0149] In summary, the multiplexing result of this implementation is that UCI1, originally carried on PUCCH1 in the first time slot, is multiplexed onto PUSCH of CC2, and UCI2, originally carried on PUCCH2 in the second time slot, is multiplexed onto PUSCH of CC2.

[0150] Alternatively, four possible solutions to Figure 9A are illustrated below as examples:

[0151] Scenario 1: If a PUCCH located on a CC1 configured with SBFD has a valid symbol type that is not SBFD and is located on a non-SBFD symbol of CC1, then when the PUCCH overlaps in time with a PUSCH on a CC2 not configured with SBFD, the UCI on the PUCCH can be multiplexed onto the PUSCH of CC2.

[0152] Scenario 2: If a PUCCH located on CC1 with SBFD configured is not an SBFD symbol and is located on an SBFD symbol of CC1, then the PUCCH is invalid. When the PUCCH overlaps in time with a PUSCH on CC2 without SBFD configured, the UCI of the PUCCH cannot be multiplexed onto the PUSCH of CC2.

[0153] Scenario 3: If a PUCCH located on CC1 with SBFD configured is an SBFD symbol and is located on a non-SBFD symbol of CC1, then the PUCCH is invalid. When the PUCCH overlaps in time with a PUSCH on CC2 without SBFD configured, the UCI of the PUCCH cannot be multiplexed onto the PUSCH of CC2.

[0154] Scenario 4: A PUCCH located on CC1 with SBFD configured is valid if its valid symbol type is a non-SBFD symbol and it is located on a non-SBFD symbol of CC1. When this PUCCH overlaps in time with a PUSCH on CC2 without SBFD configured, the UCI on this PUCCH can be multiplexed onto the PUSCH of CC2.

[0155] It should be noted that, for ease of description, various possible alternatives to Figure 9A after unfolding are shown through Situations 1 to 4. However, Situations 1 to 4 are merely examples provided by this application and should not be construed as limiting the scheme of Figure 9A in this application. Further details will not be provided thereafter.

[0156] In one possible design, the first communication device first multiplexes the UCI carried on the PUCCH onto the PUSCH for transmission, and then determines the valid symbol type of the PUCCH on at least one first carrier (that is, first perform UCI multiplexing between CC1 and CC2, and then determine the valid symbol type on CC1).

[0157] For example, please refer to Figure 9B. Figure 9B is a schematic diagram of another multiplexing method provided by the embodiments of this application, which multiplexes the UCI carried on PUCCH onto PUSCH for transmission. As shown in Figure 9B, PUCCH1 and PUCCH2 are located in CC1 configured with SBFD operation. First, UCI multiplexing between CC1 and CC2 is performed. Since both PUCCH1 and PUCCH2 overlap with PUSCH, the UCI1 originally carried on PUCCH1 and the UCI2 carried on PUCCH2 are multiplexed onto the PUSCH of CC2 for transmission (without distinguishing the valid symbol type of PUCCH1). At this time, PUCCH1 and PUCCH2 on CC1 are no longer present, and there is no longer a need to determine the valid symbol type.

[0158] In summary, the multiplexing result of this implementation is that in both the first and second time slots, UCI1 originally carried on PUCCH1 and UCI2 carried on PUCCH2 are multiplexed onto the PUSCH of CC2 for transmission.

[0159] Alternatively, three possible solutions to Figure 9B are illustrated below as examples:

[0160] Scenario 1: If a PUCCH located on CC1 with SBFD configured has a non-SBFD symbol type, and it overlaps in time with a PUSCH on CC2 without SBFD configured, then the UCI on the PUCCH can be multiplexed onto the PUSCH on CC2, regardless of whether the PUCCH is located on an SBFD symbol or a non-SBFD symbol on CC1.

[0161] Scenario 2: If the valid symbol type of the PUCCH on CC1 is SBFD, and it overlaps with the PUSCH on CC2 (which is not SBFD configured) in time, the UCI on the PUCCH can be multiplexed onto the PUSCH on CC2, regardless of whether the PUCCH is on an SBFD symbol or a non-SBFD symbol on CC1.

[0162] Scenario 3: For a PUCCH located on CC1 with SBFD configured, regardless of whether the valid symbol type of the PUCCH is a non-SBFD symbol or an SBFD symbol, when the PUCCH overlaps in time with a PUSCH on CC2 without SBFD configured, regardless of whether the PUCCH is located on an SBFD symbol or a non-SBFD symbol on CC1, the UCI on the PUCCH can be multiplexed onto the PUSCH of CC2.

[0163] In the second implementation method, the first communication device does not multiplex the UCI onto the PUSCH based on the configuration information and scheduling information.

[0164] Alternatively, the first communication device may also discard the UCI carried on the PUCCH or discard the PUSCH according to the configuration information and scheduling information. Discarding the UCI carried on the PUCCH is equivalent to discarding the PUCCH carrying the UCI.

[0165] For example, please refer to Figure 9C. Figure 9C is a schematic diagram of another multiplexing method provided by an embodiment of this application, in which UCI carried on PUCCH is multiplexed onto PUSCH for transmission. As shown in Figure 9C, there is no PUSCH on CC2, so UCI1 of PUCCH1 and UCI2 of PUCCH2 will not be multiplexed onto the PUSCH of CC2, but will only be transmitted on CC1. Since CC1 is configured with SBFD operation, it is necessary to determine the valid symbol type. The valid symbol types of PUCCH1 and PUCCH2 are SBFD symbols and non-SBFD symbols, respectively. The first time slot is an SBFD time slot, that is, all symbols in this time slot are SBFD symbols, so PUCCH1 is valid and PUCCH2 is invalid (discarded). The second time slot is a non-SBFD time slot, that is, all symbols in this time slot are non-SBFD symbols, so PUCCH2 is valid and PUCCH1 is invalid (discarded).

[0166] In summary, the multiplexing result of this embodiment is that UCI1 of the first time slot PUCCH1 is transmitted on PUCCH1 of CC1, and UCI2 of the second time slot PUCCH2 is transmitted on PUCCH2 of CC1.

[0167] In other words, the core idea of ​​the above-described implementation methods one and two is to determine the valid symbol type only on CC1. When multiplexing UCI between CC1 and CC2, the valid symbol type of PUCCH on CC1 is not distinguished, and multiplexing is performed according to existing rules. Since the above two implementation methods do not need to distinguish the valid symbol type of PUCCH, but only need to determine whether UCI needs to be multiplexed onto PUSCH for transmission according to existing multiplexing rules, this scheme increases the probability of successful UCI transmission when UCI needs to be multiplexed onto PUSCH for transmission. Even when UCI does not need to be multiplexed onto PUSCH, it can still guarantee successful transmission of UCI or PUSCH.

[0168] In the above scenario, the following is an exemplary description of a scheme by which the first communication device determines the multiplexing result based on configuration information and scheduling information when distinguishing between valid symbol types, as follows:

[0169] When the valid symbol type of the PUCCH on at least one first carrier is a non-SBFD symbol, the first communication device multiplexes the UCI carried on the PUCCH onto the PUSCH for transmission.

[0170] In one possible design, the first communication device determines the valid symbol type of the PUCCH on at least one first carrier, and multiplexes the UCI carried on the PUCCH onto the PUSCH for transmission according to the valid symbol type of the PUCCH (that is, the first communication device may first determine the valid symbol type on CC1, and then perform UCI multiplexing between CC1 and CC2).

[0171] For example, please refer to Figure 10A. Figure 10A is a schematic diagram of another multiplexing method provided by an embodiment of this application, which multiplexes the UCI carried on PUCCH onto PUSCH for transmission. As shown in Figure 10A, PUCCH1 and PUCCH2 are located in CC1 configured with SBFD operation. First, the valid symbol type is determined. The valid symbol types of PUCCH1 and PUCCH2 are SBFD symbols and non-SBFD symbols, respectively. If the first time slot is an SBFD time slot, that is, all symbols in this time slot are SBFD symbols, then PUCCH1 is valid and PUCCH2 is invalid (can be discarded). If the second time slot is a non-SBFD time slot, that is, all symbols in this time slot are non-SBFD symbols, then PUCCH2 is valid and PUCCH1 is invalid (can be discarded).

[0172] Then, UCI multiplexing between CC1 and CC2 is performed. Since only PUCCHs with valid symbol types other than SBFD can be multiplexed onto the PUSCH of CC2, as shown in Figure 10A, in the first time slot, because the valid symbol type of PUCCH1 is SBFD, it cannot be multiplexed onto the PUSCH of CC2. That is, the UCI on both PUCCH1 and PUCCH2 in this time slot cannot be multiplexed. In the second time slot, because the valid symbol type of PUCCH2 is non-SBFD, the UCI2 originally carried on PUCCH2 can be multiplexed onto the PUSCH of CC2 for transmission.

[0173] In summary, the multiplexing result of this scheme is that UCI1, which was originally carried on PUCCH1, and UCI2, which was originally carried on PUCCH2, will not be multiplexed onto PUSCH of CC2 in the first time slot. In the second time slot, UCI2, which was originally carried on PUCCH2, will be multiplexed onto PUSCH of CC2.

[0174] Alternatively, four possible solutions to Figure 10A are illustrated below as examples:

[0175] Scenario 1: If a PUCCH located on a CC1 configured with SBFD has a valid symbol type that is not SBFD and is located on a non-SBFD symbol of CC1, then when the PUCCH overlaps in time with a PUSCH on a CC2 not configured with SBFD, the UCI on the PUCCH can be multiplexed onto the PUSCH of CC2.

[0176] Scenario 2: A PUCCH located on CC1 with SBFD configured is invalid if its valid symbol type is a non-SBFD symbol and it is located on an SBFD symbol of CC1. When this PUCCH overlaps in time with a PUSCH on CC2 without SBFD configured, the UCI of this PUCCH cannot be multiplexed onto the PUSCH of CC2.

[0177] Scenario 3: A PUCCH located on CC1 with SBFD configured is invalid if its valid symbol type is SBFD and it is located on a non-SBFD symbol on CC1. When this PUCCH overlaps in time with a PUSCH on CC2 without SBFD configured, the UCI of this PUCCH cannot be multiplexed onto the PUSCH of CC2.

[0178] Scenario 4: A PUCCH located on CC1 with SBFD configured is valid if its valid symbol type is SBFD and it is located on an SBFD symbol of CC1. Furthermore, when this PUCCH overlaps in time with a PUSCH on CC2 without SBFD configured, its UCI cannot be multiplexed onto the PUSCH of CC2; when this PUCCH does not overlap with any PUSCH on a CC without SBFD configured, it can be transmitted on CC1.

[0179] In one possible design, the first communication device first multiplexes the UCI carried on the PUCCH onto the PUSCH for transmission, and then determines the valid symbol type of the PUCCH on at least one first carrier (that is, first perform UCI multiplexing between CC1 and CC2, and then determine the valid symbol type on CC1).

[0180] For example, please refer to Figure 10B. Figure 10B is a schematic diagram of another multiplexing method provided by an embodiment of this application, which multiplexes the UCI carried on the PUCCH onto the PUSCH for transmission. As shown in Figure 10B, PUCCH1 and PUCCH2 are located in CC1, which is configured with SBFD operation. First, UCI multiplexing between CCs is performed. Although both PUCCH1 and PUCCH2 overlap with the PUSCH, since the valid symbol type of PUCCH1 is SBFD symbol, it cannot be multiplexed onto the PUSCH of CC2 and must be discarded. However, the valid symbol type of PUCCH2 is non-SBFD symbol and can be multiplexed onto the PUSCH of CC2. After the multiplexing operation is performed, PUCCH1 and PUCCH2 on CC1 are no longer present, and there is no longer a need to determine the valid symbol type.

[0181] In summary, the multiplexing result of this scheme is that in both the first and second time slots, the UCI2 originally carried on PUCCH2 is multiplexed onto the PUSCH of CC2.

[0182] For example, please refer to Figure 10C. Figure 10C is a schematic diagram of another multiplexing method provided by an embodiment of this application, which multiplexes the UCI carried on the PUCCH onto the PUSCH for transmission. As shown in Figure 10C, there is no PUSCH on CC2 in the first time slot, so PUCCH1 and PUCCH2 will not be multiplexed onto the PUSCH of CC2, but will only be transmitted on CC1. Since CC1 is configured with SBFD operation, it is necessary to determine the valid symbol type. The valid symbol types of PUCCH1 and PUCCH2 are SBFD symbols and non-SBFD symbols, respectively. Therefore, PUCCH1 is valid, and PUCCH2 is invalid (discarded). The valid symbol type of PUCCH2 in the second time slot is non-SBFD symbol, so it can be multiplexed onto the PUSCH of CC2. After the multiplexing operation is performed, PUCCH1 and PUCCH2 on CC1 are no longer present, and there is no longer a need to determine the valid symbol type.

[0183] In summary, the multiplexing result of this scheme is that UCI1 of PUCCH1 is transmitted on CC1 in the first time slot, and UCI2 originally carried on PUCCH2 is multiplexed onto PUSCH of CC2 for transmission in the second time slot.

[0184] Alternatively, four possible solutions for Figure 10C are illustrated below as examples:

[0185] Scenario 1: If the valid symbol type of the PUCCH on CC1, which is configured with SBFD, is a non-SBFD symbol, then when the PUCCH overlaps in time with the PUSCH on CC2, which is not configured with SBFD, the UCI on the PUCCH can be multiplexed onto the PUSCH on CC2, regardless of whether the PUCCH is located on an SBFD symbol or a non-SBFD symbol on CC1.

[0186] Scenario 2: For a PUCCH located on a CC1 configured with SBFD, if the valid symbol type of the PUCCH is a non-SBFD symbol, and the PUCCH does not overlap with a PUSCH on any CC without SBFD, then it is further determined whether the PUCCH is located on an SBFD symbol on CC1, where:

[0187] If the PUCCH is located on the SBFD symbol on CC1, then the PUCCH is invalid and cannot be sent.

[0188] If the PUCCH is located on a non-SBFD symbol on CC1, then the PUCCH is valid and can be sent.

[0189] Scenario 3: If the valid symbol type of the PUCCH located on CC1 with SBFD configured is SBFD symbol, when the PUCCH overlaps in time with the PUSCH on CC2 without SBFD configured, the UCI on the PUCCH cannot be multiplexed onto the PUSCH of CC2, regardless of whether the PUCCH is located on an SBFD symbol or a non-SBFD symbol on CC1.

[0190] Case 4: For a PUCCH located on a CC1 configured with SBFD, if the valid symbol type of the PUCCH is an SBFD symbol, and the PUCCH does not overlap with a PUSCH on any CC without SBFD, then it is further determined whether the PUCCH is located on an SBFD symbol on CC1, where:

[0191] If the PUCCH is located on a non-SBFD symbol on CC1, then the PUCCH is invalid and cannot be sent.

[0192] If the PUCCH is located on the SBFD symbol on CC1, then the PUCCH is valid and can be sent.

[0193] Scenario 2: The scheduling information of PUSCH is used to indicate that PUSCH exists on at least one first carrier, the scheduling information of PUCCH is used to indicate that PUCCH exists on at least one second carrier, PUCCH and PUSCH partially or completely overlap in time, the configuration information of at least one first carrier is used to indicate that SBFD symbols are configured on at least one first carrier, and the configuration information of at least one second carrier is used to indicate that SBFD symbols are not configured on at least one second carrier.

[0194] For example, CC1 is configured with SBFD and has PUSCH; CC2 is not configured with SBFD and has PUCCH; PUCCH and PUSCH overlap in time.

[0195] In the above scenario, the following exemplarily describes two different implementation methods for determining the multiplexing result based on configuration information and scheduling information for two first communication devices without distinguishing between valid symbol types, as follows:

[0196] In the first implementation method, the first communication device multiplexes the UCI carried on the PUCCH onto the PUSCH for transmission based on the configuration information and scheduling information.

[0197] In one possible design, the first communication device determines the valid symbol type of the PUSCH on at least one first carrier, and multiplexes the UCI carried on the PUCCH onto the PUSCH for transmission according to the valid symbol type of the PUSCH (that is, the first communication device may first determine the valid symbol type on CC1, and then perform UCI multiplexing between CC1 and CC2).

[0198] For example, please refer to Figure 11A. Figure 11A is a schematic diagram of a multiplexing method provided by an embodiment of this application, in which UCI carried on PUCCH is multiplexed onto PUSCH for transmission. As shown in Figure 11A, PUSCH1 and PUSCH2 are located in CC1 configured with SBFD operation. First, the valid symbol type is determined. The valid symbol types of PUSCH1 and PUSCH2 are SBFD symbols and non-SBFD symbols, respectively. If the first time slot is an SBFD time slot, that is, all symbols in this time slot are SBFD symbols, then PUSCH1 is valid and PUSCH2 is invalid (can be discarded). If the second time slot is a non-SBFD time slot, that is, all symbols in this time slot are non-SBFD symbols, then PUSCH2 is valid and PUSCH1 is invalid (can be discarded).

[0199] Then, UCI multiplexing is performed between CC1 and CC2, at which point the valid symbol type of PUSCH is no longer distinguished. In the first time slot, the UCI originally carried on PUCCH is multiplexed onto PUSCH1 of CC1 (without distinguishing the valid symbol type of PUSCH1). In the second time slot, the UCI originally carried on PUCCH is multiplexed onto PUSCH2 of CC1.

[0200] In summary, the multiplexing result of this implementation is that the UCI originally carried on PUCCH is multiplexed onto PUSCH1 of CC1 for transmission in the first time slot, and the UCI originally carried on PUCCH is multiplexed onto PUSCH2 of CC1 for transmission in the second time slot.

[0201] Alternatively, four possible solutions to Figure 11A are illustrated below:

[0202] Scenario 1: If a PUSCH located on a CC1 configured with SBFD has a valid symbol type that is not SBFD and is located on a non-SBFD symbol of CC1, then when the PUSCH overlaps in time with a PUCCH on a CC2 not configured with SBFD, the UCI on the PUCCH of CC2 can be multiplexed onto the PUSCH of CC1.

[0203] Scenario 2: A PUSCH located on CC1 with SBFD configured is invalid if its valid symbol type is a non-SBFD symbol and it is located on an SBFD symbol of CC1. When this PUSCH overlaps in time with a PUCCH on CC2 without SBFD configured, the UCI of this PUCCH cannot be multiplexed onto the PUSCH of CC1.

[0204] Scenario 3: A PUSCH located on CC1 with SBFD configured is invalid if its valid symbol type is SBFD and it is located on a non-SBFD symbol of CC1. When this PUSCH overlaps in time with a PUCCH on CC2 without SBFD configured, the UCI of this PUCCH cannot be multiplexed onto the PUCCH of CC1.

[0205] Case 4: If a PUSCH located on CC1 with SBFD configured has an SBFD symbol type and is located on an SBFD symbol of CC1, then when the PUSCH overlaps in time with a PUCCH on CC2 without SBFD configured, the UCI on the PUCCH of CC2 can be multiplexed onto the PUSCH of CC1.

[0206] In one possible design, the first communication device first multiplexes the UCI carried on the PUCCH onto the PUSCH for transmission, and then determines the valid symbol type of the PUSCH on at least one first carrier (that is, first perform UCI multiplexing between CC1 and CC2, and then determine the valid symbol type on CC1).

[0207] For example, please refer to Figure 11B. Figure 11B is a schematic diagram of another multiplexing method provided by the embodiments of this application, which multiplexes the UCI carried on the PUCCH onto the PUSCH for transmission. As shown in Figure 11B, PUSCH1 and PUSCH2 are located in CC1 configured with SBFD operation. First, UCI multiplexing between CC1 and CC2 is performed. Since PUSCH1 and PUSCH2 overlap with the PUCCH, according to existing rules, the UCI originally carried on the PUCCH will be multiplexed onto the PUSCH with the earliest time among the multiple overlapping PUSCHs for transmission. That is, the UCI carried on the PUCCH will be multiplexed onto PUSCH1 of CC1 for transmission (without distinguishing the valid symbol type of PUSCH1).

[0208] Then, valid symbol type determination is performed on CC1, which is configured with SBFD operation. If the first time slot is an SBFD time slot, meaning all symbols in this time slot are SBFD symbols, then PUSCH1, which uses UCI, is valid, and PUSCH2 is invalid (and can be discarded). If the second time slot is a non-SBFD time slot, meaning all symbols in this time slot are non-SBFD symbols, then PUSCH2 is valid, and PUSCH1, which uses UCI, is invalid (and can be discarded).

[0209] In summary, the multiplexing result of this embodiment is that the UCI originally carried on PUCCH is multiplexed onto PUSCH1 of CC1 for transmission in the first time slot, and only PUSCH2 of CC1 is transmitted in the second time slot, and the UCI of PUCCH is not multiplexed on PUSCH2.

[0210] Alternatively, five possible solutions to Figure 11B are illustrated below as examples:

[0211] In scenario one, if a PUSCH located on CC1 with SBFD configured has a non-SBFD symbol type and is located on an SBFD symbol of CC1, and this PUSCH overlaps in time with a PUCCH on CC2 without SBFD configured, the UCI on the PUCCH of CC2 can be multiplexed onto the PUSCH of CC1. However, since the valid symbol type of this PUSCH is a non-SBFD symbol and is located on an SBFD symbol of CC1, this PUSCH is invalid and cannot be sent.

[0212] Scenario 2: If a PUSCH located on CC1 with SBFD configured has an SBFD symbol type and is located on a non-SBFD symbol on CC1, when the PUSCH overlaps in time with a PUCCH on CC2 without SBFD configured, the UCI on the PUCCH of CC2 can be multiplexed onto the PUSCH of CC1. However, since the valid symbol type of the PUSCH is an SBFD symbol and is located on a non-SBFD symbol on CC1, the PUSCH is invalid and cannot be sent.

[0213] Scenario 3: If a PUSCH located on CC1 with SBFD configured has a valid symbol type that is not SBFD and is located on a non-SBFD symbol of CC1, when the PUSCH overlaps in time with a PUCCH on CC2 without SBFD configured, the UCI on the PUCCH of CC2 can be multiplexed onto the PUSCH of CC1. Since the valid symbol type of the PUSCH is not SBFD and is located on a non-SBFD symbol of CC1, the PUSCH is valid.

[0214] Scenario 4: If a PUSCH located on CC1 with SBFD configured has an SBFD symbol type and is located on an SBFD symbol of CC1, when the PUSCH overlaps in time with a PUCCH on CC2 without SBFD configured, the UCI on the PUCCH of CC2 can be multiplexed onto the PUSCH of CC1. Since the valid symbol type of the PUSCH is an SBFD symbol and is located on an SBFD symbol of CC1, the PUSCH is valid.

[0215] Alternatively, scenarios one through four above can also be replaced by scenario five, as follows:

[0216] Scenario 5: For a PUSCH located on CC1 with SBFD configured, regardless of whether the valid symbol type of the PUSCH is a non-SBFD symbol or an SBFD symbol, when the PUSCH overlaps in time with a PUCCH on CC2 without SBFD configured, the UCI on the PUCCH can be multiplexed onto the PUSCH on CC2. Then, based on the valid symbol type and the symbol type of the PUSCH, it is determined whether the PUSCH is valid. If valid, the PUSCH with multiplexed UCI can be sent; if invalid, the PUSCH with multiplexed UCI cannot be sent.

[0217] In the second scenario described above, the following example further illustrates different schemes for the two first communication devices to determine the multiplexing result based on configuration information and scheduling information when distinguishing between valid symbol types, as follows:

[0218] Option 1: When the effective symbol type of the PUSCH on at least one first carrier is a non-SBFD symbol, the first communication device multiplexes the UCI carried on the PUCCH onto the PUSCH for transmission.

[0219] In one possible design, the first communication device determines the valid symbol type of the PUSCH on at least one first carrier, and multiplexes the UCI carried on the PUCCH onto the PUSCH for transmission according to the valid symbol type of the PUSCH (that is, the first communication device may first determine the valid symbol type on CC1, and then perform UCI multiplexing between CC1 and CC2).

[0220] For example, please refer to Figure 12A. Figure 12A is a schematic diagram of another multiplexing method provided by an embodiment of this application, which multiplexes the UCI carried on the PUCCH onto the PUSCH for transmission. As shown in Figure 12A, PUSCH1 and PUSCH2 are located in CC1 configured with SBFD operation. First, the valid symbol type is determined. The valid symbol types of PUSCH1 and PUSCH2 are SBFD symbols and non-SBFD symbols, respectively. If the first time slot is an SBFD time slot, that is, all symbols in this time slot are SBFD symbols, then PUSCH1 is valid and PUSCH2 is invalid (can be discarded). If the second time slot is a non-SBFD time slot, that is, all symbols in this time slot are non-SBFD symbols, then PUSCH2 is valid and PUSCH1 is invalid (can be discarded).

[0221] Then, UCI multiplexing occurs between CC1 and CC2. CC2's UCI can only be multiplexed onto the PUSCH of CC1 where the valid symbol type is not SBFD. In the first time slot, because PUSCH1's valid symbol type is SBFD, CC2's UCI cannot be multiplexed. This means that the UCI of the PUCCH in this time slot cannot be multiplexed and cannot be transmitted on CC2, because PUSCH1 of CC1 needs to be transmitted at this time. In the second time slot, because PUSCH2's valid symbol type is not SBFD, the UCI originally carried on the PUCCH will be multiplexed onto PUSCH2 of CC1.

[0222] In summary, the multiplexing result of this scheme is that only PUSCH1 of CC1 is transmitted in the first time slot, and the UCI of PUCCH1 is not multiplexed on PUSCH1; in the second time slot, the UCI originally carried on PUCCH is multiplexed onto PUSCH2 of CC1 for transmission.

[0223] Alternatively, four possible solutions to Figure 12A are illustrated below:

[0224] Scenario 1: If a PUSCH located on CC1 with SBFD configured has a valid symbol type that is not SBFD and is located on a non-SBFD symbol of CC1, then when the PUSCH overlaps in time with a PUCCH on CC2 without SBFD configured, the UCI on the PUCCH can be multiplexed onto the PUSCH of CC1.

[0225] Scenario 2: If a PUSCH located on CC1 with SBFD configured is not an SBFD symbol and is located on an SBFD symbol of CC1, then the PUSCH is invalid. When the PUSCH overlaps in time with a PUCCH on CC2 without SBFD configured, the UCI of the PUCCH cannot be reused on the PUSCH of CC1.

[0226] Scenario 3: If a PUSCH located on CC1 with SBFD configured is an SBFD symbol and is located on a non-SBFD symbol of CC1, then the PUSCH is invalid. When the PUSCH overlaps in time with a PUCCH on CC2 without SBFD configured, the UCI of the PUCCH cannot be reused on the PUSCH of CC1.

[0227] Scenario 4: A PUSCH located on CC1 with SBFD configured is valid if its valid symbol type is SBFD and it is located on an SBFD symbol of CC1. Furthermore, when this PUSCH overlaps in time with a PUCCH on CC2 without SBFD configured, the UCI of this PUCCH cannot be multiplexed onto the PUSCH of CC2.

[0228] In one possible design, the first communication device first multiplexes the UCI carried on the PUCCH onto the PUSCH for transmission, and then determines the valid symbol type of the PUSCH on at least one first carrier (that is, first perform UCI multiplexing between CC1 and CC2, and then determine the valid symbol type on CC1).

[0229] For example, please refer to Figure 12B. Figure 12B is a schematic diagram of another multiplexing method provided by an embodiment of this application, in which the UCI carried on the PUCCH is multiplexed onto the PUSCH for transmission. As shown in Figure 12B, PUSCH1 and PUSCH2 are located in CC1, which is configured with SBFD operation. First, UCI multiplexing is performed between CCs. Although both PUSCH1 and PUSCH2 overlap with the PUCCH, since the valid symbol type of PUSCH1 is SBFD, it cannot be multiplexed with the UCI of CC2. Therefore, the UCI will be multiplexed onto PUSCH2 of CC1. That is, when the PUCCH on a CC without SBFD configuration overlaps with multiple PUSCHs on a CC with SBFD configuration, the UCI of the PUCCH will be multiplexed onto the first PUSCH with a valid symbol type other than SBFD.

[0230] Then, on CC1 configured with SBFD operation, the valid symbol type is determined. If the first time slot is an SBFD time slot (meaning all symbols in this time slot are SBFD symbols), then PUSCH1 is valid, PUSCH2 is invalid (and can be discarded). The UCIs of the PUCCH in this time slot cannot be multiplexed and cannot be transmitted on CC2, because PUSCH1 of CC1 needs to be transmitted at this time. If the second time slot is a non-SBFD time slot (meaning all symbols in this time slot are non-SBFD symbols), then PUSCH2 with multiplexed UCIs is valid, and PUSCH1 is invalid (and can be discarded).

[0231] In summary, the multiplexing result of this scheme is that only PUSCH1 of CC1 is transmitted in the first time slot, and the UCI of PUCCH1 is not multiplexed on PUSCH1; in the second time slot, the UCI originally carried on PUCCH is multiplexed onto PUSCH2 of CC1 for transmission.

[0232] Alternatively, four possible solutions to Figure 12B are illustrated below as examples:

[0233] Scenario 1: If a PUSCH located on CC1 with SBFD configured has a valid symbol type that is not SBFD and is located on a non-SBFD symbol of CC1, then when the PUSCH overlaps in time with a PUCCH on CC2 without SBFD configured, the UCI on the PUCCH can be multiplexed onto the PUSCH of CC1.

[0234] Scenario 2: If a PUSCH located on CC1 with SBFD configured has a non-SBFD symbol type and is located on an SBFD symbol of CC1, and this PUSCH overlaps in time with a PUCCH on CC2 without SBFD configured, the UCI on the PUCCH of CC2 can be multiplexed onto the PUSCH of CC1. However, since the valid symbol type of this PUSCH is a non-SBFD symbol and is located on an SBFD symbol of CC1, this PUSCH is invalid and cannot be sent.

[0235] Scenario 3: If a PUSCH located on CC1 with SBFD configured has an SBFD symbol type and is located on a non-SBFD symbol of CC1, when the PUSCH overlaps in time with a PUCCH on CC2 without SBFD configured, the UCI on the PUCCH of CC2 cannot be multiplexed onto the PUSCH of CC1, and the PUSCH is invalid.

[0236] Scenario 4: A PUSCH located on CC1 with SBFD configured is valid if its valid symbol type is SBFD and it is located on an SBFD symbol of CC1. Furthermore, when this PUSCH overlaps in time with a PUCCH on CC2 without SBFD configured, the UCI on the PUCCH of CC2 cannot be multiplexed onto the PUSCH of CC1.

[0237] Step S803: The second communication device determines the multiplexing result based on the configuration information and scheduling information.

[0238] The multiplexing result is used to characterize whether the received PUSCH has multiplexed the UCI.

[0239] In this scheme, the second communication device can determine whether the first communication device should multiplex UCI onto the PUSCH for transmission based on the configuration information and scheduling information of two types of carriers, one with SBFD configured and the other without. This supplements the multiplexing rules between different types of carriers not specified in the prior art. This scheme can realize the multiplexing of UCI to PUSCH in a multi-carrier system with SBFD configured on a single carrier.

[0240] It should be noted that since step S802 has already described in detail the various possibilities for determining the reuse result based on the configuration information and scheduling information, the specific details can be found in step S803, and will not be repeated here.

[0241] In this application, the first communication device can determine whether UCI needs to be multiplexed onto the PUSCH for transmission based on the configuration information and scheduling information of two types of carriers, one with SBFD configured and the other without SBFD configured, thus supplementing the multiplexing rules between different types of carriers not specified in the prior art. This solution provides multiplexing rules for UCI and PUSCH between different types of carriers, and performs UCI multiplexing according to the multiplexing rules, thereby improving the SBFD system design.

[0242] The methods of the embodiments of this application have been described in detail above. The apparatus of the embodiments of this application is provided below.

[0243] It should be understood that the division of units in the apparatus provided in the embodiments of this application is only a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, the units in the apparatus can be implemented by a processor calling software. For example, the apparatus includes a processor connected to a memory containing instructions. The processor calls the instructions stored in the memory to implement any of the above methods or to implement the functions of each unit of the apparatus. The processor is, for example, a general-purpose processor, such as a central processing unit (CPU) or a microprocessor, and the memory is either internal or external to the apparatus.

[0244] Alternatively, the units in the device can be implemented as hardware circuits. The functionality of some or all of the units can be achieved through the design of these hardware circuits, which can be understood as one or more processors. For example, in one implementation, the hardware circuit is an application-specific integrated circuit (ASIC). The functionality of some or all of the above units is achieved through the design of the logical relationships between the components within the circuit. In another implementation, the hardware circuit can be implemented using a programmable logic device (PLD). Taking a field-programmable gate array (FPGA) as an example, it can include a large number of logic gates. The connection relationships between the logic gates are configured through a configuration file, thereby achieving the functionality of some or all of the above units.

[0245] In the embodiments of this application, each unit in the device may be one or more processors (or processing circuits) configured to implement the above methods, such as: CPU, graphics processing unit (GPU), neural network processing unit (NPU), tensor processing unit (TPU), deep learning processing unit (DPU), microprocessor unit (MPU), digital signal processor (DSP), ASIC, FPGA, or a combination of at least two of these processor forms.

[0246] Furthermore, the units in the above devices can be integrated in whole or in part, or they can be implemented independently. In one implementation, these units are integrated together as a system-on-a-chip (SOC). The SOC may include at least one processor for implementing any of the above methods or for implementing the functions of the units in the device. The at least one processor can be of different types, such as including a CPU and an FPGA, or including a CPU and an AI processor, or including a CPU and a GPU, etc. Several possible devices are listed below.

[0247] Please refer to Figure 13, which is a schematic diagram of the structure of a communication device 130 provided in an embodiment of this application. Optionally, the communication device 130 can be a first communication device or a second communication device, such as a terminal device or a network device, or it can be a component in the first communication device or the second communication device, such as a chip or integrated circuit in the terminal device or the network device. The communication device 130 is used to implement the aforementioned communication method, such as the communication method shown in Figure 8.

[0248] In one possible design, the communication device 130 includes a communication unit 1301 and a processing unit 1302. The communication device 130 is used to implement the aforementioned communication method, such as the communication method shown in FIG8. Exemplarily, the communication device is used to execute the method executed by a first communication device, or to execute the method executed by a second communication device.

[0249] The embodiments of this application and the method embodiments shown above are based on the same concept and have the same technical effects. For the specific principles, please refer to the description of the embodiments shown above, which will not be repeated here.

[0250] Please refer to Figure 14, which is a schematic diagram of another communication device 140 provided in an embodiment of this application. The communication device 140 can be a standalone device, such as a first communication device or a second communication device, or it can be a component included in a first or second communication device, such as a chip, software module, or integrated circuit. The communication device 140 may include at least one processor 1401 and a communication interface 1402. Optionally, it may also include at least one memory 1403. Further optionally, it may also include a connection line 1404, wherein the processor 1401, the communication interface 1402, and / or the memory 1403 are connected via the connection line 1404, and / or communicate with each other via the connection line 1404 to transmit control signals and / or data signals.

[0251] Wherein: processor 1401 is a module that performs arithmetic and / or logical operations, and may specifically include one or more of the following modules: filter, modem, power amplifier, low noise amplifier (LNA), baseband processor, radio frequency processor, radio frequency circuit, CPU, AP, microcontroller unit (MCU), electronic control unit (ECU), GPU, MPU, ASIC, image signal processor (ISP), DSP, FPGA, complex programmable logic device (CPLD), or coprocessor, etc.

[0252] The communication interface 1402 can be used to provide information input or output to at least one processor, or to receive signals sent externally and / or send signals to externally.

[0253] For example, the communication interface 1402 may include interface circuitry, such as input / output interfaces, chip pins, etc.

[0254] For example, the communication interface 1402 may include a wired link interface such as an Ethernet cable, or a wireless link interface (Wi-Fi, Bluetooth, general wireless transmission, vehicle short-range communication technology and other short-range wireless communication technologies, etc.).

[0255] Optionally, the communication interface 1402 may also include a radio frequency transmitter, an antenna, etc. When the communication interface 1402 includes an antenna, the number of antennas can be one or more.

[0256] As one possible design, if the communication device 140 is a first network element, a communication device, or a second network element, the communication interface 1402 may include a receiver and a transmitter. The receiver and transmitter may be the same component or different components. When the receiver and transmitter are the same component, this component may be referred to as a transceiver.

[0257] As another possible design, if the communication device 140 is a chip or circuit, the communication interface 1402 may include an input interface and an output interface. The input interface and the output interface may be the same interface or they may be different interfaces.

[0258] Alternatively, the functionality of the communication interface 1402 can be implemented via transceiver circuitry or a dedicated transceiver chip.

[0259] The memory 1403 provides storage space, in which data such as the operating system and computer programs can be stored. The memory 1403 can be one or a combination of several of the following: cache, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), compact disc read-only memory (CD-ROM), synchronous dynamic random access memory (SDRAM), hard disk drive (HDD), solid-state drive (SSD), etc. Memory is any other medium capable of carrying or storing desired program code in the form of instructions or data structures, and accessible by a computer, but is not limited thereto. The memory in the embodiments of this application can also be a circuit or any other device capable of implementing storage functions, used to store computer programs or instructions, and / or data.

[0260] The functions and operations of each module or unit in the communication device 140 listed above are merely illustrative examples.

[0261] Each functional unit in the communication device 140 can be used to implement the aforementioned communication method, such as the communication method shown in FIG8, for example, to execute the method executed by the first communication device, or to execute the method executed by the second communication device.

[0262] Optionally, the processor 1401 may be a processor specifically designed to perform the aforementioned methods (for ease of distinction, referred to as a dedicated processor), or a processor that performs the aforementioned methods by calling a computer program (for ease of distinction, referred to as a dedicated processor). Optionally, at least one processor may include both dedicated processors and general-purpose processors.

[0263] Optionally, if the communication device 140 includes at least one memory 1403, and the processor 1401 implements the aforementioned communication method by calling a computer program, the computer program can be stored in the memory 1403.

[0264] This application also provides a chip, which includes logic circuitry and a communication interface. The communication interface is used to receive or transmit signals; the logic circuitry is used to receive or transmit signals through the communication interface. The chip is used to implement the aforementioned communication method, such as the communication method shown in FIG8, for example, to execute a method executed by a first communication device, or to execute a method executed by a second communication device.

[0265] This application also provides a communication system, which includes a first communication device and a second communication device.

[0266] Optionally, the communication system may also include a third communication device.

[0267] This application also provides a computer-readable storage medium storing instructions that, when executed on at least one processor (or communication device), implement the aforementioned communication method, such as the communication method shown in FIG8, for example, for executing a method executed by a first communication device, or for executing a method executed by a second communication device.

[0268] This application also provides a computer program product, which includes computer instructions for implementing the aforementioned communication method, such as the communication method shown in FIG8, for example, for executing a method executed by a first communication device, or for executing a method executed by a second communication device.

[0269] It should be noted that, in the embodiments of this application, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplarily" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of the words "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner.

[0270] In the embodiments of this application, "at least one" refers to one or more items, and "more than one" refers to two or more items. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of a single item or a plurality of items.

[0271] For example, at least one of a, b, or c can be represented as: a, b, c, (a and b), (a and c), (b and c), or (a and b and c), where a, b, and c can be single or multiple. "AND / OR" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects have an "OR" relationship.

[0272] Furthermore, unless otherwise stated, the use of ordinal numbers such as "first" and "second" in the embodiments of this application is for distinguishing multiple objects and is not for limiting the order, sequence, priority, or importance of multiple objects. Similarly, terms like "first node" and "second node" are merely for convenience in describing new parameters in different implementations and do not indicate differences in their execution operations, importance, structure, etc.

[0273] In the above embodiments, the term "when..." can be interpreted, depending on the context, as meaning "if...", "before...", "determined...", or "detected...". The above descriptions are merely optional embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the concept and principles of this application should be included within the protection scope of this application.

[0274] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

Claims

1. A communication method, characterized in that, Applied to a first communication device, the method includes: The system receives configuration information and scheduling information from a second communication device. The configuration information includes identification information of multiple carriers, subband full-duplex (SBFD) configuration information of at least one first carrier among the multiple carriers, and configuration information of at least one second carrier. The at least one second carrier is a carrier among the multiple carriers that is not configured with SBFD except for the at least one first carrier. The scheduling information includes uplink physical shared channel (PUSCH) scheduling information and uplink physical control channel (PUCCH) scheduling information. The PUCCH scheduling information is used to schedule the PUCCH carrying uplink control information (UCI). The multiplexing result is determined based on the configuration information and the scheduling information, wherein the multiplexing result is used to characterize whether the UCI is multiplexed onto the PUSCH for transmission.

2. The method according to claim 1, characterized in that, The scheduling information of the PUCCH is used to indicate that a PUCCH exists on the at least one first carrier, the scheduling information of the PUSCH is used to indicate that a PUSCH exists on the at least one second carrier, the PUCCH and PUSCH partially or completely overlap in time, the configuration information of the at least one first carrier is used to indicate that an SBFD symbol is configured on the at least one first carrier, and the configuration information of the at least one second carrier is used to indicate that the SBFD symbol is not configured on the at least one second carrier.

3. The method according to claim 1, characterized in that, The scheduling information of the PUSCH is used to indicate that there is a PUSCH on the at least one first carrier, the scheduling information of the PUCCH is used to indicate that there is a PUCCH on the at least one second carrier, the PUCCH and PUSCH partially or completely overlap in time, the configuration information of the at least one first carrier is used to indicate that an SBFD symbol is configured on the at least one first carrier, and the configuration information of the at least one second carrier is used to indicate that the SBFD symbol is not configured on the at least one second carrier.

4. The method according to any one of claims 1-3, characterized in that, Determining the reuse result based on the configuration information and the scheduling information includes: Based on the configuration information and the scheduling information, the UCI carried on the PUCCH is multiplexed onto the PUSCH for transmission.

5. The method according to any one of claims 1-3, characterized in that, Determining the reuse result based on the configuration information and the scheduling information includes: Based on the configuration information and the scheduling information, the UCI will not be multiplexed onto the PUSCH.

6. The method according to claim 2, characterized in that, The determination of the reuse result includes: When the effective symbol type of the PUCCH or PUSCH on at least one first carrier is a non-SBFD symbol, the UCI carried on the PUCCH is multiplexed onto the PUSCH for transmission.

7. The method according to claim 2, characterized in that, The determination of the reuse result includes: When the valid symbol type of the PUCCH or PUSCH on at least one first carrier is SBFD symbol, the UCI is not multiplexed onto the PUSCH for transmission or the PUSCH is not transmitted.

8. The method according to claim 3, characterized in that, The determination of the reuse result includes: When the effective symbol type of the PUSCH on at least one first carrier is a non-SBFD symbol, the UCI carried on the PUCCH is multiplexed onto the PUSCH for transmission.

9. The method according to claim 3, characterized in that, The determination of the reuse result includes: When the effective symbol type of the PUSCH on at least one first carrier is SBFD symbol, the UCI is not multiplexed onto the PUSCH for transmission or the PUSCH is not transmitted.

10. The method according to any one of claims 4-9, characterized in that, The step of multiplexing the UCI carried on the PUCCH onto the PUSCH for transmission includes: Determine the valid symbol type of PUCCH or PUSCH on the at least one first carrier; According to the valid symbol type of the PUCCH or PUSCH, the UCI carried on the PUCCH is multiplexed onto the PUSCH for transmission.

11. The method according to any one of claims 4-8, characterized in that, After multiplexing the UCI carried on the PUCCH onto the PUSCH for transmission, the method further includes: Determine the valid symbol type of PUSCH on the at least one first carrier.

12. A communication method, characterized in that, Applied to a second communication device, the method includes: The first communication device is sent configuration information and scheduling information. The configuration information includes identification information of multiple carriers, subband full-duplex (SBFD) configuration information of at least one first carrier among the multiple carriers, and configuration information of at least one second carrier. The at least one second carrier is a carrier among the multiple carriers that is not configured with SBFD except for the at least one first carrier. The scheduling information includes uplink physical shared channel (PUSCH) scheduling information and uplink physical control channel (PUCCH) scheduling information. The PUCCH scheduling information is used to schedule the PUCCH carrying uplink control information (UCI). The multiplexing result is determined based on the configuration information and the scheduling information, wherein the multiplexing result is used to characterize whether the received PUSCH reuses the UCI.

13. The method according to claim 12, characterized in that, The scheduling information of the PUCCH is used to indicate that a PUCCH exists on the at least one first carrier, the scheduling information of the PUSCH is used to indicate that a PUSCH exists on the at least one second carrier, the PUCCH and PUSCH partially or completely overlap in time, the configuration information of the at least one first carrier is used to indicate that an SBFD symbol is configured on the at least one first carrier, and the configuration information of the at least one second carrier is used to indicate that the SBFD symbol is not configured on the at least one second carrier.

14. The method according to claim 12, characterized in that, The scheduling information of the PUSCH is used to indicate that there is a PUSCH on the at least one first carrier, the scheduling information of the PUCCH is used to indicate that there is a PUCCH on the at least one second carrier, the PUCCH and PUSCH partially or completely overlap in time, the configuration information of the at least one first carrier is used to indicate that an SBFD symbol is configured on the at least one first carrier, and the configuration information of the at least one second carrier is used to indicate that the SBFD symbol is not configured on the at least one second carrier.

15. The method according to any one of claims 12-14, characterized in that, Determining the reuse result based on the configuration information and the scheduling information includes: Based on the configuration information and the scheduling information, the UCI carried on the PUCCH is multiplexed onto the PUSCH for transmission.

16. The method according to any one of claims 12-14, characterized in that, Determining the reuse result based on the configuration information and the scheduling information includes: Based on the configuration information and the scheduling information, the UCI will not be multiplexed onto the PUSCH.

17. The method according to claim 13, characterized in that, The determination of the reuse result includes: When the effective symbol type of the PUCCH on at least one first carrier is a non-SBFD symbol, the UCI carried on the PUCCH is multiplexed onto the PUSCH for transmission.

18. The method according to claim 13, characterized in that, The determination of the reuse result includes: When the valid symbol type of the PUCCH on at least one first carrier is SBFD symbol, the UCI is not multiplexed onto the PUSCH for transmission or the PUSCH is not transmitted.

19. The method according to claim 14, characterized in that, The determination of the reuse result includes: When the effective symbol type of the PUSCH on at least one first carrier is a non-SBFD symbol, the UCI carried on the PUCCH is multiplexed onto the PUSCH for transmission.

20. The method according to claim 14, characterized in that, The determination of the reuse result includes: When the effective symbol type of the PUSCH on at least one first carrier is SBFD symbol, the UCI is not multiplexed onto the PUSCH for transmission or the PUSCH is not transmitted.

21. The method according to any one of claims 15-20, characterized in that, The step of multiplexing the UCI carried on the PUCCH onto the PUSCH for transmission includes: Determine the valid symbol type of PUCCH or PUSCH on the at least one first carrier; According to the valid symbol type of the PUCCH or PUSCH, the UCI carried on the PUCCH is multiplexed onto the PUSCH for transmission.

22. The method according to any one of claims 15-19, characterized in that, After multiplexing the UCI carried on the PUCCH onto the PUSCH for transmission, the method further includes: Determine the valid symbol type of PUSCH on the at least one first carrier.

23. A communication device, characterized in that, The communication device includes a communication unit and a processing unit, the communication unit and the processing unit being used to perform the method as described in any one of claims 1-11.

24. A communication device, characterized in that, The communication device includes a communication unit and a processing unit, the communication unit and the processing unit being used to perform the method as described in any one of claims 12-22.

25. A communication device, characterized in that, The communication device includes a processor; When the processor invokes a computer program or instruction in memory, it causes the communication device to implement the method as described in any one of claims 1-11.

26. A communication device, characterized in that, The communication device includes a processor; When the processor invokes a computer program or instruction in memory, it causes the communication device to implement the method as described in any one of claims 12-22.

27. A communication device, characterized in that, It includes logic circuits and interfaces, wherein the logic circuits and the interfaces are coupled; The interface is used for inputting and / or outputting information, and the logic circuit is used to enable the communication device to implement the method as described in any one of claims 1-22.

28. The apparatus according to claim 27, characterized in that, The communication device is a chip or chip system.

29. A communication system, characterized in that, The communication system includes the communication device as described in claim 23 and the communication device as described in claim 24; or The communication system includes the communication device as described in claim 25 and the communication device as described in claim 26.

30. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store instructions or computer programs; The instructions or the computer program are executed to implement the method as described in any one of claims 1-22.

31. A computer program product, characterized in that, include: Instructions or computer programs; The instructions or the computer program are executed to implement the method as described in any one of claims 1-22.

Images