Patent Description:
Wireless communication may take place between terminal devices via an access node. Such communication may be seen as a hierarchical communication. While it has its benefits, there may also be communication taking place directly between two or more devices without having an access node in-between. Publication <CIT> discloses a method of overbooking transmission resources for sidelink communication retransmissions. After a first UE has reserved transmission & retransmission resources for a sidelink transmission, a second UE may also reserve the retransmission resources for a sidelink communication transmission from the second UE. Such overbooking may be enabled by system configuration, or by RRC configuration messages. The permitted overbooking may vary by retransmission number such that different overbooking is permitted depending on how the retransmission number.

Document <CIT> discloses another example of the prior art.

The scope of protection sought for various embodiments is set out by the independent claims. Dependent claims define further embodiments included in the scope of protection. The exemplary embodiments and features, if any, described in this specification that do not fall under the scope of the independent claims are to be interpreted as examples useful for understanding various embodiments of the invention.

In the following, the exemplary embodiments will be described in greater detail with reference to the embodiments and the accompanying drawings, in which.

The techniques and methods described herein may be implemented by various means. For example, these techniques may be implemented in hardware (one or more devices), firmware (one or more devices), software (one or more modules), or combinations thereof. For a hardware implementation, the apparatus(es) of embodiments may be implemented within one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), graphics processing units (GPUs), processors, controllers, microcontrollers, microprocessors, other electronic units designed to perform the functions described herein, or a combination thereof. For firmware or software, the implementation can be carried out through modules of at least one chipset (e.g. procedures, functions, and so on) that perform the functions described herein. The software codes may be stored in a memory unit and executed by processors. The memory unit may be implemented within the processor or externally to the processor. In the latter case, it can be communicatively coupled to the processor via any suitable means.

Sidelink communication may be understood as communication between terminal devices in which the terminal devices connect to each other directly without an access node involvement, in other words, without relaying the data via a network such as a cellular communication network. Such terminal devices may be of any suitable type such as mobile phones, vehicles, robots or wearable consumer electronic devices. Sidelink communication may be enabled by <NUM> and/or <NUM> technology. Sidelink communication may be beneficial for example to allow devices with close proximity to each other to discover and connect to each other at high data rates and low latency. This may be useful for example in peer-to-peer gaming, vehicle platooning, etc. Also enhanced augmented reality and/or virtual reality may benefit from sidelink communication.

In sidelink communication, resource allocations as well as link adaptation are controlled by the terminal devices independently, which allows more control over usage of its resources to a terminal device. As sidelink communication allows reduction in latency due to being restricted to one hop, it may be useful for example in mission-critical industrial applications.

If sidelink discontinuous reception, DRX, is not standardized/used, then it may be that a terminal device receiving sidelink transmission is to monitor and be awake for a possible transmission to be received all the time, which consumes a lot of battery power. As a number of services used in sidelink communication allow periodic transmissions from a transmitting, Tx, terminal device to a receiving, Rx, terminal device, this periodic manner may be taken into account in sidelink design. For example, <NUM> sidelink and <NUM> vehicle to everything have taken the periodic manner of sidelink transmission into account in their design. Thus, for example a Tx terminal device using sidelink for its transmission may transmit sidelink control information, SCI, to indicate its transmission periodicity and future periodic resources that will be used for its (re)transmissions to the Rx terminal device.

As described above, a terminal device participating in sidelink communication participates in managing its sidelink resource allocation and/or sidelink resource selection as well. Therefore, if a Tx terminal device is to periodically transmit transmissions for a service to a Rx terminal device, traffic pattern and characteristics of the traffic are to be taken into account in periodic resource allocation or periodic resource selection. Examples of traffic pattern and characteristics comprise for example generation time of data, its periodicity, size and quality of service requirement. If the Rx terminal device receives from the Tx terminal device an SCI indicating and reserving future transmission resources, it is then aware of the transmissions that are to take place and may monitor resources correspondingly to be able to receive the transmissions from the Tx terminal device. Alternatively, the Rx terminal device may receive an indication indicative of one or more sidelink resources from the Tx terminal device and based on that indication, the Rx terminal device may reserve the one or more sidelink resources for future transmissions from the Tx terminal device.

