Wireless communication method, terminal device, and network device

Abstract

Provided are a wireless communication method, a terminal device, and a network device. The method comprises: a terminal device receives a first low-power wake-up signal (LP-WUS) sent by a network device; and, in response to receiving the first LP-WUS, the terminal device monitors a physical downlink control channel (PDCCH) within a first time period. In the embodiments of the present application, a terminal device monitors a PDCCH within a first time period in response to a received LP-WUS (also referred to as a "first LP-WUS"). Compared with a conventional solution in which connected discontinuous reception (C-DRX) is used to configure intermittent activated PDCCH monitoring, the prevention of unnecessary PDCCH monitoring (e.g., within an inactive time period) is facilitated, thereby reducing power consumption of the terminal device.

Description

Wireless communication methods, terminal equipment and network equipment Technical Field

[0001] This application relates to the field of communication technology, and more specifically, to a wireless communication method, terminal device, and network device. Background Technology

[0002] The communication system incorporates low-power receivers and a low-power wake-up signal (LP-WUS). When idle, the terminal device can turn off the main receiver or put it into deep sleep mode, listening to LP-WUS only through the low-power receiver, thereby reducing terminal power consumption. However, how to embed LP-WUS into traditional communication systems to further reduce terminal device power consumption is an urgent problem to be solved. Summary of the Invention

[0003] This application provides a wireless communication method, terminal device, and network device. The various aspects covered by this application are described below.

[0004] In a first aspect, a wireless communication method is provided, comprising: a terminal device receiving a first low-power wake-up signal LP-WUS sent by a network device; and in response to receiving the first LP-WUS, the terminal device listening to the physical downlink control channel (PDCCH) for a first time period.

[0005] In a second aspect, a wireless communication method is provided, comprising: a network device sending a first low-power wake-up signal LP-WUS to a terminal device; the first LP-WUS being used to trigger the terminal device to listen to the physical downlink control channel PDCCH for a first time period.

[0006] Thirdly, a terminal device is provided, comprising: a receiving unit for receiving a first low-power wake-up signal LP-WUS sent by a network device; and a listening unit for listening to the physical downlink control channel PDCCH in response to receiving the first LP-WUS.

[0007] Fourthly, a network device is provided, comprising: a transmitting unit for transmitting a first low-power wake-up signal LP-WUS to a terminal device; the first LP-WUS is used to trigger the terminal device to listen to the physical downlink control channel PDCCH for a first time period.

[0008] Fifthly, a terminal device is provided, including a processor, a memory, and a communication interface, wherein the memory is used to store one or more computer programs, and the processor is used to invoke the computer programs in the memory, causing the terminal device to perform some or all of the steps in the method of the first aspect.

[0009] In a sixth aspect, a network device is provided, including a processor, a memory, and a transceiver, wherein the memory is used to store one or more computer programs, and the processor is used to invoke the computer programs in the memory to cause the network device to perform some or all of the steps in the method of the second aspect.

[0010] Seventhly, embodiments of this application provide a communication system including the aforementioned terminal device and / or network device. In another possible design, the system may further include other devices that interact with the terminal device or network device as described in the embodiments of this application.

[0011] Eighthly, embodiments of this application provide a computer-readable storage medium storing a computer program that causes a communication device (e.g., a terminal device or a network device) to perform some or all of the steps in the methods described above.

[0012] Ninthly, embodiments of this application provide a computer program product, wherein the computer program product includes a non-transitory computer-readable storage medium storing a computer program operable to cause a communication device (e.g., a terminal device or a network device) to perform some or all of the steps of the methods described in the foregoing aspects. In some implementations, the computer program product may be a software installation package.

[0013] In a tenth aspect, embodiments of this application provide a chip including a memory and a processor, the processor being able to call and run a computer program from the memory to implement some or all of the steps described in the methods of the foregoing aspects.

[0014] In this embodiment, the terminal device listens to the PDCCH during a first time period in response to the received LP-WUS (also known as the "first LP-WUS"). Compared to the traditional scheme that uses connected discontinuous reception (C-DRX) to configure intermittent activation of PDCCH listening, this helps to avoid unnecessary PDCCH listening (e.g., inactive periods), thereby reducing the power consumption of the terminal device. Attached Figure Description

[0015] Figure 1 shows a wireless communication system 100 used in an embodiment of this application.

[0016] Figure 2 is a schematic flowchart of a wireless communication method according to an embodiment of this application.

[0017] Figure 3 shows the architecture of a second receiver applicable to an embodiment of this application.

[0018] Figure 4 shows another architecture of the second receiver applicable to the embodiments of this application.

[0019] Figure 5 shows another architecture of a second receiver applicable to embodiments of this application.

[0020] Figure 6 is an example diagram of the first time offset according to an embodiment of this application.

[0021] Figure 7 is an example diagram of another first time offset according to an embodiment of this application.

[0022] Figure 8 is an example diagram of the terminal device sending the first confirmation message and the second confirmation message.

[0023] Figure 9 is a schematic diagram of a terminal device according to an embodiment of this application.

[0024] Figure 10 is a schematic diagram of a network device according to an embodiment of this application.

[0025] Figure 11 is a schematic structural diagram of a communication device according to an embodiment of this application. Detailed Implementation

[0026] The technical solutions in this application will now be described with reference to the accompanying drawings.

[0027] Figure 1 illustrates a wireless communication system 100 according to an embodiment of this application. The wireless communication system 100 may include a network device 110 and a terminal device 120. The network device 110 may be a device that communicates with the terminal device 120. The network device 110 may provide communication coverage for a specific geographical area and may communicate with the terminal device 120 located within that coverage area.

[0028] Figure 1 illustrates an exemplary network device and two terminals. Optionally, the wireless communication system 100 may include multiple network devices, and each network device may include other terminal devices within its coverage area. This application embodiment does not limit this.

[0029] Optionally, the wireless communication system 100 may also include other network entities such as a network controller and a mobility management entity, which is not limited in this embodiment.

[0030] It should be understood that the technical solutions of the embodiments of this application can be applied to various communication systems, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal frequency division multiple access (OFDMA), single-carrier frequency division multiple access (SC-FDMA), 5th generation (5G) systems or new radio (NR), long term evolution (LTE) systems, LTE frequency division duplex (FDD) systems, LTE time division duplex (TDD) systems, etc. The terms "system" and "network" in the embodiments of this application are often used interchangeably, and the described technologies can be used not only for the systems and radio technologies mentioned above, but also for other systems and radio technologies. The following description describes an NR system for illustrative purposes, and NR terminology is used in most of the following description; however, these technologies can also be applied to applications other than NR system applications, such as future communication systems (e.g., 6th generation (6G)). th Wireless communication systems include terminal equipment and network equipment. (e.g., 6G mobile communication systems, satellite communication systems, etc.)

[0031] The terminal device in this application embodiment can also be referred to as user equipment (UE), access terminal, user unit, user station, mobile station, mobile station (MS), mobile terminal (MT), remote station, remote terminal, mobile device, user terminal, terminal, wireless communication device, user agent, or user device. The terminal device in this application embodiment can be a device that provides voice and / or data connectivity to a user, and can be used to connect people, objects, and machines, such as a handheld device with wireless connectivity, vehicle-mounted device, etc. The terminal devices in the embodiments of this application can be mobile phones, tablets, laptop computers (also known as notebook computers), personal digital assistants (PDAs), handheld computers, netbooks, ultra-mobile personal computers (UMPCs), mobile internet devices (MIDs), wearable devices, virtual reality (VR) devices, augmented reality (AR) devices, robots, vehicle user equipment (VUE), pedestrian user equipment (PUE), smart home devices (home appliances with wireless communication capabilities, such as refrigerators, televisions, washing machines, or furniture), game consoles, personal computers (PCs), ATMs or self-service machines, wireless terminals in industrial control, wireless terminals in self-driving, wireless terminals in remote medical surgery, wireless terminals in smart grids, wireless terminals in transportation safety, and smart city devices. Wireless terminals in cities and smart homes, including wearable devices such as smartwatches, smart bracelets, smart headphones, smart glasses, smart jewelry (smart bracelets, smart necklaces, smart anklets, smart wristbands, etc.), smart wristbands, and smart clothing. Optionally, the UE can act as a base station. For example, the UE can act as a scheduling entity, providing sidelink signals between UEs in V2X or D2D, etc. For instance, cellular phones and cars use sidelink signals to communicate with each other.This allows for communication between cellular phones and smart home devices without the need for base station relay signals. It should be noted that the embodiments in this application do not limit the specific type of terminal device.

[0032] The network device in this application embodiment can be a device for communicating with terminal devices, and may include access network devices or core network devices. The access network device may also be referred to as a radio access network device, radio access network (RAN), radio access network function, or radio access network unit. For example, the access network device may be a base station WLAN access point or WiFi node, etc. In this application embodiment, the access network device may refer to a radio access network node (or device) that connects the terminal device to the wireless network. Base stations can broadly encompass various names listed below, or be replaced by names such as: NodeB, Evolved NodeB (eNB), Next Generation NodeB (gNB), Relay Station, Access Point, Base Transceiver Station (BTS), Radio Base Station, Radio Transceiver, Basic Service Set (BSS), Extended Service Set (ESS), Home B Node, Home Evolved B Node, Transmitting and Receiving Point (TRP), Transmitting Point (TP), Master MeNB, Secondary SeNB, Multi-Standard Radio (MSR) Node, Home Base Station, Network Controller, Access Node, Wireless Node, Access Point (AP), Transmitting Node, Transceiver Node, Base Band Unit (BBU), Remote Radio Unit (RRU), Active Antenna Unit (AAU), Remote Radio Head (RRH), Central Unit (Central) The term "base station" is not limited to specific technical terms, but can refer to a macro base station, micro base station, relay node, donor node, or similar entities or combinations thereof. A base station can also refer to a communication module, modem, or chip installed within the aforementioned equipment or apparatus. A base station can also be a mobile switching center, or an equipment that performs base station functions in device-to-device (D2D), vehicle-to-everything (V2X), and machine-to-machine (M2M) communications, a network-side device in 6G networks, or an equipment that performs base station functions in future communication systems. A base station can support networks with the same or different access technologies.The embodiments of this application do not limit the specific technology or device form used in the network equipment. It should be noted that the embodiments of this application only use a base station in an NR system as an example for description, and do not limit the specific type of base station.

