Repeat transmission method, device, terminal and network side equipment

Abstract

The application provides a repeated transmission method, device, terminal and network side equipment. The method comprises: determining whether to perform first PUSCH repeated transmission; wherein the first PUSCH is a PUSCH transmitted after random access succeeds. In the application, the terminal determines whether to perform repeated transmission of the first PUSCH after the random access succeeds, so that the network side equipment can schedule repeated transmission of the first PUSCH for the terminal with limited uplink transmission coverage, and improve the uplink coverage performance.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a method, apparatus, terminal and network-side equipment for repeated transmission. Background Technology

[0002] In the New Radio (NR) system, after completing the four-step random access, the User Equipment (UE) reports its capabilities through the Physical Uplink Shared Channel (PUSCH) of Message 5 (Msg5) scheduled by the network side. Based on the UE capability reporting information, the network side performs the first Radio Resource Control (RRC) reconfiguration, and the UE obtains the connection-state exclusive RRC configuration.

[0003] Msg5 PUSCH transmission performance is crucial. In current technology, Msg5 PUSCH scheduled with downlink control information (DCI) scrambled by the cell radio network temporary identifier (C-RNTI) does not support repetition transmission, resulting in limited uplink transmission coverage for the terminal. Summary of the Invention

[0004] The purpose of this application is to provide a method, apparatus, terminal, and network-side device for repeated transmission, which solves the problem of limited uplink transmission coverage of the terminal.

[0005] Embodiments of this application provide a method for repeated transmission, applied to a terminal, comprising:

[0006] Determine whether the first physical uplink shared channel (PUSCH) retransmission can be performed;

[0007] The first PUSCH is the PUSCH transmitted after a successful random access.

[0008] Embodiments of this application provide a method for repeated transmission, applied to a network-side device, comprising:

[0009] Determine whether the terminal can be scheduled to perform the first PUSCH retransmission;

[0010] The first PUSCH is the PUSCH scheduled after a successful random access.

[0011] Embodiments of this application provide a terminal, including: a memory, a transceiver, and a processor.

[0012] A memory for storing computer programs; a transceiver for receiving and sending data under the control of the processor; and a processor for reading the computer programs from the memory and performing the following operations:

[0013] Determine whether the first PUSCH repeat transfer can be performed;

[0014] The first PUSCH is the PUSCH transmitted after a successful random access.

[0015] Embodiments of this application provide a network-side device, including: a memory, a transceiver, and a processor.

[0016] A memory for storing computer programs; a transceiver for receiving and sending data under the control of the processor; and a processor for reading the computer programs from the memory and performing the following operations:

[0017] Determine whether the terminal can be scheduled to perform the first PUSCH retransmission;

[0018] The first PUSCH is the PUSCH scheduled after a successful random access.

[0019] Embodiments of this application provide a retransmission apparatus, comprising:

[0020] The first processing unit is used to determine whether the first PUSCH repeat transmission can be performed;

[0021] The first PUSCH is the PUSCH transmitted after a successful random access.

[0022] Embodiments of this application provide a repetitive transmission device, comprising:

[0023] The second processing unit is used to determine whether the terminal can be scheduled to perform the first PUSCH retransmission.

[0024] The first PUSCH is the PUSCH scheduled after a successful random access.

[0025] Embodiments of this application provide a processor-readable storage medium storing a program for causing the processor to execute the methods described above.

[0026] Embodiments of this application also provide a chip including a processor coupled to a memory for executing a computer program or instructions stored in the memory. When the processor executes the computer program or instructions, the above-described method is performed.

[0027] The beneficial effects of the above-mentioned technical solution of this application are:

[0028] In an embodiment of this application, the terminal determines whether it can perform repeated transmission of the first PUSCH after successful random access, enabling the network-side device to schedule repeated transmission of the first PUSCH for terminals with limited uplink coverage, thereby improving uplink coverage performance. Attached Figure Description

[0029] Figure 1 This diagram illustrates the four-step random access process and subsequent procedures.

[0030] Figure 2 One of the flowcharts illustrating the repeated transmission method according to an embodiment of this application;

[0031] Figure 3 A second flowchart illustrating the repeated transmission method according to an embodiment of this application;

[0032] Figure 4 This is a schematic diagram of the structure of a repeating transmission device according to an embodiment of this application;

[0033] Figure 5 A second schematic diagram illustrating the structure of the repeating transmission device according to an embodiment of this application;

[0034] Figure 6 A schematic diagram illustrating the structure of the terminal according to an embodiment of this application;

[0035] Figure 7 This is a schematic diagram illustrating the structure of a network-side device according to an embodiment of this application.

[0036] Figure 8 This is a schematic diagram illustrating the structure of a chip system according to an embodiment of this application. Detailed Implementation

[0037] To make the technical problems, technical solutions, and advantages of this application clearer, a detailed description will be provided below in conjunction with the accompanying drawings and specific embodiments. In the following description, specific details such as particular configurations and components are provided merely to aid in a comprehensive understanding of the embodiments of this application. Therefore, those skilled in the art should understand that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Furthermore, for clarity and brevity, descriptions of known functions and structures have been omitted.

[0038] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments.

[0039] In the various embodiments of this application, it should be understood that the sequence number of each process described below does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0040] In this embodiment of the invention, the term "and / or" describes the relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The character " / " generally indicates that the preceding and following associated objects have an "or" relationship.

[0041] In the embodiments of this application, the term "multiple" refers to two or more, and other quantifiers are similar.

[0042] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0043] In describing the embodiments of this application, some concepts used in the following description will first be explained.

[0044] I. Four-step random access and subsequent processes.

[0045] like Figure 1 As shown, in the RRC idle state (IDLE), the UE initiates a random access procedure, sending the Msg1 preamble; receiving the RAR (Msg2) sent by the network; scheduling uplink transmission via PUSCH (Msg3) and requesting the establishment of an RRC connection (RRC setup request); receiving the Msg4 sent by the network and establishing the RRC connection (RRC setup). After entering the RRC connected state (connected), the UE sends the Msg5 message to the network: RRC setup complete; the network device sends a UE capability enquiry message to the terminal; the UE reports its capability information to the network; the network device sends an RRC reconfiguration message to the UE based on its capabilities; and the UE reports an RRC reconfiguration complete message to the network.

[0046] Embodiments of this application provide a method, apparatus, terminal, and network-side device for repeated transmission, which solves the problem of limited uplink transmission coverage of the terminal.

[0047] The method and apparatus are based on the same concept of the application. Since the methods and apparatus solve problems in similar ways, the implementation of the apparatus and methods can refer to each other, and the repeated parts will not be described again.

[0048] like Figure 2 As shown, an embodiment of this application provides a method for repeated transmission, applied to a terminal, specifically including the following steps:

[0049] Step 201: Determine whether the first physical uplink shared channel (PUSCH) can be repeatedly transmitted; wherein, the first PUSCH is the PUSCH transmitted after successful random access.

[0050] In some embodiments, determining whether a terminal can perform a first PUSCH retransmission includes: the terminal determining that it can perform the first PUSCH retransmission; and / or, the terminal determining that it cannot perform the first PUSCH retransmission. It can also be understood that the scheme for determining whether a first PUSCH retransmission can be performed in this application includes three possible schemes: 1. The terminal determines that it can perform the first PUSCH retransmission; 2. The terminal determines that it cannot perform the first PUSCH retransmission; 3. The terminal determines that it can perform the first PUSCH retransmission, and the terminal determines that it cannot perform the first PUSCH retransmission.

[0051] In this embodiment, the PUSCH transmitted after successful random access is the PUSCH transmitted after the UE receives Msg4 sent by the network side and establishes an RRC connection (RRC setup). This can also be understood as the PUSCH transmitted after the UE enters the connected state. Whether the terminal can perform repeated transmission of the first PUSCH can also be understood as whether the terminal is capable of repeatedly transmitting the first PUSCH. For example, if the terminal has the capability to repeatedly transmit the first PUSCH (i.e., the terminal supports repeated transmission of the first PUSCH) and has reported this capability to the network side device, the network side device, after obtaining the terminal's capability to repeatedly transmit the first PUSCH, determines that it can schedule the terminal to perform repeated transmission of the first PUSCH. If the terminal supports repeated transmission of the first PUSCH and has reported this capability to the network side device (i.e., the network side device knows that the terminal has this capability), then the terminal can perform repeated transmission of the first PUSCH. If the network-side device cannot obtain the terminal's first PUSCH retransmission capability (e.g., the terminal has the capability but has not reported it), or the terminal does not have the capability to retransmit the first PUSCH, then the network-side device cannot schedule the terminal to perform a retransmission of the first PUSCH. In this case, if the terminal has not reported its first PUSCH retransmission capability, or if the terminal does not have the capability to retransmit the first PUSCH, then the terminal cannot perform a retransmission of the first PUSCH. It can also be understood that the terminal having the capability to retransmit the first PUSCH does not necessarily mean that the terminal can perform a retransmission of the first PUSCH.

[0052] In this context, "having the capability to repeatedly transmit the first PUSCH" means that the terminal supports repeated transmission of the first PUSCH; "not having the capability to repeatedly transmit the first PUSCH" means that the terminal does not support repeated transmission of the first PUSCH. It should be noted that the terminal's ability to perform repeated transmission of the first PUSCH does not necessarily mean that the terminal actually performs repeated transmission of the first PUSCH. Whether the terminal actually performs repeated transmission of the first PUSCH depends on the scheduling of the network-side equipment.

[0053] The first PUSCH is the PUSCH scheduled after successful random access, for example... Figure 1 The Msg5PUSCH shown is shown.

[0054] In some embodiments, during the random access process, the terminal can determine whether it can perform a repeated transmission of the first PUSCH. This can also be understood as the terminal determining whether it can perform a repeated transmission of the first PUSCH after successful random access during the random access process, and the network-side device determining whether it can schedule a repeated transmission of the first PUSCH after successful random access during the random access process.

[0055] In an embodiment of this application, the terminal determines whether it can perform repeated transmission of the first PUSCH after successful random access, enabling the network-side device to schedule repeated transmission of the first PUSCH for terminals with limited uplink coverage, thereby improving uplink coverage performance.

[0056] As an optional embodiment, the first PUSCH includes at least one of the following:

[0057] (1) The first PUSCH scheduled by the first downlink control information (DCI) after successful random access; this can be understood as the first PUSCH being the PUSCH scheduled by the first DCI after the UE enters the connected state following the four-step random access, for example... Figure 1 The Msg5 PUSCH is shown. In some embodiments, the first PUSCH includes the first PUSCH scheduled by the first DCI after successful random access, or it can be understood that the first PUSCH is the first PUSCH scheduled by the first DCI after successful random access.

[0058] (2) The PUSCH scheduled by the first DCI after successful random access and before the terminal receives the first configuration information. The first configuration information is the terminal-specific PUSCH configuration information configured by Radio Resource Control (RRC). It can be understood that the first PUSCH is all the PUSCHs scheduled by the first DCI after the UE enters the connected state after four-step random access and before receiving the RRC configuration related to the UE-specific PUSCH. The PUSCHs scheduled by the first DCI in this range include the PUSCHs scheduled by the first DCI after successful random access in (1). In some embodiments, the first PUSCH includes the PUSCHs scheduled by the first DCI after successful random access and before the terminal receives the first configuration information. It can also be understood that the first PUSCH is the PUSCHs scheduled by the first DCI after successful random access and before the terminal receives the first configuration information.

[0059] (3) The PUSCH scheduled by the first DCI after successful random access. This can be understood as the first PUSCH being all PUSCHs scheduled by the first DCI after the UE enters the connected state following the four-step random access process. This includes the PUSCH scheduled by the first DCI after successful random access and before the terminal receives the first configuration information (as described in (2) above), and also the PUSCH scheduled by the first DCI after successful random access (as described in (1)). In some embodiments, the first PUSCH includes the PUSCH scheduled by the first DCI after successful random access, or it can be understood as the first PUSCH being the PUSCH scheduled by the first DCI after successful random access.

[0060] In some embodiments, the first PUSCH may also include multiple items from (1) to (3) above, such as: the first PUSCH includes: the first PUSCH of the first DCI scheduling after successful random access, and the first DCI scheduling PUSCH after successful random access and before the terminal receives the first configuration information; for example: the first PUSCH includes: the first DCI scheduling PUSCH after successful random access, and the first DCI scheduling PUSCH after successful random access and before the terminal receives the first configuration information; for example: the first PUSCH includes: the first PUSCH of the first DCI scheduling after successful random access, the first DCI scheduling PUSCH after successful random access and before the terminal receives the first configuration information, and the first DCI scheduling PUSCH after successful random access.

[0061] In some embodiments, the first DCI satisfies at least one of the following:

