Patent Description:
For <NUM> NR (<NUM>th generation new radio), when being configured, the discontinuous reception (DRX) functionality controls the expected user equipment (UE) behavior in terms of reception and processing of transmissions. Broadly speaking, the DRX functionality defines the notion of Active Time (also referred to as Active Time state or ACTIVE state), in which the UE is expected to receive and process incoming transmissions as appropriate. For example, the UE is expected to decode the downlink (DL) control channels, and process grants, etc..

3GPP specified the LTE (long term evolution) D2D (device-to-device) technology, also known as sidelink (SL) or the PC5 interface, as part of Release <NUM> (Rel-<NUM>). The target use case (UC) was the Proximity Services (communication and discovery). Support was enhanced during Rel-<NUM>. In Rel-<NUM>, the LTE sidelink was extensively redesigned to support vehicular communications (commonly referred to as V2X or V2V). Support was again enhanced during Rel-<NUM>. From the point of view of the lowest radio layers, the LTE SL uses broadcast communication. That is, transmission from a UE targets any receiver that is in range.

ProSe (Proximity Services) in the Release <NUM> and <NUM> of LTE. Later in Rel. <NUM> and <NUM>, LTE V2X related enhancements targeting the specific characteristics of vehicular communications were specified. In LTE V2X only broadcast is supported over sidelink.

In Rel-<NUM>, 3GPP introduced the sidelink for the <NUM> new radio (NR). The driving UC were vehicular communications with more stringent requirements than those typically served using the LTE SL. To meet these requirements, the NR SL is capable of broadcast, groupcast, and unicast communications. In groupcast communication, the intended receivers of a message are typically a subset of the vehicles near the transmitter, whereas in unicast communication, there is a single intended receiver.

Both the LTE SL and the NR SL can operate with and without network coverage and with varying degrees of interaction between the UEs (user equipment) and the NW (network), including support for standalone, network-less operation.

3GPP contribution "Discussion on physical layer design considering sidelink DRX operation", document R1-<NUM>, 3GPP TSG RAN WG1 meeting #<NUM>-e (November <NUM>), describes congestion control under SL DRX, which may be performed using channel busy ratio measured during the past active time duration.

The present invention provides a method according to claim <NUM>, a first terminal device according to claim <NUM>, and a computer program according to claim <NUM>. The dependent embodiments define further embodiments.

In the context of the present invention and its embodiments, the present disclosure provides mechanisms to adapt sidelink discontinuous reception (SL DRX) configuration based on the sidelink (SL) radio situation and to operate SL DRX by taking SL resource configuration into account, which mainly includes the following aspects:.

With the methods and devices of the present disclosure, radio situation based SL DRX configuration adaptation achieves a more optimal tradeoff between UE power consumption and SL performance. Operating SL DRX by taking SL resource configuration into account avoids that the SL communication opportunities are undesirably reduced due to mismatch between SL DRX configuration and SL resource configuration.

The present disclosure may be best understood by way of example with reference to the following description and accompanying drawings that are used to illustrate embodiments of the present disclosure. In the drawings:.

The following detailed description describes methods and devices for sidelink discontinuous reception configuration and operation. In the following detailed description, numerous specific details such as logic implementations, types and interrelationships of system components, etc. are set forth in order to provide a more thorough understanding of the present disclosure. It should be appreciated, however, by one skilled in the art that the present disclosure may be practiced without such specific details. In other instances, control structures, circuits and instruction sequences have not been shown in detail in order not to obscure the present disclosure. Those of ordinary skill in the art, with the included descriptions, will be able to implement appropriate functionality without undue experimentation.

References in the specification to "one embodiment", "an embodiment", "an example embodiment" etc. indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic.

Bracketed text and blocks with dashed borders (e.g., large dashes, small dashes, dot-dash, and dots) may be used herein to illustrate optional operations that add additional features to embodiments of the present disclosure. However, such notation should not be taken to mean that these are the only options or optional operations, and/or that blocks with solid borders are not optional in certain embodiments of the present disclosure.

In the following detailed description and claims, the terms "coupled" and "connected," along with their derivatives, may be used. "Coupled" is used to indicate that two or more elements, which may or may not be in direct physical or electrical contact with each other, cooperate or interact with each other.