[0033] Base stations can be fixed or mobile. For example, a helicopter or drone can be configured to act as a mobile base station, and one or more cells can move depending on the location of the mobile base station. In other examples, a helicopter or drone can be configured as a device to communicate with another base station.

[0034] In some deployments, the network device in this application embodiment may refer to a CU or a DU, or the network device may include both a CU and a DU. The gNB may also include an AAU.

[0035] Network devices and terminal devices can be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; they can also be deployed on water; and they can also be deployed in the air on airplanes, balloons, and satellites. This application does not limit the scenario in which the network devices and terminal devices are located.

[0036] It should be understood that all or part of the functions of the communication device in this application can also be implemented by software functions running on hardware, or by virtualization functions instantiated on a platform (e.g., a cloud platform).

[0037] In cellular networks, terminal devices (e.g., those in 5G networks) typically consume tens of milliwatts even when not transmitting or receiving any data. This idle power consumption is due to the need for the terminal device to perform periodic measurements and check for potential paging messages. Therefore, without external power support, IoT devices are difficult to implement in practice.

[0038] To address the aforementioned issues, communication systems (e.g., NR) have introduced low-power receivers and LP-WUS. When idle, terminal devices can turn off the main receiver or put it into deep sleep mode, listening to LP-WUS solely through the low-power receiver, thereby reducing terminal power consumption. However, how to embed LP-WUS into traditional communication systems to further reduce terminal device power consumption remains a pressing issue.

[0039] For example, when the main receiver of a terminal device is woken up, the terminal device enters the connected state of radio resource control (RRC), and the low-power receiver of the terminal device can continuously receive LP-WUS. Therefore, the low-power receiver is independent of the main receiver; that is, the main receiver can be turned off when the low-power receiver is active and searching for potential LP-WUS. Considering that the terminal device may be listening for LP-WUS during the reduced-power PDCCH monitoring period, LP-WUS could be applied to C-DRX to further reduce the power consumption of the terminal device, but there are currently no relevant solutions. Furthermore, when multiple terminal devices are simultaneously listening for LP-WUS, false wake-ups may occur.

[0040] To address the aforementioned issues, this application proposes a wireless communication method in which a terminal device listens to the PDCCH during a first time period in response to a received LP-WUS (hereinafter referred to as "first LP-WUS"). Compared to the traditional approach of using C-DRX configuration to intermittently activate PDCCH listening, this method helps avoid unnecessary PDCCH listening (e.g., during inactive periods), thereby reducing the power consumption of the terminal device.

[0041] The wireless communication method of this application embodiment is described below with reference to FIG2. FIG2 is a schematic flowchart of the wireless communication method of this application embodiment. The scheme shown in FIG2 includes steps S210 and S220.

[0042] In step S210, the network device sends a first LP-WUS to the terminal device. Correspondingly, the terminal device receives the first LP-WUS sent by the network device.

[0043] In some implementations, the terminal device includes a first receiver and a second receiver. The power consumption of the first receiver is higher than that of the second receiver. The first LP-WUS is received by the second receiver of the terminal device, or in other words, the first LP-WUS is monitored by the terminal device through the second receiver.

[0044] In some implementations, the power consumption of the first receiver is higher than that of the second receiver. Therefore, the first receiver can be the main receiver (MR) mentioned above, and the second receiver can be the low-power receiver (LR) mentioned above.

[0045] In some implementations, the first receiver can also be referred to as the "main communication module," and the second receiver can also be referred to as a low-power wake-up module or a low-power wake-up receiver (LP-WUR).

[0046] Embedding the first LP-WUS into a traditional communication system requires seamlessly integrating the generation of the first LP-WUS into the signal generation of the traditional communication system. To facilitate the reception of the first LP-WUS, in some implementations, the architecture of the second receiver suitable for receiving the first LP-WUS includes one or more of the following: an architecture with radio frequency (RF) envelope detection; a heterodyne architecture with intermediate frequency (IF) envelope detection; or a zero-difference or zero-IF architecture with baseband envelope detection.

[0047] In some implementations, the second receiver architecture can be an architecture with RF envelope detection. For example, referring to Figure 3, the RF signal is directly converted to a baseband signal via an RF envelope detector, without a local oscillator (LO) and phase-locked loops (PLLs), which can achieve relatively low power consumption. A 1-bit or multi-bit analog-to-digital converter (ADC) can be applied, and optional components such as a low-noise amplifier (LNA) for RF and / or asymmetric multi-processing (AMP) for baseband, high-Q matching networks and / or band-pass filters (BPFs) for RF and / or low-pass filters (LPFs) for baseband can be applied. Supporting multiple frequency bands and / or carriers may require multiple high-Q matching networks and / or RF BPFs or multiple off-chip components, which can be used to suppress adjacent channel interference or interference from signals and / or other LP-WUS from conventional communication systems on adjacent subcarriers, and can support frequency band and / or carrier tuning.

[0048] In some implementations, the second receiver architecture can be a heterodyne architecture with intermediate frequency envelope detection. For example, referring to Figure 4, the RF signal is down-converted to an intermediate frequency (IF) signal by an RF mixer with a LO. The IF signal is then converted to a baseband signal by IF envelope detection. Depending on the design, there may be one or more IF stages, and lower power consumption can be achieved by relaxing the accuracy and stability requirements of the LO. A 1-bit or multi-bit ADC can be applied. A high-Q matching network and / or an RF BPF and / or an IF BPF (and / or a BB LPF) can be used to suppress adjacent channel interference or interference from other signals and / or other LP WUS from conventional communication systems on adjacent subcarriers. Components such as an RF LNA and / or an IF AMP and / or a BB AMP can be optionally applied. Band and / or carrier tuning can be achieved by tuning the LO frequency, and an RF LNA and / or an IF AMP can be applied to improve sensitivity.

[0049] In some implementations, the second receiver architecture can be a zero-difference or zero-IF architecture with baseband envelope detection. For example, referring to Figure 5, band and / or carrier tuning can be achieved by tuning the LO frequency. Using a BB BPF / LPF instead of a high-Q matched network and / or an RF BPF is more effective and simpler for suppressing adjacent channel interference or interference from other signals and / or other LP-WUS from conventional communication systems on adjacent subcarriers. An RF LNA can be used to improve sensitivity, and baseband envelope detection can be performed in the analog domain (before the ADC) or the digital domain (after the ADC).

[0050] It should be noted that the three second receiver architectures described above are applicable to binary on-off keying (OOK) modulation. Of course, some of these architectures can also be applied to other modulation schemes, such as frequency shift keying (FSK).

[0051] In some implementations, in a multi-carrier on-off keying (MC-OOK) system based on orthogonal frequency division multiplexing (OFDM), network devices can use coded bits to perform multi-carrier amplitude shift keying (MC-ASK) waveform generation to generate the first LP-WUS.

[0052] In some implementations, the first LP-WUS can support bandwidths from 5MHz to 20MHz. Therefore, when the first LP-WUS is embedded in a traditional communication system, it can be two receiving modules or integrated into one receiving module. That is, the first receiver and the second receiver are two separate modules or the first receiver and the second receiver are integrated into one module.

[0053] In step 220, in response to receiving the first LP-WUS, the terminal device listens to the PDCCH during the first time period.

[0054] In some implementations, in response to receiving the first LP-WUS, the terminal device listens to the PDCCH for a first time period. This can be understood as the terminal device triggering PDCCH listening for a first time period based on the first LP-WUS, or in other words, the first LP-WUS is used to trigger the terminal device to listen to the PDCCH for a first time period. The first LP-WUS can be used not only to wake up the terminal device in the idle / inactive state, but also to wake up the terminal device in the connected state to listen to the PDCCH. Considering that the performance of the first LP-WUS is much worse than that of a regular PDCCH, and the number of bits will be very limited, it helps to save power for the terminal device.

[0055] In some implementations, the first LP-WUS triggers a PDCCH listener in the connected state. For example, for a connected terminal device, C-DRX can be configured with LP-WUS, meaning that when the terminal device receives the first LP-WUS, it can trigger the PDCCH listener configured by C-DRX within a first time period.

[0056] In some implementations, if the terminal device detects the PDCCH in the first time period, it can continue to monitor the PDCCH scheduled data. That is, the terminal device continues to monitor the data transmitted by the transmission resources indicated by the downlink control information (DCI) carried by the PDDCH.

[0057] In some implementations, the first receiver listens to the PDCCH. For example, when the second receiver of the terminal device receives the first LP-WUS, it wakes up the first receiver, which is in a sleep state, and causes it to enter the PDCCH listening state for a first time period.

[0058] In some implementations, the terminal device listens to the PDCCH within the first time period. This can be understood as the terminal device listening to the PDCCH within the first time period. If the PDCCH is heard, the terminal device continues to listen to the data transmitted on the transmission resource indicated by the DCI carried by the PDCCH.

[0059] In some implementations, the first LP-WUS-triggered terminal device listens to the PDCCH for a first time period, that is, the first time period is the duration of listening to the PDCCH triggered by the first LP-WUS.

[0060] For listening to the PDCCH triggered by the first LP-WUS, the key point is how to configure the listening duration for the PDCCH triggered only by the first LP-WUS. In some implementations, the first time period is determined based on the first timer.

[0061] In some implementations, the first time period is determined based on the first timer, which can be understood as the first time period being determined based on the duration of the first timer. For example, the first time period can be determined based on the start time of the first timer, where the start time of the first time period is the start time of the first timer, and the end time of the first time period is the time within the duration of the first timer or the time after the end time of the first timer.

[0062] In some implementations, the first time period is determined based on a first timer. This can be understood as the first time period being the duration of the first timer; that is, the start time of the first time period is the start time of the first timer, and the end time of the first time period is the end time of the first timer. In this case, the terminal device triggers PDCCH listening within the first time period based on the first LP-WUS. This can be understood as the first LP-WUS triggering the start of the first timer, and the terminal device listening to the PDCCH during the execution of the first timer.

