A method and apparatus for configuring discontinuous reception

Abstract

The application provides a discontinuous reception configuration method and device, relates to the technical field of communication, and solves the problem that the duration for a terminal device to monitor a physical downlink control channel (PDCCH) is set to be long and the energy-saving efficiency is low. The method comprises the following steps: a terminal device receives a first PDCCH in a first discontinuous reception (DRX) cycle; if a first condition is met, the terminal device stops monitoring the PDCCH at a first time point; wherein the first time point is a time point when an inactivity timer (InactivityTimer) triggered by the first PDCCH expires or a time point after the expiration.

Description

[0001] This application claims priority to Chinese Patent Application No. 202210743794.5, filed with the State Intellectual Property Office of China on June 27, 2022, entitled “A Method for Stopping PDCCH Monitoring, Terminal Equipment, and Network Equipment”, 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 configuration method and apparatus for discontinuous reception. Background Technology

[0003] In wireless communication systems, to save power consumption of terminal devices while ensuring efficient data transmission, a discontinuous reception (DRX) mechanism is introduced to control the terminal device's behavior of listening to the Physical Downlink Control Channel (PDCCH). The network device issues DRX configuration to the terminal device, which includes configuration information for the DRX period and its duration (onDuration). This configuration determines whether the terminal device can continuously listen to the PDCCH to obtain scheduling information during the onDuration period of the DRX period. If the terminal device does not receive any scheduling information during the onDuration period, it enters a sleep state and stops listening to the PDCCH to save power.

[0004] For extended reality (XR) services, such as virtual reality (VR), augmented reality (AR), and cloud gaming (CG), the characteristic of these services is that data packets arrive periodically with short intervals. For example, if an XR service transmits 60 frames per second, then, without considering transmission latency, the average arrival time interval between two adjacent data packets is 16.67 milliseconds (ms). However, considering that in downlink transmission, due to the different routing paths of data packets from the server to the base station, the actual arrival time of data packets may exhibit jitter, such as a jitter latency of 0–8 ms, and different data packets may exhibit different durations of jitter latency; for example, the arrival time interval of data packets may be 16.67 ms to 24.67 ms.

[0005] Currently, to address the data packet delay issue caused by jitter and ensure that data arrival times fall within the onDuration period of the DRX cycle, the onDuration length can be configured to be longer, sufficient to cover the possible arrival time of the data packets. However, increasing the onDuration length of the DRX cycle leads to increased power consumption in the terminal. If the jitter latency is short and the actual arrival time of the data packets is early, the terminal will perform ineffective PDCCH monitoring during the onDuration period after data transmission, resulting in lower energy efficiency for the terminal. Summary of the Invention

[0006] This application provides a configuration method and apparatus for discontinuous reception, which solves the problem that the duration of terminal listening to the Physical Downlink Control Channel (PDCCH) is set too long and the energy-saving efficiency is low in the prior art.

[0007] To achieve the above objectives, this application adopts the following technical solution:

[0008] In a first aspect, a method for configuring discontinuous reception is provided, the method comprising: a terminal device receiving a first PDCCH in a first DRX cycle; if a first condition is met, the terminal device stopping monitoring the physical downlink control channel PDCCH at a first moment; wherein, the first moment is the moment when the inactivity timer InactivityTimer triggered by the first PDCCH times out or the moment after the timeout.

[0009] The above implementation scheme defines a rule for terminal devices to stop monitoring PDCCH, enabling terminal devices and network devices to simultaneously stop monitoring PDCCH according to the rule, thereby shortening the time of invalid PDCCH monitoring within the DRX cycle and saving power consumption.

[0010] In one implementation, the first condition includes: at a second moment, the first timer is not running or has timed out, wherein the second moment is the moment when the terminal device receives the first PDCCH within the first DRX cycle, and the start moment of the first timer is the start or end moment of the duration of the second DRX cycle (onDuration), or the moment when the PDCCH is first received within the second DRX cycle; wherein the second DRX cycle is the preceding DRX cycle adjacent to the first DRX cycle.

[0011] The above possible implementations, by configuring a first timer, use the determination of whether the first timer has timed out as a condition for the terminal device to determine whether the received first PDCCH belongs to the current DRX cycle or the XR data frame of the previous DRX cycle, thereby further determining whether the InactivityTimer triggered by the first PDCCH can stop monitoring the PDCCH in advance, shortening the time of invalid PDCCH monitoring to save the power consumption of the terminal device.

[0012] In one implementation, the first condition includes: the inactivity timer InactivityTimer is not running during a first time period, wherein the end time of the first time period is the start time of the onDuration of the first DRX cycle.

[0013] In the above possible implementations, both the network device and the terminal device can determine whether the PDCCH corresponding to the current InactivityTimer timeout is an XR data frame arriving in the current DRX cycle or the previous DRX cycle based on whether the InactivityTimer is running within the first time period. This allows them to determine whether PDCCH monitoring can be terminated early, thereby saving terminal device power consumption and avoiding data transmission failure caused by prematurely stopping PDCCH monitoring, thus not affecting data transmission efficiency. Furthermore, when a PDCCH is lost on the terminal device side, the terminal device can make the same judgment as the network device side, avoiding data transmission failure.

[0014] In one implementation, the duration of the first time period is the duration of the InactivityTimer.

[0015] In one implementation, the first condition includes: at the start of the onDuration of the first DRX cycle, the InactivityTimer is not running, and the terminal device does not lose downlink control information (DCI) during the second DRX cycle, wherein the second DRX cycle is the preceding DRX cycle adjacent to the first DRX cycle.

[0016] In the above possible implementations, both the network device and the terminal device can determine, based on a first condition, whether packet loss occurred in the previous DRX cycle. This allows them to ascertain whether the PDCCH corresponding to the current InactivityTimer timeout is an XR data frame from the current DRX cycle or the previous DRX cycle. This enables them to determine whether PDCCH monitoring can be terminated early, thereby saving terminal device power consumption and avoiding data transmission failure caused by prematurely stopping PDCCH monitoring, thus maintaining data transmission efficiency. Furthermore, when DCI loss occurs on the terminal device side, the terminal device can make the same judgment as the network device side, preventing data transmission failure.

[0017] In one implementation, the first condition includes: the terminal device receiving first indication information from the network device during the first DRX cycle, the first indication information being used to instruct the terminal device to stop monitoring the PDCCH when or after the InactivityTimer times out, or to instruct the terminal device to stop running the onDuration timer (also known as onDurationTimer) when or after the InactivityTimer times out, or the first data indicated by the first indication information belonging to the same frame of data as the data that has been scheduled in the previous DRX cycle.

[0018] In the above possible implementations, the terminal device can determine whether it can terminate the monitoring of PDCCH in advance when the current InactivityTimer expires based on the indication information from the network device, so as to save the power consumption of the terminal device, avoid the problem of data transmission failure caused by prematurely stopping the monitoring of PDCCH, and not affect the data transmission efficiency.

[0019] In one implementation, if the first indication information is carried in the second PDCCH, then the first data is the data scheduled by the second PDCCH; or, if the first indication information is carried in the first PDSCH, then the first data is the data carried by the first PDSCH.

[0020] In one implementation, the duration of the first timer is pre-configured, or the duration of the first timer is configured by the network device.

[0021] In one implementation, the duration of the first timer is related to the PDB of the data packets transmitted by the application server to the terminal device, or it is related to the difference between the PDB of the data packets transmitted by the application server to the terminal device and the PDB of the data packets transmitted by the application server to the access network device. Alternatively, the duration of the first timer is related to the PDB of the data packets transmitted by the access network device to the terminal device.

[0022] In one implementation, the terminal device starts a second timer at the start or end of the onDuration of the first DRX cycle, or at the moment when it first receives the PDCCH within the first DRX cycle; it receives a third PDCCH in the third DRX cycle; if the second timer is not running or has timed out at the third moment, the terminal device stops monitoring the Physical Downlink Control Channel (PDCCH) at the fourth moment; wherein the third DRX cycle is the next DRX cycle adjacent to the first DRX cycle, the third moment is the moment when the third PDCCH is received, the fourth moment is the moment when the InactivityTimer triggered by the third PDCCH times out or the moment after the timeout, the second timer is a timer different from the first timer, and the duration of the second timer is the same as the duration of the first timer.

[0023] In one implementation, if the start time of the first timer is the moment when the PDCCH is first received within the second DRX cycle, then the terminal device starts the first timer after the first timer expires and at the moment when the PDCCH is first received within the onDuration of the first DRX cycle.

[0024] In one implementation, the first condition further includes: the InactivityTimer is not running at the start time of the onDuration of the first DRX cycle on the terminal device.

[0025] In one implementation, if the terminal device loses DCI during the second DRX cycle, it determines the loss based on at least one of the following: the HARQ process number HPN, the New Data Indicator (NDI), and the Redundancy Version (RV) received during the second DRX cycle; or, the Data Allocation Indicator (DAI).

[0026] In one implementation, stopping monitoring of the Physical Downlink Control Channel (PDCCH) includes stopping the operation of the onDuration timer for the first DRX period.

[0027] Secondly, a method for configuring discontinuous reception is provided, the method comprising: a network device sending a first PDCCH to a terminal device in a first DRX cycle; if a first condition is met, stopping monitoring of the physical downlink control channel PDCCH at a first moment; wherein, the first moment is the time when the inactivity timer InactivityTimer triggered by the first PDCCH expires or the moment after the timeout.

[0028] In one implementation, the first condition includes: at a second moment, the first timer is not running or has timed out, wherein the second moment is the moment when the terminal device receives the first PDCCH within the first DRX cycle, and the start moment of the first timer is the start or end moment of the duration of the second DRX cycle (onDuration), or the moment when the PDCCH is first received within the second DRX cycle; wherein the second DRX cycle is the preceding DRX cycle adjacent to the first DRX cycle.

[0029] In one implementation, the first condition includes: the inactivity timer InactivityTimer is not running during a first time period, wherein the end time of the first time period is the start time of the onDuration of the first DRX cycle.

[0030] In one implementation, the duration of the first time period is the duration of the InactivityTimer.

[0031] In one implementation, the first condition includes: at the start of the onDuration of the first DRX cycle, the InactivityTimer is not running, and the terminal device does not lose downlink control information (DCI) during the second DRX cycle, wherein the second DRX cycle is the preceding DRX cycle adjacent to the first DRX cycle.

[0032] In one implementation, the first condition includes: the network device sending first indication information to the terminal device during the first DRX cycle, the first indication information being used to indicate that monitoring of PDCCH will stop when or after the InactivityTimer times out, or to indicate that the onDuration timer will stop running when or after the InactivityTimer times out, or the first data indicated by the first indication information belongs to the same frame of data as the data that has been scheduled in the previous DRX cycle.

