A communication method and apparatus

Abstract

A communication method and device are used to reduce power consumption of a terminal device. A network device determines a first DCI and sends the first DCI to the terminal device, and then the terminal device determines, according to the first DCI, that the terminal device does not monitor a PDCCH in a first time period; wherein the first DCI is used to schedule a padding data packet, and the first DCI indicates that the terminal device does not monitor a physical downlink control channel (PDCCH) in the first time period. In this way, when there is no service arriving at the terminal device, the network device can instruct the terminal device not to monitor the PDCCH in the first time period through the DCI scheduling the padding data packet, thereby reducing the power consumption of the terminal device.

Description

[0001] This application claims priority to Chinese Patent Application No. 202210204563.7, filed on March 3, 2022, entitled "A Method for Instructing Skipping PDCCH and Search Space Switching", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of communication technology, and in particular to a communication method and apparatus. Background Technology

[0003] Before data transmission occurs between network devices and terminal devices, the network device sends data scheduling information, such as PDCCH, to the terminal device. To avoid losing this scheduling information, the terminal device needs to frequently monitor the PDCCH according to the network device's configuration. However, this frequent monitoring of the PDCCH by the terminal device leads to higher power consumption. Currently, research on power saving for terminal devices is becoming increasingly common, and detailed optimization schemes to reduce terminal device power consumption have become a research focus in the industry. Summary of the Invention

[0004] This application provides a communication method and apparatus for reducing the power consumption of terminal devices.

[0005] In a first aspect, this application provides a communication method, which may include: after a terminal device receives first downlink control information (DCI) from a network device, it determines, based on the first DCI, not to monitor the physical downlink control channel (PDCCH) within a first duration; wherein, the first DCI is used to schedule padding data packets, and the first DCI instructs the terminal device not to monitor the physical downlink control channel (PDCCH) within the first duration.

[0006] Using the above method, when no service arrives at the terminal device, the network device can instruct the terminal device not to monitor the PDCCH for a first period of time by scheduling the DCI that fills the data packets, thereby reducing the power consumption of the terminal device.

[0007] In one possible design, the first DCI is used to schedule the physical downlink shared channel (PDSCH). Thus, the first DCI can instruct the terminal device not to monitor the physical downlink control channel (PDCCH) for a first duration by scheduling downlink padding packets.

[0008] In one possible design, the first DCI is either DCI format 1_1 or DCI format 1_2 scrambled with the cell-radionetwork temporary identity (C-RNTI); or, the first DCI is either DCI format 1_1 or DCI format 1_2 scrambled with the modulation and coding scheme-cell-radio network temporary identifier (MCS-C-RNTI); or, the first DCI is either DCI format 1_1 or DCI format 1_2 scrambled with the configured scheduling-radio network temporary identity (CS-RNTI). This allows the first DCI to be flexibly implemented using downlink DCI.

[0009] In one possible design, the terminal device receives a PDSCH from the network device. The PDSCH contains a media access control sub-protocol data unit (MACsub PDU) and a corresponding logical channel identifier (LCID). This enables the network device to schedule downlink padding packets.

[0010] In one possible design, the first DCI is used to schedule the physical uplink shared channel (PUSCH). Thus, the first DCI can instruct the terminal device not to monitor the physical downlink control channel (PDCCH) for a first duration by scheduling uplink padding packets.

[0011] In one possible design, the first DCI is either DCI format 0_1 ​​or DCI format 0_2 scrambled with the Cell Radio Network Temporary Identifier (C-RNTI); or, the first DCI is either DCI format 0_1 ​​or DCI format 0_2 scrambled with the Modulation and Coding Scheme Cell-Specific Radio Network Temporary Identifier (MCS-C-RNTI); or, the first DCI is either DCI format 0_1 ​​or DCI format 0_2 scrambled with the Configuration and Scheduling Radio Network Temporary Identifier (CS-RNTI). Thus, the first DCI can be flexibly implemented using uplink DCI.

[0012] In one possible design, the terminal device sends a Physical Uplink Shared Channel (PUSCH) to the network device. The PUSCH contains a Media Access Control Sub-Protocol Data Unit (MAC sub-PDU), and the Logical Channel Identifier (LCID) corresponding to the MAC sub-PDU has a value of 63. This enables the network device to schedule uplink padding data packets.

[0013] In one possible design, the terminal device sends a PUSCH to the network device, wherein the PUSCH contains the padding data packet; consequently, the terminal device does not start the discontinuous reception inactivity timer DRX-inactivitytimer; or, when the DRX-inactivitytimer is running, the terminal device does not restart or stop the DRX-inactivitytimer. This avoids extending the active time of the terminal device, thereby saving power consumption of the terminal device.

[0014] In one possible design, when the terminal device is configured with uplink skipping, the terminal device does not send the Physical Uplink Shared Channel (PUSCH) to the network device. This eliminates the need for the terminal device to send any data packets to the network device, thus saving power consumption.

[0015] In one possible design, when the terminal device does not send a PUSCH to the network device, the terminal device does not start the discontinuous reception inactivity timer DRX-inactivitytimer; or, when the DRX-inactivitytimer is running, the terminal device does not restart or stop the DRX-inactivitytimer. This avoids extending the active time of the terminal device, thereby saving power consumption.

[0016] In one possible design, the terminal device receives a PDSCH from the network device, wherein the PDSCH includes the padding data packet; furthermore, the terminal device does not start the discontinuous reception inactivity timer DRX-inactivitytimer; or, when the DRX-inactivitytimer is running, the terminal device does not restart or stop the DRX-inactivitytimer. This avoids extending the active time of the terminal device, thereby saving power consumption of the terminal device.

[0017] In one possible design, the value of the new data indicator (NDI) field in the first DCI is the same as the value of the NDI field in the second DCI. The second DCI is the preceding DCI whose value is the same as the value of the hybrid automatic repeat request (HARQ) process number (HPN) field of the first DCI. In this way, when the first DCI is a retransmission DCI, the terminal device does not need to start, restart, or stop the DRX-inactivitytimer, which can prevent the active time of the terminal device from being prolonged, thereby saving power consumption.

[0018] In one possible design, the terminal device receives the second DCI from the network device before receiving the first DCI from the network device, and sends a correct ACK message to the network device. This allows the terminal device to subsequently recognize the padding data packet, thus preventing the DRX-inactivitytimer from starting, restarting, or stopping.

[0019] In one possible design, the value of the NDI field in the first DCI differs from the value of the NDI field in the third DCI, where the third DCI is the preceding DCI with the same value as the first DCI's HARQ process count (HPN) field. This way, when the first DCI is a new transmission DCI, the terminal device can avoid extending its active time by not starting, restarting, or stopping the DRX-inactivitytimer, thus saving power consumption.

[0020] Secondly, this application provides a communication method, which may include: a network device determining a first DCI and sending the first DCI to the terminal device, wherein the first DCI is used to schedule padding data packets, and the first DCI instructs the terminal device not to monitor the Physical Downlink Control Channel (PDCCH) for a first duration.

[0021] Using the above method, when no service arrives at the terminal device, the network device can instruct the terminal device not to monitor the PDCCH for a first period of time by scheduling the DCI that fills the data packets, thereby reducing the power consumption of the terminal device.

[0022] In one possible design, before the network device sends the first DCI to the terminal device, the network device determines that no service has arrived at the terminal device within a preset time period; or, the network device determines that there is no cached data corresponding to the terminal device. In this way, the network device can determine that no service has arrived at the terminal device, and then send the first DCI to the terminal device.

[0023] In one possible design, the preset duration is a period of time before the network device sends the first DCI, or the preset duration is a period of time after the network device sends the first DCI, or the preset duration is the moment when the network device sends the first DCI.

[0024] In one possible design, the first DCI is used for the PDSCH. Thus, the first DCI can instruct the terminal device not to monitor the Physical Downlink Control Channel (PDCCH) for a first duration by scheduling downlink padding packets.

[0025] In one possible design, the first DCI is either DCI format 1_1 or DCI format 1_2 scrambled with the Cell Radio Network Temporary Identifier (C-RNTI); or, the first DCI is either DCI format 1_1 or DCI format 1_2 scrambled with the Modulation and Coding Scheme Cell-Specific Radio Network Temporary Identifier (MCS-C-RNTI); or, the first DCI is either DCI format 1_1 or DCI format 1_2 scrambled with the Configuration and Scheduling Radio Network Temporary Identifier (CS-RNTI). Thus, the first DCI can be flexibly implemented using downlink DCI.

[0026] In one possible design, the network device sends a Physical Downlink Shared Channel (PDSCH) to the terminal device. The PDSCH includes a Media Access Control Sub-Protocol Data Unit (MAC sub-PDU), and the Logical Channel Identifier (LCID) corresponding to the MAC sub-PDU has a value of 63. This enables the network device to schedule downlink padding data packets.

[0027] In one possible design, the first DCI is used to schedule the PUSCH. Thus, the first DCI can instruct the terminal device not to monitor the Physical Downlink Control Channel (PDCCH) for a first duration by scheduling uplink padding packets.

[0028] In one possible design, the first DCI is either DCI format 0_1 ​​or DCI format 0_2 scrambled with the Cell Radio Network Temporary Identifier (C-RNTI); or, the first DCI is either DCI format 0_1 ​​or DCI format 0_2 scrambled with the Modulation and Coding Scheme Cell-Specific Radio Network Temporary Identifier (MCS-C-RNTI); or, the first DCI is either DCI format 0_1 ​​or DCI format 0_2 scrambled with the Configuration and Scheduling Radio Network Temporary Identifier (CS-RNTI). Thus, the first DCI can be flexibly implemented using uplink DCI.