[0063] In some implementations, the first timer includes existing timers and / or newly defined timers.

[0064] In some implementations, the existing timer can be an existing C-DRX configuration's discontinuous reception (DRX) inactive timer (drx-InactivityTimer). For example, the first timer is drx-InactivityTimer, which is triggered when the terminal device receives the first LP-WUS.

[0065] In some implementations, the existing timer can be the existing C-DRX configuration's DRX persistent timer (drx-onDurationTimer). For example, the first timer is drx-onDurationTimer, which is triggered when the terminal device receives the first LP-WUS.

[0066] In some implementations, the newly defined timer can be understood as the first LP-WUS-triggered timer, or a dedicated LP-WUS timer, or a timer newly designed for LP-WUS.

[0067] In some implementations, the duration of LP-WUS's dedicated timer can be less than or equal to drx-onDurationTimer.

[0068] To determine which timer the first LP-WUS should trigger, or to trigger different timers in different scenarios, the terminal device should decide which timer to trigger based on specific conditions in different scenarios. In some implementations, the first timer is determined based on one or more of the following: service type; data transmission mode; data traffic characteristics; quality of service requirements; network load information.

[0069] In some implementations, the service type can be understood as the service type of the data scheduled by the PDCCH. For example, the service type of the data scheduled by the PDCCH can be voice or video, etc.

[0070] In some implementations, the data transmission pattern can be understood as the transmission pattern of data scheduled by the PDCCH. For example, the data transmission pattern of the PDCCH can be periodic or aperiodic, predictable or unpredictable.

[0071] In some implementations, data flow characteristics can be understood as the flow characteristics during the data transmission process scheduled by the PDCCH. For example, the flow rate and whether the flow is continuous during the data transmission process scheduled by the PDCCH.

[0072] In some implementations, the Quality of Service (QoS) requirement can be understood as the QoS metrics of the data scheduled by the PDCCH. Examples include data bandwidth, latency, packet loss rate, and jitter.

[0073] In some implementations, network load information can be understood as the current network load status.

[0074] In some implementations, the first timer is determined based on the data transmission pattern. For example, for periodically transmitted data, the arrival time of the data is predictable, and the first timer can be drx-onDurationTimer, because maintaining a listening state for a short period before each transmission ensures timely data reception while saving power. Alternatively, for non-periodic data transmission, the first timer can be drx-InactivityTimer, ensuring that the terminal device maintains a long listening state after data transmission begins, suitable for applications with uncertain data transmission patterns.

[0075] In some implementations, the first timer is determined based on quality of service requirements. For example, when the application's data is latency-sensitive and has high quality of service requirements (such as video calls and online games), the first timer should be a drx-onDurationTimer to ensure that the terminal device can respond quickly to downlink data and maintain low latency. Alternatively, for scenarios with low quality of service requirements (such as periodic data synchronization and Internet of Things (IoT) applications), the first timer can be a dedicated LP-WUS timer to ensure that the terminal device remains briefly active when needed, and otherwise remains in a low-power state as much as possible.

[0076] In some implementations, the first timer is determined based on network load information. For example, under high network load, the terminal device may need more time to process data transmission, so the first timer could be a drx-InactivityTimer, keeping the terminal device active during transmission and avoiding frequent wake-ups from sleep mode when the load is high. Alternatively, when the network load is low, the first timer could be a drx-onDurationTimer or a dedicated timer from LP-WUS, allowing the terminal device to wake up only when needed, maintaining low-power operation.

[0077] In some implementations, the first timer is determined based on the data transmission mode, data traffic characteristics, and quality of service. For example, when the terminal device detects a high-rate downlink data arrival probability based on the first LP-WUS, or when real-time communication such as Voice over Internet Protocol (VoIP) is latency-sensitive and involves periodic data transmission, the first timer can be drx-onDurationTimer. Starting drx-onDurationTimer ensures that the terminal device remains active for a short period to receive data promptly. This is because drx-onDurationTimer controls the time the terminal device remains in PDCCH listening state within each DRX cycle. When this timer is started, the terminal device continuously listens to the PDCCH to receive potential data transmissions. As another example, if the terminal device is woken up by the first LP-WUS, or if continuous downlink data transmission (such as file downloads or video streaming) is anticipated, the first timer is drx-InactivityTimer. Starting drx-InactivityTimer in this case helps maintain the terminal device's activity to continuously receive data. Because drx-InactivityTimer can be started when the terminal device is active, it is used to enter DRX mode when there is no data transmission. If the data transmission ends and the timer has not expired, the terminal device remains active and continues to listen to the PDCCH; if the timer expires and there is no new data, the terminal device will enter a low-power state.

[0078] In some implementations, the start time of the first timer is determined based on a first time window and a first time offset. The first time window is used to listen to the first LP-WUS.

[0079] In some implementations, the first time offset is used to indicate the time interval between the start time of the first time window and the start time of the first timer. Accordingly, the start time of the first timer can be determined based on the start time of the first time window and the first time offset.

[0080] In some implementations, the first time offset is used to indicate the time interval between the end time of the first time window and the start time of the first timer. For example, referring to Figure 6, the first time offset is minTimeGap, and the start time of the first timer can be determined based on the end time of the first time window and minTimeGap.

[0081] In some implementations, the first time offset is used to indicate the time interval between the reception time of the first LP-WUS and the start time of the first timer within the first time window. For example, referring to Figure 6, the first time offset is WUS-offset, and the start time of the first timer can be determined based on the reception time of the first LP-WUS and the WUS-offset.

[0082] In some implementations, the first time offset is configured by the network device and is determined based on one or more of the following: one or more candidate values ​​of the first time offset reported by the terminal device; one or more candidate values ​​of the first time offset supported by the sub-carrier space (SCS); the location information of the terminal device; the degree of resource scheduling congestion; the data transmission cycle; the wake-up delay of the terminal device; the processing delay of the terminal device; and the first LP-WUS listening cycle.

[0083] In some implementations, one or more candidate values ​​of the first time offset reported by the terminal device can be understood as part or all of the one or more first time offsets supported by the terminal device reported to the network device.

[0084] In some implementations, subcarrier spacing can be understood as the frequency interval between multiple subcarriers. For example, subcarrier spacing can be one or more of the following: 15kHz, 30kHz, 60kHz, 120kHz, and 240kHz.

[0085] In some implementations, one or more candidate values ​​for the first time offset supported by the SCS can be understood as one or more first time offsets supported by a predefined or preconfigured SCS. For example, the protocol specifies that the SCS is 15kHz, supporting three first time offsets.

[0086] In some implementations, one or more candidate values ​​for the first time offset supported by the SCS can be understood as one or more first time offsets supported by the SCS reported by the terminal device. For example, the terminal device determines one or more first time offsets supported by the value of each SCS based on the SCS and the sleep state of the terminal device.

[0087] In some implementations, the location information of the terminal device can be understood as the absolute or relative position of the terminal device, which is used to calculate the data transmission delay.

[0088] In some implementations, resource scheduling congestion can be understood as the degree of congestion of the transmission resources scheduled by network devices for transmitting data.

[0089] In some implementations, the wake-up latency of a terminal device can be understood as the transition time for the first receiver of the terminal device to transition from a sleep state to a PDCCH listening state.

[0090] In some implementations, the processing latency of the terminal device can be understood as the protocol interaction time required for the terminal device to go from detecting the first LP-WUS to triggering the start of the first timer.

[0091] In some implementations, the first LP-WUS listening period can be understood as the period during which the terminal device listens to the first LP-WUS, that is, the period of the first time window.

[0092] In some implementations, if the first time offset is used to indicate the time interval between the start time of the first time window and the start time of the first timer, the first time offset can be determined based on the data transmission period, the wake-up latency of the terminal device, and the listening period of the first LP-WUS. For example, the data scheduled by PDCCH is VoIP, and its transmission period is T. VoIP The wake-up latency of the terminal device is Δt. on The first LP-WUS listening period is T. LP―WUS The first time offset can be determined by the formula Δt1 = T. VoIP ―Δt on ―T LP―WUS Sure.

[0093] In some implementations, if the first time offset is used to indicate the time interval between the start time of the first time window and the start time of the first timer, then the start time of the first time window can be determined based on the start time of the first timer and the first time offset. In this case, the first time offset can be referred to as the first LP-WUS listening advance time; that is, the first LP-WUS listening begins at the first time offset before the start time of the first timer. The first LP-WUS listening advance time ensures that the terminal device has sufficient time to complete the first LP-WUS listening and wake-up before data arrives.

[0094] In some implementations, if the first time offset is used to indicate the time interval between the end time of the first time window and the start time of the first timer, the first time offset can be determined based on one or more candidate values ​​of the first time offset reported by the terminal device, one or more candidate values ​​of the first time offset supported by the SCS, the location information of the terminal device, and the degree of resource scheduling congestion. For example, based on the degree of resource scheduling congestion and the location information of the terminal device, the network device selects a suitable first time offset for the terminal device from multiple candidate values ​​of the first time offset to adapt to different scenarios.

[0095] In some implementations, one or more candidate values ​​for the first time offset are determined based on one or more of the following: the time it takes for the terminal device to process the first LP-WUS; the transition time from the second receiver of the terminal device to the first receiver of the terminal device; the synchronization duration of the first receiver; SCS; the sleep type supported by the terminal device; data transmission latency requirements; and network status information.

[0096] In some implementations, the time it takes for the terminal device to process the first LP-WUS can be understood as the time it takes for the terminal device to receive and decode the first LP-WUS.

[0097] In some implementations, the transition time from the second receiver to the first receiver of the terminal device can be understood as the time it takes for the terminal device to switch from the second receiver in the active state to the first receiver in the sleep state, and then wake up the first receiver in the sleep state. For example, referring to Figure 7, the transition time is the time it takes for the terminal device to switch from the second receiver to the first receiver in the sleep state and wake up the first receiver after the second receiver of the terminal device receives the first LP-WUS.