[0033] In one implementation, if the first indication information is carried in the second PDCCH, then the first data is the data scheduled by the second PDCCH; or, if the first indication information is carried in the first PDSCH, then the first data is the data carried by the first PDSCH.

[0034] In one implementation, the duration of the first timer is pre-configured, or the duration of the first timer is configured by the network device.

[0035] In one implementation, a second timer is started at the start or end of the onDuration of the first DRX period, or at the moment when the terminal device first receives the PDCCH within the first DRX period; a third PDCCH is sent to the terminal device in the third DRX period; if the second timer is not running or has timed out at the third moment, monitoring of the Physical Downlink Control Channel (PDCCH) is stopped at the fourth moment; wherein, the third DRX period is the next DRX period adjacent to the first DRX period, the third moment is the moment when the terminal device receives the third PDCCH, the fourth moment is the moment when the InactivityTimer triggered by the third PDCCH times out or the moment after the timeout, the second timer is a timer different from the first timer, and the duration of the second timer is the same as the duration of the first timer.

[0036] In one implementation, if the start time of the first timer is the moment when the PDCCH is first received within the second DRX cycle, then the first timer is started after the first timer expires and at the moment when the PDCCH is first received within the onDuration of the first DRX cycle.

[0037] In one implementation, the first condition further includes: the InactivityTimer is not running at the start time of the onDuration of the first DRX cycle on the terminal device.

[0038] In one implementation, if the terminal device loses DCI during the second DRX cycle, it is determined based on at least one of the following: the HARQ process number HPN, the new data indicator NDI, and the redundancy version RV during the second DRX cycle; or, the data allocation indicator DAI.

[0039] In one implementation, stopping monitoring of the Physical Downlink Control Channel (PDCCH) includes stopping the operation of the onDuration timer for the first DRX period.

[0040] Thirdly, a communication device is provided, the communication device including a transceiver module and a processing module, the transceiver module being used to receive a first PDCCH in a first DRX period; if a first condition is met, the processing module is used to stop monitoring the physical downlink control channel PDCCH at a first moment; wherein, the first moment is the moment when the inactivity timer InactivityTimer triggered by the first PDCCH times out or the moment after the timeout.

[0041] In one implementation, the first condition includes: at a second moment, the first timer is not running or has timed out, wherein the second moment is the moment when the communication device receives the first PDCCH within the first DRX cycle, and the start moment of the first timer is the start or end moment of the duration of the second DRX cycle, or the moment when the PDCCH is first received within the second DRX cycle; wherein the second DRX cycle is the preceding DRX cycle adjacent to the first DRX cycle.

[0042] In one implementation, the first condition includes: the inactivity timer InactivityTimer is not running during a first time period, wherein the end time of the first time period is the start time of the onDuration of the first DRX cycle.

[0043] In one implementation, the duration of the first time period is the duration of the InactivityTimer.

[0044] In one implementation, the first condition includes: at the start of the onDuration of the first DRX cycle, the InactivityTimer is not running, and the communication device does not lose downlink control information (DCI) during the second DRX cycle, wherein the second DRX cycle is the preceding DRX cycle adjacent to the first DRX cycle.

[0045] In one implementation, the first condition includes: the communication device receiving first indication information from the network device during the first DRX cycle, the first indication information being used to instruct the communication device to stop monitoring the PDCCH when or after the InactivityTimer times out, or to instruct the communication device to stop running the onDuration timer when or after the InactivityTimer times out, or the first data indicated by the first indication information belonging to the same frame of data as the data scheduled in the previous DRX cycle.

[0046] In one implementation, if the first indication information is carried in the second PDCCH, then the first data is the data scheduled by the second PDCCH; or, if the first indication information is carried in the first PDSCH, then the first data is the data carried by the first PDSCH.

[0047] In one implementation, the duration of the first timer is pre-configured, or the duration of the first timer is configured by the network device.

[0048] In one embodiment, the processing module is further configured to start a second timer at the start or end of the onDuration of the first DRX period, or at the moment when the PDCCH is first received within the first DRX period; the transceiver module is further configured to receive a third PDCCH in the third DRX period; if the second timer is not running or has timed out at the third moment, the processing module is further configured to stop monitoring the physical downlink control channel PDCCH at the fourth moment; wherein, the third DRX period is the next DRX period adjacent to the first DRX period, the third moment is the moment when the third PDCCH is received, the fourth moment is the moment when the InactivityTimer triggered by the third PDCCH times out or the moment after the timeout, the second timer is a timer different from the first timer, and the duration of the second timer is the same as the duration of the first timer.

[0049] In one implementation, if the start time of the first timer is the moment when the PDCCH is first received within the second DRX cycle, the processing module is further configured to start the first timer after the first timer expires and at the moment when the PDCCH is first received within the onDuration of the first DRX cycle.

[0050] In one implementation, the first condition further includes: the InactivityTimer is not running at the start of the onDuration of the first DRX cycle.

[0051] In one implementation, the processing module is further configured to determine, based on at least one of the following information, that a DCI was lost during the second DRX cycle: the HARQ process number HPN, the New Data Indicator (NDI), and the Redundancy Version (RV) received during the second DRX cycle; or, the Data Allocation Indicator (DAI).

[0052] In one implementation, stopping monitoring of the Physical Downlink Control Channel (PDCCH) includes stopping the operation of the onDuration timer for the first DRX period.

[0053] Fourthly, a communication device is provided, comprising a transceiver module and a processing module. The transceiver module is configured to send a first PDCCH to a terminal device during a first DRX cycle. If a first condition is met, the processing module is configured to stop monitoring the physical downlink control channel (PDCCH) at a first moment. The first moment is the time when the inactivity timer (InactivityTimer) triggered by the first PDCCH times out or the time after the timeout.

[0054] In one implementation, the first condition includes: at a second moment, the first timer is not running or has timed out, wherein the second moment is the moment when the terminal device receives the first PDCCH within the first DRX cycle, and the start moment of the first timer is the start or end moment of the duration of the second DRX cycle (onDuration), or the moment when the PDCCH is first received within the second DRX cycle; wherein the second DRX cycle is the preceding DRX cycle adjacent to the first DRX cycle.

[0055] In one implementation, the first condition includes: the inactivity timer InactivityTimer is not running during a first time period, wherein the end time of the first time period is the start time of the onDuration of the first DRX cycle.

[0056] In one implementation, the duration of the first time period is the duration of the InactivityTimer.

[0057] In one implementation, the first condition includes: at the start of the onDuration of the first DRX cycle, the InactivityTimer is not running, and the terminal device does not lose downlink control information (DCI) during the second DRX cycle, wherein the second DRX cycle is the preceding DRX cycle adjacent to the first DRX cycle.

[0058] In one implementation, the first condition includes: the communication device sending a first indication message to the terminal device during the first DRX cycle, the first indication message being used to indicate that monitoring of PDCCH will stop when or after the InactivityTimer times out, or to indicate that the operation of the onDuration timer will stop when or after the InactivityTimer times out, or the first data indicated by the first indication message belongs to the same frame of data as the data that has been scheduled in the previous DRX cycle.

[0059] In one implementation, if the first indication information is carried in the second PDCCH, then the first data is the data scheduled by the second PDCCH; or, if the first indication information is carried in the first PDSCH, then the first data is the data carried by the first PDSCH.

[0060] In one implementation, the duration of the first timer is pre-configured, or the duration of the first timer is configured by the communication device.

[0061] In one implementation, the processing module is further configured to start a second timer at the start or end of the onDuration of the first DRX period, or at the moment when the terminal device first receives the PDCCH within the first DRX period; the transceiver module is further configured to send a third PDCCH to the terminal device in the third DRX period; if the second timer is not running or has timed out at the third moment, the processing module is further configured to stop monitoring the physical downlink control channel PDCCH at the fourth moment; wherein, the third DRX period is the next DRX period adjacent to the first DRX period, the third moment is the moment when the terminal device receives the third PDCCH, the fourth moment is the moment when the InactivityTimer triggered by the third PDCCH times out or the moment after the timeout, the second timer is a timer different from the first timer, and the duration of the second timer is the same as the duration of the first timer.

[0062] In one implementation, if the start time of the first timer is the moment when the PDCCH is first received within the second DRX cycle, then the first timer is started after the first timer expires and at the moment when the PDCCH is first received within the onDuration of the first DRX cycle.

[0063] In one implementation, the first condition further includes: the InactivityTimer is not running at the start time of the onDuration of the first DRX cycle on the terminal device.

[0064] In one implementation, the processing module is further configured to determine that the terminal device lost DCI during the second DRX cycle based on at least one of the following information: HARQ process number HPN, New Data Indicator (NDI), and Redundancy Version (RV) during the second DRX cycle; or, Data Allocation Indicator (DAI).

[0065] In one implementation, stopping monitoring of the Physical Downlink Control Channel (PDCCH) includes stopping the operation of the onDuration timer for the first DRX period.

[0066] Fifthly, a terminal device is provided, comprising: one or more processors and one or more memories; the one or more memories are coupled to the one or more processors, the one or more memories being used to store computer program code, the computer program code including computer instructions, which, when executed by the one or more processors, cause the terminal device to perform the method as described in any one of the first aspects above.

[0067] A sixth aspect provides a network device comprising: one or more processors and one or more memories; the one or more memories being coupled to the one or more processors, the one or more memories being used to store computer program code, the computer program code including computer instructions, which, when executed by the one or more processors, cause the network device to perform the method as described in any one of the second aspects above.

[0068] In a seventh aspect, a computer-readable storage medium is provided, the computer-readable storage medium storing computer-executable instructions, which, when invoked by the computer, are used to cause the computer to perform the method described in any one of the first aspects.

[0069] Eighthly, a computer-readable storage medium is provided, the computer-readable storage medium storing computer-executable instructions, which, when invoked by the computer, are used to cause the computer to perform the method described in any one of the second aspects above.

[0070] A ninth aspect provides a computer program product comprising instructions that, when run on a computer, causes the computer to perform the method described in any one of the first aspects above.

[0071] In a tenth aspect, a computer program product comprising instructions is provided, which, when run on a computer, causes the computer to perform the method described in any one of the second aspects above.

[0072] Eleventhly, a chip is provided, the chip being coupled to a memory for reading and executing program instructions stored in the memory to implement the method as described in any one of the first aspects above.

[0073] In a twelfth aspect, a chip is provided, the chip being coupled to a memory for reading and executing program instructions stored in the memory to implement the method as described in any one of the second aspects above.

[0074] In a thirteenth aspect, a communication system is provided, the communication system comprising a communication device as described in any one of the third aspects above and a communication device as described in any one of the fourth aspects above.

