Energy saving enhancement methods and user equipment for sidelink communications

Abstract

An energy saving enhancement method for sidelink communication is provided. A user equipment (UE) maintains a SL DRX configuration including one of a transmission mode and a reception mode in which the UE is expected to transmit and receive with a peer UE. The UE exchanges the SL DRX configuration with the peer UE. Based on the exchange of the SL DRX configuration, the UE determines when to transmit to or receive from the peer UE during a SL DRX operation. Based on the determination, the UE transmits to or receives from the peer UE during the SL DRX operation.

Description

[0001] CROSS-REFERENCE

[0002] This application claims priority to International Patent Application No. PCT / CN2020 / 107820, filed on August 7, 2022, the entire contents of which are incorporated herein by reference. TECHNICAL FIELD

[0003] The present application relates generally to mobile communications, and more particularly to power saving enhancement for Sidelink (SL) communication. BACKGROUND

[0004] In a typical mobile communication environment, a User Equipment (UE) (also referred to as a Mobile Station (MS)), such as a mobile phone (also referred to as a handset), or a tablet Personal Computer (PC) with wireless communication functionality, can communicate voice and / or data signals with one or more serving networks. The communication between the UE and the serving network can be performed using various cellular technologies, such as Global System for Mobile communications (GSM) technology, General Packet Radio Service (GPRS) technology, Enhanced Data rates for Global Evolution (EDGE) technology, Wideband Code Division Multiple Access (WCDMA) technology, Code Division Multiple Access 2000 (CDMA2000) technology, Time Division-Synchronous Code Division Multiple Access (TD-SCDMA) technology, Worldwide Interoperability for Microwave Access (WiMAX) technology, Long Term Evolution (LTE) technology, LTE-Advanced (LTE-A) technology, Time Division LTE (TD-LTE) technology, and the like.

[0005] These RAT technologies have been adopted in various telecommunication standards to provide a common protocol that enables different wireless devices to communicate on a municipal, national, regional, and even global level. An example of which is 5G NR. 5G NR is a series of improvements to LTE mobile standard promulgated by Third Generation Partnership Project (3GPP). It is designed to better support mobile broadband Internet access by improving spectral efficiency, lowering costs, and improving services. 5G NR includes both data and voice

[0006] In LTE and 5G NR, device-to-device (D2D) communication is supported to allow two or more UEs to communicate directly with each other. This D2D communication can also be referred to as SL communication, and it can be applied to vehicle communication services, which are also referred to as Vehicle-to-Everything (V2X) services. V2X collectively refers to communication technologies via all interfaces with vehicles, including Vehicle-to-Vehicle (V2V), Vehicle-to-Infrastructure (V2I), Vehicle-to-Person (V2P), and Vehicle-to-Network (V2N).

[0007] In particular, according to Release 16 of the 3GPP specification for NR-based V2X, traffic with different Quality of Service (QoS) requirements is supported, and UEs are allowed to simultaneously transmit / receive traffic delivered through unicast, groupcast, and broadcast. While there are significant enhancements over LTE-based V2X, the current NR-based V2X design has not introduced any energy saving related mechanisms. Since a UE does not know when other UEs will attempt to communicate with it, the UE needs to continuously monitor for Sidelink Control Information (SCI) over the PC5 interface, even if there can not be any peer UEs nearby. Disadvantageously, continuous SCI monitoring over the PC5 interface will result in significant power consumption for V2X UEs.

[0008] Further, in NR-based V2X, if mode-1 resource scheduling (i.e., SL resources scheduled by the network) is applied, the radio resources for new transmission and retransmission are scheduled by the network. That is, in case there is upcoming SL traffic, the UE needs to continuously monitor the Uu interface to receive SL grant scheduling from the network and ignore the power saving rules currently in use on the Uu interface. Similarly, the continuous monitoring over the Uu interface will degrade the power saving performance on the Uu interface.

[0009] Therefore, it is desirable to have a robust and efficient power saving mechanism for NR-based V2X. SUMMARY

[0010] The present disclosure proposes a power saving mechanism for NR-based V2X, in which a discontinuous reception (DRX)-like operation is introduced for SL communication.

[0011] In one aspect of the present disclosure, a method is provided, the method comprising the steps of: maintaining, by a UE, a SL DRX configuration, wherein the SL DRX configuration comprises one of a transmission mode and a reception mode in which the UE is expected to transmit to and receive from a peer UE; exchanging, with the peer UE, the SL DRX configuration; determining, based on the exchange of the SL DRX configuration, when to transmit to or receive from the peer UE during a SL DRX operation; and transmitting to or receiving from the peer UE during the SL DRX operation based on the determination.

[0012] In another aspect of the present disclosure, a UE comprising a wireless transceiver and a controller is provided. The wireless transceiver is configured to perform transmitting to and receiving from a peer UE. The controller is coupled to the wireless transceiver and is configured to: maintain a SL DRX configuration, wherein the SL DRX configuration comprises one of a transmission mode and a reception mode in which the UE is expected to transmit to and receive from the peer UE; exchange, via the wireless transceiver, the SL DRX configuration with the peer UE; determine, based on the exchange of the SL DRX configuration, when to transmit to or receive from the peer UE during a SL DRX operation; and transmit to or receive from the peer UE via the wireless transceiver during the SL DRX operation based on the determination.

[0013] Other aspects and features of the present disclosure will become apparent to those ordinarily skilled in the art upon reading the following detailed description of the specific embodiments of the UE and method supporting SL DRX operation. BRIEF DESCRIPTION OF DRAWINGS

[0014] The present application can be more fully understood by reading the following detailed description together with the accompanying drawings, in which:

[0015] FIG. 1 is a schematic diagram illustrating a cellular communication network according to an embodiment of the application;

[0016] FIG. 2 is a schematic diagram illustrating a SL communication environment according to an embodiment of the application;

[0017] FIG. 3 is a schematic diagram illustrating a SL communication environment according to another embodiment of the application;

[0018] FIG. 4 is a block diagram illustrating a UE according to an embodiment of the application;

[0019] FIG. 5 is a schematic diagram illustrating the application of a separate SL DRX configuration according to an embodiment of the application;

[0020] FIG. 6 is a schematic diagram illustrating the determination of a full SL DRX mode for a UE according to an embodiment of the application;

[0021] FIG. 7 is a flowchart illustrating a method for supporting SL DRX operation according to an embodiment of the application;

[0022] FIG. 8 is a schematic diagram illustrating the relationship between a sensing mode and a transmitting mode according to an embodiment of the application;

[0023] FIG. 9 is a schematic diagram illustrating the relationship between a sensing mode and a transmitting mode according to another embodiment of the application; and

[0024] FIG. 10 is a schematic diagram illustrating an exemplary application of a wake-up signal during SL DRX operation according to an embodiment of the application. DETAILED DESCRIPTION

[0025] The following description is made for the purpose of illustrating the general principles of the present application and should not be taken in a limiting sense. It is to be understood that these embodiments can be employed in software, hardware, firmware, or any combination thereof. As used herein, the terms “includes”, “containing”, and / or “containing” specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0026] FIG. 1 is a schematic diagram illustrating a cellular communication network according to an embodiment of the application.

[0027] like FIG. 1 As shown, the cellular communication network 100 includes an access network 110 and a core network 120. The access network 110 is responsible for processing radio signals, terminating radio protocols, and connecting one or more UEs (not shown) to the core network 120. The core network 120 is responsible for mobility management, network-side authentication, and interfacing with public / external networks (e.g., the Internet).

[0028] In one implementation, the cellular communication network 100 may be a 5G NR network, and the access network 110 and the core network 120 may be a Next Generation Radio Access Network (NG-RAN) and a Next Generation Core Network (NG-CN), respectively.

[0029] NG-RAN can include one or more base stations (BSs) supporting high-frequency bands (e.g., above 24 GHz), such as next-generation nodes (gNBs), and each gNB can also include one or more transmission reception points (TRPs), where each gNB or TRP can be referred to as a 5G BS. Some gNB functions can be distributed across different TRPs, while others can be centralized, leaving flexibility for specific deployments and scope to meet specific requirements. For example, different protocol segmentation options between the central unit and distributed units of a gNB node are possible. In one implementation, the Service Data Adaptation Protocol (SDAP) layer and the Packet Data Convergence Protocol (PDCP) layer can be located in the central unit, while the Radio Link Control (RLC) layer, Medium Access Control (MAC) layer, and Physical (PHY) layer can be located in the distributed units.

[0030] A 5G BS can form one or more cells with different component carriers (CCs) for providing mobile services to a UE. For example, a UE can camp on one or more cells formed by one or more gNBs or TRPs, where the cell where the UE camps can be called the serving cell.

[0031] The NG-CN typically comprises various network functions, including an Access and Mobility Function (AMF), a Session Management Function (SMF), a Policy Control Function (PCF), an Application Function (AF), an Authentication Server Function (AUSF), a User Plane Function (UPF), and a User Data Management (UDM), wherein each network function can be implemented as a network element on a dedicated hardware, or as a software instance running on a dedicated hardware, or as a virtualized function instantiated on a suitable platform, e.g. a cloud infrastructure.

[0032] The AMF provides UE-based authentication, authorization, mobility management, etc. The SMF is responsible for session management and allocates an Internet Protocol (IP) address to the UE. It also selects and controls the UPF for data transmission. If the UE has multiple sessions, different SMFs can be assigned to individual sessions to manage the sessions individually, and individual sessions can provide different functions. The AF provides information about packet flows to the PCF responsible for policy control to support QoS. Based on this information, the PCF determines policies regarding mobility and session management to enable the AMF and SMF to operate correctly. The AUSF stores data for UE authentication, and the UDM stores subscription data of the UE.

[0033] It should be understood that the cellular communication network 100 described in the embodiments of FIG. 1 is for illustrative purposes only and is not intended to limit the scope of the present application. For example, the RAT used by the cellular communication network 100 can be a legacy technology, such as LTE, LTE-A, or TD-LTE technology, or can be a future enhancement of 5G NR technology, such as 6G technology.

[0034] FIG. 2 is a schematic diagram illustrating an SL communication environment according to an embodiment of the present application.

