Information sending method, communication device, communication system, storage medium, and program product

Abstract

The present application discloses an information sending method, a communication device, a communication system, a storage medium, and a program product. The method comprises: repeatedly sending, to a network device, a physical uplink shared channel (PUSCH) multiplexed on the basis of an orthogonal cover code (OCC); repeatedly sending, to the network device, a physical uplink control channel (PUCCH); and determining that the PUCCH and the PUSCH overlap in the time domain, and executing a first operation, so that a terminal that needs to send a PUCCH over a PUSCH multiplexed on the basis of an OCC can execute a corresponding operation, thereby ensuring orthogonality between the terminal and other terminals in the same OCC multiplexing user group, preventing sending of the PUCCH from damaging the orthogonality between different terminals in the same OCC multiplexing user group, improving the efficiency and accuracy of system communication, and enhancing uplink coverage.

Description

Information transmission methods, communication equipment, communication systems, storage media and software products Technical Field

[0001] This application relates to the field of communication technology, and in particular to information transmission methods, communication equipment, communication systems, storage media, and program products. Background Technology

[0002] To improve uplink (UL) coverage and enable the cell to serve more users simultaneously, multi-user multiplexing based on orthogonal cover codes (OCC) can be considered to achieve uplink capacity enhancement. Summary of the Invention

[0003] This application provides information transmission methods, communication devices, communication systems, storage media, and program products.

[0004] The first aspect of this application provides an information transmission method, which is executed by a terminal, and the method includes:

[0005] Repeatedly transmit the Physical Uplink Shared Channel (PUSCH) based on Orthogonal Cover Code (OCC) multiplexing to the network device;

[0006] Repeatedly transmit the Physical Uplink Control Channel (PUCCH) to the network device;

[0007] If it is determined that the PUCCH and the PUSCH overlap in the time domain, the first operation is performed.

[0008] A second aspect of this application provides a terminal, the terminal comprising:

[0009] The transceiver module is used to repeatedly transmit the Physical Uplink Shared Channel (PUSCH) based on orthogonal cover code (OCC) multiplexing to the network device.

[0010] The transceiver module is also used to repeatedly send the Physical Uplink Control Channel (PUCCH) to the network device;

[0011] The processing module is used to determine that the PUCCH and the PUSCH overlap in the time domain and perform a first operation.

[0012] The scheme proposed in this application repeatedly transmits the Physical Uplink Shared Channel (PUSCH) based on Orthogonal Cover Code (OCC) multiplexing to the network device; repeatedly transmits the Physical Uplink Control Channel (PUCCH) to the network device; determines that the PUCCH and the PUSCH overlap in the time domain, and performs a first operation. This enables terminals that need to transmit PUCCH on the OCC-multiplexed PUSCH to perform corresponding operations, ensuring the orthogonality between the terminal and other terminals in the same OCC multiplexing user group, preventing the transmission of PUCCH from disrupting the orthogonality between different terminals within the same OCC multiplexing user group, improving system communication efficiency and accuracy, and enhancing uplink coverage. Attached Figure Description

[0013] To more clearly illustrate the technical solutions in the embodiments or background art of this application, the following description of the accompanying drawings is provided. The following drawings are merely some embodiments of this application and do not impose specific limitations on the scope of protection of this application.

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

[0015] Figure 1B is a schematic diagram of an OCC multiplexing process provided in an embodiment of this application;

[0016] Figure 1C is a schematic diagram of OCC multiplexing provided in an embodiment of this application;

[0017] Figure 2A is an interactive schematic diagram of an information sending method provided in an embodiment of this application;

[0018] Figure 2B is a schematic diagram of an information transmission timeline provided in an embodiment of this application;

[0019] Figures 3A-3D are interactive schematic diagrams of an information sending method provided in an embodiment of this application;

[0020] Figure 4A is a schematic diagram of the structure of a terminal provided in an embodiment of this application;

[0021] Figure 5A is a schematic diagram of the structure of a communication device provided in an embodiment of this application;

[0022] Figure 5B is a schematic diagram of the structure of a chip provided in an embodiment of this application. Detailed Implementation

[0023] This application provides information transmission methods, communication devices, communication systems, storage media, and program products.

[0024] In a first aspect, embodiments of this application propose an information transmission method, the method comprising:

[0025] Repeatedly transmit the Physical Uplink Shared Channel (PUSCH) based on Orthogonal Cover Code (OCC) multiplexing to the network device; repeatedly transmit the Physical Uplink Control Channel (PUCCH) to the network device; determine that the PUCCH and the PUSCH overlap in the time domain, and perform the first operation.

[0026] In the above embodiments, for terminals that need to send PUCCH on PUSCH based on OCC multiplexing, the corresponding first operation can be performed to ensure the orthogonality between the terminal and other terminals in the same OCC multiplexing user group, avoid the transmission of PUCCH from destroying the orthogonality between different terminals in the same OCC multiplexing user group, improve system communication efficiency and accuracy, and enhance uplink coverage.

[0027] In conjunction with some embodiments of the first aspect, in some embodiments, the priority of the PUSCH is the same as the priority of the PUCCH; the first operation is:

[0028] Cancel sending the PUCCH.

[0029] In conjunction with some embodiments of the first aspect, in some embodiments, the first operation is:

[0030] Repeatedly transmit the PUCCH based on OCC multiplexing on the first OCC group, the PUCCH and the PUSCH on the first OCC group covering the same OCC sequence value; cancel transmission of the PUSCH on the first OCC group; or cancel transmission of all PUSCH; wherein the first OCC group is the OCC group where the overlap is located, or the first OCC group is the next adjacent OCC group of the OCC group where the overlap is located; the PUSCH repeatedly transmitted on one OCC group covers the same value in the OCC sequence.

[0031] In conjunction with some embodiments of the first aspect, in some embodiments, the PUCCH and PUSCH based on OCC multiplexing are repeatedly transmitted on a first OCC group, wherein the PUCCH and PUSCH cover the same OCC sequence value; wherein the first OCC group is the OCC group in which the overlap is located, or the first OCC group is the next adjacent OCC group in which the overlap is located; the PUSCH repeatedly transmitted on one OCC group covers the same value in the OCC sequence.

[0032] In conjunction with some embodiments of the first aspect, in some embodiments, the number of times the PUCCH is actually transmitted is the same as the OCC length corresponding to the terminal; or, the number of times the PUCCH is actually transmitted is the same as the number of times the PUSCH is transmitted.

[0033] In conjunction with some embodiments of the first aspect, in some embodiments, the number of repeated transmissions of the configured PUCCH is different from the OCC length corresponding to the terminal; the method further includes:

[0034] The repeated transmission of the PUCCH is processed; wherein, the actual number of repeated transmissions of the processed PUCCH is the same as the OCC length corresponding to the terminal; or, the actual number of repeated transmissions of the processed PUCCH is the same as the number of repeated transmissions of the PUSCH.

[0035] In conjunction with some embodiments of the first aspect, in some embodiments, the number of times the PUCCH is retransmitted is the same as the OCC length corresponding to the terminal; or, the terminal does not expect the number of times the PUCCH is retransmitted to be different from the OCC length corresponding to the terminal.

[0036] In conjunction with some embodiments of the first aspect, in some embodiments, the starting time domain position of the actually transmitted PUCCH is the same as the starting time domain position corresponding to the PUSCH.

[0037] In conjunction with some embodiments of the first aspect, in some embodiments, the starting time domain position of the configured PUCCH is the same as the starting time domain position corresponding to the PUSCH; or, the terminal does not expect the starting time domain position of the PUCCH to be different from the starting time domain position corresponding to the PUSCH.

[0038] In conjunction with some embodiments of the first aspect, in some embodiments, the starting time domain position of the configured PUCCH is different from the starting time domain position corresponding to the PUSCH; the method further includes:

[0039] If the time-domain reference point meets the specified conditions, the repeated transmission of the PUCCH is extended; wherein, the starting time-domain position of the processed PUCCH is the same as the starting time-domain position of the corresponding PUSCH; the time-domain reference point is the starting time-domain position of the OCC group in which the overlap is located, or the time-domain reference is the starting time-domain position of the PUSCH.

[0040] In conjunction with some embodiments of the first aspect, in some embodiments, the starting time domain position of the configured PUCCH is different from the starting time domain position corresponding to the PUSCH; the method further includes:

[0041] If the time-domain reference point does not meet the specified conditions, the transmission of the PUCCH is cancelled; wherein, the time-domain reference point is the starting time-domain position of the OCC group in which the overlap is located, or, the time-domain reference is the starting time-domain position of the PUSCH.

[0042] In conjunction with some embodiments of the first aspect, in some embodiments, the starting time domain position of the configured PUCCH is different from the starting time domain position corresponding to the PUSCH; the first OCC group is the next adjacent OCC group of the OCC group where the overlap is located, and the starting time domain position of the actually transmitted PUCCH is the same as the starting time domain position of the first OCC group.

[0043] In conjunction with some embodiments of the first aspect, in some embodiments, the starting time domain position of the configured PUCCH is different from the starting time domain position corresponding to the PUSCH; the method further includes:

[0044] Cancel sending the PUCCH.

[0045] In conjunction with some embodiments of the first aspect, in some embodiments, the time-domain reference point satisfies specified conditions; the time-domain reference point is the starting time-domain position of the OCC group in which the overlap occurs, or the time-domain reference is the starting time-domain position of the PUSCH; wherein, the specified conditions include at least one of the following:

[0046] The time interval between the uplink scheduling grant and the time domain reference point exceeds the preparation time of the PUCCH and the PUSCH; the PUCCH carries a Hybrid Automatic Repeat Request Acknowledgment (HARQ-ACK), and the time interval between the Physical Downlink Shared Channel (PDSCH) associated with the HARQ-ACK and the time domain reference point exceeds both the decoding time of the PDSCH and the preparation time of the PUCCH and the PUSCH.

[0047] Secondly, embodiments of this application propose a terminal, which includes a transceiver module; wherein the terminal is used to execute the first aspect and optional implementations of the first aspect.

[0048] Thirdly, embodiments of this application propose a terminal, which includes one or more processors; wherein the terminal is used to execute the first aspect and optional implementations of the first aspect.

[0049] Fourthly, embodiments of this application propose a communication device for executing the first aspect and optional implementations thereof.

[0050] Fifthly, embodiments of this application propose a communication system, which includes: a terminal and a network device; wherein the terminal is configured to perform the method described in the first aspect and optional implementations of the first aspect.

[0051] In a sixth aspect, embodiments of this application provide a storage medium storing instructions that, when executed on a communication device, cause the communication device to perform the first aspect and its optional implementation.

[0052] In a seventh aspect, embodiments of this application provide a program product that, when executed by a communication device, causes the communication device to perform the first aspect and its optional implementation.

[0053] Eighthly, embodiments of this application provide a computer program that, when run on a computer, causes the computer to perform the first aspect and optional implementations of the first aspect.

[0054] Ninthly, embodiments of this application provide a chip or chip system. The chip or chip system includes processing circuitry configured to execute according to the first aspect and its optional implementations.

[0055] It is understood that the aforementioned terminals, network devices, communication devices, communication systems, storage media, and program products are all used to execute the methods proposed in the embodiments of this application. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods, and will not be repeated here.

[0056] This application provides information transmission methods, communication devices, communication systems, storage media, and program products. In some embodiments, the terms information transmission method, communication method, information processing method, and data processing method can be used interchangeably.

[0057] The embodiments in this application are not exhaustive, but merely illustrative of some embodiments, and are not intended to limit the scope of protection of this application. Unless otherwise specified, each step in a particular embodiment can be implemented as an independent embodiment, and the steps can be arbitrarily combined. For example, a solution after removing some steps in a particular embodiment can also be implemented as an independent embodiment, and the order of the steps in a particular embodiment can be arbitrarily interchanged. Furthermore, the optional implementation methods in a particular embodiment can be arbitrarily combined; moreover, the embodiments can be arbitrarily combined, for example, some or all steps of different embodiments can be arbitrarily combined, and a particular embodiment can be arbitrarily combined with the optional implementation methods of other embodiments. In the embodiments of this application, unless otherwise specified or logically conflicting, the terminology and / or descriptions between the embodiments are consistent and can be mutually referenced. Technical features in different embodiments can be combined to form new embodiments based on their inherent logical relationships.