[0075] Understandably, any of the communication devices, computer-readable storage media, computer program products, chips, or communication systems provided above can be used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here. Attached Figure Description

[0076] Figure 1 An architecture diagram of a communication system provided in an embodiment of this application;

[0077] Figure 2 An architectural diagram of a communication device provided in an embodiment of this application;

[0078] Figure 3 This is a schematic diagram of a discontinuous reception DRX configuration provided in an embodiment of this application;

[0079] Figure 4 A schematic diagram illustrating a discontinuous reception DRX configuration and data transmission provided in an embodiment of this application;

[0080] Figure 5 A flowchart illustrating a configuration method for discontinuous reception provided in an embodiment of this application;

[0081] Figure 6 and Figure 7 This is a schematic diagram of data transmission considering transmission jitter provided in an embodiment of this application;

[0082] Figure 8 This application provides a schematic diagram of a downlink data transmission PDB.

[0083] Figures 9-13 The diagram illustrates several configurations for discontinuous reception provided in the embodiments of this application.

[0084] Figure 14 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application. Detailed Implementation

[0085] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this embodiment, unless otherwise stated, "a plurality of" means two or more.

[0086] It should be noted that, in this application, the terms "exemplary" or "for example" are used to indicate that something is being described as an example, illustration, or illustration. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

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

[0088] First, a brief introduction will be given to the implementation environment and application scenarios of the embodiments of this application.

[0089] This application can be applied to existing new radio (NR) systems, as well as to any other wireless communication system with similar structure and function. Figure 1 As shown, the communication system includes at least a terminal device 101 and a network device 102.

[0090] The terminal device 101 involved in this application embodiment can be user equipment (UE), wherein the UE includes a handheld device, vehicle-mounted device, wearable device, or computing device with wireless communication function. For example, the UE can be a mobile phone, tablet computer, or computer with wireless transceiver function. The terminal device can also be a virtual reality (VR) terminal device, an augmented reality (AR) terminal device, a wireless terminal in industrial control, a wireless terminal in autonomous driving, a wireless terminal in telemedicine, a wireless terminal in a smart grid, a wireless terminal in a smart city, a wireless terminal in a smart home, etc.

[0091] In this application embodiment, the device for implementing the terminal's functions can be a terminal itself; it can also be a device capable of supporting the terminal in implementing those functions, such as a chip system, which can be installed in the terminal. In this application embodiment, the chip system can be composed of chips, or it can include chips and other discrete devices. In the technical solutions provided in this application embodiment, the device for implementing the terminal device functions is a UE (User Equipment) as an example to describe the technical solutions provided in this application embodiment.

[0092] The network device 102 involved in the embodiments of this application may include a base station (BS), which may be a device deployed in a wireless access network that can communicate wirelessly with terminals.

[0093] Base stations can take various forms, such as macro base stations, micro base stations, relay stations, and access points. For example, the base station involved in this application embodiment can be a 5G base station or an LTE base station. In 5G, a base station can also be called a transmission reception point (TRP) or gNB.

[0094] In this embodiment of the application, the device for implementing the function of the network device can be the network device itself; or it can be a device that enables the network device to implement the function, such as a chip system, which can be installed in the network device.

[0095] In the technical solutions provided in the embodiments of this application, the means for implementing the functions of a network device is a network device, and the network device is a base station as an example, the technical solutions provided in the embodiments of this application are described.

[0096] The technical solutions provided in this application can be applied to wireless communication between network devices and terminal devices. In this application, the term "wireless communication" can also be abbreviated as "communication," and the term "communication" can also be described as "data transmission," "information transmission," or "transmission."

[0097] It should be noted that, Figure 1 This is just an example framework diagram. Figure 1 The number of network element nodes included is unlimited. Except... Figure 1 In addition to the functional nodes shown, other nodes may also be included, such as core network devices, gateway devices, application servers, etc., without restriction. Access network devices communicate with core network devices through wired or wireless networks, such as through Next Generation (NG) interfaces.

[0098] In practical implementation, Figure 1 The network elements shown, such as terminal equipment and network equipment, can be adopted. Figure 2 The shown composition or includes Figure 2 The components shown. Figure 2 This is a schematic diagram of the structure of a communication device 200 provided in an embodiment of this application. When the communication device 200 has the functions of the terminal device described in the embodiment of this application, the communication device 200 can be a terminal device or a chip or system-on-a-chip in the terminal device. When the communication device 200 has the functions of the network device described in the embodiment of this application, the communication device 200 can be a network device or a chip or system-on-a-chip in the network device.

[0099] like Figure 2As shown, the communication device 200 may include a processor 201, a communication line 202, and a communication interface 203. Furthermore, the communication device 200 may also include a memory 204. The processor 201, memory 204, and communication interface 203 can be connected via the communication line 202.

[0100] The processor 201 can be a central processing unit (CPU), a general-purpose processor, a network processor (NP), a digital signal processor (DSP), a microprocessor, a microcontroller, a programmable logic device, or any combination thereof. The processor 201 can also be other devices with processing capabilities, such as circuits, devices, or software modules.

[0101] Communication line 202 is used to transmit information between the components included in communication device 200.

[0102] Communication interface 203 is used to communicate with other devices or other communication networks. These other communication networks can be Ethernet, Radio Access Network (RAN), Wireless Local Area Networks (WLAN), etc. Communication interface 203 can be an interface circuit, pins, RF module, transceiver, or any device capable of enabling communication.

[0103] Memory 204 is used to store instructions. These instructions can be computer programs.

[0104] The memory 204 can be a read-only memory (ROM) or other type of static storage device that can store static information and / or instructions; it can also be a random access memory (RAM) or other type of dynamic storage device that can store information and / or instructions; it can also be an electrically erasable programmable read-only memory (EEPROM), a compact optical disc (CD-ROM) or other optical disc storage, optical disk storage, magnetic disk storage medium or other magnetic storage device; optical disk storage includes compressed optical discs, laser discs, optical discs, digital universal optical discs, or Blu-ray discs, etc.

[0105] It should be noted that the memory 204 can exist independently of the processor 201, or it can be integrated with the processor 201. The memory 204 can be used to store instructions, program code, or some data, etc. The memory 204 can be located inside or outside the communication device 200, without limitation. The processor 201 is used to execute the instructions stored in the memory 204 to implement the methods provided in the following embodiments of this application.

[0106] In one example, processor 201 may include one or more CPUs, for example Figure 2 CPU0 and CPU1 in the CPU.

[0107] As an optional implementation, the communication device 200 includes multiple processors, for example, besides Figure 2 In addition to processor 201, it may also include processor 207.

[0108] As an optional implementation, the communication device 200 also includes an output device 205 and an input device 206. For example, the input device 206 is a device such as a keyboard, mouse, microphone, or joystick, and the output device 205 is a device such as a display screen or speaker.

[0109] It should be noted that the communication device 200 can be a wearable device, desktop computer, laptop computer, network server, mobile phone, tablet computer, wireless terminal, embedded device, chip system, or other device. Figure 2 Equipment with a similar structure. Furthermore... Figure 2 The structural composition shown does not constitute a limitation on the communication device, except... Figure 2 In addition to the components shown, the communication device may include more or fewer components than illustrated, or combine certain components, or have different component arrangements.

[0110] In this embodiment of the application, the chip system may be composed of chips or may include chips and other discrete devices.

[0111] In combination with the above Figure 1In the connected state, the terminal device can, based on the DRX configuration information configured by the network device, enter the onDuration period to continuously listen to the PDCCH, or enter a sleep period to stop listening to the PDCCH to save power. The DRX includes the DRX long cycle and the start offset (drx-LongCycleStartOffset). This parameter configures the length of the long DRX cycle and the offset value at the start position of a DRX cycle (whether long or short). The length of the long DRX cycle is in milliseconds (ms), and the configuration granularity of the start offset is 1 ms. The DRX configuration information may also include the configuration information of the onDurationTimer, which determines the period during which the terminal device continuously listens to the PDCCH from the start position of the DRX cycle, i.e., the number of consecutive subframes of PDCCH that need to be listened to starting from the start subframe indicated by drx-StartOffset. The DRX configuration information may also include the configuration information of the inactivityTimer. In addition, the DRX parameters also include the DRX slot offset value (drx-SlotOffset), which is used to configure the delay value before starting drx-onDurationTimer. Its configuration granularity is 1 / 32ms, and the value range is 0 to 31, that is, 0ms to 31 / 32ms. When the network device enables short DRX cycles for terminal devices, the DRX parameters can also include short cycle (shortDRX), which is used to configure the length of the short DRX cycle.

[0112] like Figure 3As shown, the general process of DRX is as follows: After entering a DRX cycle, the terminal device continuously monitors the PDCCH during the on-duration period. If no PDCCH is detected during the on-duration period, the terminal device directly enters a sleep state after the on-duration period ends. If a PDCCH is detected during the on-duration period, and this PDCCH is used to schedule newly transmitted data (i.e., the PDCCH is used to transmit the initial transmission scheduling information), then the terminal device receives data according to the received scheduling information (i.e., receives the PDSCH) and starts a DRX inactive timer. Every time the terminal device detects the initial transmission scheduling information, the DRX inactive timer is started (or restarted) once. During the DRX inactive timer period, the terminal device continuously monitors the PDCCH until the DRX inactive timer expires, at which point the terminal device enters a sleep state. DRX configuration information may also include parameters such as the DRX-hybrid auto repeat request round trip timer (drx-HARQ-RTT-Timer) and the DRX retransmission timer (drx-RetransmissionTimer). The terminal device needs to monitor the PDCCH during the DRX duration timer, the DRX inactivity timer, the downlink (DL) DRX retransmission timer, and the uplink (UL) DRX retransmission timer; these times are collectively referred to as the active time. The remaining time is collectively referred to as the outside active time. Outside the active time, the terminal device does not need to monitor the PDCCH, and can enter sleep mode to save power.

[0113] In scenarios where network devices transmit data packets for XR or similar XR services to terminal devices, such as Figure 4 As shown, taking an average arrival time interval of 16.67ms for data packets corresponding to two adjacent image frames (i.e., two XR data frames) as an example, the ideal arrival time interval for XR data frames on the terminal device side can be 16.67ms. It should be understood that a data frame is defined from the application layer perspective; a data frame can also be replaced by a video frame. A protocol data unit set (PDU set) includes the service data in a single data frame. A PDU set is defined from the MAC layer perspective. A data frame can also be replaced by a PDU set. In the following embodiments, XR data frames are used as examples of service data; however, the following method is applicable to other service scenarios and is not limited thereto.