[0035] As FIG. 2 indicated, the UE 1 is located within the radio coverage of the BS and is able to communicate with the BS through a Uu interface, and the UE 2 and the UE 3 are outside the radio coverage of the BS. In addition to supporting the Uu interface, the UE 1 also supports a PC5 interface for SL communication with the UE 2 and the UE 3.

[0036] Specifically, the UE 1 can operate as a scheduling UE (or called a relay UE) which schedules / allocates radio resources for the UEs 2 and 3 (or called scheduling UEs) according to a configuration received from the BS or pre-defined in 3GPP specifications for NR-based V2X. As a relay, the UE 1 can forward traffic between the UEs 2 and 3 and / or between the UEs 2 / 3 and the BS. For example, the UE 1 can be configured as a layer-2 relay or a layer-3 relay. Alternatively, the UE 1 can not operate as a relay and can initiate direct SL communication with one or both of the UEs 2 and 3.

[0037] Note that the 3GPP specifications mentioned herein are used to teach the concept of the present application, and the present application should not be limited thereto.

[0038] FIG. 3 is a schematic diagram illustrating a SL communication environment according to another embodiment of the present application.

[0039] As shown in FIG. 3 none of the UEs 1 to 3 is located within the wireless coverage of the BS, but SL communication between the UEs 1 to 3 can be made through the PC5 interface.

[0040] Specifically, the UE 1 can operate as a scheduling UE (or called a relay UE) which schedules / allocates radio resources for the UEs 2 and 3 (or called scheduling UEs) according to a configuration pre-defined in 3GPP specifications for NR-based V2X or previously received from the BS when the UE 1 camps on the BS. As a relay, the UE 1 can forward traffic between the UEs 2 and 3. For example, the UE 1 can be configured as a layer-2 relay or a layer-3 relay. Alternatively, the UE 1 can not operate as a relay and can initiate direct SL communication with one or both of the UEs 2 and 3.

[0041] FIG. 4 is a block diagram illustrating a UE according to an embodiment of the present application.

[0042] As shown in FIG. 4 , the UE (e.g., a transmitting (Transmitter, Tx) UE or a receiving (Receiver, Rx) UE) includes a wireless transceiver 10, a controller 20, a storage 30, a display 40, and an input / output (Input / Output, I / O) device 50.

[0043] The wireless transceiver 10 is configured to perform wireless transmission and reception with other UEs and / or a BS of an access network 110.

[0044] In detail, the wireless transceiver 10 includes a baseband processing device 11, a radio frequency (RF) device 12, and an antenna 13 including an antenna array for beamforming.

[0045] The baseband processing device 11 is configured to perform baseband signal processing and control communication between a user identification card (not shown) and the RF device 12. The baseband processing device 11 includes a plurality of hardware components that perform baseband signal processing, including analog-to-digital conversion (ADC) / digital-to-analog conversion (DAC), gain adjustment, modulation / demodulation, encoding / decoding, etc.

[0046] The RF device 12 receives an RF wireless signal via the antenna 13, converts the received RF wireless signal into a baseband signal, processes the baseband signal by the baseband processing device 11, or receives a baseband signal from the baseband processing device 11, and converts the received baseband signal into an RF wireless signal, and then transmits via the antenna 13. The RF device 12 also includes a plurality of hardware devices that perform radio frequency conversion. For example, the RF device 12 includes a mixer for multiplying a baseband signal with a carrier wave oscillating in a radio frequency supporting a cellular technology, where the radio frequency can be any radio frequency used in a 5G NR technology (e.g., 30 GHz ~ 300 GHz for mmWave), or 900 MHz, 2100 MHz, or 2.6 GHz used in an LTE / LTE-A / TD-LTE technology, or other radio frequencies, according to the RAT used.

[0047] The controller 20 can be a general purpose processor, a micro control unit (MCU), an application processor, a digital signal processor (DSP), a graphics processing unit (GPU), a holographic processing unit (HPU), a neural processing unit (NPU), etc., which includes various circuits for providing data processing and computing functions, controlling the wireless transceiver 10 to wirelessly communicate with the service network 120, storing data (e.g., program codes) to and retrieving data from the storage device 30, transmitting a series of frame data (e.g., representing text messages, graphics, images, etc.) to the display device 40, and receiving user input signals or output signals via the I / O device 50.

[0048] In particular, the controller 20 coordinates the above-mentioned operations of the wireless transceiver 10, the storage device 30, the display device 40 and the I / O device 50 to perform the method proposed by the present application.

[0049] In another embodiment, the controller 20 can be incorporated into the baseband processing device 11 to function as a baseband processor.

[0050] As will be appreciated by those skilled in the art, the circuitry of the controller 20 generally comprises transistors that control the operation of the circuitry in accordance with the functions and operations described herein. As will be further appreciated, the particular structure or interconnection of the transistors will generally be determined by a compiler, for example, a Register Transfer Language (RTL) compiler. The RTL compiler can operate on a script similar to assembly language code to generate a script that can be compiled for the final circuit layout or fabrication. Indeed, RTL is well known for its role and use in facilitating the design process of electronic and digital systems.

[0051] The storage device 30 is a non-transitory machine-readable storage medium, including a memory (e.g., FLASH memory or Non-Volatile Random Access Memory (NVRAM)), or a magnetic storage device (e.g., a hard disk or a magnetic tape), or an optical disk, or any combination for storing data, instructions and / or program codes, communication protocols and / or the method proposed by the present application of an application. In one example, the communication protocols can include a 5G NR protocol stack, which includes a NAS layer for communication with an AMF / SMF / MME entity connected to the core network 120, an RRC layer for high-layer configuration and control, a PDCP / RLC layer, a MAC layer and a PHY layer.

[0052] The display device 40 can be a Liquid-Crystal Display (LCD), a Light-Emitting Diode (LED) display, an Organic LED (OLED) display or an Electronic Paper Display (EPD) and the like for providing a display function. Alternatively, the display device 40 further includes one or more touch sensors disposed thereon or thereunder for sensing a touch, a contact or a proximity of an object (such as a finger or a stylus).

[0053] The I / O device 50 includes one or more buttons, a keyboard, a mouse, a touchpad, a video camera, a microphone and / or a speaker and the like to function as a Man-Machine Interface (MMI) for interacting with a user.

[0054] It is to be understood that FIG. 4 The components described in the implementations of the present application are merely for the purpose of illustration and are not intended to limit the scope of the present application.

[0055] For example, the UE can include more components, such as a power supply, which can be a mobile / replaceable battery that provides power to all other components of the UE, and a Global Positioning System (GPS) device that can provide location information to the UE for certain location-based services or applications. Alternatively, the UE can include fewer components. For example, the UE can not include the display device 40 and / or the I / O device 50.

[0056] Legacy DRX operation for Uu interface

[0057] In legacy cellular communications, to reduce the power consumption of the UE continuously monitoring the Physical Downlink Control Channel (PDCCH) even when the UE has no traffic to send to or receive from the network, the network can configure the UE with a DRX configuration. In 5G NR, the DRX configuration includes a number of timers and counters to define when the UE should turn on its radio to monitor the PDCCH for possible scheduling, i.e., the DRX active time. For those times not in the DRX active time, the UE does not need to monitor the PDCCH and thus can turn off the radio to save power. The BS and the UE should have a consistent understanding of the DRX active time, thus, only when the UE is in its DRX active time, the BS communicates with the UE.

[0058] Specifically, in NR Release 15, three parameters, including DRX offset, DRX cycle, and DRX on duration, are used to define the basic on-off pattern of the UE in DRX operation. The DRX cycle refers to the period of each on-off pattern. For example, if the DRX cycle is 10 milliseconds (ms) long, it means that the on-off pattern will repeat every 10 ms. The starting time of each DRX cycle is determined by the DRX offset (more specifically, the start operation and slot offset). At the start of each DRX cycle, the UE should turn on its radio to monitor the PDCCH for the time period defined by the DRX on duration and controlled by the DRX on duration timer. If the UE does not receive any PDCCH data before the DRX on duration timer expires, the UE can turn off its radio to save energy until the end of the DRX cycle and resume PDCCH monitoring at the start of the next DRX cycle. In summary, these three parameters define the timing and duration of when the UE should monitor the PDCCH when there is no PDCCH data transmitted by the BS to schedule a downlink (DL) or uplink (UL) transmission.

[0059] In the case of traffic activity when DRX is configured, the UE can need to stay awake for a longer time (i.e., the DRX active time is extended) for possible data transmission and reception. For example, if the UE receives PDCCH data scheduling a new transmission for UL / DL transmission, the DRX inactivity timer is started / restarted, and the UE should always monitor the PDCCH while the DRX inactivity timer is running. The reason is that the new transmission is ongoing, and in response, the UE should stay awake to see if there is more traffic, i.e., burst traffic, after the current new transmission.

[0060] Further, considering that the UE needs to transmit / receive Hybrid Automatic Repeat reQuest (HARQ) retransmissions, HARQ Round-Trip Time (RTT) timers and HARQ retransmission timers are defined for each UL / DL HARQ process. The purpose is that for UL, when the UE transmits an UL packet, the network can need some time (i.e. the time controlled by the HARQ RTT timer) to prepare the scheduling for the HARQ retransmission, which means that the network will not schedule any UL retransmission for the same HARQ process. Therefore, the UE can sleep (e.g. turn off its radio) when the UL HARQ RTT timer is running, and wake up to monitor possible PDCCH for HARQ retransmission after the UL HARQ RTT timer expires, when the HARQ retransmission timer is running. If the UE does not receive any UL grant scheduling for HARQ retransmission during the HARQ retransmission timer is running, the UE can consider that the network does not intend to send UL grant for HARQ retransmission for the HARQ process, therefore, the UE can sleep again. For DL, the mechanism of DL HARQ RTT timer and HARQ retransmission applies similar concepts.

[0061] SL DRX operation for PC5 interface

[0062] In NR Release 16, no power saving mechanism has been introduced for SL communication. That is, when a UE activates SL communication for NR-V2X, the UE shall monitor all SL Rx resource pools for possible SL transmission that can happen at any time. This continuous monitoring task inevitably leads to significant power consumption for the UE. To solve this problem, the present invention proposes to apply a DRX-like mechanism in the PC5 interface for SL communication to reduce unnecessary power consumption for SCI monitoring.