[0058] The terminology used in the embodiments of this application is for the purpose of describing specific embodiments only and is not intended to limit the scope of this application.

[0059] In the embodiments of this application, unless otherwise stated, elements expressed in the singular form, such as "a," "an," "the," "the," "the," "the," "the," "the," "this," etc., can mean "one and only one," or "one or more," "at least one," etc. For example, when using articles such as "a," "an," "the," etc. in translation, the noun after the article can be understood as either a singular expression or a plural expression.

[0060] In the embodiments of this application, "multiple" refers to two or more.

[0061] In some embodiments, the terms “at least one of A or B, at least one of A and B”, “one or more”, “a plurality of”, “multiple”, etc., may be used interchangeably.

[0062] In some embodiments, the notation "at least one of A and B", "A and / or B", "A in one case, B in another", "in response to one case A, in response to another case B", etc., may include the following technical solutions depending on the situation: in some embodiments, A (execute A regardless of whether there is a branch B); in some embodiments, B (execute B regardless of whether there is a branch A); in some embodiments, execution is selected from A and B (A and B are selectively executed); in some embodiments, both A and B are executed. The same applies when there are more branches such as A, B, C, etc.

[0063] In some embodiments, the notation "A or B" may include the following technical solutions, depending on the situation: in some embodiments, A (execute A regardless of whether a branch B exists); in some embodiments, B (execute B regardless of whether a branch A exists); in some embodiments, execution is selected from A and B (A and B are selectively executed). The same applies when there are more branches such as A, B, and C.

[0064] The prefixes "first," "second," etc., used in the embodiments of this application are merely for distinguishing different descriptive objects and do not impose restrictions on the position, order, priority, quantity, or content of the descriptive objects. The description of the descriptive objects is found in the claims or the context of the embodiments, and the use of prefixes should not constitute unnecessary restrictions. For example, if the descriptive object is a "field," the ordinal numbers preceding "field" in "first field" and "second field" do not restrict the position or order of the "fields." "First" and "second" do not restrict whether the "fields" they modify are in the same message, nor do they restrict the order of "first field" and "second field." Similarly, if the descriptive object is a "level," the ordinal numbers preceding "level" in "first level" and "second level" do not restrict the priority between "levels." Furthermore, the number of descriptive objects is not limited by ordinal numbers and can be one or more. For example, in "first device," the number of "devices" can be one or more. Furthermore, the objects modified by different prefixes can be the same or different. For example, if the object being described is "device", then "first device" and "second device" can be the same device or different devices, and their types can be the same or different. Similarly, if the object being described is "information", then "first information" and "second information" can be the same information or different information, and their content can be the same or different.

[0065] In some embodiments, “including A,” “containing A,” “for indicating A,” and “carrying A” can be interpreted as directly carrying A or indirectly indicating A.

[0066] In some embodiments, terms such as "time / frequency" and "time-frequency domain" refer to the time domain and / or frequency domain.

[0067] In some embodiments, terms such as “in response to…”, “in response to determining…”, “in the case of…”, “when…”, “when…”, “if…”, etc. can be used interchangeably. These descriptions all refer to the device making a corresponding action under certain objective circumstances. They do not necessarily limit the time, nor do they require the device to make a judgment action when implementing it, nor do they mean that there must be other limitations.

[0068] In some embodiments, the terms “greater than,” “greater than or equal to,” “not less than,” “more than,” “more than or equal to,” “not less than,” “higher than,” “higher than or equal to,” “not lower than,” and “above” can be used interchangeably, as can the terms “less than,” “less than or equal to,” “not greater than,” “less than,” “less than or equal to,” “not more than,” “lower than,” “lower than or equal to,” “not higher than,” and “below”.

[0069] In some embodiments, devices, etc., may be interpreted as physical or virtual, and their names are not limited to those described in the embodiments. Terms such as “device,” “equipment,” “circuit,” “network element,” “network function,” “network device,” “function,” “node,” “unit,” “section,” “system,” “network,” “chip,” “chip system,” “entity,” and “subject” are interchangeable.

[0070] In some embodiments, "network" can be interpreted as devices included in a network (e.g., access network devices, core network devices, etc.).

[0071] In some embodiments, the terms "access network device (AN device)," "radio access network device (RAN device)," "base station (BS)," "radio base station," "fixed station," "node," "access point," "transmission point (TP)," "reception point (RP)," "transmission / reception point (TRP)," "panel," "antenna panel," "antenna array," "cell," "macro cell," "small cell," "femto cell," "pico cell," "sector," "cell group," "serving cell," "carrier," "component carrier," and "bandwidth part (BWP)" can be used interchangeably.

[0072] In some embodiments, the terms "terminal", "terminal device", "user equipment (UE)", "user terminal", "mobile station (MS)", "mobile terminal (MT)", "subscriber station", "mobile unit", "subscriber unit", "wireless unit", "remote unit", "mobile device", "wireless device", "wireless communication device", "remote device", "mobile subscriber station", "access terminal", "mobile terminal", "wireless terminal", "remote terminal", "handset", "user agent", "mobile client", and "client" can be used interchangeably.

[0073] In some embodiments, access network devices, core network devices, or network devices can be replaced by terminals. For example, various embodiments of this application can also be applied to structures that replace communication between access network devices, core network devices, or network devices and terminals with communication between multiple terminals (e.g., device-to-device (D2D), vehicle-to-everything (V2X), etc.). In this case, the structure can also be configured such that the terminal has all or part of the functions of the access network device. Furthermore, terms such as "uplink" and "downlink" can be replaced with terms corresponding to communication between terminals (e.g., "sidelink"). For example, uplink channel, downlink channel, etc., can be replaced with sidelink channel, uplink link, downlink link, etc., can be replaced with sidelink link.

[0074] In some embodiments, the terminal may be replaced by an access network device, a core network device, or a network device. In this case, the access network device, core network device, or network device may also be configured to have all or some of the functions of the terminal.

[0075] In some embodiments, the acquisition of data, information, etc., may comply with the laws and regulations of the country where the location is situated.

[0076] In some embodiments, data, information, etc., may be obtained with the user's consent.

[0077] Furthermore, each element, each row, or each column in the table of this application embodiment can be implemented as an independent embodiment, and any combination of any element, any row, or any column can also be implemented as an independent embodiment.

[0078] Figure 1A is a schematic diagram of the architecture of a communication system according to an embodiment of this application.

[0079] As shown in Figure 1A, the communication system 100 includes a terminal 101 and a network device 102.

[0080] In some embodiments, terminal 101 includes, for example, at least one of the following: mobile phone, wearable device, Internet of Things (IoT) device, narrowband Internet of Things (NB-IoT) device, satellite communication device, car with communication function, smart car, tablet computer, computer with wireless transceiver function, virtual reality (VR) terminal device, augmented reality (AR) terminal device, wireless terminal device in industrial control, wireless terminal device in self-driving, wireless terminal device in remote medical surgery, wireless terminal device in smart grid, wireless terminal device in transportation safety, wireless terminal device in smart city, wireless terminal device in smart home, and red-capped terminal, but is not limited thereto.

[0081] In some embodiments, network device 102 may be a node or device that connects a terminal to a wireless network. The network device may include, but is not limited to, nodes such as satellites or drones in non-terrestrial networks, evolved Node B (eNB), next-generation eNB (ng-eNB), next-generation Node B (gNB), next-generation RAN node (NG-RAN node), node B (NB), home node B (HNB), home evolved node B (HeNB), wireless backhaul device, radio network controller (RNC), base station controller (BSC), base transceiver station (BTS), base band unit (BBU), mobile switching center, base station in 6G communication system, open RAN, cloud RAN, base station in other communication systems, and access node in Wi-Fi system.

[0082] In some embodiments, the technical solutions of this application can be applied to the Open RAN architecture. In this case, the interfaces between or within access network devices involved in the embodiments of this application can be transformed into internal interfaces of Open RAN. The processes and information interactions between these internal interfaces can be implemented by software or programs.

[0083] In some embodiments, the access network device may be composed of a central unit (CU) and a distributed unit (DU). The CU may also be called a control unit. The CU-DU structure can separate the protocol layer of the access network device. Some of the protocol layer functions are centrally controlled by the CU, while the remaining part or all of the protocol layer functions are distributed in the DU and centrally controlled by the CU. However, this is not the only possibility.

[0084] It is understood that the communication system described in the embodiments of this application is for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and does not constitute a limitation on the technical solutions proposed in the embodiments of 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 proposed in the embodiments of this application are also applicable to similar technical problems.

[0085] The following embodiments of this application can be applied to the communication system 100 shown in FIG1A, or to some of the main bodies, but are not limited thereto. The main bodies shown in FIG1A are illustrative. The communication system may include all or some of the main bodies in FIG1A, or it may include other main bodies outside of FIG1A. The number and form of each main body are arbitrary. Each main body may be physical or virtual. The connection relationship between the main bodies is illustrative. The main bodies may not be connected or may be connected. The connection can be in any way, it can be a direct connection or an indirect connection, it can be a wired connection or a wireless connection.

[0086] The embodiments of this application can be applied to Non-terrestrial Networks (NTN), Long Term Evolution (LTE), LTE-Advanced (LTE-A), LTE-Beyond (LTE-B), SUPER 3G, IMT-Advanced, 4th generation mobile communication system (4G), 5th generation mobile communication system (5G), 5G new radio (NR), 6th generation mobile communication system (6G), 6G new radio (NR), Future Radio Access (FRA), New-Radio Access Technology (RAT), New Radio (NR), New Radio Access (NX), Future Generation Radio Access (FX), Global System for Mobile Communications (GSM (registered trademark)), CDMA2000, Ultra Mobile Broadband (UMB), and IEEE IEEE 802.11 (Wi-Fi, registered trademark), IEEE 802.16 (WiMAX, registered trademark), IEEE 802.20, Ultra-Wideband (UWB), Bluetooth (registered trademark), Public Land Mobile Network (PLMN) networks, Device-to-Device (D2D) systems, Machine-to-Machine (M2M) systems, Internet of Things (IoT) systems, Narrow Band-IoT (NB-IoT) systems, Vehicle-to-Everything (V2X) systems, systems utilizing other communication methods, and next-generation systems built upon them. Furthermore, multiple systems can be combined (e.g., a combination of LTE or LTE-A with 5G / 6G).

[0087] In some embodiments, in order to improve uplink (UL) coverage and enable the cell to serve more users simultaneously, multi-user multiplexing based on orthogonal cover code (OCC) can be considered to achieve uplink capacity enhancement.

[0088] In some embodiments, non-terrestrial networks (NTNs) are an important technology that provides wireless resources via satellites (or UAS platforms, where UAS stands for unmanned aircraft system) rather than ground base stations.

[0089] In NTN, uplink capacity enhancement is considered for the following reasons in order to serve more users simultaneously:

[0090] 1. Limited frequency band resources are available for NTN;

[0091] 2. Satellites cover a larger cell radius, allowing for more users within a single cell compared to terrestrial networks;

[0092] 3. The transmission distance between the terminal and the satellite is relatively long. Under the premise of limited terminal transmission power, in order to improve cell coverage and transmission performance, the NTN network often needs to perform more blind retransmissions, which will greatly waste spectrum resources and reduce spectrum efficiency.

[0093] To improve uplink (UL) coverage and enable the cell to serve more users simultaneously, multi-user multiplexing based on orthogonal cover codes (OCC) can be considered to enhance uplink capacity.

[0094] In some embodiments, for OCC multiplexing, the supported OCC lengths are 2 and 4. For both OCC length 2 and OCC length 4, an inter-slot OCC multiplexing scheme is adopted.

[0095] As an example, the terminal processing flow for OCC multiplexing can be roughly shown in Figure 1B.