[0114] In this scenario, the network device can configure the terminal device with a DRX period length that is close to the arrival time interval of the XR data frames, for example, 16ms. Alternatively, other implementation methods can be used to make the DRX period length match or approximately match the arrival time of the XR data frames on the terminal device side. In the following embodiments of this application, it is assumed that the DRX period length matches the period length of the XR data frames.

[0115] Furthermore, considering that during downlink transmission, the actual arrival time of XR data frames may fluctuate due to different routing paths from the server to the base station. For example, the duration of the jitter may be 0–8 ms. Figure 4 As shown, the actual arrival time of XR data frames may be delayed by 0 to 8 ms, meaning the time interval between XR data frame arrivals may fluctuate between 16.67 ms and 24.67 ms. Figure 4 As can be seen, in the presence of jitter, the actual arrival location of an XR data frame may fall outside the onDuration period. In this case, since the terminal device does not receive scheduling within the onDuration period, it stops monitoring the PDCCH after the onDuration period ends. The base station can only delay the XR data frame to the next DRX cycle for scheduling. This situation increases the data transmission latency. It is understandable that the jitter duration range is 0–8ms, which can be equivalently described as a jitter range of -4ms to 4ms. The reference points are different in the two descriptions, but the physical meaning is the same.

[0116] One solution is to configure a longer onDuration period in the DRX cycle to address the issue of delayed XR data frame arrival due to jitter, i.e., to ensure that the data arrival time falls within the onDuration period as much as possible. For example, the length of onDuration can be configured to cover the possible delay range of jitter, making the onDuration length sufficient to cover all possible time periods for XR data frame arrival. However, configuring the DRX duration too long will lead to an excessively long activation time for the terminal device. When the terminal device listens to the initial PDCCH transmission, it will also start an InactivityTimer to extend the activation time. Meanwhile, the transmission time of each XR data frame may be short. Thus, the terminal device will perform ineffective PDCCH monitoring for most of the activation time (i.e., it monitors the PDCCH but does not receive data scheduling), making it difficult to achieve energy-saving effects.

[0117] Based on the above issues, the following will be combined with Figure 1 The communication system shown is described below, illustrating the implementation methods provided in the embodiments of this application. The devices in the following embodiments may have... Figure 2 The components are shown. The actions, terminology, etc., involved in the various embodiments of this application can be referenced mutually, and the embodiments can also be combined with each other without limitation. The message names or parameter names in the messages between the various devices in the embodiments of this application are just examples; other names can be used in specific implementations without limitation.

[0118] This application provides a configuration method for discontinuous reception. By configuring certain rules for the terminal device to stop monitoring the PDCCH, the terminal device can shorten the time of invalid PDCCH monitoring, thereby saving power consumption. Figure 5 As shown, the method may include:

[0119] S501: The network device sends the first PDCCH to the terminal device.

[0120] In this scenario, a single network device may be used for data scheduling across multiple terminal devices. Since the size and scheduling period of XR data frames may differ among these terminal devices, the DRX configurations set by the network device for each terminal device will also differ. Therefore, the network device maintains its corresponding DRX configuration for each terminal device, and maintains and updates various DRX-related timers for that terminal device. For example, based on the DRX configuration of the first terminal, the network device determines the start time of each DRX cycle for that first terminal, the start time of the DRX cycle duration (onDuration), and starts the inactivity timer (InactivityTimer), thus maintaining the same DRX configuration as the first terminal to synchronize data scheduling and improve communication efficiency.

[0121] It should be noted that the embodiments in this application only illustrate the synchronization of DRX configuration between a network device and a terminal device, as well as the interaction between the two, and do not constitute a limitation on the application scenario.

[0122] Specifically, network devices can send a first PDCCH to terminal devices during the first DRX cycle. The first PDCCH is the scheduling data of the terminal device during the first DRX cycle.

[0123] S502: The terminal device receives the first PDCCH in the first DRX cycle.

[0124] Correspondingly, the terminal device receives the first PDCCH from the network device in the first DRX cycle.

[0125] S503: If the first condition is met, stop monitoring PDCCH when or after the inactivity timer InactivityTimer times out.

[0126] Specifically, it can be determined that monitoring of PDCCH will stop at the first moment. The first moment can be the time when the inactivity timer InactivityTimer triggered by the first PDCCH times out, or the time after the InactivityTimer times out.

[0127] In other words, the embodiments of this application can define a rule for the terminal device to stop monitoring the PDCCH, so that the terminal device can stop monitoring the PDCCH according to the rule, thereby shortening the time of invalid PDCCH monitoring and saving power consumption.

[0128] Correspondingly, network devices can also determine when a terminal device should stop monitoring the PDCCH based on the same judgment rules as the terminal device. This allows network devices to align their PDCCH monitoring time periods with those of the terminal device, avoiding packet loss or invalid PDCCH monitoring, and improving communication efficiency and energy efficiency.

[0129] Specifically, the rule for stopping PDCCH monitoring can be: the terminal device determines to stop monitoring PDCCH after the InactivityTimer triggered by the first PDCCH times out, or stops monitoring PDCCH when the InactivityTimer times out.

[0130] Among them, the terminal device can stop monitoring PDCCH before the end of onDuration within the DRX cycle. That is, the terminal device can determine to stop monitoring PDCCH before the end of onDuration according to predefined rules and enter the sleep state in advance.

[0131] For example, such as Figure 6 As shown, the terminal device can receive the first PDCCH within the onDuration of the DRX cycle, and the InactivityTimer is started at the moment the first PDCCH is received. When the terminal device determines that the InactivityTimer has expired, it stops monitoring the PDCCH. That is, the terminal device no longer monitors the PDCCH in the subsequent period of the original onDuration, and enters a sleep state in advance, shortening the duration of continuous PDCCH monitoring.

[0132] In one possible implementation, when the XR data frame of the terminal device is large, an XR data frame can be divided into multiple Protocol Data Units (PDUs) for separate transmission. XR data frames within the same DRX cycle are transmitted as first PDUs, second PDUs, and third PDUs, etc., with each PDU corresponding to a PDCCH for scheduling data. For example, the terminal device receives the first PDCCH, second PDCCH, and third PDCCH within a DRX cycle. Each PDCCH includes downlink control information (DCI) for scheduling one PDU. Furthermore, each PDCCH scheduling newly transmitted data triggers the start or restart of the inactivity timer (InactivityTimer), extending the PDCCH monitoring time. When the XR data frame of the terminal device is large or the number of users in the cell is large, the data transmission duration is long, and the Inactivity Timer may continue running into the next DRX cycle. Figure 7 As shown, the runtime of the InactivityTimer in the second DRX cycle overlaps with the onDuration of the next adjacent DRX cycle (the first DRX cycle).

[0133] If the terminal device stops monitoring the PDCCH after the InactivityTimer times out, such as Figure 7 As shown, if the terminal device prematurely stops monitoring the PDCCH during the onDuration period of the first DRX cycle, it will be unable to monitor the XR data frame scheduling information PDCCH corresponding to the first DRX cycle. Figure 7 In the diagram, the PDCCH corresponding to the first DRX refers to the PDCCH corresponding to the XR data frame arriving in the first DRX period, and the PDCCH corresponding to the second DRX refers to the PDCCH corresponding to the XR data frame arriving in the second DRX period. Figure 7 In the second DRX cycle, the XR data frame arriving is divided into 5 transmissions, therefore Figure 7 There are 5 PDCCHs corresponding to the second DRX. In other words, because the terminal device cannot know whether the XR data frame received in a DRX cycle is part of the XR data frame corresponding to the current cycle or the XR data frame corresponding to the previous cycle, it stops monitoring the PDCCH for energy saving, which leads to data reception failure or increased transmission delay.

[0134] To address the aforementioned issues, the technical solution proposed in this application combines the high latency requirements of XR services with the XR data frame dropping function of network devices to optimize the rules for terminal devices to stop monitoring PDCCH. This allows both network devices and terminal devices to determine, based on certain judgment conditions, whether the PDCCH that has timed out in the current InactivityTimer is an XR data frame from the current DRX cycle or an XR data frame from the previous DRX cycle. This determines whether PDCCH monitoring can be terminated early, thereby saving terminal device power consumption without affecting data transmission efficiency.

[0135] XR services, in particular, have high latency requirements. For example, in real-time video scenarios, if the transmission latency of XR data frames exceeds a preset standard, it may cause problems such as stuttering and unsmooth display in real-time video, affecting the user experience. Latency requirements can be specifically reflected in the packet delay budget (PDB). For example... Figure 8 As shown, the transmission of downlink data packets from the application server to the terminal device requires several processes: Internet transmission (the application server sends data packets to the core network device), core network transmission (the core network device sends data packets to the access network device), and access network transmission (the access network device sends data packets to the terminal device). Therefore, PDB can be divided into end-to-end PDB and air interface PDB.

[0136] In this context, the end-to-end PDB of a downlink data packet refers to the maximum allowable time between the moment the application server sends the data packet and the moment the terminal device receives it, in order to meet service requirements. For example, if the end-to-end PDB of a certain service is 100ms, and the downlink data packet can be transmitted from the application server to the terminal device within 100ms, then the transmission requirements of the service can be considered met; if the time required for the downlink data packet to be transmitted from the application server to the terminal device exceeds 100ms, then the transmission requirements of the service can be considered not met.

[0137] In addition, the air interface PDB of a downlink data packet refers to the maximum allowable time for a data packet to complete transmission from the access network device to the terminal device. For example, if the air interface PDB of a certain service is 10ms, and the downlink data packet can complete the transmission from the base station to the terminal device within 10ms, then the transmission requirements of the service can be considered met.

[0138] Therefore, based on the PDB corresponding to a specific service, if the transmission time of an XR data frame exceeds the corresponding PDB requirement, it can be assumed that even if the XR data frame is transmitted, it will not be of much use to the receiving end. Thus, network devices can enable packet dropping, meaning that based on the PDB requirement of the XR service, the network device will not schedule the transmission of data packets exceeding the PDB.

[0139] For example, if the transmission time of an XR data frame exceeds the corresponding PDB, it means that when the XR data frame is sent to the terminal device, the image display time of the XR data frame has already passed. In this case, there is no need to transmit the XR data frame, and the network device can discard such XR data frames and no longer send them to the terminal device.

[0140] Based on the above technology, in one embodiment, the first condition in step S503 may specifically include: at a second moment, the first timer is not running or has timed out, wherein the second moment may be the moment when the terminal device receives the first PDCCH within the first DRX cycle.

[0141] In other words, by configuring the first timer, the timing of the first timer is used as a criterion for the terminal device to determine whether the received first PDCCH belongs to the current DRX cycle or the XR data frame of the previous DRX cycle.