It is to be noted that the future transmissions may be considered as subsequent or expected transmissions as well. The transmissions over the indicated/reserved resources may be used for periodic transmissions and/or re-transmissions. This allows the Rx terminal device to limit monitoring of sidelink transmissions to the resources indicated in the SCI which allows its power to be saved.

<FIG> illustrates an exemplary embodiment of sidelink communication between terminal devices <NUM>, <NUM> and <NUM>. In this exemplary embodiment the terminal devices <NUM>, <NUM> and <NUM> are mobile phones, but other terminal devices and/or network infrastructures could also be used. In this exemplary embodiment terminal device <NUM> receives sidelink transmissions of data from both the terminal device <NUM> and the terminal device <NUM>, which in this exemplary embodiment act as Tx terminal devices.

<FIG> illustrates an exemplary embodiment of transmissions that take place between the terminal devices introduced in the exemplary embodiment illustrated in <FIG>. The initial sidelink transmissions <NUM> are assumed to have occurred already in the context of this exemplary embodiment. Those may have occurred for example during time period <NUM> that corresponds to a sidelink, SL, discontinuous reception, DRX, on-duration of the terminal device <NUM>. The horizontal axis t in the <FIG> illustrates time. As is illustrated, the terminal device <NUM> has received a first sidelink transmission, SL TX, <NUM>, from the terminal device <NUM> and a first SL TX <NUM> from the terminal device <NUM>.

In SL TX <NUM> the terminal device <NUM> may provide an indication regarding future reserved resources for its subsequent SL transmissions and/or re-transmissions. Also, in SL TX <NUM> the terminal device <NUM> may provide an indication regarding future reserved resources for its subsequent SL transmissions and/or re-transmissions. The indications may be provided for example by using information elements, IEs, e.g. frequency resource assignment, time resource assignment, and/or resource reservation period. These IEs may thus be carried in the first transmissions, e.g. the associated SCIs of the first transmissions, and thereby after receiving the SCIs and/or data packets in the SL TX <NUM> and SL TX <NUM>, the terminal device <NUM> has knowledge of the future resources that will be used by the terminal devices <NUM> and <NUM> for their transmissions towards the terminal device <NUM>. After that, the terminal device <NUM> may limit the monitoring it performs regarding the sidelink transmissions to the indicated resources. In this exemplary embodiment therefore, after receiving the SL TX <NUM> and SL TX <NUM>, the terminal device <NUM> may monitor the resources for SL TX <NUM>, <NUM>, <NUM> and <NUM> and thereby achieve power savings. The power savings may be achieved for a limited period of time, for example until the reserved resources are not valid anymore or until its next SL DRX On-duration of the terminal device <NUM>. It is to be noted that optionally the SL TX <NUM> may indicate future sidelink resource reservation for SL TX <NUM> and the SL TX <NUM> may indicate future sidelink resource reservation for <NUM>. In addition, there may be one or more (re)transmission(s) over one or more indicated/reserved resource(s) between SL TX <NUM> and SL TX <NUM>, as well as SL TX <NUM> and SL TX <NUM>, which are not shown in <FIG>.

However, there may be situations in which a transmitting terminal device cannot transmit a sidelink transmission over resources reserved for a transmission, because of for example other communication activities overlapping in time domain. Therefore, in this exemplary embodiment, the terminal device <NUM> is not able to transmit the expected SL TX <NUM> while the terminal device <NUM> is still able to transmit the expected SLT TX <NUM>. It may be for example that sidelink logical channel prioritization, LCP, procedure executed in medium access control, MAC, layer, the physical-layer SL prioritization procedure, the SL resource pre-emption procedure, and/or the SL resource re-evaluation procedure may cause the terminal device <NUM> to skip the SL TX <NUM> over the expected resource to the terminal device <NUM>.