[0096] As an example, a multi-user OCC multiplexing scenario can be illustrated in Figure 1C, where UE#1 and UE#2 perform OCC multiplexing of length 2. Here, d(i) is the modulation symbol of UE#1, c(i) is the modulation symbol of UE#2, the OCC sequence corresponding to UE#1 is {1,-1}, and the OCC sequence corresponding to UE#2 is {1,1}. UE#1 and UE#2 occupy the same time-frequency domain resources.

[0097] The information transmission method, communication equipment, communication system, storage medium, and program products provided in this application will be described in detail below with reference to the accompanying drawings.

[0098] Figure 2A is an interactive schematic diagram of an information sending method according to an embodiment of this application. As shown in Figure 2A, this application embodiment relates to an information sending method, which includes:

[0099] Step S2101, terminal 101 sends PUSCH based on OCC multiplexing.

[0100] In some embodiments, terminal 101 sends a Physical Uplink Shared Channel (PUSCH) based on OCC multiplexing to network device 102.

[0101] In some embodiments, terminal 101 repeatedly sends PUSCH based on OCC multiplexing to network device 102.

[0102] In some embodiments, terminals in the same OCC multiplexing user group occupy the same time-frequency domain resources for their corresponding PUSCHs.

[0103] It is understandable that multiple terminals in the same OCC multiplexing user group can send uplink information on the same time-frequency domain resources, and different terminals cover different OCC sequences when sending uplink information.

[0104] In some embodiments, the OCC multiplexing described above is inter-slot OCC multiplexing.

[0105] In some embodiments, terminal 101 repeatedly transmits PUSCH in the time slots where OCC multiplexing is performed, wherein each time slot corresponds to a repetition of PUSCH.

[0106] In some embodiments, the number of times PUSCH can be retransmitted may be pre-configured by network device 102.

[0107] In step S2102, terminal 101 sends PUCCH.

[0108] In some embodiments, terminal 101 sends a Physical Uplink Control Channel (PUCCH) to network device 102.

[0109] In some embodiments, the PUCCH may carry uplink control information (UCI).

[0110] In some embodiments, the PUCCH may also carry a Hybrid Automatic Repeat Request-Acknowledge (HARQ-ACK) message.

[0111] In some embodiments, terminal 101 repeatedly sends the above-mentioned PUCCH to network device 102.

[0112] In some embodiments, the number of times the PUCCH can be repeatedly transmitted can be configured by the network device 102.

[0113] In step S2103, terminal 101 performs the first operation.

[0114] In some embodiments, terminal 101 determines that the PUSCH and PUCCH overlap in the time domain and performs a first operation.

[0115] In some embodiments, the PUSCH and PUCCH have the same priority, and the first operation is to cancel sending the PUCCH.

[0116] That is, in some embodiments, for PUSCH and PUCCH with the same priority, there is a time-domain overlap in the transmission of PUSCH and PUCCH. The transmission of PUCCH repetition is canceled (dropped) to ensure the transmission of PUSCH repetition.

[0117] Optionally, the priority information of PUSCH and PUCCH mentioned above can be pre-configured by network device 102.

[0118] In some embodiments, the first operation described above may also be: cancel sending the PUSCH.

[0119] Furthermore, terminal 101 performs OCC code covering processing on the transmitted PUCCH and repeatedly transmits the OCC-multiplexed PUCCH to network device 102.

[0120] The OCC sequence value (or OCC code) covered by the above PUCCH is the same as the PUSCH that was originally to be sent on that time domain resource.

[0121] In some embodiments, terminal 101 repeatedly transmits the above-mentioned PUCCH based on OCC multiplexing on the first OCC group, the PUCCH covering the same OCC sequence value as the PUSCH originally to be transmitted on the first OCC group.

[0122] In some embodiments, terminal 101 cancels the transmission of PUSCH on the first OCC group.

[0123] In some embodiments, terminal 101 may also cancel sending all PUSCH repetitions.

[0124] Optionally, the first OCC group mentioned above can be the OCC group in which the aforementioned overlap occurs.

[0125] Optionally, the first OCC group mentioned above can also be the next adjacent OCC group of the OCC group where the overlap occurs. That is, for the OCC group where the current overlap occurs, the PUSCH based on OCC multiplexing is normally retransmitted (this can be understood as the case where the PUSCH on the first OCC group is canceled).

[0126] It should be noted that repeated PUSCH transmissions on the same OCC group cover the same OCC sequence value. For example, as shown in Figure 2B, one PUSCH repetition occupies one time slot. The four PUSCH repetitions in Figure 2B (PUSCH with 4 repetitions) cover the same OCC sequence value, and these four repetitions constitute one OCC group.

[0127] In some embodiments, when terminal 101 performs the operation of canceling the sending of the above-mentioned PUSCH, the timeline also needs to meet at least one of the following:

[0128] The time interval between the uplink scheduling grant (UL grant) and the earliest overlapping PUSCH / PUCCH channel must exceed the preparation time of PUCCH and PUSCH.

[0129] If the PUCCH carries a Hybrid Automatic Repeat Request Acknowledgment (HARQ-ACK), then the time interval between the Physical Downlink Shared Channel (PDSCH) associated with the HARQ-ACK and the earliest overlapping PUSCH / PUCCH channel must be greater than both the PDSCH decoding time and the PUCCH preparation time.

[0130] The earliest overlapping PUSCH / PUCCH channel mentioned above refers to the time slot where the PUCCH that terminal 101 is actually preparing to send overlaps with the PUSCH mentioned above.

[0131] Optionally, the aforementioned uplink scheduling grant (UL grant) is used to schedule the aforementioned PUSCH.

[0132] Optionally, the aforementioned uplink scheduling authorization can be statically or semi-statically configured (e.g., static or semi-static configuration information), or dynamically scheduled (e.g., downlink control information (DCI)).

[0133] In some embodiments, when terminal 101 performs the operation of canceling the transmission of the above-mentioned PUSCH, the actual number of times the above-mentioned PUSCH is repeatedly transmitted needs to be the same as the OCC length of the above-mentioned PUSCH (that is, the OCC length corresponding to terminal 101).

[0134] In some embodiments, the terminal 101 performs the operation of canceling the transmission of the PUSCH, and the actual number of times the PUSCH is repeatedly transmitted is the same as the number of times the PUSCH is repeatedly transmitted.

[0135] It is understandable that the actual number of PUCCH retransmissions may be the same as or different from the number of PUCCH retransmissions configured / indicated by network device 102. The actual number of retransmissions can be adjusted based on scheduling.

[0136] In some embodiments, in order to ensure that the actual number of times the PUCCH is retransmitted is the same as the OCC length / PUSCH retransmission number corresponding to terminal 101, the configured number of times the PUCCH is retransmitted may be the same as the OCC length corresponding to the terminal; or, terminal 101 may not expect the number of times the PUCCH is retransmitted to be different from the OCC length corresponding to terminal 101.

[0137] In some embodiments, it is permissible for the configured number of PUCCH retransmissions to differ from the OCC length corresponding to the terminal. To ensure that the actual number of PUCCH retransmissions is the same as the OCC length / retransmission count of the PUSCH, the terminal 101 can perform corresponding processing on the retransmission of the PUCCH; wherein, the processed actual number of PUCCH retransmissions is the same as the OCC length / retransmission count of the PUSCH corresponding to the terminal 101.

[0138] Optionally, if the OCC length corresponding to terminal 101 is greater than the configured number of PUCCH repetitions, further spreading of the PUCCH repetitions can be considered. After spreading, the actual number of times the PUCCH is repeatedly sent is the OCC length / the number of PUCCH repetitions.

[0139] Optionally, if the OCC length corresponding to terminal 101 is less than the configured number of PUCCH repetitions, consider reducing the number of PUCCH repetitions. After the reduction, the actual number of times PUCCH is sent repeatedly is OCC length / number of PUCCH repetitions.

[0140] In some embodiments, when terminal 101 performs the operation of canceling the transmission of the PUSCH, the starting time domain position of the actually transmitted PUSCH must be the same as the corresponding starting time domain position of the PUSCH.

[0141] It is understandable that the starting time domain position of the actual PUCCH transmission is defined independently of the starting time domain position of the PUCCH configured / indicated by network device 102. They can be the same or different, depending on the scheduling of network device 102. The starting time domain position of the actual transmission can be adjusted based on the scheduling.

[0142] Optionally, the above-mentioned starting time domain position refers to the time domain position when the first repeated transmission is performed (which may be the time slot corresponding to the channel of the first repeated transmission, or the starting subframe position corresponding to the channel of the first repeated transmission).

[0143] Optionally, the temporal resource unit of the aforementioned starting temporal position can be a slot or a subframe, and there is no limitation on this.

[0144] In some embodiments, in order to ensure that the starting time domain position of the actually transmitted PUCCH is the same as the corresponding starting time domain position of the PUSCH, the starting time domain position of the configured PUCCH may be determined to be the same as the starting time domain position of the PUSCH; or, the terminal 101 does not expect the starting time domain position of the configured PUCCH to be different from the starting time domain position of the PUSCH.

[0145] In some embodiments, it is permissible for the configured start time domain position of the PUCCH to differ from that of the PUSCH. To ensure that the actual start time domain position of the transmitted PUCCH is the same as the corresponding start time domain position of the PUSCH, repeated transmissions of the PUCCH can be extended. That is, the repeated transmissions of the PUCCH are extended forward, resulting in a PUCCH start time domain position that is the same as the corresponding start time domain position of the PUSCH.

[0146] In performing the above operations, terminal 101 needs to determine that the time-domain reference point meets specified conditions. These specified conditions include at least one of the following: the time interval between the uplink scheduling grant (UL grant) and the time-domain reference point must exceed the preparation time of the PUCCH and PUSCH; if the PUCCH carries a HARQ-ACK, then the time interval between the PDSCH associated with the HARQ-ACK and the time-domain reference point must be greater than both the PDSCH decoding time and the PUCCH preparation time.

[0147] The aforementioned time-domain reference point is the starting time-domain position of the OCC group where the overlap occurs, or the time-domain reference is the starting time-domain position corresponding to all PUSCH repetitions (that is, the starting time-domain position corresponding to the first PUSCH repetition).

[0148] Optionally, the aforementioned uplink scheduling grant (UL grant) is used to schedule the aforementioned PUSCH.

[0149] Optionally, the aforementioned uplink scheduling authorization can be statically or semi-statically configured (e.g., static or semi-static configuration information), or dynamically scheduled (e.g., DCI).

[0150] As an example, as shown in Figure 2B, timeline 2 in the figure represents the time interval between the uplink scheduling grant (UL grant) and the time-domain reference point. Timeline 1 in the figure represents the time interval between the PUCCH carrying the HARQ-ACK and the PDSCH associated with the HARQ-ACK, and the time-domain reference point.

[0151] In some embodiments, it is permissible for the configured start time domain position of the PUCCH to differ from the start time domain position of the PUSCH. If the time domain reference point does not meet the conditions specified above, this can be considered an error case, and the PUCCH transmission will be cancelled.

[0152] In some embodiments, it is permissible for the configured start time domain position of the PUCCH to differ from that of the PUSCH. To ensure that the actual start time domain position of the transmitted PUCCH is the same as the corresponding start time domain position of the PUSCH, the first OCC group is determined to be the next adjacent OCC group to which the overlap occurs. That is, when the configured start time domain position of the PUCCH differs from that of the PUSCH, the transmission of the PUCCH is delayed until the next OCC group. For the currently overlapping OCC group, the PUSCH is still repeatedly transmitted, and this retransmission is canceled and the PUCCH is retransmitted only in the next OCC group.

[0153] In some embodiments, it is also permissible for the configured start time domain position of the PUCCH to differ from the start time domain position of the PUSCH. In this case, the PUCCH transmission is cancelled.

[0154] In some embodiments, the first operation described above may also be: terminal 101 repeatedly transmits PUCCH and PUSCH based on OCC multiplexing on the first OCC group.

[0155] The OCC sequence value (or OCC code) covered by the above PUCCH is the same as that of the above PUSCH.