[0029] In one possible design, the network device receives a Physical Uplink Shared Channel (PUSCH) from the terminal device. The PUSCH contains a Media Access Control Sub-Protocol Data Unit (MAC sub-PDU), and the Logical Channel Identifier (LCID) corresponding to the MAC sub-PDU has a value of 63. This enables the network device to schedule uplink padding data packets.

[0030] In one possible design, when the terminal device is configured with uplink skipping, the network device does not receive PUSCH from the terminal device. This eliminates the need for the terminal device to send any data packets to the network device, thus saving power consumption.

[0031] In one possible design, the network device receives the Physical Uplink Shared Channel (PUSCH) from the terminal device, wherein the PUSCH contains the padding data packets; furthermore, the network device does not start the discontinuous reception inactivity timer (DRX-inactivitytimer); or, when the DRX-inactivitytimer is running, the network device does not restart or stop the DRX-inactivitytimer. This avoids extending the active time of the terminal device, thereby saving power consumption of the terminal device.

[0032] In one possible design, the network device does not receive the Physical Uplink Shared Channel (PUSCH) sent by the terminal device at the location indicated by the first DCI; consequently, the network device does not start the discontinuous reception inactivity timer (DRX-inactivitytimer); or, when the DRX-inactivitytimer is running, the network device does not restart or stop the DRX-inactivitytimer. This avoids extending the active time of the terminal device, thereby saving power consumption of the terminal device.

[0033] In one possible design, the network device sends a Physical Downlink Shared Channel (PDSCH) to the terminal device, wherein the PDSCH includes the padding data packet; furthermore, the network device does not start the Discontinuous Receive Inactivity Timer (DRX-inactivitytimer); or, when the DRX-inactivitytimer is running, the network device does not restart or stop the DRX-inactivitytimer. This avoids extending the active time of the terminal device, thereby saving power consumption of the terminal device.

[0034] In one possible design, the value of the New Data Indicator (NDI) field in the first DCI is the same as the value of the NDI field in the second DCI. The second DCI is the preceding DCI whose value is the same as the value of the Hybrid Automatic Repeat Request (HARQ) process count (HPN) field in the first DCI. In this way, when the first DCI is a retransmission DCI, the network device can avoid starting, restarting, or stopping the DRX-inactivitytimer, thus preventing an extension of the terminal device's active time and saving power consumption.

[0035] In one possible design, before the network device sends the first DCI to the terminal device, the method further includes: after the network device sends the second DCI to the terminal device, receiving a correct acknowledgment (ACK) from the terminal device. This allows the terminal device to subsequently recognize padding packets, thus preventing the DRX-inactivitytimer from starting, restarting, or stopping.

[0036] In one possible design, the value of the New Data Indicator (NDI) field in the first DCI differs from the value of the NDI field in the third DCI, where the third DCI is the preceding DCI with the same value as the Hybrid Automatic Repeat Request (HARQ) process count (HPN) field in the first DCI. This way, when the first DCI is a new transmission DCI, the terminal device can avoid extending its active time by not starting, restarting, or stopping the DRX-inactivitytimer, thus saving power consumption.

[0037] Thirdly, this application provides a communication method, which may include: after a terminal device receives a downlink padding data packet from a network device, determining a first operation of the terminal device based on the downlink padding data packet. In this way, the terminal device can trigger its first operation upon receiving the downlink padding data packet, thereby saving power consumption of the terminal device.

[0038] In one possible design, the terminal device receives the downlink padding data packet from the network device by: the terminal device receiving a Physical Downlink Shared Channel (PDSCH) from the network device, wherein the PDSCH contains a Media Access Control Sub-Protocol Data Unit (MAC sub PDU), and the Logical Channel Identifier (LCID) corresponding to the MAC sub PDU has a value of 63. This allows the terminal device to receive accurate downlink padding data packets.

[0039] In one possible design, the first operation is that the terminal device does not monitor the Physical Downlink Control Channel (PDCCH) for a second duration. This allows the terminal device to refrain from monitoring the PDCCH for a period after receiving downlink padding packets, thereby saving power consumption.

[0040] In one possible design, the terminal device receives Downlink Control Information (DCI) from the network device. The DCI is used to schedule the downlink padding data packets, and instructs the terminal device not to monitor the PDCCH for a second duration after receiving the downlink padding data packets. Thus, the network device can trigger the terminal device to stop monitoring the PDCCH by scheduling downlink padding data packets.

[0041] In one possible design, the DCI is DCI format 1_0.

[0042] In one possible design, the first operation is that the terminal device does not start the discontinuous reception inactivity timer DRX-inactivitytimer; or, when the DRX-inactivitytimer is running, the first operation is that the terminal device does not restart or stop the DRX-inactivitytimer. In this way, after the terminal device receives downlink padding data packets, by not starting the DRX-inactivitytimer, or by not restarting or stopping a running DRX-inactivitytimer, the activation time of the terminal device can be avoided, thereby reducing the power consumption of the terminal device.

[0043] Fourthly, this application provides a communication method, which may include: a network device sending downlink padding data packets to a terminal device, and determining that the terminal device does not monitor the Physical Downlink Control Channel (PDCCH) for a second duration. This can save power consumption of the terminal device by sending downlink padding data packets to the terminal device to trigger a period of time during which the terminal device does not monitor the PDCCH.

[0044] In one possible design, the network device sends the downlink padding data packet to the terminal device by sending a Physical Downlink Shared Channel (PDSCH) to the terminal device. The PDSCH contains a Media Access Control Sub-Protocol Data Unit (MAC sub-PDU), and the Logical Channel Identifier (LCID) corresponding to the MAC sub-PDU has a value of 63. This allows the network device to send accurate downlink padding data packets.

[0045] In one possible design, the network device sends Downlink Control Information (DCI) to the terminal device. The DCI is used to schedule the downlink padding data packets, and instructs the terminal device not to monitor the PDCCH for a second duration after receiving the downlink padding data packets. In this way, the network device can trigger the terminal device to stop monitoring the PDCCH by scheduling downlink padding data packets.

[0046] In one possible design, the DCI is DCI format 1_0.

[0047] Fifthly, this application provides a communication method, which may include: a network device sending downlink padding data packets to a terminal device, and the network device not starting a discontinuous reception inactivity timer (DRX-inactivitytimer); or, when the DRX-inactivitytimer is running, the network device not restarting or stopping the DRX-inactivitytimer. In this way, by sending downlink padding data packets to the terminal device to trigger the non-starting of the DRX-inactivitytimer, or by not restarting or stopping a running DRX-inactivitytimer, the activation time of the terminal device can be avoided, thereby reducing the power consumption of the terminal device.

[0048] In one possible design, the network device sends the downlink padding data packet to the terminal device by sending a Physical Downlink Shared Channel (PDSCH) to the terminal device. The PDSCH contains a Media Access Control Sub-Protocol Data Unit (MAC sub-PDU), and the Logical Channel Identifier (LCID) corresponding to the MAC sub-PDU has a value of 63. This allows the network device to send accurate downlink padding data packets.

[0049] Sixthly, this application also provides a communication device, which may be a terminal device. This communication device has the functionality to implement the methods described in the first aspect or various possible design examples of the first aspect, or the third aspect or various possible design examples of the third aspect. The functionality can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the described functions.

[0050] In one possible design, the communication device includes a transceiver unit and a processing unit. These units can perform the corresponding functions in the first aspect or various possible design examples of the first aspect, or in the third aspect or various possible design examples of the third aspect, as detailed in the method examples, which will not be repeated here.

[0051] In one possible design, the communication device includes a transceiver and a processor, and optionally a memory. The transceiver is used to send and receive information or data, and to communicate and interact with other devices in the communication system. The processor is configured to support the communication device in performing the functions described in the first aspect or various possible design examples of the first aspect, or the third aspect or various possible design examples of the third aspect. The memory is coupled to the processor and stores the necessary program instructions and data of the communication device.

[0052] Seventhly, this application also provides a communication device, which may be a network device, having the functionality to implement the methods described in the second aspect or various possible design examples of the second aspect, the fourth aspect or various possible design examples of the fourth aspect, and the fifth aspect or various possible design examples of the fifth aspect. The functionality can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the described functionality.

[0053] In one possible design, the communication device includes a transceiver unit and a processing unit. These units can perform the corresponding functions in the second aspect or various possible design examples of the second aspect, the fourth aspect or various possible design examples of the fourth aspect, and the fifth aspect or various possible design examples of the fifth aspect, as detailed in the method examples, which will not be repeated here.

[0054] In one possible design, the communication device includes a transceiver and a processor, and optionally a memory. The transceiver is used to send and receive information or data, and to communicate and interact with other devices in the communication system. The processor is configured to support the communication device in performing corresponding functions in the second aspect or various possible design examples of the second aspect, the fourth aspect or various possible design examples of the fourth aspect, and the fifth aspect or various possible design examples of the fifth aspect described above. The memory is coupled to the processor and stores necessary program instructions and data for the communication device.

[0055] Eighthly, embodiments of this application provide a communication system that may include the terminal devices and network devices mentioned above.

[0056] Ninthly, embodiments of this application provide a computer-readable storage medium storing program instructions that, when executed on a computer, cause the computer to perform the methods described in the first aspect and any possible design of the embodiments of this application, or in the second aspect and any possible design. Exemplarily, the computer-readable storage medium can be any available medium accessible to a computer. For example, but not limited to, a computer-readable medium can include a non-transient computer-readable medium, random-access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), CD-ROM or other optical disk storage, magnetic disk storage media, or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible to a computer.