[0142] In one implementation, such as Figure 9 As shown, the start time of the first timer can be the start time of the duration onDuration of the second DRX cycle, that is, the first timer is started at the start time of onDuration of the second DRX cycle. The second DRX cycle is the preceding DRX cycle adjacent to the first DRX cycle.

[0143] like Figure 9 As shown, in case 1, if the terminal device receives the first PDCCH at the second moment within the first DRX cycle, and the first timer is running at the second moment, then it is considered that the first PDCCH may be the scheduling information of the XR data frame that arrived in the previous DRX cycle of the first DRX cycle, that is, the scheduling information of the XR data frame that arrived in the second DRX cycle. Therefore, when the InactivityTimer triggered by the first PDCCH times out, the monitoring of PDCCH will not be stopped.

[0144] Conversely, in case 2, if the first timer is not running or has expired at the second moment of receiving the first PDCCH, then the first PDCCH is considered to be the scheduling information of the first DRX cycle. When the InactivityTimer triggered by the first PDCCH expires, PDCCH monitoring can be stopped and PDCCH monitoring can be terminated in advance to save power consumption.

[0145] In one implementation, stopping PDCCH monitoring may specifically include: stopping the execution of the onDuration timer for the DRX cycle. Figure 9 The example in the text is to stop the onDuration timer from running during the first DRX cycle.

[0146] In the above implementation, the duration of the first timer can be pre-configured, or it can be configured by the network device.

[0147] The duration of the first timer can be related to the end-to-end PDB, that is, to the PDB of XR data frames transmitted from the application server to the terminal device. Alternatively, if the average transmission time of XR data frames from the application server to the access network device is considered a constant, the duration of the first timer can also be the difference between the following two items: based on the end-to-end PDB, and the average transmission time from the application server to the access network device. For example, ... Figure 8 As shown, the end-to-end PDB is T1, and the average transmission time between the server and the access network device is T2. Therefore, the duration of the first timer can be set to the difference between T1 and T2.

[0148] Furthermore, in the above implementation, even if PDCCH (or DCI) packet loss or reception failure occurs during the second DRX cycle, the XR data frame of the first DRX cycle will not be lost due to the cessation of PDCCH monitoring.

[0149] like Figure 9As shown in Case 3, if the terminal device does not receive PDCCH-1 as shown in the figure, the operating states of InactivityTimer on the terminal device and network device sides are inconsistent. In this case, the network device considers that InactivityTimer has not timed out, while the terminal device considers that InactivityTimer has timed out once. However, according to the above-described embodiment of this application, if the terminal device determines that the first timer is running when it receives the first PDCCH, then when the InactivityTimer triggered by the first PDCCH times out, both the terminal device and the network device determine that they will not trigger a stop monitoring of PDCCH; that is, they will continue to monitor PDCCH after InactivityTimer times out but before OnDurationTimer times out. Conversely, if the terminal device determines that the first timer is not running when it receives the first PDCCH, then when the InactivityTimer triggered by the first PDCCH times out, both the terminal device and the network device will determine that they can trigger a stop monitoring of PDCCH at this time. Therefore, this technical solution has stronger robustness.

[0150] In another implementation, the start time of the first timer can also be the end time of the second DRX cycle onDuration. That is, the first timer can be started at the end time of onDuration.

[0151] If the terminal device receives the first PDCCH at the second moment within the first DRX cycle, and the first timer is running at the second moment, then the first PDCCH is considered to be scheduling information for an XR data frame arriving in the previous DRX cycle, i.e., scheduling information for the second DRX cycle. In this case, when the InactivityTimer triggered by the first PDCCH times out, PDCCH monitoring will not be stopped. If, at the second moment of receiving the first PDCCH, the first timer is not running or has already timed out, then the first PDCCH is considered to be scheduling information for an XR data frame arriving within the first DRX cycle. In this case, when the InactivityTimer triggered by the first PDCCH times out, PDCCH monitoring can be stopped, prematurely terminating PDCCH monitoring.

[0152] In this implementation, the duration of the first timer can be related to the end-to-end PDB, that is, to the PDB of the XR data frames transmitted from the application server to the terminal device. Specifically, if the sum of the average transmission duration between the application server and the access network device and the onDuration duration in the DRX cycle is considered a constant, then the duration of the first timer can also be related to the difference between the transmission PDB between the application server and the terminal device and the aforementioned constant. For example, combined with... Figure 8As shown, the end-to-end PDB is T1, the average transmission time from the server to the access network device is T2, and the onDuration duration of the DRX cycle is T3. Therefore, the duration of the first timer can be set to the difference between T1-T2-T3.

[0153] Furthermore, it should be noted that, in the above implementation, the first timer is started at the start or end of the onDuration of a DRX cycle. Therefore, the first timer corresponding to that DRX cycle may overlap with the next adjacent DRX cycle. For example, the first timer of the second DRX cycle may overlap with the onDuration of the first DRX cycle, and the start or end of the onDuration of the first DRX cycle requires the start of another first timer (or a different timer). Therefore, at the same time, more than one first timer satisfying the aforementioned functions may be running.

[0154] In one embodiment, the method further includes the following steps.

[0155] Step 1: Start the second timer at the beginning or end of the onDuration of the first DRX cycle.

[0156] Step 2: The terminal device receives the third PDCCH at the third moment of the third DRX cycle.

[0157] Step 3: If the second timer is not running or has expired at the third time, then monitoring of the Physical Downlink Control Channel (PDCCH) will stop at the fourth time. The fourth time is either the time when the InactivityTimer triggered by the third PDCCH times out or the time after the timeout.

[0158] The third DRX cycle is the next DRX cycle adjacent to the first DRX cycle. The second timer and the first timer are timers with the same function and the same duration.

[0159] For example, such as Figure 10 As shown, taking the start time of the first timer as the start time of the DRX cycle onDuration as an example, the first timer is started at the beginning of the second DRX cycle. While the first timer is still running, another timer, the second timer, needs to be started at the beginning of the first DRX cycle. The first and second timers run simultaneously. The terminal device or network device can determine that the second timer is not running at the third moment of receiving the third PDCCH. Therefore, at the fourth moment when the InactivityTimer times out, monitoring of the PDCCH can be stopped to save power consumption on the terminal device side.

[0160] In another implementation, the start time of the first timer included in the first condition described above can also be the moment when the terminal device first receives the PDCCH within a DRX cycle. That is, the first timer is started at the moment when the PDCCH is first received within a certain DRX cycle.

[0161] At this point, the duration of the first timer can be related to the PDB of the XR data frame transmitted from the access network device to the terminal device. For example, combined with Figure 8 As shown, the air interface PDB between the access network device and the terminal device is T4, and the duration of the first timer can be set to T4.

[0162] In conjunction with specific embodiments, such as Figure 11 As shown, when the terminal device first receives the PDCCH in the second DRX cycle, the first timer is started. If the terminal device receives PDCCH-1 in the first DRX cycle, and the moment of receiving PDCCH-1 falls within the running time of the first timer, then the InactivityTime timeout triggered by PDCCH-1 will not trigger the premature termination of onDuration in the first DRX cycle. That is, the PDCCH is still monitored after the InactivityTimer times out but before the OnDurationTimer times out.

[0163] For example, such as Figure 11 As shown, if the terminal device starts the first timer when it first receives PDCCH in the first DRX cycle, and if the terminal device receives PDCCH-2 in the third DRX cycle, and the time of receiving PDCCH-2 is after the timer expires, then the InactivityTimer triggered by PDCCH-2 will trigger the onDuration of the third DRX cycle to terminate early, that is, to end PDCCH monitoring early in order to save the power consumption of the terminal device.

[0164] Furthermore, if the start time of the first timer is the moment when the PDCCH is first received within the DRX cycle, then as follows: Figure 11 As shown, when the terminal device receives the PDCCH for the first time in the second DRX cycle, it starts the first timer corresponding to the second DRX cycle. After the first timer expires, and when the PDCCH is received for the first time in the onDuration of the first DRX cycle, the first timer is started (or restarted).

[0165] Similarly, after the first timer corresponding to the first DRX cycle times out, and at the moment when the PDCCH is first received within the onDuration of the third DRX cycle, the first timer can be started (or restarted). The third DRX cycle is the next DRX cycle adjacent to the first DRX cycle.

[0166] The above-described implementations, by defining a first timer, allow both network devices and terminal devices to determine whether the PDCCH corresponding to the current InactivityTimer timeout is an XR data frame from the current DRX cycle or an XR data frame from the previous DRX cycle, based on whether the first timer is running or has timed out. This determines whether PDCCH monitoring can be terminated early, thereby saving terminal device power consumption and avoiding data transmission failures caused by prematurely stopping PDCCH monitoring, thus not affecting data transmission efficiency. Furthermore, when DCI loss occurs on the terminal device side, the terminal device can make the same judgment as the network device side, improving the overall robustness of the solution.

[0167] In another implementation, the first condition in step S503 may specifically include: the inactivity timer InactivityTimer is not running during the first time period. The end time of the first time period is the start time of the onDuration of the first DRX cycle. The duration of the first time period can be predefined or configured for the network device.

[0168] In other words, the terminal device or network device can determine that if the InactivityTimer is not running within a certain time period counting back from the start time of the onDuration of the first DRX cycle, it means that the scheduling information carried by the first PDCCH is most likely the scheduling information of the XR data frame arriving in the first DRX cycle, rather than the scheduling information of the XR data frame arriving in the previous DRX cycle. Therefore, when the InactivityTimer triggered by the first PDCCH times out or after the timeout (i.e., the XR data frame arriving in the first DRX cycle has completed transmission), the monitoring of the PDCCH can be stopped. Otherwise, if the InactivityTimer is running within the first time period, the scheduling information carried by the first PDCCH may be the scheduling information of the XR data frame arriving in the second DRX cycle, rather than the scheduling information of the XR data frame arriving in the first DRX cycle. In this case, the monitoring of the PDCCH is not stopped in advance, but the monitoring of the PDCCH continues to be performed to receive the scheduling information of the XR data frame arriving in the subsequent first DRX cycle.

[0169] The above solution takes into account that there may be XR data frames that are transmitted late among the XR data frames that arrive in the previous DRX cycle. Therefore, if it is determined that the XR data frames that arrive in the previous DRX cycle are still being transmitted close to the next DRX cycle, that is, they may still be being transmitted within the preset duration before the start time of the onDuration of the next DRX cycle (i.e., the duration of the first time period mentioned above), then it is determined that the monitoring of PDCCH will not be stopped prematurely in the next DRX cycle.