If a SL TX is not transmitted during the reserved resources and it is known that the receiving terminal device may not monitor for sidelink transmissions outside the reserved resources, this situation is to be addressed. Options for addressing the situation may include various approaches. For example, the SL TX that was not transmitted may be postponed until the next reserved/indicated sidelink resource. This may however cause additional latency that may lead to an expiry of a packet delay budget, PDB. Also, the transmitting terminal device may even throw away the delayed packet, which causes a packet loss. As another example, the SL TX that was not transmitted may be postponed until the next SL DRX On-duration of the receiving terminal device. It may be that the next SL DRX On-duration is scheduled to occur earlier than the next reserved/indicated SL resources for the SL TX. Yet, this may also cause additional latency and even a packet loss. It is to be noted though that for reasons of saving power consumption the SL DRX On-duration may occur with a larger interval than the interval of two reserved/indicated SL resources. It is also to be noted that since there might be multiple peer SL transmitting terminal devices, this issue to be addressed may occur for multiple peer SL transmitting terminal devices towards a single receiving terminal device.

<FIG> illustrates the claimed embodiment in which the above-mentioned issue is addressed. When a terminal device is not able to perform a SL TX in the resource indicated in an SCI associated with a previous transmission transmitted by the terminal device, a complementary resource set, CRS, for sidelink transmission, and its configured and/or associated SL CRS window, that may occur outside of the DRX On-duration of a receiving terminal device may be introduced to perform the SL TX.

In the claimed embodiment, if a terminal device is expected to be a receiving terminal device for a sidelink transmission from a transmitting terminal device, it provides an indication of a sidelink CRS, SL-CRS, that is associated with the receiving terminal device, to the transmitting terminal device. The terminal device that is expected to be a receiving terminal device then monitors the SL-CRS window if it does not receive a SL TX from the transmitting terminal device over a reserved/indicated SL resource as expected. It is noted, the SL TX may contain an initial transmission or a retransmission.

In this exemplary embodiment there is a receiving terminal device that receives sidelink transmissions from two transmitting terminal devices, a first transmitting terminal device and a second transmitting terminal device. It is to be noted that in some other exemplary embodiments there may be another number of transmitting and/or receiving terminal devices. In this exemplary embodiment, the receiving terminal device has received from the first transmitting terminal device a transmission <NUM> and from the second transmitting terminal device a transmission <NUM>. In the transmission <NUM> the first transmitting device has provided an indication regarding resources for its future transmissions such as <NUM>. Also, the second transmitting terminal device has provided an indication regarding resources reserved for its future transmissions such as <NUM> in the transmission <NUM>. Thus, the receiving terminal device has received an indication, from both transmitting devices, regarding resources for their futures sidelink transmissions and may thus expect to receive a sidelink transmission, SL TX, from each of the transmitting devices, accordingly. If the first transmitting terminal device does not transmit a SL TX <NUM> over the indicated resource, as expected, the first transmitting terminal device may then use the next SL-CRS window of the receiving terminal device to transmit the transmission that was supposed to be received as the SL TX <NUM>. The next SL-CRS window in this exemplary embodiment is illustrated as <NUM> and it may be extended, if needed, by <NUM>. It is to be noted, the SL-CRS window(s) <NUM> and/or <NUM> may contain continuous or discontinuous resources in time domain and/or frequency domain.

Correspondingly, if the receiving terminal device determines that it has not received the SL TX <NUM> during the reserved/indicated resource, then it may determine to be awake and monitor during the SL-CRS window <NUM>, which is its next SL-CRS window. As such, monitoring a SL-CRS window by the receiving terminal device depends, in this exemplary embodiment, on if the SL data transmission from a peer transmitting terminal device took place over its pre-indicated resource. On the other hand, if the SL data transmission from the peer transmitting terminal device is detected over the pre-indicated resources, then, in this exemplary embodiment, the receiving terminal device will not spend additional power in order to monitor its next SL-CRS window.