[0098] In some implementations, the synchronization duration of the first receiver can be understood as the duration during which the first receiver performs time or frequency synchronization. For example, referring to Figure 7, after the second receiver of the terminal device receives the first LP-WUS, it triggers the wake-up of the first receiver after the reception and processing time of the first LP-WUS. After the first receiver wakes up from the sleep state, before listening to the PDCCH, the first receiver needs to perform time or frequency synchronization in order to listen to the PDCCH.

[0099] In some implementations, the data transmission latency requirement can be understood as the transmission latency requirement of the data scheduled by the PDCCH. For example, the data transmission latency requirement can be a packet delay budget (PDB).

[0100] In some implementations, network status information can be understood as indicators that can indicate the network status. For example, network status information can be signal strength, network load, etc.

[0101] In some implementations, the sleep types supported by the terminal device can be understood as the sleep types supported by the first receiver of the terminal device. For example, the sleep types supported by the first receiver of the terminal device include deep sleep and / or shallow sleep.

[0102] In some implementations, the candidate value for the first time offset is determined based on the processing time of the first LP-WUS by the terminal device. For example, different terminal devices may have different processing capabilities for the first LP-WUS. The stronger the processing capability, the faster the terminal device can complete the detection and decoding of the first LP-WUS, thereby shortening the first time offset. Therefore, the terminal device can select an appropriate candidate value based on its own processing capability.

[0103] In some implementations, the candidate value for the first time offset is determined based on network state information. For example, under actual network conditions, factors such as signal strength and network load will also affect the selection of the first time offset. The candidate value for the first time offset can be selected based on the strength level of the signal received by the first receiver, with each strength level corresponding to a candidate value for the first time offset. For another example, under weak signal conditions, the first receiver of the terminal device may require more time to synchronize, therefore the candidate value for the first time offset may be larger.

[0104] In some implementations, the candidate value for the first time offset is determined based on the SCS (Signal Channel Counter). For example, because the SCS determines the signal's bandwidth and time-domain characteristics, a larger SCS (e.g., 60kHz or 120kHz) requires more stringent time synchronization, potentially shortening the response time of the terminal device, thus resulting in a smaller first time offset. Conversely, a smaller SCS (e.g., 15kHz or 30kHz) may require more time for the synchronization process of the first receiver, leading to a larger first time offset. Therefore, the terminal device needs to report suitable candidate values ​​for each SCS.

[0105] In some implementations, a candidate value for the first time offset can be determined based on an SCS.

[0106] In some implementations, multiple candidate values ​​for the first time offset can be determined based on a single SCS. For example, since different factors (such as SCS, sleep state, network conditions, etc.) have different requirements for the first time offset, multiple candidate values ​​for the first time offset can be determined based on each SCS.

[0107] In some implementations, the candidate value for the first time offset is determined based on the SCS (System Change Class) and the sleep types supported by the terminal device. For example, each SCS corresponds to multiple candidate values, each corresponding to a different sleep type of the terminal device, which determines the wake-up time. In deep sleep, the terminal device completely shuts down most of its circuit modules, thus requiring a longer time to restart processing. In light sleep, some modules remain active, allowing for faster wake-up. This means that under different sleep types, the terminal device may choose different first time offsets to balance power consumption and communication efficiency.

[0108] In some implementations, the candidate value for the first time offset is determined based on data transmission latency requirements and the sleep types supported by the terminal device. For example, suppose the terminal device supports two sleep types: micro-sleep with a transition time of 0ms and deep sleep with a transition time of 20ms. Then, when the PDB of the data scheduled by the PDCCH is greater than 20ms, the terminal device can report a candidate value for the first time offset greater than 20ms; or when the PDB of the traffic is less than 20ms, it can report a candidate value for the first time offset less than 20ms. The network device will be able to configure the first time offset for the terminal device more flexibly according to the different types of services being transmitted.

[0109] In some implementations, the candidate value for the first time offset is determined based on the SCS, the sleep type supported by the terminal device, and the time taken for the terminal device to process the first LP-WUS. For example, the candidate value for the first time offset can be determined using the formula Δt1 = Δt sync (SCS)+Δt sleep (Type) + Δt wus (Processing) determines, where Δt sync (SCS) is the time required for time synchronization, determined by SCS. The larger the SCS, the smaller this value; conversely, the smaller the SCS, the larger this value. Δt sleep (Type) is the wake-up time determined by the sleep type supported by the terminal device; the smaller this value is during light sleep, and the larger this value is during deep sleep; Δt wus (Processing) refers to the time it takes for the terminal device to process the first LP-WUS. This value is smaller when the terminal device has strong processing power and larger when its processing power is weak. For example, the SCS can be 15kHz or 60kHz, the sleep type supported by the terminal device can be light sleep or deep sleep, and the processing time for the first LP-WUS can be fast or slow. The candidate value for the first time offset can be determined based on the permutations and combinations of the SCS, the sleep type supported by the terminal device, and the processing time for the first LP-WUS in Table 1.

[0110] Table 1

[0111] In some implementations, one or more candidate values ​​of the first time offset reported by the terminal device can be reported by the terminal device to the network device through a capability report.

[0112] In some implementations, the network device can configure the first time offset to the terminal device via DCI. For example, the network device can use DCI format 2_6 or other DCI formats to configure the first time offset to the terminal device.

[0113] In some implementations, the duration of the first timer is determined based on the data transmission duration.

[0114] In some implementations, data transmission duration can be understood as the total transmission duration of data scheduled by the PDCCH.

[0115] In some implementations, the duration of the first timer is determined based on the data transmission duration. This can be understood as the duration of the first timer being determined based on the data transmission duration and the second time offset.

[0116] In some implementations, the second time offset can be understood as a redundant time used to ensure that the terminal device does not enter sleep mode prematurely. It can usually be set as a compensation time for network propagation delay or data transmission fluctuations.

[0117] In order for the terminal device to receive all the data scheduled by the PDCCH, in some implementations, the duration of the first timer is determined by the formula... Determined, where t data For data transmission duration, This is the second time offset.

[0118] In some implementations, the period of the first timer is determined based on the data transmission period.

[0119] In some implementations, the data transmission cycle can be understood as the transmission cycle of data scheduled by the PDCCH.

[0120] To ensure efficient coordination of the first timer within each DRX cycle, the period of the first timer, which is also the DRX cycle, should match the trigger time of the first LP-WUS. In some implementations, the period of the first timer is longer than the data transmission cycle to ensure that even if the first LP-WUS fails to be detected under certain circumstances, the terminal device still has the opportunity to listen to the PDCCH again in the next DRX cycle.

[0121] In some implementations, the period of the first timer is determined based on the data transmission period. This can be understood as the period of the first timer being determined based on the data transmission period and the third time offset.

[0122] In some implementations, the third time offset can be understood as a small time compensation to prevent the device from missing PDCCH listening due to random fluctuations in the first LP-WUS listen or data transmission. Generally, a value of 1 to 2 milliseconds for the third time offset is recommended.

[0123] In some implementations, the period of the first timer is determined by the formula T. timer 1 =T data +δ is determined, where T data δ represents the data transmission period, and δ represents the third time offset.

[0124] In some implementations, the period of the first timer is an integer multiple of the first LP-WUS listening period.

[0125] In some implementations, the first LP-WUS listening period can be understood as the period during which the terminal device listens to the first LP-WUS, that is, the period of the first time window. Therefore, it can also be said that the period of the first timer is an integer multiple of the period of the first time window.

[0126] In some implementations, the first time window includes multiple first LP-WUS monitoring occasions to improve the flexibility of network device scheduling and LP-WUS transmission. For example, referring to Figure 6, the first time window includes multiple monitoring occasions (MOs), where each MO is a first LP-WUS monitoring occasion. If the terminal device detects the first LP-WUS in multiple MOs, the start time of the first timer is determined based on the first time window and the first time offset.

[0127] In some implementations, the listening timings of multiple first LP-WUS can be discontinuous, which helps to better handle situations where the listening resources of the first LP-WUS are used for other channels / signals or other purposes (such as conflicts with UL time slots). Of course, in the embodiments of this application, the listening timings of multiple first LP-WUS can also be continuous.

[0128] In some implementations, the timing of the first LP-WUS listening can be determined based on one or more of the following: system frame number; subframe number; first LP-WUS listening period; first LP-WUS listening start offset.

[0129] In traditional standard protocols, non-integer C-DRX cycles are defined to match non-integer service cycles (e.g., extended reality (XR) cycles). Considering low power consumption, a fine-grained first LP-WUS listening cycle (e.g., a 1ms value) can be used to match the non-integer C-DRX cycle, and no non-integer first LP-WUS listening cycle is defined. Since the conventional drx-startOffset is defined to determine the PDCCH listening start timing, the first LP-WUS listening start offset (drx-WusStartOffset) can be used to determine the LP-WUS listening timing.

[0130] In some implementations, the first LP-WUS listening timing can be determined by the formula [(SFN×10)+subframe number―(drx-WusStartOffset―timeOffset)]mod(LP-WUS-cycle), where SFN is the system frame number, subframe number is the subframe number, LP-WUS-cycle is the first LP-WUS listening cycle, drx-WusStartOffset is the first LP-WUS listening start offset, and timeOffset is an offset used to adjust the first LP-WUS listening timing. That is to say, system frames and subframes that satisfy the condition [(SFN×10)+subframe number―(drx-WusStartOffset―timeOffset)]mod(LP-WUS-cycle) can be used as the first LP-WUS listening timing.

[0131] In some implementations, the start time of the first time window is determined based on one or more of the following: the start time of data transmission; the first LP-WUS listening cycle.

[0132] In some implementations, the data transmission start time can be understood as the start time of data transmission scheduled by the PDCCH.

[0133] In some implementations, the start time of the first time window is determined based on the start time of data transmission and the first LP-WUS listening period.

