Patent Description:
3GPP document R2-<NUM> discloses on- and off-durations in sidelink and a mechanism of aligning the sidelink DRX wake-up time among the UEs communicating with each other.

A method for a User Equipment (UE) to configure sidelink discontinuous reception (DRX) for sidelink groupcast communication associated with a group and a corresponding User Equipment are disclosed and are defined in the independent claims. The dependent claims define preferred embodiments thereof.

The exemplary wireless communication systems and devices described below employ a wireless communication system, supporting a broadcast service. Wireless communication systems are widely deployed to provide various types of communication such as voice, data, and so on. These systems may be based on code division multiple access (CDMA), time division multiple access (TDMA), orthogonal frequency division multiple access (OFDMA), 3GPP LTE (Long Term Evolution) wireless access, 3GPP LTE-A or LTE-Advanced (Long Term Evolution Advanced), 3GPP2 UMB (Ultra Mobile Broadband), WiMax, 3GPP NR (New Radio), or some other modulation techniques.

In particular, the exemplary wireless communication systems and devices described below may be designed to support one or more standards such as the standard offered by a consortium named "3rd Generation Partnership Project" referred to herein as 3GPP, including: <NPL>; <NPL>"; <NPL>"; <NPL>"; <NPL>"; and<NPL>. The standards and documents listed above are hereby expressly incorporated by reference in their entirety.

<FIG> shows a multiple access wireless communication system according to one embodiment of the invention. An access network <NUM> (AN) includes multiple antenna groups, one including <NUM> and <NUM>, another including <NUM> and <NUM>, and an additional including <NUM> and <NUM>. In <FIG>, only two antennas are shown for each antenna group, however, more or fewer antennas may be utilized for each antenna group. Access terminal <NUM> (AT) is in communication with antennas <NUM> and <NUM>, where antennas <NUM> and <NUM> transmit information to access terminal <NUM> over forward link <NUM> and receive information from access terminal <NUM> over reverse link <NUM>. Access terminal (AT) <NUM> is in communication with antennas <NUM> and <NUM>, where antennas <NUM> and <NUM> transmit information to access terminal (AT) <NUM> over forward link <NUM> and receive information from access terminal (AT) <NUM> over reverse link <NUM>. In a FDD system, communication links <NUM>, <NUM>, <NUM> and <NUM> may use different frequency for communication. For example, forward link <NUM> may use a different frequency then that used by reverse link <NUM>.

In communication over forward links <NUM> and <NUM>, the transmitting antennas of access network <NUM> may utilize beamforming in order to improve the signal-to-noise ratio of forward links for the different access terminals <NUM> and <NUM>. Also, an access network using beamforming to transmit to access terminals scattered randomly through its coverage causes less interference to access terminals in neighboring cells than an access network transmitting through a single antenna to all its access terminals.

An access network (AN) may be a fixed station or base station used for communicating with the terminals and may also be referred to as an access point, a Node B, a base station, an enhanced base station, an evolved Node B (eNB), a network node, a network, or some other terminology. An access terminal (AT) may also be called user equipment (UE), a wireless communication device, terminal, access terminal or some other terminology.

<FIG> is a simplified block diagram of an embodiment of a transmitter system <NUM> (also known as the access network) and a receiver system <NUM> (also known as access terminal (AT) or user equipment (UE)) in a MIMO system <NUM>. At the transmitter system <NUM>, traffic data for a number of data streams is provided from a data source <NUM> to a transmit (TX) data processor <NUM>.

Preferably, each data stream is transmitted over a respective transmit antenna. TX data processor <NUM> formats, codes, and interleaves the traffic data for each data stream based on a particular coding scheme selected for that data stream to provide coded data.

The coded data for each data stream may be multiplexed with pilot data using OFDM techniques. The pilot data is typically a known data pattern that is processed in a known manner and may be used at the receiver system to estimate the channel response. The multiplexed pilot and coded data for each data stream is then modulated (i.e., symbol mapped) based on a particular modulation scheme (e.g., BPSK, QPSK, M-PSK, or M-QAM) selected for that data stream to provide modulation symbols. The data rate, coding, and modulation for each data stream may be determined by instructions performed by processor <NUM>.

At receiver system <NUM>, the transmitted modulated signals are received by NR antennas 252a through 252r and the received signal from each antenna <NUM> is provided to a respective receiver (RCVR) 254a through 254r. Each receiver <NUM> conditions (e.g., filters, amplifies, and downconverts) a respective received signal, digitizes the conditioned signal to provide samples, and further processes the samples to provide a corresponding "received" symbol stream.

Turning to <FIG>, this figure shows an alternative simplified functional block diagram of a communication device according to one embodiment of the invention. As shown in <FIG>, the communication device <NUM> in a wireless communication system can be utilized for realizing the UEs (or ATs) <NUM> and <NUM> in <FIG> or the base station (or AN) <NUM> in <FIG>, and the wireless communications system is preferably the NR system. The communication device <NUM> may include an input device <NUM>, an output device <NUM>, a control circuit <NUM>, a central processing unit (CPU) <NUM>, a memory <NUM>, a program code <NUM>, and a transceiver <NUM>. The control circuit <NUM> executes the program code <NUM> in the memory <NUM> through the CPU <NUM>, thereby controlling an operation of the communications device <NUM>. The communications device <NUM> can receive signals input by a user through the input device <NUM>, such as a keyboard or keypad, and can output images and sounds through the output device <NUM>, such as a monitor or speakers. The transceiver <NUM> is used to receive and transmit wireless signals, delivering received signals to the control circuit <NUM>, and outputting signals generated by the control circuit <NUM> wirelessly. The communication device <NUM> in a wireless communication system can also be utilized for realizing the AN <NUM> in <FIG>.

<FIG> is a simplified block diagram of the program code <NUM> shown in <FIG> in accordance with one embodiment of the invention. In this embodiment, the program code <NUM> includes an application layer <NUM>, a Layer <NUM> portion <NUM>, and a Layer <NUM> portion <NUM>, and is coupled to a Layer <NUM> portion <NUM>. The Layer <NUM> portion <NUM> generally performs radio resource control. The Layer <NUM> portion <NUM> generally performs link control. The Layer <NUM> portion <NUM> generally performs physical connections.

3GPP has been developing standards for sidelink as a tool for UE to UE direct communication required in various use cases since LTE. The first standard for NR sidelink is to be completed in Rel-<NUM> by the work item "<NUM> V2X with NR sidelink" where solutions including NR sidelink are being specified mainly for vehicle-to-everything (V2X) while they can also be used for public safety when the service requirement can be met.

Meanwhile, the necessity of NR sidelink enhancement has been identified. For V2X and public safety, the service requirements and operation scenarios are not fully supported in Rel-<NUM> due to the time limitation, and SA works are ongoing on some enhancement in Rel-<NUM> such as architecture enhancements for 3GPP support of advanced V2X services - Phase <NUM> (FS_eV2XARC_Ph2) and System enhancement for Proximity based Services in 5GS (FS_5G_ProSe). In addition, other commercial use cases related to NR sidelink are being considered in SA WGs via several work/study items such as Network Controlled Interactive Service (NCIS), Gap Analysis for Railways (MONASTERYEND), Enhanced Relays for Energy efficiency and Extensive Coverage (REFEC), Audio-Visual Service Production (AVPROD). In order to provide a wider coverage of NR sidelink for these use cases and be able to provide the radio solutions in accordance with the progress in SA WGs, it is necessary to specify enhancements to NR sidelink in TSG RAN.