An electronic device stores and transmits (internally and/or with other electronic devices over a network) code (which is composed of software instructions and which is sometimes referred to as computer program code or a computer program) and/or data using machine-readable media (also called computer-readable media), such as machine-readable storage media (e.g., magnetic disks, optical disks, read only memory (ROM), flash memory devices, phase change memory) and machine-readable transmission media (also called a carrier) (e.g., electrical, optical, radio, acoustical or other forms of propagated signals - such as carrier waves, infrared signals). Thus, an electronic device (e.g., a computer) includes hardware and software, such as a set of one or more processors coupled to one or more machine-readable storage media to store code for execution on the set of processors and/or to store data. For instance, an electronic device may include non-volatile memory containing the code since the non-volatile memory can persist code/data even when the electronic device is turned off (when power is removed), and while the electronic device is turned on, that part of the code that is to be executed by the processor(s) of that electronic device is typically copied from the slower non-volatile memory into volatile memory (e.g., dynamic random access memory (DRAM), static random access memory (SRAM)) of that electronic device. Typical electronic devices also include a set of one or more physical network interfaces to establish network connections (to transmit and/or receive code and/or data using propagating signals) with other electronic devices. One or more parts of an embodiment of the present disclosure may be implemented using different combinations of software, firmware, and/or hardware.

The terms "terminal device" and "user equipment (UE)" are used in this disclosure as interchangeable terms.

A control node can be a base station (for example a NB, eNB or gNB), or a controlling UE/terminal device. The claimed invention is part of the embodiments of the Group A. Discontinuous reception (DRX).

For <NUM> NR, when being configured, the DRX functionality controls the expected UE behavior in terms of reception and processing of transmissions. Broadly speaking, the DRX functionality defines the notion of Active Time (also referred to as Active Time state or ACTIVE state), in which the UE is expected to receive and process incoming transmissions as appropriate. For example, the UE is expected to decode DL control channels, and process grants, etc..

It should be noted that the state of the DRX is not related to the radio resource control (RRC) state of the UE. That is, even if the UE is in the ACTIVE or INACTIVE state, its RRC state is not changed (i.e., the UE stays in its current RRC state - RRC_CONNECTED/IDLE/INACTIVE).

When the UE is not in Active Time, there is no expectation on the UE receiving and processing transmissions. That is, the base station (BS) cannot assume that the UE will be listening to DL transmissions. The DRX configuration defines the transitions between states.

Typically, UEs that are not in Active Time turn off some of their components and enter a low-power (i.e., sleeping) mode. To ensure that the UE switches regularly to Active Time (i.e., wakes up), a DRX cycle is defined. This DRX cycle is controlled by two parameters:.

In addition to this basic cycle, the DRX procedures also define other conditions that may allow the UE to switch between Active Time and Inactive Time. For example, if a UE is expecting a retransmission from the gNB, the UE may enter Inactive Time (i.e., while the gNB prepares the retransmission) and then may enter Active Time (i.e., during a window in which the gNB may send the transmission).

It should be noted that the Active Time due to the DRX cycle is determined by the DRX configuration. In other words, it is easy to predict when the UE will be in Active Time for the DRX cycle (unless the UE is explicitly commanded to leave Active Time). In contrast, it is not easy to predict whether a UE is in Active Time due to other timers because their start/stop depends on the traffic of packets.

The DRX procedures are described in TS <NUM> as follows.

The MAC (medium access control) entity may be configured by RRC with a DRX functionality that controls the UE's PDCCH (physical downlink control channel) monitoring activity for the MAC entity's C-RNTI, CS-RNTI, INT-RNTI, SFI-RNTI, SP-CSI-RNTI, TPC-PUCCH-RNTI, TPC-PUSCH-RNTI, and TPC-SRS-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>.

RRC controls DRX operation by configuring the following parameters:.

When a DRX cycle is configured, the Active Time includes the time while:.

When DRX is configured, the MAC entity shall:.

It should be noted that if a UE multiplexes a CSI configured on PUCCH with other overlapping uplink control information(s) (UCI(s)) according to the procedure specified in TS <NUM> subclause <NUM>. <NUM> and this CSI multiplexed with other UCI(s) would be reported on a PUCCH resource outside DRX Active Time, it is up to UE implementation whether to report this CSI multiplexed with other UCI(s).

Regardless of whether the MAC entity is monitoring PDCCH or not, the MAC entity transmits HARQ feedback, aperiodic CSI on PUSCH, and aperiodic SRS defined in TS <NUM> when such is expected.

The MAC entity need 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).

In the upcoming Rel-<NUM>, 3GPP will work on enhancements for the NR SL. The ambition is not only to improve the capabilities of NR SL for V2X but also to address other UCs such as National Security and Public Safety (NSPS) as well as commercial UCs such as Network Controled Interactive Services (NCIS). In the future, the NR SL may be enhanced further to also address other UCs.

In V2X, User Equipments (UEs) are typically mounted in a car and have no important power restrictions. In contrast, NSPS or NCIS mostly use handheld UEs, for which energy efficiency is a concern. With this in mind, the Rel. <NUM> Work Item on NR sidelink enhancements (RP-<NUM>) includes the study and specification of SL DRX mechanism as one of its objectives. This includes defining SL DRX configurations and the corresponding UE procedure, specifying mechanisms to align sidelink DRX configurations among the UEs communicating with each other, and specifying mechanisms to align sidelink DRX configurations with Uu DRX configurations for an in-coverage UE. in the recent RAN2 meeting, it was agreed that Uu alike DRX configuration is applied to SL for SL unicast communication. For SL broadcast and groupcast, whether to apply Uu alike DRX configuration still remains open.