In general, a terminal device may have one or more peer terminal devices among which it communicates using sidelink communication. The terminal device may be considered as a receiving terminal device and the one or more peer terminal device may be considered as transmitting terminal devices. The terminal devices are then configured with one or more SL-CRSs associated with the receiving terminal device. A SL-CRS associated with the receiving terminal device may comprise for example one or more of the following characteristics: a default size of the SL-CRS window; an extendable size of the SL-CRS window; time-and/or-frequency location information of the SL-CRS window, which may be either fixed and the same for the transmitting terminal devices or shifted with a configured time offset to the indicated SL resource that has been indicated by a transmitting terminal device but not used as expected for a SL TX; a criterion/requirement for using the SL-CRS, for example based on service type, transmission periodicity, priority, and/or quality of service, QoS; a method to use the SL-CRS (window), such as transmitting a SL data transmission, a SL control information, and/or a resource indicator associated to an expected SL data transmission, which is to take place in future. Based on how the SL-CRS is used and/or the SL channel condition, the size of the SL-CRS window may optionally be extended.

If the transmitting terminal device having indicated SL resources for its transmissions towards the receiving terminal device cannot transmit towards the receiving terminal device in the indicated SL resource, the transmitting terminal device determines the next SL-CRS window of the peer receiving terminal device and attempts to transmit to the receiving terminal device within the determined SL-CRS window. If there are multiple SL-CRS configurations associated with the receiving terminal device, the transmitting terminal device may determine the SL-CRS window to be used for the missed SL TX based on criterions and/or requirements associated with the different SL-CRS configurations and the missed SL TX. Transmission to the receiving terminal device within the determined SL-CRS window may be based on a method associated with the determined SL-CRS window. A method associated with a window may be understood to be a manner or a way of using the sidelink complementary resource set window.

If the receiving terminal device does not receive a transmission from its peer transmitting terminal device over an indicated SL resource, it may determine to monitor the next SL-CRS window associated with it, for example based on the SL-CRS configuration. Determining and monitoring the next SL-CRS window may further depend on the SL radio condition of the previous and/or last one or more reception from the transmitting terminal device. For example, the receiving terminal device may determine to monitor the next SL-CRS window, if the receiving terminal device does not receive a transmission from its peer transmitting terminal device over an indicated SL resource and the radio condition of the previous and/or last reception(s) is above a configured threshold.

<FIG> illustrates a signalling chart of an exemplary embodiment. In this exemplary embodiment, sidelink communication occurs between a transmitting terminal device <NUM> and a receiving terminal device <NUM>. In this exemplary embodiment, via the sidelink communication and/or communication with network, both the terminal device <NUM> and the terminal device <NUM> may obtain a configuration regarding a SL-CRS associated with the terminal device <NUM>. In other words, the terminal devices are configured <NUM> with the SL-CRS associated with the terminal device <NUM>. The SL-CRS may be considered as part of the SL DRX configuration of the terminal device <NUM> for example. The configuration may comprise one or more of the following: a size of the SL-CRS window, which may be a default size; location information regarding the SL-CRS window in time-and/or-frequency domain, such as periodically fixed for different terminal devices, or flexibly shifted with a configured time offset to an indicated SL resource that was then not used for SL TX; a criterion and/or requirement for using the SL-CRS, such as based on service type, transmission periodicity, and/or QoS; a method to use the SL-CRS window, such as transmitting a SL data, a SL control information, and/or a resource indicator associated to the to-be-transmitted SL data. It is to be noted that the size and the location information of the SL-CRS window configuration determines the SL-CRS window(s), which may not overlap with the SL DRX On-duration of the terminal device <NUM>. It is to be noted that the SL-CRS window may occur between a sidelink resource reserved but missed and a following sidelink resource reserved by the terminal device <NUM> or a following DRX active period, e.g. the following SL DRX On-duration, of the terminal device <NUM>.