[0057] In a tenth aspect, embodiments of this application provide a computer program product, including computer program code or instructions, which, when the computer program code or instructions are run on a computer, cause the method described in the first aspect or any possible design of the first aspect, or in the second aspect or any possible design of the second aspect, to be executed.

[0058] Eleventhly, this application also provides a chip, including a processor coupled to a memory, for reading and executing program instructions stored in the memory to enable the chip to implement the methods described in the first aspect or any possible design of the first aspect, or in the second aspect or any possible design of the second aspect, or in the third aspect or any possible design of the third aspect, or in the fourth aspect or any possible design of the fourth aspect, or in the fifth aspect or any possible design of the fifth aspect.

[0059] For the various aspects of the third to eighth aspects mentioned above, and the technical effects that may be achieved by each aspect, please refer to the above description of the technical effects that may be achieved by the various possible solutions of the first aspect or the first aspect, or the various possible solutions of the second aspect or the second aspect, or the various possible solutions of the third aspect or the third aspect, or the various possible solutions of the fourth aspect or the fourth aspect, or the various possible solutions of the fifth aspect or the fifth aspect. It will not be repeated here. Attached Figure Description

[0060] Figure 1 A schematic diagram of the architecture of a communication system provided in this application; Figure 2A schematic diagram illustrating a method for bypassing PDCCH monitoring provided in this application; Figure 3 A schematic diagram illustrating the use of scheduling DCI to indicate PDCCH skipping in a network device, provided in this application; Figure 4 A flowchart of a communication method provided in this application; Figure 5 A schematic diagram of a network device according to this application, showing how the first DCI indication PDCCH skipping is scheduled to fill data packets; Figure 6 A schematic diagram of a MAC PDU comprising one or more MAC sub PDUs provided in this application; Figure 7 A schematic diagram of a CDRX cycle provided in this application; Figure 8 A schematic diagram illustrating a network device indicating that a terminal device configured with CDRX does not monitor PDCCH for a period of time, as provided in this application; Figure 9 A flowchart of another communication method provided in this application; Figure 10 A flowchart of another communication method provided in this application; Figure 11 A schematic diagram of the structure of a communication device provided in this application; Figure 12 A structural diagram of a communication device provided in this application. Detailed Implementation

[0061] The present application will now be described in further detail with reference to the accompanying drawings.

[0062] This application provides a communication method and apparatus to reduce the power consumption of terminal devices. The method and apparatus described in this application are based on the same technical concept. Since the principles by which the method and apparatus solve the problem are similar, the implementations of the apparatus and method can be referred to each other, and repeated details will not be repeated.

[0063] In the description of this application, the terms "first," "second," etc., are used only for the purpose of distinguishing descriptions and should not be construed as indicating or implying relative importance or order.

[0064] In the description of this application, "at least one" means one or more species, and "more than one species" means two or more species.

[0065] To more clearly describe the technical solutions of the embodiments of this application, the communication methods and devices provided in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0066] Figure 1 The architecture of a communication system according to an embodiment of this application is shown. The architecture of the communication system includes network devices and terminal devices, wherein: The network device is a device with wireless transceiver capabilities or a chip that can be configured in the network device. The network device includes, but is not limited to: a generation node B (gNB), a radio network controller (RNC), a node B (NB), a base station controller (BSC), a base transceiver station (BTS), a home base station (e.g., a home evolved NodeB, or a home Node B, HNB), a baseband unit (BBU), an access point (AP), a wireless relay node, a wireless backhaul node, a transmission and reception point (TRP or transmission point, TP) in a wireless fidelity (Wi-Fi) system, etc. It can also be a network node constituting a gNB or a transmission point, such as a baseband unit (BBU) or a distributed unit (DU), etc.

[0067] In some deployments, a gNB may include a centralized unit (CU) and a DU. A gNB may also include a radio unit (RU). The CU implements some of the gNB's functions, and the DU implements others. For example, the CU implements radio resource control (RRC) and packet data convergence protocol (PDCP) layer functions, while the DU implements radio link control (RLC), media access control (MAC), and physical (PHY) layer functions. Since RRC layer information ultimately becomes PHY layer information, or is derived from PHY layer information, in this architecture, higher-layer signaling, such as RRC or PDCP layer signaling, can be considered to be sent by the DU, or by the DU+RU. It is understood that network devices can be CU nodes, DU nodes, or devices including both CU and DU nodes. Furthermore, the CU can be classified as a network device in the access network (RAN) or a network device in the core network (CN); this is not limited.

[0068] The terminal device can also be referred to as user equipment (UE), access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication device, user agent, or user device. In the embodiments of this application, the terminal device can be a mobile phone, tablet computer, computer with wireless transceiver capabilities, virtual reality (VR) terminal device, augmented reality (AR) terminal device, wireless terminal in industrial control, wireless terminal in self-driving, wireless terminal in remote medical care, wireless terminal in smart grid, wireless terminal in transportation safety, wireless terminal in smart city, wireless terminal in smart wearable devices (smart glasses, smartwatches, smart headphones, etc.), wireless terminal in smart home, etc., or it can be a chip or chip module (or chip system) that can be installed in the above devices. The embodiments of this application do not limit the application scenarios. In this application, terminal devices with wireless transceiver functions and chips that can be installed in the aforementioned terminal devices are collectively referred to as terminal devices.

[0069] It should be noted that, Figure 1 The communication system shown may be, but is not limited to, a fourth-generation (4G) system, a fifth-generation (5G) system, such as a new radio access technology (NR). Optionally, the method of this application embodiment is also applicable to various future communication systems, such as a sixth-generation (6G) system or other communication networks.

[0070] In NR, the data transmission process can be described as follows: When a network device schedules a terminal device to receive downlink data or send uplink data, it first sends downlink control information (DCI). The DCI contains data scheduling information that indicates the transmission parameters of the physical downlink shared channel (PDSCH) (which typically contains downlink data) or the physical uplink shared channel (PUSCH) (which typically contains uplink data). These transmission parameters include the time-frequency domain resource locations of the PDSCH / PUSCH. Specifically, the physical downlink control channel (PDCCH) carries the aforementioned DCI. For downlink data, the network device uses the time domain resource allocation (TDRA) field in the DCI to indicate the K0 value, which determines the time slot interval between the PDCCH and PDSCH. For uplink data, the network device uses the TDRA field in the DCI to indicate the K2 value, which determines the time slot interval between the PDCCH and PUSCH.

[0071] The network device sends a PDSCH at the time-frequency domain resource location indicated in the DCI, and the terminal device receives it at the corresponding location; or, the terminal device sends a PUSCH at the time-frequency domain resource location indicated in the DCI, and the network device receives it at the corresponding location.

[0072] When a terminal device receives its own DCI, it needs to perform blind detection (BD) on the PDCCH sent to itself in the downlink control area. That is, the terminal device monitors many PDCCH candidate locations and finds out if there is one sent to itself.

[0073] Based on the above description, terminal devices frequently monitor the PDCCH. However, if no service is generated by the terminal device within a certain period, i.e., no downlink or uplink data needs to be transmitted, the network device will not send a PDCCH to schedule the PDSCH or PUSCH. In this case, even if the terminal device monitors the PDCCH, it will not be able to receive the PDCCH sent to it. If the terminal device continues to monitor the PDCCH during these times, it will cause power consumption issues for the terminal device.

[0074] To reduce the power consumption of terminal devices, one possible solution is to introduce the concept of PDCCH skipping. Specifically, the network device can send an indication to the terminal device, instructing it to skip a period of PDCCH monitoring. Skipping a period of PDCCH monitoring can be equivalently described as the terminal device not monitoring the PDCCH for a certain period; this period of non-monitoring can be called the skipping duration. For example... Figure 2 The diagram shown illustrates skipping PDCCH monitoring. Normally, a terminal device needs to monitor the PDCCH in every time slot. However, if the terminal device is instructed by the network device to not monitor the PDCCH for a certain period of time, then the terminal device can refrain from monitoring the PDCCH during that indicated period.

[0075] However, network devices can only trigger PDCCH skipping of terminal devices by scheduling DCIs. That is, the DCI that can indicate PDCCH skipping must be a DCI that schedules data transmission. For example, a scheduling DCI may contain a PDCCH monitoring adaptation indication field, which is 1-2 bits long and can indicate PDCCH skipping. It should be noted that this field can indicate both PDCCH skipping and search space set groups switching (SSSG switching); this application only uses PDCCH skipping as an example.

[0076] The network device can configure 1 to 3 skipping durations for the terminal device, and use 1 to 2 bits to indicate the length of each skipping duration. For example, when the network device is configured with 1 skipping duration (length T1), the scheduling DCI will contain 1 bit, with a value of '0' indicating that PDCCH skipping is not performed (i.e., PDCCH is monitored normally), and a value of '1' indicating that PDCCH is not monitored within the time length T1. As another example, when the network device is configured with 2 skipping durations (lengths T1 and T2), the scheduling DCI will contain 2 bits, with a value of '00' indicating that PDCCH skipping is not performed (i.e., PDCCH is monitored normally); a value of '01' indicating that PDCCH is not monitored within the time length T1; and a value of '10' indicating that PDCCH is not monitored within the time length T2. For example, when a network device is configured with three skipping durations (lengths T1, T2, and T3), the scheduling DCI will contain 2 bits. A value of '00' indicates that PDCCH skipping is not performed (i.e., PDCCH is monitored normally); a value of '01' indicates that PDCCH is not monitored during the time period T1; a value of '10' indicates that PDCCH is not monitored during the time period T2; and a value of '11' indicates that PDCCH is not monitored during the time period T3. It should be noted that the relationship between the above bit values ​​and their corresponding meanings is only an example, and other indication methods are possible. For instance, when a network device is configured with one skipping duration (length T1), the scheduling DCI will contain 1 bit, with a value of '1' indicating that PDCCH skipping is not performed (i.e., PDCCH is monitored normally), and a value of '0' indicating that PDCCH is not monitored during the time period T1. This application does not limit this.