[0062] The first DCI is a DCI transmitted in the public search space;

[0063] The number of bits in the first DCI is a fixed value;

[0064] The first DCI is the DCI before the terminal receives the first configuration information.

[0065] In this embodiment, the first DCI can be a DCI transmitted in the common search space. The size of the first DCI is fixed, for example, a fixed number of bits, such as X bits, where X bits is a fixed value. The first DCI can be the DCI before the terminal receives the UE-specific PUSCH-related RRC configuration. The first DCI can satisfy one or more of the above conditions.

[0066] In some embodiments, the first DCI is scrambled by a first identifier. For example, the first identifier is C-RNTI, and the first DCI is DCI format 0_0 scrambled with C-RNTI in NR. The DCI format here is exemplary, and other existing or future DCI formats that implement similar functions, which are well known to those skilled in the art, may also be applied here, without limitation.

[0067] As an optional embodiment, determining whether a first physical uplink shared channel (PUSCH) retransmission can be performed includes at least one of the following:

[0068] Determine whether the first PUSCH retransmission can be performed based on the terminal's second PUSCH retransmission capability;

[0069] Based on the second PUSCH sent by the terminal, determine whether the first PUSCH can be retransmitted.

[0070] The second PUSCH is the PUSCH scheduled during the random access process performed by the terminal.

[0071] In this embodiment, the terminal can determine whether it can perform the first PUSCH retransmission based on the second PUSCH retransmission capability. This can also be understood as a correlation between the terminal's ability to perform the first PUSCH retransmission and its second PUSCH retransmission capability. Alternatively, the terminal can determine whether it can perform the first PUSCH retransmission based on the second PUSCH sent to the network-side device. This can also be understood as a correlation between the terminal's ability to perform the first PUSCH retransmission and the second PUSCH sent by the terminal. Alternatively, the terminal can determine whether it can perform the first PUSCH retransmission based on both its second PUSCH retransmission capability and the second PUSCH sent to the network-side device.

[0072] In some embodiments, the second PUSCH is the PUSCH of the random access procedure;

[0073] Wherein, the second PUSCH includes at least one of the following:

[0074] Random Access Response (RAR) Uplink (UL) grant scheduling PUSCH (RAR UL grant);

[0075] PUSCH (fallbackRAR UL grant) for fallback RAR uplink grant scheduling;

[0076] PUSCH scheduled by DCI scrambling with Temporary Cell Radio Network Temporary Identifier (TC-RNTI).

[0077] In this embodiment, the second PUSCH includes the aforementioned PUSCH, or can be understood as the aforementioned PUSCH, such as: the second PUSCH is a RAR UL licensed scheduling PUSCH, the second PUSCH is a fallback RAR uplink licensed scheduling PUSCH, or the second PUSCH is a DCI scheduled PUSCH scrambled by TC-RNTI. The terminal uses the second PUSCH retransmission capability and / or the second PUSCH when determining whether the first PUSCH retransmission can be performed. The second PUSCH is the PUSCH sent by the terminal during random access, i.e., Msg3 PUSCH.

[0078] 1) This second PUSCH can be a PUSCH scheduled by a RAR UL grant, for example... Figure 1 The initial transmission of Msg3 PUSCH is shown.

[0079] 2) The second PUSCH can also be a PUSCH scheduled by fallbackRAR UL grant, such as Msg3 PUSCH scheduled after the UE attempts two-step random access and falls back to four-step random access after failing.

[0080] 3) This second PUSCH can also be a DCI-scheduled PUSCH with TC-RNTI scrambling, for example... Figure 1 The Msg3PUSCH retransmission is shown.

[0081] The second PUSCH can be one of the above-mentioned PUSCHs, or it can include multiple of the above-mentioned PUSCHs. For example: the second PUSCH includes: the PUSCH of RAR UL grant scheduling and the PUSCH of fallback RAR uplink grant scheduling; the second PUSCH includes: the PUSCH of fallback RAR uplink grant scheduling and the PUSCH of DCI scheduling scrambled by TC-RNTI; the second PUSCH includes: the PUSCH of RAR UL grant scheduling, the PUSCH of fallback RAR uplink grant scheduling and the PUSCH of DCI scheduling scrambled by TC-RNTI.

[0082] It should be noted that when a terminal reports its ability to repeatedly transmit the second PUSCH to the network-side device, or reports whether it supports the repeated transmission of the second PUSCH to the network-side device, it does not distinguish which of the three types of second PUSCH the second PUSCH is. As long as the terminal reports that it supports the repeated transmission capability of the second PUSCH, the network-side device can schedule any one or more of the three types.

[0083] The following details how the terminal determines whether it can perform the first PUSCH retransmission.

[0084] As an optional embodiment, determining whether to perform a first PUSCH retransmission based on the terminal's second PUSCH retransmission capability includes:

[0085] (1) If the terminal reports to the network-side device that it supports the second PUSCH retransmission, it is determined that the first PUSCH retransmission can be performed.

[0086] In this embodiment, if the terminal reports to the network-side device that it supports second PUSCH retransmission, that is, reports to the network-side device that the terminal has the capability to retransmit the second PUSCH, then it is assumed that the terminal can perform first PUSCH retransmission, or that it can be scheduled by the network-side device to perform first PUSCH retransmission. If the network-side device determines that the terminal supports second PUSCH retransmission or determines that the terminal has the capability to retransmit the second PUSCH, then it assumes that the terminal has the capability to retransmit the first PUSCH and can schedule the terminal to perform the retransmission of the first PUSCH.

[0087] Alternatively, (2) if the terminal reports to the network-side device that it does not support the second PUSCH retransmission, it is determined that the first PUSCH retransmission cannot be performed.

[0088] In this embodiment, if the terminal reports to the network-side device that it does not support repeating the second PUSCH, that is, it reports to the network-side device that the terminal does not have the capability to repeat the second PUSCH, then it is considered that the terminal cannot perform repeating the first PUSCH, or that it cannot be scheduled by the network-side device to perform repeating the first PUSCH. If the network-side device determines that the terminal does not support repeating the second PUSCH or determines that the terminal does not have the capability to repeat the second PUSCH, then it assumes that the terminal also does not have the capability to repeat the first PUSCH, and cannot schedule the terminal to perform repeating the first PUSCH.

[0089] It should be noted that whether a terminal has the ability to retransmit the second PUSCH is not the same as whether the terminal has reported the ability to retransmit the second PUSCH to the network-side device. Only when the terminal reports the ability to retransmit the second PUSCH to the network-side device and the network-side device is aware of the terminal's ability to retransmit the second PUSCH can it schedule the retransmission of the terminal's first PUSCH, and only then can the terminal execute the retransmission of the first PUSCH.

[0090] The terminal reports to the network-side device whether it supports or does not support second PUSCH repetition. For example, if the network side configures RACH resources through RACH-ConfigCommon, and a set of RACH resources contains the Msg3-repetition feature or a combination of features, a terminal supporting second PUSCH repetition can send a preamble on the random access opportunity (RACHOccasion, RO) configured for that RACH resource to report support for second PUSCH repetition. If the network-side device receives the preamble on the RO configured for that RACH resource, it considers the terminal to support second PUSCH repetition. If the network-side device configures RACH resources through RACH-ConfigCommon that do not contain the Msg3-repetition feature or a combination of features, and the terminal sends a preamble on the RO configured for that RACH resource, and the network-side device receives the preamble on the RO configured for that RACH resource, it considers the terminal not to support second PUSCH repetition. Alternatively, the terminal can also report its second PUSCH repetition capability to the network-side device through other means. This application embodiment does not limit the method by which the terminal reports its second PUSCH repetition capability. The above-described method of configuring RACH resources on the network side is exemplary. Other existing or future methods of configuring RACH resources to achieve similar functions, well-known to those skilled in the art, can also be applied here, and are not limited thereto. As an optional embodiment, determining whether to perform a retransmission of the first PUSCH based on the second PUSCH sent by the terminal includes:

[0091] Based on the Logical Channel Identifier (LCID) or reserved bit information carried by the second PUSCH sent by the terminal, determine whether the first PUSCH can be retransmitted.

[0092] The LCID or reserved bit information carried by the second PUSCH is used to report the retransmission capability of the first PUSCH.

[0093] In this embodiment, the terminal can report whether it has the capability to repeatedly transmit the first PUSCH by sending the LCID or reserved bits carried by the second PUSCH to the network-side device. In some embodiments, the LCID can be the LCID in the Media Access Control (MAC) Protocol Data Unit (PDU) carried by the second PUSCH; the reserved bits can be reserved bits in the MAC PDU. After receiving the second PUSCH, the network-side device can determine whether the terminal has the capability to repeatedly transmit the first PUSCH based on the LCID or reserved bit information carried by the second PUSCH, thereby determining whether the terminal can be scheduled to repeatedly transmit the first PUSCH.

[0094] In some embodiments, determining whether to perform a first PUSCH retransmission based on the LCID or reserved bit information carried by the second PUSCH sent by the terminal includes:

[0095] If the terminal reporting the LCID or reserved bit information carried by the second PUSCH supports the repeated transmission of the first PUSCH, it is determined that the repeated transmission of the first PUSCH can be performed.

[0096] or,

[0097] If the terminal reporting the LCID or reserved bit information carried by the second PUSCH does not support the repeated transmission of the first PUSCH, it is determined that the repeated transmission of the first PUSCH cannot be performed.

[0098] In this embodiment, if the terminal reports to the network-side device that it supports repeated transmission of the first PUSCH, or reports that it has the capability to repeatedly transmit the first PUSCH, by sending the LCID or reserved bit information carried by the second PUSCH, then it is considered that the terminal can perform repeated transmission of the first PUSCH. This can also be understood as the terminal being scheduled by the network-side device to perform repeated transmission of the first PUSCH. After receiving the second PUSCH, the network-side device can determine, based on the LCID or reserved bit information carried by the second PUSCH, that the terminal supports repeated transmission of the first PUSCH, or that the terminal has the capability to repeatedly transmit the first PUSCH, and can then schedule the terminal to perform repeated transmission of the first PUSCH.

[0099] If a terminal reports to the network-side device, via the LCID or reserved bit information carried by the second PUSCH, that it does not support repeating the first PUSCH, or reports that it lacks the capability to repeat the first PUSCH, then it is considered that the terminal cannot perform repeating the first PUSCH. This can also be understood as the terminal not being scheduled by the network-side device to perform repeating the first PUSCH. Upon receiving the second PUSCH, the network-side device can determine, based on the LCID or reserved bit information carried by the second PUSCH, that the terminal does not support repeating the first PUSCH, or that the terminal lacks the capability to repeat the first PUSCH. Therefore, it cannot schedule the terminal to perform repeating the first PUSCH.

[0100] In some embodiments, the LCID includes at least one of the following:

[0101] The first LCID is used to report that the terminal supports repeated transmission of the first PUSCH.

[0102] The second LCID is used to report that the terminal does not support repeated transmission of the first PUSCH.

[0103] Wherein, the first LCID includes at least one LCID value; and / or, the second LCID includes at least one LCID value.

[0104] In this embodiment, when the terminal reports the retransmission capability of the first PUSCH to the network-side device through the LCID carried by the second PUSCH, for example, if the terminal supports the retransmission of the first PUSCH or the terminal has the capability to retransmit the first PUSCH, then the first LCID is carried in the second PUSCH; when the network-side device receives the second PUSCH, it can obtain the first LCID by decoding, and thus determine that the terminal supports the retransmission of the first PUSCH or the terminal has the capability to retransmit the first PUSCH, and can schedule the terminal to perform the retransmission of the first PUSCH.

[0105] If the terminal does not support retransmission of the first PUSCH or lacks the capability to retransmit the first PUSCH, a second LCID can be carried in the second PUSCH. When the network-side device receives the second PUSCH, it obtains the second LCID through decoding. This allows it to determine that the terminal does not support retransmission of the first PUSCH or lacks the capability to retransmit the first PUSCH, and therefore, the terminal cannot be scheduled to perform retransmission of the first PUSCH. The first LCID can be a single value or multiple values, and the second LCID can also be a single value or multiple values.

[0106] In some embodiments, where the first LCID includes at least two LCID values, each LCID value corresponds to indicating a first PUSCH retransmission number.

[0107] In this embodiment, when the first LCID contains multiple values, different values ​​can correspond to different reported first PUSCH retransmission counts. For example, the first LCID contains three LCIDs: LCID#1 indicates that the terminal supports a maximum of 2 first PUSCH retransmissions, LCID#2 indicates that the UE supports a maximum of 4 first PUSCH retransmissions, and LCID#3 indicates that the UE supports a maximum of 8 first PUSCH retransmissions. After receiving the second PUSCH sent by the terminal, the network-side device reads the LCID carried in the second PUSCH. Based on the LCID value, it can determine the number of first PUSCH retransmissions supported by the terminal, thereby deciding whether to schedule first PUSCH retransmissions for the terminal and determining the maximum number of retransmissions supported when scheduling first PUSCH retransmissions.