[0063] To enable discontinuous SCI monitoring while ensuring normal SL communication, the UE needs to know when to communicate with its peer UE, i.e. to know whether its peer UE is in active time or not. Otherwise, the UE can attempt SL communication with its peer UE, while the peer UE can have turned off its radio for power saving. Therefore, the SL communication attempt will fail (e.g. due to no response from the peer UE), and the UE can need to do HARQ retransmission. Therefore, some coordination is needed to make the UE know the SL DRX configuration of its peer UE. The principle of coordination of SL DRX operation is to ensure that the receiving UE is woken up to monitor possible SL data reception when the transmitting UE is transmitting.

[0064] In the present disclosure, each UE maintains its SL DRX configuration, which can include a transmission pattern and / or a reception pattern that the UE expects to transmit to and / or receive from a peer UE, and exchanges the SL DRX configuration with the peer UE. Based on the exchange of the SL DRX configuration, the UE can determine when to transmit to or receive from the peer UE during the SL DRX operation. Based on the determination, the UE can perform the transmission to or the reception from the peer UE during the SL DRX operation.

[0065] The transmission pattern can include information indicating specific time-frequency radio resources that the UE uses to make transmissions to the peer UE. For example, the information can include a timing offset of the SL DRX (also referred to as SL DRX offset, including a SL DRX start offset and / or a SL DRX slot offset), a transmission pattern for each repetition period (e.g., specified by a duration for transmission located at the beginning of each repetition period) (also referred to as SL DRX-ON duration), and a repetition period length (also referred to as SL DRX cycle). In one embodiment, the transmission pattern can be a grant of various SL configurations, or periodically reserved resources.

[0066] Upon receiving the transmission pattern from the peer UE, the UE can stay awake to monitor for possible transmissions from the peer UE. In other words, the UE can stay awake to monitor all time-frequency radio resources indicated by any peer UE as part of the transmission pattern. If the UE has multiple peer UEs, the UE can monitor the superposition of the transmission patterns of all peer UEs. Note that if the UE has no data for transmission or retransmission, and if no data from the peer UE is expected (i.e., the current slot is not within the transmission pattern of any peer UE), the UE can turn off its radio to save energy even if the current slot is within its own transmission pattern. In other words, if there is no data to transmit to the peer UE, the UE can skip its own transmission opportunity to its peer UE specified by its own transmission pattern. In other words, the transmitting UE determines when the receiving UE should stay awake to monitor SCI for possible traffic from the transmitting UE. Equivalently, one can say that the transmitting UE determines the SL DRX configuration for the receiving UE to determine its reception pattern, i.e., when the receiving UE should stay awake to monitor SCI and corresponding Physical Sidelink Shared Channel (PSSCH) transmissions from the transmitting UE.

[0067] The reception pattern can include information indicating specific time-frequency radio resources used by the UE to receive from a peer UE. For example, the information can include a timing offset of the SL DRX (also referred to as SL DRX offset, including a SL DRX start offset and / or a SL DRX slot offset), a transmission pattern for each repetition period (e.g., specified by a duration for transmission located at the beginning of each repetition period) (also referred to as SL DRX-ON duration), and a repetition period length (also referred to as SL DRX cycle). In one embodiment, the reception pattern can be a periodically reserved resource that the UE expects a peer UE (Tx UE) to use, of various SL configurations.

[0068] In case the SL DRX configuration received from the peer UE includes a transmission pattern, the Rx UE can stay awake to monitor the transmission resources for possible data reception from the peer UE (Tx UE). In addition, the Rx UE shall monitor the retransmission resources reserved by the Tx UE through SCI, unless the retransmission resources are no longer used (e.g., a Transport Block (TB) transmission is terminated due to successful decoding). The Rx UE shall monitor the retransmission resources even if they are outside the set of transmission resources indicated in the SL DRX configuration of the Tx UE.

[0069] Considering asymmetric traffic flows (i.e., traffic characteristics from UE A to a peer UE B are different from traffic characteristics from the peer UE B back to UE A), it is more flexible for a UE to maintain separate SL DRX configurations for transmission and for reception. FIG. 5 is a schematic diagram illustrating the application of separate SL DRX configurations according to an embodiment of the present application. As FIG. 5 indicated, UE A applies SL DRX configuration 1 to determine when to transmit to UE B, and UE B applies SL DRX configuration 2 to determine when to transmit to UE A. Thus, UE A applies SL DRX configuration 1 for transmission to UE B, and SL DRX configuration 2 for reception of UE B; UE B applies SL DRX configuration 1 for reception from UE A, and SL DRX configuration 2 for transmission to UE A.

[0070] In addition to the SL DRX configuration (with transmission and / or reception patterns), the Rx UE can determine additional and / or aperiodic DRX-ON durations or SL active times from resource reservations in SCI received from the Tx UE. For example, in addition to monitoring the resources indicated in the SL DRX configuration, the Rx UE can monitor the reserved resources indicated by the SCI received from the Tx UE. Thus, the Tx UE can impose restrictions only on some transmissions following the DRX-ON pattern, e.g., when the SCI does not reserve the transmission resources (e.g., initial / first transmission without SCI reservation) and / or when the SCI reception for the reserved resources fails at the Rx UE. Transmissions with resources reserved by previous SCI successfully received by the Rx UE can occur at any time without the need to follow the SL DRX-ON durations derived from the (pre)configured transmission and / or reception patterns. The Tx UE can check the HARQ feedback to determine whether the Rx UE has successfully received the SCI with resource reservation. If the Rx UE fails to receive the SCI with resource reservation, the Tx UE can need to reselect resources within the SL DRX-ON duration. If the Rx UE successfully receives the SCI with resource reservation, the Rx UE can select resources according to the reservation in the SCI regardless of whether the transmission falls within the SL DRX-ON duration. This is also beneficial for mode-1 resource allocation, where the radio resources are controlled by the BS. In addition, the SCI-based resource reservation scheme can be enabled or disabled by (pre)configuration for individual resource pools and / or for individual resource allocation modes (mode-1 or mode-2 resource allocation).

[0071] Alternatively, the SL DRX configuration (transmission and / or reception patterns) can be per individual resource pool and / or per individual cast type. For example, especially for broadcast / groupcast services, the transmission patterns can be (pre)configured per individual resource pool, such that all UEs in the resource pool shall follow a common transmission and / or reception pattern for broadcast / groupcast communication.

[0072] FIG. 6 is an illustration of the complete SL DRX pattern determination of a UE according to an embodiment of the present application. The UE shall monitor the superposition of all transmission patterns from all its peer UEs. As shown in FIG. 6 , the UE shall monitor all periodicities indicated by the transmission patterns from all its peer UEs (i.e., peer UE 1 and peer UE 2).

[0073] If the SL DRX configuration includes a reception pattern, after the UE receives from its peer UE a specific set of reception resources indicating the time its peer UE will stay awake for reception, the UE considers those indicated reception resources as having a higher priority for SL data transmission and considers the remaining reception resources as having a lower priority for SL data transmission. In one implementation, the UE cannot use the low-priority transmission resources for new transmission or retransmission of MAC PDU to its peer UE. In another implementation, the UE cannot use the low-priority transmission resources for new transmission, but can use the low-priority transmission resources for retransmission.

[0074] To handle bursty data arrival, the transmission pattern and / or the reception pattern can be extended as needed. For example, a Tx UE can consider future transmission resources close to the most recent new transmission (e.g., the duration of which can be determined by a timer or a configured time gap whether it is close enough) as high-priority transmission resources, and this means that as long as the Tx UE newly transmits with the duration since the most recent new transmission, the Tx UE can extend the SL DRX active time to exceed the transmission pattern for that repetition period. Specifically, the mentioned new transmission can be dedicated to new transmission of a TB, or can refer to both new transmission and retransmission of a TB. Accordingly, a Rx UE should stay awake for a period of time after the most recent new reception (e.g., the duration of the additional awake time can be determined by a timer or a configured time gap). Specifically, the mentioned new reception can be dedicated to new transmission of a TB, or can refer to both new transmission and retransmission of a TB. If the Rx UE keeps receiving new data with an interval shorter than the duration since the last new data reception, the Rx UE can also keep extending its SL DRX active time.

[0075] In one implementation, the duration of the extension of the SL DRX active time can be modeled by an inactivity timer. The inactivity timer can be restarted whenever a UE transmits or receives data for new TB transmission or for both new TB transmission and TB retransmission. The extended duration ends when the corresponding inactivity timer expires. In one implementation, the transmission pattern / reception pattern can or can not be affected by the inactivity timer. However, as long as the inactivity timer is running, the UE should stay awake for possible transmission / reception.

[0076] In one embodiment, a UE can maintain separate inactivity timers for transmission and reception. The configuration of the inactivity timer can be part of the SL DRX configuration and can be exchanged with all peer UEs. In one example, if the SL DRX configuration of a Tx UE includes the transmission pattern of the UE, the SL DRX configuration can include the value of the inactivity timer for data transmission. With the configuration of the inactivity timer, if the duration since the last new transmission exceeds the value of the inactivity timer indicated by the Tx UE, the Rx UE (i.e., the peer UE) can know that the UE will not transmit more data. In one example, if the SL DRX configuration of a Rx UE includes the reception pattern of the UE, the SL DRX configuration can include the value of the inactivity timer for data reception. With the configuration of the inactivity timer, if the duration since the last new reception exceeds the value of the inactivity timer indicated by the Rx UE, the Tx UE (i.e., the peer UE) can know that the Rx UE will stop monitoring for data reception.

[0077] In one embodiment, the inactivity timer can be configured per UE, which means that a UE can set the same value of a single inactivity timer for different peer UEs in the SL DRX configuration. In another embodiment, for unicast communication, the inactivity timer can be configured per PC5-RRC connection (i.e., per source-destination pair) or per unicast link; for groupcast and broadcast communication, the inactivity timer can be configured per groupcast / broadcast service, e.g., a UE can maintain separate SL inactivity timers for each L2 destination associated with different groupcast / broadcast services. In another embodiment, different inactivity timers can be maintained separately, e.g., per unicast link, per groupcast / broadcast service, or per transmission and reception, and a UE should remain awake as long as any of the inactivity timers is running.