[0077] When network devices use scheduling DCI to indicate PDCCH skipping, it is usually done in the last scheduling DCI of each terminal device service scheduling. For example Figure 3As shown, when a terminal device continuously transmits services, the DCI carried in the PDCCH of the scheduling data (i.e., the scheduling PDSCH) always indicates "no skipping" of the PDCCH (i.e., continuous monitoring of the PDCCH) to ensure rapid data transmission. In the PDCCH of the last transmission of a service, the network device can indicate that it will not monitor the PDCCH for a certain period (i.e., the skipping duration). The network device can determine whether this is the last transmission by checking if there is still pending data for the terminal device in its buffer. However, as... Figure 3 As shown in the black section, if the terminal device's service has not arrived after the skip period, the network device generally will not schedule the terminal device's data transmission, and therefore cannot send the scheduling DCI, and thus cannot instruct the PDCCH to skip. At this time, the terminal device can only continuously monitor the PDCCH, resulting in wasted power consumption of the terminal device.

[0078] Based on this, this application proposes a communication method that can instruct the terminal device not to monitor the PDCCH for a period of time when no service arrives, thereby reducing the power consumption of the terminal device.

[0079] It should be noted that in the following embodiments, the communication method provided in this application is described in detail using terminal devices and network devices as examples. It should be understood that the operations performed by the terminal device can also be implemented by the processor, chip or chip system, or a functional module in the terminal device, and the operations performed by the network device can also be implemented by the processor, chip or chip system, or a functional module in the network device. This application does not limit these aspects.

[0080] Based on the above description, the communication method provided in this application embodiment is applicable to... Figure 1 The communication system shown. (See attached image.) Figure 4 As shown, the specific process of this method may include: Step 401: The network device determines the first DCI, which is used to schedule padding packets. The first DCI instructs the terminal device not to monitor the PDCCH within a first duration.

[0081] Step 402: The network device sends the first DCI to the terminal device.

[0082] Step 403: The terminal device determines that it will not monitor the PDCCH within the first time period based on the first DCI.

[0083] The communication method of this application, by scheduling the first DCI of the data packet to instruct the terminal device not to monitor the PDCCH within a first duration, enables the terminal device to skip PDCCH monitoring even when no service arrives, thereby reducing power consumption in the terminal device. For example Figure 5 As shown, when a terminal device continuously transmits services, the DCI carried in the PDCCH of the scheduling data (i.e., the scheduling PDSCH) always indicates "no skipping" of the PDCCH (i.e., continuous monitoring of the PDCCH) to facilitate rapid data transmission. In the PDCCH of the last transmission of a service, the network device can indicate that it will not monitor the PDCCH for a certain period (i.e., the skipping duration). Furthermore, after the skipping duration, if the terminal device's service has not yet arrived, the network device can indicate PDCCH skipping through the first DCI of the scheduling data packet, thereby reducing the terminal device's power consumption.

[0084] It should be noted that, Figure 5 The two durations for which the terminal device does not monitor the PDCCH shown can be the same or different, and this application does not impose any limitation. When the two durations are different, one possible approach is to indicate that the network device has configured at least two skip durations for the terminal device, and the two indications from the network device that the PDCCH is not monitored are different. Alternatively, the two durations can also be predefined, and this application does not impose any limitation.

[0085] In one alternative implementation, before the network device determines that the terminal device does not monitor the PDCCH within a first duration by instructing the terminal device through the first DCI, the network device may determine that no service has arrived at the terminal device within a preset duration, or the network device may determine that there is no cached data corresponding to the terminal device.

[0086] The preset duration can be a period of time before the network device sends the first DCI, or a period of time after the network device sends the first DCI, or the preset duration can be the moment when the network device sends the first DCI. When the preset duration is a period of time after the terminal device sends the first DCI, the preset duration can be less than, equal to, or greater than the first duration, and this application does not limit it in this way.

[0087] No service arrival at the terminal device can refer to no service data transmission, no data arrival, no downlink data arrival, no need to send RRC messages or media access control control element (MAC CE) to the terminal device, etc.

[0088] For example, when the preset duration is a period of time before the network device sends the first DCI, the network device can determine during this period whether there is data from the terminal device on the core network side. When it is determined that there is no data from the terminal device on the core network side, the network device determines that no service has arrived at the terminal device within the preset duration.

[0089] For example, when the preset duration is a period of time after the network device sends the first DCI, or the moment the network device sends the first DCI, the network device can use a prediction algorithm to predict whether the terminal device will receive any service within the preset duration. The prediction algorithm is not limited in this application.

[0090] When a network device determines that there is no cached data corresponding to a terminal device, it can determine that the cache (buffer) corresponding to the terminal device is empty.

[0091] For example, the first DCI may include the following two cases: Case a1: The first DCI can be used to schedule PDSCH.

[0092] Case a2: The first DCI can be used to schedule PUSCH.

[0093] In case a1 above, the first DCI can be a DCI format 1_1 or DCI format 1_2 scrambled with the cell-radio network temporary identity (C-RNTI); or, the first DCI can be a DCI format 1_1 or DCI format 1_2 scrambled with the modulation and coding scheme-cell-radio network temporary identifier (MCS-C-RNTI); or, the first DCI can be a DCI format 1_1 or DCI format 1_2 scrambled with the configured scheduling-radio network temporary identity (CS-RNTI).

[0094] In case a1 above, the network device sends a PDSCH to the terminal device (correspondingly, the terminal device receives a PDSCH from the network device). The PDSCH contains a media access control subprotocol data unit (MAC sub PDU), and the logical channel identifier (LCID) corresponding to the MAC sub-PDU is 63.

[0095] Typically, a PDSCH contains one Media Access Control Protocol Data Unit (MAC PDU). For example... Figure 6 As shown, a MAC PDU can contain one or more MAC subPDUs. Each MAC subPDU's subheader contains an LCID, which indicates the function of the corresponding MAC subPDU. For example, different LCID values ​​indicate different functions of the MAC subPDU. Table 1 below shows the meanings of different LCID values. From Table 1, it can be seen that when the LCID value is 63, it indicates that the corresponding MAC subPDU is a padding packet, meaning it does not contain meaningful data.

[0096] Therefore, in case a1 above, when the LCID value corresponding to the MAC sub-PDU in the PDSCH sent by the network device to the terminal device is 63, it means that the network device is sending a padding packet to the terminal device.

[0097] Table 1

[0098] Since the terminal device needs to receive or send PDSCH after receiving DCI, and the power consumption of sending PUSCH is usually greater than that of receiving PDSCH, from the perspective of energy saving of the terminal device, when the first DCI of scheduling PDSCH (scheduling padding) is used in the above situation a1 to instruct the terminal device not to monitor PDCCH in the first time period, the power consumption of the terminal device can usually be lower than that of the first DCI in situation a2.

[0099] In case a2 above, the first DCI can be DCI format 0_1 ​​or DCI format 0_2 scrambled by C-RNTI; or, the first DCI can be DCI format 0_1 ​​or DCI format 0_2 scrambled by MCS-C-RNTI; or, the first DCI can be DCI format 0_1 ​​or DCI format 0_2 scrambled by CS-RNTI.

[0100] In case a2 above, when the terminal device is not configured with uplink skip function, the terminal device sends PUSCH to the network device (correspondingly, the network device receives PUSCH from the terminal device). The PUSCH contains MAC sub PDU, and the LCID value corresponding to the MAC sub PDU is 63.

[0101] Similar to PDSCH, a PUSCH typically contains one MAC PDU, and so on. Figure 6 As shown, a MAC PDU can contain one or more MAC sub-PDUs. Each MAC sub-PDU's subheader contains an LCID, which indicates the function of the corresponding MAC sub-PDU. Table 1 shows that when the LCID value is 63, it indicates that the corresponding MAC sub-PDU is a padding packet, meaning it does not contain meaningful data.

[0102] Therefore, in case a2 above, when the LCID value corresponding to the MAC sub-PDU contained in the PUSCH sent by the terminal device to the network device is 63, it means that the terminal device is sending a padding packet to the network device.

[0103] In one optional implementation, when the terminal device is not configured with uplink skipping functionality, it can send a PUSCH containing uplink data to the network device when a service temporarily arrives. In this case, the terminal device does not send a padding packet to the network device. If the terminal device does not send a scheduling request (SR) or buffer status report (BSR) to the network device, the network device cannot know whether the terminal device has uplink data to send when scheduling the terminal device to send a PUSCH via the first DCI. After receiving the first DCI, the terminal device will include uplink data in the PUSCH if there is uplink data, and include a padding packet in the PUSCH if there is no uplink data. If uplink data has already arrived when the terminal device receives the first DCI, even if the terminal device has not yet sent the corresponding SR or BSR request to the network device for scheduling, the terminal device can still send the uplink data to the network device via the PUSCH scheduled by the first DCI.

[0104] In case a2 above, when the terminal device is configured with the uplink skip function, the terminal device may not send PUSCH to the network device.