Resource pools define physical resources in time and frequency that carry sidelink control and traffic data. In the frequency domain, the resources are divided into subchannels where each subchannel consists of a set of contiguous resource blocks in a subframe or slot and different subchannels do not overlap. The subchannel sizes are determined based on convenient sizes for the Fast Fourier Transform (FFT) implementation. In the time domain, the resource pool is defined by a repeating bitmap that maps sidelink resources to all subframes or slots excluding some special subframes, for example the subframes or slots used for sidelink synchronization signal (SLSS) and physical sidelink broadcast channel (PSBCH). In the bitmap, "<NUM>" indicates that the subframe or slot contains resources that could be used for sidelink communication, and "<NUM>" indicates that the subframe or slot does not contain resources that could be used for sidelink communication. The bitmap is designed so that it is repeated an integer number of times within the system frame number (SFN) or direct frame number (DFN) range.

A UE is preconfigured with a set of resource pools which are used for sidelink communication when the UE is out of the NW coverage. When in the NW coverage, the resource pool is configured by the gNB via dedicated or common control signaling.

UE energy saving is one important performance indicator. In the 3GPP Rel-<NUM> WI on NR sidelink enhancement, the below objective on UE Sidelink energy saving has been agreed and will be studied during 3GPP Rel-<NUM> time frame.

Sidelink DRX for broadcast, groupcast, and unicast [RAN2].

In RAN2#<NUM>-e, RAN2 has made the below agreement regarding how to design timers for SL DRX.

As a baseline, for Sidelink DRX for SL unicast, it is proposed to inherit and use timers similar to what are used in Uu DRX. Sidelink DRX for SL broadcast/groupcast is open and under investigation and discussion. Detailed timers are open and under investigation and discussion.

According to the above agreement, a SL DRX configuration will contain similar timers as in Uu DRX to regulate the UE's active time. In Uu DRX, the timers are configured with semi-static absolute time values such as in number of ms, or number of slots. The UE is in active time when one of the timers such as drx-onDurationTimer or drx-InactivityTime is running.

SL DRX configuration will contain similar timers. However, a simple reusage of the above Uu rule (i.e., the timers are set to semi-static absolute time values) to handle the timers for SL DRX may not work.

On one hand, SL transmissions support a distributed s allocation mode compared to Uu, i.e., Mode <NUM> resource allocation. In other words, UE selects SL resources for a transmission autonomously. In this way, the UE may detect collision while selecting resources. In case of occurrence of high congestion in a resource pool, the UE may not be able to find free resources during an active time period.

On the other hand, SL transmissions are limited to SL resource pools, i.e., UE is allowed to perform SL transmissions or receptions within specified SL resource pools. A UE may not be allowed to perform SL transmissions or receptions while a SL drx-onDuration timer is running since there are no SL resources available during the period, e.g., there is no SL slot allocated during the period.

Therefore, it is necessary to develop corresponding solutions for SL DRX.

The present disclosure is described in the context of NR SL communications. However, most of the embodiments are in general applicable to any type of direct communications between UEs involving device-to-device (D2D) communications such as LTE SL. Embodiments are described from a TX (transmitter) UE and RX (receiver) UE point of view. Further, it is assumed that an SL UE and its serving gNB operate with the same radio access technology (RAT) e.g., NR, LTE, and so on. However, all the embodiments apply without loss of meaning to any combination of RATs between the SL UE and its serving gNB.

In the present disclosure, an SL DRX configuration denotes a set of parameters which determines the DRX behavior of a UE in SL communication, similar to the Uu DRX configuration. SL DRX parameters are not detailed in the present disclosure.

In this group, various embodiments are described on how to adapt SL DRX configuration according to measured SL congestion in terms of metrics which may include at least one of the following, e.g.:.

According to the present invention, a UE is configured to extend its DRX active time when measured SL congestion is increasing. The UE is configured to reduce its DRX active time when the measured SL congestion is decreasing. The active time could be increased/deceased by adjusting any one or more SL DRX parameters which may affect UE's active time such as for example:.

It should be noted that as an example we use the above parameters to stand for possible parameters for SL DRX. The embodiments are not limited to the examples. The names of actual parameters for SL DRX may be different. The number of parameters for SL DRX could also be different.

In the claimed invention, for an SL DRX configuration of the UE, when the measured SL congestion is above a certain level (e.g., a first configured threshold), the UE applies a secondary DRX cycle (e.g., short DRX cycle) during each existing DRX cycle (e.g., long DRX cycle) to extend its active time; and vice versa, when the measured SL congestion is below another certain level (e.g., a second configured threshold, which may be lower than the first configured threshold), the UE disables the secondary DRX cycle.