TSG RAN started discussions in RAN#<NUM> to identify the detailed motivations and work areas for NR sidelink enhancements in Rel-<NUM>. Based on the latest summary in RP-<NUM>, significant interest has been observed for the several motivations including the following:.

While several work areas have been identified in the discussion, some important principles were also discussed regarding the 3GPP evolution for NR sidelink. In dealing with different use cases in the evolution of NR sidelink, WGs should strive to achieve maximum commonality between commercial, V2X, and Critical Communication usage of sidelink in order to avoid duplicated solutions and maximize the economy of scale. In addition, enhancements introduced in Rel-<NUM> should be based on the functionalities specified in Rel-<NUM>, instead of designing the fundamental NR sidelink functionality again in Rel-<NUM>.

The objective of this work item is to specify radio solutions that can enhance NR sidelink for the V2X, public safety and commercial use cases.

Enhancements introduced in Rel-<NUM> should be based on the functionalities specified in Rel-<NUM>, and Rel-<NUM> sidelink should be able to coexist with Rel-<NUM> sidelink in the same resource pool. This does not preclude the possibility of operating Rel-<NUM> sidelink in a dedicated resource pool. The solutions should cover both the operating scenario where the carrier(s) is/are dedicated to ITS and the operating scenario where the carrier(s) is/are licensed spectrum and also used for NR Uu/LTE Uu operation.

The solutions should support the network control of NR sidelink as in Rel-<NUM>, i.e., NR Uu controls NR sidelink using Layer <NUM> and Layer <NUM> signalling and LTE Uu controls NR sidelink using Layer <NUM> signalling.

In ITS carriers, it is assumed that any co-channel coexistence requirements and mechanisms of NR sidelink with non-3GPP technologies will not be defined by 3GPP.

3GPP TS <NUM> introduced the concept of discontinuous reception as follows:.

The PDCCH monitoring activity of the UE in RRC connected mode is governed by DRX, BA, and DCP.

When DRX is configured, the UE does not have to continuously monitor PDCCH. DRX is characterized by the following:.

3GPP TS <NUM> specified operation of discontinuous reception as follows:.

The MAC entity may be configured by RRC with a DRX functionality that controls the UE's PDCCH monitoring activity for the MAC entity's C-RNTI, CI-RNTI, CS-RNTI, INT-RNTI, SFI-RNTI, SP-CSI-RNTI, TPC-PUCCH-RNTI, TPC-PUSCH-RNTI, TPC-SRS-RNTI, and AI-RNTI. When using DRX operation, the MAC entity shall also monitor PDCCH according to requirements found in other clauses of this specification. When in RRC_CONNECTED, if DRX is configured, for all the activated Serving Cells, the MAC entity may monitor the PDCCH discontinuously using the DRX operation specified in this clause; otherwise the MAC entity shall monitor the PDCCH as specified in TS <NUM> [<NUM>]. NOTE <NUM>: If Sidelink resource allocation mode <NUM> is configured by RRC, a DRX functionality is not configured.

RRC controls DRX operation by configuring the following parameters:.

Serving Cells of a MAC entity may be configured by RRC in two DRX groups with separate DRX parameters. When RRC does not configure a secondary DRX group, there is only one DRX group and all Serving Cells belong to that one DRX group. When two DRX groups are configured, each Serving Cell is uniquely assigned to either of the two groups. The DRX parameters that are separately configured for each DRX group are: drx-onDurationTimer, drx-InactivityTimer. The DRX parameters that are common to the DRX groups are: drx-SlotOffset, drx-RetransmissionTimerDL, drx-RetransmissionTimerUL, drx-LongCycleStartOffset, drx-ShortCycle (optional), drx-ShortCycleTimer (optional), drx-HARQ-RTT-TimerDL, and drx-HARQ-RTT-TimerUL. When a DRX cycle is configured, the Active Time for Serving Cells in a DRX group includes the time while:.