[0105] When the terminal device is configured with uplink skipping, if the terminal device receives the DCI of the scheduled PUSCH but has no uplink data to send, the terminal device can choose not to send the PUSCH. In other words, in case a2 above, when the terminal device is configured with uplink skipping, after the network device sends the first DCI, the terminal device neither needs to send the PUSCH nor receive the PDSCH. Therefore, from the perspective of energy saving for the terminal device, when the terminal device is configured with uplink skipping, using the first DCI of the scheduled PUSCH (scheduled padding) in case a2 above to instruct the terminal device not to monitor the PDSCH for the first duration can result in lower power consumption for the terminal device compared to when using the first DCI in case a1.

[0106] Optionally, when the terminal device is configured with uplink skipping, if a temporary service arrives at the terminal device, i.e., when uplink data needs to be sent, the terminal device can send uplink data to the network device through the PUSCH scheduled by the network device. In this case, the terminal device does not need to request uplink resources from the network device through a scheduling request (SR), thereby reducing service latency.

[0107] In one possible implementation, the terminal device can be configured for connected discontinuous reception (CDRX). The CDRX period can be a long DRX period or a short DRX period. The long DRX period is required by default, while the short DRX period is optional. If a short DRX period is configured, the terminal device will start a short-cycle timer when using the short DRX period. When the short-cycle timer expires, it will switch to a long DRX period.

[0108] For example, such as Figure 7 As shown, the CDRX cycle includes an "On Duration" portion and a "DRX Opportunity for DRX" portion. The terminal device monitors the PDCCH during the OnDuration of each CDRX cycle. If no new transmission data schedule is received during the OnDuration (i.e., no PDCCH indicating a new transmission is received), the device enters the Opportunity for DRX phase after the OnDuration ends, ceasing PDCCH monitoring until the next OnDuration cycle. If a new transmission data schedule is received during the OnDuration (i.e., a PDCCH indicating a new transmission is received), the terminal device starts an inactive timer (or deactivated timer) (InactivityTimer or DRX-inactivitytimer). The terminal device continues to monitor the PDCCH during the InactivityTimer's execution. If another new transmission data schedule is received during the InactivityTimer's execution, the InactivityTimer is restarted. Both the OnDuration and InactivityTimer execution periods are referred to as the active time, during which the terminal device monitors the PDCCH. Restarting InactivityTimer can be understood as extending the active time of the terminal device. When InactivityTimer times out, the terminal device stops monitoring PDCCH.

[0109] The method for determining whether it is "new data scheduling" is to check whether the new data indicator (NDI) field in the DCI (NDI is 1 bit, with a value of '0' or '1') has toggled. If, for the same hybrid automatic repeat request process (HARQ process) (i.e., the HARQ process number (HPN) field has the same value), the NDI in the DCI received by the terminal device has toggled compared to the NDI of the previously received DCI (e.g., NDI toggles from 0 to 1, or from 1 to 0), then it is considered that new data was transmitted using that HARQ process; if the NDI in the DCI received by the terminal device is the same as the NDI of the previously received DCI, then it is considered that data retransmission was performed using that HARQ process.

[0110] In some embodiments, when a network device instructs a terminal device configured with CDRX not to monitor the PDCCH for a period of time, it can do so as follows: Figure 8 As shown, network devices can instruct terminal devices not to monitor the PDCCH during certain periods within the active time by scheduling the DCI, thereby increasing the sleep time of terminal devices based on the CDRX mechanism. In this case, there is still a possibility that the network device cannot instruct the terminal device to skip the PDCCH when no service arrives at the terminal device.

[0111] However, using the method described in scenario a1 above, scheduling the first DCI of PDSCH (including padding packets) may cause the InactivityTimer to restart, resulting in an extended active time for the terminal device. This extended active time may increase the duration the terminal device needs to monitor PDCCH, thus increasing the terminal device's power consumption.

[0112] Based on this, in the above situation a1, when the terminal device is configured with CDRX, after the terminal device receives the PDSCH containing the padding data packet from the network device, the terminal device does not start the DRX-inactivitytimer; or, when the DRX-inactivitytimer is running, after the terminal device receives the PDSCH containing the padding data packet from the network device, it does not restart or stop the DRX-inactivitytimer.

[0113] Similarly, when the terminal device is configured with CDRX, after the network device sends a PDSCH including padding data packets to the terminal device, the network device does not start the DRX-inactivitytimer; or, when the DRX-inactivitytimer is running, after the network device sends a PDSCH including padding data packets to the terminal device, it does not restart or stop the DRX-inactivitytimer.

[0114] Using the method described in scenario a2 above, scheduling the first DCI of PUSCH (including padding data packets) may also cause the InactivityTimer to restart, resulting in an extension of the active time of the terminal device. The extension of the active time may increase the duration for which the terminal device needs to monitor PDCCH, thereby increasing the power consumption of the terminal device.

[0115] Therefore, in case a2 above, when the terminal device is configured with CDRX but not with uplink skip function, after the terminal device sends a PUSCH containing padding data to the network device, the terminal device does not start DRX-inactivitytimer; or, when the DRX-inactivitytimer is running, after the terminal device sends a PUSCH containing padding data to the network device, it does not restart or stop DRX-inactivitytimer.

[0116] Similarly, when the terminal device is configured with CDRX, the network device does not start the DRX-inactivitytimer after receiving the PUSCH containing padding packets from the terminal device; or, when the DRX-inactivitytimer is running, the network device does not restart or stop the DRX-inactivitytimer after receiving the PUSCH containing padding packets from the terminal device. After decoding the PUSCH, the network device can determine whether the PUSCH contains padding packets, and thus determine whether to start, restart, or stop the DRX-inactivitytimer.

[0117] Alternatively, in case a2 above, when the terminal device is configured with CDRX and uplink skip function, if the terminal device does not send PUSCH, that is, after the terminal device determines (because there is no data to be transmitted) not to send PUSCH, the terminal device does not start DRX-inactivitytimer; or, when the DRX-inactivitytimer is running, if the terminal device does not send PUSCH, that is, after the terminal device determines (because there is no data to be transmitted) not to send PUSCH, the DRX-inactivitytimer is not restarted or stopped.

[0118] Similarly, when the terminal device is configured with CDRX, if the network device does not receive the PUSCH sent by the terminal device at the position indicated by the first DCI (i.e., the time-frequency position where the terminal device sends the PUSCH as indicated when the first DCI schedules the PUSCH), the network device will not start the DRX-inactivitytimer; or, when the DRX-inactivitytimer is running, if the network device does not receive the PUSCH sent by the terminal device at the position indicated by the first DCI, it will not restart or stop the DRX-inactivitytimer.

[0119] By using the methods described above, the active time of the terminal device can be extended, thereby saving power consumption of the terminal device.

[0120] In an optional implementation, in the methods described in cases a1 and a2 above, the value of the NDI field in the first DCI can be different from the value of the NDI field in the third DCI, and the third DCI is the preceding DCI with the same value of the HARQ HPN field as the first DCI. In this case, the first DCI can be understood as the new transmission DCI.

[0121] When a terminal is configured with CDRX and the first DCI is a new transmission DCI, the terminal device is instructed to skip monitoring PDCCH by the padding packet scheduled through the first DCI (included in PDSCH or PUSCH). Therefore, the terminal device and network device do not need to start DRX-inactivitytimer. Thus, by not starting, restarting or stopping DRX-inactivitytimer, the active time of the terminal device is avoided, thereby saving the power consumption of the terminal device.

[0122] In an optional implementation, in the method described in case a1 above, the value of the NDI field in the first DCI can be the same as the value of the NDI field in the second DCI, and the second DCI is the preceding DCI whose HARQ HPN field value is the same as that of the first DCI. In this case, the first DCI can be understood as a retransmission DCI.

[0123] When the first DCI is a retransmission DCI, before the terminal device receives the first DCI from the network device, and after the terminal device receives the second DCI from the network device, it sends an acknowledgment (ACK) message to the network device.

[0124] Normally, when a terminal device receives a PDSCH error, it sends a NACK, prompting the network device to schedule a retransmission of the same data. Upon receiving the retransmitted data, the terminal device merges and decodes it with previously received data stored in the buffer. When the first DCI is a retransmission DCI, although the network device sends the retransmission DCI, after the data in the same HARQ process has been correctly transmitted (the terminal device sends an ACK), the terminal device usually clears the historical data packets stored in the buffer. Therefore, the data scheduled for the retransmission DCI is usually not merged and decoded with previously received data, but rather decoded separately. After decoding the data packet scheduled by the first DCI separately, the terminal device can identify the currently scheduled data packet as a padding packet.

[0125] In addition, when the terminal is configured with CDRX and the first DCI is the retransmission DCI, the terminal device and network device can avoid the active time of the terminal device by not starting, restarting or stopping the DRX-inactivitytimer, thereby saving the power consumption of the terminal device.

[0126] Using the communication method provided in this application embodiment, when no service arrives at the terminal device, the terminal device can be instructed not to monitor the PDCCH for a first time period by scheduling the DCI that fills the data packets, thereby reducing the power consumption of the terminal device.

[0127] This application also provides another communication method, applicable to Figure 1 The communication system shown. (See attached image.) Figure 9 As shown, the specific process of this method may include: Step 901: The network device sends downlink padding data packets to the terminal device, and the terminal device receives downlink padding data packets from the network device accordingly.

[0128] In one alternative implementation, the network device can send downlink padding packets to the terminal device in the following manner: the network device sends a PDSCH to the terminal device, the PDSCH containing a MAC sub-PDU, and the LCID value corresponding to the MAC sub-PDU is 63.