[0134] The first timer controls when the terminal device enters the PDCCH listening state. To start this timer before a data frame arrives at the terminal device, the start time of the first time window should be slightly earlier than the data frame transmission period. In some implementations, the start time of the first time window is determined by the formula ttime window 1 = t data ―T wus Determine, where t data T is the start time of data transmission. wus This is the first LP-WUS monitoring cycle. For example, for periodic traffic such as VoIP, which typically has a stable transmission cycle (e.g., transmitting a voice frame every 20ms), the first step is to know the data transmission cycle T. VoIPThis involves determining when data will arrive in each cycle. Typical VoIP transmission cycles range from 20ms to 50ms. For applications like VoIP, data transmission timing is predictable because the transmission rate of voice frames is usually fixed. Therefore, network devices can understand these characteristics and pre-configure the appropriate timing for the first LP-WUS listen, i.e., the start time of the first time window. To properly start the first timer before VoIP data arrives, the terminal device needs to listen for the first LP-WUS at a reasonable advance time. This advance time should be early enough to ensure the device has time to wake up and prepare to receive data, but not too early to avoid wasting power. Assume the VoIP traffic transmission cycle is T. VoIP The transmission starts at time t0. To wake up the device and start the first timer before the data arrives, the start time of this first LP-WUS listening, i.e., the start time of the first time window, should be determined by the formula: ttime window 1 = t0 - T wus Sure.

[0135] To efficiently utilize LP-WUS, network devices and terminal devices need to collaboratively configure DRX and LP-WUS mechanisms. This ensures that the LP-WUS listening cycle is adapted to the data transmission cycle, and that the terminal device is woken up in advance before each data traffic cycle arrives, while maintaining a low-power state when not needed. In some implementations, the first LP-WUS listening cycle should be the same as the data transmission cycle; that is, the period of the first time window should be the same as the data transmission cycle.

[0136] In some implementations, the parameters of the first time window and / or the first timer are determined using a model based on network load and / or traffic information. For example, by analyzing historical data transmission patterns and network load through a model and predicting future traffic and load conditions, parameters such as the period, first time offset, and first timer period of the first timer are dynamically adjusted based on the model's prediction results to achieve more precise energy-saving effects. Another example is that the listening period of the first LP-WUS can be dynamically adjusted. If the model predicts a decrease in traffic or a drop in network load, the listening period of the first LP-WUS can be extended to reduce the wake-up frequency, which can be achieved using formula T. wus =max{T data ―Δt on Δt1} determines the first LP-WUS listening period, where T data Δt is the data transmission period. on Δt1 represents the wake-up delay of the terminal device, and Δt1 represents the first time offset.

[0137] In some implementations, the content to be reported by the terminal device can be determined based on the type of the timer during the first timer's execution.

[0138] In some implementations, if the first timer is drx-onDurationTimer or drx-InactivityTimer, the terminal device can perform periodic channel state information (CSI) / layer-1 reference signal received power (L1-RSRP) reports. For example, if the first LP-WUS triggers drx-onDurationTimer, periodic CSI / L1-RSRP reports should be made while in dynamic PDCCH listening mode.

[0139] Uplink (UL) / downlink (DL) transmissions may require CSI reporting, but L1-RSRP reporting is unnecessary. In some implementations, if the first timer is drx-onDurationTimer, the terminal device can choose not to report L1-RSRP.

[0140] In some implementations, if the first timer is a dedicated timer for LP-WUS, the terminal device can be configured to periodically report CSI / L1-RSRP during the operation of the dedicated timer for LP-WUS.

[0141] To enable terminal devices to adapt to different data traffic types, some implementations allow terminal devices to perform first LP-WUS listening both outside and within the traditional C-DRX activity period. For example, the first timer is drx-onDurationTimer. First LP-WUS listening before drx-onDurationTimer can be used for predictable periodic traffic such as VoIP, while first LP-WUS listening outside the traditional C-DRX activity period is designed specifically for unpredictable or misaligned periodic services such as XR. See Table 2 for details.

[0142] Table 2

[0143] Because LP-WUS listening consumes significantly less power from the terminal device than PDCCH listening, a shorter LP-WUS listening period can reduce service latency. In some implementations, the first LP-WUS listening period is shorter than the period of the first timer. For example, if the period of the first timer is the period of C-DRX, then the first LP-WUS listening period is shorter than the long period and / or the short period of C-DRX.

[0144] In some implementations, the first LP-WUS carries one or more of the following: an identifier of the terminal device; information for instructing the terminal device to trigger PDCCH listening; and information for instructing the terminal device to listen to the PDCCH carrier.

[0145] In some implementations, the terminal device can be identified as a radio network temporary identity (RNTI). For example, a 16-bit RNTI is used to uniquely identify a specific terminal device in connected mode. The first LP-WUS carries the RNTI, which helps the terminal device determine whether the first LP-WUS is used to wake itself up, thus avoiding false wake-ups.

[0146] In some implementations, the first LP-WUS carries information to instruct the terminal device to trigger PDCCH listening. This can be understood as the terminal device receiving the first LP-WUS and triggering PDCCH listening in the first time period based on the information carried by the first LP-WUS to instruct the terminal device to trigger PDCCH listening.

[0147] In some implementations, the first LP-WUS carries information instructing the terminal device to listen to the carrier of the PDCCH. This can be understood as the terminal device receiving the first LP-WUS and determining the carrier it is listening to based on it. When the terminal device is configured with carrier aggregation (CA) in connected mode, supporting LP-WUS only wakes up a portion of the carriers, which helps save power for the terminal device.

[0148] Supporting carrier aggregation (CA) with LP-WUS in connected mode can save power by waking up only a subset of carriers. By flexibly managing the activity states of multiple carriers, LP-WUS can help end devices wake up only a portion of the carriers, thereby reducing unnecessary power consumption. In carrier aggregation scenarios, end devices may use multiple carriers simultaneously (such as a primary carrier and secondary carriers). Typically, the RF components of multiple carriers remain active, but in many cases, it is not necessary for all carriers to transmit data.

[0149] In some implementations, the information used to instruct the terminal device on the carriers listening to the PDCCH can be a bitmap, indicating one or more carriers. This approach allows for flexible data scheduling and power-saving opportunities; some terminal devices can disable the RF components of specific carriers, thus avoiding the need to turn all carriers on or off. When wake-up is required, the bitmap indicates which carriers need to participate in data transmission, rather than activating all carriers simultaneously. A bitmap is a mechanism for representing carrier wake-up states. Through bitmaps, network devices can flexibly control which carriers need to be woken up and which carriers can remain off or in a low-power state.

[0150] In some implementations, each bit in the bitmap corresponds to a specific carrier. If the bit is "1", it indicates that the carrier needs to be woken up and ready to receive data; if the bit is "0", it indicates that the carrier can remain dormant or off. This mechanism reduces unnecessary power consumption and quickly wakes up the carrier for data transmission when needed. For example, in certain scenarios, network devices may only need to use a small number of carriers to transmit data, thus avoiding unnecessary carrier switching and signal interference. Such scheduling flexibility helps optimize the utilization of network resources while improving overall energy efficiency.

[0151] Terminal equipment, based on information about the carrier of the PDCCH indicated by LP-WUS, can determine one or more serving cells to which LP-WUS applies, or LP-WUS applies to all active serving cells. Generally, power-saving mode is more suitable for single CA scenarios. However, it should also operate in CA mode. This mechanism may not be optimal. Considering that if the RF of the first receiver and the second received RF are on different carriers, they will be very independent, making it difficult to support cross-carrier association of LP-WUS. In some implementations, a serving cell should only be indicated by the first LP-WUS on the same carrier.

[0152] To avoid any misalignment between network devices and terminal devices when activating LP-WUS listening to the PDCCH, the terminal device can send an acknowledgment message to the network device. In some implementations, the terminal device sends a first acknowledgment message to the network device, which indicates that the terminal device has received the first LP-WUS.

[0153] In some implementations, before the terminal device listens to the first LP-WUS, the terminal device receives a trigger message sent by the network device. The trigger message is used to trigger the first receiver of the terminal device to wake up the second receiver of the terminal device. The power consumption of the first receiver is higher than that of the second receiver.

[0154] In some implementations, the trigger message is used to trigger the first receiver of the terminal device to wake up the second receiver of the terminal device. This can be understood as the trigger message triggering the first receiver of the terminal device to wake up the second receiver of the terminal device, and triggering the second receiver of the terminal device to listen to the first LP-WUS. For example, referring to Figure 8, the first receiver is MR and the second receiver is LR. Before receiving the trigger message, MR is in the on state and LR is in the off state. When MR receives the trigger message, it wakes up LR, and LR enters the on state and begins listening to the first LP-WUS.

[0155] In some implementations, the terminal device sends a second confirmation message to the network device, which is used to indicate that the terminal device has received the trigger message.

[0156] In some implementations, the first confirmation information and the second confirmation information can be carried in the same request. For example, after the second receiver of the terminal device receives the first LP-WUS, the first receiver of the terminal device sends a request carrying the first confirmation information and the second confirmation information to confirm that the terminal device has received the trigger message and the first LP-WUS.

[0157] In some implementations, the first and second acknowledgment messages can be carried in different requests. For example, referring to Figure 8, the first receiver is the MR (Member Receiver), and the second receiver is the LR (Legion Receiver). The network device sends a trigger request to the MR of the terminal device. After receiving the trigger message, the MR of the terminal device triggers the LR to switch from the off state to the on state. The MR of the terminal device sends a second acknowledgment request to the network device. The second acknowledgment request carries the second acknowledgment message to confirm that the MR has successfully received the trigger message. The LR of the terminal device listens for the first LP-WUS in the on state. When the LR of the terminal device receives the first LP-WUS, the MR of the terminal device sends a first acknowledgment request to the network device. The first acknowledgment request carries the first acknowledgment message to confirm that the LR has successfully received the first LP-WUS. After the handshake process, the network device and the terminal device establish a reliable consensus on the use of the MR or LR to avoid transmission or reception loss between the network device and the terminal device.

[0158] In some implementations, if a network device misses the first and second acknowledgment messages, it can resend the trigger message or the first LP-WUS until it receives an acknowledgment message.

[0159] In some implementations, after the terminal device sends the first confirmation message, the first receiver of the terminal device enters a sleep state. For example, referring to Figure 8, the first receiver is MR and the second receiver is LR. After the MR sends the first confirmation message to the network device, the MR enters a sleep state after a delay from the on state.