[0156] That is, in some embodiments, terminal 101 repeatedly transmits the above-mentioned OCC-based multiplexed PUCCH and PUSCH on the first OCC group, wherein the PUCCH and PUSCH cover the same OCC sequence value, and the above-mentioned PUCCH and PUSCH are multiplexed at the modulation symbol level.

[0157] Optionally, the first OCC group mentioned above can be the OCC group in which the aforementioned overlap occurs.

[0158] Optionally, the first OCC group mentioned above can also be the next adjacent OCC group of the OCC group where the overlap occurs. That is, for the currently overlapping OCC group, PUSCH based on OCC multiplexing is transmitted normally.

[0159] It should be noted that repeated PUSCH transmissions on the same OCC group cover the same OCC sequence value. For example, as shown in Figure 2B, one PUSCH repetition occupies one time slot. The four PUSCH repetitions in Figure 2B (PUSCH with 4 repetitions) cover the same OCC sequence value, and these four repetitions constitute one OCC group.

[0160] In some embodiments, when terminal 101 performs the operation of canceling the sending of the above-mentioned PUSCH, the timeline also needs to meet at least one of the following:

[0161] The time interval between the uplink scheduling grant (UL grant) and the earliest overlapping PUSCH / PUCCH channel must exceed the preparation time of PUCCH and PUSCH;

[0162] If the PUCCH carries a HARQ-ACK, then the time interval between the PDSCH associated with the HARQ-ACK and the earliest overlapping PUSCH / PUCCH channel must be greater than both the PDSCH decoding time and the PUCCH preparation time.

[0163] The earliest overlapping PUSCH / PUCCH channel mentioned above refers to the time slot where the PUCCH that terminal 101 is actually preparing to send overlaps with the PUSCH mentioned above.

[0164] Optionally, the aforementioned uplink scheduling grant (UL grant) is used to schedule the aforementioned PUSCH.

[0165] Optionally, the aforementioned uplink scheduling authorization can be statically or semi-statically configured (e.g., static or semi-static configuration information), or dynamically scheduled (e.g., downlink control information (DCI)).

[0166] In some embodiments, when terminal 101 performs the above operation, the actual number of times the PUCCH is repeatedly transmitted needs to be the same as the OCC length of the PUSCH (that is, the OCC length corresponding to terminal 101).

[0167] In some embodiments, when terminal 101 performs the above operation, the actual number of times the PUCCH is repeatedly transmitted needs to be the same as the number of times the PUSCH is repeatedly transmitted.

[0168] It is understandable that the actual number of PUCCH retransmissions may be the same as or different from the number of PUCCH retransmissions configured / indicated by network device 102. The actual number of retransmissions can be adjusted based on scheduling.

[0169] In some embodiments, in order to ensure that the actual number of times the PUCCH is retransmitted is the same as the OCC length / PUSCH retransmission number corresponding to terminal 101, the configured number of times the PUCCH is retransmitted may be the same as the OCC length corresponding to the terminal; or, terminal 101 may not expect the number of times the PUCCH is retransmitted to be different from the OCC length corresponding to terminal 101.

[0170] In some embodiments, it is permissible for the configured number of PUCCH retransmissions to differ from the OCC length corresponding to the terminal. To ensure that the actual number of PUCCH retransmissions is the same as the OCC length / retransmission count of the PUSCH, the terminal 101 can perform corresponding processing on the retransmission of the PUCCH; wherein, the processed actual number of PUCCH retransmissions is the same as the OCC length / retransmission count of the PUSCH corresponding to the terminal 101.

[0171] Optionally, if the OCC length corresponding to terminal 101 is greater than the configured number of PUCCH repetitions, further spreading of the PUCCH repetitions can be considered. After spreading, the actual number of times the PUCCH is repeatedly sent is the OCC length / the number of PUCCH repetitions.

[0172] Optionally, if the OCC length corresponding to terminal 101 is less than the configured number of PUCCH repetitions, consider reducing the number of PUCCH repetitions. After the reduction, the actual number of times PUCCH is sent repeatedly is OCC length / number of PUCCH repetitions.

[0173] In some embodiments, when terminal 101 performs the operation of canceling the transmission of the PUSCH, the starting time domain position of the actually transmitted PUSCH must be the same as the corresponding starting time domain position of the PUSCH.

[0174] It is understandable that the starting time domain position of the actual PUCCH transmission is defined independently of the starting time domain position of the PUCCH configured / indicated by network device 102. They can be the same or different, depending on the scheduling of network device 102. The starting time domain position of the actual transmission can be adjusted based on the scheduling.

[0175] Optionally, the above-mentioned starting time domain position refers to the time domain position when the first repeated transmission is performed (which may be the time slot corresponding to the channel of the first repeated transmission, or the starting subframe position corresponding to the channel of the first repeated transmission).

[0176] Optionally, the temporal resource unit of the aforementioned starting temporal position can be a slot or a subframe, and there is no limitation on this.

[0177] In some embodiments, in order to ensure that the starting time domain position of the actually transmitted PUCCH is the same as the corresponding starting time domain position of the PUSCH, the starting time domain position of the configured PUCCH may be determined to be the same as the starting time domain position of the PUSCH; or, the terminal 101 does not expect the starting time domain position of the configured PUCCH to be different from the starting time domain position of the PUSCH.

[0178] In some embodiments, it is permissible for the configured start time domain position of the PUCCH to differ from that of the PUSCH. To ensure that the actual start time domain position of the transmitted PUCCH is the same as the corresponding start time domain position of the PUSCH, repeated transmissions of the PUCCH can be extended. That is, the repeated transmissions of the PUCCH are extended forward, resulting in a PUCCH start time domain position that is the same as the corresponding start time domain position of the PUSCH.

[0179] In performing the above operations, terminal 101 needs to determine that the time-domain reference point meets specified conditions. These specified conditions include at least one of the following: the time interval between the uplink scheduling grant (UL grant) and the time-domain reference point must exceed the preparation time of the PUCCH and PUSCH; if the PUCCH carries a HARQ-ACK, then the time interval between the PDSCH associated with the HARQ-ACK and the time-domain reference point must be greater than both the PDSCH decoding time and the PUCCH preparation time.

[0180] The aforementioned time-domain reference point is the starting time-domain position of the OCC group where the overlap occurs, or the time-domain reference is the starting time-domain position corresponding to all PUSCH repetitions (that is, the starting time-domain position corresponding to the first PUSCH repetition).

[0181] Optionally, the aforementioned uplink scheduling grant (UL grant) is used to schedule the aforementioned PUSCH.

[0182] Optionally, the aforementioned uplink scheduling authorization can be statically or semi-statically configured (e.g., static or semi-static configuration information), or dynamically scheduled (e.g., DCI).

[0183] In some embodiments, it is permissible for the configured start time domain position of the PUCCH to differ from the start time domain position of the PUSCH. If the time domain reference point does not meet the conditions specified above, this can be considered an error case, and the PUCCH transmission will be cancelled.

[0184] In some embodiments, it is permissible for the configured start time domain position of the PUCCH to differ from that of the PUSCH. To ensure that the actual start time domain position of the transmitted PUCCH is the same as the corresponding start time domain position of the PUSCH, the first OCC group is determined to be the next adjacent OCC group to which the overlap occurs. That is, when the configured start time domain position of the PUCCH differs from that of the PUSCH, the transmission of the PUCCH is delayed until the next OCC group. For the currently overlapping OCC group, the PUSCH is still repeatedly transmitted, and then the PUCCH and PUSCH, based on OCC multiplexing, are repeatedly transmitted again in the next OCC group.

[0185] As an example, as shown in Figure 2B, timeline 2 in the figure represents the time interval between the uplink scheduling grant (UL grant) and the time-domain reference point. Timeline 1 in the figure represents the time interval between the PUCCH carrying the HARQ-ACK and the PDSCH associated with the HARQ-ACK, and the time-domain reference point.

[0186] In some embodiments, it is also permissible for the configured start time domain position of the PUCCH to differ from the start time domain position of the PUSCH. In this case, the PUCCH transmission is cancelled.

[0187] In some embodiments, the terms “eNB”, “gNB”, “base station”, and “NG-RAN node” can be used interchangeably.

[0188] In some embodiments, the terms "carrier," "band," and "frequency" can be used interchangeably.

[0189] In some embodiments, the names of information, etc., are not limited to the names described in the embodiments. Terms such as "information", "message", "signal", "signaling", "report", "configuration", "indication", "instruction", "command", "channel", "parameter", "domain", "field", "symbol", "symbol", "codepoint", "bit", "data", "program", and "chip" can be used interchangeably.

[0190] In some embodiments, the terms "uplink", "uplink", and "physical uplink" can be used interchangeably, as can the terms "downlink", "downlink", and "physical downlink", as well as the terms "sidelink", "sidelink", "sidelink communication", "sidelink communication", "direct connection", "direct link", "direct communication", and "direct link communication".

[0191] In some embodiments, the terms “downlink control information (DCI),” “downlink (DL) assignment,” “DL DCI,” “uplink (UL) grant,” and “UL DCI” can be used interchangeably.

[0192] In some embodiments, terms such as "physical downlink shared channel (PDSCH)" and "DL data" can be used interchangeably, as can terms such as "physical uplink shared channel (PUSCH)" and "UL data".

[0193] In some embodiments, the terms “radio”, “wireless”, “radio access network (RAN)”, “access network (AN)”, and “RAN-based” can be used interchangeably.

[0194] In some embodiments, the terms "search space", "search space set", "search space configuration", "search space set configuration", "control resource set (CORESET)", and "CORESET configuration" can be used interchangeably.

[0195] In some embodiments, the terms "synchronization signal (SS)," "synchronization signal block (SSB)," "reference signal (RS)," "pilot," and "pilot signal" can be used interchangeably.

[0196] In some embodiments, the terms "precoding", "precoder", "weight", "precoding weight", "quasi-co-location (QCL)", "transmission configuration indication (TCI) status", "spatial relation", "spatial domain filter", "transmission power", "phase rotation", "antenna port", "antenna port group", "layer", "the number of layers", "rank", "resource", "resource set", "resource group", "beam", "beam width", "beam angular degree", "antenna", "antenna element", and "panel" can be used interchangeably.

[0197] In some embodiments, terms such as “moment,” “point in time,” “time,” and “time location” can be used interchangeably, as can terms such as “duration,” “segment,” “time window,” “window,” and “time.”

[0198] In some embodiments, the terms "component carrier (CC)," "cell," "frequency carrier," and "carrier frequency" can be used interchangeably.

[0199] In some embodiments, terms such as wireless access scheme and waveform can be used interchangeably.

[0200] In some embodiments, the terms “frame”, “radio frame”, “subframe”, “slot”, “sub-slot”, “mini-slot”, “symbol”, “symbol”, and “transmission time interval (TTI)” can be used interchangeably.

[0201] In some embodiments, "acquire," "get," "obtain," "receive," "transmit," "bidirectional transmission," and "send and / or receive" can be used interchangeably and can be interpreted as receiving from other entities, acquiring from protocols, acquiring from higher layers, obtaining through self-processing, or autonomous implementation. Protocols include, for example, at least one of the 3GPP protocol, Wi-Fi protocol, and audio and / or video protocols.

[0202] In some embodiments, terms such as “send,” “transmit,” “report,” “distribute,” “transfer,” “bidirectional transmission,” “send and / or receive” can be used interchangeably.

[0203] In some embodiments, terms such as "certain," "preset," "default," "set," "indicated," "a certain," "any," and "first" can be used interchangeably. "Certain A," "preset A," "default A," "set A," "indicated A," "a certain A," "any A," and "first A" can be interpreted as A pre-defined in a protocol or the like, or as A obtained through setting, configuration, or instruction, or as specific A, a certain A, any A, or first A, but are not limited thereto.

[0204] In some embodiments, the determination or judgment can be made by a value represented by 1 bit (0 or 1), or by a true or false value (boolean), or by a comparison of numerical values ​​(e.g., a comparison with a predetermined value), but is not limited thereto.