[0108] The terminal can also report whether it supports repeated transmission of the first PUSCH by using the reserved bits carried in the second PUSCH. For example, a reserved bit value of 1 indicates that the terminal supports repeated transmission of the first PUSCH; a reserved bit value of 0 indicates that the terminal does not support repeated transmission of the first PUSCH; or, a reserved bit value of 0 indicates that the terminal supports repeated transmission of the first PUSCH; a reserved bit value of 1 indicates that the terminal does not support repeated transmission of the first PUSCH. After receiving the second PUSCH, the network-side device determines whether the terminal supports repeated transmission of the first PUSCH by reading the threshold of the reserved bits, and thus decides whether to schedule repeated transmission of the first PUSCH for that terminal.

[0109] As another optional embodiment, the terminal may also determine whether to perform a first PUSCH retransmission based on the second PUSCH retransmission capability and the second PUSCH together. The determination of whether to perform a first physical uplink shared channel PUSCH retransmission includes:

[0110] If the terminal reports to the network-side device that it supports the second PUSCH retransmission, it is determined that the first PUSCH retransmission can be performed.

[0111] or,

[0112] If the terminal reports to the network-side device that it does not support the retransmission of the second PUSCH, it is determined whether the retransmission of the first PUSCH can be performed based on the LCID or reserved bit information carried by the second PUSCH sent by the terminal.

[0113] In this embodiment, the terminal's ability to perform first PUSCH retransmission is related to both the second PUSCH retransmission capability and the second PUSCH sent by the terminal. For example, if the terminal reports to the network-side device that it supports second PUSCH retransmission, it is assumed that the terminal can perform first PUSCH retransmission, or that it can be scheduled by the network-side device to perform first PUSCH retransmission. If the network-side device determines that the terminal supports second PUSCH retransmission, it assumes that the terminal also supports first PUSCH retransmission, thereby determining whether to schedule the terminal to perform first PUSCH retransmission.

[0114] If a terminal lacks the capability to retransmit the second PUSCH, and reports to the network-side device that it does not support retransmitting the second PUSCH, it can use the LCID or reserved bit information carried by the second PUSCH to report whether it has the capability to retransmit the first PUSCH. If the network-side device determines that the terminal does not support retransmitting the second PUSCH, it can determine whether the terminal has the capability to retransmit the first PUSCH based on the received LCID or reserved bit information carried by the second PUSCH, and thus determine whether to schedule the terminal to perform retransmission of the first PUSCH.

[0115] Specifically, when determining whether to perform a first PUSCH retransmission based on the LCID or reserved bit information carried by the second PUSCH sent by the terminal: if the LCID or reserved bit information carried by the second PUSCH indicates that the terminal supports the first PUSCH retransmission, then the first PUSCH retransmission can be performed; if the LCID or reserved bit information carried by the second PUSCH indicates that the terminal does not support the first PUSCH retransmission, then the first PUSCH retransmission cannot be performed. The LCID includes at least one of the following: a first LCID, used to report that the terminal supports the first PUSCH retransmission; a second LCID, used to report that the terminal does not support the first PUSCH retransmission; wherein the first LCID includes at least one LCID value; and / or, the second LCID includes at least one LCID value. When the first LCID includes at least two LCID values, each LCID value corresponds to one number of first PUSCH retransmissions.

[0116] After receiving the second PUSCH from the terminal, the network-side device determines whether the terminal supports repeated transmission of the first PUSCH by reading the LCID carried in the second PUSCH. For example, if the network-side device receives the second PUSCH and obtains the first LCID by decoding, it can determine that the terminal supports repeated transmission of the first PUSCH or has the capability to repeat the first PUSCH, and can then schedule the terminal to perform repeated transmission of the first PUSCH. If the network-side device receives the second PUSCH and obtains the second LCID by decoding, it can determine that the terminal does not support repeated transmission of the first PUSCH or does not have the capability to repeat the first PUSCH, and therefore cannot schedule the terminal to perform repeated transmission of the first PUSCH.

[0117] The following example illustrates how the terminal determines whether the first PUSCH repeat transmission can be performed.

[0118] Example 1: The terminal determines whether it can perform a first PUSCH retransmission based on its second PUSCH retransmission capability; the network-side device determines whether it can schedule the terminal to perform the first PUSCH retransmission based on the terminal's second PUSCH retransmission capability.

[0119] PUSCH is scheduled via DCI. In this example, the first DCI has at least one of the following characteristics: the first DCI is a DCI in the common search space; the size of the first DCI is fixed, for example, the first DCI is a fixed number of bits; the first DCI is a DCI sent by the network-side device before the UE receives the RRC-specific configuration.

[0120] In NR, the first DCI is the fallback DCI, i.e., DCI format 0_0. Furthermore, this first DCI is scrambled using a first identifier, such as C-RNTI scrambled DCI format 0_0. The first PUSCH can be one or more of the following PUSCHs scheduled by the first DCI:

[0121] (1) After successful four-step random access, the UE enters the connected state and uses the first PUSCH scheduled by the first DCI, such as Figure 1 Msg5 PUSCH in;

[0122] (2) After the four-step random access is successful, the UE enters the connected state and schedules all PUSCHs through the first DCI before receiving the RRC configuration related to the UE's exclusive PUSCH.

[0123] (3) After the four-step random access is successful, the UE enters the connected state and uses all PUSCHs scheduled by the first DCI.

[0124] It should be noted that the scope of the first PUSCH is gradually expanded. For example, the PUSCH in (2) includes the PUSCH in (1); the PUSCH in (3) includes the PUSCH in (2) and (1). This example uses Msg5 PUSCH as the first PUSCH for illustration.

[0125] The second PUSCH is a PUSCH scheduled under at least one of the following conditions:

[0126] 1) PUSCH scheduled by RAR UL grant, i.e. Figure 1 Msg3 PUSCH's first transmission in the video;

[0127] 2) The fallbackRAR UL grant scheduled PUSCH, that is, the Msg3 PUSCH of the four-step random access scheduling after the UE fails to attempt two steps of random access;

[0128] 3) PUSCH scheduled by DCI 0_0 with TC-RNTI scrambling, i.e. Figure 1 Msg3 PUSCH retransmission in the middle.

[0129] Example 1 uses Msg3 PUSCH as the second PUSCH for illustration.

[0130] Currently, Msg3 PUSCH retransmission is supported. The UE reports the retransmission capability of Msg3 PUSCH by sending a preamble. For example, the UE sends the preamble on the RO resource that is independently configured for Msg3 PUSCH retransmission, or the UE sends the preamble specific to the Msg3 PUSCH retransmission feature on the RO resource shared with other UE features.

[0131] If a network-side device receives a preamble on a RO resource independently configured for Msg3 PUSCH retransmission, or receives a preamble specific to the Msg3 PUSCH retransmission feature on a shared RO resource, it considers that the UE sending the preamble has the capability to retransmit Msg3 PUSCH.

[0132] Whether a UE can perform Msg5 PUSCH retransmission is related to its Msg3 PUSCH retransmission capability. For example, when a UE reports support for Msg3 PUSCH retransmission in the above manner, the terminal can perform Msg5 PUSCH retransmission. If the network-side device receives a preamble on a RO resource independently configured for Msg3 PUSCH retransmission, or receives a preamble specific to the Msg3 PUSCH retransmission feature on a shared RO resource, it considers that the UE sending the preamble has both Msg3 PUSCH and Msg5 PUSCH retransmission capabilities, and the network-side device can schedule the terminal to perform Msg5 PUSCH retransmission.

[0133] If the UE does not send the preamble on the aforementioned dedicated RO or shared RO, it indicates that the terminal does not have the capability to retransmit Msg3PUSCH, and by default, the terminal also cannot perform Msg5PUSCH retransmission. If the network does not receive the preamble on the aforementioned dedicated RO or shared RO, it is considered that the UE sending the preamble does not have the capability to retransmit Msg3PUSCH or Msg5PUSCH, and the network cannot schedule the terminal to perform Msg5PUSCH retransmission.

[0134] Example 2: The terminal reports its first PUSCH retransmission capability by using the LCID or reserved bit information carried by the second PUSCH, thereby determining whether the terminal can perform the first PUSCH retransmission.

[0135] In this second example, the ability of the UE to repeatedly transmit Msg3 PUSCH reported through preamble is unrelated to whether the UE supports the ability to repeatedly transmit Msg5 PUSCH.

[0136] In NR, the MAC layer packages the content to be transmitted into a MAC PDU, which is then transmitted through the physical layer data channel. A MAC PDU contains one or more MAC sub-PDUs, and each MAC sub-PDU contains at least a MAC subheader. The subheader of the data channel contains a Logical Channel ID (LCID). Different LCIDs indicate the different functions of the data channel. In addition, the subheader contains at least 1 reserved bit.

[0137] Msg3 PUSCH is the physical uplink data channel. In Example 2, the UE carries an LCID in the subheader of Msg3 PUSCH to report its Msg5 PUSCH retransmission capability. For example, if the UE carries the first LCID in Msg3 PUSCH, it means that the UE supports Msg5 PUSCH retransmission; if the UE carries the second LCID in Msg3 PUSCH, it means that the UE does not support Msg5 PUSCH retransmission.

[0138] The first LCID and the second LCID can be the same value or multiple values. Furthermore, the UE can report the maximum supported Msg5 PUSCH retransmission capability. For example, the first LCID may contain three LCIDs: LCID#1 indicates that the UE supports a maximum of 2 Msg5 PUSCH retransmissions, LCID#2 indicates that the UE supports a maximum of 4 Msg5 PUSCH retransmissions, and LCID#3 indicates that the UE supports a maximum of 8 Msg5 PUSCH retransmissions. After receiving the Msg3 PUSCH sent by the UE, the network-side device determines whether the UE supports Msg5 PUSCH retransmissions by reading the LCID value in the MACPDU, and thus decides whether to schedule Msg5 PUSCH retransmissions for the UE.

[0139] In addition, the UE can also report Msg5 PUSCH retransmission capability by enabling a 1-bit reserved bit in the subheader. For example, a reserved bit value of 1 indicates that the UE supports Msg5 PUSCH retransmission, while a reserved bit value of 0 indicates that the UE does not support Msg5 PUSCH retransmission capability; or, a reserved bit value of 0 indicates that the UE supports Msg5 PUSCH retransmission, while a reserved bit value of 1 indicates that the UE does not support Msg5 PUSCH retransmission capability. After receiving the Msg3 PUSCH sent by the UE, the network-side device determines whether the UE supports Msg5 PUSCH retransmission by reading the reserved bit value used for reporting Msg5 PUSCH retransmission in the MAC PDU, and thus decides whether to schedule Msg5 PUSCH retransmission for the UE.

[0140] Example 3: The terminal determines whether it can perform the first PUSCH retransmission based on its second PUSCH retransmission capability and the second PUSCH itself; the network-side device determines whether it can schedule the terminal to perform the first PUSCH retransmission based on the terminal's second PUSCH retransmission capability and the second PUSCH itself.

[0141] In this example, the Msg5 PUSCH retransmission capability and the Msg3 PUSCH retransmission capability are partially bound. Specifically, when the UE reports the Msg3 PUSCH retransmission capability during the Msg1 PRACH transmission phase, for example, in Example 1, the UE sends a preamble on a RO resource independently configured for Msg3 PUSCH retransmission, or sends a preamble specific to the Msg3 PUSCH retransmission feature on a RO resource shared with other UE features, thereby reporting the Msg3 PUSCH retransmission capability. When the network-side device receives the preamble on a RO resource independently configured for Msg3 PUSCH retransmission, or receives a preamble specific to the Msg3 PUSCH retransmission feature on a shared RO resource, it considers that the UE sending the preamble possesses both Msg3 PUSCH retransmission capability and Msg5 PUSCH retransmission capability.

[0142] When a UE lacks the ability to retransmit Msg3 PUSCH, for example, if the UE sends a preamble on a resource other than the aforementioned dedicated RO or shared RO resources, it indicates that the UE does not have the ability to retransmit Msg3 PUSCH. The UE can then report whether it has the ability to retransmit Msg5 PUSCH using the LCID or reserved bits carried in the Msg3 PUSCH as shown in Example 2 above. When the network-side device receives the preamble on a resource other than the aforementioned dedicated RO or shared RO resources, it determines that the UE does not have the ability to retransmit Msg3 PUSCH. The network-side device can then determine whether the UE has the ability to retransmit Msg5 PUSCH by reading the LCID or reserved bits carried in the Msg3 PUSCH.