[0170] The duration of the first time period can be predefined. For example, the specific value of the first time period duration can be predefined, or the duration of the first time period can be predefined to be equal to the value of certain configuration parameters (such as the length of InactivityTimer). Alternatively, the duration of the first time period can be configured by the network device, for example, it can be carried by the network device when sending DRX configuration information to the terminal device. This application does not limit the specific configuration method.

[0171] In one implementation, the duration of the first time period can be the duration of the InactivityTimer.

[0172] In other words, if the InactivityTimer is not running within the duration of the InactivityTimer before the start of the onDuration of the first DRX cycle, the monitoring of PDCCH can be stopped when or after the InactivityTimer triggered by the first PDCCH times out; if the InactivityTimer is running, the monitoring of PDCCH will not be stopped in advance, that is, the monitoring of PDCCH will continue after the InactivityTimer triggered by the first PDCCH times out but before the OnDurationTimer times out.

[0173] Furthermore, in one implementation, the first condition may specifically include: at the start of the onDuration of the first DRX cycle, the InactivityTimer is not running.

[0174] In other words, the terminal device or network device can determine that: if the InactivityTimer is not running at the start of the onDuration of the first DRX cycle, it can stop monitoring the PDCCH when or after the InactivityTimer times out (triggered by the first PDCCH received within the first DRX cycle). Conversely, if the InactivityTimer is running at the start of the onDuration of the first DRX cycle, it can continue monitoring the PDCCH when or after the InactivityTimer times out (triggered by the first PDCCH received within the first DRX cycle), meaning that PDCCH monitoring continues even after the InactivityTimer times out but before the OnDurationTimer times out.

[0175] However, judging to stop monitoring PDCCH solely based on the first condition mentioned above may lead to misalignment between the terminal device and the network device if data loss occurs on the terminal device side.

[0176] For example, if the network device sends PDCCH-1 normally, but the terminal device does not receive PDCCH-1, the running states of the InactivityTimer on the terminal device and the network device will be misaligned. Figure 12 As shown in the diagram. When the terminal device receives PDCCH-2 in the first DRX cycle, the InactivityTimer triggered by PDCCH-2 overlaps with the onDuration of the first DRX cycle.

[0177] like Figure 12 In method 1, if the network device determines that it will not stop monitoring the PDCCH by judging that the InactivityTimer is running at the start time of the first DRX cycle, while the terminal device determines that it will stop monitoring the PDCCH by judging that the InactivityTimer is not running at the start time of the first DRX cycle, the terminal device and the network device will not be aligned, which may cause the XR data frame arriving in the first DRX cycle to fail to be transmitted.

[0178] To address the aforementioned issues, the two first conditions can be combined. Specifically, the terminal device or network device can determine that the InactivityTimer is not running at the start time of the first DRX cycle's onDuration; and, if the InactivityTimer is not running within the InactivityTimer period prior to the start time of the first DRX cycle's onDuration, then PDCCH monitoring can be stopped when or after the InactivityTimer triggered by the first PDCCH times out. Otherwise, PDCCH monitoring is not stopped; PDCCH monitoring continues even after the InactivityTimer times out but before the OnDurationTimer times out.

[0179] like Figure 13 In Method 2, the InactivityTimer timeout time is T1, and the onDuration start time of the first DRX cycle is T2. If T2-T1≤InactivityTimer duration, then the monitoring of PDCCH will not stop or the onDuration timer will not be stopped in advance, either at the InactivityTimer timeout time or after the timeout in the first DRX cycle.

[0180] Conversely, if the InactivityTimer of the first DRX cycle stops early enough, even if the terminal device loses the PDCCH, the InactivityTimer triggered by the lost PDCCH will not coincide with the onDuration of the first DRX cycle. Therefore, the start time of the onDuration of the first DRX cycle can be determined. If the InactivityTimer is running, or if the InactivityTimer is running at any time within the InactivityTimer duration before the start time of the onDuration of the first DRX cycle, then the terminal device will not prematurely stop monitoring the PDCCH in the first DRX cycle.

[0181] As can be seen, through the above implementation method, both the network device and the terminal device can determine, based on the first condition, whether the PDCCH corresponding to the current InactivityTimer timeout is an XR data frame arriving within the current DRX cycle or an XR data frame arriving within the previous DRX cycle. This allows them to determine whether PDCCH monitoring can be terminated early, thereby saving terminal device power consumption and avoiding data transmission failure caused by prematurely stopping PDCCH monitoring, thus not affecting data transmission efficiency. Furthermore, when PDCCH loss occurs on the terminal device side, the terminal device can make the same judgment as the network device side, avoiding data transmission failure.

[0182] In another implementation, it is also possible to determine whether the terminal device lost packets in the previous DRX cycle, and use this as a criterion to determine whether the monitoring of PDCCH can be stopped in the current DRX cycle after the InactivityTimer times out.

[0183] Therefore, the first condition in step S503 above can specifically include: at the start of the onDuration of the first DRX cycle, the InactivityTimer is not running, and the terminal device does not lose downlink control information (DCI) during the second DRX cycle. The second DRX cycle is the preceding DRX cycle adjacent to the first DRX cycle.

[0184] In other words, if it is determined that the terminal device did not lose DCI during the second DRX cycle, and the InactivityTimer was not running at the start of onDuration in the first DRX cycle, then PDCCH monitoring can be stopped when or after the InactivityTimer times out (triggered by the first PDCCH received during the first DRX cycle). Conversely, if it is determined that the terminal device lost DCI during the second DRX cycle, and the InactivityTimer was not running at the start of onDuration in the first DRX cycle, then PDCCH monitoring cannot be stopped prematurely when or after the InactivityTimer times out (triggered by the first PDCCH received during the first DRX cycle); that is, PDCCH monitoring continues after the InactivityTimer times out but before the OnDurationTimer times out.

[0185] In one implementation, the terminal device can determine whether a DCI was lost in a DRX cycle based on the hybrid automatic repeat request (HARQ) process number (HPN), new data indicator (NDI), and redundant version (RV) received within that DRX cycle. Alternatively, the terminal device can also determine whether a DCI was lost in a DRX cycle based on the data assignment indication (DAI).

[0186] HPN indicates the process number of the HARQ process. NDI indicates whether the data is a new transmission or a retransmission. Specifically, whether the NDI parameter is toggled can be used to determine whether the current data is a new transmission or a retransmission. NDI toggling means that the NDI value changes from 0 to 1, or from 1 to 0. For example, if the NDI parameter in the DCI allocated by the base station for a certain uplink HARQ process is toggled compared to the previous value, it means that the terminal device can perform an uplink new transmission this time; if the NDI parameter is the same as the previous value, then the terminal device can perform an uplink adaptive retransmission this time.

[0187] The RV is designed to implement incremental redundancy (IR) HARQ transmission. This involves dividing the redundant bits generated by the encoder into several groups, with each RV defining a transmission start point. Different RVs are used for the initial transmission and subsequent HARQ retransmissions to gradually accumulate redundant bits and complete the incremental redundancy HARQ operation. Normally, the initial data transmission uses RV = 0, and retransmissions use RV > 0.

[0188] For example, determining whether a DCI is lost based on the HPN, NDI, and RV fields carried in the DCI specifically includes: if the NDI corresponding to the same HPN is inverted and RV>0, then it is determined that a DCI is lost within the DRX cycle.

[0189] In addition, in scenarios where HARQ feedback uses a dynamic codebook, when the terminal device sends out HARQ-acknowledge (ACK) information, it can carry HARQ-ACK information corresponding to multiple physical downlink shared channels (PDSCH) in the same information (such as DCI) for feedback. That is, the number of HARQ-ACK information and the order of multiple HARQ-ACKs can be designed through the HARQ-ACK codebook.

[0190] For example, when a terminal device determines that a dynamic HARQ-ACK codebook is being used, the downlink control information (DCI) received by the terminal device includes a data assignment indication (DAI) field. The DAI field indicates the number of scheduled data packets (i.e., PDSCHs). This field can be understood as a counter; before the terminal device feeds back the HARQ-ACK codebook, the DAI count indicates the number of bits in the HARQ-ACK codebook. For instance, if HARQ-ACK information from three time slots needs to be fed back in the same time slot, and the DAI field in the DCI of each time slot indicates 1 / 2 / 3 respectively, when the terminal device feeds back the HARQ-ACK codebook, if the value indicated by the DAI field in the last DCI is equal to 3, then the terminal device can determine that the number of bits in the fed-back HARQ-ACK codebook is 3. In another design, the DAI field can be further divided into counter DAI and total DAI. Counter DAI functions identically to the previously described DAI, indicating which packet (or PDSCH) was being scheduled before a previous feedback. Total DAI indicates the number of packets (or PDSCHs) scheduled before a previous feedback. Typically, before a feedback, the total DAI value in the DCI of each scheduled data is the same. In this case, the size of the HARQ-ACK codebook can be determined based on the value indicated by total DAI. If the value indicated by the DAI field (specifically counter DAI) in the first DCI received by the terminal device is greater than 0, a lost DCI is determined.

[0191] In the above implementation, both the network device and the terminal device can determine, based on a first condition, whether packet loss occurred in the previous DRX cycle. This allows them to ascertain whether the PDCCH corresponding to the current InactivityTimer timeout is an XR data frame from the current DRX cycle or an XR data frame from the previous DRX cycle. This enables them to determine whether PDCCH monitoring can be terminated early, thereby saving terminal device power consumption and avoiding data transmission failure caused by prematurely stopping PDCCH monitoring, thus maintaining data transmission efficiency. Furthermore, when DCI loss occurs on the terminal device side, the terminal device can make the same judgment as the network device side, preventing data transmission failure.

[0192] In another implementation, since the network device knows which DRX period the XR data frame arrived in when it sends an XR data frame to the terminal device, it can send an indication to the terminal device to indicate whether it can stop monitoring the PDCCH or stop running the onDuration timer after the InactivityTimer expires, or to indicate whether the currently scheduled or transmitted XR data frame belongs to the same frame as the data scheduled in the previous DRX period.

[0193] The first condition in step S503 above may specifically include: the network device sending a first indication information to the terminal device within the first DRX cycle, wherein the first indication information may be used to instruct the terminal device to stop monitoring the PDCCH when or after the InactivityTimer times out, or to instruct the terminal device to stop running the onDuration timer when or after the InactivityTimer times out, or the first data indicated by the first indication information belongs to the same frame data as the data that has been scheduled in the previous DRX cycle.

[0194] Correspondingly, the terminal device receives the first indication information from the network device during the first DRX cycle.