[0205] In some embodiments, "not expecting to receive" can be interpreted as not receiving on time domain resources and / or frequency domain resources, or as not performing subsequent processing on the data and / or instructions received; "not expecting to send" can be interpreted as not sending, or as sending but not expecting the receiver to respond to the sent content.

[0206] In some embodiments, if an arrow in the interaction diagram representing the sending of information, signaling, etc. from one subject to another passes through other subjects, it can be interpreted as the information being forwarded from one subject to another via other subjects, or it can be interpreted as the information being sent from one subject to another without passing through other subjects.

[0207] The information transmission method involved in the embodiments of this application may include at least one of steps S2101 to S2103. For example, step S2101 may be implemented as an independent embodiment, step S2102 may be implemented as an independent embodiment, step S2103 may be implemented as an independent embodiment, step S2101+S2102 may be implemented as an independent embodiment, step S2101+S2103 may be implemented as an independent embodiment, step S2102+S2103 may be implemented as an independent embodiment, and so on, but not limited thereto.

[0208] In some embodiments, steps S2101 and S2102 are optional and may be omitted or substituted in different embodiments.

[0209] In some embodiments, other alternative implementations may be described before or after the specification corresponding to FIG2A.

[0210] Figure 3A is an interactive schematic diagram of an information sending method according to an embodiment of this application. As shown in Figure 3A, this application embodiment relates to an information sending method, which includes:

[0211] Step S3101: Terminal 101 repeatedly sends PUSCH based on OCC multiplexing.

[0212] In step S3102, terminal 101 repeatedly sends PUCCH.

[0213] In step S3103, terminal 101 determines that the above-mentioned PUCCH and the above-mentioned PUSCH overlap in the time domain and performs the first operation.

[0214] In some embodiments, the priority of the PUSCH is the same as the priority of the PUCCH; the first operation is to cancel sending the PUCCH.

[0215] In some embodiments, the first operation described above is:

[0216] The above-mentioned PUCCH based on OCC multiplexing is repeatedly transmitted on the first OCC group, and the above-mentioned PUCCH and the above-mentioned PUSCH on the first OCC group cover the same OCC sequence value;

[0217] Cancel sending the aforementioned PUSCH on the first OCC group; or, cancel sending all of the aforementioned PUSCH.

[0218] Wherein, the first OCC group is the OCC group in which the overlap is located, or the first OCC group is the next adjacent OCC group in which the overlap is located;

[0219] The PUSCH transmitted repeatedly on the aforementioned OCC group covers the same value in the OCC sequence.

[0220] In some embodiments, the first operation described above is:

[0221] On the first OCC group, the above-mentioned PUCCH and PUSCH based on OCC multiplexing are repeatedly transmitted, and the above-mentioned PUCCH and PUSCH cover the same OCC sequence value;

[0222] Wherein, the first OCC group is the OCC group in which the overlap is located, or the first OCC group is the next adjacent OCC group in which the overlap is located;

[0223] The PUSCH transmitted repeatedly on the aforementioned OCC group covers the same value in the OCC sequence.

[0224] In some embodiments, the actual number of times the above-mentioned PUCCH is repeatedly transmitted is the same as the OCC length corresponding to the above-mentioned terminal; or,

[0225] The actual number of times the above-mentioned PUCCH was repeatedly sent was the same as the number of times the above-mentioned PUSCH was repeatedly sent.

[0226] In some embodiments, the number of repeated transmissions of the configured PUCCH is different from the OCC length corresponding to the terminal; the method further includes:

[0227] The repeated transmission of the above PUCCH is handled;

[0228] Wherein, the actual number of repeated transmissions of the processed PUCCH is the same as the OCC length corresponding to the terminal; or...

[0229] The actual number of times the PUCCH is retransmitted after processing is the same as the number of times the PUSCH is retransmitted.

[0230] In some embodiments, the number of times the PUCCH is retransmitted is determined to be the same as the OCC length corresponding to the terminal; or,

[0231] The aforementioned terminal does not expect the number of times the aforementioned PUCCH is repeatedly transmitted to be different from the length of the corresponding OCC of the aforementioned terminal.

[0232] In some embodiments, the starting time domain position of the PUCCH actually transmitted is the same as the starting time domain position corresponding to the PUSCH.

[0233] In some embodiments, the starting time domain position of the configured PUCCH is the same as the starting time domain position corresponding to the PUSCH; or,

[0234] The aforementioned terminal does not expect the starting time domain position of the aforementioned PUCCH to be different from the starting time domain position corresponding to the aforementioned PUSCH.

[0235] In some embodiments, the starting time domain position of the configured PUCCH is different from the starting time domain position corresponding to the PUSCH; the method further includes:

[0236] If the time-domain reference point meets the specified conditions, perform extended processing on the repeated transmission of the above PUCCH.

[0237] The starting time domain position of the processed PUCCH is the same as the starting time domain position of the PUSCH.

[0238] The aforementioned time-domain reference point is the starting time-domain position of the OCC group where the aforementioned overlap occurs, or the aforementioned time-domain reference is the starting time-domain position of the aforementioned PUSCH.

[0239] In some embodiments, the starting time domain position of the configured PUCCH is different from the starting time domain position corresponding to the PUSCH; the method further includes:

[0240] If the time-domain reference point does not meet the specified conditions, cancel the transmission of the above PUCCH.

[0241] Wherein, the aforementioned time-domain reference point is the starting time-domain position of the OCC group in which the aforementioned overlap occurs, or the aforementioned time-domain reference is the starting time-domain position of the aforementioned PUSCH.

[0242] In some embodiments, the starting time domain position of the configured PUCCH is different from the starting time domain position corresponding to the PUSCH.

[0243] The first OCC group mentioned above is the next adjacent OCC group of the OCC group where the overlap is located, and the starting time domain position of the PUCCH actually transmitted is the same as the starting time domain position of the first OCC group mentioned above.

[0244] In some embodiments, the starting time domain position of the configured PUCCH is different from the starting time domain position corresponding to the PUSCH; the method further includes:

[0245] Cancel sending the above PUCCH.

[0246] In some embodiments, the time-domain reference point meets specified conditions;

[0247] The aforementioned time-domain reference point is the starting time-domain position of the OCC group where the aforementioned overlap occurs, or the aforementioned time-domain reference is the starting time-domain position of the aforementioned PUSCH.

[0248] The specified conditions mentioned above include at least one of the following:

[0249] The time interval between the uplink scheduling authorization and the aforementioned time domain reference point exceeds the preparation time of the aforementioned PUCCH and PUSCH.

[0250] The aforementioned PUCCH carries a Hybrid Automatic Repeat Request Acknowledgment (HARQ-ACK), and the time interval between the Physical Downlink Shared Channel (PDSCH) associated with the aforementioned HARQ-ACK and the aforementioned time domain reference point exceeds the decoding time of the aforementioned PDSCH, as well as the preparation time of the aforementioned PUCCH and the aforementioned PUSCH.

[0251] In some embodiments, the steps and their optional implementations in other embodiments described before or after this embodiment, as well as other related parts in the specification, can be referred to, and will not be repeated here.

[0252] Figure 3B is an interactive schematic diagram of an information sending method according to an embodiment of this application. As shown in Figure 3B, this application embodiment relates to an information sending method, which includes:

[0253] Step S3201: Terminal 101 repeatedly sends PUSCH based on OCC multiplexing.

[0254] In step S3202, terminal 101 repeatedly sends PUCCH.

[0255] In step S3203, terminal 101 determines that the above PUCCH and the above PUSCH overlap in the time domain and cancels the transmission of the above PUCCH.

[0256] In some embodiments, the PUSCH and PUCCH have the same priority, and terminal 101 cancels the transmission of the PUCCH.

[0257] That is, in some embodiments, for PUSCH and PUCCH with the same priority, there is a time-domain overlap in the transmission of PUSCH and PUCCH. The transmission of PUCCH repetition is canceled (dropped) to ensure the transmission of PUSCH repetition.

[0258] Optionally, the priority information of PUSCH and PUCCH mentioned above can be pre-configured by network device 102.

[0259] In some embodiments, the steps and their optional implementations in other embodiments described before or after this embodiment, as well as other related parts in the specification, can be referred to, and will not be repeated here.

[0260] Figure 3C is an interactive schematic diagram of an information sending method according to an embodiment of this application. As shown in Figure 3C, this application embodiment relates to an information sending method, which includes:

[0261] Step S3301: Terminal 101 repeatedly sends PUSCH based on OCC multiplexing.

[0262] In step S3302, terminal 101 repeatedly sends PUCCH.

[0263] In step S3303, terminal 101 determines that the above PUCCH and the above PUSCH overlap in the time domain and cancels the transmission of the above PUSCH.

[0264] In some embodiments, terminal 101 cancels the transmission of the above-mentioned PUSCH, and further performs OCC code covering processing on the transmitted PUCCH, and retransmits the OCC-multiplexed PUCCH to network device 102.

[0265] The OCC sequence value (or OCC code) covered by the above PUCCH is the same as the PUSCH that was originally to be sent on that time domain resource.

[0266] In some embodiments, terminal 101 repeatedly transmits the above-mentioned PUCCH based on OCC multiplexing on the first OCC group, the PUCCH covering the same OCC sequence value as the PUSCH originally to be transmitted on the first OCC group.

[0267] In some embodiments, terminal 101 cancels the transmission of PUSCH on the first OCC group.

[0268] In some embodiments, terminal 101 may also cancel sending all PUSCH repetitions.

[0269] Optionally, the first OCC group mentioned above can be the OCC group in which the aforementioned overlap occurs.

[0270] Optionally, the first OCC group mentioned above can also be the next adjacent OCC group of the OCC group where the overlap occurs. That is, for the OCC group where the current overlap occurs, the PUSCH based on OCC multiplexing is normally retransmitted (this can be understood as the case where the PUSCH on the first OCC group is canceled).

[0271] It should be noted that repeated PUSCH transmissions on the same OCC group cover the same OCC sequence value. For example, as shown in Figure 2B, one PUSCH repetition occupies one time slot. The four PUSCH repetitions in Figure 2B (PUSCH with 4 repetitions) cover the same OCC sequence value, and these four repetitions constitute one OCC group.

[0272] In some embodiments, when terminal 101 performs the operation of canceling the sending of the above-mentioned PUSCH, the timeline also needs to meet at least one of the following:

[0273] The time interval between the uplink scheduling grant (UL grant) and the earliest overlapping PUSCH / PUCCH channel must exceed the preparation time of PUCCH and PUSCH.

[0274] If the PUCCH carries a Hybrid Automatic Repeat Request Acknowledgment (HARQ-ACK), then the time interval between the Physical Downlink Shared Channel (PDSCH) associated with the HARQ-ACK and the earliest overlapping PUSCH / PUCCH channel must be greater than both the PDSCH decoding time and the PUCCH preparation time.

[0275] The earliest overlapping PUSCH / PUCCH channel mentioned above refers to the time slot where the PUCCH that terminal 101 is actually preparing to send overlaps with the PUSCH mentioned above.

[0276] Optionally, the aforementioned uplink scheduling grant (UL grant) is used to schedule the aforementioned PUSCH.

[0277] Optionally, the aforementioned uplink scheduling authorization can be statically or semi-statically configured (e.g., static or semi-static configuration information), or dynamically scheduled (e.g., downlink control information (DCI)).

[0278] In some embodiments, when terminal 101 performs the operation of canceling the transmission of the above-mentioned PUSCH, the actual number of times the above-mentioned PUSCH is repeatedly transmitted needs to be the same as the OCC length of the above-mentioned PUSCH (that is, the OCC length corresponding to terminal 101).

[0279] In some embodiments, the terminal 101 performs the operation of canceling the transmission of the PUSCH, and the actual number of times the PUSCH is repeatedly transmitted is the same as the number of times the PUSCH is repeatedly transmitted.

[0280] It is understandable that the actual number of PUCCH retransmissions may be the same as or different from the number of PUCCH retransmissions configured / indicated by network device 102. The actual number of retransmissions can be adjusted based on scheduling.