[0143] The method for determining whether a UE has the ability to repeatedly transmit Msg5PUSCH by using the LCID or reserved bits carried by Msg3 PUSCH is the same as in Example 2, and will not be repeated here.

[0144] The mechanism in this application embodiment for determining whether a terminal can perform first PUSCH retransmission, such as determining whether the terminal can perform first PUSCH retransmission based on the terminal's second PUSCH retransmission capability and / or the second PUSCH sent by the terminal, allows the network-side device to perform early identification and differentiation between UEs that support and do not support first PUSCH retransmission during the random access phase. This enables scheduling first PUSCH retransmission for UEs with limited first PUSCH coverage, improving UE uplink coverage performance, ensuring the network-side device successfully receives the UE capability reporting information carried by the first PUSCH, and subsequently performing RRC reconfiguration for connected UEs.

[0145] In an embodiment of this application, the terminal determines whether it can perform repeated transmission of the first PUSCH after successful random access, enabling the network-side device to schedule repeated transmission of the first PUSCH for terminals with limited uplink coverage, thereby improving uplink coverage performance.

[0146] like Figure 3 As shown in the embodiments of this application, a method for repeated transmission is also provided, applied to a network-side device, including:

[0147] Step 301: Determine whether the terminal can be scheduled to perform repeated transmission of the first PUSCH; wherein, the first PUSCH is the PUSCH scheduled after successful random access.

[0148] In some embodiments, determining whether a network-side device can schedule a terminal to perform a first PUSCH retransmission includes: the network-side device determining that it can schedule the terminal to perform a first PUSCH retransmission; and / or, the network-side device determining that it cannot schedule the terminal to perform a first PUSCH retransmission. It can also be understood that the scheme for determining whether a terminal can perform a first PUSCH retransmission in this application includes three possible schemes: 1. The network-side device determines that it can schedule the terminal to perform a first PUSCH retransmission; 2. The network-side device determines that it cannot schedule the terminal to perform a first PUSCH retransmission; 3. The network-side device determines that it can schedule the terminal to perform a first PUSCH retransmission; and 4. The network-side device determines that it cannot schedule the terminal to perform a first PUSCH retransmission.

[0149] In this embodiment, the PUSCH scheduled after successful random access is Msg4 sent by the network-side device to the terminal. After the UE receives Msg4 sent by the network side and establishes an RRC connection, the PUSCH scheduled by the network-side device can also be understood as the PUSCH scheduled by the network-side device after the UE enters the connected state. The network-side device's determination of whether it can schedule the terminal to perform repeated transmission of the first PUSCH can also be understood as the network-side device determining whether it can schedule the terminal to perform repeated transmission of the first PUSCH. For example: if it is determined that the terminal has the capability to repeat the first PUSCH, that is, the terminal supports repeated transmission of the first PUSCH and the terminal has reported this capability to the network-side device, the network-side device, after obtaining the terminal's capability to repeat the first PUSCH, determines that it can schedule the terminal to perform repeated transmission of the first PUSCH; if the terminal supports repeated transmission of the first PUSCH and the terminal has reported this capability to the network-side device, that is, the network-side device knows that the terminal has this capability, then the terminal can perform repeated transmission of the first PUSCH.

[0150] If the network-side device cannot obtain the terminal's first PUSCH retransmission capability (e.g., the terminal has the first PUSCH retransmission capability but has not reported it), or the terminal does not have the first PUSCH retransmission capability, then the terminal cannot be scheduled to perform the first PUSCH retransmission. In this case, if the terminal has not reported the first PUSCH retransmission capability, or the terminal does not have the first PUSCH retransmission capability, then the terminal cannot perform the first PUSCH retransmission.

[0151] Wherein, "the terminal has the ability to repeatedly transmit the first PUSCH" means that the terminal supports repeated transmission of the first PUSCH; "the terminal does not have the ability to repeatedly transmit the first PUSCH" means that the terminal does not support repeated transmission of the first PUSCH.

[0152] The first PUSCH is the PUSCH scheduled after successful random access, for example... Figure 1 The Msg5PUSCH shown is shown.

[0153] In some embodiments, during random access, the network-side device can determine whether it can schedule the terminal to perform repeated transmission of the first PUSCH. This can also be understood as the network-side device determining whether it can schedule the terminal to perform repeated transmission of the first PUSCH after successful random access.

[0154] In an embodiment of this application, the network-side device determines whether it can schedule the terminal to perform repeated transmission of the first PUSCH after successful random access, thereby scheduling repeated transmission of the first PUSCH for terminals with limited uplink coverage and improving the uplink coverage performance of the terminal.

[0155] As an optional embodiment, the first PUSCH includes at least one of the following:

[0156] (1) The first PUSCH scheduled by the first downlink control information (DCI) after successful random access; this can be understood as the first PUSCH being the PUSCH scheduled by the first DCI after the UE enters the connected state following the four-step random access, for example... Figure 1 The Msg5 PUSCH is shown. In some embodiments, the first PUSCH includes the first PUSCH scheduled by the first DCI after successful random access, or it can be understood that the first PUSCH is the first PUSCH scheduled by the first DCI after successful random access.

[0157] (2) The PUSCH scheduled by the first DCI after successful random access and before the terminal receives the first configuration information. The first configuration information is the terminal-specific PUSCH configuration information configured by Radio Resource Control (RRC). It can be understood that the first PUSCH is all the PUSCHs scheduled by the first DCI after the UE enters the connected state after four-step random access and before receiving the RRC configuration related to the UE-specific PUSCH. The PUSCHs scheduled by the first DCI in this range include the PUSCHs scheduled by the first DCI after successful random access in (1). In some embodiments, the first PUSCH includes the PUSCHs scheduled by the first DCI after successful random access and before the terminal receives the first configuration information. It can also be understood that the first PUSCH is the PUSCHs scheduled by the first DCI after successful random access and before the terminal receives the first configuration information.

[0158] (3) The PUSCH scheduled by the first DCI after successful random access. This can be understood as the first PUSCH being all PUSCHs scheduled by the first DCI after the UE enters the connected state following the four-step random access process. This includes the PUSCH scheduled by the first DCI after successful random access and before the terminal receives the first configuration information (as described in (2) above), and also the PUSCH scheduled by the first DCI after successful random access (as described in (1)). In some embodiments, the first PUSCH includes the PUSCH scheduled by the first DCI after successful random access, or it can be understood as the first PUSCH being the PUSCH scheduled by the first DCI after successful random access.

[0159] In some embodiments, the first DCI satisfies at least one of the following:

[0160] The first DCI is a DCI transmitted in the public search space;

[0161] The number of bits in the first DCI is a fixed value;

[0162] The first DCI is the DCI before the terminal receives the first configuration information.

[0163] In this embodiment, the first DCI can be a DCI transmitted in the common search space. The size of the first DCI is fixed, for example, a fixed number of bits, such as X bits, where X bits is a fixed value. The first DCI can be the DCI before the terminal receives the UE-specific PUSCH-related RRC configuration.

[0164] In some embodiments, the first DCI is scrambled by a first identifier. For example, the first identifier is C-RNTI, and the first DCI is a DCI format 0_0 scrambled with C-RNTI in NR. The DCI format here is exemplary, and other existing or future DCI formats that implement similar functions and are well known to those skilled in the art can also be applied here, without limitation.

[0165] As an optional embodiment, determining whether the terminal can be scheduled to perform the first PUSCH retransmission includes at least one of the following:

[0166] Based on the terminal's second PUSCH retransmission capability, determine whether the terminal can be scheduled to perform the first PUSCH retransmission.

[0167] Based on the second PUSCH sent by the terminal, determine whether the terminal can be scheduled to perform a retransmission of the first PUSCH;

[0168] The second PUSCH is the PUSCH scheduled during the random access process performed by the terminal.

[0169] In this embodiment, the network-side device can determine whether it can schedule the terminal to perform a first PUSCH retransmission based on the terminal's second PUSCH retransmission capability. Alternatively, the network-side device can determine whether it can schedule the terminal to perform a first PUSCH retransmission based on the second PUSCH sent by the terminal. Or, the network-side device can determine whether it can schedule the terminal to perform a first PUSCH retransmission based on both the second PUSCH retransmission capability and the second PUSCH sent by the terminal.

[0170] In some embodiments, the second PUSCH is the PUSCH of the random access procedure;

[0171] Wherein, the second PUSCH includes at least one of the following:

[0172] Random access response to RAR uplink grant scheduling PUSCH (RAR UL grant);

[0173] PUSCH (fallbackRAR UL grant) for RAR uplink grant scheduling;

[0174] PUSCH scheduled by DCI scrambling with the temporary identifier TC-RNTI of the temporary cell radio network.

[0175] In this embodiment, the second PUSCH includes the aforementioned PUSCH, or can be understood as the aforementioned PUSCH, for example: the second PUSCH is a RAR UL granted scheduling PUSCH, the second PUSCH is a fallback RAR uplink granted scheduling PUSCH, or the second PUSCH is a DCI scheduled PUSCH scrambled by TC-RNTI. The network-side device uses the second PUSCH retransmission capability and / or the second PUSCH when determining whether the terminal can be scheduled to perform the first PUSCH retransmission. The second PUSCH is the PUSCH sent by the terminal during random access. This second PUSCH can be a RAR UL grant, for example... Figure 1 The Msg3 PUSCH shown is the initial transmission; the second PUSCH can also be a fallback RAR UL grant, for example, the Msg3 PUSCH scheduled after the UE attempts two-step random access and fails, then falls back to four-step random access; the second PUSCH can also be a PUSCH scheduled by DCI with TC-RNTI scrambling, for example... Figure 1 The Msg3 PUSCH retransmission is shown.

[0176] It should be noted that when a terminal reports its ability to repeatedly transmit the second PUSCH to the network-side device, or reports whether it supports the repeated transmission of the second PUSCH to the network-side device, it does not distinguish which of the three types of second PUSCH the second PUSCH is. As long as the terminal reports that it supports the repeated transmission capability of the second PUSCH, the network-side device can schedule any one or more of the three types.

[0177] As an optional embodiment, determining whether the terminal can be scheduled to perform the first PUSCH retransmission based on the terminal's second PUSCH retransmission capability includes:

[0178] If the terminal supports the second PUSCH retransmission, it is determined that the terminal can be scheduled to perform the first PUSCH retransmission.

[0179] or,

[0180] If the terminal does not support the second PUSCH retransmission, it is determined that the terminal cannot be scheduled to perform the first PUSCH retransmission.

[0181] In this embodiment, if the network-side device determines that the terminal supports the second PUSCH retransmission, that is, the terminal has the capability to retransmit the second PUSCH, then it is assumed that the terminal also has the capability to retransmit the first PUSCH or that the terminal also supports the first PUSCH retransmission. In this case, the network-side device can schedule the terminal to perform the retransmission of the first PUSCH.

[0182] If the network-side device determines that the terminal does not support the retransmission of the second PUSCH or does not have the capability to retransmit the second PUSCH, then by default the terminal also does not have the capability to retransmit the first PUSCH, and cannot schedule the terminal to perform the retransmission of the first PUSCH.

[0183] The network-side device determines whether a terminal supports second PUSCH repetition. For example, if the network configures RACH resources via RACH-ConfigCommon, and a RACH resource contains the Msg3-repetition feature or a combination of features, a terminal supporting second PUSCH repetition can send a preamble to the RO configured on that RACH resource to report support for second PUSCH repetition. If the network-side device receives the preamble on the RO configured on that RACH resource, it considers the terminal to support second PUSCH repetition. If the network-side device configures RACH resources via RACH-ConfigCommon that do not contain the Msg3-repetition feature or a combination of features, and the terminal sends a preamble on the RO configured on that RACH resource, and the network-side device receives the preamble on the RO configured on that RACH resource, it considers the terminal not to support second PUSCH repetition. Alternatively, the terminal can also report its second PUSCH repetition capability to the network-side device through other methods.

[0184] As an optional embodiment, determining whether the terminal can be scheduled to perform a retransmission of the first PUSCH based on the second PUSCH sent by the terminal includes:

[0185] Based on the LCID or reserved bit information carried by the second PUSCH sent by the terminal, determine whether the terminal can be scheduled to perform repeated transmission of the first PUSCH;

[0186] The LCID or reserved bit information carried by the second PUSCH is used to report the retransmission capability of the first PUSCH.

[0187] In this embodiment, the terminal can report whether it has the capability to repeatedly transmit the first PUSCH by sending the LCID or reserved bits carried by the second PUSCH to the network-side device. In some embodiments, the LCID can be the LCID in the MAC PDU carried by the second PUSCH; the reserved bits can be reserved bits in the MAC PDU. After receiving the second PUSCH, the network-side device can determine whether the terminal has the capability to repeatedly transmit the first PUSCH based on the LCID or reserved bit information carried by the second PUSCH, thereby determining whether the terminal can be scheduled to perform repeated transmission of the first PUSCH.