[0129] Specifically, for details regarding the LCID value of 63 corresponding to the MAC sub-PDU in PDSCH indicating the padding of data packets, please refer to [link / reference needed]. Figure 4 The embodiments shown are combined with Figure 6 The description of PDSCH in Table 1 will not be described in detail here.

[0130] Step 902: The network device determines that the terminal device does not monitor the PDCCH during the second time period.

[0131] Step 903: The terminal device determines that it will not monitor the PDCCH during the second duration based on the downlink padding data packet.

[0132] It should be noted that the order of steps 902 and 903 is not limited in this application.

[0133] For example, a network device can send a DCI to an end device, which is used to schedule the downlink padding data packet. The DCI instructs the end device not to monitor the PDCCH for a second time period after receiving the downlink padding data packet. In this way, the end device can determine that it will not monitor the PDCCH for the second time period after receiving the downlink data packet.

[0134] Optionally, the second duration can be configured by the network device for the terminal device, or it can be predefined, or it can be indicated by the network device when sending downlink padding packets to the terminal device. For example, the PDSCH sent by the network device to the terminal device contains both downlink padding packets and the second duration.

[0135] For example, the DCI can be DCI format 1_0, DCI format 1_1, or DCI format 1_2.

[0136] Using the above method, after the terminal device receives the downlink padding data packet, it can achieve a period of time without monitoring the PDCCH, thereby saving the power consumption of the terminal device.

[0137] This application also provides another communication method, applicable to Figure 1 The communication system shown. (See attached image.) Figure 10 As shown, the specific process of this method may include: Step 1001: The network device sends downlink padding data packets to the terminal device.

[0138] Specifically, the relevant description of the network device sending downlink padding data packets to the terminal device can be found in the relevant description in step 901 above, and will not be repeated here.

[0139] Step 1002: The network device does not start DRX-inactivitytimer; or, when DRX-inactivitytimer is running, the network device does not restart or stop DRX-inactivitytimer.

[0140] Step 1003: The terminal device determines that it will not start DRX-inactivitytimer based on the downlink padding data packet; or, when DRX-inactivitytimer is running, it determines that the terminal device will not restart or stop DRX-inactivitytimer.

[0141] It should be noted that the order of steps 1002 and 1003 is not limited in this application.

[0142] By using the above method, after the terminal device receives the downlink padding data packet, by not starting the DRX-inactivitytimer, or by not restarting or stopping the running DRX-inactivitytimer, the activation time of the terminal device can be avoided, thereby reducing the power consumption of the terminal device.

[0143] Based on the above embodiments, this application also provides a communication device, see below. Figure 11 As shown, the communication device 1100 may include a transceiver unit 1101 and a processing unit 1102. The transceiver unit 1101 is used for receiving or sending information (messages or data) to the communication device 1100, and the processing unit 1102 is used for controlling and managing the operations of the communication device 1100. The processing unit 1102 can also control the steps performed by the transceiver unit 1101.

[0144] For example, the communication device 1100 may specifically be a network device, a processor or chip in the network device, a chip system, or a functional module, etc., as described in the above embodiments; or, the communication device 1100 may specifically be a terminal device, a processor or chip in the terminal device, a chip system, or a functional module, etc., as described in the above embodiments.

[0145] In one embodiment, the communication device 1100 is used to implement the above. Figure 4 In the embodiments described above, the terminal device functions as follows: the transceiver unit 1101 is used to receive a first DCI from the network device, the first DCI is used to schedule padding data packets, and the first DCI indicates that the terminal device does not monitor the physical downlink control channel (PDCCH) within a first duration; the processing unit 1102 is used to determine, based on the first DCI, that it does not monitor the PDCCH within the first duration.

[0146] In one optional implementation, the first DCI is used to schedule the Physical Downlink Shared Channel (PDSCH).

[0147] For example, the first DCI is a DCI format 1_1 or DCI format 1_2 scrambled with the Cell Radio Network Temporary Identifier (C-RNTI); or, the first DCI is a DCI format 1_1 or DCI format 1_2 scrambled with the Modulation and Coding Scheme Cell-Specific Radio Network Temporary Identifier (MCS-C-RNTI); or, the first DCI is a DCI format 1_1 or DCI format 1_2 scrambled with the Configuration and Scheduling Radio Network Temporary Identifier (CS-RNTI).

[0148] Optionally, the transceiver unit 1101 is further configured to receive a Physical Downlink Shared Channel (PDSCH) from the network device, wherein the PDSCH includes a Media Access Control Sub-Protocol Data Unit (MAC sub PDU), and the logical channel identifier (LCID) corresponding to the MAC sub PDU has a value of 63.

[0149] In another alternative implementation, the first DCI is used to schedule the Physical Uplink Shared Channel (PUSCH).

[0150] For example, the first DCI is a DCI format 0_1 ​​or DCI format 0_2 scrambled with the Cell Radio Network Temporary Identifier (C-RNTI); or, the first DCI is a DCI format 0_1 ​​or DCI format 0_2 scrambled with the Modulation and Coding Scheme Cell-Specific Radio Network Temporary Identifier (MCS-C-RNTI); or, the first DCI is a DCI format 0_1 ​​or DCI format 0_2 scrambled with the Configuration and Scheduling Radio Network Temporary Identifier (CS-RNTI).

[0151] Optionally, the transceiver unit 1101 is further configured to send a Physical Uplink Shared Channel (PUSCH) to the network device, wherein the PUSCH includes a Media Access Control Sub-Protocol Data Unit (MAC sub PDU), and the Logical Channel Identifier (LCID) corresponding to the MAC sub PDU has a value of 63.

[0152] In one possible manner, the transceiver unit 1101 is further configured to send a Physical Uplink Shared Channel (PUSCH) to the network device, wherein the PUSCH contains the padding data packet; the processing unit 1102 is further configured to not start the discontinuous reception inactivity timer DRX-inactivitytimer; or, when the DRX-inactivitytimer is running, not to restart or stop the DRX-inactivitytimer.

[0153] In one example, when the terminal device is configured with uplink skip function, the transceiver unit 1101 is also used to not send the Physical Uplink Shared Channel (PUSCH) to the network device.

[0154] In another possible approach, when the transceiver unit 1101 is also configured not to send the Physical Uplink Shared Channel (PUSCH) to the network device, the processing unit 1102 is also configured not to start the discontinuous reception inactivity timer (DRX-inactivitytimer); or, when the DRX-inactivitytimer is running, the DRX-inactivitytimer is not restarted or stopped.

[0155] In one example, the transceiver unit 1101 is further configured to receive a Physical Downlink Shared Channel (PDSCH) from the network device, wherein the PDSCH includes the padding data packet; the processing unit 1102 is further configured to not start the discontinuous reception inactivity timer (DRX-inactivitytimer); or, when the DRX-inactivitytimer is running, not to restart or stop the DRX-inactivitytimer.

[0156] Optionally, the value of the New Data Indicator (NDI) field in the first DCI is the same as the value of the NDI field in the second DCI, and the second DCI is the previous DCI with the same value as the Hybrid Automatic Repeat Request (HARQ) process number (HPN) field of the first DCI.

[0157] For example, the transceiver unit 1101 is further configured to receive the second DCI from the network device before receiving the first DCI from the network device, and send a correct response ACK information to the network device.

[0158] Optionally, the value of the New Data Indicator (NDI) field in the first DCI is different from the value of the NDI field in the third DCI, wherein the third DCI is the previous DCI with the same value as the Hybrid Automatic Repeat Request (HARQ) process number (HPN) field of the first DCI.

[0159] In another embodiment, the communication device 1100 is used to implement the above. Figure 4 In the embodiments described above, the functions of the network device may specifically include: the processing unit 1102 is used to determine a first downlink control information (DCI), the first DCI is used to schedule padding data packets, and the first DCI instructs the terminal device not to monitor the physical downlink control channel (PDCCH) within a first duration; the transceiver unit 1101 is used to send the first DCI to the terminal device.

[0160] Optionally, the processing unit 1102 is further configured to: determine that no service has arrived at the terminal device within a preset time period before the transceiver unit 1101 sends the first DCI to the terminal device; or determine that there is no cached data corresponding to the terminal device.

[0161] In one optional implementation, the first DCI is used to schedule the Physical Downlink Shared Channel (PDSCH).

[0162] For example, the first DCI is a DCI format 1_1 or DCI format 1_2 scrambled with the Cell Radio Network Temporary Identifier (C-RNTI); or, the first DCI is a DCI format 1_1 or DCI format 1_2 scrambled with the Modulation and Coding Scheme Cell-Specific Radio Network Temporary Identifier (MCS-C-RNTI); or, the first DCI is a DCI format 1_1 or DCI format 1_2 scrambled with the Configuration and Scheduling Radio Network Temporary Identifier (CS-RNTI).

[0163] Optionally, the network device sends a Physical Downlink Shared Channel (PDSCH) to the terminal device. The PDSCH includes a Media Access Control Sub-Protocol Data Unit (MAC sub PDU), and the Logical Channel Identifier (LCID) corresponding to the MAC sub PDU has a value of 63.

[0164] In one alternative implementation, the first DCI is used to schedule the Physical Uplink Shared Channel (PUSCH).