In the claimed invention, for an SL DRX configuration of the UE, when the measured SL congestion is above a certain level (e.g., a first configured threshold), the UE applies a secondary timer (e.g., second-OnDurationTimer or second-Inactivitytimer) during each existing DRX cycle (e.g., long DRX cycle) to extend its active time; and vice versa, when the measured SL congestion is below another certain level (e.g., a second configured threshold, which may be lower than the first configured threshold), the UE disables the secondary timer to reduce its active time.

In another embodiment, two UEs involved in SL unicast communication coordinate the SL DRX configuration adaptation via one of the following ways:.

The assistance info may be an absolute value or a degree of change compared to the value in the last sent assistance info.

In the above procedure, either a whole SL DRX configuration or only the SL DRX parameter(s) that are changed may be informed to the peer UE.

In another embodiment, multiple SL DRX configurations and/or multiple values for certain SL DRX parameters such as drx-onDurationTimer and/or drx-InactivityTimer etc. are (pre)configured. The UE could only select one of the SL DRX configurations and/or one of the values for the SL DRX parameters when adapting the SL DRX configuration. Each of the multiple SL DRX configurations and/or the multiple values for the SL DRX parameters may be associated with an index, and the UE only informs the index of the selected configuration and/or the selected parameter value to the peer UE when adapting the SL DRX configuration.

In another embodiment, the SL DRX configuration adaptation is only performed when there are GBR PC5 bearers configured between the two UEs.

In another embodiment, the SL DRX configuration could only be adapted once every m ms, where m is preconfigured or configured by the NW via dedicated or common signaling.

In another embodiment, the SL DRX parameters such as drx-onDurationTimer and/or drx-InactivityTimer, etc., could only be increased or decreased at most j% in every k ms, where j and k are preconfigured or configured by the NW via dedicated or common signaling.

In another embodiment, multiple m's, j's and k's are (pre)configured. Smaller m and/or smaller k and/or larger j are adopted when there are GBR PC5 bearers configured between the two UEs; otherwise, larger m and/or larger k and/or smaller j are adopted.

In another embodiment, the SL DRX timers such as drx-onDurationTimer, drx-InactivityTimer and drx-RetransmissionTimer, etc., are only started and running when they should be started and running according to the DRX configuration and during the SL subframes/slots in which SL communication is allowed. For example:.

A UE is only in an SL active state when the timers such as drx-onDurationTimer, drx-InactivityTimer and/or drx-RetransmissionTimer, etc., have been started and are not paused/expired/stopped.

In another embodiment, the SL DRX timers are counted in number of logical frames/slots/ms/ofdm (orthogonal frequency divisional multiplexing) symbols. Logical frames/slots/ms/ofdm symbols may be subset of all physical frames/slots/ms/ofdm symbols. They may be determined/positioned in time according to the SL resource configuration (e.g., the configuration is associated with one or more specific resource pools). As soon as the timer is started, the timer value may be only changed after each logical frame/slot/ms/ofdm symbol has elapsed. A UE may only be in the SL active state when in SL frames/slots and the timers such as drx-onDurationTimer, drx-InactivityTimer and drx-RetransmissionTimer, etc., have been started and are not expired/stopped.

With such an SL DRX operation, SL DRX could be configured independently of SL resource configuration, i.e. multiple resource pools could share the same SL DRX configuration. This can save signaling consumption as there is no need to coordinate SL DRX configuration when the resource pool is reconfigured.

<FIG> is a flow chart illustrating a method <NUM> implemented on a first terminal device according to some embodiments of the present disclosure. As an example, operations of this flow chart may be performed by a first UE which may perform adaptation of an SL DRX configuration (the above Group A), but they are not limited thereto. The operations in this and other flow charts will be described with reference to the exemplary embodiments of the other figures. However, it should be appreciated that the operations of the flow charts may be performed by embodiments of the present disclosure other than those discussed with reference to the other figures, and the embodiments of the present disclosure discussed with reference to these other figures may perform operations different than those discussed with reference to the flow charts.

In one embodiment, the first UE may adapt an SL DRX configuration based on measured SL congestion (block <NUM>). The measured SL congestion may be measured in a resource pool.

As an example, the SL congestion may be measured in terms of metrics including at least one of:.

The active time may be extended or reduced by adjusting SL DRX parameters for the SL DRX configuration.

The SL DRX parameters may include at least one of:.

In a variant, the active time may be extended by applying a secondary DRX cycle during each existing DRX cycle when the measured SL congestion is above a first configured threshold, and the active time may be reduced by disabling the secondary DRX cycle when the measured SL congestion is below a second configured threshold.