Access Preamble (as described in clauses <NUM>. <NUM> and <NUM>.

When DRX is configured, the MAC entity shall:.

implementation whether to report this CSI multiplexed with other UCI(s). Regardless of whether the MAC entity is monitoring PDCCH or not on the Serving Cells in a DRX group, the MAC entity transmits HARQ feedback, aperiodic CSI on PUSCH, and aperiodic SRS defined in TS <NUM> [<NUM>] on the Serving Cells in the DRX group when such is expected.

The MAC entity needs not to monitor the PDCCH if it is not a complete PDCCH occasion (e.g. the Active Time starts or ends in the middle of a PDCCH occasion).

3GPP TS <NUM> specified configuration of discontinuous reception as follows:.

The purpose of this procedure is to modify an RRC connection, e.g. to establish/modify/release RBs, to perform reconfiguration with sync, to setup/modify/release measurements, to add/modify/release SCells and cell groups. As part of the procedure, NAS dedicated information may be transferred from the Network to the UE.

The purpose of this procedure is to provide synchronisation information to a UE.

The purpose of this procedure is to modify a PC5-RRC connection, e.g. to establish/modify/release sidelink DRBs, to configure NR sidelink measurement and reporting, to configure sidelink CSI reference signal resources and CSI reporting latency bound.

The UE may initiate the sidelink RRC reconfiguration procedure and perform the operation in sub-clause <NUM>. <NUM> on the corresponding PC5-RRC connection in following cases:.

In RRC_CONNECTED, the UE applies the NR sidelink communications parameters provided in RRCReconfiguration (if any). In RRC_IDLE or RRC_INACTIVE, the UE applies the NR sidelink communications parameters provided in system information (if any). For other cases, UEs apply the NR sidelink communications parameters provided in SidelinkPreconfigNR (if any). When UE performs state transition between above three cases, the UE applies the NR sidelink communications parameters provided in the new state, after acquisition of the new configurations. Before acquisition of the new configurations, UE continues applying the NR sidelink communications parameters provided in the old state.

The IE DRX-Config is used to configure DRX related parameters.

To perform unicast mode of V2X communication over PC5 reference point, the UE is configured with the related information as described in clause <NUM>.

Figure <NUM>. <NUM>-<NUM> shows the layer-<NUM> link establishment procedure for unicast mode of V2X communication over PC5 reference point.

This solution is for "Key Issue #<NUM>: Support of QoS aware NR PC5 power efficiency for pedestrian UEs".

In road safety as well as public safety use cases, Pedestrian UEs are often involved in PC5 groupcast or broadcast communication in connectionless manner. One pedestrian UE may need to listen to various PC5 Tx UEs in proximity without knowing about Tx UEs in advance. Thus, possible DRX operation for PC5 Rx UE needs to cope with various and random Tx UEs present in proximity. PC5 Tx UE, on the other hand, may not know or care about presence of any particular Rx UE in proximity. This makes PC5 DRX operation specific to each pair of PC5 Tx UE and Rx UE rather impractical, especially for PC5 groupcast and broadcast.

In connection-oriented PC5 unicast case, DRX operation specific to a pair of Tx UE and Rx UE over PC5 may be agreed beforehand between Rx UE and Tx UE. However, if the PC5 unicast Tx UE or Rx UE has other PC5 unicast/groupcast/broadcast communication services with the same or different peer UEs in addition to the PC5 unicast in question, uncoordinated PC5 DRX configuration for each PC5 unicast communication may lead to mis-aligned PC5 DRX patterns. This makes PC5 DRX overall less effective in terms of power saving.

To coordinate PC5 DRX configurations not only between the peered PC5 Tx UE and Rx UEs for one SL application/service but also among a number of PC5 UEs involved in multiple PC5 communications in proximity, this solution is based on having a common set of PC5 DRX patterns configured in PC5 UEs by the serving network for in-coverage operation or pre-configured for out-of-coverage operation. A PC5 DRX pattern includes information about the ON/OFF periods that shall be used in the (AS-layer) PC5 DRX schedule and each PC5 DRX pattern may be associated with one or more V2X service types. Note that there may be PC5 DRX patterns that would rather fit combinations of service types. Thus, the (pre-)configured set of PC5 DRX patterns may be corresponding to supported combinations of different use cases, service profiles, status or classes of PC5 UEs. The (pre-)configured set of PC5 DRX patterns can be also in line with resource pool configurations, because the patterns can be known to the AS layer when the resource pools are configured (or the other way round), so that the V2X layer does not need to deal with or understand resource pool configurations. However, the resource pool configuration does not need to be performed in a way that guarantees dedicated radio resources for specific V2X service types.

The contents of the PC5 DRX pattern set (e.g., length and period of ON/OFF cycles) may take into account QoS requirements of the V2X service type(s), e.g. the default PC5 QoS parameters that are configured in the UEs for each V2X service type, as described in TS <NUM> [<NUM>] clause <NUM>. The fact that the QoS for a certain V2X service may be different on different UEs can be compensated by the PC5 DRX schedule selection and enforcement procedure that takes place on the UE (see clause <NUM>.

In this way, the extensive coordination between relevant PC5 UEs in proximity to determine and agree on the PC5 DRX patterns can be avoided. The relevant PC5 UEs only needs to select one or more PC5 DRX pattern(s) from the limited set of configured PC5 DRX patterns and adapt SL transmissions and receptions to the selected pattern(s) of their own and other PC5 UEs in proximity.

The PC5 DRX mode shall be activated only if a PC5 DRX pattern that fits the V2X services running on the UE is found. Further, the V2X layer may enable the application layer to request the deactivation of the PC5 DRX mode. When and why a V2X application may request the deactivation of the PC5 DRX mode is up to the implementation of the V2X application and out of scope for the V2X layer.

Figure <NUM>. <NUM>-<NUM> illustrates an example operation of the solution for power efficient PC5 communication for Pedestrian UEs based on pre-defined PC5 DRX patterns.

The solution has the following impacts to the existing entities:.

For Key Issue #<NUM> (Support of QoS aware NR PC5 power efficiency for pedestrian UEs), regarding NR PC5 DRX operations the following principles are taken as the interim conclusion:.

According to 3GPP TS <NUM> and TS <NUM>, NR Uu specified one mechanism for saving UE power on monitoring downlink control channel (e.g. Physical Downlink Control Channel (PDCCH)). If a UE is configured with discontinuous reception (DRX) by its serving base station (e.g. gNB), the UE does not have to continuously monitor the downlink control channel. Basically, DRX mechanism is characterized by following:.

According to 3GPP RP-<NUM>, Rel-<NUM> NR sidelink is designed based on the assumption of "always-on" when UE operates sidelink, e.g., only focusing on UEs installed in vehicles with sufficient battery capacity. Solutions for power saving in Rel-<NUM> are required for vulnerable road users (VRUs) in V2X use cases and for UEs in public safety and commercial use cases where power consumption in the UEs needs to be minimized. In general, DRX mechanism operates periodic repetition of on-duration followed by inactivity period. Therefore, DRX mechanism is applicable for reception of periodic traffic. Preferably, DRX pattern of on-duration may be designed, applied, or assigned mainly based on periodic traffic pattern.

In Uu, DRX wake-up time is determined based on system frame number and subframe number which are synced between UE and gNB. When operating sidelink communication, the timing to align sidelink Transmission Time Interval (TTI) for monitoring sidelink control channel could be synced with gNB, Global Navigation Satellite Systems (GNSS), or a synchronization reference UE. For example, UE1 and UE2 communicate each other. UE2 monitors a sidelink signal or channel for synchronization (e.g. Physical Sidelink Broadcast Channel (PSBCH), or a signal or channel including MasterInformationBlockSidelink) sent by UE1 if UE1 is a synchronization reference UE. In the sidelink signal or channel for synchronization, information about frame number (e.g. directFrameNumber) and/or time slot (e.g. slotIndex) used to send this sidelink signal or channel for synchronization could be included so that frame number and/or time slot of UE2 can be synced with frame number and/or time slot of UE1.

Basically, UE1 has to transmit sidelink packets to UE2 at the period or time duration on which UE2 is awake for receiving these sidelink packets. Otherwise, these sidelink packets may be lost at UE2 if UE1 transmits these sidelink packets when UE2 is on the "sleep" period. According to one alternative (discussed in 3GPP TS <NUM>), each sidelink service could be associated with one sidelink DRX configuration. The association between sidelink service and sidelink DRX configuration could be pre-defined or pre-configured in UE or provisioned by network through authorization procedure. The association between sidelink service and sidelink DRX configuration could be applicable for unicast sidelink communication, broadcast sidelink communication and/or groupcast sidelink communication. For example, UE1 could initialize a sidelink service toward UE2 and establishes a unicast link with UE2. As another example, UE1 and UE2 could perform a sidelink service which will initialize groupcast sidelink communication. Thus, UE1 and UE2 will form a group for the groupcast sidelink communication.

According to the sidelink DRX configuration for a given sidelink service, UE1 may know how long UE2 stays awake after waking up (i.e. on-duration in each cycle of sidelink DRX) and the time interval between each wake-up period (i.e. cycle length of sidelink DRX). More specifically, the sidelink DRX configuration (i.e. the on-duration in each cycle of sidelink DRX, and the cycle length of sidelink DRX) may be determined or derived based on traffic pattern of the given sidelink service. This could be illustrated in <FIG>. However, UE1 has no information about time to start such wake-up period of the sidelink DRX configuration (i.e. startOffset for on-duration in each cycle of sidelink DRX), so that UE1 may send sidelink control information and/or sidelink transmission to UE2 at wrong time. Similarly, UE2 also has no the information about time to start such wake-up period of the sidelink DRX configuration, so that UE2 may monitor sidelink control information and/or receive sidelink transmission from UE1 at wrong time. To address this problem, some methods to determine when to start a wake-up period of a sidelink DRX configuration could be considered.

For groupcast, each group could be associated with one group ID. Each group could be also associated with one groupcast destination Layer-<NUM> ID (L2ID). A groupcast destination L2ID could be derived from a group ID. Different groups may be associated with different group IDs or different groupcast destination L2IDs.

Possibly, a time to start a wake-up period of a sidelink DRX configuration for a group could be derived from or could be determined based on a group ID or a groupcast destination L2ID associated with the group. Preferably, a time to start a wake-up period of a sidelink DRX configuration for a group could be derived from or could be determined based on a Vehicle-to-Everything (V2X) layer ID or value (e.g. Group ID, groupcast destination L2ID, or. ) or an application layer ID or value (which could have been negotiated or exchanged between each member in the group via application layer signalling) associated with the group.

Preferably, upper layer (e.g. V2X layer) of the UE could provide the V2X layer ID or value or the application layer ID or value to lower layer (i.e. Access Stratum (AS) layer, e.g. Radio Resource Control (RRC) layer, Medium Access Control (MAC) layer, or Physical (PHY) layer) of the UE. The lower layer of the UE could then derive the time to start the wake-up period of the sidelink DRX configuration from the V2X layer ID or value or the application layer ID or value.

Preferably, the upper layer of the UE could directly provide the time to start the wake-up period of the sidelink DRX configuration to the lower layer of the UE. The lower layer of the UE could then apply the time to start the wake-up period of the sidelink DRX configuration. In this alternative, the upper layer of the UE could derive the time to start the wake-up period of the sidelink DRX configuration from the V2X layer ID or value or the application layer ID or value.

Since each member in the group knows/acquires the same V2X layer ID/value or the same application layer ID/value associated with the group, each member in the group will then derive/determine or apply the same time to start the wake-up period of the sidelink DRX configuration associated with the group. Preferably, for a sidelink group comprising at least a UE1, the UE1 could derive or determine a time to start a wake-up period of a sidelink DRX configuration for the sidelink group based on group ID or destination Learning from Limited and Imperfect Data (L2ID) associated with the group. The UE1 could perform sidelink transmission to the sidelink group (e.g., to other UEs within the sidelink group) based on or within the wake-up period. The UE2 could perform sidelink reception from the sidelink group (e.g., from other UEs within the sidelink group) based on or within the wake-up period.

Moreover, it will separate wake-up periods for different groups at different timing, so that it would reduce resource collisions in case these sidelink transmissions occur at the same wake-up period across all groups. This benefit could be also applicable to sidelink unicast communication.

For unicast, each pair of UEs over a unicast link could be associated with one source L2ID and one destination L2ID. For instance, UE1 and UE2 could establish a unicast link for sidelink communication. From UE1 aspect, the source L2ID is UE1's L2ID and the destination L2ID could be UE2's L2ID. When UE1 transmits a sidelink transmission to the UE2, the source L2ID associated with the sidelink transmission could be (set to) UE1's L2ID and the destination L2ID associated with the sidelink transmission could be (set to) UE2's L2ID. From UE2's perspective, the source L2ID could be UE2's L2ID and the destination L2ID could be UE1's L2ID. When UE2 transmits a sidelink transmission to the UE1, the source L2ID associated with the sidelink transmission could be (set to) UE2's L2ID and the destination L2ID associated with the sidelink transmission could be (set to) UE1's L2ID.

Possibly, a time to start a wake-up period of a sidelink DRX configuration for a unicast link could be derived from or could be determined based on a source L2ID and/or a destination L2ID associated with the unicast link. Preferably, for a unicast link established between UE1 and UE2, a time to start a wake-up period of a sidelink DRX configuration for the unicast link could be derived from or could be determined based on a UE1's L2ID and/or UE2's L2ID.

Preferably for a unicast link between UE1 and UE2, the UE1 could derive or determine the time to start a wake-up period of a sidelink DRX configuration for the unicast link based on UE1's L2ID and UE2's L2ID. The UE1 could perform sidelink transmission to the UE2 based on or within the wake-up period. The UE1 could perform sidelink reception from the UE2 based on or within the wake-up period. Preferably, the UE2 could derive or determine the time to start a wake-up period of a sidelink DRX configuration for the unicast link based on UE2's L2ID and UE1's L2ID. The UE2 could perform sidelink transmission to the UE1 based on or within the wake-up period. The UE2 could perform sidelink reception from the UE1 based on or within the wake-up period.

Preferably for a unicast link between UE1 and UE2, the UE1 could derive or determine a first time to start a first wake-up period of a sidelink DRX configuration for the unicast link based on UE1's L2ID. The UE1 could perform sidelink reception from the UE2 based on or within the first wake-up period. The UE2 could derive or determine the first time to start the first wake-up period of a sidelink DRX configuration for the unicast link based on UE1's L2ID. The UE2 could perform sidelink transmission to the UE1 based on or within the first wake-up period. Preferably, the UE2 could derive or determine a second time to start a second wake-up period of a sidelink DRX configuration for the unicast link based on UE2's L2ID. The UE2 could perform sidelink reception from the UE1 based on or within the second wake-up period. The UE1 could derive or determine the second time to start the second wake-up period of a sidelink DRX configuration for the unicast link based on UE2's L2ID. The UE1 could perform sidelink transmission to the UE2 based on or within the second wake-up period.

Preferably for a unicast link between UE1 and UE2, the UE1 could derive or determine a first time to start a first wake-up period of a sidelink DRX configuration for the unicast link based on UE1's L2ID. The UE1 could perform sidelink transmission to the UE2 based on or within the first wake-up period. The UE2 could derive or determine the first time to start the first wake-up period of a sidelink DRX configuration for the unicast link based on UE1's L2ID. The UE2 could perform sidelink reception from the UE1 based on or within the first wake-up period. Preferably, the UE2 could derive or determine a second time to start a second wake-up period of a sidelink DRX configuration for the unicast link based on UE2's L2ID. The UE2 could perform sidelink transmission to the UE1 based on or within the second wake-up period. The UE1 could derive or determine the second time to start the second wake-up period of a sidelink DRX configuration for the unicast link based on UE2's L2ID. The UE1 could perform sidelink reception from the UE2 based on or within the second wake-up period.

Preferably for a unicast link between UE1 and UE2, the UE1 could derive or determine a first time to start a first wake-up period of a sidelink DRX configuration for the unicast link based on UE1's L2ID. The UE1 could perform sidelink reception from the UE2 based on or within the first wake-up period. The UE2 could derive or determine the first time to start the first wake-up period of a sidelink DRX configuration for the unicast link based on UE1's L2ID. The UE2 could perform sidelink transmission to the UE1 based on or within the first wake-up period. Preferably, the UE2 could derive or determine the first time to start the first wake-up period of a sidelink DRX configuration for the unicast link based on UE1's L2ID. The UE2 could perform sidelink reception from the UE1 based on or within the first wake-up period. The UE1 could derive or determine the first time to start the first wake-up period of a sidelink DRX configuration for the unicast link based on UE1's L2ID. The UE1 could perform sidelink transmission to the UE2 based on or within the first wake-up period.

Preferably for a unicast link between UE1 and UE2, the UE1 could derive or determine a second time to start a second wake-up period of a sidelink DRX configuration for the unicast link based on UE2's L2ID. The UE1 could perform sidelink transmission to the UE2 based on or within the second wake-up period. The UE2 could derive or determine the second time to start the second wake-up period of a sidelink DRX configuration for the unicast link based on UE2's L2ID. The UE2 could perform sidelink reception from the UE1 based on or within the second wake-up period. Preferably, the UE2 could derive or determine the second time to start the second wake-up period of a sidelink DRX configuration for the unicast link based on UE2's L2ID. The UE2 could perform sidelink transmission to the UE1 based on or within the second wake-up period. The UE1 could derive or determine the second time to start the second wake-up period of a sidelink DRX configuration for the unicast link based on UE2's L2ID. The UE1 could perform sidelink reception from the UE2 based on or within the second wake-up period.

Preferably, it could be possible that some parameters in a sidelink DRX configuration except for a parameter used for determining time to start wake-up period could be negotiated between two UEs (via PC5-S message, PC5-RRC message or MAC control element) but the parameter used for determining time to start wake-up period could be derived from or could be determined based on the source L2ID (e.g., UE1's L2ID or UE2's L2ID) and/or the destination L2ID (e.g., UE2's L2ID or UE1's L2ID) associated with the unicast link.

Alternatively, the parameter used for determining time to start wake-up period could be negotiated between two UEs (e.g.,UE1 and UE2 of a unicast link). For example, UE1 could provide one or more candidate values of time to start wake-up period to UE2 (through e.g. PC5-S message, PC5-RRC message or MAC control element), and UE2 could then respond to UE1 with one of them for a determined value of time to start wake-up period (through e.g. PC5-S message, PC5-RRC message or MAC control element). In response to receipt of the determined value of time to start wake-up period, UE1 may apply/use the determined value of time to start wake-up period to start a wake-up period for the unicast link.

Preferably, UE1 may perform sidelink transmission to the UE2 based on or within the wake-up period. Alternatively, UE1 may perform sidelink reception from the UE2 based on or within the wake-up period. In response to the response, UE2 may also apply/use the determined value of time to start wake-up period to start the wake-up period for the unicast link. Preferably, UE2 may perform sidelink transmission to the UE1 based on or within the wake-up period. Alternatively, UE2 may perform sidelink reception from the UE1 based on or within the wake-up period.

In order to maximize power saving, wake-up time for sidelink DRX could be aligned with wake-up time for Uu DRX. If UE1 is configured with Uu DRX by its gNB, UE1 could determine a time to start wake-up period of sidelink DRX based on the time to start wake-up period of Uu DRX. Preferably, if UE1 is configured with Uu DRX by its gNB, UE1 could determine the one or more candidate values of time to start wake-up period of sidelink DRX based on the time to start wake-up period of UE1's Uu DRX. Preferably, if UE2 is configured with Uu DRX by its gNB, UE2 could determine one of the one or more candidate values based on the time to start wake-up period of UE2's Uu DRX. Alternatively, if UE1 is not configured with Uu DRX by its gNB or UE1 is out-of-coverage, UE1 could determine a time to start wake-up period of sidelink DRX based on the source L2ID (e.g., UE1's L2ID or UE2's L2ID) and/or the destination L2ID (e.g., UE2's L2ID or UE1's L2ID) associated with the unicast link with UE2. UE1 could then configure UE2 to follow the determined time to start wake-up period of sidelink DRX (via e.g. PC5-S message, PC5-RRC message or MAC control element).

More specifically, the association between sidelink service and sidelink DRX configuration could be that an identity of a sidelink service (e.g. PSID) or an identity of an application offering the sidelink service (e.g. AID) is associated with one sidelink DRX configuration. More specifically, the wake-up period could be determined based on an on-duration of a sidelink DRX cycle.

More specifically, the time to start the wake-up period could be based on a startOffset of a sidelink DRX cycle. The time to start the wake-up period may mean a slot offset (e.g. drx-SlotOffsetSL) used for determining a delay before starting the on-duration timer. The time to start the wake-up period may mean a cycle start offset (e.g. drx-StartOffset) used for determining a subframe where the SL DRX cycle starts.

More specifically, the sidelink DRX configuration could configure at least one of an on-duration timer (e.g. drx-onDurationTimerSL) used for determining a duration at the beginning of a SL DRX cycle, an inactive timer (e.g. drx-InactivityTimerSL) used for determining a duration after a Physical Sidelink Control Channel (PSCCH) occasion in which a sidelink control information indicates a sidelink transmission, a retransmission timer (e.g. drx-RetransmissionTimerSL) used for determining a maximum duration until a sidelink retransmission is received, a cycle length (e.g. drx-LongCycleStartOffsetSL) used for determining a length of the SL DRX cycle, a short cycle length (e.g. drx-ShortCycleSL) used for determining a length of a second SL DRX cycle shorter than the length of the SL DRX cycle, and/or a round trip-time timer (e.g. drx-HARQ-RTT-TimerSL) used for determining a maximum duration before a sidelink HARQ retransmission grant is expected. Preferably, the sidelink DRX configuration does not comprise the time to start the wake-up period of the sidelink DRX configuration.

More specifically, the unit for the time to start of wake-up period for sidelink DRX could be slot, symbol or subframe. The wake-up period for sidelink DRX could be started at a specific sidelink frame number and/or a specific sidelink time slot.

More specifically, the specific sidelink frame number and/or the specific sidelink time slot could be determined based on or could be derived from the V2X layer ID/value (e.g. Group ID, groupcast destination L2ID, or. ) or the application layer ID/value, if the sidelink DRX is applied for sidelink groupcast communication. The specific sidelink frame number and/or the specific sidelink time slot could be determined based on or could be derived from a source L2ID and/or a destination L2ID associated with a unicast link, if the sidelink DRX is applied for sidelink unicast communication. The specific sidelink frame number and/or the specific sidelink time slot could be determined based on or could be derived from an identifier used to identify a unicast link, if the sidelink DRX is applied for sidelink unicast communication.

More specifically, deriving or determining a time (e.g., any one of the time to start a wake-up period of a sidelink DRX configuration for the sidelink group, or the time to start a wake-up period of a sidelink DRX configuration for the unicast link) based on a ID (e.g., any one of V2X layer ID/value, application layer ID/value, Group ID, groupcast destination L2ID, source L2ID, destination L2ID, UE1's L2ID, or UE2's L2ID) may mean that (part of) the ID value is a derivation factor for (deriving/determining) the time. Cycle length of sidelink DRX may also be a derivation factor for (deriving/determining) the time.

More specifically, deriving or determining a time (e.g., the time to start a wake-up period of a sidelink DRX configuration for the unicast link) based on a ID1 and a ID2 (e.g., source L2ID and destination L2ID, or UE1's L2ID and UE2's L2ID) may mean that (part of) the ID1 value and (part of) the ID2 value are both derivation factor for (deriving/determining) the time. Cycle length of sidelink DRX may also be a derivation factor for (deriving/determining) the time.

More specifically, deriving or determining a time (e.g., any one of the time to start a wake-up period of a sidelink DRX configuration for the sidelink group, or the time to start a wake-up period of a sidelink DRX configuration for the unicast link) based on a ID (e.g., any one of V2X layer ID/value, application layer ID/value, Group ID, groupcast destination L2ID, source L2ID, destination L2ID, UE1's L2ID, or UE2's L2ID) may mean that (part of) the ID value is in a formula for (deriving/determining) the time. Cycle length of sidelink DRX may also be in the formula for (deriving/determining) the time.

More specifically, deriving or determining a time (e.g., the time to start a wake-up period of a sidelink DRX configuration for the unicast link) based on a ID1 and a ID2 (e.g., source L2ID and destination L2ID, or UE1's L2ID and UE2's L2ID) may mean that (part of) the ID1 value and (part of) the ID2 value are both in a formula for (deriving/determining) the time. Cycle length of sidelink DRX may also be in the formula for (deriving/determining) the time.

More specifically, deriving or determining a time (e.g., any one of the time to start a wake-up period of a sidelink DRX configuration for the sidelink group, or the time to start a wake-up period of a sidelink DRX configuration for the unicast link) based on a ID (e.g., any one of V2X layer ID/value, application layer ID/value, Group ID, groupcast destination L2ID, source L2ID, destination L2ID, UE1's L2ID, or UE2's L2ID) may mean a value for (deriving/determining) the time is equal to a derived value via (part of) the ID value module cycle length of sidelink DRX.

More specifically, deriving or determining a time (e.g., the time to start a wake-up period of a sidelink DRX configuration for the unicast link) based on a ID1 and a ID2 (e.g., source L2ID and destination L2ID, or UE1's L2ID and UE2's L2ID) may mean a value for (deriving/determining) the time is equal to a derived value via a summation value of (part of) the ID1 value and (part of) the ID2 value module cycle length of sidelink DRX.

More specifically, in the claimed invention, deriving or determining a time, i.e. the time to start a wake-up period of a sidelink DRX configuration for the sidelink group based on a ID, i.e. any one of Group ID or groupcast destination L2ID means that a value for (deriving/determining) the time is derived as (part of) the ID value modulo cycle length of sidelink DRX.

More specifically, deriving or determining a time (e.g., the time to start a wake-up period of a sidelink DRX configuration for the unicast link) based on a ID1 and a ID2 (e.g., source L2ID and destination L2ID, or UE1's L2ID and UE2's L2ID) may mean a value for (deriving/determining) the time is derived as a summation value of (part of) the ID1 value and (part of) the ID2 value module cycle length of sidelink DRX.

More specifically, deriving or determining a time (e.g., any one of the time to start a wake-up period of a sidelink DRX configuration for the sidelink group, or the time to start a wake-up period of a sidelink DRX configuration for the unicast link) based on a ID (e.g., any one of V2X layer ID/value, application layer ID/value, Group ID, groupcast destination L2ID, source L2ID, destination L2ID, UE1's L2ID, or UE2's L2ID) may mean a value for (deriving/determining) the time is equal to a derived value of "((part of) the ID value) mod (cycle length of sidelink DRX)". Preferably, deriving or determining a time (e.g., any one of the time to start a wake-up period of a sidelink DRX configuration for the sidelink group, or the time to start a wake-up period of a sidelink DRX configuration for the unicast link) based on a ID (e.g., any one of V2X layer ID/value, application layer ID/value, Group ID, groupcast destination L2ID, source L2ID, destination L2ID, UE1's L2ID, or UE2's L2ID) may mean a value for (deriving/determining) the time is equal to a derived value of "(A*((part of) the ID value)+B) mod (cycle length of sidelink DRX)". A may be another derivation factor for (deriving/determining) the time. A may be a random number or a variable number or a configured number. B may be another derivation factor for (deriving/determining) the time. B may be a random number or a variable number or a configured number.

More specifically, deriving or determining a time (e.g., the time to start a wake-up period of a sidelink DRX configuration for the unicast link) based on a ID1 and a ID2 (e.g., source L2ID and destination L2ID, or UE1's L2ID and UE2's L2ID) may mean a value for (deriving/determining) the time is equal to a derived value of "((part of) the ID1 value + (part of) the ID2 value) mod (cycle length of sidelink DRX)". Preferably, deriving or determining a time (e.g., the time to start a wake-up period of a sidelink DRX configuration for the unicast link) based on a ID1 and a ID2 (e.g., source L2ID and destination L2ID, or UE1's L2ID and UE2's L2ID) may mean a value for (deriving/determining) the time is equal to a derived value of "(A1*((part of) the ID1 value) + A2*((part of) the ID2 value)+B) mod (cycle length of sidelink DRX)". A1 may be another derivation factor for (deriving/determining) the time. A1 may be a random number or a variable number or a configured number. A2 may be another derivation factor for (deriving/determining) the time. A2 may be a random number or a variable number or a configured number. A1 and A2 may be different or the same. B may be another derivation factor for (deriving/determining) the time. B may be a random number or a variable number or a configured number.

More specifically, deriving or determining a time (e.g., any one of the time to start a wake-up period of a sidelink DRX configuration for the sidelink group, or the time to start a wake-up period of a sidelink DRX configuration for the unicast link) based on a ID (e.g., any one of V2X layer ID/value, application layer ID/value, Group ID, groupcast destination L2ID, source L2ID, destination L2ID, UE1's L2ID, or UE2's L2ID) may mean a value for (deriving/determining) the time is derived as "((part of) the ID value) mod (cycle length of sidelink DRX)". Preferably, deriving or determining a time (e.g., any one of the time to start a wake-up period of a sidelink DRX configuration for the sidelink group, or the time to start a wake-up period of a sidelink DRX configuration for the unicast link) based on a ID (e.g., any one of V2X layer ID/value, application layer ID/value, Group ID, groupcast destination L2ID, source L2ID, destination L2ID, UE1's L2ID, or UE2's L2ID) may mean a value for (deriving/determining) the time is derived as "(A*((part of) the ID value)+B) mod (cycle length of sidelink DRX)". A may be another derivation factor for (deriving/determining) the time. A may be a random number or a variable number or a configured number. B may be another derivation factor for (deriving/determining) the time. B may be a random number or a variable number or a configured number.

More specifically, deriving or determining a time (e.g., the time to start a wake-up period of a sidelink DRX configuration for the unicast link) based on a ID1 and a ID2 (e.g., source L2ID and destination L2ID, or UE1's L2ID and UE2's L2ID) may mean a value for (deriving/determining) the time is derived as "((part of) the ID1 value+(part of) the ID2 value) mod (cycle length of sidelink DRX)". Preferably, deriving or determining a time (e.g., the time to start a wake-up period of a sidelink DRX configuration for the unicast link) based on a ID1 and a ID2 (e.g., source L2ID and destination L2ID, or UE1's L2ID and UE2's L2ID) may mean a value for (deriving/determining) the time is derived as "(A1*((part of) the ID1 value) + A2*((part of) the ID2 value)+B) mod (cycle length of sidelink DRX)". A1 may be another derivation factor for (deriving/determining) the time. A1 may be a random number or a variable number or a configured number. A2 may be another derivation factor for (deriving/determining) the time. A2 may be a random number or a variable number or a configured number. A1 and A2 may be different or the same. B may be another derivation factor for (deriving/determining) the time. B may be a random number or a variable number or a configured number.

Preferably, the ID value means a decimal value of the ID. Part of the ID may mean some (not all) LSB bits of the ID. Part of the ID value may mean a decimal value of some (not all) LSB bits of the ID.

In one example, the ID is <NUM> bits. The part of the ID is LSB <NUM> bits of the ID. The part of the ID value is a decimal value of the LSB <NUM> bits of the ID. The LSB portion of the ID is the LSB <NUM> bits of the ID. The value portion of the ID value is a decimal value of the LSB <NUM> bits of the ID.

Preferably, part of the ID may mean some (not all) MSB bits of the ID. Part of the ID value may mean a decimal value of some (not all) MSB bits of the ID.

In one example, the ID is <NUM> bits. The part of the ID is MSB <NUM> bits of the ID. The part of the ID value is a decimal value of the MSB <NUM> bits of the ID. The MSB portion of the ID is the MSB <NUM> bits of the ID. The value portion of the ID is a decimal value of the MSB <NUM> bits of the ID.

<FIG> is a flow chart <NUM> illustrating a method for a UE to configure sidelink DRX for sidelink groupcast communication associated with a group. In step <NUM>, the UE applies a sidelink DRX configuration for the sidelink groupcast communication associated with the group, wherein the sidelink DRX configuration comprises at least one of an on-duration timer (length) used for determining an on-duration (at a beginning) of/for (each) sidelink DRX cycle and/or a cycle length used for determining a length of (each) sidelink DRX cycle. In step <NUM>, the UE derives or determines a time to start of on-duration for (each) sidelink DRX cycle or start of (each) sidelink DRX cycle based on at least an identifier associated with the group. In step <NUM>, the UE monitors a sidelink control channel, associated with the group, based on the sidelink DRX configuration and the time to start of on-duration for (each) sidelink DRX cycle or start of (each) sidelink DRX cycle.

Preferably, the sidelink DRX configuration may not comprise the time to start of on-duration for (each) sidelink DRX cycle or start of (each) sidelink DRX cycle.

Preferably, the time to start of on-duration for (each) sidelink DRX cycle or start of (each) sidelink DRX cycle could be a startOffset, and/or a unit of the time to start of on-duration for (each) sidelink DRX cycle or start of (each) sidelink DRX cycle could be subframe.

Preferably, the derived or determined time to start of on-duration for (each) sidelink DRX cycle or start of (each) sidelink DRX cycle may be (equal to) a derived value of a part of the identifier mod the cycle length. Preferably, the derived or determined time to start of on-duration for (each) sidelink DRX cycle or start of (each) sidelink DRX cycle may be (equal to) a derived value of the identifier mod the cycle length. The mod means modulo or modulus.

Preferably, the UE may have information indicating one or more time to start of on-duration for (each) sidelink DRX cycle or start of (each) sidelink DRX cycle, and/or the UE could derive or determine the time to start of on-duration for (each) sidelink DRX cycle or start of (each) sidelink DRX cycle based on at least the identifier associated with the group and the information.

Preferably, the UE could derive or determine an index based on at least the identifier associated with the group. Furthermore, the UE could derive or determine the time to start of on-duration for (each) sidelink DRX cycle or start of (each) sidelink DRX cycle, from the one or more time to start of on-duration for (each) sidelink DRX cycle or start of (each) sidelink DRX cycle, based on the index.

Preferably, the identifier associated with the group may be a part of groupcast destination Layer-<NUM> ID. Preferably, the identifier associated with the group may be a groupcast destination Layer-<NUM> ID.

Preferably, the UE could monitor the sidelink control channel, associated with the group, in a period. The period could be determined based on the sidelink DRX configuration and the time to start of on-duration for (each) sidelink DRX cycle or start of (each) sidelink DRX cycle The period may be an active time on which at least the on-duration timer is running.

Referring back to <FIG> and <FIG>, in one exemplary embodiment of a method for a UE to configure sidelink DRX for sidelink groupcast communication associated with a group, the UE <NUM> includes a program code <NUM> stored in the memory <NUM>. The CPU <NUM> could execute program code <NUM> to enable the UE (i) to apply a sidelink DRX configuration for the sidelink groupcast communication associated with the group, wherein the sidelink DRX configuration comprises at least one of an on-duration timer (length) used for determining an on-duration (at a beginning) of/for (each) sidelink DRX cycle and/or a cycle length used for determining a length of (each) sidelink DRX cycle, (ii) to derive or determine a time to start of on-duration for (each) sidelink DRX cycle or start of (each) sidelink DRX cycle based on at least an identifier associated with the group, and (iii) to monitoring a sidelink control channel, associated with the group, based on the sidelink DRX configuration and the time to start of on-duration for (each) sidelink DRX cycle or start of (each) sidelink DRX cycle. Furthermore, the CPU <NUM> can execute the program code <NUM> to perform all of the above-described actions and steps or others described herein.

<FIG> is a flow chart <NUM> illustrating a method for a second UE to configure sidelink DRX in a sidelink groupcast communication. In step <NUM>, the second UE initializes a sidelink service for the sidelink groupcast communication. In step <NUM>, the second UE determines a SL DRX configuration based on association between sidelink service and SL DRX configuration, wherein the SL DRX configuration is associated with the sidelink service. In step <NUM>, the second UE derives or determines a time to start of on-duration for (each) sidelink DRX cycle based on at least an identifier associated with the sidelink groupcast communication. In step <NUM>, the second UE monitors sidelink control channel, for the sidelink groupcast communication, based on the time to start of on-duration for (each) sidelink DRX cycle and the SL DRX configuration.

Referring back to <FIG> and <FIG>, in one exemplary embodiment of a method for a second UE to configure SL DRX in a sidelink groupcast communication, the second UE <NUM> includes a program code <NUM> stored in the memory <NUM>. The CPU <NUM> could execute program code <NUM> to enable the second UE (i) to initialize a sidelink service for the sidelink groupcast communication, (ii) to determine a SL DRX configuration based on association between sidelink service and SL DRX configuration, wherein the SL DRX configuration is associated with the sidelink service, (iii) to derive or determine a time to start of on-duration for (each) sidelink DRX cycle based on at least an identifier associated with the sidelink groupcast communication, and (iv) to monitor sidelink control channel, for the sidelink groupcast communication, based on the time to start of on-duration for (each) sidelink DRX cycle and the SL DRX configuration. Furthermore, the CPU <NUM> can execute the program code <NUM> to perform all of the above-described actions and steps or others described herein.

<FIG> is a flow chart <NUM> illustrating a method for a first UE to consider sidelink DRX in a sidelink groupcast communication. In step <NUM>, the first UE initializes a sidelink service for the sidelink groupcast communication. In step <NUM>, the first UE determines a SL DRX configuration based on association between sidelink service and SL DRX configuration, wherein the SL DRX configuration is associated with the sidelink service. In step <NUM>, the first UE derives or determines a time to start of on-duration for each sidelink DRX cycle based on at least an identifier associated with the sidelink groupcast communication. In step <NUM>, the first UE transmits sidelink control information, for the sidelink groupcast communication, on sidelink control channel in a period, wherein the period is determined based on the time to start of on-duration for each sidelink DRX cycle and the SL DRX configuration.

Referring back to <FIG> and <FIG>, in one exemplary embodiment of a method for a first UE to consider sidelink (SL) DRX in a sidelink groupcast communication, the first UE <NUM> includes a program code <NUM> stored in the memory <NUM>. The CPU <NUM> could execute program code <NUM> to enable the first UE (i) to initialize a sidelink service for the sidelink groupcast communication, (ii) to determine a SL DRX configuration based on association between sidelink service and SL DRX configuration, wherein the SL DRX configuration is associated with the sidelink service, (iii) to derive or determine a time to start of on-duration for each sidelink DRX cycle based on at least an identifier associated with the sidelink groupcast communication, and (iv) to transmit sidelink control information, for the sidelink groupcast communication, on sidelink control channel in a period, wherein the period is determined based on the time to start of on-duration for each sidelink DRX cycle and the SL DRX configuration. Furthermore, the CPU <NUM> can execute the program code <NUM> to perform all of the above-described actions and steps or others described herein.

In the context of the embodiments illustrated in <FIG> and <FIG> and discussed above, Preferably, the association between sidelink service and SL DRX configuration could be preconfigured or predefined in the first UE and the second UE or is provisioned by network. The first UE or the second UE could select an entry of a list of the association between sidelink service and SL DRX configuration, and wherein the entry includes the SL DRX configuration and an identity of the sidelink service or an index associated with the sidelink service.

Preferably, the SL DRX configuration could configure at least one of an on-duration timer (e.g. drx-onDurationTimerSL) used for determining a duration at the beginning of a SL DRX cycle, an inactive timer (e.g. drx-InactivityTimerSL) used for determining a duration after a PSCCH occasion in which a sidelink control information indicates a sidelink transmission, a retransmission timer (e.g. drx-RetransmissionTimerSL) used for determining a maximum duration until a sidelink retransmission is received, a cycle length (e.g. drx-LongCycleStartOffsetSL) used for determining a length of the SL DRX cycle, a short cycle length (e.g. drx-ShortCycleSL) used for determining a length of a second SL DRX cycle shorter than the length of the SL DRX cycle, and/or a round trip-time timer (e.g. drx-HARQ-RTT-TimerSL) used for determining a maximum duration before a sidelink HARQ retransmission grant is expected.

Preferably, the first UE and the second UE could belong to a group for the sidelink groupcast communication. The identifier associated with the group or the groupcast sidelink communication could be a (part of) groupcast destination Layer-<NUM> ID or a group ID.

<FIG> is a flow chart <NUM> illustrating a method for a (Rx) UE. In step <NUM>, the (Rx) UE initializes a sidelink service for a sidelink groupcast communication. In step <NUM>, the (Rx) UE receives an identifier (ID) associated with the sidelink groupcast communication, wherein the ID is used for data transmission and reception in the sidelink groupcast communication. In step <NUM>, the (Rx) UE receives a SL DRX configuration associated with the sidelink service, wherein the SL DRX configuration includes at least a first length of on-duration and a second length of a cycle. In step <NUM>, the (Rx) UE derives or determines an offset based on at least the identifier. In step <NUM>, the (Rx) UE determines a periodic active time based on at least the first length of on-duration, the second length of the cycle and the offset, wherein the offset is used to indicate or define where the cycle starts and the first length of on-duration is a duration at beginning of the cycle. In step <NUM>, the (Rx) UE monitors sidelink control channel within the periodic active time for the sidelink groupcast communication.

Referring back to <FIG> and <FIG>, in one exemplary embodiment of a method for a the (Rx) UE, the (Rx) UE <NUM> includes a program code <NUM> stored in the memory <NUM>. The CPU <NUM> could execute program code <NUM> to enable the (Rx) UE (i) to initialize a sidelink service for a sidelink groupcast communication, (ii) to receive an identifier (ID) associated with the sidelink groupcast communication, wherein the ID is used for data transmission and reception in the sidelink groupcast communication, (iii) to receive a SL DRX configuration associated with the sidelink service, wherein the SL DRX configuration includes at least a first length of on-duration and a second length of a cycle, (iv) to derive or determine an offset based on at least the identifier, (v) to determine a periodic active time based on at least the first length of on-duration, the second length of the cycle and the offset, wherein the offset is used to indicate or define where the cycle starts and the first length of on-duration is a duration at beginning of the cycle, and (vi) to monitor sidelink control channel within the periodic active time for the sidelink groupcast communication. Furthermore, the CPU <NUM> can execute the program code <NUM> to perform all of the above-described actions and steps or others described herein.

<FIG> is a flow chart <NUM> illustrating a method for a (Tx) UE. In step <NUM>, the (Tx) UE initializes a sidelink service for a sidelink groupcast communication. In step <NUM>, the (Tx) UE receives an identifier (ID) associated with the sidelink groupcast communication, wherein the ID is used for data transmission and reception in the sidelink groupcast communication. In step <NUM>, the (Tx) UE receives a SL DRX configuration associated with the sidelink service, wherein the SL DRX configuration includes at least a first length of on-duration and a second length of a cycle. In step <NUM>, the (Tx) UE derives or determines an offset based on at least the identifier. In step <NUM>, the (Tx) UE determines a periodic active time based on at least the first length of on-duration, the second length of the cycle and the offset, wherein the offset is used to indicate or define where the cycle starts and the first length of on-duration is a duration at beginning of the cycle. In step <NUM>, the (Tx) UE transmits a data within the periodic active time for the sidelink groupcast communication.

Referring back to <FIG> and <FIG>, in one exemplary embodiment of a method for a the (Tx) UE, the (Tx) UE <NUM> includes a program code <NUM> stored in the memory <NUM>. The CPU <NUM> could execute program code <NUM> to enable the (Tx) UE (i) to initialize a sidelink service for a sidelink groupcast communication, (ii) to receive an identifier (ID) associated with the sidelink groupcast communication, wherein the ID is used for data transmission and reception in the sidelink groupcast communication, (iii) to receive a SL DRX configuration associated with the sidelink service, wherein the SL DRX configuration includes at least a first length of on-duration and a second length of a cycle, (iv) to derive or determine an offset based on at least the identifier, (v) to determine a periodic active time based on at least the first length of on-duration, the second length of the cycle and the offset, wherein the offset is used to indicate or define where the cycle starts and the first length of on-duration is a duration at beginning of the cycle, and (vi) to transmit a data within the periodic active time for the sidelink groupcast communication. Furthermore, the CPU <NUM> can execute the program code <NUM> to perform all of the above-described actions and steps or others described herein.

Various aspects of the disclosure have been described above. It should be apparent that the teachings herein could be embodied in a wide variety of forms and that any specific structure, function, or both being disclosed herein is merely representative. Based on the teachings herein one skilled in the art should appreciate that an aspect disclosed herein could be implemented independently of any other aspects and that two or more of these aspects could be combined in various ways. For example, an apparatus could be implemented or a method could be practiced using any number of the aspects set forth herein. In addition, such an apparatus could be implemented or such a method could be practiced using other structure, functionality, or structure and functionality in addition to or other than one or more of the aspects set forth herein. As an example of some of the above concepts, in some aspects concurrent channels could be established based on pulse repetition frequencies. In some aspects concurrent channels could be established based on pulse position or offsets. In some aspects concurrent channels could be established based on time hopping sequences. In some aspects concurrent channels could be established based on pulse repetition frequencies, pulse positions or offsets, and time hopping sequences.

Those of skill would further appreciate that the various illustrative logical blocks, modules, processors, means, circuits, and algorithm steps described in connection with the aspects disclosed herein may be implemented as electronic hardware (e.g., a digital implementation, an analog implementation, or a combination of the two, which may be designed using source coding or some other technique), various forms of program or design code incorporating instructions (which may be referred to herein, for convenience, as "software" or a "software module"), or combinations of both.

It is understood that any specific order or hierarchy of steps in any disclosed process is an example of a sample approach. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the processes may 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.

The steps of a method or algorithm described in connection with the aspects disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module (e.g., including executable instructions and related data) and other data may reside in a data memory such as RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM, or any other form of computer-readable storage medium known in the art. A sample storage medium may be coupled to a machine such as, for example, a computer/processor (which may be referred to herein, for convenience, as a "processor") such the processor can read information (e.g., code) from and write information to the storage medium. A sample storage medium may be integral to the processor. The ASIC may reside in user equipment. In the alternative, the processor and the storage medium may reside as discrete components in user equipment. Moreover, in some aspects any suitable computer-program product may comprise a computer-readable medium comprising codes relating to one or more of the aspects of the disclosure. In some aspects a computer program product may comprise packaging materials.

Claim 1:
A method for a User Equipment, in the following also referred to as UE, to configure sidelink discontinuous reception, in the following also referred to as DRX, for sidelink groupcast communication associated with a group, comprising:
obtaining or being configured with a sidelink DRX configuration for the sidelink groupcast communication associated with the group, wherein the sidelink DRX configuration comprises at least one of an on-duration timer length used for determining an on-duration for each sidelink DRX cycle and/or a cycle length used for determining a length of each sidelink DRX cycle (<NUM>);
deriving or determining a time to start of on-duration for each sidelink DRX cycle or start of each sidelink DRX cycle based on at least an identifier associated with the group (<NUM>); and
monitoring a sidelink control channel, associated with the group, based on the sidelink DRX configuration and the time to start of on-duration for each sidelink DRX cycle or start of each sidelink DRX cycle (<NUM>),
characterized in that
the time to start of on-duration for each sidelink DRX cycle or start of each sidelink DRX cycle is derived or determined based on a derived value of "(part of the identifier) modulo (the cycle length)" or a derived value of "(the identifier) modulo (the cycle length)".