[0160] As discussed above, a terminal device can include a first receiver and a second receiver. An important question concerns the assumption that the first and second receivers can simultaneously receive DL signals. In some implementations, this capability is closely related to the terminal device's implementation. For example, if there is a switching mechanism between the antenna and either the first or second receiver, the terminal device can only use one of the two receivers at any given time. If the first and second receivers are connected to the antenna without a switch, the terminal device can use both receivers simultaneously, but there may be some signal power loss because the total received power is divided into different branches (corresponding to different receivers). If the power is evenly distributed between the two branches (i.e., the two receivers), both receivers may introduce a few dB of signal-to-noise ratio loss. When the terminal device has only one receiver, in connected mode, LP-WUS can at least trigger PDCCH listening when DL traffic arrives.

[0161] In some implementations, if the terminal device includes two receivers, namely the first receiver and the second receiver mentioned above, the terminal device can also, based on its own capabilities and implementation mechanisms, allow the first receiver to receive DL signals from the network device.

[0162] In connected mode, the LP-WUS indication triggers the PDCCH listening of the first receiver; LP-WUS only affects the PDCCH listening of the first receiver. For DL-configured resources, such as DL semi-persistent scheduling (SPS), since the network device allocates DL SPS resources knowing that LP-WUS is enabled, the network device expects the terminal device to perform traditional operations on the DL SPS resources, and there should be no mismatch between the terminal device and the network device's listening on the first or second receiver. In some implementations, the terminal device should listen to the DL SPS resources through the first receiver to avoid losing any DL data.

[0163] However, for UL-configured resources, such as UL Type 1 or UL Class 2 (UL SPS), sometimes UL-configured assets exist, but the terminal device lacks UL data for transmission. If UL skipping is not enabled, the terminal device should still send padding bits in the UL-configured resources, resulting in additional power consumption. In some implementations, if the terminal device is triggering PDCCH listening using the first LP-WUS, UL configuration is skipped if no UL data is available. This eliminates the need for the terminal device to turn on the first receiver and continue listening to LP-WUS, further reducing the terminal device's power consumption.

[0164] Since the power consumption of the second receiver listening to the first LP-WUS is much lower than the power consumption of the first receiver listening to the PDCCH, the PDCCH listening can be triggered additionally according to the traditional C-DRX cycle. If the first timer needs to be started according to the service mode or other factors, and the timer is not started by the first LP-WUS, the terminal device needs to confirm whether it needs to listen to the second LP-WUS during the operation of the first timer.

[0165] In some implementations, if the start of the first timer is not triggered by the first LP-WUS, the terminal device performs one or more of the following operations during the operation of the first timer: does not listen to the second LP-WUS, which is sent to the terminal device by the network device after the first LP-WUS; listens to the second LP-WUS; or determines whether to listen to the second LP-WUS based on the first LP-WUS.

[0166] In some implementations, the first timer is not triggered by the first LP-WUS. This can be understood as the terminal device not listening to or receiving the first LP-WUS, and the first timer is started by the traditional C-DRX configuration.

[0167] In some implementations, the first timer is not started by the first LP-WUS. This can be understood as the terminal device receiving the first LP-WUS, but the first LP-WUS does not indicate that the first timer should be started. Instead, the first timer is started by the traditional C-DRX configuration.

[0168] In some implementations, determining whether to listen to the second LP-WUS based on the first LP-WUS can be understood as follows: the terminal device receives the first LP-WUS, but the first LP-WUS does not indicate the start of the first timer. The first timer is started by the traditional C-DRX cycle. During the operation of the first timer, the terminal device determines whether to listen to the second LP-WUS based on the information indicated by the first LP-WUS.

[0169] The method embodiments of this application have been described in detail above with reference to Figures 1 to 8. The apparatus embodiments of this application will be described in detail below with reference to Figures 9 to 11. It should be understood that the descriptions of the method embodiments correspond to the descriptions of the apparatus embodiments; therefore, any parts not described in detail can be referred to the foregoing method embodiments.

[0170] Figure 9 is a schematic diagram of a terminal device according to an embodiment of this application. The terminal device 900 shown in Figure 9 includes a receiving unit 910 and a listening unit 920.

[0171] The receiving unit 910 is used to receive the first low-power wake-up signal LP-WUS sent by the network device;

[0172] The listening unit 920, in response to receiving the first LP-WUS, is configured to listen to the physical downlink control channel (PDCCH) during a first time period.

[0173] In some implementations, the first time period is determined based on a first timer, which includes one or more of the following: a non-continuous reception DRX inactive timer; a DRX continuous timer; or a timer triggered by the first LP-WUS.

[0174] In some implementations, the first timer is determined based on one or more of the following: service type; data transmission mode; data traffic characteristics; quality of service requirements; and network load information.

[0175] In some implementations, the start time of the first timer is determined based on a first time window and a first time offset, wherein the first time window is used to monitor the first LP-WUS.

[0176] In some implementations, the first time offset is used to indicate the time interval between the start time of the first time window and the start time of the first timer; or the first time offset is used to indicate the time interval between the end time of the first time window and the start time of the first timer.

[0177] In some implementations, the first time offset is configured by the network device and is determined based on one or more of the following: one or more candidate values ​​of the first time offset reported by the terminal device; one or more candidate values ​​of the first time offset supported by the subcarrier spacing SCS; the location information of the terminal device; the resource scheduling congestion level; the data transmission cycle; the wake-up delay of the terminal device; the processing delay of the terminal device; and the listening cycle of the first LP-WUS.

[0178] In some implementations, the candidate value is determined based on one or more of the following: the time the terminal device processes the first LP-WUS; the transition time from the second receiver of the terminal device to the first receiver of the terminal device, wherein the power consumption of the first receiver is higher than that of the second receiver; the synchronization duration of the first receiver; SCS; the sleep type supported by the terminal device; data transmission latency requirements; and network status information.

[0179] In some implementations, the duration of the first timer is determined based on the data transmission duration.

[0180] In some implementations, the period of the first timer is determined based on the data transmission period.

[0181] In some implementations, the first time window includes multiple listening opportunities of the first LP-WUS, the listening opportunities being determined based on one or more of the following: system frame number; subframe number; the listening period of the first LP-WUS; and the listening start offset of the first LP-WUS.

[0182] In some implementations, the start time of the first time window is determined based on one or more of the following: the start time of data transmission; the listening period of the first LP-WUS.

[0183] In some implementations, the parameters of the first time window and / or the first timer are determined using a model based on network load and / or traffic information.

[0184] In some implementations, the first LP-WUS carries one or more of the following: an identifier of the terminal device; information for instructing the terminal device to trigger listening to the PDCCH; and information for instructing the terminal device to listen to the carrier of the PDCCH.

[0185] In some implementations, the terminal device further includes a sending unit, configured to send first confirmation information to the network device, the first confirmation information being used to indicate that the terminal device has received the first LP-WUS.

[0186] In some implementations, the terminal device further includes: before the listening unit listens to the first LP-WUS, the receiving unit 910 is also configured to receive a trigger message sent by the network device, the trigger message being used to trigger the first receiver of the terminal device to wake up the second receiver of the terminal device, wherein the power consumption of the first receiver is higher than that of the second receiver.

[0187] In some implementations, the terminal device further includes: the sending unit is further configured to send second confirmation information to the network device, the second confirmation information being used to indicate that the terminal device has received the trigger message.

[0188] In some implementations, the terminal device further includes an execution unit, which, if the start of the first timer is not triggered by the first LP-WUS, performs one or more of the following operations during the operation of the first timer: not listening to the second LP-WUS, which is sent to the terminal device by the network device after the first LP-WUS; listening to the second LP-WUS; and determining whether to listen to the second LP-WUS based on the first LP-WUS.

[0189] Figure 10 is a schematic diagram of a network device according to an embodiment of this application. The network device 1000 shown in Figure 10 includes: a transmitting unit 1010.

[0190] The transmitting unit 1010 is used to send a first low-power wake-up signal LP-WUS to the terminal device; the first LP-WUS is used to trigger the terminal device to listen to the physical downlink control channel PDCCH during a first time period.

[0191] In some implementations, the first time period is determined based on a first timer, which includes one or more of the following: a non-continuous reception DRX inactive timer; a DRX continuous timer; or a timer triggered by the first LP-WUS.

[0192] In some implementations, the first timer is determined based on one or more of the following: service type; data transmission mode; data traffic characteristics; quality of service requirements; and network load information.

[0193] In some implementations, the start time of the first timer is determined based on a first time window and a first time offset, wherein the first time window is used to monitor the first LP-WUS.

[0194] In some implementations, the first time offset is used to indicate the time interval between the start time of the first time window and the start time of the first timer; or the first time offset is used to indicate the time interval between the end time of the first time window and the start time of the first timer.

[0195] In some implementations, the first time offset is configured by the network device and is determined based on one or more of the following: one or more candidate values ​​of the first time offset reported by the terminal device; one or more candidate values ​​of the first time offset supported by the subcarrier spacing SCS; the location information of the terminal device; the resource scheduling congestion level; the data transmission cycle; the wake-up delay of the terminal device; the processing delay of the terminal device; and the listening cycle of the first LP-WUS.

[0196] In some implementations, the candidate value is determined based on one or more of the following: the time the terminal device processes the first LP-WUS; the transition time from the second receiver of the terminal device to the first receiver of the terminal device, wherein the power consumption of the first receiver is higher than that of the second receiver; the synchronization duration of the first receiver; the subcarrier spacing (SCS); the sleep type supported by the terminal device; the data transmission latency requirement; and network status information.

[0197] In some implementations, the duration of the first timer is determined based on the data transmission duration.

[0198] In some implementations, the period of the first timer is determined based on the data transmission period.

[0199] In some implementations, the first time window includes multiple listening opportunities of the first LP-WUS, the listening opportunities being determined based on one or more of the following: system frame number; subframe number; the listening period of the first LP-WUS; and the listening start offset of the first LP-WUS.