The SL-CRS may be configured, in this exemplary embodiment, by using coordination between the terminal device <NUM> and the terminal device <NUM> or by using coordination from the terminal device <NUM> to the terminal device <NUM>. For example, the terminal device <NUM> derives its SL-CRS configuration and indicates it to the terminal device <NUM>, which optionally may be based on a request from the terminal device <NUM>. The SL-CRS configuration may be indicated for example together with other SL DRX configurations by using for example PC5-signalling or PC5-radio resource control message, MAC control element, CE, and/or SCI. Alternatively, the configuration may be indicated separately from other SL DRX configuration. The coordination may further take into account additional information that may be provided by a base station and/or a technical specification. For example, the terminal devices <NUM> and <NUM> may be provisioned or configured by the base station with a policy and/or assistance information to derive the SL-CRS configuration. In another example, the SL-CRS configuration associated with the terminal device <NUM> may be obtained from a base station.

In some other exemplary embodiments, the SL-CRS configuration may be configured by a fixed mapping, where the mapping may consider the character(s) of the missed SL TX. For example, the terminal device <NUM> and <NUM> may each determine the SL-CRS associated with the terminal device <NUM> by considering the service type to be transmitted, the QoS requirement, IE(s) transmitted in the SCI, and/or identifier(s), ID(s), of the terminal device <NUM> and/or the terminal device <NUM> of the considered PC5 transmission. In such a case, the terminal devices <NUM> and <NUM> do not need to use additional signalling to exchange the SL-CRS configurations, since the SL-CRS configurations may be derived by the terminal device(s) implicitly. The mapping may be configured by a specification, by implementation of the terminal device, and/or by an access node, for example via dedicated signalling or broadcasted system information block, SIB.

In yet some other exemplary embodiments, multiple peer SL transmitting terminal devices may be configured with the same SL-CRS configuration as that of a receiving terminal device, such as one or more fixed SL-CRS windows used by the receiving terminal device to receive from the multiple transmitting terminal devices. Thus, the receiving terminal device may limit its monitoring to monitor one SL-CRS window in case multiple transmitting terminal devices cannot use their indicated resources.

In some other exemplary embodiments, the SL-CRS configuration may be determined by a peer SL transmitting terminal device flexibly by using a configured time offset with regard to an SL resource indicated/reserved by a transmitting terminal device in time-and/or-frequency domain. And in yet some other exemplary embodiments, a transmitting terminal device and a receiving terminal device may use both the fixed SL-CRS window and the flexible SL-CRS window for different SL transmissions, e.g. with regard to the QoS requirements of the considered SL transmissions. For example, a flexible SL-CRS window may be applied for a SL TX requiring strict QoS requirements, such as high reliability and/or low latency, in order to ensure QoS. As another example, a fixed SL-CRS window may be applied if a SL TX has more relaxed QoS requirements, which allows the receiving terminal device to save more power.

In yet some other exemplary embodiments, the SL-CRS configuration may further take into account QoS requirements of the SL transmissions. For example, the occurring periodicity and/or location of one or more SL-CRS windows may be set such that there is a capability to meet the latency requirement of the considered SL TX. As another example, the size of the SL-CRS window may be configured large enough such that collisions are reduced, and reliability requirement is met if multiple terminal devices transmit to the receiving terminal device within the same SL-CRS window.

In some other exemplary embodiments, there may be multiple SL-CRS configurations known and may be used by a receiving terminal device and a transmitting terminal device, such that the different SL-CRS configurations may be used for different services, different data traffic profiles/patterns (e.g. transmission periodicity), different types of QoS flows (e.g. by considering latency, and/or reliability), and/or different traffic priorities. In this exemplary embodiment, a policy regarding how to use a SL-CRS configuration may be indicated by criterion or requirement associated with the SL-CRS configuration. For example, a "resource reservation period" IE and/or the "priority" IE carried in SCI may be used as the criterion to determine the proper SL-CRS configuration, which is to be used for the considered SL transmission, or re-transmission between the transmitting terminal device and the receiving terminal device.