[0195] In one implementation, the first indication information can be implemented using a specific bit. For example, if the bit value is 1, it indicates that PDCCH monitoring will stop when or after the InactivityTimer times out, or that the terminal device will stop the onDuration timer from running when or after the InactivityTimer times out, or that the first data indicated by the first indication information belongs to the same frame of data as the data scheduled in the previous DRX cycle. Conversely, if the bit value is 0, it indicates that PDCCH monitoring will not stop when or after the InactivityTimer times out, or that the terminal device will not stop the onDuration timer from running when or after the InactivityTimer times out, or that the first data indicated by the first indication information does not belong to the same frame of data as the data scheduled in the previous DRX cycle.

[0196] In one implementation, the first indication information or the second indication information can be carried in the PDCCH or in the DCI of the PDCCH. For example, if the first indication information is carried in the second PDCCH, then the first data is data scheduled by the second PDCCH. That is, the network device can carry the first indication information in the PDCCH to indicate to the terminal device that the data scheduled by the PDCCH belongs to the same frame as the data scheduled in the previous DRX period.

[0197] In another implementation, the first indication information or the second indication information may be carried in the PDSCH, or in the higher-layer control signaling of the PDSCH, such as the control element (CE) of Medium Access Control (MAC) or Radio Resource Control (RRC) signaling.

[0198] For example, if the first indication information is carried within the first PDSCH, then the first data is the data carried by the first PDSCH. That is, the network device can carry the first indication information in the PDSCH to indicate to the terminal device that the data transmitted by the PDSCH belongs to the same frame of data as the data scheduled in the previous DRX cycle.

[0199] In the above implementation, the terminal device can determine whether to terminate the monitoring of PDCCH in advance when the current InactivityTimer expires based on the indication information from the network device, so as to save the power consumption of the terminal device, avoid the problem of data transmission failure caused by prematurely stopping the monitoring of PDCCH, and not affect the data transmission efficiency.

[0200] It is understood that the same step or a step or message with the same function in the embodiments of this application can be referenced and learned from each other in different embodiments.

[0201] Based on the above embodiments, this application also provides a communication device, which can be a terminal device. This communication device has the functions of the terminal devices in the various possible embodiments described above. These functions can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions.

[0202] This application also provides a communication device, such as... Figure 14 As shown, the communication device 1400 includes a transceiver module 1401 and a processing module 1402.

[0203] The transceiver module 1401 can be used to receive the first PDCCH in the first DRX cycle.

[0204] The processing module 1402 can be used to stop monitoring the physical downlink control channel (PDCCH) at a first moment if a first condition is met. The first moment is the time when the inactivity timer (InactivityTimer) triggered by the first PDCCH times out, or the moment after the timeout.

[0205] In one implementation, the first condition includes: at a second moment, the first timer is not running or has timed out, wherein the second moment is the moment when the communication device 1400 receives the first PDCCH within the first DRX cycle, and the start moment of the first timer is the start or end moment of the duration of the second DRX cycle, or the moment when the PDCCH is first received within the second DRX cycle; wherein the second DRX cycle is the preceding DRX cycle adjacent to the first DRX cycle.

[0206] In one implementation, the first condition includes: the inactivity timer InactivityTimer is not running during a first time period, wherein the end time of the first time period is the start time of the onDuration of the first DRX cycle.

[0207] In one implementation, the duration of the first time period is the duration of the InactivityTimer.

[0208] In one implementation, the first condition includes: at the start of the onDuration of the first DRX cycle, the InactivityTimer is not running, and the communication device 1400 does not lose downlink control information (DCI) during the second DRX cycle, wherein the second DRX cycle is the preceding DRX cycle adjacent to the first DRX cycle.

[0209] In one implementation, the first condition includes: the communication device 1400 receiving first indication information from a network device during the first DRX cycle, the first indication information being used to instruct the communication device 1400 to stop monitoring the PDCCH when or after the InactivityTimer times out, or to instruct the communication device 1400 to stop running the onDuration timer when or after the InactivityTimer times out, or the first data indicated by the first indication information belongs to the same frame of data as the data that has been scheduled in the previous DRX cycle.

[0210] In one implementation, if the first indication information is carried in the second PDCCH, then the first data is the data scheduled by the second PDCCH; or, if the first indication information is carried in the first PDSCH, then the first data is the data carried by the first PDSCH.

[0211] In one implementation, the duration of the first timer is pre-configured, or the duration of the first timer is configured by the network device.

[0212] In one embodiment, the processing module 1402 may also be used to start a second timer at the start or end of the onDuration of the first DRX cycle, or at the moment when the PDCCH is first received within the first DRX cycle.

[0213] Transceiver module 1401 is also used to receive the third PDCCH during the third DRX cycle.

[0214] The processing module 1402 can also be used to stop monitoring the Physical Downlink Control Channel (PDCCH) at the fourth time if the second timer is not running or has expired at the third time. Here, the third DRX period is the next DRX period adjacent to the first DRX period; the third time is the time when the third PDCCH is received; the fourth time is the time when the InactivityTimer triggered by the third PDCCH expires or the time after the expiration; and the second timer is a different timer from the first timer, with the same duration as the first timer.

[0215] In one embodiment, the processing module 1402 can also be used to start the first timer after the first timer expires and at the moment when the first PDCCH is first received within the onDuration of the first DRX cycle, if the start time of the first timer is the moment when the PDCCH is first received within the second DRX cycle.

[0216] In one implementation, the first condition further includes: the InactivityTimer is not running at the start time of the onDuration of the first DRX cycle of the communication device 1400.

[0217] In one implementation, the processing module 1402 can also be used to determine that a DCI was lost during the second DRX cycle based on at least one of the following: the HARQ process number HPN, the new data indicator NDI, and the redundancy version RV received during the second DRX cycle; or, the data allocation indicator DAI.

[0218] In one implementation, stopping monitoring of the Physical Downlink Control Channel (PDCCH) includes stopping the operation of the onDuration timer for the first DRX period.

[0219] Specifically, the communication device 1400 can realize the functions of the terminal device in the above possible embodiments, as detailed in the foregoing method examples, which will not be repeated here.

[0220] In addition, this application also provides a communication device, which can be a network device. This communication device has the functions of a network device implementing the various possible embodiments described above. These functions can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the functions described above.

[0221] In one possible design, such as Figure 14 As shown, the communication device 1400 includes a transceiver module 1401 and a processing module 1402.

[0222] The transceiver module 1401 is used to send the first PDCCH to the terminal device in the first DRX cycle.

[0223] The processing module 1402 is configured to stop monitoring the Physical Downlink Control Channel (PDCCH) at a first moment if a first condition is met. The first moment is the time when the inactivity timer triggered by the first PDCCH times out, or the moment after the timeout.

[0224] In one implementation, the first condition includes: at a second moment, the first timer is not running or has timed out, wherein the second moment is the moment when the terminal device receives the first PDCCH within the first DRX cycle, and the start moment of the first timer is the start or end moment of the duration of the second DRX cycle (onDuration), or the moment when the PDCCH is first received within the second DRX cycle; wherein the second DRX cycle is the preceding DRX cycle adjacent to the first DRX cycle.

[0225] In one implementation, the first condition includes: the inactivity timer InactivityTimer is not running during a first time period, wherein the end time of the first time period is the start time of the onDuration of the first DRX cycle.

[0226] In one implementation, the duration of the first time period is the duration of the InactivityTimer.

[0227] In one implementation, the first condition includes: at the start of the onDuration of the first DRX cycle, the InactivityTimer is not running, and the terminal device does not lose downlink control information (DCI) during the second DRX cycle, wherein the second DRX cycle is the preceding DRX cycle adjacent to the first DRX cycle.

[0228] In one implementation, the first condition includes: the communication device 1400 sends a first indication message to the terminal device during the first DRX cycle, the first indication message being used to indicate that monitoring of PDCCH will stop when or after the InactivityTimer times out, or to indicate that the operation of the onDuration timer will stop when or after the InactivityTimer times out, or the first data indicated by the first indication message belongs to the same frame of data as the data that has been scheduled in the previous DRX cycle.

[0229] In one implementation, if the first indication information is carried in the second PDCCH, then the first data is the data scheduled by the second PDCCH; or, if the first indication information is carried in the first PDSCH, then the first data is the data carried by the first PDSCH.

[0230] In one implementation, the duration of the first timer is pre-configured, or the duration of the first timer is configured by the communication device 1400.

[0231] In one embodiment, the processing module 1402 is further configured to start a second timer at the start or end of the onDuration of the first DRX cycle, or at the moment when the PDCCH is first received within the first DRX cycle of the terminal device.

[0232] The transceiver module 1401 is also used to send a third PDCCH to the terminal device during the third DRX cycle.

[0233] The processing module 1402 is further configured to, if the second timer is not running or has expired at the third time, stop monitoring the Physical Downlink Control Channel (PDCCH) at the fourth time. Wherein, the third DRX period is the next DRX period adjacent to the first DRX period, the third time is the time when the terminal device receives the third PDCCH, the fourth time is the time when the InactivityTimer triggered by the third PDCCH expires or the time after the expiration, and the second timer is a different timer from the first timer, with the same duration as the first timer.

[0234] In one implementation, if the start time of the first timer is the moment when the PDCCH is first received within the second DRX cycle, then the first timer is started after the first timer expires and at the moment when the PDCCH is first received within the onDuration of the first DRX cycle.

[0235] In one implementation, the first condition further includes: the InactivityTimer is not running at the start time of the onDuration of the first DRX cycle on the terminal device.

[0236] In one embodiment, the processing module 1402 is further configured to determine that the terminal device lost DCI during the second DRX cycle based on at least one of the following information: HARQ process number HPN, New Data Indicator (NDI), and Redundancy Version (RV) during the second DRX cycle; or, Data Allocation Indicator (DAI).

[0237] In one implementation, stopping monitoring of the Physical Downlink Control Channel (PDCCH) includes stopping the operation of the onDuration timer for the first DRX period.

[0238] Specifically, the communication device 1400 can implement the functions of the network device in the various possible implementations described above. For details, please refer to the detailed descriptions in the aforementioned method examples, which will not be repeated here.

[0239] Understandable, combined Figure 2 As shown, when the device is an electronic device, the transmission module can be a transceiver, which may include an antenna and radio frequency circuits, etc., and the processing module can be a processor, such as a baseband chip. When the device is a component having the functions of the first communication device and / or the second communication device in the above embodiments, the transmission module can be a radio frequency unit, and the processing module can be a processor. When the device is a chip system, the transmission module can be the input interface and / or output interface of the chip system, and the processing module can be the processor of the chip system, such as a central processing unit (CPU).

[0240] It should be noted that the specific execution process and embodiments in the above-mentioned device can refer to the steps and related descriptions executed by the terminal device or network device in the above-mentioned method embodiments. The technical problems solved and the technical effects brought about can also refer to the content described in the foregoing embodiments, and will not be repeated here.