[0078] The SL DRX configuration of a UE can be configured according to the QoS requirements of the established SL Radio Bearers (SLRBs) from the UE to its peer UEs. In one embodiment, the SL DRX configuration can be determined by the upper layer (e.g., V2X layer) based on the QoS requirements of those QoS flows (e.g., identified by QoS profiles) and forwarded to the AS layer. Therefore, in the AS layer, the UE applies the SL DRX configuration provided by the upper layer. In one embodiment, each QoS flow or SLRB or QoS requirement (e.g., specified by a QoS profile) can be mapped to a suitable (partial) SL DRX configuration. Based on the supported QoS flows or SLRBs or QoS profiles, in the AS layer, the UE determines the suitable SL DRX configuration, or the part of the suitable SL DRX configuration (e.g., the suitable SL DRX cycle). If there are multiple QoS flows, multiple SL radio bearers, or multiple QoS requirements (QoS profiles) to be supported, the UE can apply separate SL DRX configuration(s) simultaneously for each SL QoS flow, SL radio bearer, or QoS profile. Alternatively, the UE can select one SL DRX configuration to meet the QoS requirements of all QoS flows \ SL radio bearers or QoS profiles, or support the highest priority or the most delay stringent QoS flow, SLRB, or QoS profile.

[0079] In addition to the static SL DRX configuration, a UE can configure multiple SL DRX configurations for its peer UEs and switch between these SL DRX configurations based on the traffic arrival status. For example, when data from a delay-sensitive SLRB or QoS flow becomes available, the UE can use a SL DRX configuration with short latency.

[0080] In one embodiment, when data from a delay-sensitive SLRB becomes available, the Tx UE can switch to use a SL DRX configuration with short latency; when the Rx UE receives data from a delay-sensitive SLRB (e.g., data belonging to a SL logical channel associated with the delay-sensitive SLRB), the Rx UE can automatically switch to use this SL DRX configuration to support short latency.

[0081] In one embodiment, if the Tx UE decides to switch to a different SL DRX configuration for a unicast link or for a groupcast / broadcast service, the Tx UE can send an explicit notification of the new SL DRX configuration to its peer UEs (e.g., via SCI or MAC CE or PC5-RRC message, such as RRCReconfigurationSidelink message).

[0082] In one embodiment, the Tx UE can use a counter or timer to support fallback switching from a short-latency SL DRX configuration to a long-latency SL DRX configuration. When the UE decides to fallback to a long-latency SL DRX configuration (e.g., no data is sent or received for a latency-sensitive SLRB for a period of time), the UE sends a notification of SL DRX configuration change to its peer UE (via SCI, MAC CE or PC5-RRC message). Upon receiving the message indicating the SL DRX configuration change, the Rx UE switches its SL DRX configuration accordingly to align with the selection of SL DRX configuration by the Tx UE.

[0083] FIG. 7 is an example of a flowchart of a method for supporting SL DRX operation according to an embodiment of the present application. In this embodiment, the method can be applied to and performed by any UE that is involved in SL communication with another UE.

[0084] In step S710, the UE maintains a SL DRX configuration, the SL DRX configuration including one of a transmission mode and a reception mode in which the UE is expected to transmit and receive with a peer UE.

[0085] In step S720, the UE exchanges the SL DRX configuration with the peer UE.

[0086] In step S730, based on the exchange of the SL DRX configuration, the UE determines when to transmit to or receive from the peer UE during the SL DRX operation.

[0087] In step S740, based on the determination, the UE performs the transmission to or the reception from the peer UE during the SL DRX operation.

[0088] Granularity of SL DRX configuration

[0089] The granularity of the SL DRX configuration can have multiple alternatives.

[0090] For example, for unicast communication, the SL DRX configuration (with the transmission mode) can be maintained per unicast link (identified by source UE ID, destination UE ID and link identifier), or per PC5-RRC connection (identified by source UE ID and destination UE ID), or per PC5 QoS flow (each PC5 QoS flow has its own QoS profile, which includes QoS requirements such as latency requirement, error rate requirement, etc.).

[0091] For groupcast or broadcast communications, the SL DRX configuration (with transmission pattern) can be maintained per groupcast / broadcast service (identified by destination ID). Alternatively, the SL DRX configuration (with transmission pattern) can be maintained per UE, which means that the UE can apply a single transmission pattern for transmission to all peer UEs. Alternatively, the SL DRX configuration for a groupcast / broadcast service can follow the SL DRX configuration associated with one or more of the QoS flows, SL radio bearers or QoS profiles used for that groupcast / broadcast service. Alternatively, for a groupcast / broadcast service, some SL DRX configurations (e.g., slot offset) are configured based on the L2 destination ID, some SL DRX configurations (e.g., SL DRX cycle or SL inactivity timer) are derived from the QoS flows, SL radio bearers or QoS profiles applied for the groupcast / broadcast service.

[0092] The SL DRX configuration for a groupcast / broadcast service can be configured statistically. In one embodiment, the SL DRX configuration for a groupcast / broadcast service can be configured in pre-configuration (e.g., for UEs outside the radio coverage of the BS). In another embodiment, the SL DRX configuration for a groupcast / broadcast service can be configured in acquired system information (e.g., for UEs operating in RRC_IDLE / RRC_INACTIVE / RRC_CONNECTED mode). In another embodiment, the SL DRX configuration for a groupcast / broadcast service can be configured in dedicated signaling (e.g., for UEs operating in RRC_CONNECTED mode). If the SL DRX configuration for a groupcast / broadcast service is configured statistically, the UEs can not need to exchange the SL DRX configuration for a groupcast / broadcast service via PC5 signaling. In contrast, for unicast services, the UEs can still need to exchange the SL DRX configuration with their peer UEs.

[0093] Update of SL DRX configuration

[0094] When a UE has an update on its SL DRX configuration, the UE shall inform the change to its peer UEs. Without the update of the information, the peer UEs will not be able to discover the UE according to the old (outdated) SL DRX configuration of the UE. As a result, the peer UEs can consider that a SL Radio Link Failure (RLF) has occurred (due to no HARQ feedback received from the UE) and release the PC5-RRC connection with the UE.

[0095] The question regarding SL DRX configuration update is when should the UE apply the new SL DRX configuration after transmitting the new SL DRX configuration to its peer UEs. The UE changing its SL DRX configuration should ensure that it is accessible by all peer UEs. In one embodiment, the UE changing its SL DRX configuration should remain awake according to both the new and old SL DRX configurations until all peer UEs have received the new SL DRX configuration, i.e., the UE can stop monitoring the old SL DRX configuration only after all peer UEs have received the new SL DRX configuration. In one embodiment, the UE changing its SL DRX configuration should keep monitoring SCI and / or PSSCH until all its peer UEs receive the new (updated) SL DRX configuration.

[0096] In SL relay scenario, the relay UE relays UL and DL traffic for remote UEs. For traffic from relay UE to remote UEs (DL relay data), the relay UE can transmit DL relay data to a limited number of remote UEs at a time (due to scheduling capability), therefore, those remote UEs not scheduled can need to remain awake to be scheduled, resulting in unnecessary power waste. For traffic from remote UEs to relay UE (UL relay data), simultaneous transmission from remote UEs to relay UE can cause serious collision when UL traffic load is heavy. To solve this problem of transmission collision and power inefficiency in SL relay scenario when traffic load is high, various schemes are proposed as follows.

[0097] In one embodiment, remote UEs are categorized into multiple subgroups. UEs in the same subgroup apply the same SL DRX configuration (with transmission pattern and / or reception pattern). UEs in different subgroups can also apply the same SL DRX configuration but can transmit and / or receive at different times, e.g., with the same or different timing offset for transmission and / or reception period. This enables UEs in different subgroups to transmit and / or receive at different times to eliminate collision caused by simultaneous transmission. In addition, remote UEs in subgroup 1 do not need to wake up at the transmission time or reception time of other subgroups. Furthermore, if the relay UE detects that the traffic load is light, it can dynamically configure multiple subgroups of remote UEs to use the same timing offset to increase resource utilization.

[0098] In one embodiment, the relay UE uses polling messages to indicate which remote UEs (in a sub-group) can proceed with SL transmission for UL relay data. The polled remote UEs can transmit, while the unpolled remote UEs should wait to transmit after being polled. In one example, the relay UE can transmit a signaling / message to request SL Buffer Status Report (BSR) from individual remote UEs, so that the relay UE can poll the remote UEs based on the buffer status information. In one example, individual remote UEs can transmit a SL BSR at a pre-configured time, e.g., at the beginning of the transmission mode of the remote UE’s SL DRX cycle. If the traffic load is light, the relay UE can poll all remote UEs (in a particular sub-group) to start their data transmission. If the traffic load is heavy, the relay UE can only poll some remote UEs at a time (e.g., remote UEs with the highest priority for relaying or the most delay-critical data). In one example, if the relay UE determines that it cannot schedule some remote UEs immediately in this SL DRX cycle due to a heavy traffic load, the relay UE can instruct (in a particular sub-group) these remote UEs to sleep for power saving, even though these remote UEs can have data to transmit. In one example, the relay UE can poll (in a particular sub-group) some remote UEs to transmit only those data that satisfy certain conditions. For example, the data allowed to transmit are in those logical channels with certain priority limit (e.g., higher than a threshold or with an arbitrary value of priority). For example, the data allowed to transmit are in those logical channels with Bj values within a certain range (e.g., greater than a threshold like 0 or with an arbitrary value). In one example, the relay UE can also indicate a certain set of time-frequency transmission resources for transmission for certain remote UEs (in a particular sub-group) to select.

[0099] In one embodiment, for a remote UE, the transmission mode and the reception mode do not overlap with each other to avoid half-duplex loss, i.e., when the relay UE transmits data to the remote UE, the relay UE cannot receive data. In one example, the start time of the transmission mode of a remote UE (or the start time of the reception mode of the relay UE for receiving relay data) is pre-configured. In one example, for a remote UE, the reception mode is right before the transmission time. This means, for remote UEs (of individual sub-groups), the relay UE first transmits DL relay data to the remote UEs. After completing the DL relay data transmission, the relay UE transmits a polling message to poll one or more remote UEs (in a sub-group) to start UL relay data transmission. In this way, the duration of the reception mode and the transmission mode can be flexible, i.e., if the relay UE completes the transmission of DL relay data earlier, the remote UEs can start the transmission of UL relay data earlier.