[0165] For example, the first DCI is a DCI format 0_1 ​​or DCI format 0_2 scrambled with the Cell Radio Network Temporary Identifier (C-RNTI); or, the first DCI is a DCI format 0_1 ​​or DCI format 0_2 scrambled with the Modulation and Coding Scheme Cell-Specific Radio Network Temporary Identifier (MCS-C-RNTI); or, the first DCI is a DCI format 0_1 ​​or DCI format 0_2 scrambled with the Configuration and Scheduling Radio Network Temporary Identifier (CS-RNTI).

[0166] In one possible design, the transceiver unit 1101 is further configured to receive the Physical Uplink Shared Channel (PUSCH) from the terminal device, wherein the PUSCH includes a Media Access Control Sub-Protocol Data Unit (MAC subPDU), and the logical channel identifier (LCID) corresponding to the MAC subPDU is 63.

[0167] In another possible design, when the terminal device is configured with uplink skip function, the transceiver unit 1101 is also used to not receive PUSCH from the terminal device.

[0168] In one example, the transceiver unit 1101 is further configured to receive the Physical Uplink Shared Channel (PUSCH) from the terminal device, wherein the PUSCH contains the padding data packet; the processing unit 1102 is further configured to not start the discontinuous reception inactivity timer DRX-inactivitytimer; or, when the DRX-inactivitytimer is running, not to restart or stop the DRX-inactivitytimer.

[0169] In another example, the processing unit 1102 is further configured to not start the discontinuous reception inactivity timer DRX-inactivitytimer if the transceiver unit 1101 does not receive the physical uplink shared channel (PUSCH) sent by the terminal device at the location indicated by the first DCI; or, when the DRX-inactivitytimer is running, not to restart or stop the DRX-inactivitytimer.

[0170] In another example, the transceiver unit 1101 is further configured to send a Physical Downlink Shared Channel (PDSCH) to the terminal device, wherein the PDSCH includes the padding data packet; the processing unit 1102 is further configured to not start the discontinuous reception inactivity timer (DRX-inactivitytimer); or, when the DRX-inactivitytimer is running, not to restart or stop the DRX-inactivitytimer.

[0171] Optionally, the value of the New Data Indicator (NDI) field in the first DCI is the same as the value of the NDI field in the second DCI, and the second DCI is the previous DCI with the same value as the Hybrid Automatic Repeat Request (HARQ) process number (HPN) field of the first DCI.

[0172] For example, the transceiver unit 1101 is further configured to send the second DCI to the terminal device before sending the first DCI to the terminal device, and receive a correct response ACK information from the terminal device.

[0173] Optionally, the value of the New Data Indicator (NDI) field in the first DCI is different from the value of the NDI field in the third DCI, wherein the third DCI is the previous DCI with the same value as the Hybrid Automatic Repeat Request (HARQ) process number (HPN) field of the first DCI.

[0174] In another embodiment, the communication device 1100 is used to implement the above. Figure 9 or Figure 10In the embodiments described above, the functions of the terminal device may specifically include: the transceiver unit 1101 is used to receive downlink padding data packets from the network device; and the processing unit 1102 is used to determine a first operation of the terminal device based on the downlink padding data packets.

[0175] For example, when the transceiver unit 1101 receives the downlink padding data packet from the network device, it can be used to: receive the Physical Downlink Shared Channel (PDSCH) from the network device, wherein the PDSCH includes a Media Access Control Sub-Protocol Data Unit (MAC sub PDU), and the Logical Channel Identifier (LCID) corresponding to the MAC sub PDU has a value of 63.

[0176] In one alternative implementation, the first operation is to not monitor the Physical Downlink Control Channel (PDCCH) for a second duration.

[0177] Optionally, the transceiver unit 1101 is further configured to receive downlink control information (DCI) from the network device, the DCI being used to schedule the downlink padding data packet, and the DCI instructing the terminal device not to monitor the PDCCH within the second duration after receiving the downlink padding data packet.

[0178] For example, the DCI is DCI format 1_0.

[0179] In another optional implementation, the first operation is to not start the discontinuous reception inactivity timer DRX-inactivitytimer; or, when the DRX-inactivitytimer is running, the first operation is to not restart or stop the DRX-inactivitytimer.

[0180] In another embodiment, the communication device 1100 is used to implement the above. Figure 9 The network device functions as described in the embodiments may specifically include: the transceiver unit 1101 is used to send downlink padding data packets to the terminal device; the processing unit 1102 is used to determine that the terminal device does not monitor the physical downlink control channel (PDCCH) within a second time period.

[0181] Optionally, when the transceiver unit 1101 sends the downlink padding data packet to the terminal device, it can be used to: send a Physical Downlink Shared Channel (PDSCH) to the terminal device, wherein the PDSCH includes a Media Access Control Sub-Protocol Data Unit (MAC sub-PDU), and the logical channel identifier (LCID) corresponding to the MAC sub-PDU has a value of 63.

[0182] For example, the transceiver unit 1101 is further configured to send downlink control information (DCI) to the terminal device, the DCI being used to schedule the downlink padding data packet, and the DCI instructing the terminal device not to monitor the PDCCH within the second duration after receiving the downlink padding data packet.

[0183] In one example, the DCI is DCI format 1_0.

[0184] In another embodiment, the communication device 1100 is used to implement the above. Figure 10 The network device functions as described in the embodiments may specifically include: the transceiver unit 1101 is used to send downlink padding data packets to the terminal device; the processing unit 1102 is used to not start the discontinuous reception inactivity timer DRX-inactivitytimer; or, when the DRX-inactivitytimer is running, the DRX-inactivitytimer is not restarted or stopped.

[0185] Optionally, when the transceiver unit 1101 sends the downlink padding data packet to the terminal device, it is configured to: send a Physical Downlink Shared Channel (PDSCH) to the terminal device, wherein the PDSCH includes a Media Access Control Sub-Protocol Data Unit (MAC sub-PDU), and the logical channel identifier (LCID) corresponding to the MAC sub-PDU has a value of 63.

[0186] 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, there may be other division methods. The functional units in the 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.

[0187] 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 computer-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.

[0188] Based on the above embodiments, this application also provides a communication device, see below. Figure 12 As shown, the communication device 1200 may include a transceiver 1201 and a processor 1202. Optionally, the communication device 1200 may also include a memory 1203. The memory 1203 may be located inside or outside the communication device 1200. The processor 1202 can control the transceiver 1201 to receive and send information, messages, or data.

[0189] Specifically, the processor 1202 may be a central processing unit (CPU), a network processor (NP), or a combination of a CPU and an NP. The processor 1202 may further include a hardware chip. This hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0190] The transceiver 1201, processor 1202, and memory 1203 are interconnected. Optionally, the transceiver 1201, processor 1202, and memory 1203 are interconnected via a bus 1204; the bus 1204 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 12 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0191] In one optional implementation, the memory 1203 is used to store programs, etc. Specifically, the program may include program code, which includes computer operation instructions. The memory 1203 may include RAM, and may also include non-volatile memory, such as one or more disk storage devices. The processor 1202 executes the application program stored in the memory 1203 to achieve the above-mentioned functions, thereby realizing the functions of the communication device 1200.

[0192] For example, the communication device 1200 may be a network device in the above embodiments; or it may be a terminal device in the above embodiments.

[0193] In one embodiment, the communication device 1200 implements Figure 4 , Figure 9 or Figure 10 In the embodiment shown, the transceiver 1201 can implement the functions of the terminal device. Figure 4 , Figure 9 or Figure 10 The transmit and receive operations performed by the terminal device in the illustrated embodiment; the processor 1202 can implement Figure 4 , Figure 9 or Figure 10 The embodiments shown depict operations performed by the terminal device other than sending and receiving operations. For detailed descriptions, please refer to the above. Figure 4 , Figure 9 or Figure 10 The relevant descriptions in the illustrated embodiments will not be detailed here.

[0194] In one embodiment, the communication device 1200 implements Figure 4 , Figure 9 or Figure 10 In the embodiment shown, the transceiver 1201 can perform the functions of the network device. Figure 4 , Figure 9 or Figure 10 The transmit and receive operations performed by the network device in the illustrated embodiment; the processor 1202 can implement Figure 4 , Figure 9 or Figure 10 The embodiments shown depict operations performed by the network device other than sending and receiving operations. For detailed descriptions, please refer to the above. Figure 4 , Figure 9 or Figure 10 The relevant descriptions in the illustrated embodiments will not be detailed here.

[0195] Based on the above embodiments, this application provides a communication system, which may include the terminal devices and network devices involved in the above embodiments.

[0196] This application also provides a computer-readable storage medium for storing a computer program. When the computer program is executed by a computer, the computer can implement the communication method provided in the above-described method embodiments.

[0197] This application also provides a computer program product for storing a computer program. When the computer program is executed by a computer, the computer can implement the communication method provided in the above method embodiments.

[0198] This application also provides a chip, including a processor coupled to a memory, for calling a program in the memory to enable the chip to implement the communication method provided in the above method embodiments.

[0199] This application also provides a chip coupled to a memory, which is used to implement the communication method provided in the above method embodiments.

[0200] 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 embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0201] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should 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 program instructions. These computer program 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, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0202] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0203] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0204] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the 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 communication method, characterized in that, include: The terminal device receives a first downlink control information (DCI) from the network device. The first DCI is used to schedule padding data packets. The first DCI instructs the terminal device not to monitor the physical downlink control channel (PDCCH) for a first duration. The first DCI is used to schedule the physical downlink shared channel (PDSCH) or the first DCI is used to schedule the physical uplink shared channel (PUSCH). The terminal device determines, based on the first DCI, that it will not monitor the PDCCH within the first duration. Wherein, when the first DCI is used to schedule PDSCH, the method further includes: the terminal device receiving a Physical Downlink Shared Channel (PDSCH) from the network device, wherein the PDSCH includes a Media Access Control Sub-Protocol Data Unit (MACsub PDU), and the Logical Channel Identifier (LCID) corresponding to the MAC sub PDU has a value of 63. When the first DCI is used to schedule PUSCH, the method further includes: the terminal device sending a Physical Uplink Shared Channel (PUSCH) to the network device, wherein the PUSCH contains a Media Access Control Sub-Protocol Data Unit (MAC subPDU), and the Logical Channel Identifier (LCID) corresponding to the MAC subPDU has a value of 63.