[0188] In some embodiments, determining whether the terminal can be scheduled to perform a repeated transmission of the first PUSCH based on the LCID or reserved bit information carried by the second PUSCH sent by the terminal includes:

[0189] If the terminal reporting the LCID or reserved bit information carried by the second PUSCH supports the repeated transmission of the first PUSCH, it is determined that the terminal can be scheduled to perform the repeated transmission of the first PUSCH.

[0190] or,

[0191] If the terminal reporting the LCID or reserved bit information carried by the second PUSCH does not support the repeated transmission of the first PUSCH, it is determined that the terminal cannot be scheduled to perform the repeated transmission of the first PUSCH.

[0192] In this embodiment, if the terminal reports to the network-side device that it supports repeated transmission of the first PUSCH or has the capability to repeatedly transmit the first PUSCH through the LCID or reserved bit information carried by the second PUSCH, the network-side device, after receiving the second PUSCH, can know that the terminal supports repeated transmission of the first PUSCH or has the capability to repeatedly transmit the first PUSCH based on the LCID or reserved bit information carried by the second PUSCH, and can then schedule the terminal to perform repeated transmission of the first PUSCH.

[0193] If, after receiving the second PUSCH, the network-side device learns from the LCID or reserved bit information carried by the second PUSCH that the terminal does not support repeated transmission of the first PUSCH, or learns that the terminal does not have the capability to repeat transmission of the first PUSCH, then it cannot schedule the terminal to perform repeated transmission of the first PUSCH.

[0194] In some embodiments, the LCID includes at least one of the following:

[0195] The first LCID is used to report that the terminal supports repeated transmission of the first PUSCH.

[0196] The second LCID is used to report that the terminal does not support repeated transmission of the first PUSCH.

[0197] Wherein, the first LCID includes at least one LCID value; and / or, the second LCID includes at least one LCID value.

[0198] In this embodiment, when the terminal reports the retransmission capability of the first PUSCH to the network-side device through the LCID carried by the second PUSCH, for example, if the terminal supports the retransmission of the first PUSCH or the terminal has the capability to retransmit the first PUSCH, then the first LCID is carried in the second PUSCH; when the network-side device receives the second PUSCH, it can obtain the first LCID by decoding, and thus determine that the terminal supports the retransmission of the first PUSCH or the terminal has the capability to retransmit the first PUSCH, and can schedule the terminal to perform the retransmission of the first PUSCH.

[0199] If the terminal does not support retransmission of the first PUSCH or lacks the capability to retransmit the first PUSCH, a second LCID can be carried in the second PUSCH. When the network-side device receives the second PUSCH, it obtains the second LCID through decoding. This allows it to determine that the terminal does not support retransmission of the first PUSCH or lacks the capability to retransmit the first PUSCH, and therefore, the terminal cannot be scheduled to perform retransmission of the first PUSCH. The first LCID can be a single value or multiple values, and the second LCID can also be a single value or multiple values.

[0200] In some embodiments, where the first LCID includes at least two LCID values, each LCID value corresponds to indicating a first PUSCH retransmission number.

[0201] In this embodiment, when the first LCID contains multiple values, different values ​​can correspond to different reported first PUSCH retransmission counts. For example, the first LCID contains three LCIDs: LCID#1 indicates that the terminal supports a maximum of 2 first PUSCH retransmissions, LCID#2 indicates that the UE supports a maximum of 4 first PUSCH retransmissions, and LCID#3 indicates that the UE supports a maximum of 8 first PUSCH retransmissions. After receiving the second PUSCH sent by the terminal, the network-side device reads the LCID carried in the second PUSCH. Based on the LCID value, it can determine the number of first PUSCH retransmissions supported by the terminal, thereby deciding whether to schedule first PUSCH retransmissions for the terminal, and determining the maximum number of retransmissions supported when scheduling first PUSCH retransmissions.

[0202] Network-side devices can also determine whether a terminal supports repeated transmission of the first PUSCH by using the reserved bits carried in the second PUSCH. For example, a reserved bit value of 1 indicates that the terminal supports repeated transmission of the first PUSCH; a reserved bit value of 0 indicates that the terminal does not support repeated transmission of the first PUSCH; or, a reserved bit value of 0 indicates that the terminal supports repeated transmission of the first PUSCH; a reserved bit value of 1 indicates that the terminal does not support repeated transmission of the first PUSCH. After receiving the second PUSCH, the network-side device determines whether the terminal supports repeated transmission of the first PUSCH by reading the threshold of the reserved bits, thereby deciding whether to schedule repeated transmission of the first PUSCH for that terminal.

[0203] As another optional embodiment, determining whether the terminal can be scheduled to perform the first PUSCH retransmission includes:

[0204] If the terminal supports the second PUSCH retransmission, it is determined that the terminal can be scheduled to perform the first PUSCH retransmission.

[0205] or,

[0206] If the terminal does not support the second PUSCH retransmission, it is determined whether the terminal can be scheduled to perform the first PUSCH retransmission based on the LCID or reserved bit information carried by the second PUSCH sent by the terminal.

[0207] In this embodiment, whether the terminal has the capability to repeatedly transmit the first PUSCH is related to its capability to repeatedly transmit the second PUSCH and the second PUSCH sent by the terminal. For example, if it is determined that the terminal supports repeated transmission of the second PUSCH, it is assumed that the terminal also supports repeated transmission of the first PUSCH, thereby determining whether to schedule the terminal to perform repeated transmission of the first PUSCH.

[0208] If the network-side device determines that the terminal does not support the retransmission of the second PUSCH, it can determine whether the terminal has the capability to retransmit the first PUSCH based on the LCID or reserved bit information carried by the received second PUSCH, and thus determine whether to schedule the terminal to perform the retransmission of the first PUSCH.

[0209] Specifically, determining whether the terminal can be scheduled to perform a first PUSCH retransmission based on the LCID or reserved bit information carried by the second PUSCH sent by the terminal includes: if the LCID or reserved bit information carried by the second PUSCH indicates that the terminal supports the first PUSCH retransmission, then the terminal can be scheduled to perform a first PUSCH retransmission; or if the LCID or reserved bit information carried by the second PUSCH indicates that the terminal does not support the first PUSCH retransmission, then the terminal cannot be scheduled to perform a first PUSCH retransmission.

[0210] After receiving the second PUSCH from the terminal, the network-side device determines whether the terminal supports repeated transmission of the first PUSCH by reading the LCID carried in the second PUSCH. For example, if the network-side device receives the second PUSCH and obtains the first LCID by decoding, it can determine that the terminal supports repeated transmission of the first PUSCH or has the capability to repeat the first PUSCH, and can then schedule the terminal to perform repeated transmission of the first PUSCH. If the network-side device receives the second PUSCH and obtains the second LCID by decoding, it can determine that the terminal does not support repeated transmission of the first PUSCH or does not have the capability to repeat the first PUSCH, and therefore cannot schedule the terminal to perform repeated transmission of the first PUSCH.

[0211] The mechanism in this application embodiment for determining whether a terminal can be scheduled to perform repeated transmission of the first PUSCH, such as determining whether the terminal can be scheduled to perform repeated transmission of the first PUSCH based on the terminal's second PUSCH repeated transmission capability and / or the second PUSCH sent by the terminal, enables the network-side device to perform early identification and differentiation between UEs that support and do not support repeated transmission of the first PUSCH during the random access phase. This allows for scheduling repeated transmission of the first PUSCH for UEs with limited first PUSCH coverage, improving UE uplink coverage performance, ensuring that the network-side device successfully receives the UE capability reporting information carried by the first PUSCH, and subsequently performing RRC reconfiguration for connected UEs.

[0212] In an embodiment of this application, the network-side device determines whether it can schedule the terminal to perform repeated transmission of the first PUSCH after successful random access, thereby scheduling repeated transmission of the first PUSCH for terminals with limited uplink coverage and improving the uplink coverage performance of the terminal.

[0213] Based on the same technical concept, this application also provides a repeat transmission device. This device can realize the terminal-side functions described in the foregoing embodiments.

[0214] See Figure 4 This is a schematic diagram of the structure of the repeating transmission device 400 provided in an embodiment of this application. Figure 4 As shown, the device 400 may include:

[0215] The first processing unit 410 is used to determine whether the first PUSCH retransmission can be performed; wherein the first PUSCH is the PUSCH transmitted after successful random access.

[0216] In some embodiments, the first PUSCH includes at least one of the following:

[0217] The first downlink control information (DCI) scheduled PUSCH after successful random access;

[0218] After successful random access, and before the terminal receives the first DCI scheduled PUSCH, the first configuration information is the terminal-specific PUSCH configuration information configured by Radio Resource Control (RRC).

[0219] The PUSCH of the first DCI scheduling after successful random access.

[0220] In some embodiments, the first DCI satisfies at least one of the following:

[0221] The first DCI is a DCI transmitted in the public search space;

[0222] The number of bits in the first DCI is a fixed value;

[0223] The first DCI is the DCI before the terminal receives the first configuration information.

[0224] In some embodiments, the first DCI is scrambled by a first identifier.

[0225] In some embodiments, the first processing unit is specifically configured to perform at least one of the following:

[0226] Determine whether the first PUSCH retransmission can be performed based on the terminal's second PUSCH retransmission capability;

[0227] Based on the second PUSCH sent by the terminal, determine whether the first PUSCH can be retransmitted.

[0228] The second PUSCH is the PUSCH scheduled during the random access process performed by the terminal.

[0229] In some embodiments, the first processing unit is specifically used for:

[0230] If the terminal reports to the network-side device that it supports the second PUSCH retransmission, it is determined that the first PUSCH retransmission can be performed.

[0231] or,

[0232] If the terminal reports to the network-side device that it does not support the retransmission of the second PUSCH, it is determined that the retransmission of the first PUSCH cannot be performed.

[0233] In some embodiments, the first processing unit is specifically used for:

[0234] Based on the Logical Channel Identifier (LCID) or reserved bit information carried by the second PUSCH sent by the terminal, determine whether the first PUSCH can be retransmitted.

[0235] The LCID or reserved bit information carried by the second PUSCH is used to report the retransmission capability of the first PUSCH.

[0236] In some embodiments, the first processing unit is specifically used for:

[0237] If the terminal reports to the network-side device that it supports the second PUSCH retransmission, it is determined that the first PUSCH retransmission can be performed.

[0238] or,

[0239] If the terminal reports to the network-side device that it does not support the retransmission of the second PUSCH, it is determined whether the retransmission of the first PUSCH can be performed based on the LCID or reserved bit information carried by the second PUSCH sent by the terminal.

[0240] In some embodiments, the first processing unit is specifically used for:

[0241] If the terminal reporting the LCID or reserved bit information carried by the second PUSCH supports the repeated transmission of the first PUSCH, it is determined that the repeated transmission of the first PUSCH can be performed.

[0242] or,

[0243] If the terminal reporting the LCID or reserved bit information carried by the second PUSCH does not support the repeated transmission of the first PUSCH, it is determined that the repeated transmission of the first PUSCH cannot be performed.

[0244] In some embodiments, the second PUSCH is the PUSCH of the random access procedure;

[0245] Wherein, the second PUSCH includes at least one of the following:

[0246] Random Access Response (RAR) uplink grant scheduling PUSCH;

[0247] Rollback of RAR uplink authorized scheduling PUSCH;

[0248] PUSCH scheduled by DCI scrambling with the temporary identifier TC-RNTI of the temporary cell radio network.

[0249] In some embodiments, the LCID includes at least one of the following:

[0250] The first LCID is used to report that the terminal supports repeated transmission of the first PUSCH.

[0251] The second LCID is used to report that the terminal does not support repeated transmission of the first PUSCH.

[0252] Wherein, the first LCID includes at least one LCID value; and / or, the second LCID includes at least one LCID value.

[0253] In some embodiments, where the first LCID includes at least two LCID values, each LCID value corresponds to indicating a first PUSCH retransmission number.

[0254] It should be noted that the apparatus provided in this application embodiment can implement all the method steps implemented in the method embodiment applied to the terminal, and can achieve the same technical effect. Here, the parts that are the same as those in the method embodiment and the beneficial effects will not be described in detail.

[0255] This application also provides a repeat transmission device. This device can realize the functions of the network-side device in the foregoing embodiments.

[0256] See Figure 5 This is a schematic diagram of the structure of the repeating transmission device 500 provided in an embodiment of this application. Figure 5 As shown, the device 500 may include:

