Method for scheduling of physical uplink shared channel
By receiving and scheduling the DCI signal of subsequent PUSCH transmissions after the last PUSCH transmission in HARQ processing, the complexity of DCI scheduling with TC-RNTI and CS-RNTI scrambling in the prior art is solved, and more flexible PUSCH scheduling is achieved.
Patent Information
- Application Number
- CN202180089332.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2021-01-14
- Filing Date
- 2021-12-21
- Publication Date
- 2026-05-15
- Estimated Expiration
- 2041-12-21
AI Technical Summary
Existing 3GPP specifications have limitations on PUSCH scheduling and fail to effectively handle PUSCH scheduled by DCI scrambled by TC-RNTI and CS-RNTI, leading to increased complexity in UE implementation.
The paper proposes to receive and schedule the DCI signals of subsequent PUSCH transmissions after the last PUSCH transmission of a given HARQ process, including DCI formats scrambled with TC-RNTI and CS-RNTI, and to skip the DCI signals received before the last PUSCH transmission.
It simplifies the UE's PUSCH scheduling process, reduces implementation complexity, and improves scheduling flexibility.
Smart Images

Figure CN116746249B_ABST
Abstract
Description
[0001] Cross-reference to related applications
[0002] This disclosure is a part of a non-provisional application claiming priority to U.S. Patent Application No. 63 / 137,178, filed January 14, 2021, the contents of which are incorporated herein by reference in their entirety. Technical Field
[0003] This disclosure generally relates to mobile communications, and more particularly to the process of scheduling a physical uplink shared channel (PUSCH) in mobile communications. Background Technology
[0004] Unless otherwise stated herein, the methods described in this section are not prior art to the claims listed below, and are not admitted as prior art by virtue of being included in this section.
[0005] In mobile communications such as those based on the 3rd Generation Partnership Project (3GPP) specifications for 5th Generation (5G) New Radio (NR) and above, there is a limitation in 3GPP specification Rep. 15 (Rel-15) regarding scheduling user equipment (UE) using another dynamic PUSCH before the first PUSCH with the same hybrid automatic repeat request (HARQ) processing identification (ID) has been sent. Specifically, this limitation states that the UE is not expected to be scheduled to send another PUSCH for a given HARQ processing by sending downlink control information (DCI) format 0_0 or 0_1 scrambled with either the cell radio network temporary identifier (C-RNTI) or the modulation coding scheme (MCS) C-RNTI (MCS-C-RNTI). The intention of this restriction is to simplify UE implementation by excluding back-to-back scheduling of PUSCHs with the same HARQ processing ID. Back-to-back scheduling means that the UE will not want to schedule another DCI for a PUSCH with a given HARQ processing ID unless the last PUSCH for that HARQ processing ID has already been sent. The current 3GPP specification's restriction focuses only on PUSCHs scheduled using DCIs scrambled by C-RNTI or MCS-C-RNTI.
[0006] From the UE implementation perspective, dynamically scheduled PUSCHs using DCIs scrambled with other radio network temporary identifiers (RNTIs) typically require the same complexity to handle "back-to-back" PUSCH scheduling. However, there are two cases of dynamically scheduled PUSCHs that are not within the current limitations. In the first case, DCIs scrambled with the temporary cell-RNTI (TC-RNTI) used to schedule the initial transmission and retransmission of Msg3 are currently not included in this limitation. These are dynamically scheduled PUSCHs, and the UE behavior is the same as for PUSCHs scheduled using DCIs scrambled with C-RNTIs. In the second case, DCIs scrambled with the configured scheduling RNTI (CS-RNTI) are currently not included in this limitation when a second (or later) retransmission of a configured grant PUSCH (CG-PUSCH) is used. Similar to the first case, subsequent retransmissions of CG-PUSCHs are considered dynamic PUSCHs. Therefore, a solution is needed related to a new process for PUSCH scheduling in mobile communications. Summary of the Invention
[0007] The following summary is merely illustrative and not intended to be limiting in any way. That is, it is provided to illustrate the concepts, highlights, benefits, and advantages of the novel and non-obvious techniques described herein. The selected implementations are further described in the detailed description below. Therefore, the following summary is not intended to identify the essential features of the claimed subject matter, nor is it intended to define the scope of the claimed subject matter.
[0008] The purpose of this disclosure is to propose solutions and schemes for addressing the aforementioned problems. Specifically, it is believed that the various schemes proposed in this disclosure resolve problems related to the process of PUSCH scheduling in mobile communications. More specifically, the various schemes proposed according to this disclosure aim to extend the current limitations to PUSCH scheduled by DCI scrambled by TC-RNTI and CS-RNTI (except for the first retransmission of CG-PUSCH).
[0009] In one aspect, a method includes: performing the last PUSCH transmission of one or more PUSCH transmissions associated with a given HARQ process. The method further includes: receiving, after but not before, a DCI signal for subsequent PUSCH transmissions scrambled by a specific RNTI and scheduled for the given HARQ process.
[0010] In another aspect, a method includes: the last PUSCH transmission in one or more PUSCH transmissions that perform DCI signal scheduling and are associated with a first HARQ process. The method further includes: receiving a DCI signal for a subsequent PUSCH transmission scrambled by a specific RNTI and scheduling the first HARQ process. The method also includes: skipping the subsequent PUSCH transmission if the DCI signal is received before the last PUSCH transmission.
[0011] In another aspect, a method includes: performing the last of one or more PUSCH transmissions associated with a first HARQ process and scheduled either by uplink (UL) authorization in a random access (RA) response or by a DCI signal scrambled by TC-RNTI. The method further includes: receiving a DCI signal scrambled by TC-RNTI and scheduled for a subsequent PUSCH transmission that is part of the first HARQ process. The method also includes: skipping the subsequent PUSCH transmission if the DCI signal is received before the last PUSCH transmission.
[0012] It is worth noting that although the descriptions provided herein may be within the context of certain radio access technologies, networks, and network topologies (such as 5G / NR), the proposed concepts, schemes, and any variations / derivatives thereof can be implemented, used, and carried out in other types of radio access technologies, networks, and network topologies, such as (e.g., but not limited to): Long-Term Evolution (LTE), LTE-Advanced, LTE-Advanced Pro, Internet of Things (IoT), Narrowband Internet of Things (NB-IoT), Industrial Internet of Things (IIoT), Vehicle-to-Everything (V2X), and non-terrestrial network (NTN) communications. Therefore, the scope of this disclosure is not limited to the examples described herein. Attached Figure Description
[0013] The accompanying drawings are included to provide a further understanding of this disclosure, and are incorporated in and constitute a part of this disclosure. The drawings illustrate implementations of this disclosure and, together with the description, serve to explain the principles of this disclosure. It will be apparent that the drawings are not necessarily drawn to scale, as some components may be shown out of proportion to their actual dimensions in order to clearly illustrate the concepts of this disclosure.
[0014] Figure 1 This is a schematic diagram of an example network environment that can realize the various schemes proposed in this disclosure.
[0015] Figure 2 This is a schematic diagram of an example scenario according to an embodiment of the present disclosure.
[0016] Figure 3 This is a schematic diagram of an example scenario according to an embodiment of the present disclosure.
[0017] Figure 4 This is a block diagram of an example communication device and an example network device according to embodiments of the present disclosure.
[0018] Figure 5 This is a flowchart illustrating an example process according to an embodiment of this disclosure.
[0019] Figure 6 This is a flowchart illustrating an example process according to an embodiment of this disclosure.
[0020] Figure 7 This is a flowchart illustrating an example process according to an embodiment of this disclosure. Detailed Implementation
[0021] This document discloses detailed embodiments and implementations of the claimed subject matter. However, it should be understood that the disclosed embodiments and implementations are merely illustrative of the claimed subject matter, which can be implemented in various forms. This disclosure may be implemented in many different forms and should not be construed as limiting the exemplary embodiments and implementations set forth herein. Rather, these exemplary embodiments and implementations are provided to make the description of this disclosure thorough and complete, and to fully convey the scope of this disclosure to those skilled in the art. In the following description, details of known features and / or techniques may be omitted to avoid unnecessarily obscuring the presented embodiments and implementations.
[0022] Overview
[0023] Embodiments of this disclosure relate to various techniques, methods, schemes, and / or solutions related to the process of PUSCH scheduling in mobile communications. According to this disclosure, many possible solutions can be implemented individually or in combination. That is, although these possible solutions may be described individually below, two or more of these possible solutions may be implemented in one combination or another.
[0024] Figure 1 A schematic diagram illustrating an example network environment 100 that can implement various solutions and schemes proposed according to this disclosure is provided. (See also...) Figure 1 Network environment 100 involves UE 110 communicating wirelessly with wireless network 120 (e.g., a 5G NR mobile network or another type of network such as NTN). UE 110 can communicate wirelessly with wireless network 120 via base station or network node 125 (e.g., eNB, gNB, or transmit-receive point (TRP)). In network environment 100, UE 110 and wireless network 120 can implement various schemes related to the PUSCH scheduling process used in mobile communications, as described below.
[0025] According to the first scheme proposed in this disclosure, UE 110 may not receive the DCI (e.g., scrambled cyclic redundancy check, CRC) scrambled by TC-RNTI for the transmission of the PUSCH that scheduled the HARQ process until after the expected transmission of the last PUSCH of the given HARQ process has ended. Figure 2 Example scenario 200 based on the proposed solution is illustrated. (See reference...) Figure 2 We do not want UE 110 to receive DCI scheduled by TC-RNTI. In some cases, the aforementioned restriction may only apply to the case where the last PUSCH is scheduled using a DCI scrambled by TC-RNTI (for example, the restriction does not apply to the case where the last PUSCH is scheduled using Msg2).
[0026] As an example of an implementation of the proposed first scheme, if the last PUSCH of a given HARQ process is scheduled via DCI format 0_0 with a CRC scrambled by TC-RNTI or by uplink (UL) grant in the RA response, it is not desirable to schedule UE 110 to send another PUSCH via DCI format 0_0 with a CRC scrambled by TC-RNTI for that HARQ process, where the DCI is received before the expected end of the transmission of the last PUSCH.
[0027] According to the second scheme proposed in this disclosure, when PUSCH is scheduled using / via DCI, UE 110 may not receive the DCI (e.g., scrambled CRC) scrambled by TC-RNTI for the transmission of the PUSCH that scheduled the HARQ process until after the expected transmission of the last PUSCH for a given HARQ process has ended. Figure 3 Example scenario 300 based on the proposed solution is illustrated. (See reference...) Figure 3 We do not want UE 110 to receive DCI scheduled by CS-RNTI.
[0028] As an example of an implementation of the proposed second scheme, if the last PUSCH of a given HARQ process is scheduled via a DCI with a CRC scrambled by C-RNTI, CS-RNTI, or MCS-C-RNTI, it is not desirable to schedule UE 110 to send another PUSCH for that HARQ process via a DCI format 0_0 or 0_1 scrambled by C-RNTI, CS-RNTI, or MCS-C-RNTI, where the DCI is received before the expected end of the transmission of the last PUSCH.
[0029] As another example of the implementation of the proposed second scheme, if the last PUSCH of a given HARQ process is scheduled via a DCI with a CRC scrambled by C-RNTI, CS-RNTI, or MCS-C-RNTI, it is not desirable to schedule UE110 to send another PUSCH for that HARQ process via a DCI format 0_0, 0_1, or 0_2 scrambled by C-RNTI, CS-RNTI, or MCS-C-RNTI, where the DCI is received before the expected end of the transmission of the last PUSCH.
[0030] In each of the first and second proposed schemes, it is desirable for UE 110 to transmit another PUSCH for a given HARQ process using DCI format 0_0 scrambled by TC-RNTI only after the expected transmission of the last PUSCH for that HARQ process has ended. In each of the first and second proposed schemes, when scheduling PUSCH using / through DCI, it is desirable for UE 110 to transmit another PUSCH for a given HARQ process using DCI format 0_0 or 0_1 scrambled by CS-RNTI only after the expected transmission of the last PUSCH for that HARQ process has ended.
[0031] In each of the proposed first and second schemes, when UE 110 receives a PUSCH scrambled with C-RNTI, MCS-C-RNTI, or CS-RNTI in DCI format 0_0 or 0_1 for a given HARQ process, it is desired that UE 110 receive another PUSCH scrambled with C-RNTI, MCS-C-RNTI, or CS-RNTI in another DCI format 0_0 or 0_1 for the same HARQ process only after the transmission of the last PUSCH of that HARQ process has ended. In each of the proposed first and second schemes, when UE 110 receives a PUSCH scrambled with CS-RNTI in DCI format 0_0 or 0_1 for a given HARQ process, it is desired that UE 110 receive another PUSCH scrambled with CS-RNTI in another DCI format 0_0 or 0_1 for the same HARQ process only after the transmission of the last PUSCH of that HARQ process has ended.
[0032] In each of the first and second proposed schemes, when UE 110 receives a PUSCH scrambled with C-RNTI, MCS-C-RNTI, or CS-RNTI in DCI format 0_0, 0_1, or 0_2 for a PUSCH scheduled for a given HARQ process, UE 110 is expected to receive another PUSCH scrambled with C-RNTI, MCS-C-RNTI, or CS-RNTI in another DCI format 0_0, 0_1, or 0_2 for another PUSCH scheduled for the same HARQ process only after the transmission of the last PUSCH of that HARQ process has ended. In each of the first and second proposed schemes, when UE 110 receives a PUSCH scrambled with CS-RNTI in DCI format 0_0, 0_1, or 0_2 for a PUSCH scheduled for a given HARQ process, UE 110 is expected to receive another PUSCH scrambled with CS-RNTI in another DCI format 0_0, 0_1, or 0_2 for another PUSCH scheduled for the same HARQ process only after the transmission of the last PUSCH of that HARQ process has ended. In each of the first and second proposed schemes, if UE 110 receives a CS-RNTI scrambled DCI format of a PUSCH scheduled for a given HARQ process, it is desired that UE 110 receive another CS-RNTI scrambled DCI format of another PUSCH scheduled for the same HARQ process only after the transmission of the last PUSCH of that HARQ process has ended.
[0033] Exemplary Implementation
[0034] Figure 4Example communication device 410 and example network device 420 according to embodiments of the present disclosure are illustrated. Each of the communication device 410 and network device 420 can perform various functions to implement the schemes, techniques, processes, and methods described herein related to the PUSCH scheduling process for mobile communications, including the scenarios / schemes described above and the processes described below.
[0035] Communication device 410 may be part of an electronic device, which may be a UE, such as a portable or mobile device, a wearable device, a wireless communication device, or a computing device. For example, communication device 410 may be implemented in a smartphone, smartwatch, personal digital assistant, digital camera, or computing device such as a tablet computer, laptop computer, or notebook computer. Communication device 410 may be part of a machine-type device, such as an IoT, NB-IoT, IIoT, or NTN device, home appliance, wired communication device, or computing device, such as a stationary or fixed device. For example, communication device 410 may be implemented in a smart thermostat, smart refrigerator, smart door lock, wireless speaker, or home control center. Alternatively, communication device 410 may be implemented as one or more integrated circuit (IC) chips, for example, but not limited to, one or more single-core processors, one or more multi-core processors, one or more reduced-instruction-set computing (RISC) processors, or one or more complex-instruction-set computing (CISC) processors. Communication device 410 may include... Figure 4 At least some of the components shown, for example, processor 412. Communication device 410 may also include one or more other components unrelated to the scheme proposed in this disclosure (e.g., internal power supply, display device, and / or user interface device), and therefore, for simplicity and brevity, such components of communication device 410 are not described in [the present disclosure]. Figure 4 It is shown in the text, but not described below.
[0036] Network device 420 may be part of an electronic device / station, which may be a network node such as a base station, cell, router, gateway, or satellite. For example, network device 420 may be implemented in an eNodeB in an LTE network, in a gNB in 5G, NR, IoT, NB-IoT, IIoT, or in a satellite in an NTN network. Alternatively, network device 420 may be implemented as one or more IC chips, for example, but not limited to, one or more single-core processors, one or more multi-core processors, or one or more RISC or CISC processors. Network device 420 may include... Figure 4 At least some of the components shown, for example, processor 422. Network device 420 may also include one or more other components unrelated to the scheme proposed in this disclosure (e.g., internal power supply, display device, and / or user interface device), and therefore, for simplicity and brevity, such components of network device 420 are not described in [the present disclosure]. Figure 4 It is shown in the text, but not described below.
[0037] On one hand, each processor in processors 412 and 222 may be implemented as one or more single-core processors, one or more multi-core processors, one or more RISC processors, or one or more CISC processors. That is, even though the singular term "processor" is used herein to refer to processors 412 and 422, the respective processors in processors 412 and 422 according to this disclosure may include multiple processors in some embodiments and a single processor in other embodiments. On the other hand, the respective processors in processors 412 and 422 may be implemented as hardware (and optionally firmware) having electronic components, including, for example, but not limited to, one or more transistors, one or more diodes, one or more capacitors, one or more registers, one or more inductors, one or more memristors, and / or one or more variable capacitors, configured and set to achieve a specific purpose according to this disclosure. In other words, in at least some embodiments, the respective processors in processors 412 and 422 are dedicated machines specifically designed, arranged, and configured to perform specific tasks, including novel processes for PUSCH scheduling in mobile communications according to various implementations of this disclosure.
[0038] In some embodiments, the communication device 410 may further include a transceiver 416 coupled to the processor 412 and capable of wirelessly transmitting and receiving data. In some embodiments, the communication device 410 may further include a memory 414 coupled to the processor 412 and accessible by the processor 412 and storing data therein. In some embodiments, the network device 420 may further include a transceiver 426 coupled to the processor 422 and capable of wirelessly transmitting and receiving data. In some embodiments, the network device 420 may further include a memory 424 coupled to the processor 422 and accessible by the processor 422 and storing data therein. Therefore, the communication device 410 and the network device 420 may wirelessly communicate with each other via transceiver 416 and transceiver 426, respectively.
[0039] The various devices in communication device 410 and network device 420 can be communication entities capable of communicating with each other using various proposed schemes according to this disclosure. To aid understanding, the following description of the operation, function, and capabilities of each of communication device 410 and network device 420 is provided in the context of a mobile communication environment, wherein communication device 410 is implemented in or as a communication device or UE (e.g., UE 110), and network device 420 is implemented in or as a network node of a communication network (e.g., wireless network 120) or a base station (e.g., network node 125). It is also worth noting that although the example implementations described below are provided in the context of mobile communication, they can also be implemented in other types of networks.
[0040] According to the scheme proposed in this disclosure concerning the PUSCH scheduling process in mobile communications, using a communication device 410 implemented in or as a UE in UE 110 and a network device 420 implemented in or as a network node in network node 125 of network environment 100, the processor 412 of the communication device 410 can execute the last PUSCH transmission of one or more PUSCH transmissions associated with a given HARQ process (e.g., the first HARQ process among one or more HARQ processes) via a transceiver 416 and the network device 420. Furthermore, after but not before the last PUSCH transmission, the processor 412 can receive, via the transceiver 416, a DCI signal scrambled by a specific RNTI and scheduling subsequent PUSCH transmissions for the given HARQ process from the network device 420. Additionally, the processor 412 can execute subsequent PUSCH transmissions for the given HARQ process via the transceiver 416 and the network device 420.
[0041] In some implementations, a specific RNTI may include a TC-RNTI. In this case, the DCI signal may include a DCI format 0_0 with CRC scrambled by the TC-RNTI.
[0042] In some implementations, a specific RNTI may include a CS-RNTI. In this case, the DCI signal may include DCI format 0_0, 0_1, or 0_2.
[0043] In some implementations, a specific RNTI may include a C-RNTI. In this case, the DCI signal may include DCI format 0_0, 0_1, or 0_2.
[0044] In some implementations, a specific RNTI may include an MCS-C-RNTI. In this case, the DCI signal may include DCI format 0_0, 0_1, or 0_2.
[0045] According to another scheme related to the PUSCH scheduling process in mobile communications proposed in this disclosure, using a communication device 410 implemented in or as a UE in UE 110 and a network device 420 implemented in or as a network node in network node 125 in network environment 100, the processor 412 of the communication device 410 can execute, via transceiver 416, the last PUSCH transmission of one or more PUSCH transmissions scheduled by a DCI signal and associated with a given HARQ process (e.g., the first HARQ process among one or more HARQ processes). Additionally, the processor 412 can receive, via transceiver 416, a DCI signal scrambled by a specific RNTI and scheduling subsequent PUSCH transmissions for a given HARQ process. Furthermore, if the DCI signal is received before the last PUSCH transmission, the processor 412 can skip subsequent PUSCH transmissions.
[0046] In some implementations, a specific RNTI may include a TC-RNTI. In this case, the DCI signal may include a DCI format 0_0 with CRC scrambled by the TC-RNTI.
[0047] In some implementations, a specific RNTI may include a CS-RNTI. In this case, the DCI signal may include DCI format 0_0, 0_1, or 0_2.
[0048] In some implementations, a specific RNTI may include a C-RNTI. In this case, the DCI signal may include DCI format 0_0, 0_1, or 0_2.
[0049] In some implementations, a specific RNTI may include an MCS-C-RNTI. In this case, the DCI signal may include DCI format 0_0, 0_1, or 0_2.
[0050] According to another scheme related to the PUSCH scheduling process in mobile communications proposed in this disclosure, utilizing a communication device 410 implemented in or as a UE in UE 110 and a network device 420 implemented in or as a network node in network node 125 in network environment 100, the processor 412 of the communication device 410 can execute, via transceiver 416, the last PUSCH transmission of one or more PUSCH transmissions associated with a given HARQ process (e.g., the first HARQ process among one or more HARQ processes) and scheduled by UL authorization in the RA response or by a DCI signal scrambled by TC-RNTI. Additionally, the processor 412 can receive, via transceiver 416, a DCI signal scrambled by TC-RNTI and scheduled for a given HARQ process for subsequent PUSCH transmissions. Furthermore, if the DCI signal is received before the last PUSCH transmission, the processor 412 can skip the subsequent PUSCH transmission.
[0051] In some implementations, the DCI signal may include DCI format 0_0.
[0052] Indicative processing
[0053] Figure 5 An example process 500 according to an embodiment of the present disclosure is illustrated. Whether partially or completely, process 500 can be an example implementation of the above-described scheme regarding the PUSCH scheduling process in mobile communications according to the present disclosure. Process 500 can represent one aspect of the features implemented by communication device 410 and / or network device 420. Process 500 can include one or more operations, actions, or functions as illustrated by one or more of steps 510, 520, and 530. Although illustrated as discrete steps, the individual steps of process 500 can be divided into additional steps, combined into fewer steps, or deleted according to desired implementations. Furthermore, the steps of process 500 can be... Figure 5 The process can be executed in the order shown, or alternatively in a different order. Process 500 can be implemented by communication device 410 or any suitable UE or machine-type device. For purely illustrative purposes and not for limitation, process 500 is described below in the context of communication device 410 as UE 110 and network device 420 as network node 125 in wireless network 120 (e.g., 5G / NR mobile network). Process 500 may begin at step 510.
[0054] In step 510, process 500 includes: the processor 412 of communication device 410 executing, via transceiver 416, the last of one or more PUSCH transmissions associated with a given HARQ process (e.g., the first HARQ process among one or more HARQ processes). Process 500 proceeds from step 510 to step 520.
[0055] In step 520, processing 500 includes: after, but not before, the last PUSCH transmission, the processor 412 receives via transceiver 416 the DCI signal of the subsequent PUSCH transmission scrambled by a specific RNTI and scheduled for a given HARQ processing. Processing 500 proceeds from step 520 to step 530.
[0056] In step 530, the process 500 includes: the processor 412 performing a subsequent PUSCH transfer for a given HARQ process via the transceiver 416.
[0057] In some implementations, a specific RNTI may include a TC-RNTI. In this case, the DCI signal may include a DCI format 0_0 with CRC scrambled by the TC-RNTI.
[0058] In some implementations, a specific RNTI may include a CS-RNTI. In this case, the DCI signal may include DCI format 0_0, 0_1, or 0_2.
[0059] In some implementations, a specific RNTI may include a C-RNTI. In this case, the DCI signal may include DCI format 0_0, 0_1, or 0_2.
[0060] In some implementations, a specific RNTI may include an MCS-C-RNTI. In this case, the DCI signal may include DCI format 0_0, 0_1, or 0_2.
[0061] Figure 6 An example process 600 according to an embodiment of the present disclosure is illustrated. Whether partially or completely, process 600 can be an example implementation of the above-described scheme regarding the PUSCH scheduling process in mobile communications according to the present disclosure. Process 600 can represent one aspect of the features implemented by communication device 410 and / or network device 420. Process 600 can include one or more operations, actions, or functions as illustrated by one or more of steps 610, 620, and 630. Although illustrated as discrete steps, the individual steps of process 600 can be divided into additional steps, combined into fewer steps, or deleted according to desired implementations. Furthermore, the steps of process 600 can be... Figure 6The process can be executed in the order shown, or alternatively in a different order. Process 600 can be implemented by communication device 410 or any suitable UE or machine-type device. For purely illustrative purposes and not for limitation, process 600 is described below in the context of communication device 410 as UE 110 and network device 420 as network node 125 in wireless network 120 (e.g., 5G / NR mobile network). Process 600 may begin at step 610.
[0062] In step 610, process 600 includes: the processor 412 of communication device 410 executing, via transceiver 416, the last of one or more PUSCH transmissions scheduled by DCI signaling and associated with a given HARQ process (e.g., the first HARQ process among one or more HARQ processes). Process 600 proceeds from step 610 to step 620.
[0063] In step 620, process 600 includes: processor 412 receiving, via transceiver 416, a DCI signal scrambled by a specific RNTI and scheduled for a given HARQ processing of subsequent PUSCH transmissions. Process 600 proceeds from step 620 to step 630.
[0064] In step 630, processing 600 includes: if the DCI signal is received before the last PUSCH transmission, processor 412 skips the subsequent PUSCH transmission.
[0065] In some implementations, a specific RNTI may include a TC-RNTI. In this case, the DCI signal may include a DCI format 0_0 with CRC scrambled by the TC-RNTI.
[0066] In some implementations, a specific RNTI may include a CS-RNTI. In this case, the DCI signal may include DCI format 0_0, 0_1, or 0_2.
[0067] In some implementations, a specific RNTI may include a C-RNTI. In this case, the DCI signal may include DCI format 0_0, 0_1, or 0_2.
[0068] In some implementations, a specific RNTI may include an MCS-C-RNTI. In this case, the DCI signal may include DCI format 0_0, 0_1, or 0_2.
[0069] Figure 7An example process 700 according to an embodiment of the present disclosure is illustrated. Whether partially or completely, process 700 can be an example implementation of the above-described scheme regarding the PUSCH scheduling process in mobile communications according to the present disclosure. Process 700 can represent one aspect of the features implemented by communication device 410 and / or network device 420. Process 700 can include one or more operations, actions, or functions as illustrated by one or more of steps 710, 720, and 730. Although illustrated as discrete steps, the individual steps of process 700 can be divided into additional steps, combined into fewer steps, or deleted according to desired implementations. Furthermore, the steps of process 700 can be... Figure 7 The process can be executed in the order shown, or alternatively in a different order. Process 700 can be implemented by communication device 410 or any suitable UE or machine-type device. For purely illustrative purposes and not for limitation, process 700 is described below in the context of communication device 410 as UE 110 and network device 420 as network node 125 in wireless network 120 (e.g., 5G / NR mobile network). Process 700 may begin at step 710.
[0070] In step 710, process 700 includes: the processor 412 of communication device 410 executing, via transceiver 416, the last of one or more PUSCH transmissions associated with a given HARQ process (e.g., the first HARQ process among one or more HARQ processes) and scheduled by UL authorization in the RA response or by a DCI signal scrambled by TC-RNTI. Process 700 proceeds from step 710 to step 720.
[0071] In step 720, process 700 includes: processor 412 receiving, via transceiver 416, a DCI signal scrambled by TC-RNTI and scheduled for a given HARQ processing of subsequent PUSCH transmissions. Process 700 proceeds from step 720 to step 730.
[0072] In step 730, processing 700 includes: if the DCI signal is received before the last PUSCH transmission, processor 412 skips the subsequent PUSCH transmission.
[0073] In some implementations, the DCI signal may include DCI format 0_0.
[0074] Additional Notes
[0075] The topics described herein sometimes illustrate different components contained within or connected to other components. It should be understood that the architectures depicted are merely exemplary, and in reality, many other architectures can be implemented to achieve the same functionality. Conceptually, any arrangement of components used to achieve the same functionality is effectively “associated” to achieve the desired functionality. Thus, any two components combined here to achieve a particular function can be considered “associated” with each other to achieve the desired functionality, regardless of the architecture or intermediate components. Similarly, any two such associated components can also be considered “operably connected” or “operably coupled” to each other to achieve the desired functionality, and any two components that can be suchly associated can also be considered “operably coupled” to each other to achieve the desired functionality. Specific examples of being operablely coupled include, but are not limited to, components that can physically cooperate and / or physically interact and / or components that can wirelessly interact and / or components that logically interact and / or components that can logically interact.
[0076] Furthermore, for any plural and / or singular terms used in this context, those skilled in the art can translate them from plural to singular and / or from singular to plural as appropriate, depending on the context and / or application. For clarity, various singular / plural substitutions can be explicitly described herein.
[0077] Furthermore, those skilled in the art will understand that, generally, the terminology used herein, and especially in the appended claims (e.g., the body of the appended claims), is intended to be “open-ended” (e.g., the term “comprising” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “having at least,” the term “including” should be interpreted as “including but not limited to,” etc.). Those skilled in the art will also understand that if there is an intent to state a particular number of referenced claims, such intent will be explicitly stated in those claims, and furthermore, without such statements, such intent does not exist. For example, to aid understanding, the appended claims may contain the use of introductory phrases “at least one” and “one or more” to introduce the claim statements. However, the use of such phrases should not be construed as implying that a claim statement introduced by the indefinite article "a" or "an" will limit any particular claim containing such an introductory claim statement to containing only one implementation of such a statement, even if the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an" (e.g., "a" or "an" should be interpreted as meaning "at least one" or "one or more"); the same applies to the use of definite articles for referencing claim statements. Furthermore, even if a specific number of referred claim statements are explicitly stated, those skilled in the art should recognize that such a statement should be interpreted as meaning at least the number stated (e.g., a bare statement of "two statements" means at least two statements, or two or more statements, in the absence of other modifiers). Furthermore, in instances where the convention of “at least one of A, B, and C” is used, this syntactic structure is generally intended to be understood by a person skilled in the art to mean the convention (e.g., “a system having at least one of A, B, and C” should include, but is not limited to, systems having a single A, a single B, a single C, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). In instances where the convention of “at least one of A, B, or C” is used, this syntactic structure is generally intended to be understood by a person skilled in the art to mean the convention (e.g., “a system having at least one of A, B, or C” should include, but is not limited to, systems having a single A, a single B, a single C, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). It should also be understood by a person skilled in the art that, in practice, any transition words and / or phrases presenting two or more alternative terms (whether in the specification, claims, or drawings) should be understood to contemplate the possibility of including one, any, or both of these terms. For example, the phrase “A or B” should be understood as including the possibility of “A” or “B” or “A and B”.
[0078] Based on the foregoing, it should be clear that the various implementations of this disclosure have been described for illustrative purposes, and various modifications may be made without departing from the scope and spirit of this disclosure. Therefore, the various implementations described herein are not intended to be limiting, and the true scope and spirit are indicated by the following claims.
Claims
1. A method for scheduling a physical uplink shared channel, the method comprising: The processor of the device executes the last physical uplink shared channel transmission in one or more physical uplink shared channel transmissions associated with the first hybrid automatic repeat request processing. The last physical uplink shared channel is scheduled by downlink control information signals scrambled with a specific radio network temporary identifier. as well as After, but not before, the last physical uplink shared channel transmission, the processor receives another downlink control information signal scrambled by the specific radio network temporary identifier and scheduling the processing of the first hybrid automatic repeat request for subsequent physical uplink shared channel transmissions.
2. The physical uplink shared channel scheduling method according to claim 1, wherein, The specific radio network temporary identifier includes the temporary cell radio network temporary identifier.
3. The physical uplink shared channel scheduling method according to claim 2, wherein, The downlink control information signal includes downlink control information format 0_0.
4. The physical uplink shared channel scheduling method according to claim 1, wherein, The specific radio network temporary identifier includes the configured scheduling radio network temporary identifier.
5. The physical uplink shared channel scheduling method according to claim 4, wherein, The downlink control information signal includes downlink control information format 0_0, 0_1, or 0_2.
6. The physical uplink shared channel scheduling method according to claim 1, wherein, The specific radio network temporary identifier includes the cell radio network temporary identifier.
7. The physical uplink shared channel scheduling method according to claim 6, wherein, The downlink control information signal includes downlink control information format 0_0, 0_1, or 0_2.
8. The physical uplink shared channel scheduling method according to claim 1, wherein, The specific radio network temporary identifier includes the modulation and coding scheme cell radio network temporary identifier.
9. The physical uplink shared channel scheduling method according to claim 8, wherein, The downlink control information signal includes downlink control information format 0_0, 0_1, or 0_2.
10. A method for scheduling a physical uplink shared channel, the method comprising: The processor of the device executes the last physical uplink shared channel transmission in one or more physical uplink shared channel transmissions associated with the first hybrid automatic repeat request processing. The last physical uplink shared channel is scheduled by downlink control information signals scrambled with a specific radio network temporary identifier. The processor receives another downlink control information signal that is scrambled by the specific radio network temporary identifier and schedules the subsequent physical uplink shared channel transmission of the first hybrid automatic repeat request; as well as If the other downlink control information signal is received before the last physical uplink shared channel transmission, the processor skips the subsequent physical uplink shared channel transmission.
11. The physical uplink shared channel scheduling method according to claim 10, wherein, The specific radio network temporary identifier includes the temporary cell radio network temporary identifier.
12. The physical uplink shared channel scheduling method according to claim 11, wherein, The downlink control information signal includes downlink control information format 0_0.
13. The physical uplink shared channel scheduling method according to claim 10, wherein, The specific radio network temporary identifier includes the configured scheduling radio network temporary identifier.
14. The physical uplink shared channel scheduling method according to claim 13, wherein, The downlink control information signal includes downlink control information format 0_0, 0_1, or 0_2.
15. The physical uplink shared channel scheduling method according to claim 10, wherein, The specific radio network temporary identifier includes the cell radio network temporary identifier.
16. The physical uplink shared channel scheduling method according to claim 15, wherein, The downlink control information signal includes downlink control information format 0_0, 0_1, or 0_2.
17. The physical uplink shared channel scheduling method according to claim 10, wherein, The specific radio network temporary identifier includes the modulation and coding scheme cell radio network temporary identifier.
18. The physical uplink shared channel scheduling method according to claim 17, wherein, The downlink control information signal includes downlink control information format 0_0, 0_1, or 0_2.
19. A method for scheduling a physical uplink shared channel, the method comprising: The device's processor executes the last physical uplink shared channel transmission of one or more physical uplink shared channel transmissions that are associated with the first hybrid automatic repeat request processing and scheduled via uplink grants in the random access response; The processor receives downlink control information signals that are scrambled by the temporary identifier of the temporary cell radio network and schedule the processing of the first hybrid automatic repeat request for subsequent physical uplink shared channel transmissions. as well as If the downlink control information signal is received before the last physical uplink shared channel transmission, the processor skips the subsequent physical uplink shared channel transmission.
20. The physical uplink shared channel scheduling method according to claim 19, wherein, The downlink control information signal includes downlink control information format 0_0.