[0100] In one embodiment, in a SL relay scenario, the time that a relay UE transmits to or receives from its upstream relay UE (or gNB) does not overlap with the time that the relay UE transmits to or receives from its downstream UE (e.g., relay UE or remote UE).

[0101] In one embodiment, in a SL relay scenario, the DRX-ON duration for a relay UE in the Uu interface does not overlap with the transmission mode and / or reception mode of the relay UE in the PC5 interface to transmit to or receive from its downstream UE, which can be a relay UE (e.g., for multi-hop scenario) or a remote UE.

[0102] Accessing peer UE before exchanging SL DRX configuration

[0103] In SL DRX operation, a UE can not know the SL DRX configuration of a peer UE before exchanging its SL DRX configuration. That is, before UE A and UE B exchange their SL DRX configurations (e.g., during PC5-RRC connection setup procedure), UE A can not discover UE B if UE B applies SL DRX too early, because UE A does not know when UE B will monitor PSCCH / PSSCH. Therefore, UE A and UE B cannot establish PC5-RRC connection due to early SL DRX.

[0104] To solve this problem, each UE can be mandated to monitor a specific set of time- frequency radio resources to receive possible ping / discovery messages from a peer UE. The time- frequency radio resources to monitor by default can be a specific resource pool (e.g., default resource pool), or a specific bandwidth part (e.g., default SL bandwidth part), or a specific duration of each period (e.g., default DRX reception mode that a UE is to monitor).

[0105] There are different approaches to use the default monitoring resources. In one embodiment, a UE only monitors the default monitoring resources when it does not monitor the normal resources (i.e., time-frequency radio resources used for normal SL communication), e.g., for power saving. For example, if a UE cannot find its peer UE by sending a ping / discovery message in the normal resources, the UE can assume that its peer UE has started SL DRX operation and thus can switch to send a ping / discovery message on the default monitoring resources to find the peer UE. In another embodiment, a UE always monitors the default monitoring resources regardless of whether it is in SL DRX operation or whether it does not monitor the normal resources (i.e., time-frequency radio resources used for normal SL communication), e.g., for power saving. For example, when a UE wants to find its peer UE but has not acquired the SL DRX configuration of its peer UE, the UE can always find the peer UE by sending a ping / discovery message on the default monitoring resources, since each UE always monitors the default monitoring resources.

[0106] The above default monitoring resources can be pre-configured such that each UE can know the time-frequency location of the default monitoring resources even if the UE being searched is out of radio coverage of the BS or even if the peer UE that wants to find the UE is out of radio coverage of the BS.

[0107] In one embodiment, the default monitoring resources are shared by all UEs that support SL communication or SL DRX operation. Since there can be congestion / conflict in this default resource pool, to reduce the congestion / conflict, some transmission restrictions can be introduced for the default monitoring resources. In one embodiment, only when a UE A does not know the SL DRX configuration of a UE B, the UE A can send a ping / discovery message on the default monitoring resources to find the UE B. In another embodiment, the default monitoring resources can only be used for ping / discovery purpose but not for normal SL communication. In another embodiment, when a UE receives a ping / discovery message in the default monitoring resources, the UE can exchange SL DRX configuration with its peer UE. Thereafter, all SL communication between UEs is conducted outside of the default monitoring resources.

[0108] In one embodiment, the default monitoring resources of a UE can be derived using an algorithm based on the L2 source ID of the UE. For example, a UE A has an L2 source ID as ID_A. Then, the UE A can need to stay awake to periodically monitor SCI, where the periodicity can be pre-configured / default value, can be derived based on a given algorithm and ID_A to derive the starting offset.

[0109] In one embodiment, the default monitoring resource of a multicast / broadcast service can be derived by using an algorithm based on the L2 Destination ID of the multicast / broadcast service. For example, all UEs running a certain multicast / broadcast service shall monitor SCI periodically, where the periodicity of the SCI to be monitored can be derived from the SL DRX cycle associated with the QoS flow or SL radio bearer or QoS profile of the multicast / broadcast service, and where the starting offset of the SCI to be monitored can be derived from the L2 Destination ID of the multicast / broadcast service.

[0110] Partial sensing before transmission operation

[0111] For performing SL transmission, a UE can need to perform sensing on PSCCH / PSSCH to reduce the probability that the UE selects the same time-frequency radio resources as other UEs for transmission, which can cause collision / interference with other UEs. However, if the UE performs SL DRX operation, the UE can turn off its radio to save energy, thus will not have complete sensing information. Therefore, we need to find out the relationship between the sensing pattern and the transmission pattern of SL DRX operation to ensure that the UE can perform transmission without colliding / interfering with other peer UEs.

[0112] FIG. 8 is a schematic diagram illustrating the relationship between the sensing pattern and the transmission pattern according to an embodiment of the present application. As shown, the sensing pattern is before the transmission pattern to ensure that the UE has enough sensing results for resource selection. FIG. 8

[0113] FIG. 9 is a schematic diagram illustrating the relationship between the sensing pattern and the transmission pattern according to another embodiment of the present application. As shown, a UE (e.g., UE A) can be configured with a sensing pattern overlapping with the reception pattern. By configuring overlapping patterns for sensing and reception, the power consumption of UE A can be further reduced. FIG. 9

[0114] Regarding the detailed design of partial sensing, the first issue is the granularity of the sensing pattern of the Tx UE.

[0115] ​​In one embodiment, the granularity of the sensing mode can be per UE. In one example, the sensing mode is not associated with the transmission mode, and the Tx UE can follow a regular on-off mode to ensure that the Tx UE can transmit data at any time it wishes, or to ensure that the Tx UE can always transmit data with small delay whenever its data arrives. In one example, the Tx UE can select the per-UE sensing mode to ensure that the corresponding sensing result can enable the Tx UE to meet all QoS requirements of the highest priority and / or the most delay-critical SL data, and the QoS requirements can be determined by QoS metrics, e.g., packet delay budget of all established QoS flows, SL radio bearers, and / or SL logical channels. In one example, the per-UE sensing mode can be selected by the UE itself, or can be selected by the UE based on pre-configuration, acquired system information, or dedicated signaling from the network. In one example, the sensing mode is related to the timing of the last transmission. For example, if there is transmitting traffic, the SCI monitoring is denser (i.e., more slots are added to the list for sensing compared to the default sensing mode); or if there is no transmitting traffic, the SCI monitoring becomes sparse or even stops. In one example, the slots for the UE to monitor can change non-decreasingly if the arrived traffic increases within a given period or if the priority of the arrived traffic is high.

[0116] In another embodiment, the granularity of the sensing mode is per link or per PC5-RRC connection. In one example, the Tx UE can have a fixed sensing mode before the transmission mode starts in the SL DRX configuration for each link. This means that the Tx UE should ensure that it is ready for transmission for a particular link before the transmission mode for that link starts. In one example, if the UE exchanges its transmission mode with its peer UEs for SL DRX operation, the final DRX mode (or the time the UE needs to monitor) is the superposition of the transmission modes of all peer UEs and the sensing mode for preparing transmission to each peer UE. In one example, if the UE exchanges its reception mode with its peer UEs, the final DRX mode (or the time the UE needs to monitor) is the superposition of the reception mode of the UE and the sensing mode for preparing transmission to each peer UE. In other words, the sensing mode should be considered as part of the time the UE monitors.

[0117] A second question about sensing is whether the UE can skip sensing before the transmission mode if there is no SL data to transmit before the transmission mode starts, e.g., no SL data arrives within a fixed or configurable duration (or time window, or duration measured by a timer).

[0118] In one implementation, if there is no SL data to transmit in the upcoming transmission pattern, the UE can skip the sensing pattern for SCI monitoring. It aims to save sensing power more aggressively. In one example, if there is no SL data available for transmission in a fixed or configurable duration (or time window, or duration measured by a timer) before the start of the transmission pattern, the UE can consider that no transmission for the upcoming transmission pattern is likely to occur, and therefore, the UE can cancel the sensing for the upcoming transmission pattern. In another implementation, the UE can not skip the sensing even if there is no SL data available for transmission at the timing close to the start of the transmission pattern. In the previous implementation, if there is no SL data to transmit in the upcoming transmission pattern, the UE is allowed to skip the sensing pattern for the upcoming transmission pattern, so the UE can obtain the benefit of power saving. However, another issue is raised on what the UE should do if it skips the sensing but the SL data arrives at the UE later, and multiple solutions are proposed to solve the issue.

[0119] In one solution, the UE can only postpone the transmission of the late SL data to the transmission pattern of the next repetition period.

[0120] In one solution, the UE can check whether it can get enough sensing results before the end of the transmission pattern to the peer UE (e.g., in a fixed or configured duration). If yes, the UE can immediately perform the sensing and transmit the data before the end of the transmission pattern. Otherwise, if no, the UE can postpone the transmission to the transmission pattern of the next repetition period.

[0121] In one solution, when the late data arrives, the UE starts to perform the sensing, and selects a resource from the available candidate resources whenever the sensing results for n subframes / slots are available, where n can be a constant or can be configured by the network through pre-configuration, system information configuration, or dedicated signaling. The value of n can depend on the priority of the SL data (e.g., the SL logical channel priority of the data) or the (remaining) packet delay budget (PDB) of the SL data. In other words, when the SL data to be transmitted has a higher priority or a stricter delay requirement, the UE is allowed to transmit the data with fewer candidate resources. For example, n can be set to 0, e.g., for extremely high priority data.

[0122] In one option, the UE can be allowed to transmit with limited transmission without sufficient sensing results. In one example, the UE can select resources for transmission from an exceptional resource pool, a resource pool dedicated for partial sensing, or a resource pool for random resource selection before sufficient sensing results are obtained. In one example, the UE without sufficient sensing results can transmit with limited number of transmissions per resource pool, which can be similar to congestion control.