2. The method as described in claim 1, characterized in that, When the first DCI is used for scheduling PDSCH, the first DCI is a DCI format 1_1 or DCI format 1_2 scrambled with the Cell Radio Network Temporary Identifier (C-RNTI); or The first DCI is a DCI format 1_1 or DCI format 1_2 scrambled with the Modulation and Coding Scheme Cell-Specific Radio Network Temporary Identifier (MCS-C-RNTI); or The first DCI is either DCI format 1_1 or DCI format 1_2 scrambled with the configuration scheduling radio network temporary identifier CS-RNTI.

3. The method as described in claim 1, characterized in that, When the first DCI is used for scheduling PUSCH, the first DCI is a DCI format 0_1 ​​or DCI format 0_2 scrambled with the Cell Radio Network Temporary Identifier (C-RNTI); or The first DCI is a DCI format 0_1 ​​or DCI format 0_2 scrambled with the Modulation and Coding Scheme Cell-Specific Radio Network Temporary Identifier (MCS-C-RNTI); or The first DCI is either DCI format 0_1 ​​or DCI format 0_2 scrambled with the configuration scheduling radio network temporary identifier CS-RNTI.

4. The method as described in claim 1 or 3, characterized in that, When the first DCI is used to schedule PUSCH, the method further includes: The terminal device sends a Physical Uplink Shared Channel (PUSCH) to the network device, wherein the PUSCH contains the padding data packet; The terminal device does not start the discontinuous reception inactivity timer DRX-inactivitytimer; or, when the DRX-inactivitytimer is running, the terminal device does not restart or stop the DRX-inactivitytimer.

5. The method as described in claim 1 or 3, characterized in that, When the first DCI is used to schedule PUSCH, and the terminal device is configured with uplink skip function, the method further includes: The terminal device does not send the Physical Uplink Shared Channel (PUSCH) to the network device.

6. The method as described in claim 5, characterized in that, The method further includes: The terminal device does not start the discontinuous reception inactivity timer DRX-inactivitytimer; or, when the DRX-inactivitytimer is running, the terminal device does not restart or stop the DRX-inactivitytimer.

7. The method according to any one of claims 1-2, characterized in that, When the first DCI is used to schedule PDSCH, the method further includes: The terminal device receives the Physical Downlink Shared Channel (PDSCH) from the network device, wherein the PDSCH includes the padding data packet; The terminal device does not start the discontinuous reception inactivity timer DRX-inactivitytimer; or, when the DRX-inactivitytimer is running, the terminal device does not restart or stop the DRX-inactivitytimer.

8. The method according to any one of claims 1-2, characterized in that, When the first DCI is used to schedule PDSCH, the value of the New Data Indicator (NDI) field in the first DCI is the same as the value of the NDI field in the second DCI. The second DCI is the previous DCI with the same value as the Hybrid Automatic Repeat Request (HARQ) process number (HPN) field of the first DCI.

9. The method as described in claim 8, characterized in that, Before the terminal device receives the first DCI from the network device, the method further includes: The terminal device receives the second DCI from the network device and sends a correct response ACK information to the network device.

10. The method according to any one of claims 1-3, characterized in that, The new data indication NDI field value in the first DCI is different from the NDI field value in the third DCI, where the third DCI is the previous DCI with the same value as the HARQ process number HPN field value in the first DCI.

11. A communication method, characterized in that, include: The network device determines a first downlink control information (DCI), which is used to schedule padding data packets. The first DCI instructs the terminal device not to monitor the physical downlink control channel (PDCCH) for a first duration. The first DCI is used to schedule the physical downlink shared channel (PDSCH) or the first DCI is used to schedule the physical uplink shared channel (PUSCH). The network device sends the first DCI to the terminal device; Wherein, when the first DCI is used to schedule PDSCH, the method further includes: the network device sending a Physical Downlink Shared Channel (PDSCH) to the terminal device, wherein the PDSCH contains a Media Access Control Sub-Protocol Data Unit (MACsub PDU), and the Logical Channel Identifier (LCID) corresponding to the MAC sub PDU has a value of 63. When the first DCI is used to schedule PUSCH, the method further includes: the network device receiving a Physical Uplink Shared Channel (PUSCH) from the terminal device, wherein the PUSCH contains a Media Access Control Sub-Protocol Data Unit (MAC subPDU), and the Logical Channel Identifier (LCID) corresponding to the MAC subPDU has a value of 63.

12. The method as described in claim 11, characterized in that, Before the network device sends the first DCI to the terminal device, the method further includes: The network device determines that no service has arrived at the terminal device within a preset time period; or The network device determines that there is no cached data corresponding to the terminal device.

13. The method as described in claim 11 or 12, characterized in that, When the first DCI is used for scheduling PDSCH, the first DCI is a DCI format 1_1 or DCI format 1_2 scrambled with the Cell Radio Network Temporary Identifier (C-RNTI); or The first DCI is a DCI format 1_1 or DCI format 1_2 scrambled with the Modulation and Coding Scheme Cell-Specific Radio Network Temporary Identifier (MCS-C-RNTI); or The first DCI is either DCI format 1_1 or DCI format 1_2 scrambled with the configuration scheduling radio network temporary identifier CS-RNTI.

14. The method as described in claim 11 or 12, characterized in that, When the first DCI is used for scheduling PUSCH, the first DCI is a DCI format 0_1 ​​or DCI format 0_2 scrambled with the Cell Radio Network Temporary Identifier (C-RNTI); or The first DCI is a DCI format 0_1 ​​or DCI format 0_2 scrambled with the Modulation and Coding Scheme Cell-Specific Radio Network Temporary Identifier (MCS-C-RNTI); or The first DCI is either DCI format 0_1 ​​or DCI format 0_2 scrambled with the configuration scheduling radio network temporary identifier CS-RNTI.

15. The method as described in claim 11 or 12, characterized in that, When the first DCI is used to schedule PUSCH, and the terminal device is configured with uplink skip function, the method further includes: The network device does not receive PUSCH from the terminal device.

16. The method according to any one of claims 11-12, characterized in that, When the first DCI is used to schedule PUSCH, the method further includes: The network device receives the Physical Uplink Shared Channel (PUSCH) from the terminal device, wherein the PUSCH contains the padding data packet; The network device does not start the discontinuous reception inactivity timer DRX-inactivitytimer; or, when the DRX-inactivitytimer is running, the network device does not restart or stop the DRX-inactivitytimer.

17. The method according to any one of claims 11-12, characterized in that, The method further includes: The network device did not receive the Physical Uplink Shared Channel (PUSCH) sent by the terminal device at the location indicated by the first DCI. The network device does not start the discontinuous reception inactivity timer DRX-inactivitytimer; or, when the DRX-inactivitytimer is running, the network device does not restart or stop the DRX-inactivitytimer.

18. The method according to any one of claims 11-12, characterized in that, The method further includes: The network device sends a Physical Downlink Shared Channel (PDSCH) to the terminal device, wherein the PDSCH includes the padding data packet; The network device does not start the discontinuous reception inactivity timer DRX-inactivitytimer; or, when the DRX-inactivitytimer is running, the network device does not restart or stop the DRX-inactivitytimer.

19. The method according to any one of claims 11-12, characterized in that, The value of the New Data Indicator (NDI) field in the first DCI is the same as the value of the NDI field in the second DCI. The second DCI is the previous DCI with the same value as the Hybrid Automatic Repeat Request (HARQ) process number (HPN) field of the first DCI.

20. The method as described in claim 19, characterized in that, Before the network device sends the first DCI to the terminal device, the method further includes: The network device sends the second DCI to the terminal device and receives the correct ACK information from the terminal device.

21. The method according to any one of claims 11-12, characterized in that, The new data indication NDI field value in the first DCI is different from the NDI field value in the third DCI, where the third DCI is the previous DCI with the same value as the HARQ process number HPN field value in the first DCI.

22. A communication device, characterized in that, Includes memory, processor, and transceiver, wherein: The memory is used to store computer instructions; The transceiver is used to receive and send information; The processor is coupled to the memory and is used to invoke computer instructions in the memory to perform the method as described in any one of claims 1-10 via the transceiver.

23. A communication device, characterized in that, Includes memory, processor, and transceiver, wherein: The memory is used to store computer instructions; The transceiver is used to receive and send information; The processor, coupled to the memory, is configured to invoke computer instructions in the memory to perform the method as described in any one of claims 11-21 via the transceiver.

24. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when invoked by the computer, perform the method as described in any one of claims 1-10, or perform the method as described in any one of claims 11-21.

25. A computer program product, characterized in that, It includes instructions that, when executed on a computer, cause the method as claimed in any one of claims 1-10, or the method as claimed in any one of claims 11-21, to be performed.

26. A chip, characterized in that, The chip includes a processor coupled to a memory for reading and executing program instructions stored in the memory to implement the method as described in any one of claims 1-10, or to implement the method as described in any one of claims 11-21.

Images