[0257] The second processing unit 510 is used to determine whether the terminal can be scheduled to perform repeated transmission of the first PUSCH; wherein the first PUSCH is the PUSCH scheduled after successful random access.

[0258] In some embodiments, the first PUSCH includes at least one of the following:

[0259] The first PUSCH scheduled by the first DCI after successful random access.

[0260] After successful random access, and before the terminal receives the first DCI scheduled PUSCH, the first configuration information is the terminal-specific PUSCH configuration information configured by RRC.

[0261] The PUSCH of the first DCI scheduling after successful random access.

[0262] In some embodiments, the first DCI satisfies at least one of the following:

[0263] The first DCI is a DCI transmitted in the public search space;

[0264] The size of the first DCI is a fixed value;

[0265] The first DCI is the DCI before the terminal receives the first configuration information.

[0266] In some embodiments, the first DCI is scrambled by a first identifier.

[0267] In some embodiments, the second processing unit is specifically configured to perform at least one of the following:

[0268] Based on the terminal's second PUSCH retransmission capability, determine whether the terminal can be scheduled to perform the first PUSCH retransmission.

[0269] Based on the second PUSCH sent by the terminal, determine whether the terminal can be scheduled to perform a retransmission of the first PUSCH;

[0270] The second PUSCH is the PUSCH scheduled during the random access process performed by the terminal.

[0271] In some embodiments, the second processing unit is specifically used for:

[0272] If the terminal supports the second PUSCH retransmission, it is determined that the terminal can be scheduled to perform the first PUSCH retransmission.

[0273] or,

[0274] If the terminal does not support the second PUSCH retransmission, it is determined that the terminal cannot be scheduled to perform the first PUSCH retransmission.

[0275] In some embodiments, the second processing unit is specifically used for:

[0276] Based on the LCID or reserved bit information carried by the second PUSCH sent by the terminal, determine whether the terminal can be scheduled to perform repeated transmission of the first PUSCH;

[0277] The LCID or reserved bit information carried by the second PUSCH is used to report the retransmission capability of the first PUSCH.

[0278] In some embodiments, the second processing unit is specifically used for:

[0279] If the terminal supports the second PUSCH retransmission, it is determined that the terminal can be scheduled to perform the first PUSCH retransmission.

[0280] or,

[0281] If the terminal does not support the second PUSCH retransmission, it is determined whether the terminal can be scheduled to perform the first PUSCH retransmission based on the LCID or reserved bit information carried by the second PUSCH sent by the terminal.

[0282] In some embodiments, the second processing unit is specifically used for:

[0283] If the terminal reporting the LCID or reserved bit information carried by the second PUSCH supports the repeated transmission of the first PUSCH, it is determined that the terminal can be scheduled to perform the repeated transmission of the first PUSCH.

[0284] or,

[0285] If the terminal reporting the LCID or reserved bit information carried by the second PUSCH does not support the repeated transmission of the first PUSCH, it is determined that the terminal cannot be scheduled to perform the repeated transmission of the first PUSCH.

[0286] In some embodiments, the second PUSCH is the PUSCH of the random access procedure;

[0287] Wherein, the second PUSCH includes at least one of the following:

[0288] RAR uplink licensed scheduling PUSCH;

[0289] Rollback of RAR uplink authorized scheduling PUSCH;

[0290] PUSCH scheduled by DCI scrambling via TC-RNTI.

[0291] In some embodiments, the LCID includes at least one of the following:

[0292] The first LCID is used to report that the terminal supports repeated transmission of the first PUSCH.

[0293] The second LCID is used to report that the terminal does not support repeated transmission of the first PUSCH.

[0294] Wherein, the first LCID includes at least one LCID value; and / or, the second LCID includes at least one LCID value.

[0295] In some embodiments, where the first LCID includes at least two LCID values, each LCID value corresponds to indicating a first PUSCH retransmission number.

[0296] It should be noted that the apparatus provided in this application embodiment can implement all the method steps implemented in the method embodiment applied to the network side device, and can achieve the same technical effect. Here, the parts that are the same as those in the method embodiment and the beneficial effects will not be described in detail.

[0297] It should be noted that the division of units in the embodiments of this application is illustrative and only represents one logical functional division. In actual implementation, other division methods may be used. Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated units described above can be implemented in hardware or as software functional units.

[0298] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a processor-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0299] like Figure 6 As shown, embodiments of this application also provide a terminal, including: a memory 620, a transceiver 600, and a processor 610; wherein, the memory 620 is used to store computer programs; the transceiver 600 is used to receive and send data under the control of the processor 610; and the processor 610 is used to read the computer program in the memory and perform the following operations:

[0300] Determine whether the first PUSCH repeat transfer can be performed;

[0301] The first PUSCH is the PUSCH transmitted after a successful random access.

[0302] In some embodiments, the first PUSCH includes at least one of the following:

[0303] The first downlink control information (DCI) scheduled PUSCH after successful random access;

[0304] After successful random access, and before the terminal receives the first DCI scheduled PUSCH, the first configuration information is the terminal-specific PUSCH configuration information configured by RRC.

[0305] The PUSCH of the first DCI scheduling after successful random access.

[0306] In some embodiments, the first DCI satisfies at least one of the following:

[0307] The first DCI is a DCI transmitted in the public search space;

[0308] The number of bits in the first DCI is a fixed value;

[0309] The first DCI is the DCI before the terminal receives the first configuration information.

[0310] In some embodiments, the first DCI is scrambled by a first identifier.

[0311] In some embodiments, the processor is configured to read a computer program from the memory and perform at least one of the following operations:

[0312] Determine whether the first PUSCH retransmission can be performed based on the terminal's second PUSCH retransmission capability;

[0313] Based on the second PUSCH sent by the terminal, determine whether the first PUSCH can be retransmitted.

[0314] The second PUSCH is the PUSCH scheduled during the random access process performed by the terminal.

[0315] In some embodiments, the processor is configured to read a computer program from the memory and perform the following operations:

[0316] If the terminal reports to the network-side device that it supports the second PUSCH retransmission, it is determined that the first PUSCH retransmission can be performed.

[0317] or,

[0318] If the terminal reports to the network-side device that it does not support the retransmission of the second PUSCH, it is determined that the retransmission of the first PUSCH cannot be performed.

[0319] In some embodiments, the processor is configured to read a computer program from the memory and perform the following operations:

[0320] Based on the Logical Channel Identifier (LCID) or reserved bit information carried by the second PUSCH sent by the terminal, determine whether the first PUSCH can be retransmitted.

[0321] The LCID or reserved bit information carried by the second PUSCH is used to report the retransmission capability of the first PUSCH.

[0322] In some embodiments, the processor is configured to read a computer program from the memory and perform the following operations:

[0323] If the terminal reports to the network-side device that it supports the second PUSCH retransmission, it is determined that the first PUSCH retransmission can be performed.

[0324] or,

[0325] If the terminal reports to the network-side device that it does not support the retransmission of the second PUSCH, it is determined whether the retransmission of the first PUSCH can be performed based on the LCID or reserved bit information carried by the second PUSCH sent by the terminal.

[0326] In some embodiments, the processor is configured to read a computer program from the memory and perform the following operations:

[0327] If the terminal reporting the LCID or reserved bit information carried by the second PUSCH supports the repeated transmission of the first PUSCH, it is determined that the repeated transmission of the first PUSCH can be performed.

[0328] or,

[0329] If the terminal reporting the LCID or reserved bit information carried by the second PUSCH does not support the repeated transmission of the first PUSCH, it is determined that the repeated transmission of the first PUSCH cannot be performed.

[0330] In some embodiments, the second PUSCH is the PUSCH of the random access procedure;

[0331] Wherein, the second PUSCH includes at least one of the following:

[0332] RAR uplink licensed scheduling PUSCH;

[0333] Rollback of RAR uplink authorized scheduling PUSCH;

[0334] PUSCH scheduled by DCI scrambling via TC-RNTI.

[0335] In some embodiments, the LCID includes at least one of the following:

[0336] The first LCID is used to report that the terminal supports repeated transmission of the first PUSCH.

[0337] The second LCID is used to report that the terminal does not support repeated transmission of the first PUSCH.

[0338] Wherein, the first LCID includes at least one LCID value; and / or, the second LCID includes at least one LCID value.

[0339] In some embodiments, where the first LCID includes at least two LCID values, each LCID value corresponds to indicating a first PUSCH retransmission number.

[0340] Among them, Figure 6 In this context, the bus architecture can include any number of interconnected buses and bridges, specifically linking various circuits of one or more processors represented by processor 610 and memory represented by memory 620 together. The bus architecture can also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. The bus interface provides an interface. Transceiver 600 can be multiple components, including transmitters and transceivers, providing a unit for communicating with various other devices over a transmission medium, including wireless channels, wired channels, optical fibers, etc. For different user equipment, user interface 630 can also be an interface capable of connecting external or internal devices, including but not limited to keypads, displays, speakers, microphones, joysticks, etc.

[0341] The processor 610 is responsible for managing the bus architecture and general processing, while the memory 620 can store the data used by the processor 610 when performing operations.

[0342] In some embodiments, the processor 610 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a complex programmable logic device (CPLD), and the processor may also adopt a multi-core architecture.

[0343] The processor executes any of the methods described in the embodiments of this application according to the obtained executable instructions by calling a computer program stored in memory. The processor and memory may also be physically separated.

[0344] It should be noted that the terminal provided in this application embodiment can implement all the method steps implemented in the method embodiment applied to the terminal, and can achieve the same technical effect. Here, the parts that are the same as those in the method embodiment and the beneficial effects will not be described in detail.

[0345] like Figure 7 As shown, embodiments of this application also provide a network-side device, including: a memory 720, a transceiver 700, and a processor 710; wherein, the memory 720 is used to store computer programs; the transceiver 700 is used to receive and transmit data under the control of the processor 710; and the processor 710 is used to read the computer program in the memory and perform the following operations:

[0346] Determine whether the terminal can be scheduled to perform the first PUSCH retransmission; wherein the first PUSCH is the PUSCH scheduled after successful random access.

[0347] In some embodiments, the first PUSCH includes at least one of the following:

[0348] The first PUSCH scheduled by the first DCI after successful random access.

[0349] After successful random access, and before the terminal receives the first DCI scheduled PUSCH, the first configuration information is the terminal-specific PUSCH configuration information configured by RRC.

[0350] The PUSCH of the first DCI scheduling after successful random access.

[0351] In some embodiments, the first DCI satisfies at least one of the following:

[0352] The first DCI is a DCI transmitted in the public search space;

[0353] The size of the first DCI is a fixed value;

[0354] The first DCI is the DCI before the terminal receives the first configuration information.

[0355] In some embodiments, the first DCI is scrambled by a first identifier.

[0356] In some embodiments, the processor is configured to read a computer program from the memory and perform at least one of the following operations:

[0357] Based on the terminal's second PUSCH retransmission capability, determine whether the terminal can be scheduled to perform the first PUSCH retransmission.

[0358] Based on the second PUSCH sent by the terminal, determine whether the terminal can be scheduled to perform a retransmission of the first PUSCH;

[0359] The second PUSCH is the PUSCH scheduled during the random access process performed by the terminal.

[0360] In some embodiments, the processor is configured to read a computer program from the memory and perform the following operations:

[0361] If the terminal supports the second PUSCH retransmission, it is determined that the terminal can be scheduled to perform the first PUSCH retransmission.

[0362] or,

[0363] If the terminal does not support the second PUSCH retransmission, it is determined that the terminal cannot be scheduled to perform the first PUSCH retransmission.

[0364] In some embodiments, the processor is configured to read a computer program from the memory and perform the following operations:

[0365] Based on the LCID or reserved bit information carried by the second PUSCH sent by the terminal, determine whether the terminal can be scheduled to perform repeated transmission of the first PUSCH;

[0366] The LCID or reserved bit information carried by the second PUSCH is used to report the retransmission capability of the first PUSCH.

[0367] In some embodiments, the processor is configured to read a computer program from the memory and perform the following operations:

[0368] If the terminal supports the second PUSCH retransmission, it is determined that the terminal can be scheduled to perform the first PUSCH retransmission.

[0369] or,

[0370] If the terminal does not support the second PUSCH retransmission, it is determined whether the terminal can be scheduled to perform the first PUSCH retransmission based on the LCID or reserved bit information carried by the second PUSCH sent by the terminal.

[0371] In some embodiments, the processor is configured to read a computer program from the memory and perform the following operations:

[0372] If the terminal reporting the LCID or reserved bit information carried by the second PUSCH supports the repeated transmission of the first PUSCH, it is determined that the terminal can be scheduled to perform the repeated transmission of the first PUSCH.

[0373] or,

[0374] If the terminal reporting the LCID or reserved bit information carried by the second PUSCH does not support the repeated transmission of the first PUSCH, it is determined that the terminal cannot be scheduled to perform the repeated transmission of the first PUSCH.