As a further example, the active time may be extended by applying a secondary timer during each existing DRX cycle when the measured SL congestion is above a first configured threshold, and the active time may be reduced by disabling the secondary timer when the measured SL congestion is below a second configured threshold.

As an example, the method <NUM> may further comprise:.

As a further example, the method <NUM> may further comprise:
using a previous SL DRX configuration when the rejection of the adaptation is received.

As a further example, the method <NUM> may further comprise:
receiving assistance information about the SL DRX configuration from the second UE prior to transmitting the signaling.

As a further example, the assistance information may include at least one of:.

As a further example, the assistance information may be an absolute value or a degree of change as compared to a value of immediately previously received assistance information.

As a further example, the signaling may comprise a whole SL DRX configuration or may comprise only one or more changed SL DRX parameters for the SL DRX configuration.

As an example, the method <NUM> may further comprise:
when adapting a plurality of SL DRX configurations, selecting one of the SL DRX configurations and/or one of values of SL DRX parameters for the SL DRX configurations.

As a further example, the signaling may comprise an index associated with each of the plurality of SL DRX configurations and/or the values of the SL DRX parameters for the SL DRX configurations.

As an example, the SL DRX configuration may be adapted only when GBR PC5 bearers are configured between the first UE and a second UE.

As an example, the SL DRX configuration may be adapted according to a first configured interval.

As a further example, the SL DRX parameters for the SL DRX configuration may be adjusted within a configured percent according a second configured interval.

As a further example, when the GBR PC5 bearers are configured between the first UE and a second UE, the first interval and/or the second interval may be configured as smaller values and the percent is configured as a larger value, and when the GBR PC5 bearers are not configured between the first UE and a second UE, the first interval and/or the second interval may be configured as larger values and the percent may be configured as a smaller value.

As an example, parameters for the adaptation of the SL DRX configuration may be configured by a control node or preconfigured.

As a further example, the control node may be a gNB, or a controlling UE, or a combination of the gNB and the controlling UE.

Furthermore, the present disclosure provides a first terminal device which is adapted to perform the method <NUM>.

<FIG> is a flow chart illustrating a method <NUM> implemented on a second terminal device according to some embodiments of the present disclosure. As an example, operations of this flow chart may be performed by a second UE which may be informed by the first UE of the SL DRX configuration.

In one embodiment, the second UE may receive a signaling indicating adaption of an SL DRX configuration from a first UE, the adaption of the SL DRX configuration being performed based on measured SL congestion (block <NUM>). The second UE may transmit an acceptance or rejection of the adaptation to the first UE (block <NUM>).

As an example, the method <NUM> may further comprise:
transmitting assistance information about the SL DRX configuration to the first UE prior to receiving the signaling.

As a further example, the assistance information may be an absolute value or a degree of change as compared to a value of immediately previously transmitted assistance information.

As an example, the signaling may comprise a whole SL DRX configuration or may comprise only one or more changed SL DRX parameters for the SL DRX configuration.

As an example, the signaling may comprise an index associated each of a plurality of adapted SL DRX configurations and/or the values of the SL DRX parameters for the adapted SL DRX configurations.

Furthermore, the present disclosure provides a second terminal device which is adapted to perform the method <NUM>.

<FIG> is a flow chart illustrating a method <NUM> implemented on a third terminal device according to some embodiments of the present disclosure. As an example, operations of this flow chart may be performed by a third UE which may perform an SL DRX operation by considering the SL resource configuration (the above Group B).

In one embodiment, the third UE may start one or more SL DRX timers in an SL DRX slot (block <NUM>).

As a further example, the third UE may be in a DRX inactive state when the one or more SL DRX timers are paused.

As an example, the one or more SL DRX timers may be counted in number of logical slot symbols which are a subset of all physical slot symbols.

As a further example, the logical slot symbols may be positioned in time based on an SL resource configuration.

As a further example, in the case that the one or more SL DRX timers are started, one or more values of the one or more SL DRX timers may be changed only after each of the logical slot symbols has elapsed.

As an example, configurations for the third UE may be signaled by a control node or preconfigured.

Furthermore, the present disclosure provides a third terminal device which is adapted to perform the method <NUM>.

<FIG> is a flow chart illustrating a method <NUM> implemented on a control node according to some embodiments of the present disclosure. As an example, operations of this flow chart may be performed by a control node which may provide configurations for at least the method <NUM> of <FIG> and the method <NUM> of <FIG>.

In one embodiment, the control node may provide parameters for adaption of an SL DRX configuration of the method <NUM> (block <NUM>), or provide configurations for the method <NUM> (block <NUM>).

As an example, the parameters may include a first configured threshold and a second configured threshold. As a further example, active time of a UE may be extended when measured SL congestion is above the first configured threshold, and the active time may be reduced when the measured SL congestion is below the second configured threshold.

As an example, the parameters may include:
a first configured interval, according to which the SL DRX configuration is adapted.