[0281] In some embodiments, in order to ensure that the actual number of times the PUCCH is retransmitted is the same as the OCC length / PUSCH retransmission number corresponding to terminal 101, the configured number of times the PUCCH is retransmitted may be the same as the OCC length corresponding to the terminal; or, terminal 101 may not expect the number of times the PUCCH is retransmitted to be different from the OCC length corresponding to terminal 101.

[0282] In some embodiments, it is permissible for the configured number of PUCCH retransmissions to differ from the OCC length corresponding to the terminal. To ensure that the actual number of PUCCH retransmissions is the same as the OCC length / retransmission count of the PUSCH, the terminal 101 can perform corresponding processing on the retransmission of the PUCCH; wherein, the processed actual number of PUCCH retransmissions is the same as the OCC length / retransmission count of the PUSCH corresponding to the terminal 101.

[0283] Optionally, if the OCC length corresponding to terminal 101 is greater than the configured number of PUCCH repetitions, further spreading of the PUCCH repetitions can be considered. After spreading, the actual number of times the PUCCH is repeatedly sent is the OCC length / the number of PUCCH repetitions.

[0284] Optionally, if the OCC length corresponding to terminal 101 is less than the configured number of PUCCH repetitions, consider reducing the number of PUCCH repetitions. After the reduction, the actual number of times PUCCH is sent repeatedly is OCC length / number of PUCCH repetitions.

[0285] In some embodiments, when terminal 101 performs the operation of canceling the transmission of the PUSCH, the starting time domain position of the actually transmitted PUSCH must be the same as the corresponding starting time domain position of the PUSCH.

[0286] It is understandable that the starting time domain position of the actual PUCCH transmission is defined independently of the starting time domain position of the PUCCH configured / indicated by network device 102. They can be the same or different, depending on the scheduling of network device 102. The starting time domain position of the actual transmission can be adjusted based on the scheduling.

[0287] Optionally, the above-mentioned starting time domain position refers to the time domain position when the first repeated transmission is performed (which may be the time slot corresponding to the channel of the first repeated transmission, or the starting subframe position corresponding to the channel of the first repeated transmission).

[0288] Optionally, the temporal resource unit of the aforementioned starting temporal position can be a slot or a subframe, and there is no limitation on this.

[0289] In some embodiments, in order to ensure that the starting time domain position of the actually transmitted PUCCH is the same as the corresponding starting time domain position of the PUSCH, the starting time domain position of the configured PUCCH may be determined to be the same as the starting time domain position of the PUSCH; or, the terminal 101 does not expect the starting time domain position of the configured PUCCH to be different from the starting time domain position of the PUSCH.

[0290] In some embodiments, it is permissible for the configured start time domain position of the PUCCH to differ from that of the PUSCH. To ensure that the actual start time domain position of the transmitted PUCCH is the same as the corresponding start time domain position of the PUSCH, repeated transmissions of the PUCCH can be extended. That is, the repeated transmissions of the PUCCH are extended forward, resulting in a PUCCH start time domain position that is the same as the corresponding start time domain position of the PUSCH.

[0291] In performing the above operations, terminal 101 needs to determine that the time-domain reference point meets specified conditions. These specified conditions include at least one of the following: the time interval between the uplink scheduling grant (UL grant) and the time-domain reference point must exceed the preparation time of the PUCCH and PUSCH; if the PUCCH carries a HARQ-ACK, then the time interval between the PDSCH associated with the HARQ-ACK and the time-domain reference point must be greater than both the PDSCH decoding time and the PUCCH preparation time.

[0292] The aforementioned time-domain reference point is the starting time-domain position of the OCC group where the overlap occurs, or the time-domain reference is the starting time-domain position corresponding to all PUSCH repetitions (that is, the starting time-domain position corresponding to the first PUSCH repetition).

[0293] Optionally, the aforementioned uplink scheduling grant (UL grant) is used to schedule the aforementioned PUSCH.

[0294] Optionally, the aforementioned uplink scheduling authorization can be statically or semi-statically configured (e.g., static or semi-static configuration information), or dynamically scheduled (e.g., DCI).

[0295] As an example, as shown in Figure 2B, timeline 2 in the figure represents the time interval between the uplink scheduling grant (UL grant) and the time-domain reference point. Timeline 1 in the figure represents the time interval between the PUCCH carrying the HARQ-ACK and the PDSCH associated with the HARQ-ACK, and the time-domain reference point.

[0296] In some embodiments, it is permissible for the configured start time domain position of the PUCCH to differ from the start time domain position of the PUSCH. If the time domain reference point does not meet the conditions specified above, this can be considered an error case, and the PUCCH transmission will be cancelled.

[0297] In some embodiments, it is permissible for the configured start time domain position of the PUCCH to differ from that of the PUSCH. To ensure that the actual start time domain position of the transmitted PUCCH is the same as the corresponding start time domain position of the PUSCH, the first OCC group is determined to be the next adjacent OCC group to which the overlap occurs. That is, when the configured start time domain position of the PUCCH differs from that of the PUSCH, the transmission of the PUCCH is delayed until the next OCC group. For the currently overlapping OCC group, the PUSCH is still repeatedly transmitted, and this retransmission is canceled and the PUCCH is retransmitted only in the next OCC group.

[0298] In some embodiments, it is also permissible for the configured start time domain position of the PUCCH to differ from the start time domain position of the PUSCH. In this case, the PUCCH transmission is cancelled.

[0299] In some embodiments, the steps and their optional implementations in other embodiments described before or after this embodiment, as well as other related parts in the specification, can be referred to, and will not be repeated here.

[0300] Figure 3D is an interactive schematic diagram of an information sending method according to an embodiment of this application. As shown in Figure 3D, the embodiment of this application relates to an information sending method, which includes:

[0301] Step S3401: Terminal 101 repeatedly sends PUSCH based on OCC multiplexing.

[0302] In step S3402, terminal 101 repeatedly sends PUCCH.

[0303] In step S3403, terminal 101 determines that the above PUCCH and the above PUSCH overlap in the time domain, and repeatedly transmits PUCCH and PUSCH based on OCC multiplexing.

[0304] The OCC sequence value (or OCC code) covered by the above PUCCH is the same as that of the above PUSCH.

[0305] In some embodiments, terminal 101 repeatedly transmits the above-mentioned OCC-based multiplexed PUCCH and PUSCH on the first OCC group, wherein the PUCCH and PUSCH cover the same OCC sequence value, and the PUCCH and PUSCH are multiplexed at the modulation symbol level.

[0306] Optionally, the first OCC group mentioned above can be the OCC group in which the aforementioned overlap occurs.

[0307] Optionally, the first OCC group mentioned above can also be the next adjacent OCC group of the OCC group where the overlap occurs. That is, for the currently overlapping OCC group, PUSCH based on OCC multiplexing is transmitted normally.

[0308] It should be noted that repeated PUSCH transmissions on the same OCC group cover the same OCC sequence value. For example, as shown in Figure 2B, one PUSCH repetition occupies one time slot. The four PUSCH repetitions in Figure 2B (PUSCH with 4 repetitions) cover the same OCC sequence value, and these four repetitions constitute one OCC group.

[0309] In some embodiments, when terminal 101 performs the operation of canceling the sending of the above-mentioned PUSCH, the timeline also needs to meet at least one of the following:

[0310] The time interval between the uplink scheduling grant (UL grant) and the earliest overlapping PUSCH / PUCCH channel must exceed the preparation time of PUCCH and PUSCH;

[0311] If the PUCCH carries a HARQ-ACK, then the time interval between the PDSCH associated with the HARQ-ACK and the earliest overlapping PUSCH / PUCCH channel must be greater than both the PDSCH decoding time and the PUCCH preparation time.

[0312] The earliest overlapping PUSCH / PUCCH channel mentioned above refers to the time slot where the PUCCH that terminal 101 is actually preparing to send overlaps with the PUSCH mentioned above.

[0313] Optionally, the aforementioned uplink scheduling grant (UL grant) is used to schedule the aforementioned PUSCH.

[0314] Optionally, the aforementioned uplink scheduling authorization can be statically or semi-statically configured (e.g., static or semi-static configuration information), or dynamically scheduled (e.g., downlink control information (DCI)).

[0315] In some embodiments, when terminal 101 performs the above operation, the actual number of times the PUCCH is repeatedly transmitted needs to be the same as the OCC length of the PUSCH (that is, the OCC length corresponding to terminal 101).

[0316] In some embodiments, when terminal 101 performs the above operation, the actual number of times the PUCCH is repeatedly transmitted needs to be the same as the number of times the PUSCH is repeatedly transmitted.

[0317] It is understandable that the actual number of PUCCH retransmissions may be the same as or different from the number of PUCCH retransmissions configured / indicated by network device 102. The actual number of retransmissions can be adjusted based on scheduling.

[0318] In some embodiments, in order to ensure that the actual number of times the PUCCH is retransmitted is the same as the OCC length / PUSCH retransmission number corresponding to terminal 101, the configured number of times the PUCCH is retransmitted may be the same as the OCC length corresponding to the terminal; or, terminal 101 may not expect the number of times the PUCCH is retransmitted to be different from the OCC length corresponding to terminal 101.

[0319] In some embodiments, it is permissible for the configured number of PUCCH retransmissions to differ from the OCC length corresponding to the terminal. To ensure that the actual number of PUCCH retransmissions is the same as the OCC length / retransmission count of the PUSCH, the terminal 101 can perform corresponding processing on the retransmission of the PUCCH; wherein, the processed actual number of PUCCH retransmissions is the same as the OCC length / retransmission count of the PUSCH corresponding to the terminal 101.

[0320] Optionally, if the OCC length corresponding to terminal 101 is greater than the configured number of PUCCH repetitions, further spreading of the PUCCH repetitions can be considered. After spreading, the actual number of times the PUCCH is repeatedly sent is the OCC length / the number of PUCCH repetitions.

[0321] Optionally, if the OCC length corresponding to terminal 101 is less than the configured number of PUCCH repetitions, consider reducing the number of PUCCH repetitions. After the reduction, the actual number of times PUCCH is sent repeatedly is OCC length / number of PUCCH repetitions.

[0322] In some embodiments, when terminal 101 performs the operation of canceling the transmission of the PUSCH, the starting time domain position of the actually transmitted PUSCH must be the same as the corresponding starting time domain position of the PUSCH.

[0323] It is understandable that the starting time domain position of the actual PUCCH transmission is defined independently of the starting time domain position of the PUCCH configured / indicated by network device 102. They can be the same or different, depending on the scheduling of network device 102. The starting time domain position of the actual transmission can be adjusted based on the scheduling.

[0324] Optionally, the above-mentioned starting time domain position refers to the time domain position when the first repeated transmission is performed (which may be the time slot corresponding to the channel of the first repeated transmission, or the starting subframe position corresponding to the channel of the first repeated transmission).

[0325] Optionally, the temporal resource unit of the aforementioned starting temporal position can be a slot or a subframe, and there is no limitation on this.

[0326] In some embodiments, in order to ensure that the starting time domain position of the actually transmitted PUCCH is the same as the corresponding starting time domain position of the PUSCH, the starting time domain position of the configured PUCCH may be determined to be the same as the starting time domain position of the PUSCH; or, the terminal 101 does not expect the starting time domain position of the configured PUCCH to be different from the starting time domain position of the PUSCH.

[0327] In some embodiments, it is permissible for the configured start time domain position of the PUCCH to differ from that of the PUSCH. To ensure that the actual start time domain position of the transmitted PUCCH is the same as the corresponding start time domain position of the PUSCH, repeated transmissions of the PUCCH can be extended. That is, the repeated transmissions of the PUCCH are extended forward, resulting in a PUCCH start time domain position that is the same as the corresponding start time domain position of the PUSCH.

[0328] In performing the above operations, terminal 101 needs to determine that the time-domain reference point meets specified conditions. These specified conditions include at least one of the following: the time interval between the uplink scheduling grant (UL grant) and the time-domain reference point must exceed the preparation time of the PUCCH and PUSCH; if the PUCCH carries a HARQ-ACK, then the time interval between the PDSCH associated with the HARQ-ACK and the time-domain reference point must be greater than both the PDSCH decoding time and the PUCCH preparation time.