[0123] In one option, when the UE operates in SL DRX operation, there are separate transmission resource pools dedicated for periodic traffic and aperiodic traffic. If the UE has a delayed periodic traffic, the UE delays it to the subsequent multiple SL DRX cycles as the UE needs more time for sensing result collection. In contrast, if the UE has a delayed aperiodic traffic, the UE can wake up to collect sensing results as the time needed to collect sufficient sensing results for transmission is relatively short. In this alternative, a UE cannot transmit aperiodic traffic in the resource pool for periodic traffic and vice versa.

[0124] In one option, the sensing mode with different periodicity can be selected according to traffic status, traffic priority, and / or power mode. If there is no traffic and / or traffic with low priority and / or energy saving mode, a large sensing periodicity can be selected. When data arrives and / or traffic with high priority and / or full power mode, full sensing or small sensing periodicity can be selected. The traffic priority can be derived from the priority in SCI or from the priority (pre-)configured from upper layers. The power mode can be derived from the device type and / or (pre-)configured.

[0125] In the previous discussion, we discussed the UE behavior when sensing results are not available. In particular, the rule to determine whether the UE can proceed with resource selection for transmission can have multiple criteria.

[0126] In one example, the selection window should include candidate resources located in N TTIs / slots / subframes, or at least m candidate resources, where N and m can be determined by configuration. N or m can consider all candidate resources or only those that satisfy a criterion (e.g., RSRP below a threshold).

[0127] In one example, each candidate resource has its required sensing result. For example, for a candidate resource in slot n, the UE monitors {n-k*reservation period} slots, where k is an integer and the reservation period is used to check whether the candidate resource has been reserved by other UEs. For example, for a candidate resource in slot n, the UE monitors [n-k2, n-k1] slots to ensure that the candidate resource in slot n is not reserved by other UEs, where k1 and k2 are configured to determine the required sensing window. For example, if the UE monitors more than x% of the slots / TTIs in the sensing window [n-k2, n-k1], the candidate resource in slot n is considered to have an available sensing result, where x is a configurable parameter. The UE can apply one or more specific sensing patterns to ensure a low collision probability of the candidate resource in a specific slot / subframe, e.g., the candidate resource is available for selection if all or part of the corresponding required sensing pattern has been monitored.

[0128] Resource selection requirements

[0129] In legacy NR V2X, when a packet arrives in slot n, the resource selection window is in the window [n+T1, n+T2], where T2 is determined by the minimum T2 and the packet delay budget. Now, when we consider the SL DRX operation, T2 also depends on the transmission pattern, i.e., if the UE selects a candidate transmission resource from the transmission pattern, its peer UE (e.g., Rx UE) can have turned off its radio to save energy, resulting in a packet reception failure. Here, multiple schemes are proposed to address this issue.

[0130] In one scheme, the selected T2 should be within the configured transmission pattern, i.e., T2 is upper bounded by the duration of the transmission pattern in each repetition period. If T2 is very close to T1 and the resource selection window [n+T1, n+T2] is too narrow (e.g., less than a threshold), the UE can need to postpone the transmission to the next repetition period.

[0131] In another scheme, the Tx UE can ensure that its first TB transmission is within the transmission pattern. If the Rx UE receives the first TB transmission within the transmission pattern but fails to decode, the Rx UE can extend the DRX active time to allow the reception of TB retransmission. In other words, the Tx UE does not schedule all new transmissions and retransmission resources before the end of the transmission pattern in the current repetition period. In one example, if the number of TTIs / slots to the end of the transmission pattern is too short for the Tx UE to select a transmission resource for the first transmission of a TB, the Tx UE can postpone the transmission of the TB (e.g., MAC Protocol Data Unit (PDU)) to the next repetition period.

[0132] In one embodiment, for mode-1 scheduling, when the transmitting UE has SL grant for transmission, the transmitting UE considers only those destination UEs in the SL active time for transmission.

[0133] Further energy saving with wake-up / enter-sleep signal

[0134] To further reduce SL power consumption, the Tx UE can provide signaling or message to inform the Tx UE of no data reception. In one embodiment, the SL DRX configuration includes the transmission pattern, and the Tx UE sends an indication to inform the Rx UE about the Tx UE will not transmit in his own transmission resources configured in his own SL DRX configuration. After receiving the indication, the Rx UE can skip the monitoring of the corresponding reception resources from the Tx UE. In another embodiment, the SL DRX configuration includes the reception pattern, the Tx UE sends an indication to inform the Rx UE about the Tx UE will not transmit data in the reception resources configured in the peer UE’s SL DRX configuration. After receiving the indication, the Rx UE can skip the monitoring of the corresponding reception resources from the Tx UE. Further, upon receiving the indication, the Rx UE can wait for a period of time before stopping reception, which can ensure the completion of all ongoing HARQ processing on reception. Such waiting time can be controlled based on a (pre-)configured or specified timer or duration.

[0135] The signaling or message for informing the Rx UE of no data reception can have various forms. In one embodiment, the Rx UE does not expect any (more) data in the current repetition period of the transmission pattern of the peer UE. In one embodiment, upon receiving the indication, the receiving UE does not expect any reception from the Tx UE in the next / coming n transmission pattern periods, where n is an integer. In one embodiment, the indication indicates a time period (e.g., in units of slots, subframes, or frames, etc.) during which the Rx UE does not expect to receive any data from the Tx UE.

[0136] A specific set of time-frequency resources can be configured for the Tx UE to indicate the monitoring behavior of the Rx UE, e.g., to indicate whether the Rx UE needs to wake up to monitor the reception pattern in one or more repetition periods. If the Rx UE does not receive the indication, the Rx UE can skip the reception pattern in one or more repetition periods. In short, we can refer to the indication as a wake-up signal. Introducing the wake-up signal can have significant energy saving benefits, especially when the Tx UE has a low packet arrival rate for the individual repetition periods of the transmission pattern, or when the Rx UE has a long reception pattern for the individual repetition periods. For example, in the SL relay scenario, the relay UE can have multiple remote UEs to transmit data, therefore, the relay UE (e.g., Tx UE) can choose a relatively long transmission pattern, which means the remote UEs (e.g., Rx UEs) can need to monitor a longer reception pattern in the individual repetition periods. Another example is for delay-sensitive traffic, the repetition period of the reception pattern can be relatively short, therefore in the time domain, the reception pattern can occupy a large portion of the individual repetition periods. Or we can refer to the indication as a go-to-sleep signal. That is, if the Rx UE receives the go-to-sleep signal from the Tx UE, the Rx UE can sleep in the current or upcoming DRX pattern to save energy. Otherwise, if the Rx UE does not receive the go-to-sleep signal, the Rx UE should monitor the current or upcoming DRX pattern, e.g., according to the SL DRX operation, without the additional indication. Compared to the wake-up signal, the go-to-sleep signal is more suitable for the case where the packet arrival rate for the individual repetition periods of the SL DRX pattern is quite high (e.g., the probability is greater than 0.5). Based on the traffic arrival rate with its peer UE (e.g., Rx UE), the Tx UE can choose or be configured to use the wake-up or go-to-sleep signal. Whether to use the wake-up or go-to-sleep signal can be configured statically (e.g., (re)configured via a PC5-RRC message during SLRB setup or PC5-RRC connection setup, or in a PC5-RRC message such as a PC5-RRC reconfiguration message) or dynamically (e.g., configured via a MAC CE or indicated via SCI). For example, the Tx UE can dynamically indicate in the L1 control signaling (e.g., SCI or PSCCH) whether the signaling is used as a wake-up or go-to-sleep signal, or dynamically indicate whether the Rx UE needs to wake up for the Tx UE transmitting the signal in the current or upcoming repetition period of the transmission pattern. The time-frequency radio resources for the wake-up signal and / or the go-to-sleep signal can be reserved by a configured grant from a BS or a UE.

[0137] In another implementation, the Tx UE can choose or be configured to use the wake-up or go-to-sleep signal based on the traffic arrival rate with its peer UE.

[0138] The configuration of the wake-up or go-to-sleep signal can depend on how the SL DRX configuration works. More specifically, if the UE exchanges its transmission pattern with its peer UEs, the granularity of the wake-up or go-to-sleep signal can have the same granularity as the transmission pattern. For example, for unicast services, the wake-up or go-to-sleep signal can be configured per unicast link, or per PC5-RRC connection, or per UE (same granularity as the transmission pattern in the SL DRX operation mentioned earlier). For groupcast / broadcast services, the wake-up or go-to-sleep signal can be configured per groupcast / broadcast service (same granularity as the transmission pattern in the SL DRX operation mentioned earlier). Similarly, if the UE exchanges its reception pattern with its peer UEs for the SL DRX operation, the granularity of the wake-up or go-to-sleep signal can have the same granularity as the reception pattern. For example, for unicast services, the wake-up or go-to-sleep signal can be configured per unicast link, or per PC5-RRC connection, or per UE (same granularity as the SL DRX reception pattern).

[0139] The configuration of the resources for the wake-up or go-to-sleep signal can be achieved through various schemes.

[0140] In one scheme, the wake-up / sleep resources (i.e., resources configured for the wake-up / go-to-sleep signal) are configured per Tx UE. For example, for unicast services, the (independent) SCI used to transmit the wake-up or go-to-sleep signal in an applicable resource(s) includes the source UE ID and a bitmap to identify the destination UE for the unicast link. In this case, each Rx UE (i.e., the peer UE of the Tx UE) monitors the resources of the Tx UE to transmit the wake-up or go-to-sleep signal. If the Tx UE has very different transmission patterns for different links / peer UEs, it can only need to monitor the latest wake-up / sleep occasion(s) / resources before the start of the transmission pattern for the peer UE of the link. That is, the peer UE does not need to monitor all the wake-up / go-to-sleep occasions / resources for reception from the Tx UE. The peer UE only needs to monitor the wake-up / go-to-sleep resources that are the closest to the start of the transmission pattern. For groupcast or broadcast services, the wake-up / go-to-sleep resources can be right before or at the start of each transmission pattern. The Rx UE monitors the wake-up / go-to-sleep resources dedicated to the groupcast / broadcast service to determine whether there is a transmission in the transmission pattern.