After configuring the terminal device <NUM> and <NUM> with the SL-CRS configuration, in other words, both terminal devices have obtained or received the SL-CRS configuration based on which they may determine a SL-CRS window, the terminal device <NUM> transmits <NUM> towards the terminal device <NUM>. This may occur for example during an SL DRX On-duration and/or wakeup time of the terminal device <NUM> or by using a pre-indicated SL resource. In the transmission <NUM>, the terminal device <NUM> may provide an indication indicating its future SL transmission resources that may be periodic or aperiodic. It is to be noted that the transmission may also be a re-transmission. The indicating may be performed for example by using a legacy SCI according to 3GPP Rel. <NUM> or in any other suitable way. Based on the received indication, the terminal device <NUM> may monitor the indicted SL resources in future. In addition, the information indicated in <NUM> may be used for deriving the SL-CRS configuration by a fixed mapping, according to some exemplary embodiment(s), e.g. by the terminal devices <NUM> and/or <NUM>.

The terminal device <NUM> may determine <NUM> that it will not be able to perform a SL TX during an upcoming indicated/reserved resource. In other words, a SL TX will be missed and not transmitted as expected over an indicated/reserved resource. This may be for example due to a SL logical channel prioritization, LCP, procedure executed in MAC layer, the physical-layer SL prioritization procedure, the SL resource pre-emption procedure, and/or the SL resource re-evaluation procedure. Therefore, the terminal device <NUM> will not transmit to the terminal device <NUM> a SL TX over the indicated/reserved resource. Correspondingly, as the terminal device <NUM> monitors the indicated/reserved resource for the expected SL TX, it detects <NUM> that the expected SL TX was not received over the indicated/reserved resource. In other words, the terminal device <NUM> detects <NUM> a skipped SL TX <NUM> from the terminal device <NUM>. The detection <NUM> of the skipped SL TX <NUM> from the terminal device <NUM> by the terminal device <NUM> may be based on missing of sidelink control information, SCI, over physical sidelink control channel, PSCCH, from the terminal device <NUM> over an indicated/reserved SL resource as planned for example. Alternatively, for example, the detection of the skipped SL TX from the terminal device <NUM> by the terminal device <NUM> may be based on different source and/or destination ID, compared to the ID of the terminal device <NUM> or <NUM>, carried in the second stage of SCI over PSSCH over an indicated/reserved SL resources as planned. This may be the case for example if the terminal device <NUM> uses the indicated/reserved SL resources to transmit to another terminal device instead of the terminal device <NUM> due to for example an LCP reason or if the indicated/reserved SL resources from the terminal device <NUM> are pre-emptied by other terminal devices.

As the terminal device <NUM> skipped a SL TX towards the terminal device <NUM> over an indicated/reserved SL resource, both terminal device <NUM> and <NUM> determine <NUM> the next SL-CRS window for communication. For example, the terminal device <NUM> and the terminal device <NUM> may select and determine the SL-CRS configuration and the SL-CRS window based on the transmission received from the transmission <NUM> described above. This may be for example based on the "resource reservation period" IE and/or the "priority" IE carried in the SCI in the transmission <NUM>. In another example, the terminal device <NUM> and the terminal device <NUM> may select and determine the SL-CRS configuration and the SL-CRS window based on the configuration obtained in <NUM>.

After determining the SL-CRS window, the terminal device <NUM> transmits to the terminal device <NUM> via a resource within the determined SL-CRS window. It is to be noted that a SL-CRS window may comprise one or more resources, where the terminal device <NUM> may transmit to the terminal device <NUM> over one or some of them. The transmission from the terminal device <NUM> to the terminal device <NUM> may depend on a method associated with the SL-CRS configuration. The method associated with the SL-CRS configuration may comprise at least some of the followings:.

It is to be noted that in some embodiment, a SL-CRS window may comprise continuous or discontinuous SL resources. For example, the continuous or discontinuous SL resources may be aligned with a SL resource pool configuration.