[0329] The aforementioned time-domain reference point is the starting time-domain position of the OCC group where the overlap occurs, or the time-domain reference is the starting time-domain position corresponding to all PUSCH repetitions (that is, the starting time-domain position corresponding to the first PUSCH repetition).

[0330] Optionally, the aforementioned uplink scheduling grant (UL grant) is used to schedule the aforementioned PUSCH.

[0331] Optionally, the aforementioned uplink scheduling authorization can be statically or semi-statically configured (e.g., static or semi-static configuration information), or dynamically scheduled (e.g., DCI).

[0332] In some embodiments, it is permissible for the configured start time domain position of the PUCCH to differ from the start time domain position of the PUSCH. If the time domain reference point does not meet the conditions specified above, this can be considered an error case, and the PUCCH transmission will be cancelled.

[0333] In some embodiments, it is permissible for the configured start time domain position of the PUCCH to differ from that of the PUSCH. To ensure that the actual start time domain position of the transmitted PUCCH is the same as the corresponding start time domain position of the PUSCH, the first OCC group is determined to be the next adjacent OCC group to which the overlap occurs. That is, when the configured start time domain position of the PUCCH differs from that of the PUSCH, the transmission of the PUCCH is delayed until the next OCC group. For the currently overlapping OCC group, the PUSCH is still repeatedly transmitted, and then the PUCCH and PUSCH, based on OCC multiplexing, are repeatedly transmitted again in the next OCC group.

[0334] As an example, as shown in Figure 2B, timeline 2 in the figure represents the time interval between the uplink scheduling grant (UL grant) and the time-domain reference point. Timeline 1 in the figure represents the time interval between the PUCCH carrying the HARQ-ACK and the PDSCH associated with the HARQ-ACK, and the time-domain reference point.

[0335] In some embodiments, it is also permissible for the configured start time domain position of the PUCCH to differ from the start time domain position of the PUSCH. In this case, the PUCCH transmission is cancelled.

[0336] In some embodiments, the steps and their optional implementations in other embodiments described before or after this embodiment, as well as other related parts in the specification, can be referred to, and will not be repeated here.

[0337] The following is an exemplary description of the methods described in the above embodiments.

[0338] In some embodiments, when PUCCH repetition occurs during inter-slot OCC multiplexing PUSCH transmission, some implementation guidelines require dropping the PUSCH transmission and performing PUCCH repetition transmission while meeting timeline requirements. Based on this, it is necessary to consider how to guarantee the orthogonality of multi-user OCC multiplexing.

[0339] Key Point 1: For handling the overlap between PUSCH repetition and PUCCH repetition with OCC multiplexing enabled, at least one of the following designs can be considered:

[0340] In some embodiments, Direction 1: For PUCCH repetitions and PUSCH repetitions with the same priority, ensure that the PUSCH repetition is transmitted first and cancel (drop) the PUCCH repetition.

[0341] In some embodiments, Direction 2: Based on meeting the timeline requirements, prioritize the transmission of PUCCH repetitions and drop the transmission of PUSCH repetitions for inter-slot OCC multiplexing, wherein the timeline requirements are as described in point 4.

[0342] Based on this, the PUCCH repetition to be transmitted is covered with OCC code, which is the same as the OCC code of the PUSCH repetition.

[0343] The transmission of the drop PUSCH repetition includes at least one of the following methods:

[0344] Optionally, Option 1: Drop the transmission of the PUSCH repetition within the current OCC Group where overlapping occurs;

[0345] Optionally, Option 2: Drop all PUSCH repetition transfers.

[0346] In some embodiments, Direction 3: performs multiplexing between PUCCH repetition and PUSCH repetition, wherein the UCI information carried by PUCCH covers the same OCC code as the PUSCH repetition.

[0347] Point 2: For Direction 2 and Direction 3 in Point 1, consider at least one of the following designs to ensure that the actual number of repetitions of PUCCH transmission is aligned with the PUSCH OCC length:

[0348] In some embodiments, Option 1 for Directions 2 & 3: The number of PUCCH retransmissions is inconsistent with the PUSCH OCC length, specifically considering the following design:

[0349] Optionally, if the OCC length is greater than the number of PUCCH repetitions, consider further spreading the PUCCH repetitions. After spreading, the number of PUCCH transmissions will be OCC length / number of PUCCH repetitions.

[0350] Optionally, if the OCC length is less than the number of PUCCH repetitions, consider reducing the PUCCH repetitions. The number of PUCCH reductions is equal to the number of PUSCH repetitions / OCC length.

[0351] In some embodiments, Option 2 for Directions 2 & 3: The terminal does not expect the number of PUCCH retransmissions to be inconsistent with the PUSCH OCC length. Alternatively, the number of PUCCH retransmissions is guaranteed to be consistent with the PUSCH OCC length based on network configuration / scheduling.

[0352] Key Point 3: Based on Key Point 1, the determination of the starting transmission position of the actual first PUCCH repetition should consider at least one of the following methods:

[0353] It should be noted that the definition of the actual starting transmission position mentioned above is independent of the definition of the starting transmission position of the PUCCH configured / indicated by the base station. The two may be equal or unequal, depending on the actual scheduling of the gNB.

[0354] Method 1: The terminal does not expect the time domain position (e.g., time slot position or subframe position) of the first transmission of PUCCH repetition to be different from that of the first transmission of PUSCH repetition. Alternatively, the network configuration / scheduling ensures that the first transmission of PUCCH repetition is consistent with the time domain position of the first transmission of PUSCH repetition.

[0355] Method 2: Allow the starting position of the first repetition of PUCCH to be different from the starting position of the first repetition of PUSCH. In this case, PUCCH can be spread forward until the PUSCH repetition resources are fully occupied. In this method, it is necessary to ensure that the timeline requirements described in point 4 are met between the first reference point and the scheduling DCI, where the first reference point is the starting position of the first PUSCH repetition within this OCC group / all PUSCH repetitions.

[0356] Alternatively, consider delaying the transmission of the PUCCH repetition to the next OCC Group. Specifically, use the time-domain position of the first PUSCH repetition within the next OCC Group as the time-domain position of the first PUCCH repetition.

[0357] For the case of PUCCH repetition transmission based on delays to the next OCC Group in the above methods, for Direction 2 in Point 1, the current OCC Group still performs PUSCH repetition transmission, and the PUSCH repetition transmission in the next OCC Group undergoes a drop operation. Furthermore, the PUCCH repetition undergoes OCC multiplexing processing based on at least one of Points 1 and 2. For Direction 3 in Point 1, the current OCC Group still performs PUSCH repetition transmission, and in the next OCC Group, UCI multiplexing operations are performed with the PUSCH repetition based on at least one of Points 1 and 2. Simultaneously, OCC code covering is applied to the UCI of the PUCCH repetition transmission.

[0358] Method 3: Allow the starting position of the first repetition of PUCCH to be different from the starting position of the first repetition of PUSCH. In this case, simply drop the PUCCH repetition.

[0359] Method 4: Modify the reference point of the timeline requirement. Change the reference point from the overlapping slot to the first slot of PUSCH repetitions or the first slot of the overlapping OCC group. If the timeline requirement is met, perform PUCCH forward spreading (extend to the time domain position before the first overlapping slot). Otherwise, it is considered that the timeline requirement is not met and is regarded as an error case.

[0360] It should be noted that, in the embodiments of this application, OCC group refers to a temporal resource under an OCC code cover.

[0361] Key Point 4: The UCI multiplexing mechanism on PUSCH needs to meet the following timeline requirements:

[0362] The time interval between the uplink scheduling grant (UL grant) and the earliest overlapping PUSCH / PUCCH channel must exceed the preparation time of PUCCH and PUSCH.

[0363] If the PUCCH carries HARQ-ACK (Hybrid Automatic Repeat Request Acknowledgment), the time interval between the PDSCH (Physical Downlink Shared Channel) associated with the HARQ-ACK and the earliest overlapping PUSCH / PUCCH channel must be greater than both the PDSCH decoding time and the PUCCH preparation time.

[0364] In some embodiments, unless contradictory, the optional implementations in this embodiment can be implemented as independent embodiments, and the optional implementations in this embodiment can also be combined arbitrarily. The technical features of different feasible implementations in this embodiment can be combined to form new optional implementations based on their inherent logical relationships.

[0365] In some embodiments, the steps and their optional implementations in other embodiments described before or after this embodiment, as well as other related parts in the specification, can be referred to, and will not be repeated here.

[0366] This application also proposes an apparatus (also referred to as a communication device, etc.) for implementing any of the above methods. For example, an apparatus is proposed, which includes units or modules for implementing the steps performed by the terminal in any of the above methods. Furthermore, another apparatus is proposed, which includes units or modules for implementing the steps performed by a network device (e.g., an access network device, a core network functional node, a core network device, etc.) in any of the above methods.

[0367] It should be understood that the division of units or modules in the above device 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 or modules in the device can be implemented by a processor calling software: for example, the device 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 the units or modules in the above device. The processor can be, for example, a general-purpose processor, such as a Central Processing Unit (CPU) or a microprocessor, and the memory can be internal or external to the device. Alternatively, the units or modules in the device can be implemented in the form of hardware circuits. The functionality of some or all of the units or modules 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 units or modules 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 configuration files, thereby achieving the functionality of some or all of the units or modules. All units or modules of the above device can be implemented entirely through processor-called software, entirely through hardware circuits, or partially through processor-called software with the remaining parts implemented through hardware circuits.

[0368] In this application embodiment, the processor is a circuit with signal processing capabilities. In one implementation, the processor can be a circuit with instruction read and execute capabilities, such as a Central Processing Unit (CPU), a microprocessor, a graphics processing unit (GPU) (which can be understood as a microprocessor), or a digital signal processor (DSP). In another implementation, the processor can implement certain functions through the logical relationships of hardware circuits. The logical relationships of the aforementioned hardware circuits are fixed or reconfigurable. For example, the processor is a hardware circuit implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD), such as an FPGA. In a reconfigurable hardware circuit, the process of the processor loading a configuration document and configuring the hardware circuit can be understood as the process of the processor loading instructions to implement the functions of some or all of the above units or modules. Furthermore, it can also be a hardware circuit designed for artificial intelligence, which can be understood as an ASIC, such as a Neural Network Processing Unit (NPU), a Tensor Processing Unit (TPU), or a Deep Learning Processing Unit (DPU).

[0369] Figure 4A is a schematic diagram of the structure of a terminal according to an embodiment of this application. The terminal 4100 is used to execute any of the above methods. In some embodiments, as shown in Figure 4A, the terminal 4100 may include at least one of a transceiver module 4101, a processing module 4102, etc. In some embodiments, the transceiver module 4101 is used to repeatedly transmit the Physical Uplink Shared Channel (PUSCH) multiplexed based on Orthogonal Cover Code (OCC) to the network device; the transceiver module 4101 is also used to repeatedly transmit the Physical Uplink Control Channel (PUCCH) to the network device; the processing module 4102 is used to determine that the PUCCH and the PUSCH overlap in the time domain and perform a first operation. Optionally, the transceiver module is used to execute at least one of the communication steps (e.g., steps S2101, S2102, S3101, S3102, S3201, S3202, S3301, S3302, S3401, S3402, but not limited thereto) performed by the terminal 101 in any of the above methods, which will not be elaborated here. Optionally, the processing module is used to execute at least one of the other steps (e.g., steps S2103, S3103, S3203, S3303, S3403, but not limited thereto) performed by the terminal 101 in any of the above methods, which will not be elaborated here.

[0370] In some embodiments, the transceiver module may include a transmitting module and / or a receiving module, which may be separate or integrated. Optionally, the transceiver module may be interchangeable with a transceiver.

[0371] In some embodiments, the processing module may be a single module or may include multiple sub-modules. Optionally, the multiple sub-modules may each perform all or part of the steps required by the processing module.