As an example, the parameters may include a second configured interval and a configured percent. As a further example, SL DRX parameters for the SL DRX configuration may be adjusted within the configured percent according the second configured interval.

As an example, the provided configurations may include an SL resource configuration.

As an example, the control node may be a gNB, or a controlling UE, or a combination of the gNB and the controlling UE.

Furthermore, the present disclosure provides a control node which is adapted to perform the method <NUM>.

<FIG> is a block diagram illustrating a first terminal device <NUM> according to some embodiments of the present disclosure. As an example, the first terminal device <NUM> may act as a first UE which may perform adaptation of an SL DRX configuration (the above Group A), but it is not limited thereto. It should be appreciated that the first terminal device <NUM> may be implemented using components other than those illustrated in <FIG>.

With reference to <FIG>, the first terminal device <NUM> may comprise at least a processor <NUM>, a memory <NUM>, a network interface <NUM> and a communication medium <NUM>. The processor <NUM>, the memory <NUM> and the network interface <NUM> may be communicatively coupled to each other via the communication medium <NUM>.

The processor <NUM> may include one or more processing units. A processing unit may be a physical device or article of manufacture comprising one or more integrated circuits that read data and instructions from computer readable media, such as the memory <NUM>, and selectively execute the instructions. In various embodiments, the processor <NUM> may be implemented in various ways. As an example, the processor <NUM> may be implemented as one or more processing cores. As another example, the processor <NUM> may comprise one or more separate microprocessors. In yet another example, the processor <NUM> may comprise an application-specific integrated circuit (ASIC) that provides specific functionality. In still another example, the processor <NUM> may provide specific functionality by using an ASIC and/or by executing computer-executable instructions.

The memory <NUM> may include one or more computer-usable or computer-readable storage medium capable of storing data and/or computer-executable instructions. It should be appreciated that the storage medium is preferably a non-transitory storage medium.

The network interface <NUM> may be a device or article of manufacture that enables the first terminal device <NUM> to send data to or receive data from other devices. In different embodiments, the network interface <NUM> may be implemented in different ways. As an example, the network interface <NUM> may be implemented as an Ethernet interface, a token-ring network interface, a fiber optic network interface, a network interface (e.g., Wi-Fi, WiMax, etc.), or another type of network interface.

The communication medium <NUM> may facilitate communication among the processor <NUM>, the memory <NUM> and the network interface <NUM>. The communication medium <NUM> may be implemented in various ways. For example, the communication medium <NUM> may comprise a Peripheral Component Interconnect (PCI) bus, a PCI Express bus, an accelerated graphics port (AGP) bus, a serial Advanced Technology Attachment (ATA) interconnect, a parallel ATA interconnect, a Fiber Channel interconnect, a USB bus, a Small Computing System Interface (SCSI) interface, or another type of communications medium.

In the example of <FIG>, the instructions stored in the memory <NUM> may include those that, when executed by the processor <NUM>, cause the first terminal device <NUM> to implement the method described with respect to <FIG>.

<FIG> is another block diagram illustrating a first terminal device <NUM> according to some embodiments of the present disclosure. As an example, the first terminal device <NUM> may act as a first UE which may perform adaptation of an SL DRX configuration (the above Group A), but it is not limited thereto. It should be appreciated that the first terminal device <NUM> may be implemented using components other than those illustrated in <FIG>.

With reference to <FIG>, the first terminal device <NUM> may comprise at least an adaptation unit <NUM>. The adaptation unit <NUM> may be adapted to perform at least the operation described in the block <NUM> of <FIG>.

<FIG> is a block diagram illustrating a second terminal device <NUM> according to some embodiments of the present disclosure. As an example, the second terminal device <NUM> may act as a second UE which may be informed by the first UE of the SL DRX configuration, but it is not limited thereto. It should be appreciated that the second terminal device <NUM> may be implemented using components other than those illustrated in <FIG>.

With reference to <FIG>, the second terminal device <NUM> may comprise at least a processor <NUM>, a memory <NUM>, a network interface <NUM> and a communication medium <NUM>. The processor <NUM>, the memory <NUM> and the network interface <NUM> are communicatively coupled to each other via the communication medium <NUM>.

The processor <NUM>, the memory <NUM>, the network interface <NUM> and the communication medium <NUM> are structurally similar to the processor <NUM>, the memory <NUM>, the network interface <NUM> and the communication medium <NUM> respectively, and will not be described herein in detail.

In the example of <FIG>, the instructions stored in the memory <NUM> may include those that, when executed by the processor <NUM>, cause the second terminal device <NUM> to implement the method described with respect to <FIG>.

<FIG> is another block diagram illustrating a second terminal device <NUM> according to some embodiments of the present disclosure. As an example, the second terminal device <NUM> may act as a second UE which may be informed by the first UE of the SL DRX configuration, but it is not limited thereto. It should be appreciated that the second terminal device <NUM> may be implemented using components other than those illustrated in <FIG>.