[0141] In one scheme, wake-up / enter-sleep resources are configured for each Rx UE. For example, if a Tx UE has data to send to an Rx UE, the Tx UE sends a wake-up / enter-sleep signal in the wake-up / enter-sleep resource of the Rx UE. The Rx UE monitors its own wake-up / enter-sleep resource and wakes up as long as there is data to receive from any peer UE (e.g., Tx UE).

[0142] In one scheme, wake-up / enter-sleep resources are configured for each link / connection (e.g., for unicast) or for each destination ID (e.g., for groupcast / broadcast services). A UE can apply separate wake-up signals / enter-sleep resources for different links / connections and different groupcast / broadcast services.

[0143] In one scheme, wake-up / enter-sleep resources are configured for each cast mode. For unicast services, the content sent on the wake-up / enter-sleep resource can include the UE IDs of the destination UE and the source UE. For groupcast services, the content sent on the wake-up / enter-sleep resource can include a groupcast ID to identify the groupcast service, and optionally, the content can also indicate a subset of group members to keep awake for reception. For broadcast services, the content sent on the wake-up / enter-sleep resource can include a broadcast ID to identify a particular broadcast service.

[0144] In one scheme, wake-up / enter-sleep resources are configured in a hybrid manner for each UE and for each link / service configuration. For example, some wake-up / enter-sleep resources are dedicated to directional or unidirectional links (specific to Tx UE ID and Rx UE ID). Some wake-up / enter-sleep resources are dedicated to a Tx UE (e.g., for unicast, a Tx UE can use the wake-up / enter-sleep resource to wake up multiple peer UEs, or for groupcast, to wake up a subset of group members). Some wake-up / enter-sleep resources are dedicated to an Rx UE, and for example, if all Tx UEs have data to send to the Rx UE, they can send an indication on the Rx UE's wake-up / enter-sleep resource to keep the Rx UE awake. A UE can be configured with multiple Tx UE-specific, Rx UE-specific, link-specific, or cast type-specific wake-up / enter-sleep resources simultaneously.

[0145] In one approach, there can be no specific wake-up / go-to-sleep resource, i.e., all the needed information is included in the content of the wake-up / go-to-sleep signal. In one example, the transmitting UE can transmit a SCI or a MAC PDU (on PSSCH) that includes the UE ID of the Rx UE that should stay awake or sleep. In one example, the Tx UE can transmit a go-to-sleep signal to the Rx UE when the Tx UE no longer has data for the Rx UE to receive. In one implementation, the Tx UE can transmit the go-to-sleep signal during the sensing mode of the Rx UE to inform the Rx UE that the Tx UE will not transmit data to the Rx UE in the upcoming reception mode of the Rx UE.

[0146] When a UE is notified to stop data reception from its peer UE (e.g., the UE receives a go-to-sleep signal), the UE can also prefer to stop transmission to the peer UE (e.g., if there is no more data to transmit to the peer UE). In one implementation, the UE can reply with a response message to the peer UE (e.g., in the form of a go-to-sleep signal, a message carried by a SCI or a MAC CE). After the signaling exchange (for a period of time), the ongoing communication can be terminated (or can continue in the next repetition period of the transmission or reception mode). In one implementation, the UE can not need to reply with any response message, but just stop transmitting and receiving in the current repetition period of the transmission or reception mode.

[0147] Alternatively, when a UE is notified to stop data reception from its peer UE, the UE can still have data to transmit. In one implementation, the UE can continue transmitting data. In one implementation, the UE can stop transmitting even if there is still data waiting to be transmitted. The UE behavior when there is data to transmit can depend on the configuration, or the priority or delay requirement of the data waiting to be transmitted.

[0148] FIG. 10is a diagram illustrating exemplary applications of a wake-up signal during SL DRX operation according to embodiments of the disclosure. A Tx UE is configured with Tx UE-specific wake-up resources on which the Tx UE can indicate which peer UEs (i.e., Rx UEs) have data to receive. The transmission pattern is repeated every cycle. In cycle 1, the Tx UE sends a wake-up signal to indicate that both Rx UE 1 and Rx UE 2 have data to receive. In response to the wake-up signal, both Rx UEs should remain awake during the configured SL DRX cycle. In cycle 2, only Rx UE 2 has data to receive, therefore, the Tx UE sends a wake-up signal to only Rx UE 2, so that Rx UE 2 remains awake for reception. In cycle 3, no Rx UE has data to receive, therefore, no wake-up signal is sent at all, so that both Rx UE 1 and Rx UE 2 can turn off their radios during the SL DRX reception cycle to save power.

[0149] Coexistence of UEs with different SL DRX capabilities

[0150] SL DRX will be a new feature in 3GPP Release 17. An issue to be considered is how an R17 UE supporting SL DRX coexists with an R16 UE not supporting SL DRX.

[0151] Without any specific design, when an R16 UE communicates with an R17 UE supporting and activated SL DRX operation, the R16 UE can send data to the R17 UE when the R17 UE is not in the SL active time. Since the R17 UE is sleeping, the R16 UE cannot receive the sidelink HARQ feedback from the R17 UE. As a result, the R16 UE will retransmit the packet, or even consider the link with the R17 UE is broken. Specifically, when the number of consecutive un-received SL HARQ feedbacks is higher than a threshold, the transmitting UE (i.e., R16 UE) should consider the sidelink with the R17 UE is broken, thus releasing the corresponding PC5-RRC connection with the R17 UE. To avoid this abnormal issue when introducing the SL DRX feature, the issue of coexistence of R16 UE with R17 UE supporting SL DRX should be addressed.

[0152] For sidelink unicast transmission, this can be addressed by UE capability exchange. For example, at PC5-RRC connection setup, two UEs can exchange their UE capabilities. After R17 UE and R16 UE exchange UE capabilities, the R17 UE will not operate SL DRX to enable it to communicate normally with the R16 UE, i.e. there is no risk of the R17 UE missing transmitted packets since the R17 UE remains awake after receiving the UE capability from its peer UE.

[0153] However, for connectionless groupcast or broadcast communication, it is not possible for individual UEs to exchange UE capabilities with all peer UEs or group members monitoring the same groupcast or broadcast service. Therefore, in the case of groupcast and broadcast, additional methods other than UE capability exchange are needed to cope with the coexistence of UEs supporting SL DRX and UEs not supporting SL DRX.

[0154] In addition to UE capability exchange, there are multiple solutions to address the coexistence issue.

[0155] In one embodiment, separate resource pools are configured for UEs supporting SL DRX and UEs not supporting SL DRX. In this embodiment, UEs not supporting SL DRX are always required to monitor the resource pool not supporting SL DRX. In contrast, what resource pool a UE supporting SL DRX should apply depends on the mode of its peer UE (for unicast) or the service of interest (for groupcast / broadcast).

[0156] In one example of separate resource pools for UEs with / without SL DRX capability, a UE supporting SL DRX operates SL DRX in the resource pool supporting SL DRX. That is, the UE can apply its SL DRX configuration on top of the Rx resource pool supporting SL DRX.

[0157] In one example of separate resource pools for UEs with / without SL DRX capability, a UE supporting SL DRX should remain awake during the period of the Rx resource pool supporting SL DRX. In this example, the UE can turn off the radio to save energy when the UE is outside the period of the Rx resource pool supporting SL DRX. In this example, the SL DRX operation is defined by the time configuration of the multiple resource pools supporting and not supporting SL DRX.

[0158] In one example of separate resource pools for SL DRX capable / SL DRX not capable UEs, for SL unicast, if the peer UE is a SL DRX not capable UE, the SL DRX capable UE shall apply the SL DRX not supported transmission and / or reception resource pool to communicate with the peer UE. Conversely, if the peer UE also supports SL DRX, the SL DRX capable UE then applies the SL DRX supported transmission / reception resource pool to communicate with the peer UE.

[0159] In one example of separate resource pools for SL DRX capable / SL DRX not capable UEs, for SL groupcast / broadcast, each groupcast or broadcast service is associated with an indicator indicating whether the groupcast / broadcast service applies SL DRX or not.

[0160] There are multiple ways to configure the SL DRX enable / disable indicator for a groupcast / broadcast service.

[0161] In one implementation, the indicator is provided by upper layer, e.g., the V2X layer informs the AS layer of the UE about whether the groupcast / broadcast service is dedicated for SL DRX capable UEs (e.g., whether the groupcast / broadcast service will apply SL DRX operation) or is applicable for both SL DRX capable and SL DRX not capable UEs.

[0162] In one implementation, whether a SL groupcast / broadcast service enables SL DRX is determined by a (pre-)configured rule in the AS layer, which can also take into account the QoS profile / parameters of the groupcast / broadcast. For example, if the groupcast / broadcast service has very tight delay budget, the UE can determine that the groupcast / broadcast service is SL DRX disabled, so that short delay can be guaranteed. Another example is if the purpose of the groupcast / broadcast service is power efficient operation, e.g., for long time regular data collection, the delay budget can be quite long, so SL DRX function should be enabled. The (pre-)configured AS rule can be specified in pre-configuration (e.g., for out-of-coverage UEs), in SIB (e.g., for in-coverage UEs), or optionally via dedicated signaling (e.g., for RRC_CONNECTED UEs) for the UE to determine whether the groupcast / broadcast service should be operated in SL DRX mode or not.

[0163] There are also multiple implementations on how to use the SL DRX enable / disable indicator for a groupcast / broadcast service.

[0164] In one embodiment, if a SL groupcast / broadcast service is SL DRX enabled, SL DRX capable UEs apply Tx / Rx resource pools dedicated for SL DRX for groupcast / broadcast transmission / reception. Conversely, SL DRX incapable UEs can also apply Rx resource pools dedicated for SL DRX for receiving packets for this groupcast / broadcast service. If it is further specified that all those SL DRX capable UEs should remain awake during the entire period of Tx / Rx resource pools dedicated for SL DRX, SL DRX incapable UEs can also transmit data in these resource pools dedicated for SL DRX.

[0165] In one embodiment, if a SL groupcast / broadcast service is SL DRX enabled, SL DRX incapable UEs do not support the SL groupcast / broadcast service. That is, only UEs that support SL DRX operation can support SL DRX enabled SL groupcast / broadcast service.