[0372] In some embodiments, the processing module can be replaced by the processor, and the transceiver module can be replaced by the transceiver.

[0373] Figure 5A is a schematic diagram of the structure of the communication device 5100 proposed in an embodiment of this application. The communication device 5100 can be a network device (e.g., access network device, core network device, etc.), a terminal (e.g., user equipment, etc.), a chip, chip system, or processor that supports the network device in implementing any of the above methods, or a chip, chip system, or processor that supports the terminal in implementing any of the above methods. The communication device 5100 can be used to implement the methods described in the above method embodiments; for details, please refer to the descriptions in the above method embodiments.

[0374] As shown in Figure 5A, the communication device 5100 is used to execute any of the above methods. In some embodiments, the communication device 5100 includes one or more processors 5101. The processor 5101 may be a general-purpose processor or a special-purpose processor, such as a baseband processor or a central processing unit. The baseband processor may be used to process communication protocols and communication data, and the central processing unit may be used to control communication devices (e.g., base stations, baseband chips, terminal devices, terminal device chips, DUs or CUs, etc.), execute programs, and process program data. Optionally, the communication device 5100 is used to execute any of the above methods. Optionally, one or more processors 5101 are used to invoke instructions to cause the communication device 5100 to execute any of the above methods.

[0375] In some embodiments, the communication device 5100 further includes one or more transceivers 5102. When the communication device 5100 includes one or more transceivers 5102, the transceivers 5102 perform at least one of the communication steps such as sending and / or receiving in the above-described method (e.g., steps S2101, S2102, S3101, S3102, S3201, S3202, S3301, S3302, S3401, S3402, but not limited thereto), and the processor 5101 performs at least one of other steps (e.g., steps S2103, S3103, S3203, S3303, S3403, but not limited thereto). In optional embodiments, the transceivers may include a receiver and / or a transmitter, which may be separate or integrated together. Optionally, terms such as transceiver, transceiver unit, transceiver, transceiver circuit, interface circuit, and interface can be used interchangeably; terms such as transmitter, transmitter unit, transmitter, and transmitter circuit can be used interchangeably; and terms such as receiver, receiver unit, receiver, and receiver circuit can be used interchangeably.

[0376] In some embodiments, the communication device 5100 further includes one or more memories 5103 for storing data and / or instructions. Optionally, one or more processors 5101 are used to invoke instructions stored in the memory 5103 to cause the communication device 5100 to perform any of the above methods. Optionally, all or part of the memory 5103 may also be located outside the communication device 5100. In an optional embodiment, the communication device 5100 may include one or more interface circuits 5104. Optionally, the interface circuit 5104 is connected to the memory 5102 and can be used to receive data and / or instructions from the memory 5102 or other devices, and can be used to send data and / or instructions to the memory 5102 or other devices. For example, the interface circuit 5104 can read data and / or instructions stored in the memory 5102 and send the data and / or instructions to the processor 5101.

[0377] The communication device 5100 described in the above embodiments may be a network device or a terminal, but the scope of the communication device 5100 described in this application is not limited thereto, and the structure of the communication device 5100 may not be limited by FIG. 5A. The communication device may be a standalone device or a part of a larger device. For example, the communication device may be: (1) a standalone integrated circuit IC, or chip, or chip system or subsystem; (2) a collection of one or more ICs, optionally, the IC collection may also include storage components for storing data, programs and / or instructions; (3) an ASIC, such as a modem; (4) a module that can be embedded in other devices; (5) a receiver, terminal device, smart terminal device, cellular phone, wireless device, handheld device, mobile unit, vehicle device, network device, cloud device, artificial intelligence device, etc.; (6) others, etc.

[0378] Figure 5B is a schematic diagram of the structure of chip 5200 according to an embodiment of this application. For cases where the communication device 5100 can be a chip or a chip system, please refer to the schematic diagram of chip 5200 shown in Figure 5B, but it is not limited thereto.

[0379] Chip 5200 includes one or more processors 5201. Chip 5200 is used to perform any of the methods described above.

[0380] In some embodiments, chip 5200 further includes one or more interface circuits 5202. Optionally, terms such as interface circuit, interface, and transceiver pin can be used interchangeably. In some embodiments, chip 5200 further includes one or more memories 5203 for storing data and / or instructions. Optionally, all or part of the memories 5203 may be located outside of chip 5200. Optionally, the interface circuit 5202 is connected to the memories 5203, and the interface circuit 5202 can be used to receive data and / or instructions from the memories 5203 or other devices, and the interface circuit 5202 can be used to send data and / or instructions to the memories 5203 or other devices. For example, the interface circuit 5202 can read data and / or instructions stored in the memories 5203 and send the data and / or instructions to the processor 5201.

[0381] In some embodiments, the interface circuit 5202 performs at least one of the communication steps such as sending and / or receiving in the above-described method (e.g., steps S2101, S2102, S3101, S3102, S3201, S3202, S3301, S3302, S3401, S3402, but not limited thereto). The interface circuit 5202 performing the communication steps such as sending and / or receiving in the above-described method refers, for example, to the interface circuit 5202 performing data and / or instruction interaction between the processor 5201, chip 5200, memory 5203, or transceiver device. In some embodiments, the processor 5201 performs at least one of other steps (e.g., steps S2103, S3103, S3203, S3303, S3403, but not limited thereto).

[0382] The modules and / or devices described in the various embodiments, such as virtual devices, physical devices, and chips, can be combined or separated arbitrarily as needed. Optionally, some or all steps can also be performed collaboratively by multiple modules and / or devices, which is not limited here.

[0383] This application also proposes a storage medium storing instructions that, when executed on a communication device, cause the communication device to perform any of the above methods. Optionally, the storage medium is an electronic storage medium. Optionally, the storage medium is a computer-readable storage medium, but not limited thereto; it may also be a storage medium readable by other devices. Optionally, the storage medium may be a non-transitory storage medium, but not limited thereto; it may also be a temporary storage medium.

[0384] This application also proposes a program product, including a program and / or instructions, which, when executed by a communication device, cause the communication device to perform any of the above methods. Optionally, the program product is a computer program product. Optionally, the program product is stored on the storage medium.

[0385] This application also proposes a computer program that, when run on a computer, causes the computer to perform any of the above methods.

Claims

A method for sending information, characterized in that, The method is executed by a terminal, and the method includes: Repeatedly transmit the Physical Uplink Shared Channel (PUSCH) based on Orthogonal Cover Code (OCC) multiplexing to the network device; Repeatedly transmit the Physical Uplink Control Channel (PUCCH) to the network device; If it is determined that the PUCCH and the PUSCH overlap in the time domain, the first operation is performed. The method according to claim 1, characterized in that, The priority of the PUSCH is the same as the priority of the PUCCH; the first operation is: Cancel sending the PUCCH. The method according to claim 1, characterized in that, The first operation is: The PUCCH based on OCC multiplexing is repeatedly transmitted on the first OCC group, and the PUCCH and the PUSCH on the first OCC group cover the same OCC sequence value; Cancel sending the PUSCH on the first OCC group; or cancel sending all of the PUSCH. Wherein, the first OCC group is the OCC group in which the overlap is located, or the first OCC group is the next adjacent OCC group in which the overlap is located; The PUSCH repeatedly transmitted on one of the OCC groups covers the same value in the OCC sequence. The method according to claim 1, characterized in that, The first operation is: On the first OCC group, the PUCCH and PUSCH, which are multiplexed based on OCC, are repeatedly transmitted, and the PUCCH and PUSCH cover the same OCC sequence value; Wherein, the first OCC group is the OCC group in which the overlap is located, or the first OCC group is the next adjacent OCC group in which the overlap is located; The PUSCH repeatedly transmitted on one of the OCC groups covers the same value in the OCC sequence. The method according to claim 3 or 4, characterized in that, The actual number of times the PUCCH is repeatedly transmitted is the same as the OCC length corresponding to the terminal; or, The actual number of times the PUCCH is repeatedly sent is the same as the number of times the PUSCH is repeatedly sent. The method according to claim 5, characterized in that, The configured number of retransmissions of the PUCCH is different from the OCC length corresponding to the terminal; the method further includes: The repeated transmission of the PUCCH is processed; Wherein, the actual number of repeated transmissions of the processed PUCCH is the same as the OCC length corresponding to the terminal; or... The actual number of times the PUCCH is retransmitted after processing is the same as the number of times the PUSCH is retransmitted. The method according to claim 5, characterized in that, The configured number of retransmissions of the PUCCH is the same as the OCC length corresponding to the terminal; or, The terminal does not expect the number of times the PUCCH is repeatedly transmitted to be different from the length of the OCC corresponding to the terminal. The method according to claim 3 or 4, characterized in that, The actual starting time domain position of the PUCCH is the same as the starting time domain position of the PUSCH. The method according to claim 8, characterized in that, The starting time domain position of the configured PUCCH is the same as the starting time domain position corresponding to the PUSCH; or, The terminal does not expect the starting time domain position of the PUCCH to be different from the starting time domain position corresponding to the PUSCH. The method according to claim 8, characterized in that, The starting time domain position of the configured PUCCH is different from the starting time domain position corresponding to the PUSCH; the method further includes: If the time-domain reference point meets the specified conditions, the repeated transmission of the PUCCH is extended. The starting time domain position of the processed PUCCH is the same as the starting time domain position of the corresponding PUSCH. The time-domain reference point is the starting time-domain position of the OCC group where the overlap is located, or the time-domain reference is the starting time-domain position of the PUSCH. The method according to claim 8, characterized in that, The starting time domain position of the configured PUCCH is different from the starting time domain position corresponding to the PUSCH; the method further includes: If the time-domain reference point does not meet the specified conditions, cancel the transmission of the PUCCH. Wherein, the time-domain reference point is the starting time-domain position of the OCC group in which the overlap is located, or the time-domain reference is the starting time-domain position of the PUSCH. The method according to claim 8, characterized in that, The starting time domain position of the configured PUCCH is different from the starting time domain position corresponding to the PUSCH; The first OCC group is the next adjacent OCC group of the OCC group where the overlap is located, and the starting time domain position of the actually transmitted PUCCH is the same as the starting time domain position of the first OCC group. The method according to claim 3 or 4, characterized in that, The starting time domain position of the configured PUCCH is different from the starting time domain position corresponding to the PUSCH; the method further includes: Cancel sending the PUCCH. The method according to any one of claims 3-10, characterized in that, The time-domain reference point meets the specified conditions; The time-domain reference point is the starting time-domain position of the OCC group where the overlap is located, or the time-domain reference is the starting time-domain position of the PUSCH; The specified conditions include at least one of the following: The time interval between the uplink scheduling authorization and the time domain reference point exceeds the preparation time of the PUCCH and the PUSCH; The PUCCH carries a Hybrid Automatic Repeat Request Acknowledgment (HARQ-ACK), the time interval between the Physical Downlink Shared Channel (PDSCH) associated with the HARQ-ACK and the time domain reference point, and exceeds the decoding time of the PDSCH, as well as the preparation time of the PUCCH and the PUSCH. A terminal, characterized in that, The terminal includes: The transceiver module is used to repeatedly transmit the Physical Uplink Shared Channel (PUSCH) based on orthogonal cover code (OCC) multiplexing to the network device. The transceiver module is also used to repeatedly send the Physical Uplink Control Channel (PUCCH) to the network device; The processing module is used to determine that the PUCCH and the PUSCH overlap in the time domain and perform a first operation. A terminal, characterized in that, The terminal includes: One or more processors; The terminal is used to execute the information sending method according to any one of claims 1-14. A communication device, characterized in that, The communication device is used to perform the information transmission method according to any one of claims 1-14. A communication system, characterized in that, The device includes a terminal and a network device, wherein the terminal is configured to implement the information transmission method according to any one of claims 1-14. A storage medium storing instructions, characterized in that, When the instruction is executed on the communication device, the communication device performs the information transmission method as described in any one of claims 1-14. A program product comprising at least one of a program and instructions, characterized in that: When at least one of the programs or instructions is executed by the communication device, the information transmission method according to any one of claims 1-14 is implemented.

Images