[0375] In some embodiments, the second PUSCH is the PUSCH of the random access procedure;

[0376] Wherein, the second PUSCH includes at least one of the following:

[0377] RAR uplink licensed scheduling PUSCH;

[0378] Rollback of RAR uplink authorized scheduling PUSCH;

[0379] PUSCH scheduled by DCI scrambling via TC-RNTI.

[0380] In some embodiments, the LCID includes at least one of the following:

[0381] The first LCID is used to report that the terminal supports repeated transmission of the first PUSCH.

[0382] The second LCID is used to report that the terminal does not support repeated transmission of the first PUSCH.

[0383] Wherein, the first LCID includes at least one LCID value; and / or, the second LCID includes at least one LCID value.

[0384] In some embodiments, where the first LCID includes at least two LCID values, each LCID value corresponds to indicating a first PUSCH retransmission number.

[0385] Among them, Figure 7In this context, the bus architecture can include any number of interconnected buses and bridges, specifically linking various circuits together, represented by one or more processors (processor 710) and memory (memory 720). The bus architecture can also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. The bus interface provides an interface. The transceiver 700 can be multiple elements, including transmitters and transceivers, providing a unit for communicating with various other devices over transmission media, including wireless channels, wired channels, optical fibers, etc. The processor is responsible for managing the bus architecture and general processing. The processor 710 is responsible for managing the bus architecture and general processing, and the memory 720 can store data used by the processor 710 during operation.

[0386] The processor 710 can be a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a complex programmable logic device (CPLD). The processor can also adopt a multi-core architecture.

[0387] It should be noted that the device provided in this application embodiment can implement all the method steps implemented in the method embodiment applied to the network side device, and can achieve the same technical effect. Here, the parts that are the same as those in the method embodiment and the beneficial effects will not be described in detail.

[0388] This application also provides a processing apparatus, including a processor and an interface. The processor can be used to execute the methods described in the above method embodiments.

[0389] It should be understood that the aforementioned processing device can be a chip. For example, the processing device can be a field-programmable gate array (FPGA), can include an application-specific integrated circuit (ASIC), can be a system-on-a-chip (SoC), can be a central processor unit (CPU), can be a network processor (NP), can be a digital signal processor (DSP), can be a microcontroller unit (MCU), can be a programmable logic device (PLD), or other integrated chips.

[0390] In implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software. The steps of the method disclosed in the embodiments of this application can be executed by a hardware processor, or by a combination of hardware and software modules within the processor. The software modules can reside in mature storage media in the art, such as random access registers, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. Since the storage medium is located in memory, the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method; to avoid repetition, these will not be described in detail here.

[0391] It should be noted that the processor in the embodiments of this application can be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0392] It should also be understood that the memory mentioned in the embodiments of this application can be volatile memory and / or non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM). For example, RAM can be used as an external cache. By way of example and not limitation, RAM includes various forms such as: static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM). It should be noted that when the processor is a general-purpose processor, DSP, ASIC, FPGA, or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, the memory (storage module) can be integrated into the processor.

[0393] Based on the same concept, this application also provides a computer program product, which includes a computer program or instructions that, when run on a computer, cause the computer to perform the methods provided in the above embodiments.

[0394] Based on the same concept, this application also provides a chip including a processor coupled to a memory for executing a computer program or instructions stored in the memory. When the processor executes the computer program or instructions, the method provided in the above embodiments is implemented.

[0395] Based on the same concept, a specific embodiment of this application also provides a processor-readable storage medium storing a program for causing the processor to execute the steps of the above-described repeated transmission method, and achieving the same technical effect. To avoid repetition, it will not be described again here.

[0396] The readable storage medium can be any available medium or data storage device that the processor can access, including but not limited to magnetic memory (e.g., floppy disk, hard disk, magnetic tape, magneto-optical disk (MO)), optical memory (e.g., CD, DVD, BD, HVD), and semiconductor memory (e.g., ROM, EPROM, EEPROM, non-volatile memory (NAND FLASH), solid-state drive (SSD)).

[0397] like Figure 8 This application provides a chip system 800. The chip system 800 (or processing system) includes logic circuitry 810 and an input / output interface 820. The logic circuitry 810 can be the processing circuitry within the chip system 800. The logic circuitry 810 can be coupled to a memory unit, calling instructions from the memory unit, enabling the chip system 800 to implement the methods and functions of the embodiments of this application. The input / output interface 820 can be the input / output circuitry within the chip system 800, outputting processed information or inputting data or signaling information to be processed into the chip system 800 for processing.

[0398] As one approach, the chip system 800 is used to implement the operations described in the various method embodiments above. For example, the logic circuit 810 is used to implement the relevant operations performed by the terminal in the method embodiments above, such as... Figures 2 to 3 The relevant operations performed by the terminal in any of the illustrated embodiments; the input / output interface 820 is used to implement the sending and / or receiving related operations of the terminal in the above method embodiments, such as... Figures 2 to 3 The sending and / or receiving related operations performed by the terminal in any of the illustrated embodiments.

[0399] It should be noted that the technical solutions provided in this application can be applied to a variety of systems. For example, applicable systems may include Long Term Evolution (LTE) systems, LTE Frequency Division Duplex (FDD) systems, LTE Time Division Duplex (TDD) systems, Long Term Evolution Advanced (LTE-A) systems, Universal Mobile Telecommunication System (UMTS), Worldwide Interoperability for Microwave Access (WiMAX) systems, 5G New Radio (NR) systems and their evolved communication systems, and 6G (sixth generation mobile communication technology) systems. These systems may include terminal equipment and network equipment. The systems may also include a core network component, such as the Evolved Packet Core (EPC) and the 5G Core Network (5GC).

[0400] The terminal devices involved in the embodiments of this application can be devices that provide voice and / or data connectivity to users, handheld devices with wireless connectivity, or other processing devices connected to a wireless modem. The names of the terminal devices may differ in different systems; for example, in 5G or 6G systems, the terminal device may be called User Equipment (UE). Wireless terminal devices can be USB storage devices, other personal computer memory devices, and dongles. They can also communicate with one or more core networks (CNs) via a Radio Access Network (RAN). Wireless terminal devices can be mobile terminal devices, such as mobile phones (or "cellular" phones) and computers with mobile terminal devices. For example, they can be portable, pocket-sized, handheld, computer-embedded, or vehicle-mounted mobile devices that exchange voice and / or data with the radio access network. Examples of such devices include Personal Communication Service (PCS) phones, cordless phones, Session Initiated Protocol (SIP) phones, Wireless Local Loop (WLL) stations, Personal Digital Assistants (PDAs), personal computers, tablets, and Machine-type Communication (MTC) terminal devices. Wireless terminal devices can also be referred to as systems, subscriber units, subscriber stations, mobile stations, mobile devices, remote stations, access points, remote terminals, access terminals, user terminals, user agents, user devices, and wireless access devices and routers / modems that meet the limitations of this definition; however, this application does not limit the scope of the embodiments.

[0401] The network device involved in this application embodiment can be a base station, which may include multiple cells providing services to terminals. Depending on the specific application, the base station may also be called an access point, or a device in the access network that communicates with wireless terminal devices through one or more sectors on the air interface, or other names. The network device can be used to exchange received air frames with Internet Protocol (IP) packets, acting as a router between the wireless terminal device and the rest of the access network, where the rest of the access network may include an Internet Protocol (IP) communication network. The network device can also coordinate the attribute management of the air interface. For example, the network device involved in this application embodiment can be an evolved Node B (eNB or e-NodeB) in a long term evolution (LTE) system, a 5G base station (gNB) in a next generation system, or a Home evolved Node B (HeNB), relay node, femto, pico, network testing equipment, etc., and is not limited in this application embodiment. In some network architectures, network devices may include centralized unit (CU) nodes and distributed unit (DU) nodes, which may also be geographically separated.

[0402] Network devices and terminal devices can each use one or more antennas to perform Multiple-Input Multiple-Output (MIMO) transmission. MIMO transmission can be single-user MIMO or multi-user MIMO. Depending on the configuration and number of antenna combinations, MIMO transmission can be 2D-MIMO, 3D-MIMO, FD-MIMO, or massive-MIMO, and can also be diversity transmission, precoding transmission, or beamforming transmission, etc.

[0403] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage and optical storage) containing computer-usable program code.

[0404] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-executable instructions. These computer-executable instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or one or more blocks of the block diagrams.

[0405] These processor-executable instructions may also be stored in a processor-readable memory that can instruct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the processor-readable memory produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more blocks of a block diagram.

[0406] These processor-executable instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more blocks of a block diagram.

[0407] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for repeated transmission, characterized in that, Applied to terminals, including: Determine whether the first physical uplink shared channel (PUSCH) retransmission can be performed; The first PUSCH is the PUSCH transmitted after a successful random access.

2. The method according to claim 1, characterized in that, The first PUSCH includes at least one of the following: The first downlink control information (DCI) scheduled PUSCH after successful random access; After successful random access, and before the terminal receives the first DCI scheduled PUSCH, the first configuration information is the terminal-specific PUSCH configuration information configured by Radio Resource Control (RRC). The PUSCH of the first DCI scheduling after successful random access.

3. The method according to claim 2, characterized in that, The first DCI satisfies at least one of the following: The first DCI is a DCI transmitted in the public search space; The number of bits in the first DCI is a fixed value; The first DCI is the DCI before the terminal receives the first configuration information.

4. The method according to claim 2 or 3, characterized in that, The first DCI is scrambled using the first identifier.

5. The method according to claim 1, characterized in that, Determining whether a first physical uplink shared channel (PUSCH) retransmission can be performed includes at least one of the following: Determine whether the first PUSCH retransmission can be performed based on the terminal's second PUSCH retransmission capability; Based on the second PUSCH sent by the terminal, determine whether the first PUSCH can be retransmitted. The second PUSCH is the PUSCH scheduled during the random access process performed by the terminal.

6. The method according to claim 5, characterized in that, The step of determining whether the first PUSCH retransmission can be performed based on the terminal's second PUSCH retransmission capability includes: If the terminal reports to the network-side device that it supports the second PUSCH retransmission, it is determined that the first PUSCH retransmission can be performed. or, If the terminal reports to the network-side device that it does not support the retransmission of the second PUSCH, it is determined that the retransmission of the first PUSCH cannot be performed.

7. The method according to claim 5, characterized in that, The step of determining whether the first PUSCH can be retransmitted based on the second PUSCH sent by the terminal includes: Based on the Logical Channel Identifier (LCID) or reserved bit information carried by the second PUSCH sent by the terminal, determine whether the first PUSCH can be retransmitted. The LCID or reserved bit information carried by the second PUSCH is used to report the retransmission capability of the first PUSCH.

8. The method according to claim 5, characterized in that, The determination of whether the first physical uplink shared channel (PUSCH) retransmission can be performed includes: If the terminal reports to the network-side device that it supports the second PUSCH retransmission, it is determined that the first PUSCH retransmission can be performed. or, If the terminal reports to the network-side device that it does not support the retransmission of the second PUSCH, it is determined whether the retransmission of the first PUSCH can be performed based on the LCID or reserved bit information carried by the second PUSCH sent by the terminal.

9. The method according to claim 7 or 8, characterized in that, The step of determining whether to perform a retransmission of the first PUSCH based on the LCID or reserved bit information carried by the second PUSCH sent by the terminal includes: If the terminal reporting the LCID or reserved bit information carried by the second PUSCH supports the repeated transmission of the first PUSCH, it is determined that the repeated transmission of the first PUSCH can be performed. or, If the terminal reporting the LCID or reserved bit information carried by the second PUSCH does not support the repeated transmission of the first PUSCH, it is determined that the repeated transmission of the first PUSCH cannot be performed.

10. The method according to any one of claims 5 to 9, characterized in that, The second PUSCH is the PUSCH for the random access procedure; Wherein, the second PUSCH includes at least one of the following: Random Access Response (RAR) uplink grant scheduling PUSCH; Rollback of RAR uplink authorized scheduling PUSCH; PUSCH scheduled by DCI scrambling with the temporary identifier TC-RNTI of the temporary cell radio network.

11. The method according to any one of claims 7 to 9, characterized in that, The LCID includes at least one of the following: The first LCID is used to report that the terminal supports repeated transmission of the first PUSCH. The second LCID is used to report that the terminal does not support repeated transmission of the first PUSCH. Wherein, the first LCID includes at least one LCID value; and / or, the second LCID includes at least one LCID value.

12. The method according to claim 11, characterized in that, When the first LCID includes at least two LCID values, each LCID value corresponds to an indication of a first PUSCH retransmission number.