In some exemplary embodiments, the determining and monitoring performed by the terminal device <NUM> regarding its SL-CRS may further depend on the SL radio condition detected. For example, if the terminal device <NUM> detects a low sidelink reference signal received power, SL-RSRP, when performing configuration <NUM> and/or receiving one or multiple transmissions <NUM> from the terminal device <NUM> , it may not monitor its SL-CRS window if it detects a missing transmission from the terminal device <NUM> as the terminal device <NUM> may miss the transmission due to a bad radio condition instead of a skipped SL TX from the terminal device <NUM>. In such exemplary embodiments, the terminal device <NUM> may only monitor the indicated/reserved SL resources either until the SL radio condition is recovered, which may be determined for example based on detecting a better SL-RSRP, or until a pre-determined time has passed, even if it detects a missing transmission from the terminal device <NUM>.

<FIG> illustrates an exemplary embodiment in which configuration of a transmitting terminal device, such as the terminal device <NUM> in the above exemplary embodiment, and a receiving terminal device, such as the terminal device <NUM> in the above exemplary embodiment, are configured with a SL-CRS associated with the receiving terminal device such that there are plurality of transmitting terminal devices configured with the same fixed SL-CRS window associated with the receiving terminal device. In this exemplary embodiment, the SL-CRS window <NUM> comprises two resources and may optionally be extended with additional resources <NUM>. In some other exemplary embodiments, the window may comprise a different amount of resources. In this exemplary embodiment, there is a first transmitting terminal device and a second transmitting terminal device that are expected to transmit SL TX to the receiving terminal device. The first transmitting terminal device however cannot transmit SL TX <NUM> as expected and the second transmitting terminal device cannot transmit SL TX <NUM> as expected. In this exemplary embodiment, both transmit instead in the next SL-CRS window <NUM> and/or <NUM>. This helps the receiving terminal device to minimize its power consumption when neither transmitting terminal device transmits during the reserved/indicated resources as it is sufficient for the receiving terminal device to monitor one SL-CRS window to receive the missed SL TXs from different transmitting terminal devices.

<FIG> illustrates an exemplary embodiment in which configuration of a transmitting terminal device, such as the terminal device <NUM> in the above exemplary embodiment, and a receiving terminal device, such as the terminal device <NUM> in the above exemplary embodiment, are configured with a SL-CRS associated with the receiving terminal device such that the SL-CRS window follows an indicated/reserved sidelink resource associated with the transmitting terminal device with a pre-determined time offset. In this exemplary embodiment, as in the previous exemplary embodiment, there is the first transmitting terminal device and the second transmitting terminal device performing sidelink transmissions to the receiving terminal device. The time offset <NUM> is for the first transmitting terminal device and the time offset <NUM> is for the second transmitting terminal device. Thus, if the first transmitting terminal device does not perform a SL TX towards the receiving terminal device over an indicated/reserved SL resource, it transmits within a SL-CRS window that starts the time offset <NUM> after the indicated/reserved SL resource. The time offset may be defined as an amount of SL slots. As different transmitting terminal devices may indicate/reserve different SL resources, the SL-CRS windows to be used by different SL Tx UEs may not overlap (partially). It is to be noted that the time offset <NUM> and <NUM> may correspond to the same amount of SL slots or they may correspond to different amounts of SL slots. In this exemplary embodiment, latency performance may be ensured as the SL-CRS window may follow an indicated/reserved SL resource with a small offset. Further, as different transmitting terminal devices may use non-overlapping SL-CRS windows, they may expect less collisions among them, which may provide good reliability.

Embodiments described herein may be compatible with a communication system, such as in at least one of the following: Global System for Mobile Communications (GSM) or any other second generation cellular communication system, Universal Mobile Telecommunication System (UMTS, <NUM>) based on basic wideband-code division multiple access (W-CDMA), high-speed packet access (HSPA), Long Term Evolution (LTE), LTE-Advanced, a system based on IEEE <NUM> specifications, a system based on IEEE <NUM> specifications, and/or a fifth generation (<NUM>) mobile or cellular communication system.