With reference to <FIG>, the second terminal device <NUM> may comprise at least a receiving unit <NUM> and a transmission unit <NUM>. The receiving unit <NUM> may be adapted to perform at least the operation described in the block <NUM> of <FIG>. The transmission unit <NUM> may be adapted to perform at least the operation described in the block <NUM> of <FIG>.

<FIG> is a block diagram illustrating a third terminal device <NUM> according to some embodiments of the present disclosure. As an example, the third terminal device <NUM> may act as a third UE which may perform an SL DRX operation by considering the SL resource configuration (the above Group B), but it is not limited thereto. It should be appreciated that the third terminal device <NUM> may be implemented using components other than those illustrated in <FIG>.

With reference to <FIG>, the third terminal device <NUM> may comprise at least a processor <NUM>, a memory <NUM>, a network interface <NUM> and a communication medium <NUM>. The processor <NUM>, the memory <NUM> and the network interface <NUM> are communicatively coupled to each other via the communication medium <NUM>.

The processor <NUM>, the memory <NUM>, the network interface <NUM> and the communication medium <NUM> are structurally similar to the processor <NUM> or <NUM>, the memory <NUM> or <NUM>, the network interface <NUM> or <NUM> and the communication medium <NUM> or <NUM> respectively, and will not be described herein in detail.

In the example of <FIG>, the instructions stored in the memory <NUM> may include those that, when executed by the processor <NUM>, cause the third terminal device <NUM> to implement the method described with respect to <FIG>.

<FIG> is another block diagram illustrating a third terminal device <NUM> according to some embodiments of the present disclosure. As an example, the third terminal device <NUM> may act as a third UE which may perform an SL DRX operation by considering the SL resource configuration (the above Group B), but it is not limited thereto. It should be appreciated that the third terminal device <NUM> may be implemented using components other than those illustrated in <FIG>.

With reference to <FIG>, the third terminal device <NUM> may comprise at least a starting unit <NUM>. The starting unit <NUM> may be adapted to perform at least the operation described in the block <NUM> of <FIG>.

<FIG> is a block diagram illustrating a control node <NUM> according to some embodiments of the present disclosure. As an example, the control node <NUM> may provide configurations for at least the method <NUM> of <FIG> and the method <NUM> of <FIG>, but it is not limited thereto. It should be appreciated that the control node <NUM> may be implemented using components other than those illustrated in <FIG>.

With reference to <FIG>, the control node <NUM> may comprise at least a processor <NUM>, a memory <NUM>, a network interface <NUM> and a communication medium <NUM>. The processor <NUM>, the memory <NUM> and the network interface <NUM> are communicatively coupled to each other via the communication medium <NUM>.

The processor <NUM>, the memory <NUM>, the network interface <NUM> and the communication medium <NUM> are structurally similar to the processor <NUM>, <NUM> or <NUM>, the memory <NUM>, <NUM> or <NUM>, the network interface <NUM>, <NUM> or <NUM> and the communication medium <NUM>, <NUM> or <NUM> respectively, and will not be described herein in detail.

In the example of <FIG>, the instructions stored in the memory <NUM> may include those that, when executed by the processor <NUM>, cause the control node <NUM> to implement the method described with respect to <FIG>.

<FIG> is another block diagram illustrating a control node <NUM> according to some embodiments of the present disclosure. As an example, the control node <NUM> may provide configurations for at least the method <NUM> of <FIG> and the method <NUM> of <FIG>, but it is not limited thereto. It should be appreciated that the control node <NUM> may be implemented using components other than those illustrated in <FIG>.

With reference to <FIG>, the control node <NUM> may comprise at least a providing unit <NUM>. The providing unit <NUM> may be adapted to perform at least the operations described in the blocks <NUM> and <NUM> of <FIG>.

The units shown in <FIG>, <FIG>, <FIG> and <FIG> may constitute machine-executable instructions embodied within a machine, e.g., readable medium, which when executed by a machine will cause the machine to perform the operations described. Besides, any of these units may be implemented as hardware, such as an application specific integrated circuit (ASIC), Digital Signal Processor (DSP), Field Programmable Gate Array (FPGA) or the like.

Moreover, it should be appreciated that the arrangements described herein are set forth only as examples. Other arrangements (e.g., more controllers or more detectors, etc.) may be used in addition to or instead of those shown, and some units may be omitted altogether. Functionality and cooperation of these units are correspondingly described in more detail with reference to <FIG>.