13. A method for repeated transmission, characterized in that, Applied to network-side devices, including: Determine whether the terminal can be scheduled to perform the first PUSCH retransmission; The first PUSCH is the PUSCH scheduled after a successful random access.

14. The method according to claim 13, characterized in that, The first PUSCH includes at least one of the following: The first PUSCH scheduled by the first DCI after successful random access. After successful random access, and before the terminal receives the first DCI scheduled PUSCH, the first configuration information is the terminal-specific PUSCH configuration information configured by RRC. The PUSCH of the first DCI scheduling after successful random access.

15. The method according to claim 14, characterized in that, The first DCI satisfies at least one of the following: The first DCI is a DCI transmitted in the public search space; The size of the first DCI is a fixed value; The first DCI is the DCI before the terminal receives the first configuration information.

16. The method according to claim 14 or 15, characterized in that, The first DCI is scrambled using the first identifier.

17. The method according to claim 13, characterized in that, Determining whether the terminal can be scheduled to perform the first PUSCH retransmission includes at least one of the following: Based on the terminal's second PUSCH retransmission capability, determine whether the terminal can be scheduled to perform the first PUSCH retransmission. Based on the second PUSCH sent by the terminal, determine whether the terminal can be scheduled to perform a retransmission of the first PUSCH; The second PUSCH is the PUSCH scheduled during the random access process performed by the terminal.

18. The method according to claim 17, characterized in that, The step of determining whether the terminal can be scheduled to perform the first PUSCH retransmission based on the terminal's second PUSCH retransmission capability includes: If the terminal supports the second PUSCH retransmission, it is determined that the terminal can be scheduled to perform the first PUSCH retransmission. or, If the terminal does not support the second PUSCH retransmission, it is determined that the terminal cannot be scheduled to perform the first PUSCH retransmission.

19. The method according to claim 17, characterized in that, The step of determining whether the terminal can be scheduled to perform a retransmission of the first PUSCH based on the second PUSCH sent by the terminal includes: Based on the LCID or reserved bit information carried by the second PUSCH sent by the terminal, determine whether the terminal can be scheduled to perform repeated transmission of the first PUSCH; The LCID or reserved bit information carried by the second PUSCH is used to report the retransmission capability of the first PUSCH.

20. The method according to claim 17, characterized in that, Determining whether the terminal can be scheduled to perform the first PUSCH retransmission includes: If the terminal supports the second PUSCH retransmission, it is determined that the terminal can be scheduled to perform the first PUSCH retransmission. or, If the terminal does not support the second PUSCH retransmission, it is determined whether the terminal can be scheduled to perform the first PUSCH retransmission based on the LCID or reserved bit information carried by the second PUSCH sent by the terminal.

21. The method according to claim 19 or 20, characterized in that, The step of determining whether the terminal can be scheduled to perform a repeated transmission of the first PUSCH based on the LCID or reserved bit information carried by the second PUSCH sent by the terminal includes: If the terminal reporting the LCID or reserved bit information carried by the second PUSCH supports the repeated transmission of the first PUSCH, it is determined that the terminal can be scheduled to perform the repeated transmission of the first PUSCH. or, If the terminal reporting the LCID or reserved bit information carried by the second PUSCH does not support the repeated transmission of the first PUSCH, it is determined that the terminal cannot be scheduled to perform the repeated transmission of the first PUSCH.

22. The method according to any one of claims 17 to 21, characterized in that, The second PUSCH is the PUSCH for the random access procedure; Wherein, the second PUSCH includes at least one of the following: RAR uplink licensed scheduling PUSCH; Rollback of RAR uplink authorized scheduling PUSCH; PUSCH scheduled by DCI scrambling via TC-RNTI.

23. The method according to any one of claims 19 to 21, characterized in that, The LCID includes at least one of the following: The first LCID is used to report that the terminal supports repeated transmission of the first PUSCH. The second LCID is used to report that the terminal does not support repeated transmission of the first PUSCH. Wherein, the first LCID includes at least one LCID value; and / or, the second LCID includes at least one LCID value.

24. The method according to claim 23, characterized in that, When the first LCID includes at least two LCID values, each LCID value corresponds to an indication of a first PUSCH retransmission number.

25. A terminal, characterized in that, include: Memory, transceiver, processor: Memory, used to store computer programs; A transceiver, used to receive and send data under the control of the processor; Processor, configured to read the computer program in the memory and perform the following operations: Determine whether the first PUSCH repeat transfer can be performed; The first PUSCH is the PUSCH transmitted after a successful random access.

26. The terminal according to claim 25, characterized in that, The first PUSCH includes at least one of the following: The first downlink control information (DCI) scheduled PUSCH after successful random access; After successful random access, and before the terminal receives the first DCI scheduled PUSCH, the first configuration information is the terminal-specific PUSCH configuration information configured by RRC. The PUSCH of the first DCI scheduling after successful random access.

27. The terminal according to claim 26, characterized in that, The first DCI satisfies at least one of the following: The first DCI is a DCI transmitted in the public search space; The number of bits in the first DCI is a fixed value; The first DCI is the DCI before the terminal receives the first configuration information.

28. The terminal according to claim 26 or 27, characterized in that, The first DCI is scrambled using the first identifier.

29. The terminal according to claim 25, characterized in that, The processor is configured to read a computer program from the memory and perform at least one of the following operations: Determine whether the first PUSCH retransmission can be performed based on the terminal's second PUSCH retransmission capability; Based on the second PUSCH sent by the terminal, determine whether the first PUSCH can be retransmitted. The second PUSCH is the PUSCH scheduled during the random access process performed by the terminal.

30. The terminal according to claim 29, characterized in that, The processor is used to read the computer program in the memory and perform the following operations: If the terminal reports to the network-side device that it supports the second PUSCH retransmission, it is determined that the first PUSCH retransmission can be performed. or, If the terminal reports to the network-side device that it does not support the retransmission of the second PUSCH, it is determined that the retransmission of the first PUSCH cannot be performed.

31. The terminal according to claim 29, characterized in that, The processor is used to read the computer program in the memory and perform the following operations: Based on the Logical Channel Identifier (LCID) or reserved bit information carried by the second PUSCH sent by the terminal, determine whether the first PUSCH can be retransmitted. The LCID or reserved bit information carried by the second PUSCH is used to report the retransmission capability of the first PUSCH.

32. The terminal according to claim 29, characterized in that, The processor is used to read the computer program in the memory and perform the following operations: If the terminal reports to the network-side device that it supports the second PUSCH retransmission, it is determined that the first PUSCH retransmission can be performed. or, If the terminal reports to the network-side device that it does not support the retransmission of the second PUSCH, it is determined whether the retransmission of the first PUSCH can be performed based on the LCID or reserved bit information carried by the second PUSCH sent by the terminal.

33. The terminal according to claim 31 or 32, characterized in that, The processor is used to read the computer program in the memory and perform the following operations: If the terminal reporting the LCID or reserved bit information carried by the second PUSCH supports the repeated transmission of the first PUSCH, it is determined that the repeated transmission of the first PUSCH can be performed. or, If the terminal reporting the LCID or reserved bit information carried by the second PUSCH does not support the repeated transmission of the first PUSCH, it is determined that the repeated transmission of the first PUSCH cannot be performed.

34. The terminal according to any one of claims 29 to 33, characterized in that, The second PUSCH is the PUSCH for the random access procedure; Wherein, the second PUSCH includes at least one of the following: RAR uplink licensed scheduling PUSCH; Rollback of RAR uplink authorized scheduling PUSCH; PUSCH scheduled by DCI scrambling via TC-RNTI.

35. The terminal according to any one of claims 31 to 33, characterized in that, The LCID includes at least one of the following: The first LCID is used to report that the terminal supports repeated transmission of the first PUSCH. The second LCID is used to report that the terminal does not support repeated transmission of the first PUSCH. Wherein, the first LCID includes at least one LCID value; and / or, the second LCID includes at least one LCID value.

36. The terminal according to claim 35, characterized in that, When the first LCID includes at least two LCID values, each LCID value corresponds to an indication of a first PUSCH retransmission number.

37. A network-side device, characterized in that, include: Memory, transceiver, processor: Memory, used to store computer programs; A transceiver, used to receive and send data under the control of the processor; Processor, configured to read the computer program in the memory and perform the following operations: Determine whether the terminal can be scheduled to perform the first PUSCH retransmission; The first PUSCH is the PUSCH scheduled after a successful random access.

38. The device according to claim 37, characterized in that, The first PUSCH includes at least one of the following: The first PUSCH scheduled by the first DCI after successful random access. After successful random access, and before the terminal receives the first DCI scheduled PUSCH, the first configuration information is the terminal-specific PUSCH configuration information configured by RRC. The PUSCH of the first DCI scheduling after successful random access.

39. The device according to claim 38, characterized in that, The first DCI satisfies at least one of the following: The first DCI is a DCI transmitted in the public search space; The size of the first DCI is a fixed value; The first DCI is the DCI before the terminal receives the first configuration information.

40. The device according to claim 38 or 39, characterized in that, The first DCI is scrambled using the first identifier.

41. The device according to claim 37, characterized in that, The processor is configured to read a computer program from the memory and perform at least one of the following operations: Based on the terminal's second PUSCH retransmission capability, determine whether the terminal can be scheduled to perform the first PUSCH retransmission. Based on the second PUSCH sent by the terminal, determine whether the terminal can be scheduled to perform a retransmission of the first PUSCH; The second PUSCH is the PUSCH scheduled during the random access process performed by the terminal.

42. The device according to claim 41, characterized in that, The processor is used to read the computer program in the memory and perform the following operations: If the terminal supports the second PUSCH retransmission, it is determined that the terminal can be scheduled to perform the first PUSCH retransmission. or, If the terminal does not support the second PUSCH retransmission, it is determined that the terminal cannot be scheduled to perform the first PUSCH retransmission.

43. The device according to claim 41, characterized in that, The processor is used to read the computer program in the memory and perform the following operations: Based on the LCID or reserved bit information carried by the second PUSCH sent by the terminal, determine whether the terminal can be scheduled to perform repeated transmission of the first PUSCH; The LCID or reserved bit information carried by the second PUSCH is used to report the retransmission capability of the first PUSCH.

44. The device according to claim 41, characterized in that, The processor is used to read the computer program in the memory and perform the following operations: If the terminal supports the second PUSCH retransmission, it is determined that the terminal can be scheduled to perform the first PUSCH retransmission. or, If the terminal does not support the second PUSCH retransmission, it is determined whether the terminal can be scheduled to perform the first PUSCH retransmission based on the LCID or reserved bit information carried by the second PUSCH sent by the terminal.

45. The device according to claim 43 or 44, characterized in that, The processor is used to read the computer program in the memory and perform the following operations: If the terminal reporting the LCID or reserved bit information carried by the second PUSCH supports the repeated transmission of the first PUSCH, it is determined that the terminal can be scheduled to perform the repeated transmission of the first PUSCH. or, If the terminal reporting the LCID or reserved bit information carried by the second PUSCH does not support the repeated transmission of the first PUSCH, it is determined that the terminal cannot be scheduled to perform the repeated transmission of the first PUSCH.

46. ​​The device according to any one of claims 41 to 45, characterized in that, The second PUSCH is the PUSCH for the random access procedure; Wherein, the second PUSCH includes at least one of the following: RAR uplink licensed scheduling PUSCH; Rollback of RAR uplink authorized scheduling PUSCH; PUSCH scheduled by DCI scrambling via TC-RNTI.

47. The device according to any one of claims 43 to 45, characterized in that, The LCID includes at least one of the following: The first LCID is used to report that the terminal supports repeated transmission of the first PUSCH. The second LCID is used to report that the terminal does not support repeated transmission of the first PUSCH. Wherein, the first LCID includes at least one LCID value; and / or, the second LCID includes at least one LCID value.

48. The device according to claim 47, characterized in that, When the first LCID includes at least two LCID values, each LCID value corresponds to an indication of a first PUSCH retransmission number.

49. A repetitive transmission device, characterized in that, include: The first processing unit is used to determine whether the first PUSCH repeat transmission can be performed; The first PUSCH is the PUSCH transmitted after a successful random access.

50. A repetitive transmission device, characterized in that, include: The second processing unit is used to determine whether the terminal can be scheduled to perform the first PUSCH retransmission. The first PUSCH is the PUSCH scheduled after a successful random access.

51. A processor-readable storage medium, characterized in that, The processor-readable storage medium stores a program for causing the processor to perform the method according to any one of claims 1 to 12, or to perform the method according to any one of claims 13 to 24.

52. A chip, characterized in that, The method includes a processor coupled to a memory for executing a computer program or instructions stored in the memory, wherein when the processor executes the computer program or instructions, the method as described in any one of claims 1 to 24 is performed.

Images