[0200] In some implementations, the start time of the first time window is determined based on one or more of the following: the start time of data transmission; the listening period of the first LP-WUS.

[0201] In some implementations, the parameters of the first time window and / or the first timer are determined using a model based on network load and / or traffic information.

[0202] In some implementations, the first LP-WUS carries one or more of the following: an identifier of the terminal device; information for instructing the terminal device to trigger listening to the PDCCH; and information for instructing the terminal device to listen to the carrier of the PDCCH.

[0203] In some implementations, the network device further includes a receiving unit, configured to receive first confirmation information sent by the terminal device, the first confirmation information being used to indicate that the terminal device has received the first LP-WUS.

[0204] In some implementations, the network device further includes: before the transmitting unit 1010 transmits the first LP-WUS, the transmitting unit 1010 is further configured to send a trigger message to the terminal device, the trigger message being used to trigger the first receiver of the terminal device to wake up the second receiver of the terminal device, wherein the power consumption of the first receiver is higher than that of the second receiver.

[0205] In some implementations, the network device further includes: the receiving unit is further configured to receive second confirmation information sent by the terminal device, the second confirmation information being used to indicate that the terminal device has received the trigger message.

[0206] In an optional embodiment, the receiving unit 910 may be a transceiver 1130, and the listening unit 920 may also be a transceiver 1130. The terminal device 900 may further include a processor 1110 and a memory 1120, as shown in FIG11.

[0207] In an optional embodiment, the transmitting unit 1010 may be a transceiver 1130. The network device 1000 may also include a processor 1110 and a memory 1120, as shown in FIG11.

[0208] Figure 11 is a schematic structural diagram of a communication device according to an embodiment of this application. The dashed lines in Figure 11 indicate that the unit or module is optional. This device 1100 can be used to implement the methods described in the above method embodiments. Device 1100 can be a chip, a terminal device, or a network device.

[0209] Apparatus 1100 may include one or more processors 1110. The processor 1110 may support apparatus 1100 in implementing the methods described in the preceding method embodiments. The processor 1110 may be a general-purpose processor or a special-purpose processor. For example, the processor may be a central processing unit (CPU). Alternatively, the processor may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0210] The apparatus 1100 may further include one or more memories 1120. The memories 1120 store a program that can be executed by the processor 1110, causing the processor 1110 to perform the methods described in the preceding method embodiments. The memories 1120 may be independent of the processor 1110 or integrated within the processor 1110.

[0211] The device 1100 may also include a transceiver 1130. The processor 1110 can communicate with other devices or chips via the transceiver 1130. For example, the processor 1110 can send and receive data with other devices or chips via the transceiver 1130.

[0212] This application also provides a computer-readable storage medium for storing a program. This computer-readable storage medium can be applied to a terminal or network device provided in this application, and the program causes a computer to execute the methods performed by the terminal or network device in various embodiments of this application.

[0213] This application also provides a computer program product. The computer program product includes a program. The computer program product can be applied to a terminal or network device provided in this application embodiment, and the program causes a computer to execute the methods performed by the terminal or network device in various embodiments of this application.

[0214] This application also provides a computer program. This computer program can be applied to the terminal or network device provided in this application, and the computer program causes the computer to execute the methods performed by the terminal or network device in various embodiments of this application.

[0215] It should be understood that the terms "system" and "network" in this application can be used interchangeably. Furthermore, the terminology used in this application is only for explaining specific embodiments of the application and is not intended to limit the application. The terms "first," "second," "third," and "fourth," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. In addition, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion.

[0216] In the embodiments of this application, the term "instruction" can be a direct instruction, an indirect instruction, or an indication of a relationship. For example, A instructing B can mean that A directly instructs B, such as B being able to obtain information through A; it can also mean that A indirectly instructs B, such as A instructing C, so B can obtain information through C; or it can mean that there is a relationship between A and B.

[0217] In the embodiments of this application, the term "correspondence" can indicate a direct or indirect correspondence between two things, or an association between two things, or a relationship such as instruction and being instructed, configuration and being configured.

[0218] In this application embodiment, the "protocol" may refer to a standard protocol in the field of communication, such as the LTE protocol, the NR protocol, and related protocols applied to future communication systems. This application does not limit this.

[0219] In the embodiments of this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0220] In the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0221] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0222] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0223] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0224] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The 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 described in 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 device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can read or a data storage device such as a server or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs, DVDs) or semiconductor media (e.g., solid-state disks, SSDs), etc.

[0225] 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 that can be easily conceived by those skilled in the art within the scope of the technology 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 method of wireless communication, comprising: include: The terminal device receives the first low-power wake-up signal LP-WUS sent by the network device; In response to receiving the first LP-WUS, the terminal device listens to the Physical Downlink Control Channel (PDCCH) for a first time period.

2. The method of claim 1, wherein, The first time period is determined based on a first timer, which includes one or more of the following: Non-continuous reception DRX inactive timer; DRX continuous timer; The timer triggered by the first LP-WUS.

3. The method of claim 2, wherein, The first timer is determined based on one or more of the following: Business type; Data transmission mode; Data flow characteristics; Service quality requirements; Network load information.

4. The method of claim 2 or 3, wherein, The start time of the first timer is determined based on the first time window and the first time offset. The first time window is used to monitor the first LP-WUS.

5. The method of claim 4, wherein, The first time offset is used to indicate the time interval between the start time of the first time window and the start time of the first timer; or The first time offset is used to indicate the time interval between the end time of the first time window and the start time of the first timer.

6. The method of claim 5, wherein, The first time offset is configured by the network device and is determined based on one or more of the following: One or more candidate values ​​of the first time offset reported by the terminal device; One or more candidate values ​​for the first time offset supported by the subcarrier spacing SCS; The location information of the terminal device; Resource scheduling congestion level; Data transmission cycle; The wake-up delay of the terminal device; The processing latency of the terminal device; The first LP-WUS listening cycle.

7. The method of claim 6, wherein, The candidate value is determined based on one or more of the following: The time it takes for the terminal device to process the first LP-WUS; The transition time from the second receiver of the terminal device to the first receiver of the terminal device, wherein the power consumption of the first receiver is higher than that of the second receiver; The synchronization duration of the first receiver; SCS; The terminal device supports the following sleep types; Data transmission latency requirements; Network status information.

8. The method of any one of claims 2-7, wherein, The duration of the first timer is determined based on the data transmission duration.

9. The method of any one of claims 2-8, wherein, The period of the first timer is determined based on the data transmission period.

10. The method of claim 4, wherein, The first time window includes multiple listening opportunities of the first LP-WUS, and the listening opportunities are determined based on one or more of the following: System frame number; Subframe number; The listening period of the first LP-WUS; The first LP-WUS listener begins to offset.

11. The method of claim 4 or 10, wherein, The start time of the first time window is determined based on one or more of the following: Data transmission start time; The first LP-WUS listening cycle.

12. The method of claim 4, wherein, The parameters of the first time window and / or the first timer are determined using a model based on network load and / or traffic information.

13. The method of any one of claims 1-12, wherein, The first LP-WUS carries one or more of the following: The identifier of the terminal device; Information used to instruct the terminal device to trigger listening to the PDCCH; Information used to instruct the terminal device to listen to the carrier of the PDCCH.

14. The method of any one of claims 1-13, wherein, The method further includes: The terminal device sends a first confirmation message to the network device, the first confirmation message being used to indicate that the terminal device has received the first LP-WUS.

15. The method of any one of claims 1-14, wherein, The method further includes: Before the terminal device listens to the first LP-WUS, the terminal device receives a trigger message sent by the network device. The trigger message is used to trigger the first receiver of the terminal device to wake up the second receiver of the terminal device. The power consumption of the first receiver is higher than that of the second receiver.

16. The method of claim 15, wherein, The method further includes: The terminal device sends a second confirmation message to the network device, the second confirmation message being used to indicate that the terminal device has received the trigger message.

17. The method of any one of claims 2-16, wherein, The method further includes: If the first timer is not triggered by the first LP-WUS, then during the operation of the first timer, the terminal device performs one or more of the following operations: The second LP-WUS is not monitored; the second LP-WUS is sent by the network device to the terminal device after the first LP-WUS. Listen to the second LP-WUS; Whether to listen to the second LP-WUS is determined based on the first LP-WUS.

18. A method of wireless communication, comprising: include: The network device sends a first low-power wake-up signal (LP-WUS) to the terminal device; The first LP-WUS is used to trigger the terminal device to listen to the physical downlink control channel (PDCCH) during a first time period.

19. The method of claim 18, wherein, The first time period is determined based on a first timer, which includes one or more of the following: Non-continuous reception DRX inactive timer; DRX continuous timer; The timer triggered by the first LP-WUS.

20. The method of claim 19, wherein, The first timer is determined based on one or more of the following: Business type; Data transmission mode; Data flow characteristics; Service quality requirements; Network load information.

21. The method of claim 19 or 20, wherein, The start time of the first timer is determined based on the first time window and the first time offset. The first time window is used to monitor the first LP-WUS.

22. The method of claim 21, wherein, The first time offset is used to indicate the time interval between the start time of the first time window and the start time of the first timer; or The first time offset is used to indicate the time interval between the end time of the first time window and the start time of the first timer.

23. The method of claim 22, wherein, The first time offset is configured by the network device and is determined based on one or more of the following: One or more candidate values ​​of the first time offset reported by the terminal device; One or more candidate values ​​for the first time offset supported by the subcarrier spacing SCS; The location information of the terminal device; Resource scheduling congestion level; Data transmission cycle; The wake-up delay of the terminal device; The processing latency of the terminal device; The first LP-WUS listening cycle.

24. The method of claim 23, wherein, The candidate value is determined based on one or more of the following: The time it takes for the terminal device to process the first LP-WUS; The transition time from the second receiver of the terminal device to the first receiver of the terminal device, wherein the power consumption of the first receiver is higher than that of the second receiver; The synchronization duration of the first receiver; SCS; The terminal device supports the following sleep types; Data transmission latency requirements; Network status information.

25. The method of any one of claims 19-24, wherein, The duration of the first timer is determined based on the data transmission duration.