As used herein, the term "determining" (and grammatical variants thereof) may include: calculating, computing, processing, deriving, measuring, investigating, looking up (e.g., looking up in a table, a database or another data structure), ascertaining and the like. Also, "determining" may include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory), obtaining and the like. Also, "determining" can include resolving, selecting, choosing, establishing, and the like.

<FIG> illustrates an apparatus <NUM>, which may be an apparatus such as, or comprised in, a terminal device, according to an example embodiment. The apparatus <NUM> comprises a processor <NUM>. The processor <NUM> interprets computer program instructions and processes data. The processor <NUM> may comprise one or more programmable processors. The processor <NUM> may comprise programmable hardware with embedded firmware and may, alternatively or additionally, comprise one or more application specific integrated circuits, ASICs.

The processor <NUM> is coupled to a memory <NUM>. The processor is configured to read and write data to and from the memory <NUM>. The memory <NUM> may comprise one or more memory units. The memory units may be volatile or non-volatile. It is to be noted that in some example embodiments there may be one or more units of non-volatile memory and one or more units of volatile memory or, alternatively, one or more units of non-volatile memory, or, alternatively, one or more units of volatile memory. Volatile memory may be for example RAM, DRAM or SDRAM. Non-volatile memory may be for example ROM, PROM, EEPROM, flash memory, optical storage or magnetic storage. In general, memories may be referred to as non-transitory computer readable media. The memory <NUM> stores computer readable instructions that are execute by the processor <NUM>. For example, non-volatile memory stores the computer readable instructions and the processor <NUM> executes the instructions using volatile memory for temporary storage of data and/or instructions.

The computer readable instructions may have been pre-stored to the memory <NUM> or, alternatively or additionally, they may be received, by the apparatus, via electromagnetic carrier signal and/or may be copied from a physical entity such as computer program product. Execution of the computer readable instructions causes the apparatus <NUM> to perform functionality described above.

The apparatus <NUM> further comprises, or is connected to, an input unit <NUM>. The input unit <NUM> comprises one or more interfaces for receiving a user input. The one or more interfaces may comprise for example one or more motion and/or orientation sensors, one or more cameras, one or more accelerometers, one or more microphones, one or more buttons and one or more touch detection units. Further, the input unit <NUM> may comprise an interface to which external devices may connect to.

The apparatus <NUM> also comprises an output unit <NUM>. The output unit comprises or is connected to one or more displays capable of rendering visual content such as a light emitting diode, LED, display, a liquid crystal display, LCD and a liquid crystal on silicon, LCoS, display. The output unit <NUM> further comprises one or more audio outputs. The one or more audio outputs may be for example loudspeakers or a set of headphones.

The apparatus <NUM> may further comprise a connectivity unit <NUM>. The connectivity unit <NUM> enables wired and/or wireless connectivity to external networks. The connectivity unit <NUM> may comprise one or more antennas and one or more transceivers that may be integrated to the apparatus <NUM> or the apparatus <NUM> may be connected to. The connectivity unit <NUM> may comprise an integrated circuit or a set of integrated circuits that provide the wireless communication capability for the apparatus <NUM>. Alternatively, the wireless connectivity may be a hardwired application specific integrated circuit, ASIC.

Claim 1:
An apparatus (<NUM>) comprising means for:
receiving an indication from a transmitting terminal device (<NUM>) indicative of a sidelink resource reserved for receiving a subsequent sidelink transmission from the transmitting terminal device (<NUM>);
detecting that the subsequent sidelink transmission is not received from the transmitting terminal device (<NUM>) over the reserved sidelink resource; and
as a response to detecting that the subsequent sidelink transmission was not received over the reserved sidelink resource, monitoring a sidelink complementary resource set window (<NUM>, <NUM>, <NUM>, <NUM>) for receiving the subsequent sidelink transmission from the transmitting terminal device (<NUM>).