<FIG> is a block diagram illustrating a wireless communication system <NUM> according to some embodiments of the present disclosure. The wireless communication system <NUM> comprises at least a first terminal device <NUM>, a second terminal device <NUM> and a control node <NUM>. In one embodiment, the first terminal device <NUM> may act as the first terminal device <NUM> or <NUM> as depicted in <FIG>, the second terminal device <NUM> may act as the second terminal device <NUM> or <NUM> as depicted in <FIG>, and the control node <NUM> may act as the control node <NUM> or <NUM> as depicted in <FIG>. In one embodiment, the first terminal device <NUM>, the second terminal device <NUM> and the control node <NUM> may communicate with each other.

<FIG> is a block diagram illustrating a wireless communication system <NUM> according to some embodiments of the present disclosure. The wireless communication system <NUM> comprises at least a third terminal device <NUM> and a control node <NUM>. In one embodiment, the third terminal device <NUM> may act as the third terminal device <NUM> or <NUM> as depicted in <FIG>, and the control node <NUM> may act as the control node <NUM> or <NUM> as depicted in <FIG>. In one embodiment, the third terminal device <NUM> and the control node <NUM> may communicate with each other.

<FIG> is a block diagram schematically illustrating a telecommunication network connected via an intermediate network to a host computer.

With reference to <FIG>, in accordance with an embodiment, a communication system includes a telecommunication network <NUM>, such as a 3GPP-type cellular network, which comprises an access network <NUM>, such as a radio access network, and a core network <NUM>. The access network <NUM> comprises a plurality of base stations 1512a, 1512b, 1512c, such as NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area 1513a, 1513b, 1513c. Base stations 1512a, 1512b, 1512c can be control nodes, such as control nodes <NUM>, <NUM> and <NUM> of <FIG> and <FIG>. Each base station 1512a, 1512b, 1512c is connectable to the core network <NUM> over a wired or wireless connection <NUM>. A first user equipment (UE) <NUM> located in coverage area 1513c is configured to wirelessly connect to, or be paged by, the corresponding base station 1512c. A second UE <NUM> in coverage area 1513a is wirelessly connectable to the corresponding base station 1512a. UEs <NUM>, <NUM> can be terminal devices, such as terminal devices <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> and <NUM> of <FIG>, <FIG>.

It is noted that the host computer <NUM>, base station <NUM> and UE <NUM> illustrated in <FIG> may be identical to the host computer <NUM>, one of the base stations 1512a, 1512b, 1512c and one of the UEs <NUM>, <NUM> of <FIG>, respectively.

The wireless connection <NUM> between the UE <NUM> and the base station <NUM> is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to the UE <NUM> using the OTT connection <NUM>, in which the wireless connection <NUM> forms the last segment. More precisely, the teachings of these embodiments may improve the radio resource utilization and thereby provide benefits such as reduced user waiting time.

Some portions of the foregoing detailed description have been presented in terms of algorithms and symbolic representations of transactions on data bits within a computer memory. These algorithmic descriptions and representations are ways used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of transactions leading to a desired result. The transactions are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated.

It should be appreciated, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the above discussion, it is appreciated that throughout the description, discussions utilizing terms such as "processing" or "computing" or "calculating" or "determining" or "displaying" or the like, refer to actions and processes of a computer system, or a similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method transactions. In addition, embodiments of the present disclosure are not described with reference to any particular programming language. It should be appreciated that a variety of programming languages may be used to implement the teachings of embodiments of the present disclosure as described herein.

An embodiment of the present disclosure may be an article of manufacture in which a non-transitory machine-readable medium (such as microelectronic memory) has stored thereon instructions (e.g., computer code) which program one or more data processing components (generically referred to here as a "processor") to perform the operations described above. In other embodiments, some of these operations might be performed by specific hardware components that contain hardwired logic (e.g., dedicated digital filter blocks and state machines). Those operations might alternatively be performed by any combination of programmed data processing components and fixed hardwired circuit components.

In the foregoing detailed description, embodiments of the present disclosure have been described with reference to specific exemplary embodiments thereof. It will be evident that various modifications may be made thereto without departing from the scope of the present disclosure as set forth in the following claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.

Claim 1:
A method (<NUM>) implemented by a first terminal device (<NUM>, <NUM>, <NUM>), the method comprising:
adapting (<NUM>) a sidelink discontinuous reception, SL DRX, configuration based on measured sidelink, SL, congestion characterised by:
extending active time of the first terminal device (<NUM>, <NUM>, <NUM>) when the measured SL congestion is increasing; and
reducing the active time of the first terminal device (<NUM>, <NUM>, <NUM>) when the measured SL congestion is decreasing,
wherein the active time is extended by applying a secondary DRX cycle during each existing DRX cycle when the measured SL congestion is above a first configured threshold, and the active time is reduced by disabling the secondary DRX cycle when the measured SL congestion is below a second configured threshold, or
wherein the active time is extended by applying a secondary timer during each existing DRX cycle when the measured SL congestion is above a first configured threshold, and the active time is reduced by disabling the secondary timer when the measured SL congestion is below a second configured threshold.