26. The method of any one of claims 19-25, wherein, The period of the first timer is determined based on the data transmission period.

27. The method of claim 21, wherein, The first time window includes multiple listening opportunities of the first LP-WUS, and the listening opportunities are determined based on one or more of the following: System frame number; Subframe number; The listening period of the first LP-WUS; The first LP-WUS listener begins to offset.

28. The method of claim 21 or 27, wherein, The start time of the first time window is determined based on one or more of the following: Data transmission start time; The first LP-WUS listening cycle.

29. The method of claim 21, wherein, The parameters of the first time window and / or the first timer are determined using a model based on network load and / or traffic information.

30. The method of any one of claims 18-29, wherein, The first LP-WUS carries one or more of the following: The identifier of the terminal device; Information used to instruct the terminal device to trigger listening to the PDCCH; Information used to instruct the terminal device to listen to the carrier of the PDCCH.

31. The method of any one of claims 18-30, wherein, The method further includes: The network device receives a first confirmation message sent by the terminal device, the first confirmation message being used to indicate that the terminal device has received the first LP-WUS.

32. The method of any one of claims 18-31, wherein, The method further includes: Before the network device sends the first LP-WUS, the network device sends a trigger message to the terminal device. The trigger message is used to trigger the first receiver of the terminal device to wake up the second receiver of the terminal device. The power consumption of the first receiver is higher than that of the second receiver.

33. The method of claim 32, wherein, The method further includes: The network device receives a second confirmation message sent by the terminal device, the second confirmation message being used to indicate that the terminal device has received the trigger message.

34. A terminal device, comprising: include: The receiving unit is used to receive the first low-power wake-up signal LP-WUS sent by the network device; A listening unit, in response to receiving the first LP-WUS, is configured to listen to the physical downlink control channel (PDCCH) during a first time period.

35. The terminal device according to claim 34, characterized by The first time period is determined based on a first timer, which includes one or more of the following: Non-continuous reception DRX inactive timer; DRX continuous timer; The timer triggered by the first LP-WUS.

36. The terminal device of claim 35, wherein, The first timer is determined based on one or more of the following: Business type; Data transmission mode; Data flow characteristics; Service quality requirements; Network load information.

37. The terminal device according to claim 35 or 36, characterized by The start time of the first timer is determined based on the first time window and the first time offset. The first time window is used to monitor the first LP-WUS.

38. The terminal device of claim 37, wherein, The first time offset is used to indicate the time interval between the start time of the first time window and the start time of the first timer; or The first time offset is used to indicate the time interval between the end time of the first time window and the start time of the first timer.

39. The terminal device of claim 38, wherein, The first time offset is configured by the network device and is determined based on one or more of the following: One or more candidate values ​​of the first time offset reported by the terminal device; One or more candidate values ​​for the first time offset supported by the subcarrier spacing SCS; The location information of the terminal device; Resource scheduling congestion level; Data transmission cycle; The wake-up delay of the terminal device; The processing latency of the terminal device; The first LP-WUS listening cycle.

40. The terminal device of claim 39, wherein, The candidate value is determined based on one or more of the following: The time it takes for the terminal device to process the first LP-WUS; The transition time from the second receiver of the terminal device to the first receiver of the terminal device, wherein the power consumption of the first receiver is higher than that of the second receiver; The synchronization duration of the first receiver; SCS; The terminal device supports the following sleep types; Data transmission latency requirements; Network status information.

41. The terminal device of any one of claims 35-40, wherein, The duration of the first timer is determined based on the data transmission duration.

42. The terminal device of any one of claims 35-41, wherein, The period of the first timer is determined based on the data transmission period.

43. The terminal device of claim 37, wherein, The first time window includes multiple listening opportunities of the first LP-WUS, and the listening opportunities are determined based on one or more of the following: System frame number; Subframe number; The listening period of the first LP-WUS; The first LP-WUS listener begins to offset.

44. The terminal device according to claim 37 or 43, characterized by The start time of the first time window is determined based on one or more of the following: Data transmission start time; The first LP-WUS listening cycle.

45. The terminal device of claim 37, wherein, The parameters of the first time window and / or the first timer are determined using a model based on network load and / or traffic information.

46. The terminal device of any one of claims 34-45, wherein, The first LP-WUS carries one or more of the following: The identifier of the terminal device; Information used to instruct the terminal device to trigger listening to the PDCCH; Information used to instruct the terminal device to listen to the carrier of the PDCCH.

47. The terminal device of any one of claims 34-46, wherein, The terminal device also includes: The sending unit is configured to send a first confirmation message to the network device, the first confirmation message being used to instruct the terminal device to receive the first LP-WUS.

48. The terminal device of any one of claims 34-47, wherein, The terminal device also includes: Before the listening unit listens to the first LP-WUS, the receiving unit is also used to receive a trigger message sent by the network device. The trigger message is used to trigger the first receiver of the terminal device to wake up the second receiver of the terminal device. The power consumption of the first receiver is higher than that of the second receiver.

49. The terminal device of claim 48, wherein, The terminal device also includes: The sending unit is further configured to send a second confirmation message to the network device, the second confirmation message being used to indicate that the terminal device has received the trigger message.

50. The terminal device of any one of claims 35-49, wherein, The terminal device also includes: If the start of the first timer is not triggered by the first LP-WUS, the execution unit performs one or more of the following operations during the operation of the first timer: The second LP-WUS is not monitored; the second LP-WUS is sent by the network device to the terminal device after the first LP-WUS. Listen to the second LP-WUS; Whether to listen to the second LP-WUS is determined based on the first LP-WUS. 51.A network device, characterized by, include: The transmitting unit is used to send a first low-power wake-up signal LP-WUS to the terminal device; The first LP-WUS is used to trigger the terminal device to listen to the physical downlink control channel (PDCCH) during a first time period.

52. The network device of claim 51, wherein, The first time period is determined based on a first timer, which includes one or more of the following: Non-continuous reception DRX inactive timer; DRX continuous timer; The timer triggered by the first LP-WUS.

53. The network device of claim 52, wherein, The first timer is determined based on one or more of the following: Business type; Data transmission mode; Data flow characteristics; Service quality requirements; Network load information.

54. The network device of claim 52 or 53, wherein, The start time of the first timer is determined based on the first time window and the first time offset. The first time window is used to monitor the first LP-WUS.

55. The network device of claim 54, wherein, The first time offset is used to indicate the time interval between the start time of the first time window and the start time of the first timer; or The first time offset is used to indicate the time interval between the end time of the first time window and the start time of the first timer.

56. The network device of claim 55, wherein, The first time offset is configured by the network device and is determined based on one or more of the following: One or more candidate values ​​of the first time offset reported by the terminal device; One or more candidate values ​​for the first time offset supported by the subcarrier spacing SCS; The location information of the terminal device; Resource scheduling congestion level; Data transmission cycle; The wake-up delay of the terminal device; The processing latency of the terminal device; The first LP-WUS listening cycle.

57. The network device of claim 56, wherein, The candidate value is determined based on one or more of the following: The time it takes for the terminal device to process the first LP-WUS; The transition time from the second receiver of the terminal device to the first receiver of the terminal device, wherein the power consumption of the first receiver is higher than that of the second receiver; The synchronization duration of the first receiver; SCS; The terminal device supports the following sleep types; Data transmission latency requirements; Network status information.

58. The network device of any of claims 52-57, wherein, The duration of the first timer is determined based on the data transmission duration.

59. The network device of any of claims 52-58, wherein, The period of the first timer is determined based on the data transmission period.

60. The network device of claim 54, wherein, The first time window includes multiple listening opportunities of the first LP-WUS, and the listening opportunities are determined based on one or more of the following: System frame number; Subframe number; The listening period of the first LP-WUS; The first LP-WUS listener begins to offset.

61. The network device of claim 54 or 60, wherein, The start time of the first time window is determined based on one or more of the following: Data transmission start time; The first LP-WUS listening cycle.

62. The network device of claim 54, wherein, The parameters of the first time window and / or the first timer are determined using a model based on network load and / or traffic information.

63. The network device of any of claims 51-62, wherein, The first LP-WUS carries one or more of the following: The identifier of the terminal device; Information used to instruct the terminal device to trigger listening to the PDCCH; Information used to instruct the terminal device to listen to the carrier of the PDCCH.

64. The network device of any of claims 51-63, wherein, The network device also includes: The receiving unit is configured to receive first confirmation information sent by the terminal device, wherein the first confirmation information is used to indicate that the terminal device has received the first LP-WUS.

65. The network device of any of claims 51-64, wherein, The network device also includes: Before the transmitting unit transmits the first LP-WUS, the transmitting unit is further configured to send a trigger message to the terminal device. The trigger message is used to trigger the first receiver of the terminal device to wake up the second receiver of the terminal device. The power consumption of the first receiver is higher than that of the second receiver.

66. The network device of claim 65, wherein, The network device also includes: The receiving unit is further configured to receive a second confirmation message sent by the terminal device, the second confirmation message being used to indicate that the terminal device has received the trigger message.

67. A terminal device, comprising: The device includes a transceiver, a memory, and a processor. The memory is used to store a program, and the processor is used to invoke the program in the memory and control the transceiver to receive or send signals so that the terminal performs the method as described in any one of claims 1-17.

68. A network device, comprising: The device includes a transceiver, a memory, and a processor. The memory stores a program, and the processor invokes the program in the memory and controls the transceiver to receive or transmit signals so that the network device performs the method as described in any one of claims 18-33.

69. An apparatus, comprising: Includes a processor for calling a program from memory to cause the device to perform the method as described in any one of claims 1-33.

70. A chip, comprising: Includes a processor for calling a program from memory, causing a device on which the chip is mounted to perform the method as described in any one of claims 1-33.

71. A computer readable storage medium, characterized in that, It contains a program that causes a computer to perform the method as described in any one of claims 1-33.

72. A computer program product, characterized in that, Includes a program that causes a computer to perform the method as described in any one of claims 1-33.

73. A computer program, characterized in that, The computer program causes the computer to perform the method as described in any one of claims 1-33.

Images