[0166] In one embodiment, if a SL groupcast / broadcast service is SL DRX disabled, UEs support the SL groupcast / broadcast service, regardless of whether the UEs support SL DRX operation or not.

[0167] As mentioned above, we can configure separate resource pools such that UEs in some resource pools do not apply SL DRX, while UEs in another part of resource pools apply SL DRX.

[0168] In addition to separate resource pools, another possible embodiment is that a resource pool is shared by UEs that perform SL DRX operation and UEs that do not support SL DRX operation. Here we refer to this as a shared resource pool. Both SL DRX capable UEs and SL DRX incapable UEs can use this shared resource pool for sidelink communication.

[0169] In one embodiment regarding how to use the shared resource pool, all resource pools that SL DRX incapable UEs can use are shared resource pools. That is, SL DRX incapable UEs can use each applicable resource pool to communicate with SL DRX capable / SL DRX incapable UEs, or to support SL DRX activated / deactivated groupcast / broadcast service.

[0170] In one embodiment regarding how to use the shared resource pool, for the UE without SL DRX capability, some resource pools are shared resource pools, while some resource pools are not shared resource pools, e.g., dedicated for SL DRX forbidden operation. For example, when the UE without SL DRX capability wants to communicate with the UE with SL DRX capability or support the groupcast / broadcast service with SL DRX activated, it uses the shared resource pool. Otherwise, the UE without SL DRX capability uses other resource pools which do not support SL DRX for sidelink communication.

[0171] In one embodiment regarding how to use the shared resource pool, if the peer UE is also the UE with SL DRX capability, or if the concerned groupcast / broadcast service is operating SL DRX, the UE with SL DRX capability performs SL DRX operation when using the shared resource pool. If the peer UE is the UE without SL DRX capability, or if the concerned groupcast / broadcast service is not working in SL DRX mode, the UE with SL capability does not perform SL DRX when using the shared resource.

[0172] In one example regarding how to use the shared resource pool, if the peer UE is also the UE with SL DRX capability, or if the concerned groupcast / broadcast service is operating SL DRX, the UE with SL DRX capability does not use the shared resource pool for sidelink communication. In other words, the UE with SL DRX capability can only use the shared resource pool when it wants to deactivate SL DRX operation to coexist with the peer UE which does not support SL DRX or support the groupcast / broadcast service which is not working in SL DRX mode. If the UE with SL DRX capability wants to perform SL DRX for its sidelink communication, it uses other resource pools dedicated for SL DRX operation. For example, if the UE with SL DRX capability wants to communicate with another UE with SL DRX capability, they apply Tx / Rx resource pools which support SL DRX, and they can perform SL DRX operation (e.g., to intermittently monitor the sidelink control channel in a certain time pattern). In contrast, if the UE with SL DRX capability wants to communicate with the UE without SL DRX capability, they apply shared Tx / Rx resource pools which do not support SL DRX, and within the shared resource pool, the UE with SL DRX capability needs to continuously monitor the sidelink control channel.

[0173] In one example regarding how to use the shared resource pool, the time period of the shared resource pool is aligned with the (common) broadcast / groupcast SL DRX active time of the groupcast / broadcast service. With this resource pool configuration, both SL DRX capable UEs and non-SL DRX capable UEs can properly monitor the same broadcast / groupcast service. This is because by aligning the time period of the shared resource pool with the common broadcast / groupcast SL DRX active time of the groupcast / broadcast service, the transmission / reception time of the non-SL DRX capable UEs is reshaped as if the non-SL DRX capable UEs perform SL DRX operation as the SL DRX capable UEs do.

[0174] It should be understood that any particular order or hierarchy of steps in any disclosed processes is an example of an example approach. Based on design preferences, it is understood that the particular order or hierarchy of steps in the processes can be rearranged, while remaining within the scope of the present disclosure. The accompanying method claims present elements of the various steps in a sample order, and are not meant to be limited to the specific order or hierarchy presented.

[0175] The ordinal indicators, such as first, second, etc., as used in the claims are used herein for distinguishing between two elements having a same name or for disambiguating the claims during examination and are not meant to impose an order of importance.

Claims

1. An energy-saving enhancement method for sidelink communication, the method comprising: The user equipment maintains a sidelink discontinuous reception configuration, wherein the sidelink discontinuous reception configuration includes one of the transmission mode and reception mode that the user equipment expects to transmit and receive with peer user equipment. For multicast or broadcast communication, a separate default sidelink discontinuous reception configuration is maintained, or the sidelink discontinuous reception configuration is maintained for each group of quality of service streams or each group of quality of service stream profiles. Exchange the side link discontinuous reception configuration with the peer user equipment; Based on the switching of the sidelink discontinuous reception configuration, determine when to transmit to or receive from the peer user equipment during sidelink discontinuous reception operation; and Based on the determination, transmission to or reception from the peer user equipment is performed during the side link discontinuous reception operation.

2. The energy-saving enhancement method for side link communication as described in claim 1, characterized in that, The transmission mode includes information indicating multiple time-frequency radio resources for the user equipment to transmit to the peer user equipment, and the reception mode includes information indicating multiple time-frequency radio resources for the user equipment to receive from the peer user equipment.

3. The energy-saving enhancement method for side link communication as described in claim 2, characterized in that, The information includes the sidelink discontinuous reception offset, the sidelink discontinuous reception on-time duration, and the sidelink discontinuous reception period.

4. The energy-saving enhancement method for side link communication as described in claim 1, characterized in that, For unicast communication, the sidelink discontinuous reception configuration is maintained for each unicast link or for each PC5 radio resource control connection.

5. The energy-saving enhancement method for side link communication as described in claim 1, characterized in that, For multicast or broadcast communications, the sidelink discontinuous reception configuration is maintained for each multicast or broadcast service identified by the Layer 2 destination identifier, or for each PC5 quality of service flow associated with quality of service requirements.

6. The energy-saving enhancement method for side link communication as described in claim 1, characterized in that, The sidelink discontinuous reception configuration is maintained for each user equipment, and the user equipment applies the same sidelink discontinuous reception configuration to sidelink communications with all peer user equipments.

7. The energy-saving enhancement method for side link communication as described in claim 1, characterized in that, The sidelink discontinuous reception configuration is configured based on pre-configuration, system information received from the base station, or dedicated signaling from the base station.

8. The energy-saving enhancement method for sidelink communication as described in claim 1, further comprising: Before exchanging the side link discontinuous reception configuration, monitor the time-frequency radio resource set used to receive discovery messages from the peer user equipment.

9. The energy-saving enhancement method for side link communication as described in claim 8, characterized in that, The time-frequency radio resource set is configured based on pre-configuration, system information received from the base station, or the layer 2 destination identifier of the user equipment.

10. The energy-saving enhancement method for side link communication as described in claim 1, characterized in that, The transmission performed includes transmitting a first transport block to the peer user equipment within the transmission mode.

11. The energy-saving enhancement method for sidelink communication as described in claim 1, further comprising: Sensing is performed on the physical-side link control channel before transmission to the peer user equipment.

12. The energy-saving enhancement method for sidelink communication as described in claim 11, further comprising: Before transmitting to the peer user equipment, receiving from the peer user equipment is performed, wherein the receiving and sensing overlap in the time and frequency domains.

13. An energy-efficient enhanced user equipment for sidelink communication, comprising: A wireless transceiver is used to perform sending and receiving with peer user equipment. as well as The controller, coupled to the wireless transceiver, is used for: Maintain the sidelink discontinuous reception configuration, wherein the sidelink discontinuous reception configuration includes one of the transmission mode and reception mode in which the user equipment is expected to transmit and receive with the peer user equipment. For multicast or broadcast communication, maintain a separate default sidelink discontinuous reception configuration, or maintain the sidelink discontinuous reception configuration for each group of quality of service streams or each group of quality of service stream profiles. The sidelink discontinuous reception configuration is exchanged with the peer user equipment via the wireless transceiver; Based on the switching of the sidelink discontinuous reception configuration, it is determined when to transmit to or receive from the peer user equipment during the sidelink discontinuous reception operation. as well as Based on the determination, transmission to or reception from the peer user equipment is performed during the side link discontinuous reception operation.

14. The user equipment as claimed in claim 13, characterized in that, The transmission mode includes information indicating multiple time-frequency radio resources for the user equipment to transmit to the peer user equipment, and the reception mode includes information indicating multiple time-frequency radio resources for the user equipment to receive from the peer user equipment.

15. The user equipment as claimed in claim 14, characterized in that, The information includes the sidelink discontinuous reception offset, the sidelink discontinuous reception on-time duration, and the sidelink discontinuous reception period.

16. The user equipment as claimed in claim 13, characterized in that, For unicast communication, the sidelink discontinuous reception configuration is maintained for each unicast link or for each PC5 radio resource control connection; or for multicast or broadcast communication, the sidelink discontinuous reception configuration is maintained for each multicast or broadcast service identified by a Layer 2 destination identifier, or for each PC5 quality of service stream associated with a quality of service requirement; or the sidelink discontinuous reception configuration is maintained for each user equipment, and the user equipment applies the same sidelink discontinuous reception configuration to sidelink communications with all peer user equipments.

17. The user equipment as claimed in claim 13, characterized in that, The sidelink discontinuous reception configuration is configured based on pre-configuration, system information received from the base station, or dedicated signaling from the base station.

18. The user equipment as claimed in claim 13, characterized in that, Before exchanging the sidelink discontinuous reception configuration, the controller is also configured to monitor the time-frequency radio resource set for receiving discovery messages from the peer user equipment via the radio transceiver; wherein the time-frequency radio resource set is configured based on pre-configuration, system information received from the base station, or the layer 2 destination identifier of the user equipment.

19. The user equipment as claimed in claim 13, characterized in that, The transmission performed includes transmitting a first transport block to the peer user equipment within the transmission mode.

20. The user equipment as claimed in claim 13, characterized in that, Before sending data to the peer user equipment, the controller is also configured to perform one or both of the following: Sensing is performed on the physical-side cross-link control channel; and To receive data from the peer user equipment; When sensing and receiving are performed simultaneously, the receiving and sensing overlap in the time domain and frequency domain.

Images