[0241] In this embodiment, the device is presented in an integrated manner, divided into various functional modules. Here, "module" can refer to specific circuitry, a processor and memory executing one or more software or firmware programs, integrated logic circuitry, and / or other devices that can provide the aforementioned functions. In a simplified embodiment, those skilled in the art will recognize that the transmission device for this side link can employ the aforementioned... Figure 2 As shown in the figure.

[0242] For example, Figure 14 The function / implementation process of the processing module 1402 can be achieved through... Figure 2 The processor 201 in the memory calls computer program instructions stored in memory 204 to implement the program. For example, Figure 14 The function / implementation process of the transceiver module 1401 can be obtained through Figure 2 The communication interface 203 in the middle.

[0243] In some implementations... Figure 2 The processor 201 can call computer execution instructions stored in the memory 204, so that the device 200 can perform the operations of the terminal device or network device in the above-described method embodiments, and implement the above-described possible implementation methods of this application.

[0244] The communication devices in the above-described device embodiments can completely correspond to the terminal devices or network devices in the method embodiments, with corresponding modules or units performing the corresponding steps. For example, when the device is implemented as a chip, the transceiver unit can be an interface circuit for the chip to receive signals from other chips or devices. The transceiver module used for sending or receiving is an interface circuit of the device, used to send signals to other devices. For example, when the device is implemented as a chip, the transceiver module can be an interface circuit for sending signals to other chips or devices.

[0245] In an exemplary embodiment, a computer-readable storage medium or a computer program product including instructions is also provided, which can be executed by the processor 201 of the communication device 200 to perform the methods of the above embodiments. Therefore, the technical effects obtained can be referred to the above method embodiments, and will not be repeated here.

[0246] This application also provides a computer program product including instructions that, when executed, enable the computer to perform operations corresponding to the terminal device or network device described above.

[0247] This application also provides a system-on-a-chip (SoC) comprising a processing unit and a communication unit. The processing unit may be, for example, a processor, and the communication unit may be, for example, an input / output interface, pins, or circuitry. The processing unit can execute computer instructions to cause the communication device to which the chip is applied to perform the operations of the terminal device and network device in the methods provided in the embodiments of this application.

[0248] Optionally, any of the communication devices provided in the above embodiments of this application may include the system chip.

[0249] Optionally, the computer instructions are stored in a storage unit.

[0250] This application also provides a communication system, which may include any of the terminal devices and network devices described in the above embodiments.

[0251] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software programs, it can be implemented, in whole or in part, as a computer program product. This computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions according to the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices.

[0252] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0253] Finally, it should be noted that the above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A configuration method for discontinuous reception, characterized in that, The method includes: The terminal device receives the first PDCCH in the first DRX cycle; If the first condition is met, the terminal device stops monitoring the physical downlink control channel (PDCCH) at the first moment. Wherein, the first moment is the moment when the inactivity timer InactivityTimer triggered by the first PDCCH times out or the moment after the timeout; The first condition includes: At the second moment, the first timer is not running or has timed out, wherein the second moment is the moment when the terminal device receives the first PDCCH within the first DRX cycle, the start moment of the first timer is the start or end moment of the duration of the second DRX cycle (onDuration), and the duration of the first timer is related to the data packet delay budget (PDB) for the application server to transmit Extended Reality (XR) data frames to the terminal device; or, the start moment of the first timer is the moment when the PDCCH is first received within the second DRX cycle, and the duration of the first timer is related to the data packet delay budget (PDB) for the access network device to transmit Extended Reality (XR) data frames to the terminal device; wherein the second DRX cycle is the preceding DRX cycle adjacent to the first DRX cycle; or... The InactivityTimer is not running during the first time period, wherein the end time of the first time period is the start time of the onDuration of the first DRX cycle; or, At the start of the onDuration of the first DRX cycle, the InactivityTimer is not running, and the terminal device does not lose downlink control information (DCI) during the second DRX cycle, wherein the second DRX cycle is the preceding DRX cycle adjacent to the first DRX cycle; or, The terminal device receives a first indication information from the network device during the first DRX cycle. The first indication information indicates that the first data scheduled by the first PDCCH does not belong to the same frame data as the data scheduled in the previous DRX cycle.

2. The method according to claim 1, characterized in that, The duration of the first time period is the duration of the InactivityTimer.

3. The method according to claim 1, characterized in that, If the first indication information is carried within the second PDCCH, then the first data is the data scheduled by the second PDCCH; or, If the first indication information is carried in the first physical downlink shared channel (PDSCH), then the first data is the data carried by the first PDSCH.

4. The method according to claim 1, characterized in that, The duration of the first timer is pre-configured, or the duration of the first timer is configured by the network device.

5. The method according to claim 1 or 4, characterized in that, The terminal device starts the second timer at the start or end of the onDuration of the first DRX cycle, or at the moment when it first receives the PDCCH within the first DRX cycle. Receive the third PDCCH in the third DRX cycle; If the second timer is not running or has expired at the third time, the terminal device will stop monitoring the physical downlink control channel (PDCCH) at the fourth time. Wherein, the third DRX cycle is the next DRX cycle adjacent to the first DRX cycle, the third time is the time when the third PDCCH is received, the fourth time is the time when the InactivityTimer triggered by the third PDCCH times out or the time after the timeout, the second timer is a timer different from the first timer, and the duration of the second timer is the same as the duration of the first timer.

6. The method according to claim 1 or 4, characterized in that, If the start time of the first timer is the moment when the PDCCH is first received within the second DRX cycle, then the terminal device starts the first timer after the first timer expires and at the moment when the PDCCH is first received within the onDuration of the first DRX cycle.

7. The method according to claim 1 or 2, characterized in that, The first condition further includes: at the start of the onDuration of the first DRX cycle, the InactivityTimer is not running on the terminal device.

8. The method according to claim 1, characterized in that, The terminal device loses DCI during the second DRX cycle, determined based on at least one of the following information: The HARQ process number HPN, New Data Indicator (NDI), and Redundancy Version (RV) received during the second DRX cycle; Alternatively, the data allocation instruction is DAI.

9. The method according to any one of claims 1-4 and 8, characterized in that, The step of stopping monitoring the Physical Downlink Control Channel (PDCCH) includes stopping the execution of the onDuration timer for the first DRX cycle.

10. A method for configuring discontinuous reception, characterized in that, The method includes: The network device sends the first PDCCH to the terminal device in the first DRX cycle; If the first condition is met, then monitoring of the Physical Downlink Control Channel (PDCCH) will stop at the first moment. Wherein, the first moment is the moment when the inactivity timer InactivityTimer triggered by the first PDCCH times out or the moment after the timeout; The first condition includes: At the second moment, the first timer is not running or has timed out, wherein the second moment is the moment when the terminal device receives the first PDCCH within the first DRX cycle, the start moment of the first timer is the start or end moment of the duration of the second DRX cycle (onDuration), and the duration of the first timer is related to the data packet delay budget (PDB) for the application server to transmit Extended Reality (XR) data frames to the terminal device; or, the start moment of the first timer is the moment when the PDCCH is first received within the second DRX cycle, and the duration of the first timer is related to the data packet delay budget (PDB) for the access network device to transmit Extended Reality (XR) data frames to the terminal device; wherein the second DRX cycle is the preceding DRX cycle adjacent to the first DRX cycle; or... The InactivityTimer is not running during the first time period, wherein the end time of the first time period is the start time of the onDuration of the first DRX cycle; or, At the start of the onDuration of the first DRX cycle, the InactivityTimer is not running, and the terminal device does not lose downlink control information (DCI) during the second DRX cycle, wherein the second DRX cycle is the preceding DRX cycle adjacent to the first DRX cycle; or, The network device sends a first indication message to the terminal device during the first DRX cycle. The first indication message indicates that the first data scheduled by the first PDCCH does not belong to the same frame data as the data scheduled in the previous DRX cycle.

11. The method according to claim 10, characterized in that, The duration of the first time period is the duration of the InactivityTimer.

12. The method according to claim 10, characterized in that, If the first indication information is carried within the second PDCCH, then the first data is the data scheduled by the second PDCCH; or, If the first indication information is carried within the first PDSCH, then the first data is the data carried by the first PDSCH.

13. The method according to claim 10, characterized in that, At the start or end of the onDuration of the first DRX cycle, or at the moment when the PDCCH is first received by the terminal device in the first DRX cycle, the second timer is started; In the third DRX cycle, a third PDCCH is sent to the terminal device; If the second timer is not running or has expired at the third time, then monitoring of the physical downlink control channel (PDCCH) will stop at the fourth time. Wherein, the third DRX cycle is the next DRX cycle adjacent to the first DRX cycle, the third time is the time when the terminal device receives the third PDCCH, the fourth time is the time when the InactivityTimer triggered by the third PDCCH times out or the time after the timeout, the second timer is a timer different from the first timer, and the duration of the second timer is the same as the duration of the first timer.

14. The method according to claim 10 or 13, characterized in that, If the start time of the first timer is the moment when the PDCCH is first received within the second DRX cycle, then the first timer is started after the first timer expires and at the moment when the PDCCH is first received within the onDuration of the first DRX cycle.

15. The method according to claim 10 or 11, characterized in that, The first condition further includes: at the start of the onDuration of the first DRX cycle, the InactivityTimer is not running on the terminal device.

16. The method according to claim 10, characterized in that, The terminal device loses DCI during the second DRX cycle, determined based on at least one of the following information: The HARQ process number HPN, New Data Indicator (NDI), and Redundancy Version (RV) within the second DRX cycle; Alternatively, the data allocation instruction is DAI.

17. A terminal device, characterized in that, The terminal device includes a processor and a memory coupled to the processor; the memory stores computer program code, the computer program code including computer instructions, which, when executed by the processor, cause the terminal device to perform the method as described in any one of claims 1-9.

18. A network device, characterized in that, The network device includes a processor and a memory coupled to the processor; the memory is coupled to the processor and stores computer program code, the computer program code including computer instructions, which, when executed by the processor, cause the network device to perform the method as described in any one of claims 10-16.

19. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions that, when invoked by the computer, cause the computer to perform the method as described in any one of claims 1-9, or the method as described in any one of claims 10-16.

20. A computer program product containing instructions, characterized in that, When the instructions are executed on a computer, the computer performs the method as described in any one of claims 1-9, or the method as described in any one of claims 10-16.

21. A chip, characterized in that, The method 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-9, or to implement the method as described in any one of claims 10-16.

22. A communication system, characterized in that, The communication system includes the terminal device as described in claim 17 and the network device as described in claim 18.

Images