Method for performing discontinuous reception on sidelink

Abstract

A method for determining DRX operation in a wireless transmit receive unit (WTRU) having information indicating a plurality of DRX configurations includes selecting a first DRX configuration from the plurality of DRX configurations based on a first cast type and associated first quality of service (QoS) information for a first sidelink radio bearer (SLRB) configuration, selecting a second DRX configuration from the plurality of DRX configurations based on a second cast type and associated second QoS information for a second SLRB configuration, determining a sidelink monitoring time based on a combination of an active time associated with the first DRX configuration and an active time associated with the second DRX configuration, and monitoring a sidelink control channel using the determined sidelink monitoring time.

Description

[0001] This application is a divisional of the application filed on February 12, 2021, having application number 202180025935.3, entitled “Method for performing discontinuous reception on sidelink” and having a filing date of February 12, 2021.

[0002] Cross Reference to Related Applications

[0003] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 975,238 filed on February 12, 2020, U.S. Provisional Patent Application No. 62 / 985,604 filed on March 5, 2020, U.S. Provisional Application No. 63 / 061,388 filed on August 5, 2020, U.S. Provisional Application No. 63 / 090,992 filed on October 13, 2020, and U.S. Application No. 63 / 125,446 filed on December 15, 2020, all of which are incorporated by reference herein in their entirety for all purposes. BACKGROUND

[0004] 5G specifications include providing discontinuous reception (DRX) to conserve energy in mobile units. The main purpose of DRX is to reduce battery consumption when there is no uplink or downlink data for the mobile device to process. Thus, the mobile device can enter a sleep mode in which the RF interface is in a low power or off mode. When traffic related to the mobile unit is expected to occur, the mobile unit can power up to process the information. SUMMARY

[0005] In one embodiment, a method for determining DRX operation in a wireless transmit receive unit (WTRU) having information indicating a plurality of DRX configurations, the method comprising: selecting a first DRX configuration from the plurality of DRX configurations based on a first cast type and associated first quality of service (QoS) information for a first sidelink radio bearer (SLRB) configuration; selecting a second DRX configuration from the plurality of DRX configurations based on a second cast type and associated second QoS information for a second SLRB configuration; determining a sidelink monitoring time based on a combination of an active time associated with the first DRX configuration and an active time associated with the second DRX configuration, and performing sidelink (SL) control channel monitoring using the determined sidelink monitoring time.

[0006] In one embodiment, a method for use in a receiving wireless transmit receive unit (RX WTRU) having reception configuration information comprising a first RX resource pool and a second RX resource pool, the method comprising: changing monitoring from the first RX resource pool to monitoring the first RX resource pool and the second RX resource pool upon receiving data; and changing monitoring from the first RX resource pool and the second RX resource pool back to monitoring the first RX resource pool after an elapsed time.

[0007] In one embodiment, a method for determining discontinuous reception (DRX) operation in a wireless transmit receive unit (WTRU) having a plurality of DRX configurations, the method comprising selecting one or more of: selecting one of the plurality of DRX configurations associated with a type of received transmission and / or intended receiver, selecting one of the plurality of DRX configurations associated with an ongoing quality of service (QoS), selecting one of the plurality of DRX configurations associated with a priority of recently received data, selecting one of the plurality of DRX configurations provided by another WTRU, and selecting one of the plurality of DRX configurations based on a static configuration associated with a sidelink.

[0008] In another embodiment, a method for determining discontinuous reception (DRX) operation in a wireless transmit receive unit (WTRU) having a plurality of DRX configurations, the method comprising one or more of: determining the DRX operation based on a forward reservation signal and / or a scheduled reception or transmission, wherein the WTRU performs the DRX operation between the scheduled transmission or reception, and determining the DRX operation based on at least one of a channel busy ratio (CBR), a sidelink control information (SCI) content, a configuration of the WTRU, a presence of pending transmissions, a time period between scheduled transmissions or receptions, and a latency in a WTRU buffer.

[0009] In another embodiment, a method for determining discontinuous reception (DRX) operation in a wireless transmit receive unit (WTRU), the method comprising one or more of: determining the DRX operation based on a sidelink transmission or reception at the WTRU, and determining the DRX operation based on a combination of transmission activity and reception activity.

[0010] In another embodiment, a method performed by a first WTRU to determine a transmission opportunity to a peer WTRU in a discontinuous reception (DRX) operation, the method comprising one or more of: determining a transmission time based on an availability of the peer WTRU, the availability depending on at least one of a time related to a last transmission to the peer WTRU and a quality of service (QoS) of transmissions to the peer WTRU; determining a transmission time based on a peer WTRU active period; determining a different offset of a transport block retransmission associated with the transmission opportunity; and transmitting an activity signal on a sidelink communication to indicate an intention to transmit from the WTRU to the peer WTRU.

[0011] In another embodiment, a method for use in a receiving wireless transmit receive unit (RX WTRU), wherein the RX WTRU is configured with a first receive (RX) resource pool and a second RX resource pool, the method comprising upon receiving quality of service data, changing monitoring from the first RX resource pool to monitoring the first RX resource pool and the second RX resource pool; and upon expiration of an inactivity timer, changing monitoring from the first RX resource pool and the second RX resource pool to monitoring the first RX resource pool.

[0012] While various embodiments herein are described and / or claimed in terms of devices, systems, apparatuses, etc., and / or any elements thereof performing operations, processes, algorithms, functions, etc., and / or any portions thereof, it should be understood that any of the embodiments described and / or claimed herein contemplate any device, system, apparatus, etc., and / or any elements thereof being configured to perform any of the operations, processes, algorithms, functions, etc., and / or any portions thereof. BRIEF DESCRIPTION OF DRAWINGS

[0013] A more detailed understanding can be had from the following detailed description, given by way of example in conjunction with the accompanying drawings wherein:

[0014] FIG. 1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments can be implemented;

[0015] FIG. 1B is a system diagram illustrating an example WTRU that can be used within the communications system FIG. 1A illustrated in FIG. 1 can be used.

[0016] FIG. 1C is a system diagram illustrating an example WTRU that can be used within the communications system FIG. 1ASystem diagram of an exemplary radio access network (RAN) and exemplary core network (CN) used within the illustrated communication system;

[0017] FIG. 1D is a flow diagram illustrating a process involving the use of one or more receive resource pools according to one embodiment; FIG. 1A System diagram of another exemplary RAN and another exemplary CN used within the illustrated communication system;

[0018] FIG. 2 depicts an exemplary establishment of a secure layer 2 link over PC5;

[0019] FIG. 3 depicts an exemplary configuration of active resources and associated resources for L2-ID 1;

[0020] FIG. 4 depicts exemplary active monitoring and DRX of a RX WTRU;

[0021] FIG. 5 depicts a WTRU in a minimum communication range for resource pool monitoring;

[0022] FIG. 6 is a flow diagram illustrating a process involving the use of one or more receive resource pools according to one embodiment;

[0023] FIG. 7 is a flow diagram illustrating another process involving the use of one or more receive resource pools; and

[0024] FIG. 8 is an exemplary method of determining a sidelink monitoring time for a WTRU. DETAILED DESCRIPTION

[0025] A detailed description of illustrative embodiments will now be described with reference to the various figures. Although this description provides a detailed example of a possible implementation, it should be noted that the specifics are intended to be illustrative only and are not intended to limit the scope of the application in any way. In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it will be recognized by one skilled in the art that

[0026] FIG. 1Ais a diagram illustrating an example communications system 100 in which one or more disclosed embodiments can be implemented. The communications system 100 can be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 can enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 can employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word DFT-Spread OFDM (ZT UW DTS-s OFDM), unique-word OFDM (UW-OFDM), resource block-filter OFDM, filter bank multicarrier (FBMC), and the like.

[0027] As shown FIG. 1A The communications system 100 can include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104 / 113, a CN 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, but it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which can be referred to as a “station” and / or a “STA”)

[0028] The communications system 100 can also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b can be any type of device configured to wirelessly interface to at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or the other networks 112. By way of example, the base stations 114a, 114b can be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a gNB, a NR Node B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b can include any number of interconnected base stations and / or network elements.

[0029] The base station 114a can be part of the RAN 104 / 113, which can also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and / or the base station 114b can be configured to transmit and / or receive wireless signals on one or more carrier frequencies (which can be referred to as a cell (not shown)). These frequencies can be in the licensed spectrum, the unlicensed spectrum, or a combination of the licensed and unlicensed spectrums. A cell can provide service to a particular geographic area and can be fixed, or can change in size and / or shape over time. A cell can further be divided into cell sectors. For example, a cell associated with a base station 114a can be divided into three sectors. Thus, in embodiments, the base station 114a can include three transceivers, one for each sector of the cell. In embodiments, the base station 114a can employ Multiple Input Multiple Output (MIMO) techniques and can utilize multiple transceivers for each sector of the cell. For example, signals can be transmitted and / or received using beamforming.

[0030] The base stations 114a, 114b can communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 can be established using any suitable radio access technology (RAT).

[0031] More specifically, as noted above, the communications system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a and WTRUs 102a, 102b, 102c in the RAN 104 / 113 can implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish the air interface 115 / 116 / 117 using wideband CDMA (WCDMA). WCDMA can include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed Downlink (DL) Packet Access (HSDPA) and / or High-Speed UL Packet Access (HSUPA).

[0032] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which can establish the air interface 116 using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro).

[0033] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement a radio technology such as NR Radio Access, which can establish the air interface 116 using New Radio (NR).

[0034] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement multiple radio access technologies. For example, the base station 114a and WTRUs 102a, 102b, 102c can implement LTE wireless access and NR wireless access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c can be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., a eNB and a gNB).

[0035] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c can implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0036] FIG. 1A The base station 114b in FIG. 13 can be a wireless router, Home Node B, Home eNode B, or access point, for example, and can utilize any suitable RAT for facilitating wireless connectivity access by the WTRUs 102c, 102d. The base station 114b and the WTRUs 102c, 102d can implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d can implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. As shown, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b can not be required to access the Internet 110 via the CN 106 / 115. FIG. 1A

[0037] The RAN 104 / 113 can be in communication with the CN 106 / 115, which can be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data can have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 / 115 can provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, a FIG. 1A ​The RAN 104 / 113 and / or the CN 106 / 115 can also be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which can employ a NR radio technology, the CN 106 / 115 can also be in communication with another RAN (not shown) that employs a GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0038] The CN 106 / 115 can also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or the other networks 112. The PSTN 108 can include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 can include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and / or the internet protocol (IP) in the TCP / IP internet protocol suite. The networks 112 can include wired and / or wireless communications networks owned and / or operated by other service providers. For example, the networks 112 can include another CN connected to one or more RANs, which can employ the same RAT as the RAN 104 / 113 or a different RAT.

[0039] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 can include multi-mode capabilities, e.g., the WTRUs 102a, 102b, 102c, 102d can include multiple transceivers for communicating with different wireless networks over different wireless links. For example, FIG. 1A The WTRU 102c shown in Figure 1 A can be configured to communicate with the base station 114a using a cellular-based radio technology and can be configured to communicate with the base station 114b using an IEEE 802 radio technology.

[0040] FIG. 1B is a system diagram of an example WTRU 102. As shown in FIG. 1B The WTRU 102 can include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138, among others. It should be appreciated that the WTRU 102 can include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0041] The processor 118 can be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 can perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to the transceiver 120, which can be coupled to the transmit / receive element 122. While FIG. 1B The processor 118 and the transceiver 120 are depicted as separate components, but it will be understood that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.

[0042] The transmit / receive element 122 can be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. For example, in one embodiment, the transmit / receive element 122 can be an antenna configured to transmit and / or receive RF signals. In an embodiment, the transmit / receive element 122 can be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit / receive element 122 can be configured to transmit and / or receive both RF and light signals. It will be appreciated that the transmit / receive element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0043] Although the transmit / receive element 122 is depicted in the WTRU 102 FIG. 1B In one embodiment, the WTRU 102 can include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0044] The transceiver 120 can be configured to modulate information to be transmitted by the transmit / receive element 122 and to demodulate information received by the transmit / receive element 122. As indicated above, the WTRU 102 can be a multi-mode device. Thus, the transceiver 120 can include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11, for example.

[0045] The processor 118 of the WTRU 102 can be coupled to, and can receive user input data from, the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 can also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 can access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and / or the removable memory 132. The non-removable memory 130 can include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 can include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 can access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0046] The processor 118 can receive power from the power source 134 and can be configured to distribute and / or control the power to the other components in the WTRU 102. The power source 134 can be any suitable device for powering the WTRU 102. For example, the power source 134 can include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0047] The processor 118 can also be coupled to the GPS chipset 136, which can be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 can receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 can acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0048] The processor 118 can further be coupled to other peripherals 138, which can include one or more software and / or hardware modules that provide additional features, functionality and / or wired or wireless connectivity. For example, the peripherals 138 can include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulated (FM) radio The processor 118 can further be coupled to other peripherals 138, which can include one or more software and / or hardware modules that provide additional features, functionality and / or wired or wireless connectivity. For example, the peripherals 138 can include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® The peripheral device 138 can include one or more sensors, which can be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, a compass sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0049] The WTRU 102 can include a full duplex radio for which transmission and reception of some or all signals associated with the UL (for example, for transmission) and downlink (for example, for reception) can be concurrent and / or simultaneous. The full duplex radio can include an interference management unit 139 to reduce and / or substantially eliminate self-interference and / or cross-interference due to concurrent transmission and reception. In one embodiment, the WTRU 102 can include a half duplex radio for which transmission and reception of some or all signals associated with the UL (for example, for transmission) or downlink (for example, for reception) are not concurrent and / or simultaneous.

[0050] FIG. 1C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As

[0051] The RAN 104 can include eNode-Bs 160a, 160b, 160c, although it will be appreciated that the RAN 104 can include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c can each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In an embodiment, the eNode-Bs 160a, 160b, 160c can implement MIMO technology. Accordingly, the eNode-B 160a, for example, can use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a.

[0052] Each of the eNode-Bs 160a, 160b, 160c can be associated with a particular cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, and the like. As shown, the eNode-Bs 160a, 160b, 160c can communicate with one another over an X2 interface. FIG. 1C

[0053] FIG. 1C The CN 106 can include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements can be owned and / or operated by an entity other than the CN operator.

[0054] MME 162 can be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an SI interface and can serve as a control node. For example, the MME 162 can be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activations / deactivations, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. MME 162 can provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0055] The SGW 164 can be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 can generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 can perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0056] The SGW 164 can be connected to the PGW 166, which can provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0057] ​CN 106 can facilitate communications with other networks. For example, the CN 106 can provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional landline communications devices. For example, the CN 106 can include, or can communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 can provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which can include other wired and / or wireless networks that are owned and / or operated by other service providers.

[0058] Although WTRUs are described in FIGS. 1A-1D representative embodiments as wireless terminals, it is contemplated that in certain representative embodiments such a terminal can (e.g., temporarily or permanently) use a wired communication interface to communicate with a communication network.

[0059] In representative embodiments, the other network 112 can be a WLAN.

[0060] A WLAN in Infrastructure Basic Service Set (BSS) mode can have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can have an access or an interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic in to and / or out of the BSS. Traffic to STAs that is carried by the WLAN can be transmitted from the AP to the STAs. Traffic that originates from STAs can be transmitted to the AP that can send the traffic to the DS or to another network. Traffic that is destined to an STA that is not associated with the AP (i.e., an alien STA) can be transmitted to the AP that can page the alien STA and / or receive traffic from the alien STA that is directed to the AP. The AP can also be used to facilitate communications between STAs associated with the AP. For example, the AP can schedule access to the wireless channel among the associated STAs.

[0061] When using an 802.11 ac infrastructure mode of operation or similar mode of operation, an AP can transmit beacons on a fixed channel, such as a primary channel. The primary channel can be a fixed width (e.g., 20 MHz wide bandwidth) or a width that is dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by STAs to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access / collision avoidance (CSMA / CA) can be implemented, for example, in 802.11 systems. For CSMA / CA, a STA (e.g., each STA), including the AP, can listen to the primary channel. If the primary channel is sensed / detected as busy by a particular STA, the particular STA can back off. Only one STA can transmit in a given BSS at any given time.

[0062] High Throughput (HT) STAs can use 40 MHz wide channels, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

[0063] Very High Throughput (VHT) STAs can support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. 40 MHz and / or 80 MHz channels can be formed by combining contiguous 20 MHz channels. A 160 MHz channel can be formed by combining 8 contiguous 20 MHz channels, or by combining two noncontiguous 80 MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel encoding, the data can be parsed by a segment parser that can divide the data into two streams. Each stream can be independently subjected to inverse fast Fourier transform (IFFT) processing and time domain processing. The streams can be mapped to the two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above-described operations for the 80+80 configuration can be reversed, and the combined data can be sent to the medium access control (MAC).

[0064] 802.11af and 802.11ah support sub-1 GHz modes of operation. The channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah relative to those used in 802.11η and 802.1 lac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the television white space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to representative embodiments, 802.11ah can support meter type control / machine type communications, such as MTC devices in a macro coverage area. MTC devices can have certain capabilities, e.g., limited capabilities, including support for (e.g., only support for) certain bandwidths and / or limited bandwidth. MTC devices can include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0065] WLAN systems that can support multiple channels and channel bandwidths such as 802.11η, 802.1 lac, 802.11af, and 802.11ah include a channel that can be designated as a primary channel. The primary channel can have a bandwidth equal to the largest common operating bandwidth supported by all STAs in a BSS. The bandwidth of the primary channel can be set and / or limited by a STA from all STAs operating in the BSS that supports the smallest bandwidth mode of operation. In the example of 802.11ah, for a STA (e.g., MTC type device) that supports (e.g., only supports) a 1 MHz mode, the primary channel can be 1 MHz wide even though other STAs in the AP and BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth modes of operation. Carrier sensing and / or network allocation vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, e.g., due to a STA (only supporting a 1 MHz mode of operation) transmitting to the AP, the entire available frequency band can be considered busy even though most of the frequency band remains idle and can be available.

[0066] In the United States, the available frequency band for 802.11ah use is 902 MHz to 928 MHz. In Korea, the available frequency band is 917.5 MHz to 923.5 MHz. In Japan, the available frequency band is 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11ah use is 6 MHz to 26 MHz, depending on the country code.

[0067] FIG. 1D is a system diagram illustrating the RAN 113 and the CN 115 according to an embodiment. As noted above, the RAN 113 can employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 can also be in communication with the CN 115.

[0068] The RAN 113 can include gNBs 180a, 180b, 180c, although the RAN 113 can include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c can each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In an embodiment, the gNBs 180a, 180b, 180c can implement MIMO technology. For example, gNBs 180a, 108b can utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, can use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c can implement carrier aggregation technology. For example, the gNB 180a can transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers can be on unlicensed spectrum while the remaining component carriers can be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c can implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0069] The WTRUs 102a, 102b, 102c can use OFDM symbols of different lengths associated with different numerologies to communicate with the gNBs 180a, 180b, 180c. For example, the OFDM symbol spacing and / or the OFDM subcarrier spacing can vary from different transmissions, from different cells, and / or from different portions of a wireless transmission spectrum. The WTRUs 102a, 102b, 102c can use subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing different quantities of OFDM symbols and / or lasting varying lengths of absolute time) to communicate with gNBs 180a, 180b, 180c.

[0070] The gNBs 180a, 180b, 180c can be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In the standalone configuration, the WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c can utilize signal s for communication with gNBs 180a, 180b, 180c in an unlicensed frequency band. In the non-standalone configuration, the WTRUs 102a, 102b, 102c can communicate with or be connected to gNBs 180a, 180b, 180c while also communicating with or being connected to another RAN, such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c can implement DC principles to substantially simultaneously communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c. In the non-standalone configuration, eNode-Bs 160a, 160b, 160c can serve as the WTRUs' 102a, 102b, 102c mobility anchor points and gNBs 180a, 180b, 180c can provide additional coverage and / or throughput to the WTRUs 102a, 102b, 102c serving.

[0071] Each of the gNBs 180a, 180b, 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown, the gNBs 180a, 180b, 180c can communicate with one another over an Xn interface. FIG. 1D As shown, the gNBs 180a, 180b, 180c can be in communication with the AN 152 and / or the CN 180. The gNBs 180a, 180b, 180c can each include one or more ANs, or components, and can be configured to function as a base station, or gNB. In some aspects, one or more of the gNBs 180a, 180b, 180c can communicate with the core network 180, with other gNBs 180a, 180b, 180c, or with other network nodes not shown in FIG. 1. In some aspects, the gNBs 180a, 180b, 180c can be implemented as a virtual network function, or as part of a virtual network function.

[0072] FIG. 1DThe illustrated CN 115 can include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While each of the foregoing elements are depicted as part of the CN 115, it will be appreciated that any of these elements can be owned and / or operated by an entity other than the CN operator.

[0073] The AMF 182a, 182b can be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and can serve as a control node. For example, the AMF 182a, 182b can be responsible for authenticating WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling of different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, management of the WTRU 102a, 102b, 102c registration area, termination of non-access stratum (NAS) signaling, mobility management, and the like. The AMF 162 can utilize network slicing to customize CN support for WTRUs 102a, 102b, 102c based on the type of services utilized by a WTRU 102a, 102b, 102c. For example, different network slices can be established for different use cases (e.g., services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced mobile broadband (eMBB) access, services for machine type communication (MTC) access, and / or the like). The AMF 162 can provide control plane functionality for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0074] The SMF 183a, 183b can be connected to AMF 182a, 182b in the CN 115 via an N11 interface. The SMF 183a, 183b can also be connected to UPF 184a, 184b in the CN 115 via an N4 interface. The SMF 183a, 183b can select and control the UPF 184a, 184b and configure the traffic routing at the UPF 184a, 184b. The SMF 183a, 183b can perform other functions, such as managing and allocating WTRU / UE IP address, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and the like. A PDU session type can be IP-based, non-IP based, Ethernet-based, and the like.

[0075] The UPF 184a, 184b can be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which can provide WTRUs 102a, 102b, 102c with access to packet- switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b can perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering of downlink packets, providing mobility anchoring, and the like.

[0076] The CN 115 can facilitate communications with other networks. For example, the CN 115 can include, or can communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108. Further, the CN 115 can provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which can include other wired and / or wireless networks that are owned and / or operated by other service providers. In embodiments, the WTRUs 102a, 102b, 102c can be connected to a DN 185a, 185b through the UPF 184a, 184b via the N3 interface between the UPF 184a, 184b and the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0077] In view of FIGS. 1A-1D And FIGS. 1A-1D One or more or all of the functions described herein for one or more of the following can be performed by one or more emulation devices (not shown): WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMF 182a-ab, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device or devices described herein. An emulation device can be one or more devices configured to emulate one or more or all of the functions described herein. For example, emulation devices can be used to test other devices and / or to simulate a network and / or WTRU functionality.

[0078] The one or more emulation devices can perform the one or more, including all, functions while not implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device can be utilized in a testing scenario in a testing laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network in order to implement testing of one or more components. The one or more emulation devices can be test equipment. Direct RF coupling and / or wireless communications, via RF circuitry (e.g., which can include one or more antennas) can be used by the emulation devices to transmit and / or receive data.

[0079] The one or more emulation devices can perform the one or more, including all, functions while not implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device can be utilized in a testing scenario in a testing laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network in order to implement testing of one or more components. The one or more emulation devices can be test equipment. Direct RF coupling and / or wireless communications, via RF circuitry (e.g., which can include one or more antennas) can be used by the emulation devices to transmit and / or receive data.

[0080] Examples provided herein do not limit the applicability of the subject matter to other wireless technologies, e.g., using the same or different principles that can be applicable.

[0081] As explained herein, a wireless transmit receive unit (WTRU) can be an example of user equipment (UE). Thus, the terms UE and WTRU can be used interchangeably herein.

[0082] Vehicle communication is a mode of communication by which WTRUs can communicate directly with each other. There are two scenarios for vehicle-to-everything (V2X) operation:

[0083] (a) In-coverage scenario, where the WTRU receives assistance from the network to start transmitting and receiving V2X messages, and (b) Out-of-coverage scenario, where the WTRU uses some pre-configured parameters to start transmitting and receiving V2X messages.

[0084] V2X communication is supported in Release 14 LTE and is inspired by previous work on device-to-device (D2D) communication. V2X communication services can be composed of four different types:

[0085] (i) V2V (vehicle-to-vehicle): Vehicle WTRUs can communicate directly with each other.

[0086] (ii) V2I (vehicle-to-infrastructure): Vehicle WTRUs can communicate with road-side units / evolved Node Bs (RSU / eNB).

[0087] (iii) V2N (Vehicle-to-Network): A vehicle WTRU can communicate with the core network.

[0088] (iv) V2P (Vehicle-to-Pedestrian): A vehicle WTRU can communicate with a WTRU with special conditions (e.g., low battery capacity).

[0089] V2X resource allocation in LTE

[0090] Long Term Evolution (LTE) defines two modes of operation in V2X communications. Mode 3, where the network provides the WTRU with scheduling assignments for V2X sidelink (SL) transmissions. Mode 4, where the WTRU autonomously selects resources from configured / preconfigured resource pools. In addition, V2X LTE defines two types of resource pools: reception pools, monitored for reception of V2X transmissions; and V2X transmission pools, which can be used by the WTRU for selecting transmission resources in Mode 4. A WTRU configured to be in Mode 3 can not use the transmission pools. A resource pool defines a subset of available subframes and resource blocks for sidelink transmission or reception. Sidelink communication is a half-duplex scheme, and a WTRU can be configured with multiple transmission resource pools and multiple reception resource pools.

[0091] In LTE, these resource pools are signaled to the WTRU semi-statically via radio resource control (RRC) signaling. In Mode 4, the WTRU uses listening before selecting resources in the RRC configured transmission pool. LTE V2X does not support dynamic resource pool reconfiguration; pool configurations can only be carried via system information block (SIB) and / or dedicated RRC signaling. As used herein, a new radio (NR) V2X resource pool can include a set of resources used in V2X communications for a new radio (NR) WTRU using discontinuous reception (DRX). A reception (RX) resource pool defines resources that a WTRU should monitor. A transmission (TX) resource pool defines resources that a WTRU can use for transmission. Not all resources in the sidelink can be used for TX or RX. In this document, a RX resource pool can also be referred to as a RX pool, and a TX resource pool can also be referred to as a TX pool.

[0092] New radio (NR) V2X access technology

[0093] The Third Generation Partnership Project (3GPP) includes a next generation wireless system, referred to as “New Radio” (NR). NR systems are expected to support a variety of use cases, such as enhanced mobile broadband (eMBB), ultra-reliable and low-latency communications (URLLC).

[0094] 3GPP can support enhanced V2X (eV2X) communication in NR systems. It is expected that eV2X in NR supports new services for both safety and non-safety scenarios, such as sensor sharing, automated driving, vehicle platooning, remote driving. Different eV2X services require different performance requirements, for some scenarios, a latency of 3ms is required.

[0095] New use cases for NR V2X

[0096] It is expected that NR V2X supports new use cases defined in 3GPP standards. In particular, the following use cases will be supported:

[0097] Vehicle platooning. Vehicle platooning enables vehicles to dynamically form groups that travel together. All vehicles in a platoon receive periodic data from the leading vehicle in order to perform platoon operations. This information allows the distance between vehicles to become very small, i.e. the gap distance converted to time can be very low (sub-seconds). Platooning applications can allow the followed vehicles to drive autonomously.

[0098] Advanced driving. Advanced driving enables semi-automated or fully-automated driving. Longer inter-vehicle distances are assumed. Each vehicle and / or road side unit (RSU) shares data obtained from its local sensors with approaching vehicles, thus allowing the vehicles to coordinate their trajectories or activities. In addition, each vehicle shares its driving intention with approaching vehicles. The benefits of this use case group are safer travel, collision avoidance, and improved traffic efficiency.

[0099] Extended sensors. Extended sensors enable the exchange of raw or processed data collected by local sensors or real-time video data between vehicles, RSUs, pedestrian devices, and V2X application servers. Vehicles can enhance their perception of their environment beyond what their own sensors can detect and have a more comprehensive view of the local situation.

[0100] Remote driving. Remote driving enables a remote driver or V2X application to operate a remote vehicle for passengers who cannot drive themselves or who are located in a dangerous environment. For situations with limited variations and predictable routes, such as public transportation, cloud computing-based driving can be used. In addition, this use case group can consider access to cloud-based backend service platforms.

[0101] Quality of service (QoS) for NR V2X

[0102] A QoS model is used in NR V2X in 3GPP. In Rel-14 V2X, documented in TS 23.285, QoS over PC5 is supported through ProSe Per-Packet Priority (PPPP). The application layer is allowed to mark packets with a PPPP, which indicates the required QoS level. Certain enhancements were added, e.g. by allowing derivation of packet delay budget (PDB) from PPPP.

[0103] New QoS requirements for NR V2X are documented in TS 22.186. New performance Key Performance Indicators (KPIs) are specified by the following parameters:

[0104] - Payload (bytes);

[0105] - Transmission rate (messages / second);

[0106] - Maximum end-to-end latency (ms);

[0107] - Reliability (%);

[0108] - Data rate (Mbps);

[0109] - Minimum required communication range (meters).

[0110] Note that the same set of service requirements applies to both PC5-based V2X communication and Uu-based V2X communication. These QoS characteristics can be well represented with the 5G QoS Indicators (5QIs) defined in TS 23.501.

[0111] One possibility is to have a unified QoS model for PC5 and Uu, i.e. 5QIs are also used for V2X communication over PC5, so that the application layer can have a consistent way of indicating QoS requirements, regardless of the used link.

[0112] Considering a WTRU supporting 5GS V2X, there are three different types of traffic: broadcast, multicast and unicast. For unicast type of traffic, the same QoS model as for Uu can be utilized, i.e. each of the unicast links can be considered as a bearer and a QoS flow can be associated with it. All QoS characteristics and the additional parameter of data rate defined in 5QI can be applied. Furthermore, the minimum required communication range can be considered as an additional parameter specific to PC5 use cases. Similar considerations apply to multicast traffic, as it can be considered as a special case of unicast, i.e. with multiple defined traffic receivers.

[0113] For broadcast services, there is no bearer concept. Therefore, each of these messages can have different characteristics according to the application requirements. Then, 5QI should be used in a similar way as PPPP / PPPR, i.e. each packet is marked. 5QI is able to express all characteristics required for PC5 broadcast operation, e.g. delay, priority, reliability, etc. A set of V2X broadcast specific 5QI (i.e. VQI) can be defined for PC5.

[0114] PC5 QoS parameters are negotiated during the establishment of a one-to-one communication procedure, thus enhancing the one-to-one communication establishment procedure defined in TS 23.303 to support PC5 QoS parameter negotiation between two WTRUs. After the PC5 QoS parameter negotiation procedure, the same QoS is used in both directions.

[0115] WTRUs participating in a one-to-one communication negotiate PC5 QoS parameters during the link establishment procedure as shown in FIG. 2 Message 1 is a Direct Communication Request (DCR) message and message 2 is an authentication and establishment of security association. In message 1, UE-1 (WTRU-1) sends a Direct Communication Request message to UE-2 (WTRU-2) in order to trigger mutual authentication. This message includes the requested PC5 QoS parameters. In message 2, UE-2 (WTRU-2) initiates the procedure for mutual authentication. UE-2 (WTRU-2) includes the accepted PC5 QoS parameters in the response message.

[0116] Discontinuous reception (DRX) in NR Uu

[0117] Connected mode DRX is specified for power saving in NR uu for WTRUs in RRC CONNECTED. DRX is based on the configured scheduling of the wake-up time at the WTRU. If the WTRU receives a physical downlink control channel (PDCCH) scheduling during its wake-up time, it remains awake for a period of time until no further scheduling is received. The WTRU can be configured with the following example parameters.

[0118] - drx-onDurationTimer: duration at the beginning of the DRX cycle;

[0119] - drx-SlotOffset: delay before starting the drx-onDurationTimer;

[0120] - drx-InactivityTimer: duration after the PDCCH occasion in which a PDCCH indicates a new uplink (UL) or downlink (DL) transmission for the MAC entity;

[0121] - drx-RetransmissionTimerDL (per DL Hybrid Automatic Repeat Request (HARQ) process other than broadcast process): maximum duration until a DL retransmission is received;

[0122] - drx-RetransmissionTimerUL (per UL HARQ process): maximum duration until a grant for a UL retransmission is received;

[0123] - drx-LongCycleStartOffset: long DRX cycle and drx-StartOffset defining the subframe in which the long DRX cycle and short DRX cycle start;

[0124] - drx-ShortCycle (optional): short DRX cycle;

[0125] - drx-ShortCycleTimer (optional): duration for which the UE shall follow the short DRX cycle;

[0126] - drx-HARQ-RTT-TimerDL (per DL HARQ process other than broadcast process): minimum duration before the MAC entity expects a DL assignment for a HARQ retransmission;

[0127] - drx-HARQ-RTT-TimerUL (per UL HARQ process): minimum duration before the MAC entity expects a UL HARQ retransmission grant.

[0128] The WTRU configured with DRX will then determine its active time (time during which the WTRU actively monitors the PDCCH) based on:

[0129] When a DRX cycle is configured, the active time includes the time when:

[0130] - drx-onDurationTimer or drx-InactivityTimer or drx-RetransmissionTimerDL or drx-RetransmissionTimerUL or ra-ContentionResolutionTimer (as specified in clause 5.1.5 of Release 14); or

[0131] - a Scheduling Request is sent on Physical Uplink Control Channel (PUCCH) and is in a pending state (as specified in clause 5.4.4 of Release 14); or

[0132] - After successfully receiving a random access response for a preamble not selected by the MAC entity, a new transmitted PDCCH indicating a cell radio network temporary identifier (C-RNTI) addressed to the MAC entity has not been received (as described in clause 5.1.4 of Release 14).

[0133] Partial sensing and random selection in LTE V2X

[0134] Another power saving mechanism introduced in LTE V2X (for pedestrian WTRUs) is in terms of partial sensing. In the case of partial sensing, the WTRU is configured by upper layers with a minimum number of candidate subframes in the resource selection window [T1, T2], where a specific subframe is selected by the WTRU implementation. The WTRU then only performs sensing in the listening window for subframes that are an integer number of reservation periods away from the candidate subframe, thus reducing the amount of resources the WTRU needs to perform sensing in the listening window.

[0135] Another possibility for pedestrian WTRUs is to perform random selection on the resource pool. If the resource pool is configured for random selection, the WTRU can perform resource selection without considering any sensing results during the sensing procedure.

[0136] Destination

[0137] Power saving for sidelink (PC5 reference point interface) can be achieved by performing discontinuous reception (i.e., skipping certain slots in sidelink resource decoding). However, since a WTRU can communicate with multiple peer WTRUs, a WTRU performing DRX should preferably be used to ensure that it performs DRX when no peer WTRU (whether broadcast, groupcast, or unicast) is performing transmission. Alternatively, a transmitting WTRU preferably selects resources such that it knows that the intended WTRU is performing active reception.

[0138] Method for sidelink DRX

[0139] Definition of active behavior

[0140] In the following embodiments, a WTRU can determine an active behavior on the sidelink (PC5 reference point interface) in order to reduce the power consumption of the WTRU performing sidelink transmissions. The PC5 reference point interface can be used in instances where a WTRU communicates directly with another (peer) WTRU over a direct channel between the units. In this case, there is no need to communicate with the core network. Examples of such PC5 direct communication can include communications between vehicles and other devices, such as vehicle-to-vehicle (V2V) or vehicle-to-anything (V2X) communications where a vehicle uses a WTRU. In one example, the WTRU can be a mobile handset that employs sidelink (SL) communications on a PC5 reference point communication link. The active behavior can be determined dynamically by the WTRU (e.g., based on measurements of the sidelink and / or reception and / or transmission of data from an upper layer or a peer WTRU) or can be configured by the network. Additionally, the network (NW) can configure a set of measured values (e.g., sidelink measurement values) and a corresponding active behavior to be applied by the WTRU. Additionally, the WTRU can change its active behavior as a result of an event related to receiving data (possibly from a peer WTRU, or from an upper layer for transmission) or receiving an explicit indication to change such active behavior.

[0141] In the following discussion, the active behavior can include any of the following:

[0142] - whether the WTRU is considered active (e.g., monitoring the physical sidelink control channel (PSCCH) and / or PDCCH) at a given time;

[0143] - DRX cycle: the wake-up periodicity when performing DRX;

[0144] - values and / or whether to use one or more timers associated with the DRX behavior, similar to Uu DRX timers, such as:

[0145] - inactivity timer associated with sidelink transmissions;

[0146] - on-duration timer associated with sidelink transmissions;

[0147] - slot offset;

[0148] - retransmission timer;

[0149] - HARQ round trip time (RTT) timer; and / or

[0150] - DRX short cycle timer.

[0151] - length of the listening window for a resource pool for listening mode 2 resource allocation.

[0152] - Number of candidate subframes or slots in the resource selection window that can be considered by the WTRU for transmission (as resulting listening resources).

[0153] - Number of sub-channels, number of frequency resources, initial, last sub-channel / frequency resource to be considered for listening and / or resource allocation.

[0154] - Number of candidate frequency resources or sub-channels that can be considered by the WTRU for transmission.

[0155] - Offset of one or more listening and / or resource selection subframes. For example, the WTRU can determine to perform listening in subframe nl + j*P, where nl is an offset of a system frame number (SFN), j is an integer value, and P is a fixed / (pre-)configured value.

[0156] - Number of repetitions performed by the WTRU, possibly for the same transport block (TB), possibly to reach other WTRUs in DRX.

[0157] - Amount of resources and / or resource pools that can be used for reception / transmission / listening, e.g., the WTRU can be configured with multiple active states (e.g., low, high, medium), whereby each state can be associated with one or more amounts of resources and / or resource pools usage, and can transition between such states based on any of the events described herein.

[0158] - Activation / deactivation of channel state information (CSI) reporting and / or HARQ feedback, or whether the WTRU is allowed / required to send HARQ and / or CSI feedback.

[0159] - Number of receive (RX) antennas used or activated. The number of RX antennas used or activated can be referred to as the maximum number of layers. For example, a first configuration of RX antennas can support a single layer as the maximum number of layers, while a second configuration of RX antennas can support two layers as the maximum number of layers.

[0160] - How the WTRU sets specific values for certain timers (e.g., HARQ RTT timer, retransmission timer). That is, whether the WTRU is expected to receive during the retransmission timer.

[0161] In the following, the following terms can be effectively understood as related to time units: time slot, sub-slot, mini-slot, subframe, transmission time interval (TTI), radio frame, etc. Furthermore, a symbol and a set of symbols can indicate a period of time in which such symbols occur.

[0162] Active behavior determined based on events related to sidelink reception, transmission

[0163] An active behavior can be determined based on the reception of a trigger and / or a measurement by the WTRU, similar to the reception of PDCCH for Uu DRX. Specifically, the WTRU can reset an inactivity timer, or have any behavior that modifies its active behavior as a result of any of the following:

[0164] - reception of a Sidelink Control Information (SCI), whereby the SCI can be:

[0165] a. an SCI scheduling data,

[0166] b. an SCI performing an announcement of future scheduling data,

[0167] c. an SCI that can trigger a Channel State Information (CSI) report,

[0168] d. an SCI that can request associated HARQ feedback for scheduling data,

[0169] e. an SCI that can indicate that another SCI (e.g., a first SCI) needs to be monitored, decoded, attempted to be decoded, or received (e.g., a second SCI).

[0170] f. an SCI that does not reserve another resource in the future, and / or is associated with a periodic Sidelink (SL) process but it is the last reserved resource associated with the periodic SL process,

[0171] g. an SCI indicating that resource reselection is performed,

[0172] h. an SCI containing some explicit indication to modify the active behavior of the receiving WTRU.

[0173] - reception of a Downlink Control Information (DCI) scheduling a sidelink.

[0174] - reception of sidelink data, whereby such data is addressed (per L2 ID) to the RX WTRU

[0175] - reception of a Sidelink Wake-up Signal (S-WUS), wherein the WTRU can monitor a Physical Sidelink Control Channel (PSCCH) in a certain time window when the WTRU receives an associated S-WUS signal. Otherwise, the WTRU can skip monitoring PSCCH in the time window. The S-WUS can be one or more of the following:

[0176] a. a special SCI indicating wake-up. The SCI can be used for S-WUS, which can include at least one or more of the following:

[0177] (i) a destination ID or a source ID; a WTRU configured with the destination ID or the source ID can wake up.

[0178] (ii) Time window size; the WTRU can monitor PSCCH during the indicated time window after S-WUS reception.

[0179] (iii) Resource pool index or identification; the WTRU can monitor PSCCH in the indicated resource pool.

[0180] (iv) Bandwidth part (BWP) and / or carrier ID; the WTRU can monitor PSCCH in the indicated BWP and / or carrier.

[0181] b. A predetermined signal (e.g., sequence, reference signal) can be indicated to wake up.

[0182] - Reception of a data PDU on sidelink, where such data PDU can be further conditioned according to the properties of the PDU or the content of the PDU.

[0183] a. For example, the WTRU can have a first behavior (e.g., reset inactivity timer) when the PDU contains data from a logical channel (LCH), and a second behavior (e.g., do not reset inactivity timer) when the PDU includes control information (e.g., MAC control element (CE), CSI feedback, PC5 RRC, etc.).

[0184] - Reception of a SL synchronization signal block / physical broadcast channel (SSB / PBCH).

[0185] - Reception of PC5-RRC signaling.

[0186] - Reception of a sidelink MAC control element (SL MAC CE).

[0187] For example, the WTRU can initiate DRX on PSCCH upon occurrence of any of the above events. For example, the WTRU can initiate / stop an inactivity timer (whose expiry causes initiation of DRX on PSCCH) upon occurrence of any of the above events.

[0188] In the following sections, any solution / implementation referring to “reception” can mean reception of any of the above trigger items.

[0189] The WTRU can autonomously enable / disable power saving behavior

[0190] The WTRU can autonomously disable any power saving behavior or any behavior related to power saving described herein based on one or more factors determined at the WTRU, which can include:

[0191] - WTRU location: For example, a WTRU can be configured with a set of zones or zone configurations, whereby the power saving behavior described herein is enabled / disabled (e.g., enabled in zone X, disabled in zone Y).

[0192] - Current WTRU battery life: For example, a WTRU can be (pre)configured with a battery life percentage above which the power saving behavior is disabled.

[0193] - Resource pool congestion: For example, a WTRU can be (pre)configured with a channel busy ratio (CBR) range above / below which the power saving behavior is disabled / enabled.

[0194] - Upper layer service configuration: For example, a WTRU can be (pre)configured with a set of L2 IDs for which the power saving should be disabled. When such a WTRU is configured with such a service, it can disable the power saving behavior (possibly for that service, or for all transmissions).

[0195] - Broadcast type: For example, a WTRU can be (pre)configured to perform the power saving behavior only for certain broadcast types (e.g., for unicast transmissions, but not for broadcast / groupcast transmissions).

[0196] - Attributes associated with group information: For example, a WTRU can be (pre)configured to perform the power saving behavior only when its group transmission is associated with a certain group size, knowledge of the group size, knowledge of the WTRU IDs within the group, or similar group information provided by the upper layer. For example, a WTRU can perform a certain power saving behavior only when the group size associated with a certain group transmission / reception is known.

[0197] - QoS of current pending or configured transmissions / receptions (e.g., based on sidelink radio bearer (SLRB) configuration): For example, a WTRU can disable the power saving behavior when the WTRU and / or peer WTRU has an SLRB established with a certain QoS, or for which the SLRB configuration indicates that the power saving behavior should be disabled.

[0198] - WTRU capability: For example, if other operations at the WTRU cause the WTRU to exceed its capability, the power saving can be enabled to meet the WTRU capability.

[0199] - Number of radio access technologies (RATs): For example, if a WTRU uses both LTE V2X and NR V2X, the WTRU can use the power saving behavior for NR V2X operation (or LTE V2X operation). However, if the WTRU uses only NR V2X, the WTRU can disable the power saving behavior.

[0200] - WTRU speed (absolute or relative): For example, if the WTRU speed is above a threshold, the WTRU can disable the power saving behavior. Otherwise, the WTRU can enable the power saving behavior.

[0201] - Declare radio link failure (RLF): When RLF is declared, the WTRU can enable / disable the power saving behavior.

[0202] Active behavior can be characterized by performing or not performing different behaviors on the sidelink of the WTRU

[0203] Active behavior at the WTRU can be characterized by performing or not performing different behaviors on the sidelink. Specifically, in the discussion herein, any reference to “DRX” or “sidelink DRX” can refer to different active behavior performed on the sidelink during active time and inactive time. Active time and inactive time can be characterized by differences in the WTRU:

[0204] - PSCCH decoding.

[0205] a. Whether the WTRU performs PSCCH decoding. For example, the WTRU can perform PSCCH decoding when active and not perform PSCCH decoding when inactive.

[0206] b. Number or configuration of subchannels for which decoding is performed. For example, the WTRU can perform PSCCH decoding on a first set of subchannels when active and a second set of subchannels when inactive. For example, the WTRU can assume a first configuration of subchannels when active and a second configuration of subchannels when inactive.

[0207] c. Strength of PSCCH decoding. For example, the WTRU can perform a first number of blind decodes on PSCCH when active and a second set of blind decodes on PSCCH when inactive.

[0208] d. Type of PSCCH decoding. For example, the WTRU can decode a first set of SCI transmissions when active and can decode a second set of SCI transmissions when inactive. For example, the WTRU can decode first stage SCI only when active and can decode first stage SCI and second stage SCI when inactive. For example, the WTRU can decode first SCI (e.g., SCI-1) when inactive and can decode associated SCI (e.g., SCI-2) only when active. For example, in one application of the above, the WTRU can change from monitoring only SCI-1 to monitoring both SCI-1 and SCI-2 based on a fixed time period of monitoring of SCI-2 and / or time since last successful decoding of SCI-2.

[0209] e. Perform sensing. For example, the WTRU can change any of the following behaviors depending on whether the WTRU is active or inactive.

[0210] (i) Whether the WTRU performs sensing, possibly for the purpose of resource selection.

[0211] (ii) Whether the WTRU updates the sensing results.

[0212] (iii) Any parameters or properties related to the WTRU sensing algorithm, such as sensing window, number of time / frequency resources to be sensed, threshold for determining availability of data, whether to perform sensing for pre-emption, etc.

[0213] - Synchronization. The WTRU can perform transmission of synchronization sources when it is active, and can not perform such transmission when it is inactive.

[0214] - Measurements on sidelink (e.g., related to unicast), such as CSI request / reporting, reference signal received power (RSRP) measurement request / reporting, radio link monitoring / radio link failure (RLM / RLF).

[0215] a. For example, active behavior can consist of performing such operations, while inactive state can consist of not performing such actions.

[0216] b. For example, active behavior can consist of performing the following operations:

[0217] (i) Different time-frequency configurations (more frequent, less frequent).

[0218] (ii) Different parameter configurations (e.g., different number of HARQ failures / radio link control (RLC) failures / timers / counters for RLF, different averaging for reference received radio power (RSRP) measurements).

[0219] (A). Channel quality feedback transmission behavior can depend on WTRU activity state / behavior

[0220] In one example, the WTRU's channel quality feedback behavior can depend on the WTRU active state. Specifically, when the WTRU is in an active state, the WTRU can perform certain operations with respect to channel quality feedback. When the WTRU is in an inactive state, the WTRU can perform a second set of actions (e.g., limited operations). In this and any of the example solutions herein, channel quality feedback can refer to CSI feedback or RSRP reporting, or any other measurement feedback provided by a WTRU to another WTRU. In this context, the example solutions specific to CSI feedback can also apply to RSRP reporting or other types of feedback, and vice versa. The WTRU can change any of the following with respect to its feedback reporting behavior depending on its active state:

[0221] - whether the WTRU reports feedback.

[0222] - the priority associated with feedback reporting transmissions relative to other transmissions.

[0223] - the timing of feedback reporting transmissions, possibly relative to CSI requests.

[0224] - the timing of feedback reporting transmissions, possibly relative to active behavior (e.g., DRX on period).

[0225] - resource selection rules associated with resource selection for transmitting feedback.

[0226] The WTRU can also change any of the above with respect to feedback reporting behavior when transmitting CSI feedback depending on other aspects of the active behavior itself. For example, the timing of the DRX on duration (or active behavior) with respect to the CSI feedback window can further determine the modified CSI feedback transmission behavior.

[0227] In one example embodiment, a WTRU can respond to a CSI feedback request only when not configured with DRX or power saving mechanisms associated with some limited activity behavior. In another example embodiment, a WTRU can provide CSI feedback only when it can be provided within the ON duration (or some expected decoding period) of the WTRU or a peer WTRU, otherwise the WTRU can drop the CSI feedback transmission. In another example embodiment, a WTRU can send CSI feedback only when the WTRU has pending data to transmit and other DRX based rules described herein allow such transmission. If the WTRU does not have pending data to transmit, possibly within the CSI feedback window, the WTRU can drop the CSI feedback transmission (i.e., transmission of CSI feedback only is not allowed during DRX). In another example embodiment, a WTRU can change the priority associated with CSI feedback transmission according to the activity state. Specifically, the WTRU can set the feedback to a first priority when the WTRU is in an active state, and the WTRU can set the priority to a second value when the WTRU is in an inactive state. In another example embodiment, a WTRU can decide whether to send CSI feedback with respect to the CSI feedback window / delay of the active period duration. Specifically, the WTRU can send CSI feedback if the delay falls within the DRX active time / duration, or some delays fall within some offset of the end of the DRX active time / duration. Otherwise, the WTRU can drop the CSI feedback report. In one example, a WTRU can be configured with periodic RSRP reporting. The WTRU can measure and / or report such RSRP only when the periodic reporting time coincides with the active monitoring period of the WTRU and / or a peer WTRU. The WTRU can also delay such measurement and / or reporting to the next active monitoring period of the WTRU and / or a peer WTRU.

[0228] For example, a RX WTRU can monitor or receive a PSCCH within an active time, and the WTRU can skip monitoring or receiving the PSCCH outside of the active time. A RX WTRU is a WTRU that receives with respect to a particular transmission from another entity, such as a peer WTRU or a core network entity. A TX WTRU is a WTRU that performs a transmission to another entity, such as a peer WTRU.

[0229] A. A PSCCH can consist of one or more SCI. For example, a two-stage SCI can be used, where a PSCCH can carry two SCI (e.g., SCI-1 and SCI-2). A WTRU can monitor a first stage SCI (e.g., SCI-1) only in an OFF duration (or inactivity time), and a WTRU can monitor a first stage and a second stage SCI (e.g., SCI-1 and SCI-2) in an ON duration (or activity time). In the following, an activity time, an ON duration, a time window in which a WTRU is able to monitor a PSCCH, and an active window can be used interchangeably. Also, an inactivity time, an OFF duration, a time window in which a WTRU is able to skip monitoring a PSCCH, and an inactive window can be used interchangeably herein.

[0230] (i) A SCI-1 can include DRX activity related information. For example, a SCI-1 can indicate that a specific WTRU or a group of WTRUs wake up or skip monitoring a PSCCH for a specific duration.

[0231] (ii) A SCI-1 can indicate whether an associated SCI-2 needs to be monitored in an OFF duration. Thus, a WTRU can determine whether the WTRU needs to decode an associated SCI-2 based on an indication in a SCI-1. If a WTRU is in an ON duration, the WTRU can decode a SCI-2 regardless of the indication in a SCI-1, or if there is no such indication in a SCI-1.

[0232] b. When a WTRU is configured with more than one destination ID, the WTRU can monitor a PSCCH in a slot that is an active slot in any of the DRX configurations. Alternatively, the WTRU can determine a destination ID with the highest L1 priority and the activity is based on the DRX configuration associated with the determined destination ID.

[0233] RX WTRU behavior for determining activity / inactivity

[0234] Method for determining WTRU activity behavior configuration

[0235] (e.g., how a WTRU determines its DRX cycle configuration parameters).

[0236] Separate reception activities defined by the WTRU in combination, by transmission type and / or intended receiver

[0237] In subsequent examples, a specific WTRU behavior can depend on a specific cast type of a transmission. For example, a determination of a L2 ID based DRX configuration can be used only for groupcast and / or broadcast. Other examples of such behavior limited to a specific cast type are not excluded.

[0238] In an embodiment, a WTRU can be defined or configured with different reception activity behavior (e.g., set of timers, DRX mechanism, DRX configuration, etc.) for different types of transmissions on the sidelink. Furthermore, the WTRU can also combine the independent activity behavior associated with each type of data being received to determine the overall activity behavior or resource set for the WTRU to monitor (e.g., determine the actual slots and / or subchannels for the WTRU to perform sidelink control channel monitoring). The WTRU can potentially monitor SCI only for a particular transmission type where the DRX activity behavior associated with that transmission type indicates that the WTRU should be active. Alternatively, the WTRU can be active if at least one of its activity behaviors is one where its transmission type indicates that the WTRU should be active.

[0239] Different reception activity behavior can be performed for each different transmission type. The different reception activity behavior can consist of, for example:

[0240] - different DRX cycles, cycle offsets, on-duration, DRX timers, etc. or any similar configuration;

[0241] a. For example, a WTRU can maintain a DRX cycle, offset, inactivity timer, etc. for each transmission type. For example, when receiving SCI associated with a first transmission type, the WTRU can reset the inactivity timer associated only with that first transmission type.

[0242] - different functions within the DRX mechanism;

[0243] A. For example, a WTRU can use an inactivity timer / mechanism to determine the wake-up time for one transmission type but not for another transmission type.

[0244] - different DRX schemes:

[0245] a. For example, a WTRU can use a timer-based scheme for DRX (i.e., DRX cycle, on-duration, etc.) described herein for one transmission type and a pool-based scheme (e.g., monitor separate resource pools for active vs. inactive states, or implement DRX with monitoring sparse resource pools) described herein for another transmission type.

[0246] - different sets of active resources defined as a particular resource pool, or a set of active resources defined within a resource pool.

[0247] In particular, the transmission type can encompass any one or a combination of the following:

[0248] - transmission mode (i.e., mode 1 transmission vs. mode 2 transmission).

[0249] - Broadcast type (i.e., unicast vs. groupcast vs. broadcast).

[0250] - Uu transmission / reception vs. sidelink transmission / reception.

[0251] - Operation on different resource pools with different configurations (e.g., physical sidelink feedback channel (PSFCH) configuration, DRX configuration, etc.).

[0252] - Sidelink reception processes, possibly associated with different attributes, such as:

[0253] a. HARQ enabled vs. HARQ disabled.

[0254] b. Different expected reception periodicity for the sidelink process, based on, e.g., SCI reserving resources.

[0255] c. Periodic transmission vs. aperiodic transmission.

[0256] d. Reception according to configured grant vs. according to dynamic grant.

[0257] - Slot type (e.g., normal slot vs. mini-slot, where a mini-slot is referred to as a slot containing a smaller number of consecutive symbols).

[0258] - L2 source and / or destination ID.

[0259] - DRX / active behavior configuration (possibly identified by the TX WTRU in its transmission).

[0260] - QoS parameters (e.g., L1 / L2 priority, PC5 QoS identifier (PQI), or PQI group).

[0261] A WTRU can determine whether it should be active based on the reception activity behavior associated with the transmission type. For example, a WTRU can maintain one or more timers (e.g., inactivity timer, etc.) associated with reception of a particular transmission type. For example, a WTRU can reset its inactivity timer upon reception of data associated with the transmission type. The WTRU can determine whether it is active for the transmission type based on whether one or more timers are running and / or not running.

[0262] A WTRU can be configured with rules to determine when it is active (e.g., monitoring SL PSCCH for SL scheduling) based on independent activity behavior associated with each transmission type. Such rules can be based on any of the following:

[0263] - Having at least one activity behavior indicating that the WTRU should be active.

[0264] - having a certain number of active behaviors indicate that the WTRU should be active.

[0265] - having at least one active behavior with a (pre-)configured or predetermined property that the WTRU should be active, where such property can be any of the following:

[0266] a. priority or other QoS property.

[0267] b. presence or value of certain configuration aspects or parameters that can be associated with the SLRB, such as presence of a range parameter associated with the SLRB, or whether the RLC entity is configured with acknowledgement mode (AM), mode, etc.

[0268] When at least one of the active behaviors indicates that the WTRU should be active, the WTRU can determine that it is active (e.g., monitor the SL PSCCH). Alternatively, when at least one of a subset (possibly configured) of the active behaviors indicates that the WTRU should be active, the WTRU can determine that it is active (e.g., monitor the SL PSCCH).

[0269] For example, the RX WTRU can be configured with active behaviors for each transmission type, where the transmission type can be any of the aforementioned factors. For example, for each transmission type, the RX WTRU can be configured with any of the following:

[0270] - a DRX cycle or slot period in which the WTRU always monitors the PSCCH to schedule and / or change to a different RX pool.

[0271] - an on duration, or number of potentially consecutive slots, in which the WTRU monitors the PSCCH and / or remains on the active RX pool before changing back to the inactive RX pool.

[0272] - an inactivity timer that the WTRU can reset upon receiving a sidelink schedule for the transmission type.

[0273] A WTRU can determine the slots for active PSCCH monitoring for scheduling based on a combination of each of the independent activity behaviors associated with each type of transmission. For example, a WTRU can wake up to perform PSCCH monitoring in order to schedule and / or change the RX resource pool according to each slot decided by the DRX cycle for each type of transmission. For example, a WTRU can start multiple on-duration timers, where each such timer is associated with each type of transmission of the WTRU and is started when the WTRU performs PSCCH monitoring for scheduling according to the corresponding DRX cycle. The WTRU can also start an inactivity timer upon receiving SCI indicating a particular type of transmission, where the value of the inactivity timer can be determined based on the indicated configuration. If no inactivity timer is running and no on-duration timer, the WTRU can determine that it can stop monitoring PSCCH for scheduling.

[0274] (A). WTRU has separate activity behavior for broadcast and / or for each unicast link of the WTRU

[0275] In one example, a WTRU can be configured with a SL DRX behavior for broadcast reception (e.g., a DRX configuration with a set of timers). In addition, the WTRU can be configured with additional DRX behavior for each unicast link that is active at the WTRU. The DRX behavior for each type of transmission can also be further defined differently and can consist of any of the behaviors defined herein. Specifically, for broadcast, the WTRU can select a DRX configuration where the reception activity of the WTRU is determined based on the received QoS (as described herein). On the other hand, the WTRU can have separate DRX procedures or activity behavior for each established unicast link and can define the activity behavior based on receiving a reservation signal (as described herein). In addition, the WTRU can also combine the groupcast DRX cycle behavior with all independent unicast DRX behaviors to determine a single active time. Specifically, the WTRU can determine the active time based on at least one of the DRX behavior for unicast or broadcast such that the WTRU can be active.

[0276] In one example, a WTRU can be configured with a DRX behavior for aperiodic (one-shot or asynchronous) transmissions (i.e., a DRX configuration with a set of timers) and can be configured to perform DRX based on receiving a reservation signal for periodic transmissions (as discussed herein). The WTRU can monitor the PSCCH for periodic transmissions based on receiving a SCI reservation (possibly with independent DRX behavior for each periodic reception) and also adhere to additional aperiodic DRX configuration for possible reception of one-shot transmissions. In one example application of the above, a WTRU can perform DRX between periodic transmissions and disable DRX when receiving a SCI indicating that there is an asynchronous transmission.

[0277] (B). WTRU has separate active behavior for different L2 source / destination IDs

[0278] In one example, a WTRU can be configured (e.g., by the network or by upper layers) with a reception active behavior for each source and / or destination L2 ID or group thereof. For example, a WTRU can receive a reception active behavior or changes thereof for a specific source and / or destination ID from a peer WTRU in PC5-RRC signaling and / or MAC CE. For example, a WTRU can receive a reception active behavior for a specific L2 ID or group of L2 IDs in a system information block (SIB) or dedicated signaling and / or after a request from the network. For example, a WTRU can receive a DRX configuration (e.g., on duration, DRX cycle, inactivity timer, etc.) and / or a pool set to be used for different active states and associated with a source / destination L2 ID in PC5-RRC. A WTRU can determine its active time according to the active behavior of at least one PC5-RRC connection at the WTRU and / or the source / destination L2 ID of interest. For example, if a WTRU determines that it should be active for at least one L2 source / destination ID (based on the source / destination L2 ID active behavior), the WTRU can be active and monitor the physical sidelink shared channel (PSSCH). In particular, the active time can be defined as the joint of the active times defined for each of the source / destination L2 IDs of interest to the WTRU. A WTRU can maintain separate active behavior (e.g., set of timers, on duration, active resource pool, etc.) for each source / destination L2 ID. A WTRU can perform any of the behaviors described herein (e.g., reset inactivity timer, determine on duration, etc.) according to such timers or active state properties based on receiving SCI matching the source / destination associated with the active state behavior.

[0279] In the above example, a source / destination ID can encompass any identification (e.g., destination index) derived from or related to these identifications as well as any indication of a service, service type, or similar defined by upper layers. For example, a WTRU can receive a DRX configuration to be applied for a specific destination index when reporting the L2 ID and its associated destination index to the network.

[0280] A WTRU can receive the mapping information of L2 ID to DRX configuration in different ways. In one example, a WTRU can receive a list of DRX configurations, and for each DRX configuration, the applicable or allowed L2 IDs. In another example, a WTRU can receive a table / list of L2 IDs, and for each, the corresponding DRX configuration to be applied (e.g., index of the DRX configuration).

[0281] (C). WTRU determines whether to perform DRX based on whether the L2 ID of interest is configured for DRX

[0282] In one example, the WTRU can determine whether to perform SL DRX or continuously monitor based on the DRX status of one or more of its configured / interested L2 IDs. For example, the WTRU can receive (e.g., from upper layers or the NW) a configuration of L2 IDs that are configured / not configured to operate in DRX. If all of the WTRU’s interested L2 IDs are configured with DRX, the WTRU can operate in SL DRX. If at least one of the WTRU’s interested L2 IDs disables DRX or is configured without DRX, the WTRU can disable DRX. If an interested L2 ID is added / removed from its list of interested L2 IDs, and thus the condition to enable / disable DRX is changed, the WTRU can enable / disable DRX.

[0283] (D). WTRU has separate active behavior for different active behavior configurations

[0284] In one example, the WTRU can be configured with an active behavior for each of a set of active behavior configurations. Each such configuration can be identified by a configuration ID. The TX WTRU can transmit the configuration ID with one or more of its transmissions. For example, the TX WTRU can transmit the configuration ID in SCI.

[0285] The RX WTRU can be configured with an active behavior for each of the expected / configured DRX configurations. For example, for each expected / configured DRX configuration, the RX WTRU can be configured with any of the following:

[0286] - a DRX cycle or slot period in which the WTRU always monitors PSCCH to schedule and / or change to a different RX resource pool.

[0287] - an on-duration, or number of potentially consecutive slots, in which the WTRU monitors PSCCH and / or remains on an active RX pool before changing back to an inactive RX pool.

[0288] - an inactivity timer that the WTRU can reset upon receiving a sidelink schedule for the indicated configuration.

[0289] The WTRU can determine its expected / configured DRX configurations according to NW (pre-)configuration and / or sidelink RRC configuration (e.g., from a peer WTRU).

[0290] The WTRU can determine the slots for active PSCCH monitoring for scheduling based on a combination of each of the independent active behavior associated with each desired / configured DRX configuration. For example, the WTRU can wake up to perform PSCCH monitoring in order to schedule and / or change the RX resource pool according to each slot decided by the DRX cycle of each desired / configured DRX configuration. For example, the WTRU can start multiple on-duration timers, where each such timer is associated with each of its desired / configured DRX configuration and is started when the WTRU performs PSCCH monitoring for scheduling according to the corresponding DRX cycle. The WTRU can also start an inactivity timer upon receiving SCI indicating a particular DRX configuration, where the value of the inactivity timer can be determined based on the indicated configuration. If there is no running inactivity timer (associated with any desired / configured DRX configuration) and no on-duration timer (associated with any desired / configured DRX configuration), the WTRU can determine that it can stop monitoring PSCCH for scheduling.

[0291] The TX WTRU can select the active behavior configuration (e.g., the configuration ID to be transmitted in SCI) based on any of the following:

[0292] - one or more QoS parameters (e.g., L2 / L1 priority) associated with the data being transmitted.

[0293] a. For example, the WTRU can select a (pre-)configured active behavior configuration when the transmission is performed with a particular L1 / L2 priority.

[0294] - SLRB or logical channel (LCH) of the data being transmitted.

[0295] a. For example, the WTRU can select a (pre-)configured active behavior configuration when the transmission contains data from a SLRB or LCH. For example, the WTRU can be configured with a mapping of SLRB or LCH to active behavior configuration.

[0296] - whether the transmission is periodic or aperiodic.

[0297] - buffer status of one or more logical channels.

[0298] (E). WTRU has separate active behavior for different received QoS

[0299] In one example, the WTRU can be configured with separate active behavior for one or more values of QoS parameters. For example, the WTRU can be configured (e.g., by the NW (pre-)configuration or sidelink RRC) with separate active behavior for each L1 / L2 priority. The WTRU can perform independent DRX for each of the L1 / L2 IDs of interest. Specifically, the WTRU can be configured via sidelink RRC with the L1 / L2 priority of interest and the corresponding active behavior. Alternatively, the WTRU can assume that all L1 / L2 priorities are L1 / L2 priorities of interest.

[0300] (F). WTRU combining independent active behavior for periodic and aperiodic transmissions

[0301] Examples described herein (DRX between periodic transmissions and inactivity timer after SCI reception) can be combined to define WTRU behavior under reception of periodic and aperiodic data. Specifically, the WTRU can perform DRX based on reception and follow a DRX configuration with DRX cycle, on-duration, and inactivity timer. Upon receiving SCI without periodic reservation while the WTRU is active, the WTRU can start the inactivity timer and can enter DRX upon expiration of such timer. In combination, the WTRU can receive SCI with indicated periodic reception while the WTRU is active (e.g., possibly while the inactivity timer is running). The WTRU can perform DRX between transmissions of periodic SCI transmissions, as long as the inactivity timer is not running and the on-duration timer is not running (i.e., the WTRU is in DRX with respect to aperiodic transmissions). In this case, the WTRU can be active only for reception of periodic SCI.

[0302] (G). WTRU reception activity based on received QoS determination

[0303] The WTRU can define its active behavior based on QoS related parameters associated with expected reception. The WTRU can determine the QoS of expected reception based on any of the following:

[0304] - services configured at the WTRU and one or more QoS parameters associated with each service (e.g., worst case QoS configured for any service).

[0305] - QoS associated with any established or configured bearer that the WTRU is receiving from.

[0306] - QoS parameters included in data / control received by the WTRU at or within some previous time period.

[0307] - an indication from the network.

[0308] - QoS parameters associated with the established unicast link over which the reception activity is defined.

[0309] How the WTRU determines the DRX configuration based on the QoS can also depend on the cast type. For example, in unicast, the WTRU can determine the QoS based on the QoS profile and / or SLRB configuration established by the TX WTRU (and provided by the TX WTRU in the PC5-RRC signaling) and can determine the DRX configuration according to the QoS profile / SLRB. For groupcast / broadcast, the WTRU can be configured with a worst-case QoS profile associated with the L2 ID. Other examples are provided below. How this is done can be categorized into any of the following categories.

[0310] First category: QoS can be associated / configured with L2 ID by the NW / upper layer:

[0311] (1). WTRU selects the DRX configuration associated with the QoS of its ongoing service

[0312] In one example, the WTRU can be configured with multiple DRX configurations (DRX cycle, on-duration, inactivity timer, etc.), possibly associated with a resource pool. Each DRX configuration can be associated with QoS related attributes, such as latency, priority, reliability, minimum communication range (MCR), etc., or values derived from any of these (e.g., PQI). The WTRU can be configured (by the network or upper layer) with a sidelink service (e.g., via the L2 ID of interest), and a mapping between such service and one or more QoS parameters. Such QoS parameters can also represent worst-case QoS parameters. For a WTRU configured in DRX, the WTRU can select the DRX configuration for the resource pool with the associated QoS parameters. Specifically, the WTRU can follow the pattern of wake-up time and / or apply the timers associated with the DRX configuration of the corresponding QoS configuration.

[0313] For example, a WTRU can be configured with a list of L2 IDs of interest (e.g., broadcast or groupcast). The WTRU can be configured with one or more QoS values (e.g., PQI) associated with each L2 ID. The WTRU can determine a single DRX configuration for each of its configured QoS values based on a configured mapping (e.g., DRX configuration and a set of allowed QoS values). The WTRU can determine its active time based on a combination of the DRX configurations for each of the QoS values of the L2 IDs of interest. If the WTRU is configured with multiple DRX configurations allowed for a QoS value, the WTRU can further select one of the multiple DRX configurations. Alternatively, the WTRU can determine a single QoS value from the configured set of QoS values for one or more L2 IDs. The WTRU can select the minimum / maximum value, can select based on some (pre-)configured or pre-defined table, or can select based on a specific QoS value (e.g., select the PQI with the minimum latency). Once selected, the WTRU can use the DRX configuration associated with that QoS value. The WTRU can also derive one QoS value for all its interested services or L2 IDs. Alternatively, the WTRU can derive one QoS value for all its interested DRX services or L2 IDs of a specific cast type (e.g., broadcast and / or groupcast). Alternatively, the WTRU can select one QoS value per L2 ID of interest.

[0314] Second category: QoS can be determined from the transmission of a peer WTRU.

[0315] (1). WTRU selects the DRX configuration associated with the priority of the most recently received data

[0316] In another example, a WTRU can be configured with multiple DRX configurations / active behaviors, possibly each associated with a QoS parameter (e.g., L1 priority or L2 priority) provided in the transmission by another WTRU. The WTRU can determine the DRX configuration / active behavior based on receiving past data marked with a specific L1 / L2 priority. Specifically, the WTRU can select the DRX configuration associated with the priority:

[0317] - received in the last transmission before entering a specific active state.

[0318] - for this configuration, most of the transmissions in the past time are associated with a specific priority.

[0319] - the number of transmissions over a certain past window of a specific priority is above a threshold.

[0320] - When receiving multiple transmissions with different priorities, the WTRU can be configured to select one associated active behavior based on some specified or (pre-)configured rules (e.g., configuration associated with the highest priority transmission).

[0321] For example, the WTRU can determine the value of a timer (e.g., on-duration, inactivity timer, etc.) that determines whether it is active based on priority and / or other received QoS parameters (e.g., MCR), possibly where such received parameters are associated with the transmission that caused the previous active state transition at the WTRU. For example:

[0322] - The WTRU can determine the DRX cycle and / or on-duration and / or periodicity of RX resource pool change based on the priority of the last SCI scheduled data received by the WTRU.

[0323] - The WTRU can determine the inactivity timer value (i.e., the period of time after which the WTRU moves to DRX) based on the L1 priority in the SCI received when such timer is reset. Specifically, the WTRU can start the inactivity timer upon receiving the SCI, whereby the expiration of such timer can move the WTRU to DRX. The WTRU can set the value of such timer based on the L1 priority in the SCI that started such timer.

[0324] In another example, the WTRU can change from one active behavior to another based on receiving data marked with a certain priority. For example, the change in active behavior can include a change from a short DRX cycle to a long DRX cycle, or vice versa.

[0325] For example, the WTRU can change from a configured short DRX cycle to a configured long DRX cycle after a certain period of time in which it does not receive one or more transmissions with a priority higher than a certain threshold priority.

[0326] For example, the WTRU can change from a long DRX to a short DRX after receiving one or more transmissions with a threshold value higher than a certain threshold priority.

[0327] (2). WTRU determines / changes DRX configuration based on QoS information received from any transmitter (e.g., in a group)

[0328] In another solution, the WTRU can determine / change the active behavior (e.g., DRX configuration) based on the received information associated with the application or the link for which the DRX should be applied. The determination / change of DRX can involve enabling / disabling DRX. The WTRU can maintain a specific active behavior or DRX configuration associated with the QoS information of the QoS level received in the last transmission received for that link. The WTRU can maintain a specific active behavior or DRX configuration associated with the worst case QoS transmission received for that link in the recent time period. The link can represent a unicast link or a broadcast / groupcast L2 ID. Upon receiving data or indication or QoS information indicating or requiring a different DRX configuration to be used, the WTRU can change to a different DRX configuration. Examples of such information can be:

[0329] - L1 or L2 priority information.

[0330] - QoS flow ID, PQI, QoS profile, or any indicator referring to QoS flow in a protocol layer (e.g., packet data convergence protocol (PDCP) or service data adaptation protocol (SDAP)).

[0331] a. For example, upon receiving data that can be associated with a link for which the received PQI has a higher level than the current maximum PQI, the WTRU can change its DRX configuration.

[0332] - MCR (minimum communication range).

[0333] - Other information or identifier that implicitly indicates the QoS or worst case QoS at the transmitter.

[0334] - Other information that can affect the ability to meet the QoS, such as:

[0335] a. Measurement of sidelink (e.g., CBR, CR, CSI, RSRP, etc.) sent by a peer WTRU and / or measured by the RX WTRU.

[0336] For example, the WTRU can determine / change its DRX configuration upon receiving a PQI of a different QoS class for which a different DRX configuration should be used. The WTRU can maintain such DRX configuration until it can receive data of a different PQI / PQI class that causes a change in the active behavior based on the determination mechanism described herein (e.g., combination of QoS / DRX configuration).

[0337] (3). WTRU determines / changes DRX configuration based on a new SLRB configured / created at the RX WTRU

[0338] In one solution that can be used in conjunction with the previous examples, a RX WTRU can determine / change its DRX configuration upon creating a SLRB for reception based on the QoS information and / or SLRB configuration associated with the SLRB. For example, a WTRU can determine its DRX configuration from its SLRB configuration. For example, a WTRU can be configured with one or more DRX configurations for a given established SLRB, which can be associated with only a subset of cast types and / or one or more L2 IDs. Similar to the discussion herein regarding selection of DRX configuration and / or active time based on a combination of QoS and / or DRX configuration, a WTRU can determine its DRX configuration and / or its active time based on a combination of DRX configurations associated with its established SLRBs for reception. Upon receiving a data packet that can be associated with an L2 ID, a RX WTRU can change the DRX configuration if the RX WTRU created a new SLRB configuration that is not compatible with the WTRU or requires the WTRU to change to a different DRX configuration. For example, a WTRU can be configured with a default DRX configuration when the WTRU is not configured with any SLRB. Upon creating a SLRB for reception, the WTRU can change to the active behavior associated with the DRX configuration configured for the SLRB and / or the QoS profile associated with the SLRB configuration.

[0339] A TX WTRU can have similar behavior to be able to reach a RX WTRU. Specifically, upon creating a SLRB for transmission, a TX WTRU can perform transmission such that the transmission is limited to the active time defined by the DRX configuration of the created SLRB (or the QoS profile associated with the created SLRB). In addition, the TX WTRU can assume a new DRX configuration after the first transmission associated with the SLRB, or after a certain number of transmissions after the first transmission for the SLRB.

[0340] (4). WTRU can be configured with a default DRX configuration before knowing the QoS

[0341] In one solution, a WTRU can use a default DRX configuration when the WTRU does not know the QoS associated with a service. Specifically, a WTRU can determine its DRX configuration from the QoS information received from a peer WTRU. In addition, a WTRU can use a default DRX configuration before receiving the QoS information from a peer WTRU. Such a default DRX configuration can be (pre-)configured at the WTRU. In addition, a WTRU can have multiple such default DRX configurations and can select the appropriate one based on the L2 ID of interest (using similar mechanisms defined herein for associated DRX configuration with L2 ID).

[0342] (5). WTRU sets the value of the DRX timer based on the priority of the most recently received data

[0343] In another example, a WTRU can be configured with different rules for handling timers associated with active behavior based on receiving data with different L1 priorities. Specifically, a WTRU can set the timer value based on the L1 priority of the SCI received in the active time. For example, a WTRU can reset an inactivity timer upon receiving a SCI, and can dynamically set such inactivity timer value based on the L1 priority of the SCI that resets the inactivity timer.

[0344] Receiving active behavior can depend on a combination of L2 ID and QoS

[0345] In one example, a WTRU can be configured with active behavior and / or DRX configuration based on a combination of L2 ID and QoS. Specifically, a WTRU can use the combination of L2 ID and QoS to determine the active behavior and / or DRX configuration.

[0346] In one example embodiment, a WTRU can be configured with a DRX configuration for each pair of L2 ID and QoS parameter (e.g., PQI or PQI group, or any other parameter defined herein). For example, a WTRU can be configured with a DRX configuration for L2 ID = x and PQI = y. A WTRU can determine the QoS associated with a transmission according to the L2 ID based on the mechanisms herein. For example, a WTRU can obtain QoS information from a transmission associated with an L2 ID to determine the possible PQI values (or QoS levels) allowed for that L2 ID. Alternatively, a WTRU can be configured with a DRX configuration per L2 ID pair and SLRB. A WTRU can determine the DRX configuration upon establishing an SLRB for a particular L2 ID based on the configuration.

[0347] In another example embodiment, a WTRU can be configured with multiple DRX configurations per L2 ID. A WTRU can select one of the multiple DRX configurations based on the QoS information received from the L2 ID. For example, a WTRU can select a first DRX configuration for PQI values above a certain threshold, and a second DRX configuration for PQI values below the threshold.

[0348] In another example embodiment, a WTRU can be configured with a set of L2 IDs that can share a DRX configuration associated with a QoS. Specifically, the WTRU can derive a DRX configuration based on the QoS and apply the DRX configuration for a set of L2 IDs configured as L2 IDs of interest. For another set of L2 IDs that can also be L2 IDs of interest of the WTRU, the WTRU can apply a modified DRX configuration (e.g., change one or more parameters of the active behavior or DRX configuration associated with the first set of L2-IDs).

[0349] In another example embodiment, a WTRU can derive a complete DRX configuration from a combination of parameters (DRX cycle, on-duration, etc.), some of which are configured according to a QoS and others of which are configured according to an L2 ID. For example, a WTRU can derive a DRX configuration for a pair of QoS and L2 ID by combining parameters configured for the L2 ID with parameters configured for the QoS level and deriving a DRX configuration / active behavior.

[0350] Reception activity of a WTRU determined based on a configuration provided by another WTRU

[0351] In one embodiment, a WTRU can determine its reception activity based on a configuration provided by another WTRU. For example, a WTRU can provide a DRX configuration to its peer WTRU via PC5-RRC signaling during unicast link establishment. Such reception activity can be specific to the unicast link associated with the PC5-RRC signaling used to initiate / configure the unicast link.

[0352] Reception activity of a WTRU determined based on a static configuration associated with a sidelink

[0353] In one embodiment, a WTRU can be statically configured (e.g., via SIB, dedicated RRC signaling from the NW or other WTRU, or pre-configured) with reception activity. For example, a WTRU can be configured with multiple possible active behaviors / DRX configurations, each of which is associated with an aspect of a sidelink, and can select from one such configuration to be applied to determine its monitoring behavior for PSCCH. Such activity can also be associated with a specific aspect of a sidelink communication. Specifically, a WTRU can be (pre-)configured with an active behavior / DRX configuration associated with any of:

[0354] - a sidelink service.

[0355] - one or more reception resource pools and / or any parameters associated with such resource pools.

[0356] a. For example, whether PUCCH is configured for a resource pool.

[0357] b. For example, whether pre-emption is allowed / disallowed on the resource pool.

[0358] - One or more transmit resource pools and / or any parameters associated with such resource pools.

[0359] a. For example, whether PUCCH is configured for the resource pool.

[0360] b. For example, whether pre-emption is allowed / disallowed on the resource pool.

[0361] - One or more L2 source and / or destination IDs.

[0362] - One or more SLRBs or SLRB configurations.

[0363] - QoS (received or configured).

[0364] - Broadcast type.

[0365] - Transmit mode (mode 1 or mode 2).

[0366] - Sidelink process or properties of such process (e.g., expected periodicity, whether such process / transmission enables / disables HARQ, periodic or asynchronous, maximum number of retransmissions, whether the process is associated with a configured grant, etc.).

[0367] - Type of SCI to monitor.

[0368] - Synchronization source (e.g., in physical shared broadcast channel (PSBCH) or SL master information block (MIB)) and / or configuration explicitly / implicitly indicated in transmission of synchronization signal.

[0369] (A) The WTRU can select from one of the multiple configured active behaviors or a combination of active behaviors

[0370] The WTRU can be further configured with certain rules to select the appropriate active behavior / DRX configuration when multiple active behaviors / DRX configurations are applicable due to the WTRU enabling multiple of the above factors. For example, the WTRU can be configured to receive data associated with multiple L2 destination IDs and each L2 destination ID can be configured with its own active behavior / DRX configuration. The WTRU can select the active behavior / DRX configuration to apply in the presence of multiple configurations based on any one or a combination of the following:

[0371] - Parameters that are part of the configuration itself.

[0372] a. For example, the WTRU can select the configuration that minimizes or maximizes certain parameters associated with the DRX configuration.

[0373] (i) For example, the WTRU can select the applicable active behavior / DRX configuration with the smallest value of DRX cycle, the largest value of on-duration, the largest value of inactivity timer, etc.

[0374] (1). For example, the WTRU can select based on a first rule (e.g., smallest DRX configuration), and if two configurations have the same value associated with the first rule, can select based on a second rule.

[0375] (ii) For example, the WTRU can select the applicable active behavior / DRX configuration corresponding to the densest RX resource pool.

[0376] - The configuration can be associated with the most and / or most recently received for that aspect in a time period.

[0377] a. For example, the WTRU can select the configuration associated with the aspect for which the most scheduling SCI has been received in a recent time period or time window.

[0378] - A priority associated with one of the above factors that can be pre-configured or can be dynamically changed (e.g., based on signaling by the NW, PC5-RRC, or SCI).

[0379] a. For example, the WTRU can receive a priority associated with each individual aspect (e.g., L2 ID), and can select the DRX configuration associated with the aspect (e.g., L2 ID) with the highest priority.

[0380] b. For example, the WTRU can receive (e.g., in SCI) an indication (e.g., L2 ID) to change / update the priority associated with the aspect associated with the SCI, and can change its selection criteria upon receiving such indication.

[0381] - A configuration that has been activated by the WTRU based on the factors described herein.

[0382] The WTRU can be configured to select one active behavior / DRX configuration from only a subset of the configured active behavior / DRX configurations. Such determination can be made based on whether the active behavior / DRX configurations are considered compatible (i.e., which subset of the configured active behaviors can be used to select an active behavior). The WTRU can determine the compatibility of two or more DRX configurations based on:

[0383] - The resource pattern that the WTRU expects to actively monitor PSSCH for scheduling allows for selection of one of these configurations, where such pattern can be determined based on the parameters of the DRX configuration itself.

[0384] a. For example, the DRX configurations have at least one common or overlapping on-duration that occurs periodically.

[0385] b. For example, the DRX cycles of the DRX configurations are multiples of each other.

[0386] - The configuration itself.

[0387] a. For example, the DRX configurations can be associated with a configuration group, or can be configured to allow selection of a DRX configuration from a subset of the related configurations.

[0388] When a WTRU is unable to select a single DRX configuration from two or more applicable DRX configurations of the configurations, the WTRU can apply them independently, as further described herein.

[0389] A WTRU configured with multiple specific aspects of sidelink communication can further define its active behavior based on a combination of the active behavior of each configuration.

[0390] In one example, a WTRU can have a DRX configuration configured for each L2 destination ID used for broadcast communication. The WTRU can perform DRX on the sidelink based on the L2 destination ID configured by an upper layer that the WTRU is interested in receiving. In the case that the WTRU is configured with multiple L2 destination IDs, the WTRU can be active at any active time defined by any of the individual DRX configurations associated with each of the L2 IDs of interest.

[0391] - A TX WTRU can transmit data in slots within the active time (e.g., active slots) of a RX WTRU, where the active slots can be determined based on the destination ID (e.g., L1 or L2).

[0392] a. A set of destination IDs and their associated DRX configurations can be (pre-)configured.

[0393] b. The listening for resource selection can be performed in active time, on-duration, or active slots. Slots that are not within the active time (e.g., inactive slots) can be excluded from, or need not be included for, listening.

[0394] c. Resources reserved for future transmissions can only be valid within the active time. For example, a WTRU can assume that the reserved resources can not be used for sidelink transmissions outside of the active time.

[0395] d. The active time can be determined based on the on-duration only in the absence of an inactivity timer.

[0396] In one example, the WTRU can determine any aspect of its active / inactive state configuration based on receiving a synchronization source. In particular, the WTRU can be configured to monitor for synchronization source transmissions from a peer WTRU. Once the WTRU has selected a synchronization source, the WTRU can determine its active state configuration based on receiving a synchronization source transmission. In particular, the WTRU's active state configuration (e.g., timing of one or more wake-up slots, pattern of its wake-ups, etc.) can be determined based on a combination of:

[0397] - the PSBCH reception timing of the synchronization source.

[0398] a. For example, the WTRU's active state can be defined with respect to the timing of the WTRU's synchronization source transmission. In particular, the WTRU can define its on-period or active period to occur at a slot with respect to the reception slot of the synchronization source.

[0399] - information provided by the synchronization source in the PSBCH transmission.

[0400] a. For example, the WTRU can receive an active period, on-duration, timers related to DRX behavior, or any other such parameter described herein within the synchronization source transmission.

[0401] - a combination of the above.

[0402] a. For example, the WTRU can obtain a slot number or slot offset with respect to the timing of the PSBCH in which the WTRU should wake up.

[0403] (B). WTRU receives an active state configuration identification associated with a (pre-)configured or predefined active behavior

[0404] The WTRU can determine its active behavior based on receiving an active state configuration identification that identifies an active behavior that can be (pre-)configured (e.g., in RRC signaling or SIB) or predefined (e.g., in a specified table). For example, a first WTRU can transmit a determined active state configuration identification (e.g., in PSBCH), and a second WTRU can determine its active behavior (e.g., value of a timer) corresponding to the received identification in a (pre-)configured or predefined table.

[0405] (C). WTRU performs an active configuration request from the network

[0406] A WTRU can perform an activity configuration request from the network, which can be associated with one of the aspects of sidelink communication (e.g., L2 source / destination ID). Such a request can be in the form of an RRC message (e.g., SidelinkWTRUlnformation) over the Uu reference link. For example, a WTRU can provide the L2 ID associated with the activity configuration request from the network in an RRC message over the Uu reference link. A WTRU can further trigger a request for activity configuration based on certain triggers / conditions below (or other triggers discussed herein), or a combination thereof:

[0407] The WTRU establishes a unicast link with a peer WTRU.

[0408] The WTRU receives an indication from an upper layer to establish a sidelink unicast or sidelink group (e.g., the WTRU receives group information and / or group size and / or group member ID).

[0409] The WTRU does not have an active configuration (e.g., L2 source / destination ID) for an associated aspect of sidelink communication, which can be associated with a configuration of a specific gNB / cell, a specific group of gNBs / cells.

[0410] The WTRU does not receive sidelink data (e.g., L2 source / destination ID) associated with a specific aspect of sidelink communication within a (pre-)configured time period and decides to indicate a desire to move to DRX or change activity state / behavior.

[0411] The WTRU enters a specific location (e.g., a pre-configured area) that triggers such a request.

[0412] The WTRU battery level reaches a specific threshold.

[0413] The measured CBR meets some (pre-)configured condition.

[0414] The WTRU has changed its activity state or activity state configuration.

[0415] The WTRU can include any of the following information in the activity configuration request:

[0416] a. Activity behavior / configuration obtained from a peer WTRU.

[0417] b. Current activity behavior / configuration at the WTRU, possibly in the form of an identification.

[0418] c. Identification of the activity behavior at the WTRU, or a priority, QoS, or similar attribute associated with the last change of activity state / behavior at the WTRU.

[0419] d. The number of data transmissions received over a period of time, possibly associated with an active behavior configuration, and possibly depending on the type of transmission (as defined herein).

[0420] Reception activity at a WTRU based on data scheduling of another WTRU

[0421] (WTRU's power saving behavior at the WTRU can be determined by the transmission [pattern] of sidelink data of a peer WTRU).

[0422] WTRU's reception activity determined based on information in SCI

[0423] In one solution, a WTRU can determine or change its active behavior based on the presence or absence of information in SCI or based on the value of such information in SCI. The presence or absence and / or value of such field / parameter can consist of any one or a combination of the following:

[0424] - Resource reservation period.

[0425] - QoS parameters (e.g., L1 priority, range).

[0426] - Location information (e.g., zone ID).

[0427] - Index of resource pool (e.g., identifying TX resource pool).

[0428] - Flag, bit or value reserving for power saving (e.g., enabling / disabling power saving, indicating the amount of time to stay awake, indicating the pattern of wake-up period, indicating active behavior configuration identification).

[0429] - Broadcast type.

[0430] - Demodulation reference signal (DMRS) pattern.

[0431] - Modulation and coding scheme (MCS).

[0432] - Specific pattern or set of time / frequency resource assignment.

[0433] - HARQ process ID.

[0434] - SCI format (e.g., format of second stage SCI).

[0435] - Beta offset indicator.

[0436] - Number of DMRS ports.

[0437] - NDI (new data indicator).

[0438] - CSI request.

[0439] - Destination / source ID.

[0440] - Redundancy version.

[0441] A WTRU can be configured to perform a first action or have a first active behavior when a SCI contains one or more of the above fields, and / or when one or more of the above fields has a certain value, and the WTRU can perform a second action or have a second active behavior when the SCI does not contain the field and / or when one or more of the above fields has a second value. Such first or second action can relate to aspects of the active behavior defined herein, for example:

[0442] - Whether to start, stop, or reset a timer related to defining an active time at the WTRU.

[0443] - Whether to change from one RX resource pool to another RX resource pool.

[0444] - A timer value related to an active behavior to be used.

[0445] - And so on.

[0446] (A). A power saving flag / value can change the active behavior associated with an aspect of a SCI

[0447] A WTRU can also change the active behavior / DRX configuration associated with one aspect of a SCI (as described herein) upon receiving information (another parameter), which can be in the same SCI or in a MAC CE / RRC contained in data scheduled by the SCI. For example, if a WTRU supports multiple independent active behaviors and / or selects a single active behavior from a set of configured active behaviors, the WTRU can receive a power saving flag or value that changes the active behavior associated with another aspect in the same SCI.

[0448] For example, a WTRU can receive a flag indicating to enable / disable an active behavior / DRX configuration associated with any of the following:

[0449] - L2 source and / or destination ID in the SCI.

[0450] - HARQ process ID of a HARQ process indicated in the SCI.

[0451] - Broadcast type in the SCI.

[0452] - Scheduling process associated with a periodic transmission.

[0453] When active behavior is enabled, the WTRU can perform DRX based on the associated DRX configuration. When active behavior is disabled, the WTRU can need to always monitor PSCCH for scheduling, possibly for the associated aspects (e.g., L2 ID, HARQ process, etc.).

[0454] For example, the WTRU can receive a new configuration (in the form of a configuration ID, or new parameters for the associated active behavior / DRX configuration) in SCI, and can change the behavior associated with any of the SCI aspects in the above examples.

[0455] (B). TX WTRU can set a power saving flag / value based on an event associated with data transmission

[0456] TX WTRU can set a power saving flag based on an event associated with data transmission, or any aspect associated with active behavior in SCI (as described herein). For example, any event associated with the determination of active behavior by the TX WTRU (described elsewhere herein) can further be used to modify or change the transmission in SCI that controls the peer WTRU active behavior.

[0457] WTRU reception activity based on forward reservation signal determination

[0458] In one embodiment, the WTRU can determine its active behavior based on receiving a resource reservation signal (e.g., in SCI), possibly associated with a transmission intended for the WTRU.

[0459] In one example, the WTRU can receive a first SCI reserving resources for data to be received by the WTRU at some future time, indicated by the first SCI. Such reception can be for the same TB (e.g., in case of blind retransmission) or can be for a new TB (e.g., in case of forward booking future transmission). The WTRU can perform DRX (i.e., no active decoding on the sidelink) for a certain number of slots after receiving the first SCI until receiving the next SCI (occurring at the reserved time) (or a certain number of slots before receiving the next SCI). In case the WTRU receives multiple periodic transmissions, the WTRU can perform DRX on all slots that do not correspond to the scheduled or reserved transmission by the WTRU for each periodic transmission received by the WTRU. In another related example, the DRX can start performing after a number of configurable slots from the first SCI, and / or can end performing after a number of configurable slots before the second SCI, where the number of such slots can further depend on QoS or CBR or other factors discussed herein.

[0460] (A). The WTRU monitors the sidelink at a pre-defined time / frequency to monitor for changes within the reservation period

[0461] A (RX) WTRU that determines its activity behavior based on receiving a forward reservation signal can be configured or determine a set of monitoring times within which it monitors / checks for changes within the reservation period. For example, the WTRU can monitor the PSCCH at a pre-defined time relative to the reservation time in order to receive possible changes within the reservation period (e.g., due to a reselection decision made by the TX WTRU). For example, the WTRU can monitor the PSCCH in multiple slots before and / or after the reservation time in order to determine possible changes within the reservation time. For example, the WTRU can monitor the PSCCH in multiple slots between two reservation times in order to determine possible changes within the reservation time. If the WTRU detects a reselection associated with a peer WTRU’s reservation, the WTRU can change its activity behavior to perform monitoring associated with the new periodic transmission and stop monitoring the old periodic transmission.

[0462] A (TX) WTRU that performs resource reselection can limit the resources used for transmission to a subset of time / frequency locations that are (pre-)configured for reservation time changes. Specifically, the WTRU that performs resource reselection can select, based on listening, only those resources from the (pre-)configured subset of resources associated with the indication of the reselection decision from the resources available for transmission. When performing the reselection, the WTRU can further indicate (e.g., in SCI) which periodic sidelink process has been reselected.

[0463] A (TX or RX) WTRU can autonomously determine the allowed resources (e.g., time) in which resource reselection can be performed. The WTRU can base such determination on rules so that both the TX WTRU and the RX WTRU can select the same resources for transmission after reselection (at the TX WTRU) and monitoring (at the RX WTRU). The amount / set of resources to be monitored can depend on:

[0464] - the periodicity of the sidelink transmission.

[0465] - the QoS associated with the periodic sidelink transmission.

[0466] - the CBR measured on the sidelink.

[0467] - the slot or frame number (or offset) associated with the periodic transmission.

[0468] - (sidelink or uplink) configuration parameters.

[0469] For example, the WTRU can select a set of N equally spaced time and / or frequency resources between periodic transmissions of a periodic sidelink process, where the WTRU performs monitoring of PSCCH in case of reselection decision (and thus, the TX WTRU can use these resources for reselection of the periodic sidelink process). The value of N can be determined based on a (pre-)configured formula that depends on the QoS and periodicity of the sidelink process.

[0470] For example, in case of unicast transmission, the peer WTRU can exchange the configuration of such time / frequency resources in PC5-RRC signaling during unicast link establishment.

[0471] (B). The capability of the WTRU to perform DRX between scheduled receptions / transmissions can depend on:

[0472] The WTRU can be allowed to perform DRX on a given slot based on its current transmission and / or reception status and / or measurements of the sidelink channel. For example, the WTRU can perform DRX between receptions of periodic transmissions announced by the peer WTRU in SCI. For example, the WTRU performing DRX between periodic receptions (as discussed herein) can further determine its capability to perform DRX on a given slot based on other factors. The WTRU can perform DRX according to a number of factors, such as any of the following:

[0473] - CBR of the resource pool:

[0474] a. In particular, if the CBR of the resource pool is high, the WTRU can not perform DRX between periodic receptions. For example, the WTRU can be configured with a threshold CBR below which the WTRU can perform DRX between periodic receptions.

[0475] - Based on information or related data in SCI.

[0476] a. For example, the SCI can indicate whether the WTRU can perform DRX between periodic receptions or should remain active. Such indication can be explicit (e.g., a one-bit indicator). Alternatively, such indication can be implicit based on the value of some other field or data within the SCI or associated data, such as:

[0477] (i) L1 priority is above or below a threshold.

[0478] (ii) The SCI indicates retransmission and time until retransmission is below a threshold number of slots.

[0479] a. For example, the indication in the SCI can apply to the time period between the reception of the SCI and the next periodic reservation, or to multiple periods (possibly more than one, possibly indicated in the SCI itself), or for an indefinite number of periods (e.g., until additional information is received in a future SCI).

[0480] b. For example, the SCI can contain such indication only between DRX times that allow / disallow periodic transmissions. In the absence of such indication, the RX WTRU can assume that it can perform DRX until the next indication, or can assume that it cannot perform DRX until the next indication.

[0481] - Based on a configuration from upper layers or from a peer WTRU.

[0482] a. For example, the WTRU can be (pre-)configured to perform DRX between periodic receptions.

[0483] b. For example, the WTRU can receive such configuration from a peer WTRU during unicast link setup.

[0484] c. For example, the WTRU can have a capability related to whether it is allowed to perform DRX between periodic receptions.

[0485] - Based on configured services and or L2 IDs of interest:

[0486] a. For example, the WTRU can be configured with a set of L2 IDs of interest, and an associated DRX behavior (whether to perform DRX between receptions) for each L2 ID, and if at least one L2 ID of interest is configured with a behavior and the corresponding L1 ID is received in the SCI, the WTRU can adhere to such behavior.

[0487] - Based on whether the WTRU has pending transmissions:

[0488] a. For example, a WTRU can perform DRX between receptions if it does not have any transmissions (of data or feedback) pending for execution. For example, a WTRU can perform DRX between receptions if the number of transmissions pending for execution and / or the buffer status at the WTRU is below a certain threshold. For example, a WTRU can perform DRX between receptions depending on whether it has any feedback and / or the timing of any feedback to the transmitting WTRU, such as HARQ feedback, Channel Quality Indicator (CQI) feedback, etc. For example, a WTRU can perform DRX if it does not need to send HARQ feedback between receptions, or if the HARQ feedback timing can be small (e.g., below a threshold) relative to the time between receptions. For example, a WTRU can not perform DRX if it receives a CSI request and the CSI transmission window expires between two expected receptions.

[0489] - Based on the time between any scheduled transmissions / receptions:

[0490] a. For example, a WTRU can be configured with a threshold time between periodic transmissions, and can only perform DRX between periodic transmissions if the transmission period is above this threshold (i.e., for small periodicities, there can be no benefit to performing DRX between periodic transmissions).

[0491] b. For example, a WTRU can perform DRX between a SCI reception and a scheduled HARQ feedback transmission (not necessarily related to the SCI reception) if the time between the SCI reception and the HARQ feedback transmission exceeds a certain number of slots.

[0492] - Based on the delay requirements of the data in the WTRU buffer:

[0493] a. For example, a WTRU can be allowed to perform DRX if there is no data (or a limited amount of data) in its buffer with a delay requirement that expires within the scheduled period of DRX. For example, a WTRU can be allowed to perform DRX over a set of slots if all the data in its buffer can be transmitted within its delay requirements after performing DRX over the set of slots.

[0494] - The presence / timing of retransmissions associated with an initial transmission.

[0495] a. For example, a WTRU can perform DRX between an initial transmission and a retransmission, or between multiple retransmissions, depending on the amount of time between such transmissions / retransmissions.

[0496] b. For example, a WTRU performing DRX between periodic transmissions can monitor the PSCCH to schedule on slots associated with an initial transmission, as well as monitor for retransmissions associated with the periodic transmissions.

[0497] - Based on whether the WTRU is configured with a set of resources that can be used for reselection (e.g., a defined set of resources, or another active behavior configuration whose active resources can be used).

[0498] - Based on whether the WTRU expects feedback (e.g., HARQ feedback, CQI feedback, RSRP, etc.) at one or more slots between scheduled receptions and the timing of such feedback.

[0499] a. For example, if the WTRU does not expect HARQ feedback, CQI feedback, or RSRP, the WTRU can perform DRX.

[0500] b. For example, if the time between any of the scheduled transmissions and the expected feedback and / or the time between feedback is greater than a threshold, the WTRU can perform DRX.

[0501] c. The WTRU can not perform DRX on slots where it can need to monitor PSCCH associated with scheduling:

[0502] (i) The WTRU expects HARQ feedback from its own transmission (i.e., a slot corresponding to the expected PSFCH timing associated with any of its HARQ-based transmissions).

[0503] (ii) The WTRU expects periodic RSRP measurements.

[0504] WTRU has different active behaviors for SCI that does or does not make forward reservations and / or reservation periodicity

[0505] In another related example (which can be used in combination with other examples herein), the WTRU can determine its active behavior based on whether the SCI reserves (or does not reserve) future resources. Specifically, the WTRU can have a first active behavior when the SCI indicates forward reservations and a second active behavior when the SCI does not indicate forward reservations. This can allow the WTRU to remain in an active state when periodic transmissions are expected, while allowing DRX when periodic transmissions are not expected. For example, the WTRU can start an inactivity timer (or as described elsewhere herein) upon receiving any of the following events (or combination of events) related to reception:

[0506] - Receiving SCI. The WTRU can only start the inactivity timer upon receiving SCI that does not reserve future resources. Receiving SCI that makes future reservations can reset such timer and / or can not start the timer.

[0507] - The WTRU can also start such inactivity timer only upon receiving SCI without reservation.

[0508] - The WTRU can also start such inactivity timer only upon transmitting HARQ feedback (e.g., ACK, NACK) associated with SCI / data transmission with HARQ feedback enabled.

[0509] - Receiving a CSI feedback request. Specifically, the WTRU can change from the first active state to the second active state (e.g., from monitoring the pool associated with the inactive state to monitoring the pool associated with the active state) upon receiving a CSI feedback request. The WTRU can also reset the inactivity timer upon such reception.

[0510] - The WTRU can start such inactivity timer only upon transmitting CSI feedback after receiving a CSI request.

[0511] The WTRU can enter DRX upon expiration of such inactivity timer if the WTRU has not received any additional transmissions (SCI) intended for it prior to the expiration of the timer. For example, the WTRU can start such timer if the WTRU has received SCI that does not reserve future resources (for retransmission or new transmission) and the WTRU has no future transmissions to process and the WTRU has no HARQ feedback transmission to make. On the other hand, the WTRU can start such timer upon transmitting ACK to SCI reception with HARQ feedback enabled if the WTRU has no future reserved resources to process / expect associated with reception from any sidelink process. On the other hand, the WTRU can start such timer upon transmitting CSI feedback if the WTRU has no future reserved resources to process / expect associated with reception from any sidelink process and has no HARQ feedback to send and has no expected retransmission from any sidelink reception process (i.e., the sidelink reception process has been acknowledged or has reached the maximum number of retransmissions, and / or the WTRU has flushed its RX HARQ buffer associated with each sidelink process).

[0512] Reception activity of the WTRU based on the amount of received transmissions.

[0513] In one solution, the WTRU can determine its active behavior based on the amount of transmissions received at the WTRU (possibly over a preconfigured or predetermined time period). Specifically, if the number of sidelink transmissions received by the WTRU over a time period is greater than a threshold, the WTRU can perform any of the actions described herein related to active behavior (e.g., reset the inactivity timer, transition from DRX-based monitoring to active monitoring, change from monitoring a first pool to a second pool, etc.). The measured number of transmissions can also be limited to those associated with a particular type (e.g., asynchronous, periodic), a particular cast (unicast, groupcast, or broadcast), or having a particular attribute related to HARQ (e.g., enable / disable HARQ).

[0514] In one example solution, the WTRU can be configured to monitor on the first pool as long as the number of transmissions received on the first pool over a configured time period is below a threshold. When the number of transmissions over the last configured time period exceeds the threshold, the WTRU can start monitoring the second pool. The WTRU can continue monitoring the second pool as long as a second condition is met. When the second condition is no longer met, the WTRU can transition from monitoring the second pool to monitoring the first pool. Such a second condition can be any one or a combination of the following:

[0515] - expiration of a timer.

[0516] a. The WTRU can monitor the second pool for a period of time after changing to the second pool.

[0517] - a condition related to activity on the first pool and / or the second pool.

[0518] a. The WTRU can monitor the second pool as long as the number of transmissions received on the first pool and / or the second pool received over a configured timer period remains above a threshold.

[0519] Active behavior at the WTRU determined based on an active-inactive command received from another WTRU.

[0520] In one scenario, a RX WTRU can change from one active behavior to another active behavior based on receiving an inactivity command from another WTRU. For example, such a command can be in the form of a SL MAC CE or an SCI including such a command. Specifically, the RX WTRU can be configured with a first resource pool and a second set of resource pools. Both the first resource pool and the second resource pool can be used to receive PSCCH and physical sidelink shared channel (PSSCH) associated with the same L2 ID. The WTRU can activate monitoring of the second resource pool only when it receives an SCI (i.e., in PSCCH) on the first resource pool, thereby minimizing energy consumption at the WTRU. In another example, to further minimize energy consumption, the first resource pool can be configured for narrowband reception of SCI only, while the second resource pool can be for wideband reception of both PSCCH and PSSCH. After activating the second resource pool, an active timer (i.e., on-duration timer and inactivity timer) can be started and maintained. Before the active timer expires, if the WTRU receives an inactivity command (e.g., SL MAC CE) indicating termination of activity (e.g., due to transmission of last data), the RX WTRU can stop the corresponding active timer and deactivate monitoring of the indicated resource pool. The inactivity command can indicate the following:

[0521] - Resource pool to stop monitoring: The inactivity command can indicate termination of activity on at least one resource pool.

[0522] - Resource pool to switch monitoring to: The inactivity command can indicate change from one second (active) resource pool to another second (active) resource pool.

[0523] - Timing associated with change of monitoring behavior:

[0524] a. For example, the inactivity command can also indicate a DRX duration, as long as the DRX duration is ongoing, the RX WTRU can apply the DRX duration to deactivate monitoring of the resource pool. The RX WTRU can reactivate the resource pool and the associated active timer after the indicated DRX duration expires.

[0525] b. For example, the inactivity command can indicate a delay (time) until the WTRU should change its active behavior (e.g., switch to inactivity time of DRX configuration, or switch to monitor an inactivity pool)

[0526] - Specific decoding parameters associated with change of active behavior, where such decoding parameters can be L1 / L2 ID, L1 / L2 priority, or any other aspect specific to decoding PSCCH.

[0527] A. For example, an inactivity command can stop active monitoring associated with only the L2 ID provided in the inactivity command (e.g., on the active pool).

[0528] If an RX WTRU is configured to receive from multiple TX WTRUs and receives multiple inactivity commands indicating termination of at least one active resource pool common to multiple TX WTRUs, the RX WTRU can use other criteria (e.g., priority) to determine whether to deactivate the indicated resource pool and transition to DRX. Alternatively, the RX WTRU can transition to DRX as long as all TX WTRUs have indicated termination of activity on the common resource pool.

[0529] Activity behavior at a WTRU determined based on an inactivity command received implicitly from another WTRU.

[0530] In one scenario, an RX WTRU can change from one activity behavior to another based on an inactivity command received implicitly from another WTRU. For example, such a command can be in the form of the presence of padding bits in a MAC PDU. Specifically, when detecting the presence of one or more padding bits after the data bits in a received MAC PDU, the RX WTRU can perform the following operations:

[0531] - stop active timers (e.g., on-duration timer, inactivity timer) in at least one of the configured resource pools and transition to DRX.

[0532] - If (pre-)configured with a DRX timer, the RX WTRU can use the detection of an inactivity command to start the DRX timer and remain in DRX as long as the DRX timer is running. After the DRX timer expires, the RX WTRU can activate and start monitoring in the configured resource pools.

[0533] - If (pre-)configured with a resource pool to be deactivated, the RX WTRU can use the detection of an inactivity command to deactivate monitoring in the pre-configured resource pool.

[0534] WTRU reception of physical sidelink feedback channel (PSFCH) is handled independently of RX activity behavior

[0535] In one embodiment, a WTRU can perform reception of PSFCH based on its scheduled timing without impacting the active behavior of the reception. Specifically, a WTRU already in DRX can wake up to perform only PSFCH reception at the scheduled time (determined by the timing of its own transmission) and can continue DRX after such reception. Furthermore, the reception of PSFCH can not increase and / or reset any timers associated with the reception-based active time. The WTRU can simply perform reception of PSFCH in such symbols. In the above exemplary application, a WTRU in SL-DRX performs PSFCH reception only on the SL associated with the time slot in which the HARQ feedback reception (with respect to the transmission) is expected.

[0536] Alternatively, a WTRU can also perform PSCCH and / or physical sidelink shared channel (PSSCH) reception / decoding on the time slot in which the WTRU expects to receive PSFCH (or a specific number of time slots before / after in which the WTRU expects to receive PSFCH), even if the WTRU is currently in DRX for that specific time slot. The WTRU, upon receiving SCI scheduling it during such time slot, can perform similar behavior as receiving SCI during normal on-duration. During such time slot, the WTRU can transition to active state upon receiving SCI. Specifically, the WTRU can start inactivity timer upon receiving SCI during such time slot and / or start active monitoring of PSCCH, and / or start active monitoring of active resource pool.

[0537] Active behavior at WTRU after transmitting PSFCH.

[0538] In one solution, the RX WTRU can further increase power saving by transitioning to DRX after transmitting the PSFCH. Specifically, the RX WTRU can be configured with a first resource pool and a second set of resource pools. Both the first resource pool and the second resource pool can be used to receive PSCCH and PSSCH associated with the same L2 ID. The second resource pool is activated to improve power efficiency only when SCI is received in the first resource pool. For a given HARQ process, the WTRU can transmit the PSFCH to the TX WTRU and start the SL RTT HARQ timer. The WTRU can then transition to DRX by deactivating the first resource pool and the second resource pool or by deactivating only the second resource pool. The WTRU can further transition to DRX as long as the SL RTT HARQ timer for each HARQ process is running. Upon expiry of the SL RTT HARQ timer, the WTRU can reactivate the corresponding resource pool and start an active timer (i.e., on duration timer, inactivity timer) for subsequent reception of PSCCH and PSSCH. The duration of the SL RTT HARQ timer can be determined by a combination of factors including QoS or L2 ID attributed to the HARQ process.

[0539] The WTRU ignores certain sidelink transmissions when determining / updating its active behavior.

[0540] In one solution, the WTRU can ignore certain “special” transmissions in determining / updating its active behavior. Specifically, the WTRU can determine the active behavior based on the reception of sidelink transmissions using the methods described herein. However, the WTRU can ignore certain “special” transmissions in such determination. For example, certain “special” transmissions can cause the WTRU not to reset the active timer. For example, certain “special” transmissions can not be used to calculate the transmission density for determining the active behavior. For example, certain “special” transmissions can not be part of the rules for determining changes in the reception resource pool and / or resetting the timer (e.g., inactivity timer).

[0541] The WTRU can ignore any of the following when determining / updating its active behavior:

[0542] - CSI feedback reception.

[0543] a. This can be conditioned on receiving CSI feedback only. For example, the WTRU can ignore the reception of CSI feedback from a peer WTRU if such data transmission is not multiplexed with other data transmissions.

[0544] - PC5 Radio Resource Control (RRC) message.

[0545] a. This can depend on the content / type of the PC5-RRC message. For example, the WTRU can ignore any PC5-RRC message (possibly it is also not multiplexed with data) whereby the message is only for configuration change (e.g., not for establishing a unicast link).

[0546] - the transmission where the WTRU is outside the minimum communication range (MCR) associated with the transmission.

[0547] a. For example, the WTRU can ignore any groupcast transmission received whereby the WTRU is outside the minimum communication range (MCR) sent in the SCI for the transmission.

[0548] - the priority is lower than a threshold.

[0549] a. For example, the WTRU can be configured with a priority threshold and can ignore any transmission received with a priority lower (lower priority) than the threshold.

[0550] - a discovery message or similar message for relay discovery / selection.

[0551] a. For example, the WTRU can ignore the reception of discovery messages containing (possibly only) discovery messages intended for relay discovery / selection.

[0552] - HARQ feedback.

[0553] a. For example, the WTRU can ignore the reception of any HARQ feedback (ACK / NACK) or specific HARQ feedback (e.g., only ACK) when determining whether to reset the inactivity timer with respect to receiving a transmission from a peer WTRU.

[0554] The WTRU counts PSFCH reception (possibly containing only ACK or NACK) as an active event.

[0555] In another embodiment, the WTRU can consider a PSFCH reception as a reception event that determines its active behavior (e.g., it can reset the inactivity timer). The WTRU can also associate the type of feedback received (e.g., ACK or NACK) with the reception event, while other types of feedback can not be associated with an active event. For example, the WTRU can reset the inactivity timer and / or remain in active channel monitoring upon receiving an SCI intended for it (e.g., with a specific L1 / L2 ID of interest) or receiving a PSFCH containing a NACK. Receiving a PSFCH containing an ACK can not cause the inactivity timer to be reset. Upon expiration of such timer, the WTRU can perform DRX.

[0556] The WTRU performs active monitoring (non-DRX) after a CSI feedback request.

[0557] In one embodiment, the WTRU can disable DRX (e.g., perform normal active monitoring on PSCCH or change the reception pool) after transmitting the CSI request to the peer WTRU. Specifically, the WTRU can have any of the following behaviors after transmitting the CSI request to the peer WTRU:

[0558] - If the WTRU is currently in DRX, the WTRU can disable or move out of DRX.

[0559] - If the WTRU is currently in active monitoring state, the WTRU can reset any timers (e.g., inactivity timer) associated with transitioning to DRX.

[0560] - If the WTRU is currently in active monitoring state, the WTRU can extend any timers (e.g., inactivity timer) associated with transitioning to DRX by an amount related to the CSI feedback window.

[0561] - The WTRU can remain in active monitoring state until CSI feedback is received.

[0562] - The WTRU can remain in active monitoring state until the CSI feedback window associated with the CSI request expires. Then, if the WTRU is allowed, the WTRU can move to DRX based on possible other rules described herein.

[0563] - If the WTRU is in active monitoring state, the WTRU can determine the time it can move to DRX based on the time when the last of the following events occurs: 1) the running inactivity timer expires; 2) the WTRU receives CSI feedback before the CSI feedback window expires; 3) the CSI feedback window expires without receiving CSI feedback.

[0564] Exemplary embodiments

[0565] WTRU determines / changing HARQ RTT timer behavior based on sidelink characteristics

[0566] The WTRU can perform different handling of HARQ RTT based on sidelink characteristics such as the following or any other sidelink characteristics mentioned herein that can impact active behavior:

[0567] - Whether HARQ is enabled / disabled for transmission.

[0568] - Whether the grant is a configured grant.

[0569] - Whether the transmission reserves retransmission resources and how many retransmission resources are reserved.

[0570] - Time between transmission and retransmission resources.

[0571] - Whether PUCCH is configured for resource pool.

[0572] - Whether the process (on which HARQ RTT is considered) is for unicast, groupcast or broadcast.

[0573] - Whether mode 1 or mode 2 is used for transmission.

[0574] - Priority / QoS of the transmission (may be related to LCH ID or priority of LCH).

[0575] - Measured CBR.

[0576] - Whether pre-emption is configured / allowed.

[0577] Depending on the above cases, any of the following behaviors can be changed:

[0578] - When the HARQ RTT timer is started.

[0579] - Value of the HARQ RTT timer to be used.

[0580] - Whether HARQ RTT is used (i.e., whether the WTRU can go to sleep after transmitting NACK).

[0581] Start time:

[0582] For example, the WTRU can start the HARQ RTT timer at different time instances depending on whether HARQ is enabled / disabled in the transmission. If HARQ is enabled, the WTRU starts the HARQ RTT upon transmitting the PSFCH. If HARQ is disabled, the WTRU can start the HARQ RTT:

[0583] - Upon receiving data that the WTRU determines is not properly decoded.

[0584] - Some (pre-)configured time after receiving such data.

[0585] a. Depending on the priority of the data in the transmission

[0586] b. Can depend on the measured CBR.

[0587] Duration:

[0588] For example, the WTRU can determine the value of the HARQ RTT timer depending on the above characteristics. Specifically, depending on these characteristics, the WTRU can be configured with different HARQ RTT timer values. Specifically, the WTRU can extend / reduce the HARQ RTT value by an amount depending on the characteristic. Specifically, the WTRU can stop the HARQ RTT timer before an event related to one of the above cases.

[0589] For example, if the WTRU receives a mode 1 transmission, it can use a first value of HARQ RTT, and if it receives a mode 2 transmission, it can use a second value of HARQ RTT. For example, if the resource pool is configured with PUCCH, it can use a first value of HARQ RTT. If the resource pool is not configured with PUCCH, it can use a second value of HARQ RTT. For example, if the WTRU receives a retransmission resource, it can set the HARQ RTT to the time until the retransmission resource, otherwise it can set the HARQ RTT to a (pre-)configured value. For example, the WTRU can receive different HARQ RTT times for different values of transmission priority (possibly in the above examples).

[0590] Whether to use HARQ RTT (i.e., whether to allow going to sleep after an error reception of a transmission):

[0591] For example, the WTRU can be allowed to use HARQ RTT if pre-emption is not configured / allowed. For example, the WTRU can be allowed to use HARQ RTT if the priority of the transmission is above / below a threshold. For example, the WTRU can be allowed to use HARQ RTT if the CBR is below a threshold.

[0592] Determining reception activity as a function of the WTRU’s own transmission

[0593] (Power saving behavior at the WTRU can be determined by the WTRU’s own transmission)

[0594] SL activity behavior can be a function of the WTRU’s own data transmission.

[0595] In one embodiment, the WTRU can determine and / or change its activity behavior based on the timing and / or nature of its own transmission, which can include the mode or timing of any sidelink data arriving at the WTRU or scheduled by the WTRU for autonomous transmission. For example, the WTRU can determine the mode of sidelink control channel monitoring, the value of timers related to DRX, or extend / change some time of timers related to DRX based on the timing and / or attributes related to its own transmission, such as any one or a combination of the following:

[0596] - the resources selected for its own transmission.

[0597] - the frequency of its own transmission (or time between transmissions).

[0598] - whether the WTRU has a transmission to make, and any characteristics related to such transmission, such as:

[0599] a. periodicity.

[0600] b. QoS.

[0601] c. Amount of data to be transmitted (size of transmission).

[0602] d. Number of (re)transmissions to be made.

[0603] - Time at which its own transmission occurs, possibly relative to the monitoring time.

[0604] - Frequency of WTRU feedback transmission (e.g., PSFCH transmission) or time associated therewith.

[0605] - Any properties associated with the feedback transmission (e.g., CSI feedback window).

[0606] In another solution, a WTRU can determine and / or change its active behavior based on conditions indicating the use of multiple configured resource pools. Specifically, a WTRU can be configured with a first resource pool and a second resource pool, where the second resource pool is used to support the WTRU’s active behavior (e.g., transmission, listening) only when at least one of the conditions affecting the use of the first resource pool is met. The conditions that trigger the use of the second resource pool can be any one or a combination of the following:

[0607] - Insufficient resources in the first resource pool after performing logical channel prioritization (LCP) procedure to meet the QoS requirement for a subsequent transmission.

[0608] - Expiration of an activity timer for using the first resource pool.

[0609] - Reception of a trigger (e.g., PFSCH, upper layer indication) in the first resource pool.

[0610] (A). SL active behavior can be determined by the transmissions pending at the WTRU.

[0611] In a series of solutions, a WTRU can define its SL active behavior based on the presence of pending data to be transmitted by the WTRU. Specifically, one or more factors affecting the SL active behavior can be determined by any one or a combination of the following:

[0612] - Presence or absence of data in the WTRU buffer.

[0613] - Action of transmitting data on the sidelink, in particular for mode 2 WTRU.

[0614] - QoS and / or LCH associated with the data in the WTRU buffer or the data recently transmitted by the WTRU.

[0615] - Transmission and / or reception of SL Radio Link Control (RLC) or Packet Data Convergence Protocol (PDCP) status reports.

[0616] - Transmission and / or reception of SL HARQ feedback, and / or type of HARQ feedback (ACK / NACK / DTX).

[0617] - Pending CSI feedback to be provided by the WTRU and its properties (e.g., CSI feedback window).

[0618] - Periodicity of data to be transmitted or SL TX HARQ process created per data process.

[0619] - Exchange of control signaling associated with connection control, L2 ID update, SL unicast reconfiguration, or SL unicast capability signaling.

[0620] - Number of configured blind retransmissions or HARQ-based retransmissions.

[0621] In one example, a WTRU can consider itself active during a sidelink transmission and / or reception of feedback (e.g., HARQ feedback) associated with such transmission. The WTRU can also remain active for a period of time (e.g., defined by a timer) after transmission / retransmission of some data and / or reception of feedback. Such transmission / retransmission can also be constrained to the last transmission / retransmission of any data in the WTRU’s SL TX buffer that can be associated with a particular logical channel. Specifically, the WTRU can start a timer upon transmission / retransmission of any data or the last data in the WTRU’s buffer and remain active (i.e., decode SL Physical Sidelink Control Channel (PSCCH)) while the timer is running. If the WTRU does not receive any new data for transmission before the timer expires, the WTRU can enter DRX. Alternatively, the WTRU can restart such timer upon transmission of new data and / or reception of data from a peer WTRU. The WTRU can be configured with such timers for transmission events and reception events that can be different. In another example, the WTRU can start a timer upon reception of an ACK associated with the transmission / retransmission of the last data in the WTRU’s buffer and remain active while the timer is running. In such example, the timer can be determined based on any one or a combination of the following:

[0622] - Measured Channel Busy Ratio (CBR) of the transmission resource pool.

[0623] - QoS and / or logical channel (LCH) associated with the last data transmission or number of recent data transmissions.

[0624] - Can be configured per L2 ID.

[0625] - Can be statically configured by upper layers.

[0626] In another example, the WTRU can start a timer upon removing the last periodic SL process associated with a transmission and move to DRX upon expiry of the timer. The timer can be based on aspects mentioned in previous examples. Additionally, the timer can be determined from the periodicity of the last removed sidelink process or the most recent removed multiple sidelink processes.

[0627] In another example, the WTRU can consider itself active during the period of a sidelink transmission. After the last transmission (no data in the buffer), the WTRU can initiate a transmission of an RLC / PDCP request and can move to DRX (inactive) upon receiving such status report.

[0628] In another example, as a result of a request from upper layers (e.g., L2 address change request from upper layers, reconfiguration request of unicast link configuration, etc.), the WTRU can initiate a control signal exchange (e.g., PC5 RRC) with a peer WTRU. The WTRU can be active after the transmission of an initial PC5-RRC message (e.g., SL reconfiguration message) until receiving a response message (e.g., SL reconfiguration response message).

[0629] (B). SL active behavior for reception can change depending on the presence of SL transmissions

[0630] (Destination: Due to half duplex, a WTRU performing SL DRX based on SCI reception can miss certain transmissions from a peer WTRU, unaware of the presence of activity).

[0631] In one embodiment, the SL active behavior for reception can also depend on the occurrence of transmissions by the WTRU or other WTRUs. Specifically, the WTRU can change or define any aspect associated with the SL active behavior for reception (e.g., DRX based on SCI reception) based on any one or a combination of the following properties of its transmissions or transmissions by other WTRUs:

[0632] - One or more transmissions occur at the WTRU, possibly at a certain time relative to the active time based on reception (e.g., during the on duration based on reception).

[0633] - The amount or frequency of such transmissions.

[0634] - The time / frequency of such transmissions.

[0635] - Congestion on the resource pool (e.g., CBR or similar).

[0636] - Attributes of the sensing results associated with the resource pool (e.g., number / percentage of available resources).

[0637] - Number of expected retransmissions from the peer WTRU.

[0638] - Expected QoS of transmissions from the peer WTRU and / or SLRBs configured at the WTRU or at the peer WTRU.

[0639] a. This can vary with the services active at the WTRU in question.

[0640] b. Such can be determined by the SLRB configurations exchanged during unicast link setup.

[0641] In one example, a WTRU performing SCI-based DRX and configured with a particular on-duration and / or inactivity timer (determined using any of the methods described herein) can increase its on-duration and / or inactivity timer by a (pre-configured) amount for each data transmission during its active time based on the reception. Alternatively, the WTRU can be configured with a set of on-durations and / or inactivity timers. The WTRU can select the appropriate on-duration and / or inactivity timer to use for each of the following:

[0642] - Number of transmissions it reserves during the active time.

[0643] - Transmission density (e.g., CR) it makes during the active time.

[0644] - Number of sidelink processes it is active (has data to transmit) during the active time.

[0645] - Buffer status during the active time.

[0646] - Similar measurements of sidelink transmissions or sidelink resource usage.

[0647] In another example, a WTRU performing reception-based DRX or similar can be configured with active behavior (e.g., timers related to SCI-based DRX) that depends on the congestion (e.g., CBR) of the resource pool. For example, the WTRU can be configured to use a first timer or a first set of timers (e.g., on-duration timer, inactivity timer, etc.) for a first CBR or a first CBR range, and can use a second timer or a second set of timers for a second CBR or a second CBR range. The WTRU can be configured with a mapping of CBR ranges to timers or active behavior.

[0648] In another example, a WTRU performing reception-based DRX or similar can be configured with active behavior (e.g., on-duration timer or active timer) that depends on the outcome of listening at the WTRU. Specifically, the WTRU can be configured with an on-duration, inactivity time, or other active behavior for each of the following values or value ranges:

[0649] - amount, percentage, or density of resources available within a time / frequency window (e.g., initially configured on-duration or inactivity timer period).

[0650] - amount, percentage, or density of resources where the received signal strength indicator (RSSI) is above / below a threshold.

[0651] For example, the WTRU can determine the percentage of resources available in the first configured on-duration. If this percentage of resources is below a threshold, the WTRU can increase the on-duration to a second value. Alternatively, the WTRU can select an on-duration such that the absolute amount of available resources is above a threshold.

[0652] (C). Resource selection can be performed to avoid on-duration

[0653] In another solution to the half-duplex issue, a WTRU can perform resource selection for transmission to avoid or reduce potential conflict with its reception-based active time (e.g., on-duration). For example, the WTRU can perform resource selection for its own transmission by removing resources, active time, etc. associated with its own (RX-based) on-duration. For example, the WTRU can perform resource selection for its own transmission by selecting resources with lower priority associated with its (RX-based) on-duration.

[0654] If the WTRU needs to select resources for transmission during the active period, the WTRU can further extend its on-duration. Specifically, the WTRU can select resources for transmission during the active period to meet timing requirements of its data transmission. If resources are selected during the active period, the WTRU can extend the active period by a (pre-)configured amount. The amount can also depend on the amount of resources selected by the WTRU to drop during the active period or during the extended active period.

[0655] (D). WTRU combines independent transmission active behavior and reception active behavior to determine active time

[0656] A WTRU can be configured to perform only a transmitting active behavior (i.e., its active time can be affected by its own transmission on the sidelink), only a receiving active behavior (e.g., its active time can be affected by the reception of data on the sidelink), or both transmitting and receiving active behaviors. For example, a WTRU performing only a transmitting active behavior can be beneficial for a WTRU performing only transmission (i.e., no reception). For example, a WTRU performing only a receiving active behavior when in a DRX configuration will perform transmission when data arrives or an SL grant is received from the network, but can determine its active behavior after such transmission based on receiving SCI. For the time slots it is performing transmission, it can also perform reception (e.g., on a different carrier).

[0657] A WTRU configured to perform both a transmitting active behavior and a receiving active behavior can determine its active time according to a combination of a transmission-based rule / active behavior and a reception-based rule / active behavior, where each rule / active behavior can be as defined herein. For example, a WTRU can be configured with a DRX configuration that defines its rule for active time with respect to SCI reception. In addition, the WTRU can be configured with a set of active time rules based on its pending transmissions as defined herein. The WTRU can determine its active time for PSCCH decoding according to an “or” operation between the RX-based DRX active time and the transmission-based active time. In other words, the WTRU is active if it needs to be active for the DRX defined for reception or needs to be active based on the rules related to pending transmissions. Alternatively, the WTRU can be in DRX if it is determined to be “in DRX for transmission-based activity” and “determined to be in DRX for reception-based activity.”

[0658] (E). WTRU treats transmission and reception events as equivalent events in active behavior determination

[0659] In another example, the WTRU can consider any transmission event (e.g., transmission of HARQ feedback, transmission of data, or transmission of CSI feedback) as an activity event (in conjunction with a reception event) to control a single set of inactivity timers related to active behavior. Specifically, the WTRU can start an inactivity timer. Such timer can be reset by any event associated with either reception (e.g., reception of SCI) or transmission (e.g., transmission of data). The WTRU can set the timer value (e.g., the timer value after the WTRU moves to DRX) to be the same regardless of the event. Alternatively, the WTRU can set the timer value based on the event itself (e.g., a transmission event can have a different value compared to a reception event). The WTRU can also set different timers depending on the transmission or reception event itself (e.g., transmission of data causes the timer to be set to T1 while transmission of HARQ feedback causes the timer to be set to T2).

[0660] When considering transmission events in active behavior evaluation, the following events (and exact timing of these events) can be considered (same or different treatment as discussed above):

[0661] - Transmission and / or retransmission of CSI and / or TB (in either mode 1 or mode 2).

[0662] - Reception by the WTRU of SL DCI scheduling a mode 1 sidelink transmission.

[0663] - Transmission of any or specific HARQ feedback (i.e., ACK, NACK, and / or DTX - due to not meeting MCR requirements).

[0664] - Transmission of CSI feedback.

[0665] - Transmission of CSI request from a peer WTRU.

[0666] (F). The WTRU can perform DRX based on the expiration of the delay associated with the transmission / reception.

[0667] In one embodiment, the WTRU can determine whether it can perform DRX based on a number of conditions being met, whereby one such condition is the expiration of the delay (time requirement) associated with the initial transmission received / transmitted by the WTRU for one of its SL HARQ processes. For example, the RX WTRU can receive in the SCI an initial transmission with a priority / delay parameter.

[0668] If the initial transmission is not decoded correctly and the delay indicated in the SCI has expired (relative to the timing of the initial transmission), the RX WTRU can move to DRX when all other possible conditions for DRX as described herein are met. Alternatively, the delay indicated in the SCI relative to a (pre-configured) offset from the timing of the initial transmission can also be considered to determine when the WTRU can move to DRX.

[0669] Similarly, if a NACK is received from the initial transmission and the delay associated with the packet in the initial transmission has expired (relative to the timing of the initial transmission), the TX WTRU can move to DRX when all other possible conditions for DRX as described herein are met. Alternatively, the delay associated with the packet in the initial transmission relative to a (pre-configured) offset from the timing of the initial transmission can also be considered to determine when the TX WTRU can move to DRX.

[0670] (G). WTRU can perform DRX between data transmission / reception and associated PSFCH resources

[0671] In one solution, a WTRU can perform DRX between its data transmission and the associated PSFCH resources associated with that transmission. Specifically, a TX WTRU can perform a transmission on the sidelink and can perform DRX in the time slots between the transmission and the associated PSFCH resources for feedback if other conditions related to DRX are met (determined by configuration / computation).

[0672] Similarly, a RX WTRU can perform DRX between receiving a transmission indicating that feedback is needed and the corresponding PSFCH resource where the RX WTRU performs the HARQ feedback transmission.

[0673] In another embodiment, if the MCR requirement for receiving data is not met and the RX WTRU is not required to transmit PSFCH, the WTRU can perform DRX during or after the PSFCH resources.

[0674] (H). WTRU can perform DRX between data transmission / reception and blind retransmission resources

[0675] In one embodiment, a WTRU can perform DRX between its data transmission and the blind retransmission of that data. Similarly, a RX WTRU can perform DRX between receiving a transmission from another WTRU and the scheduled blind retransmission.

[0676] TX WTRU behavior when communicating with a WTRU, the WTRU can be in active / inactive state

[0677] Destination: How a transmitting WTRU can ensure it can reach a given WTRU that is inactive [e.g., in a context similar to DRX at the RX WTRU].

[0678] Adjusting WTRU transmission based on known reception activity at a peer WTRU

[0679] A WTRU can dynamically adjust its transmission opportunities (time and / or frequency, resource pool, etc.), its transmission format (e.g., SCI type, number of sub-channels, sub-channel format, etc.), and possibly transmission parameters (e.g., Modulation and Coding Scheme (MCS), HARQ, etc.) based on known activity behavior and / or active time of a receiving WTRU that can be associated with the same group. Such adjustment of transmission opportunities can consist of any one or a combination of the following behaviors:

[0680] - A WTRU can buffer traffic intended for one or more WTRUs or groups (e.g., L2 ID) until a later instant associated with an active time.

[0681] - A WTRU can buffer CSI feedback transmission intended for another WTRU until a later instant.

[0682] - A WTRU can constrain the LCHs that can be multiplexed into a PDU transmitted at a given time and / or resource pool to a subset of LCHs (e.g., possibly associated with expected receivers known to be active).

[0683] - A WTRU can change or adjust its HARQ retransmission behavior (e.g., increase or decrease the number of retransmissions, change the coding associated with each HARQ transmission, enable / disable HARQ).

[0684] - Change or adjust its transmission parameters such as MCS, number of slots for a single TB transmission.

[0685] - Change or adjust the frequency / carrier / BWP on which the transmission is performed.

[0686] - Change or adjust its resource selection decision, such as selecting time / frequency resources that satisfy certain criteria that can be adapted to the activity behavior of the receiving WTRU.

[0687] - Choose between periodic or asynchronous transmission.

[0688] - Change the type or format of SCI transmission (e.g., transmit to a WTRU using a one-stage SCI instead of a 2-stage SCI).

[0689] - Change the sub-channel format used for transmission.

[0690] - change / adjust or decide whether to request feedback (e.g., CSI feedback) from a peer WTRU based on the activity behavior of the peer WTRU.

[0691] (A). WTRU transmits on resources associated with RX WTRU activity behavior based on certain conditions

[0692] In one embodiment, a WTRU can restrict its SL data transmission, possibly associated with a specific peer WTRU, WTRU or L2 ID group, such that its SL data transmission is limited to time / frequency resources associated with sidelink activity at the peer WTRU. Such resources can represent time / frequency resources in which the peer WTRU, possibly associated with an L2 destination ID, is guaranteed to monitor PSCCH (i.e., at active times). These active resources can consist of a set of slots within the DRX cycle of the peer WTRU, corresponding to the ON duration of the peer WTRU or WTRU group, possibly associated with an L2 ID, possibly associated with a cast type, possibly associated with other factors capable of changing the activity behavior of the RX WTRU as described herein. Alternatively, these active resources can be a set of time / frequency / beam resources (which can or can not be contiguous) within a resource pool for which the WTRU, possibly associated with an L2 ID, cast type, etc., is guaranteed to monitor the sidelink control channel. Alternatively, the guaranteed active resources can consist of a first resource pool, while the WTRU can monitor a second resource pool only under certain conditions (e.g., inactivity or similar timers running). In the above exemplary application, the transmitting (TX) WTRU can change the destination IDs allowed to be transmitted according to the grant associated with the resource pool based on an inactivity timer associated with the last transmission on that resource pool.

[0693] The TX WTRU can determine the set of such resources:

[0694] - by (pre-)configuration.

[0695] a. For example, the WTRU can be (pre-)configured with (e.g., in a system information block (SIB) or dedicated signaling) a set of time / frequency resources for which the intended receiver is considered active (e.g., similar to the SL DRX configuration described herein).

[0696] b. For example, such resources can be indicated as part of a TX pool configuration.

[0697] c. For example, such resources can also be specific to:

[0698] (i) Destination L2 ID - i.e. each destination L2 ID can be configured with a set of active resources, when configured in DRX, the WTRU interested in the L2 ID must monitor these resources.

[0699] (ii) Unicast link or intended peer WTRU.

[0700] (iii) WTRU group.

[0701] - Obtained from a peer WTRU.

[0702] a. For example, a WTRU can receive the active resources of a peer WTRU from one or the other WTRU. For example, a WTRU in a unicast link can send its own and / or the DRX configuration or active resource pattern of the peer WTRU to the peer WTRU during the unicast link establishment or during a PC5-RRC signaling exchange after the unicast link establishment.

[0703] b. For example, a WTRU can periodically broadcast its active resources, such as:

[0704] (i) In a PC5-RRC message to the L2 ID it applies to, or to a special L2 ID.

[0705] (ii) In SCI, where the SCI can contain an index to a predefined or (pre-)configured set of active resources, and where the L1 ID can be a special L1 ID, or the L1 ID the active resources apply to.

[0706] (iii) In a SL MAC CE, where the addressing and indexing can be similar to the examples above.

[0707] A WTRU can also restrict its SL transmissions to a subset of resources only, based on any of the following conditions / behaviors:

[0708] 1. Time related conditions

[0709] - Based on a timer or an amount of time related to a previous transmission performed by the WTRU. For example, if the last transmission to the same destination occurred at least an amount of time in the past, the WTRU can restrict its transmissions to a subset of resources only (corresponding to the monitoring resources for inactive RX WTRUs). For example, the WTRU can start / restart a timer associated with transmissions to a particular destination after a transmission to that destination. As long as this timer is running, the WTRU can perform transmissions to that destination without any restrictions on time frequency resources. After the timer expires, the WTRU can perform transmissions to that destination only on the active resource set for that destination.

[0710] - based on a timer or an amount of time related to a previous transmission performed by another WTRU (which can also include the intended destination WTRU in the case of unicast), whereby such transmission can indicate that the intended destination can receive the transmission outside of the active resources.

[0711] a. Similar or in conjunction with the previous solution, the timer can be reset upon reception of a transmission from another WTRU to the same destination (e.g., same L2 ID). Such reset of the timer can also depend on the properties of the received transmission, which can reflect the likelihood of receiving such a message, such as:

[0712] (i) a configured MCR.

[0713] (ii) a configured number of retransmissions;

[0714] (iii) whether HARQ feedback is configured with the transmission.

[0715] (iv) the received power (e.g., RSRP) of the transmission (e.g., PSCCH, PSSCH, RS, etc.).

[0716] b. Also, a WTRU in a unicast link with a peer WTRU can perform a transmission to the peer WTRU outside of the active resources for a certain period of time (timer) after reception of a transmission from the peer WTRU. Such timer can be independent of the timer associated with its own transmission or a transmission from another WTRU.

[0717] c. Also, an intended destination WTRU can provide a list of L2 destinations it is interested in (which it is actively decoding data for). The TX WTRU can then transmit on resources outside of the active resources for the destination after the TX WTRU receives data addressed to one of these interested destinations (based on a timer behavior similar to the first two examples).

[0718] d. Also, when such transmission coincides with the timing of the HARQ feedback resources used by the first WTRU, the first WTRU can perform a data transmission to the second WTRU to send HARQ feedback for the transmission of the second WTRU. Specifically, the first WTRU can determine the timing of the HARQ feedback (PSFCH) to be transmitted to the second WTRU after the transmission of the second WTRU. The first WTRU can determine that such slot containing the PSFCH (or multiple slots before / after the PSFCH resource) is allowed and / or part of the constrained set of active resources that can be used to transmit to the second WTRU when the second WTRU is in DRX.

[0719] 2. Conditions related to quality

[0720] - based on QoS requirements / aspect of the data to be transmitted.

[0721] a. For example, a WTRU can be configured to only transmit data with certain QoS requirements on active resources. For example, a WTRU can be configured with a SLRB or LCH configuration that is associated with whether or not the WTRU should transmit data on active resources or whether the WTRU can transmit data from that LCH on other resources (as long as other conditions discussed as part of this solution (e.g., timers) are also met).

[0722] b. A WTRU can be further configured with logical channel prioritization (LCP) constraints such that it cannot multiplex data / LCHs that are allowed to be transmitted outside of active resources and data / LCHs that need to be transmitted on active resources.

[0723] c. Such LCP constraints can further apply as long as the TX WTRU has not received an indication from the RX WTRU that it has started its inactivity timer. For example, such LCP constraints can apply until the TX WTRU has received an indication (e.g., HARQ feedback, CQI request / report, RRC message, MAC CE, etc.) from the peer WTRU that can indicate that the RX WTRU is no longer in DRX or is monitoring resources outside of its normal DRX active period (e.g., inactivity timer is running).

[0724] - based on presence / absence of feedback received from one or more peer WTRUs.

[0725] a. For example, a WTRU can perform transmission on active resources after one or more transmissions to a destination such that the WTRU has not received HARQ feedback.

[0726] 3. Conditions related to the type of broadcast

[0727] A WTRU can determine its available resources for transmission, or the transmission resources that will allow it to reach a peer WTRU, based on the type of cast of the transmission in question. Specifically, a WTRU can assume that a first set of resources can be used to reach WTRUs for broadcast / groupcast transmissions, while a second set of resources can be used to reach WTRUs for unicast, groupcast. Based on the differences in DRX mechanisms applicable to the type of cast further described herein, a WTRU can also determine resources that are different from the resources used for broadcast / groupcast transmissions, in which a unicast WTRU can reach. For example, a WTRU can use a separate pool of resources for some (e.g., possibly the first transmission in a set of transmissions, possibly a transmission with higher QoS) or all transmissions. For example, a WTRU can use a dedicated set of “active” resources in a pool of resources for broadcast / groupcast transmissions, where such set of resources can be statically allocated in the pool of resources. Alternatively, a WTRU can transmit to a unicast peer WTRU according to a resource pattern, which can be dynamically changed based on the WTRU’s own transmission pattern / activity. Specifically, a WTRU can transmit to a unicast peer WTRU in a resource that can be outside of the “active” resources for unicast (or broadcast / groupcast), but in which an inactivity timer (as described herein) associated with the particular peer WTRU is running.

[0728] (B). When the condition is met, the WTRU adjusts its resource selection and / or logical channel priority (LCP)

[0729] When a WTRU constrains its transmissions to active resources, the WTRU can perform resource selection and TB transmission / LCP due to these active resources. Specifically:

[0730] - The WTRU can exclude or lower the priority of resources that do not belong to the active resources for the destination when transmitting to the destination, possibly only when one of the above conditions is met.

[0731] - The WTRU can determine its all transmission and retransmission resources (e.g., for blind retransmission) such that they all fall within the active resources, possibly only when one of the above conditions is met. Alternatively, the WTRU can determine its transmission / retransmission resources such that the first x transmissions of the same TB fall within the active resources, possibly only when one of the above conditions is met.

[0732] a. For example, a WTRU can perform initial transmission within a first pool (guaranteed active resources) and select resources for retransmission in a second pool (non-guaranteed active resources). Alternatively, a WTRU can select resources for initial transmission and subsequent x retransmissions from a first pool, and select resources for the remaining retransmissions from a second pool.

[0733] - The WTRU can select multiple processes or resources such that the number x of resources possibly associated with different TBs occur within the guaranteed set of active resources or resource pool.

[0734] - Given a sidelink grant, the WTRU can select the associated destination L2 to transmit for that grant if the sidelink grant is associated with a resource that falls within the active resources for a specific destination L2 ID, otherwise the WTRU can not use the grant for that associated destination L2 ID. The WTRU can only perform such a constraint if one of the above conditions is met.

[0735] - The WTRU can select the periodicity of the sidelink process to match the periodicity of the active resources possibly associated with a specific destination. The WTRU can then apply a constraint to the selected destination such that the sidelink process is used for data transmission to the destination associated with the active resources. The WTRU can only perform such a periodicity selection and / or constraint if one of the above conditions is met.

[0736] (C). WTRU performs TB repetition or retransmission at different offsets associated with a destination

[0737] In one example embodiment, the WTRU can perform transmission of the same data in different resources, where each of these resources can be associated with a different possible configuration of the same destination. For example, a groupcast or broadcast L2 destination ID can be associated with DRX configurations with different slot offsets (e.g., configured differently depending on the gNB controlling the group members). The WTRU can be (pre)configured with the possible different configurations for the destination (e.g., based on dedicated signaling from the network, e.g., a system information block (SIB)). The WTRU can perform retransmission of a TB in each active resource associated with a different configuration. Specifically:

[0738] - In mode 2, the WTRU can select the transmission and retransmission resources such that each transmission / retransmission is associated with one of the different configurations received by the WTRU.

[0739] - In mode 1, the WTRU can receive a single sidelink grant (e.g., via DCI) that corresponds to sidelink physical resources occurring in each active resource (e.g., one transmission resource per configuration or offset). The WTRU can perform transmission of the same TB in each of the associated physical resources. Alternatively, the WTRU can receive a single grant in each active resource associated with a different configuration and can perform transmission of the same TB in each of these resources.

[0740] (D). WTRU improves reliability of transmission within active resources

[0741] Destination: In a timer-based condition, a subsequent transmission within the active resources can be missed if the RX WTRU experiences half duplexing.

[0742] In one embodiment, the WTRU can increase the reliability of transmissions occurring within the active resources to increase the probability of successful reception of the subsequent transmissions by the destination WTRU. This increase in reliability can apply (possibly only apply) to transmissions made in the active resources due to the WTRU's inability to transmit in the inactive resources (e.g., based on the expiration of the transmission timer described in this series of solutions). Specifically, the WTRU can perform transmissions with increased reliability when the inactivity timer at the TX WTRU (possibly associated with the L2 source / destination) is not running. Specifically, the WTRU can perform such transmissions only in the active resources associated with the L2 source / destination. The WTRU can perform any of the following to increase the reliability of such transmissions:

[0743] - Perform blind retransmission or HARQ-based retransmission within the active resources.

[0744] - Perform a larger number of retransmissions than required / configured.

[0745] a. Specifically, the WTRU can determine the number of retransmissions to the L2 source / destination ID based on whether the inactivity timer for the L2 ID is running.

[0746] - Transmit multiple TBs to be processed to the same destination within the active resources.

[0747] - Select a large number of resources for transmission (in resource selection) within the active resources.

[0748] a. Specifically, the WTRU can determine the number of resources in the active time (for transmission and / or retransmission) based on whether the inactivity timer for the L2 ID is running.

[0749] - Use a different MCS (e.g., a more conservative MCS) for transmissions within the active resources.

[0750] - Use a different MCR for transmissions.

[0751] a. Specifically, the WTRU can use the MCR configured from the upper layer when transmitting with the inactivity timer running, and can not use the MCR (or can use a different or larger MCR) when the inactivity timer is not running,

[0752] For example, a WTRU can be configured with a maximum number of retransmissions that can be performed for a transmission of a TB when the peer WTRU is assumed to be in an inactive state. For example, a WTRU can be configured with a maximum number of retransmissions when an activity timer at the TX WTRU corresponding to the RX WTRU is not running. Such maximum number of retransmissions can be different from the maximum number of retransmissions allowed when the peer WTRU is in an active state and / or when an inactivity timer at the TX WTRU corresponding to the RX WTRU is running. The WTRU can select the number of retransmissions according to the state of the inactivity timer.

[0753] For example, a WTRU can be configured to use a maximum number of retransmissions for transmissions to a peer WTRU in an inactivity state regardless of the CBR (e.g., the WTRU selects a maximum value for retransmissions regardless of the measured CBR). When the peer WTRU is assumed to be active (i.e., the inactivity timer is running), the WTRU can determine the maximum number of retransmissions based on the CBR.

[0754] For example, a WTRU performing resource selection for transmissions to an inactive WTRU (e.g., when the inactivity timer is not running) can be configured to perform blind retransmissions such that the resources selected for the blind retransmissions fall within the active time (e.g., on-duration or active resource pool) of the peer WTRU. When the peer WTRU is assumed to be active, the WTRU can select any resource for retransmission. Alternatively, when the peer WTRU is assumed to be inactive, the WTRU can select a subset of resources for transmission / retransmission to fall within the active time (e.g., on-duration or active resource pool) of the peer WTRU.

[0755] For example, a WTRU can be configured with different number / percentage of resources to select in the active resources / L2 ID of a peer WTRU depending on whether an inactivity timer is running for the peer WTRU and / or the value of the inactivity timer at the time of transmission / resource selection.

[0756] For example, a WTRU can be configured to initiate transmissions in inactive resources only after it has performed at least N transmissions in active resources. As described, the WTRU can further restrict transmissions in inactive resources when the inactivity timer of the peer WTRU is not running or has a value that satisfies some preconfigured condition. The WTRU can also determine such values based on other factors described herein, such as transmission QoS, CBR, etc.

[0757] (E). A WTRU prioritizes / restricts transmissions to a peer WTRU in grants that fall / exit the active time of the peer WTRU.

[0758] In one solution, if such grant is associated with an active time of a peer WTRU, the WTRU can prioritize transmissions to a particular peer WTRU when selecting data to transmit in the grant. Specifically, the TX WTRU can receive a grant (e.g., from the network in mode 1 or from a resource selection procedure in mode 2). When selecting an L2 Destination ID of data to be processed for transmission to be occupied by the grant, the TX WTRU can prioritize L2 Destination IDs associated with a peer WTRU where the grant is associated with (i.e., falls within) an active period of a DRX mode. For example, the TX WTRU can be communicating with two peer WTRUs in unicast, where the first peer WTRU is configured with DRX and the second peer WTRU is not configured with DRX. If the WTRU receives a grant that occurs within the active time of the first peer WTRU, the TX WTRU can prioritize / constrain transmission of data destined to the first peer WTRU in the grant. Conversely, the TX WTRU can prioritize / constrain data transmission to the second peer WTRU for grants that occur outside of the active period of the first peer WTRU. Specifically, when a grant does not fall within the active time of an L2 source / destination, and the L2 source / destination is configured with DRX, the TX WTRU can constrain selection of the L2 source / destination.

[0759] The TX WTRU can implement such prioritization / constraint based on any of the following:

[0760] - LCP constraints associated with the grant.

[0761] a. For example, a grant that occurs during an active time of a particular WTRU can not be allowed for transmission of data associated with another WTRU that:

[0762] (i) is not configured with DRX.

[0763] (ii) does not have the same or overlapping active time as the particular WTRU.

[0764] b. For example, a grant that occurs during an inactive time of a particular WTRU can not be used for transmission of data associated with the particular WTRU.

[0765] - a separate prioritization step in the LCP procedure.

[0766] a. For example, when determining a destination L2 ID to associate with a grant that occurs in an active time of one or more particular peer WTRUs, the TX WTRU can determine an L2 destination ID with the highest priority logical channel where data is available for transmission in all L2 destination IDs that have a DRX configuration and where the grant falls within the active time of the L2 destination ID.

[0767] b. If none of such L2 Destination IDs have data available, the TX WTRU can select another L2 Destination ID with data available based on legacy LCP (i.e., the L2 Destination ID with the highest LCH priority has data available for transmission).

[0768] c. For example, if two destinations have the same or similar priority, the WTRU can select the destination configured with DRX and the grant falls within the active time of that source / destination / WTRU.

[0769] - a bias applied to LCH priority in the LCP procedure.

[0770] a. For example, the priority associated with a L2 destination ID configured with DRX can be increased by a bias when the considered grant falls within the active time of that L2 destination ID. Specifically, when the highest priority LCH is considered for the grant during the LCP procedure to select a L2 destination ID, the WTRU can add a bias to the specific LCH priority.

[0771] In another related solution, the TX WTRU can further determine whether to perform the above prioritization for a specific grant based on a combination of one or more factors, such as:

[0772] - the priority of the data pending for transmission, possibly associated with L2 destination IDs of the WTRU configured with / without DRX and / or the grant falls within the active or inactive period.

[0773] a. For example, the WTRU can perform such prioritization / constraint if the priority associated with the peer WTRU associated with DRX is above a threshold.

[0774] - the DRX cycle value (i.e., periodicity of the active time) associated with the peer WTRU configured with DRX.

[0775] - the amount of data pending for transmission for the peer WTRU in DRX.

[0776] - the PDB (required transmission delay) of the data configured in DRX for the WTRU pending for transmission at the TX WTRU.

[0777] - the remaining PDB measured at the time of the grant (i.e., the remaining required delay for transmitting the data).

[0778] - the measured CBR.

[0779] In one example, the TX WTRU can apply the prioritization rules described above when the remaining PDB is less than the DRX cycle value associated with the peer WTRU. Otherwise, the TX WTRU can not apply the prioritization rules.

[0780] In another example, the TX WTRU can apply the prioritization rules described above when the highest priority of data pending for transmission to the WTRU configured with DRX is above a threshold, where the threshold can also depend on other factors such as the DRX cycle value and / or the measured CBR.

[0781] In one example of the LCP procedure, the TX WTRU can select the source / destination for transmission in the grant by selecting the L2 source or destination with the highest priority logical channel that has data available for transmission in the L2 source / destination, where the L2 source and destination are not configured with DRX or, if configured with DRX, have an active time that overlaps with the grant. If multiple destinations have the same priority or fall within a priority range, the TX WTRU can select a destination configured with DRX and for which the grant occurs within the active time.

[0782] (F). WTRU prioritizes / restricts transmissions to peer WTRU based on grant location within active time

[0783] In one solution, the WTRU can prioritize / restrict transmissions to a peer WTRU based on the time of the grant within the active period. Specifically, the WTRU can prioritize / restrict transmissions to a peer WTRU when the grant is located at the end of the active period. This can further depend on the remaining PDB of pending data to be transmitted to the WTRU. This can also depend on the time of occurrence of the next active period (e.g., DRX cycle), possibly relative to the remaining PDB.

[0784] For example, the WTRU can prioritize / restrict grants that occur in the last n time slots of the active time (on duration) of a particular peer WTRU, in the last n% of time slots of the active time of a particular peer WTRU, or after a certain amount of time has elapsed within the active period of a particular peer WTRU, such that the WTRU can prioritize / restrict transmissions to that particular peer WTRU in such grants. The WTRU can also perform prioritization / restriction based on whether the subsequent DRX active period falls within the remaining PDB of data to be transmitted, or can change the prioritization,

[0785] In one example embodiment, the TX WTRU can enable restriction in the LCP procedure such that if the TX WTRU has pending data to transmit to the peer WTRU, the grant that falls in the last N time slots of the DRX active time of the particular WTRU must be used for data transmission to that particular WTRU.

[0786] - In one example embodiment, if the data pending at the TX WTRU has a remaining PDB that is less than the DRX cycle (possibly, a function of the DRX cycle) of the RX WTRU, the TX WTRU can enable the constraint described in the previous example embodiment.

[0787] - In one example embodiment, the TX WTRU can bias the priority of an LCH during destination selection in LCP, whereby the bias is a function of the location of the grant within the active time. Specifically, when an LCH is associated with a transmission to a peer WTRU and the grant is located within the last N time slots of the active time of the peer WTRU, the WTRU can increase the priority of the LCH by a certain amount. As described in the examples above, the WTRU can further apply or not apply such bias depending on the relative size of the remaining PDB and the DRX cycle.

[0788] (G). The WTRU changes / adjusts the LCP constraints on the resource pool based on the time elapsed since the last data activity.

[0789] The WTRU can be configured with LCP constraints associated with a resource pool. Specifically, the WTRU can be configured with a constraint that allows a certain LCH to be multiplexed during LCP to a resource grant as long as the resource is associated with a first pool. With such a constraint, the WTRU can not be allowed to multiplex data from such logical channel to a grant associated with a second pool.

[0790] The WTRU can change such LCP constraints (enable / disable the constraints) based on a condition related to the time elapsed since the last data activity. The data activity can consist of:

[0791] - A data transmission possibly associated with the L2 source ID and / or L2 destination ID of an LCH.

[0792] - A data transmission possibly containing data from one or more of the LCHs under discussion (e.g., the LCH under discussion).

[0793] - An acknowledgement or feedback (e.g., HARQ feedback, CSI feedback, RSRP, etc.) possibly associated with one of the above data transmissions.

[0794] - The transmission / reception of an active command as discussed herein.

[0795] Such constraints that can be changed can be configured only for certain LCHs, while other LCHs can be configured with static constraints (i.e., the configuration is per LCH).

[0796] For example, the WTRU can restrict the SLRB / LCH to use resources from the first pool only when a last transmission associated with the L2 ID associated with the SLRB / LCH occurred at some time T1 in the past, where T1 > threshold. For example, the WTRU can maintain a separate timer per L2 destination ID and / or L2 source ID. The WTRU can start such timer upon transmission to the L2 source and / or destination ID. Upon starting such timer, the WTRU can cancel / disable the LCP restrictions associated with one or more LCHs. The WTRU can reset such timer upon transmission to the destination ID and / or source ID. When the timer expires, the WTRU can enable the LCP restrictions.

[0797] In another example, the WTRU can restrict the SLRB / LCH to use resources from the first pool. Upon receiving feedback (e.g., HARQ ACK feedback), the WTRU can start a timer and disable the restriction during the running of the timer. Specifically, when such timer is running, the WTRU can allow data from the LCH to be multiplexed according to grants from either the first pool or the second pool. The WTRU can reset such timer upon each reception of HARQ feedback from the peer WTRU. Upon expiration of the timer, the WTRU can re-enable the LCP restrictions and allow the LCH to be multiplexed according to grants associated with only one of the pools.

[0798] (H). The WTRU changes / adjusts the LCP restrictions on the resource pool based on the amount of data transmitted in the pool.

[0799] In one solution, the WTRU can adjust the LCP restrictions on the resource pool based on the amount of data transmitted on the pool. Specifically, the WTRU can enable / disable such restrictions (for a particular logical channel) based on the amount of data transmitted on the first pool, which is measured by any of:

[0800] - the number of sidelink procedures on the first resource pool.

[0801] - the channel occupancy ratio (CR) on the first resource pool.

[0802] - the periodicity of one or more procedures on the first resource pool.

[0803] - the number of sub-channels selected for a grant on the first resource pool.

[0804] Specifically, the LCH can be allowed to transmit on either the first resource pool or the second resource pool. When any of the above measures of the amount of data exceeds or does not exceed a threshold, the WTRU can restrict such LCH so that it is allowed only on the second pool (not allowed on the first pool) or only on the first pool (not allowed on the second pool).

[0805] (I). WTRU customizes the feedback request (e.g., CSI) to the active time of the peer WTRU

[0806] The WTRU can adjust the timing of CSI feedback based on the known active time of the peer WTRU. For example:

[0807] The WTRU can request CSI feedback only within a certain portion of the active time (e.g., the first N time slots of the DRX ON time, or a specific subset of the inactivity monitoring resource pool).

[0808] The WTRU can request CSI feedback only when the inactivity timer of the peer WTRU is below a threshold.

[0809] The WTRU can transmit the CSI feedback request only in the first transmission to the peer WTRU associated with the DRX ON time or some pre-configured or pre-determined resources associated with the inactivity resource pool.

[0810] WTRU transmits an “active signal” to indicate sidelink transmission in upcoming time / frequency period

[0811] In one embodiment, the WTRU can be configured to possibly transmit an active signal at a pre-defined time / frequency resource in order to schedule / signal the intention to transmit sidelink transmission in a future time period and / or set of frequency resources. The active signal can be an explicit signal (e.g., SCI, MAC CE or SL RRC message explicitly acting as an active signal). Alternatively, the active signal can consist of normal sidelink transmission on the set of resources reserved for active signal (e.g., normal SCI transmission on the set of sidelink resources associated with the active signal). The active signal can be associated with a set of “associated resources” whereby the transmission of the active signal indicates that the “associated resources” are used for transmission. The detection of the active signal by the RX WTRU can require monitoring the “associated resources” associated with the active signal. The absence of the active signal determined by the WTRU can indicate the possibility of performing DRX in the “associated resources” of the RX WTRU.

[0812] WTRU transmits an inactivity command or DRX flag / indication to assist the peer WTRU to minimize energy consumption.

[0813] In one solution, the TX WTRU can send an inactivity command (as described elsewhere herein) to change the active behavior at the receiving peer WTRU. Such a command can be in the form of a PC5-RRC message, a SL MAC CE, or a SL MAC subheader (i.e., containing only an LCID). Alternatively, such a command can be transmitted as a SCI or as one of the fields in the SCI (e.g., the power saving flag described further herein). Similarly, the WTRU can transmit a flag, command, or indication (in PC5-RRC, MAC CE, or MAC header, or SCI) to trigger a change in the active behavior / DRX configuration at the peer WTRU. Such a command can indicate:

[0814] - the DRX configuration to be applied (possibly in the form of a DRX configuration ID or an active behavior ID).

[0815] - one or more parameters of the DRX configuration to be applied / changed.

[0816] - whether to enable / disable DRX at the RX WTRU and the possible time at which the DRX should be enabled / disabled.

[0817] - the resource pool index to be used for further reception by the RX WTRU.

[0818] - termination of the activity on at least one resource pool, with the intent to stop the activity timer (i.e., on-duration timer, inactivity timer) and to deactivate the monitoring of the resource pool at the peer WTRU.

[0819] - change from one (active) resource pool to another (active) resource pool at the peer WTRU.

[0820] - the time period (e.g., number of slots or cycle of “associated resources” as described herein) for which the peer WTRU can perform DRX or abstain from monitoring the PSCCH for data and / or activity signals.

[0821] For example, consider the case where the TX WTRU can be configured to perform transmissions in a first resource pool and a second resource pool. For a given L2 ID, since the TX WTRU knows the active resource pool monitored at the peer WTRU, the TX WTRU can send an inactivity command to stop the activity timer (i.e., on-duration timer and inactivity timer) and to deactivate the monitoring of the indicated resource pool in the peer WTRU. As a result, the peer WTRU can transition to DRX in the indicated resource pool and achieve further power saving. The transmission of the inactivity command / indication and the information possibly included in the inactivity command can be triggered and / or the information in the command is determined by a combination of factors at the TX WTRU such as the following:

[0822] - Factors associated with SLRB / LCH configuration at the TX WTRU.

[0823] a. For example, the TX WTRU can determine the DRX configuration to transmit in the DRX flag / indication based on the configured SLRB or LCH at the TX WTRU. In particular, the WTRU can be (pre)configured with the required RX WTRU activity behavior for a specific configured SLRB / LCH. For example, the TX WTRU can receive the activity behavior ID / DRX configuration ID / enable / disable flag and per SLRB configuration. The WTRU can determine the information in the DRX flag / indication to a peer WTRU based on the set of SLRBs established at the TX WTRU for that peer WTRU.

[0824] b. For example, the TX WTRU can trigger the transmission of such a command (or include such a command with pending data transmission) when changing the SLRB / LCH configuration.

[0825] - Factors associated with the data in the buffer or the buffer status of the transmitter (possibly associated with each LCH):

[0826] a. For example, the command can be sent when the TX WTRU has no pending transmission in its buffer (possibly associated with the corresponding RX WTRU, which can be associated with only one or more LCHs).

[0827] (i) For example, the WTRU can receive the SLRB / LCH configuration indicating whether the WTRU can send an inactivity command when configured with such LCH. The WTRU can send such a command when the TX WTRU has no pending data transmission in its buffer, as long as each of the configured LCHs at the TX WTRU allows the transmission of an inactivity command.

[0828] b. For example, the command can be sent when the amount of data in the TX WTRU's buffer (possibly associated with the corresponding RX WTRU) is below a threshold.

[0829] c. For example, the command can be sent when the TX WTRU has no data in its buffer (possibly associated with the RX WTRU) for a certain period of time.

[0830] (i) The WTRU can determine such a period of time based on (pre)configuration.

[0831] (ii) The time period can be further configured per QoS and / or per LCH. For example, if the WTRU has no data in its buffer and the time period in which the WTRU has no data in its buffer for each LCH exceeds the time period configured for that LCH, the WTRU can send an inactivity command.

[0832] d. For example, the WTRU can determine the inactivity period to transmit in the inactivity command based on the LCH and / or the last LCH configured at the WTRU, such that data is available for transmission at the WTRU before the WTRU's buffer is emptied.

[0833] e. For example, the WTRU can determine the active configuration to transmit based on the amount of data in the WTRU's buffer. Specifically, the WTRU can be configured with a certain amount of data (or a certain range of amount of data) in the buffer for each active configuration, and can select the active configuration to transmit based on the buffer status.

[0834] f. For example, the WTRU can send a DRX flag indicating to disable DRX upon receiving new data in its buffer that can be associated with one or more LCHs.

[0835] g. For example, after the LCP procedure, a command can be sent to the RX WTRU with pending data in the associated LCHs. Specifically, if the LCHs selected for grant based on LCP constraints do not include any of the LCHs associated with the RX WTRU, and the TX WTRU does not have any additional grants until the next active period of the RX WTRU, a command can be sent to the RX WTRU to transition to DRX. The rules applied according to the LCP procedure when determining the grants can include setting the priority of the SL data to be higher than the priority of the inactivity command, such that the grant can include all remaining data in the buffer before the inactivity command. In this case, the command can be sent when the last TB containing data from all LCHs associated with the RX WTRU is combined, and there can be no additional transmissions intended for the RX WTRU for a certain duration of time. The command can be sent as an end marker with the last TB by using the remaining resources in the grant.

[0836] - a factor associated with the HARQ feedback status from the RX WTRU.

[0837] a. For example, the WTRU can send the command after receiving a certain HARQ feedback status (e.g., ACK) on the data transmission.

[0838] i. For example, an ACK after the last data transmitted in the buffer.

[0839] - a factor associated with the delay requirement (PDB) of the data to be transmitted.

[0840] a. For example, expiration of a timeout value associated with the PDB (Packet Delay Budget) of one or more pending transmissions in its buffer. For example, the WTRU can send the command if all pending data to be transmitted has exceeded its PDB.

[0841] b. For example, the WTRU can send such a command upon reception of data with a delay requirement (PDB) that is smaller than a certain function of the currently configured active behavior parameter (e.g., DRX cycle) at the RX WTRU.

[0842] c. For example, the WTRU can set the value of the DRX command based on the PDB of the data in its buffer.

[0843] - an indication from an upper layer.

[0844] a. For example, the WTRU can send the command after an upper layer request to start / release a unicast link.

[0845] - a factor associated with the presence / type of sidelink procedures at the TX WTRU.

[0846] a. For example, the WTRU can send the command if it has no active sidelink procedures that can be associated with a type of transmission (periodic vs. asynchronous transmission).

[0847] - a factor associated with sidelink channel congestion.

[0848] a. For example, the WTRU can send the command or determine the value of the command / flag depending on whether the CBR associated with the sidelink carrier (containing the configured resource pool associated with the peer WTRU) is above / below a threshold value.

[0849] b. For example, the WTRU can send the command or determine the value of the command / flag depending on whether the CBR associated with the sidelink carrier containing the configured resource pool remains above / below a threshold value for longer than a time duration.

[0850] c. For example, the amount of time indicated in an inactivity timer can depend on the measured CBR.

[0851] - a factor associated with the TX WTRU location.

[0852] a. For example, the WTRU can send the command if it moves into a (pre)configured location or zone where DRX is enabled or transmission of the inactivity command is allowed.

[0853] b. For example, the WTRU can send the command if it detects a transmission from a peer WTRU for which the WTRU has moved out of the minimum communication range of such transmission.

[0854] - an indication from the network.

[0855] a. For example, the WTRU can receive an indication from the network (e.g., when in mode 1) and can send the command upon receiving such indication. The indication can be received explicitly as a field in DCI, MAC CE or RRC message from the network. The WTRU can further receive from the network a time period to be sent in the inactivity command and can include such time in the command. Alternatively, the WTRU can transmit the command due to other signaling from the network such as:

[0856] (i). reconfiguration of SLRB (e.g., if such SLRB reconfiguration enables DRX like behavior).

[0857] (ii). release of Uu connection (e.g., if the idle mode configuration allows DRX behavior, the command can be sent after release by the network in RRC connected.

[0858] (iii). release of one or more SLRB (e.g., if the network releases one or more SLRBs associated with a unicast link when the WTRU only has buffered data associated with the SLRB, the command can be sent).

[0859] The WTRU receiving the inactivity command can perform any of the following:

[0860] - change from one active behavior / DRX configuration to another active behavior / DRX configuration.

[0861] - switch from active resource pool to inactive resource pool.

[0862] - stop all timers / counters etc. related to active monitoring and transition to active behavior related to DRX and / or inactivity.

[0863] - avoid monitoring PSCCH for data and / or active command for the time period indicated in the inactivity command.

[0864] - acknowledge the reception of the inactivity command.

[0865] - sending a command to another WTRU or another unicast link (e.g., another pair of source / destination IDs), where such indication can also include information in the received inactivity command.

[0866] - forwarding the inactivity command to a group of WTRUs that can be configured at the WTRU (e.g., destination IDs that the WTRU is configured to relay).

[0867] - changing the active configuration / DRX configuration, as further described herein.

[0868] In a groupcast scenario, it can be possible that a first subset of receiving WTRUs in the group have successfully received the transmission of the TB while a second subset of WTRUs need a retransmission. The first subset of WTRUs that have successfully received the TB can choose to deactivate monitoring in the corresponding resource pool and transition to DRX in the subsequent slots, while the second subset of WTRUs that sent feedback can continue monitoring for retransmission. In this case, an inactivity command can be sent by the TX WTRU to the first subset of WTRUs to transition to DRX while waiting for the retransmission to the second subset of WTRUs to complete. The inactivity command can include a DRX duration, and as long as the DRX duration is running, the WTRUs in the first subset can apply to deactivate monitoring of the resource pool. The WTRUs in the first subset can re-activate the resource pool and associated active timer after the indicated DRX duration expires. The inactivity command containing the DRX duration can be sent individually to each WTRU in the first subset via unicast transmission.

[0869] (A) WTRU indicates in periodic reservation SCI whether peer WTRU is permitted to DRX

[0870] In one example embodiment of the above solution, the WTRU can include a flag / indication to peer WTRUs in the periodic reservation SCI (i.e., SCI reserving resources in the future) indicating whether the peer WTRU can perform DRX in any / all of the slots between the current SCI and the future resources. The WTRU can determine whether to include such flag and / or the value of the flag (i.e., whether the peer WTRU should monitor for PSCCHs scheduled between periodic SCI transmissions) based on any of the following:

[0871] - whether an asynchronous transmission is planned / scheduled prior to the future scheduled resources.

[0872] a. In particular, the WTRU can decide to perform resource selection for a one-shot / asynchronous transmission in one of the resources between the SCI and the future reserved resources, and can indicate to the peer WTRU to perform PSCCH decoding for scheduling between periodic transmissions.

[0873] - the need / trigger for resource reselection.

[0874] a. In particular, the WTRU can trigger resource (re)selection for the same periodic procedure (or another periodic or aperiodic procedure) and can indicate to the peer WTRU to monitor PSCCH for scheduling between periodic transmissions.

[0875] - based on arrival of new data that can be associated with a particular LCH and / or QoS requirement.

[0876] a. For example, the WTRU can indicate to the peer WTRU that PSCCH monitoring for scheduling is needed when data has arrived for a particular LCH (e.g., a LCH configured with such a characteristic or a LCH configured with a particular priority / delay and / or other QoS parameters).

[0877] b. For example, the WTRU can indicate to the peer WTRU that PSSCH monitoring for scheduling is needed if data has arrived and PDB requires such data to be transmitted between periodic transmissions.

[0878] c. For example, the WTRU can indicate to the peer WTRU that PSSCH monitoring for scheduling is needed if data has arrived such that the priority of such data meets a criterion related to other data in the WTRU buffer, a certain preconfigured condition, any data reported in a previous BSR, or a combination of these.

[0879] (i) For example, priority is higher (or equal to) than any existing data in the WTRU buffer.

[0880] - based on the need to perform a CSI request.

[0881] a. For example, the WTRU can indicate to the peer WTRU that PSCCH monitoring for scheduling is needed if the TX WTRU intends to transmit a CSI request (or has a pending CSI request).

[0882] The WTRU can also provide a set of resources (explicitly or based on a pre-defined configured index) for which the peer WTRU should perform PSCCH monitoring between the SCI and the future reserved resources and can constrain such SCI transmission (based on resource selection) to such resources. Alternatively, the WTRU can provide selected resources in the SCI for asynchronous transmission (after resource selection). Upon receiving such additional information, the RX WTRU can perform DRX on all slots between the SCI and the future reserved resources (except those indicated in the selected / constrained resource list in the SCI).

[0883] WTRU transmits padding to indicate the capability of the peer WTRU to perform DRX

[0884] In one solution, the TX WTRU can send an implicit inactivity command to instruct the RX WTRU to stop monitoring the configured resource pool and transition to DRX. For example, the inactivity command can be sent in the form of one or more padding bits that constitute the remaining bits after combining initial data bits in a MAC PDU. The inactivity command can be implicitly sent by the TX WTRU when the following conditions are met:

[0885] - Data in buffers in all prioritized LCHs and MAC CEs associated with the RX WTRU can be included within the grant.

[0886] - Other remaining resources are available within the grant for including padding bits.

[0887] - No transmission is needed in at least one subsequent period corresponding to the active period of the RX WTRU or any of the configured resource pools monitored by the RX WTRU.

[0888] The inactivity command can be pre-configured to also implicitly indicate the following information:

[0889] - DRX duration: For example, the inactivity command indicates a duration for which the RX WTRU remains in DRX. After the pre-configured DRX duration expires, the RX WTRU can re-activate the resource pool and associated active timer.

[0890] - Active resource pool: For example, the inactivity command indicates a resource pool that the RX WTRU can activate and monitor after transitioning from DRX.

[0891] (A). WTRU determines a set of resources for an active signal and associated resource

[0892] The WTRU can be configured with a specific or dedicated set of resources for transmitting / receiving an active signal. Such a dedicated set of resources can consist of any combination of the following:

[0893] - A pre-configured time / frequency resource within a resource pool.

[0894] - A pre-configured SL frame / subframe / SFN number.

[0895] The WTRU can determine the active signal resources using resource identification obtained from any of the following sources:

[0896] - SIB or dedicated signaling - For example, in-coverage WTRUs can determine the frame / slot number from system information. Each WTRU can then be configured (also in SIB or dedicated signaling) with time / frequency resources for active signal resources and associated resources. Such configuration can be further determined based on other factors (e.g., L2 Destination ID) described further below.

[0897] - SL-MIB, SL SSB, SL-PBCH, or similar sidelink broadcast channel - For example, out-of-coverage WTRUs can determine the frame / slot number from a sidelink broadcast channel. Each WTRU can then be configured (in pre-configuration) with time / frequency resources for active signal resources and associated resources. Such configuration can be further determined based on other factors (e.g., L2 Destination ID) described further below.

[0898] - GNSS or similar satellite signal - For example, in-coverage or out-of-coverage WTRUs can determine the frame / slot number from GNSS. Each WTRU can then be configured (in SIB or (pre-)configuration) with time / frequency resources for active (pre-)configuration and associated resources. Such configuration can be further determined based on other factors (e.g., L2 Destination ID) described further below.

[0899] - PC5-RRC - For example, when such active signal is specific to a unicast link, a WTRU can configure a peer WTRU with a set of resources for active signal and associated resources.

[0900] A dedicated set of resources for transmitting an active signal can be further associated with a set of time / frequency SL resources, when a WTRU detects a transmission of an active signal, the WTRU shall further perform active monitoring of such associated resources. When a WTRU does not detect any transmission in active signal resources for an associated set of resources, the WTRU can abandon monitoring the associated set of resources (i.e., perform DRX). A WTRU can further determine whether it can perform DRX in associated resources in the absence of an active signal according to other rules described herein.

[0901] A set of resources for an active signal can be defined according to the first N sets of resources in an associated set of monitoring resources. For example, a resource pool or a set of time / frequency resources for sidelink transmission can be divided into multiple sets of resources, and each set of resources can be associated with an active monitoring period. The resources associated with an active signal can be the first N resources of each active monitoring period.

[0902] The set of resources for the active signal and possibly the associated resources that guarantee active monitoring after receiving the active signal can also be associated with (or dedicated to):

[0903] - a cast type (i.e., active signal resources and associated monitoring resources for each cast type).

[0904] - an L1 / L2 destination ID (i.e., active signal resources and associated monitoring resources for each L2 ID).

[0905] - a TX or RX resource pool.

[0906] - a unicast link.

[0907] - a QoS or priority value or set of values (i.e., active signal resources and associated monitoring resources for each priority value or set of values).

[0908] With such associations, the following TX / RX WTRU behaviors can be further specific to each of the above factors.

[0909] (B). TX WTRU behaviors

[0910] When a TX WTRU is configured to use the active signal for transmission, the TX WTRU can do the following:

[0911] - If the WTRU has a new transmission to perform, perform the transmission in the resources for the active signal before performing any additional transmissions on any associated resources.

[0912] - If the WTRU is already transmitting in the resources associated with the active signal, or in the active signal itself, can be allowed to perform transmissions in any associated resources.

[0913] - If the WTRU has detected a transmission from another WTRU in the resources associated with the active signal, the WTRU can transmit in any associated resources.

[0914] (C). RX WTRU behaviors

[0915] When a RX WTRU is configured to use the active signal, the RX WTRU can do the following:

[0916] - If the WTRU has received a transmission in the resources associated with the active signal, can be required to perform active monitoring / decoding in the associated monitoring resources.

[0917] - If the WTRU has not received a transmission in the resources associated with the active signal, and possibly, if the WTRU does not meet other conditions described herein for maintaining active monitoring (e.g., expected CSI feedback reception), the WTRU can perform DRX in the associated monitoring resources. The WTRU can again monitor the SL resources at the resources associated with the next active signal.

[0918] (D). TX WTRU / RX WTRU can prioritize transmission / reception of active signal

[0919] Transmission / reception of the active signal can be prioritized over other transmissions / receptions. This can be achieved by any of the following examples:

[0920] - The TX WTRU can assign the highest priority value to the transmission of the active signal or to the transmission within the resources for the active signal, regardless of the priority value of the actual data (if any) associated with the transmission.

[0921] - The TX WTRU can prioritize the transmission of the active signal over UL transmission / reception.

[0922] - The TX WTRU can preempt its own transmission or a transmission by another WTRU in order to transmit the active signal.

[0923] - The TX WTRU can avoid using the resources for the active signal for transmitting data that is not intended for the transmission of the active signal.

[0924] - The RX WTRU can prioritize the reception of the active signal resources over UL transmission / reception.

[0925] - The TX WTRU can add an offset to the priority of the transmission of the active signal and / or the reception of the SCI in the listening when determining whether resources available for transmission (assuming such transmission is associated with the transmission of the active signal) are available.

[0926] (E). Exemplary embodiments

[0927] FIG. 3 Exemplary embodiments of the described solutions / embodiments are shown. The active signal transmission is performed by transmitting normal SCI / data in the resources so configured. In FIG. 3 , the active signal 301 is a transmission received by the WTRU for period 1. The active signal 302 is a transmission of period 2. The active signal 303 is a transmission of period 3. The active signal resources are defined for each L2 destination ID. The WTRU receives the active resource configuration and the configuration of the associated resources via SIB and further computes each of these resources specific to each L2 destination ID currently configured to be received by upper layers.

[0928] When executing a transmission addressed to an L2 destination ID, the TX WTRU ensures that for each cycle of the associated resource it intends to use for the transmission, it performs the transmission within the active resource designated for the L2 destination ID. When the RX WTRU detects a transmission addressed to an L2 destination ID in an active signaling resource, the RX WTRU will ensure that it performs monitoring in the associated resource.

[0929] like FIG. 4 As shown in the example, the TX WTRU performs transmissions 401 and 403 in the active signal resources used for cycles 1 and 3. The RX WTRU performs activity monitoring in the associated resources used for these two cycles. In cycle 2, no TX WTRU transmission occurs in the active signal 402 for the resource used for cycle 2. Considering that there are no transmissions in the active signal resources used for this cycle (i.e., no TX transmission at 402), the RX WTRU performs DRX in the associated resource for cycle 2.

[0930] Dynamic resource pool determination

[0931] Based on the activity's resource pool

[0932] DRX and / or algorithms (such as any of the power-saving mechanisms described herein) can further control other power-saving aspects. Such aspects may include resource pools and / or one or more of their characteristics. Such aspects may include the amount of resources maintained for listening (e.g., a listening window). Such controls may be applied only to resource pools associated with one or more V2X groups.

[0933] Dynamic adaptation of resource pools based on launch activities

[0934] For example, a WTRU can dynamically adjust a resource pool (e.g., in time and / or frequency) according to scheduled activities and / or resource usage that can be for a specific V2X group (e.g., L2 ID) for a given time period. A WTRU can use a first resource pool while a timer T is running, start or restart the timer when it determines (the WTRU or another WTRU) transmits control and / or data on resources associated with the resource pool currently being used, and use a second resource pool Y when the timer expires. It can be that the WTRU starts or restarts the timer only if it determines that the transmission is for a configured session of the WTRU (e.g., associated with one or more specific configured L2 IDs). It can be that the WTRU uses a transmission in another one of the resource pools for such determination if one of the resource pools is used only for the purpose of restarting the timer (e.g., if a transmission in one of the pools does not enable the WTRU to determine whether the transmission is for a configured session of the WTRU, e.g., a wake-up signal). It can be that the WTRU can additionally use the first resource pool according to a fixed configured periodicity.

[0935] A WTRU is configured to activate a second (active) resource pool based on activity on the first pool.

[0936] A WTRU can be configured with a first and a second receive or transmit pool, whereby a WTRU’s monitoring activity (e.g., PSCCH decoding, listening, using the pool for resource selection, etc.) on the second pool is determined based on activity on the first and / or second pool. The monitoring activity can consist of any of:

[0937] Whether the WTRU performs decoding of PSCCH and / or PSSCH on the second pool.

[0938] Whether the WTRU performs monitoring / decoding of PSFCH, PSBCH, SL master information block (MIB) on the second pool.

[0939] Whether the WTRU is allowed to transmit on the second pool.

[0940] Whether the WTRU performs listening or stores / collects listening results on the second pool.

[0941] The amount of listening results collected for the second pool (e.g., listening window, whether partial or full listening is used, configuration of partial listening, etc.).

[0942] During the active time, a WTRU can monitor only the second pool. Alternatively, a WTRU can monitor both the first and the second pool.

[0943] A WTRU can determine whether to start / stop decoding on the second (active) pool based on any of the following (shown in the following examples). In certain cases, a combination of specific examples can be used to determine the conditions for activating monitoring on the second pool is possible.

[0944] A WTRU monitoring the first pool can be configured with a first condition. The first condition can trigger the WTRU to start monitoring on the second pool in addition to the first pool. A WTRU monitoring the second pool can be configured with a second condition. The second condition can trigger the WTRU to stop monitoring the second pool and only monitor the first pool.

[0945] Possible first conditions:

[0946] A WTRU can be configured with any of the following or a combination of the following as a first condition:

[0947] - Receiving a specific L2 ID (source and / or destination).

[0948] a. For example, a WTRU monitoring only the first pool can start monitoring the second pool if it receives transmissions that can be periodic only, associated with one or more specific L2 destination IDs. Such L2 destination IDs can be any of the L2 destination IDs of interest to the WTRU. Alternatively, such L2 destination IDs can be a subset of one or more configured L2 destination IDs that trigger the start of monitoring of the second pool.

[0949] - Receiving a specific amount or density of receptions in the first pool and possibly also in the second pool.

[0950] a. For example, a WTRU monitoring only the first pool can start monitoring the second pool if it receives two or more SCI on the first pool, where the time difference between such SCI is below a threshold.

[0951] b. For example, a WTRU monitoring only the first pool can start monitoring the second pool if it receives a number of SCI (above a threshold number) within a specific time period, where such time period can be further limited by the configuration of the first resource pool.

[0952] - Receiving data of a specific type / property (e.g., periodic vs. asynchronous).

[0953] a. For example, a WTRU monitoring only the first pool can start monitoring the second pool if it receives transmissions indicating periodic transmissions, possibly associated with L2 IDs of interest. A WTRU monitoring only the first pool can continue to monitor only the first pool if it receives asynchronous (aperiodic) transmissions.

[0954] - receiving data, where at least some of the data is associated with a QoS configured to allow triggering monitoring of the second pool.

[0955] a. For example, if the received PDU contains data from a logical channel configured to allow triggering WTRU monitoring of the second pool (e.g., above / below a threshold), the WTRU can initiate monitoring of the second pool.

[0956] b. For example, if the received SCI contains a priority configured to allow monitoring of the second pool, the WTRU can initiate monitoring of the second pool.

[0957] c. For example, if the received data is associated with an MCR below a threshold, which can be related to an estimated distance to a peer WTRU, the WTRU can initiate monitoring of the second pool. For example, if the WTRU receives data and if the WTRU is within the MCR of the received data, the WTRU can initiate monitoring of the second pool.

[0958] - receiving an explicit command / indication from the network or a peer WTRU to start monitoring the second pool. Such explicit command can be in the form of:

[0959] a. A MAC CE, RRC message, possibly transmitted with data, possibly transmitted periodically by a peer WTRU.

[0960] (i). For example, the message can be an indication to start monitoring the second pool.

[0961] (ii). For example, the message can be an indication to monitor the second pool for a certain time period, in multiple cycles (related to the periodicity of the data, the periodicity of the monitoring of the first pool, or to a certain periodicity associated with or configured with the first pool or the second pool). For example, the command can contain a mapping to a pre-configured set of time periods or time slots / sub-channels that the WTRU is expected to measure in the second pool.

[0962] (iii). For example, the WTRU can monitor the second pool as long as it receives such a message (possibly in a periodic manner) in the first pool and / or the second pool. Specifically, the message can be a "keep monitoring" indication. Such indication can trigger the WTRU to monitor the second pool for a time associated with the periodicity of the first pool and / or the "keep monitoring" indication. Such indication can be piggybacked with data in the first pool or the second pool.

[0963] (iv). For example, the WTRU can be configured with DRX enabled and can monitor the first (inactive) pool. The WTRU can be (re)configured to disable DRX and can start monitoring the second (active) pool. The WTRU can be (re)configured to enable DRX and can return to monitoring the first (inactive) pool.

[0964] b. a new SCI, an explicit indication within the SCI, or a SCI scheduling data in the second pool.

[0965] (i). For example, the SCI can be a standalone SCI or can be a SCI scheduling data.

[0966] (ii). For example, the SCI can also be a SCI scheduling data in the second pool.

[0967] (iii). For example, the SCI can initiate periodic transmission on the second pool.

[0968] (iv). For example, the SCI can provide scheduling information indicating resources associated with the second pool. Upon receiving such scheduling, the WTRU can start monitoring the second pool.

[0969] c. a certain field value in the SCI that is expected to not be correctly received in the first pool.

[0970] (i). For example, if the WTRU receives a reserved interval that is not supported by the WTRU or the first pool or is associated with an indication to start monitoring the second pool, the WTRU can start monitoring the second pool. For example, the first pool can be configured with one or more “trigger” reserved intervals (e.g., 20ms, 50ms). If the WTRU receives on the first pool a scheduling with one of these trigger reception intervals, the WTRU can start monitoring the second pool.

[0971] (ii). For example, if the WTRU receives a reserved interval that cannot be used in the first pool based on the resource configuration of the first pool, the WTRU can start monitoring the second pool.

[0972] Possible second conditions:

[0973] The WTRU can be configured with any one or a combination of the following as the second condition:

[0974] - expiry of an inactivity timer as discussed herein and possibly associated with transmissions in the first pool or the second pool or both the first pool and the second pool.

[0975] - lack of transmissions within the MCR.

[0976] a. For example, the WTRU can stop monitoring the second pool after the inactivity timer expires, where the WTRU does not receive any transmissions within the MCR.

[0977] - detecting the absence of any one of the first conditions (immediately from the absence or after some inactivity timer from the absence).

[0978] a. For example, the WTRU can stop monitoring the second pool after the last transmission of a periodic procedure in the first pool, where the start of such periodic procedure can have initiated monitoring of the second pool.

[0979] b. For example, the WTRU can stop monitoring the second pool if it does not receive an explicit command associated with the first conditions, possibly in a transmission period or possibly with a periodicity associated with resources in the first pool.

[0980] c. For example, the WTRU can stop monitoring the second pool if it does not receive a “keep monitoring” indication as further described herein for the first conditions.

[0981] - detecting an explicit command transmitted in the first pool or the second pool.

[0982] a. For example, the WTRU can receive a SCI, MAC CE, RRC message or similar information that explicitly indicates that the WTRU can stop monitoring the second pool.

[0983] b. For example, such explicit command or message can appear as an explicit indication in the SCI.

[0984] c. For example, such command can be transmitted using similar implicit methods discussed above in the section “WTRU transmission padding to indicate capability of peer WTRU to perform DRX”.

[0985] (A). The WTRU assumes that all scheduling in the first pool is associated with resources in the second pool.

[0986] In one example, the WTRU can start monitoring resources in the second pool upon receiving a scheduling SCI or a command message (e.g., MAC CE, RRC). The WTRU can further assume that all transmissions in the first pool are associated with one or more resources (e.g., sub-channels and / or time slots) in the second pool. Such association can be pre-configured and / or can be indicated in the SCI / command message from the first pool itself. The WTRU can only monitor the second pool for the duration of the associated resources and can then stop monitoring the second pool. The WTRU can continue monitoring the second pool as long as it receives an SCI or a command in the first pool that there is some association in the second pool.

[0987] (B). The WTRU is provided with two different configurations of one or more resource pools to be used for each active / inactive time.

[0988] In one example, the WTRU can be provided with multiple (e.g., two) configurations for a resource pool. The WTRU can change from using a first configuration of a resource pool to using a second configuration of a resource pool when the first condition described above or any other condition described herein for transitioning from an inactive RX behavior to an active RX behavior occurs. The WTRU can also change from using the second configuration of a resource pool to using the first configuration of a resource pool when the second condition described above or any other condition described herein for transitioning from an active behavior to an inactive behavior occurs. The WTRU can change any of the configuration aspects of its resource pool, including:

[0989] - configuration of PSCCH, PSSCH, and / or PSFCH (e.g., configuration of DMRS, betaOffset of second SCI, etc.).

[0990] - subchannel size.

[0991] - number of subchannels.

[0992] - numerology.

[0993] - starting resource block of subchannel.

[0994] - MCS table.

[0995] - zone configuration.

[0996] - time window for measurements related to sensing, CBR, CR, etc.

[0997] - resource pool periodicity and / or time resources.

[0998] For example, the WTRU can be configured with a set of parameters or configuration of one or more of the above aspects to be used with an active period, and another such configuration to be used with an inactive period. The WTRU can use the first configuration when it determines that it is in an active period as described herein, and the WTRU can use the second configuration when it determines that it is in an inactive period as described herein.

[0999] (C). Exemplary embodiments

[1000] (C1). Measuring activity on a first pool by reception / reception absence.

[1001] For example, a WTRU can be configured with a first RX resource pool (e.g., a default pool) and a second RX pool (an active pool). The WTRU can be configured to start / restart a timer upon reception of data (possibly intended for a L2 ID of interest of the WTRU) within the first RX pool. While such a timer is running, the WTRU can perform PSCCH decoding in the second RX pool (and possibly also in the first RX pool). After expiration of such a timer, the WTRU can perform PSCCH decoding only on the first RX pool (default pool). Reception of a PSCCH on the first RX pool and / or the second RX pool can reset such a timer.

[1002] (C2). Measure activity on the first pool by density of reception.

[1003] For example, a WTRU can be configured to monitor the activity density (e.g., the number of received transmissions, possibly intended to the WTRU, received within a certain unit of time) on the first pool. When the activity density of the first pool exceeds a certain threshold, the WTRU starts monitoring the second pool (and possibly also starts monitoring the first RX pool). When such an activity density of the first pool and / or the second pool falls below (possibly different) thresholds, the WTRU can stop monitoring the second RX pool. Alternatively, initiation of monitoring of the second pool can start a timer at the WTRU, and the WTRU can stop monitoring the second pool upon expiration of such a timer. Such a timer can be further reset upon occurrence of similar events associated with initiation of monitoring of the second pool.

[1004] (C3). Measure activity on the first pool by priority of transmission

[1005] For example, a WTRU can be configured to monitor the priority of transmissions on the first pool, possibly intended to the WTRU, and when the priority of one or more transmissions exceeds a threshold (i.e., higher priority), monitoring of the second pool can be initiated. Such a priority condition can be further combined with any other example of this solution. For example, reception density can be measured for transmissions associated with a priority above a threshold. When all transmissions (possibly for a period of time) are below the threshold, the WTRU can stop monitoring the second RX pool. Alternatively, initiation of monitoring of the second pool can start a timer at the WTRU, and the WTRU can stop monitoring the second pool upon expiration of such a timer. Such a timer can be further reset upon occurrence of similar events associated with initiation of monitoring of the second pool (i.e., reception density associated with a certain priority exceeds a threshold).

[1006] (C4.) Measure activity on the first pool based on WTRU location

[1007] For example, a WTRU configured with a first RX pool and a second RX pool can also be configured with corresponding location information. Specifically, when the RX WTRU receives a transmission in the first pool from a TX WTRU, the RX WTRU identifies the location of the TX WTRU from the location information (e.g., zone ID) indicated in the SCI. While the location information (e.g., zone ID) of the TX WTRU remains unchanged, the RX WTRU can perform PSCCH decoding on the second RX pool and possibly on the first RX pool. When the location information of the TX WTRU changes due to mobility or another TX WTRU transmitting from a different location, the RX WTRU can perform decoding of PSCCH only on the first RX pool. The criteria for determining the location information (i.e., zone ID) at the RX WTRU for monitoring or not monitoring the second RX pool can be pre-configured.

[1008] This scenario can be applicable for energy-constrained public safety WTRUs with the capability of selecting RX pools to monitor based on the location of the TX WTRU. For example, the RX WTRU can select to monitor a first RX pool and a second RX pool associated with a TX WTRU located in a high-relevance critical zone. Alternatively, the RX WTRU can save energy by monitoring only a first RX pool associated with a TX WTRU located in a low-relevance non-critical zone.

[1009] (C5.) Measure activity on the first pool by receiving data within the MCR

[1010] For example, upon receiving data within the minimum communication range (MCR) signaled by the WTRU in the SCI, a WTRU configured with / with a first RX pool (indicating a low level of activity) and a second RX pool (indicating a higher level of activity) can transition from monitoring the first resource pool to monitoring the first resource pool and the second resource pool. The MCR can be an information element received via the SCI. Priority information can be included in the SCI. The WTRU can start (restart) an inactivity timer upon receiving data in the first resource pool and / or the second resource pool for the WTRU within the MCR signaled in the SCI for the first resource pool and / or the second resource pool. The WTRU can set the value of the inactivity timer based on the QoS of the last received transmission. Thereafter, when the inactivity timer expires, the WTRU can change from monitoring the first resource pool and the second resource pool to monitoring the first resource pool. This implementation is shown in FIG. 5 FIG. 5 ​WTRU 502 in FIG. 5B can monitor the resource pool associated with low data activity (first resource pool) and another resource pool (second resource pool) associated with high data activity when the WTRU 502 is within a minimum communication range (MCR 506) of the vehicle 504 at location 1. In this configuration, the WTRU 502 can start and maintain an active timer. When FIG. 5 When the WTRU 502 in FIG. 5B moves to a location 2 outside the MCR 506 of the vehicle 504, the WTRU 502 does not receive data from the vehicle 504. Outside the MCR and possibly after the active timer expires, the WTRU 502 can then monitor the resource pool associated with low data activity instead of both resource pools. In this example (WTRU 502 at location 2 outside the MCR 506), there is no need to monitor the resource pool associated with high data activity.

[1011] (C6). Measure activity on the first pool by the type of transmission on the first pool

[1012] The WTRU can decide whether to monitor the second pool based on a combination of any of the examples and the type of transmission, which can be any of the following:

[1013] - Broadcast (i.e., unicast, groupcast, broadcast).

[1014] - Data / control.

[1015] a. For example, whether the data is associated with a signaling radio bearer (SRB) or a data radio bearer (DRB).

[1016] b. For example, whether the transmission is a SCI with data or a SCI only transmission.

[1017] - Periodic vs. asynchronous.

[1018] - Feedback nature of the transmission.

[1019] a. For example, whether HARQ is enabled.

[1020] For example, upon receiving data in the first pool, the WTRU can start monitoring the second pool as long as the received transmission in the first pool is associated with an asynchronous transmission. If the received transmission in the first pool indicates a future reserved resource (e.g., indicated by a reservation period in the SCI), the WTRU can not start monitoring the second pool. The WTRU can further determine whether to monitor the second pool upon receiving a periodic transmission in the first pool according to the indicated period. Specifically, if the next transmission indicated in the SCI is associated with a slot associated with the first pool, the WTRU can continue to monitor only the first pool, otherwise, the WTRU can monitor the second pool after the transmission in the first pool.

[1021] (D). The thresholds in the above examples can further depend on the Channel Busy Ratio (CBR)

[1022] In any of the above examples, the threshold or condition used to determine when to start / stop monitoring the second pool can further depend on the measured CBR. For example, the WTRU can be configured with a set of thresholds for such condition, where each threshold is associated with a range of CBR, and the WTRU uses that threshold when the measured CBR falls within the associated range.

[1023] (E). The thresholds in the above examples can further depend on the priority of the transmission that triggers the RX pool change.

[1024] In any of the above examples, the threshold or condition used to determine when to start / stop monitoring the second pool can further depend on the received priority of the transmission. For example, the WTRU can be configured with a set of thresholds for such condition, where each threshold is associated with a priority, and the WTRU uses that threshold when the received priority matches the priority associated with the threshold.

[1025] (E1). Two-level monitoring rate of activation triggers on the first pool

[1026] For example, the WTRU can be configured with a two-level monitoring rate for the first pool, where the monitoring rate is associated with a number of instances in a given duration in which the RX WTRU monitors for second pool activation triggers (e.g., periodic signal, SL MAC CE, SCI). In this case, the first monitoring rate can be configured to ensure that the RX WTRU is able to detect a certain value of activation triggers transmitted by the TX WTRU with high probability. Likewise, the second monitoring rate can be configured with a lower frequency value than the first monitoring rate. When using the first monitoring rate, upon detecting an activation trigger, an inactivity timer can be started in a first time slot, and if another activation trigger is received while the inactivity timer is running, the inactivity timer is reset. If the inactivity timer expires without detecting any activation triggers, the first monitoring rate is changed to the second monitoring rate.

[1027] (E2). Receiving an activity command in the first pool based on WTRU location

[1028] For example, a WTRU can be configured with a first resource pool for monitoring and also be configured with associated location information (e.g., zone ID). Specifically, the first resource pool used by the WTRU to monitor for activation triggers for activating a second resource pool is determined based on the geographical zone in which the WTRU is located. In this case, the WTRU can be (pre)configured with one or more first resource pools that can be used to monitor each corresponding zone ID. Since multiple WTRUs at a given time and location can apply the same first resource pool configuration, the RX WTRU can also be configured with additional location-based trigger conditions for mitigating potential congestion in the first resource pool. For example, when the WTRU approaches the boundary of the current zone, the trigger condition can be used to activate one or more first resource pools associated with a neighboring zone. The WTRU can use the activated first resource pools of the neighboring zone for monitoring for the presence of activation triggers until the activation triggers move away from the boundary area of the zone and reach the central area of another zone to transition back to monitoring a single first resource pool. In another example, if the TX WTRU knows the location of the RX WTRU (e.g., based on an upper layer indication indicating that the RX WTRU is at the zone boundary), the TX WTRU can transmit activation triggers in both the first resource pool associated with its own zone and the first resource pool associated with the neighboring zone to improve the probability of the RX WTRU receiving the activation command. In another example, if the TX WTRU knows that it is approaching the boundary of a neighboring zone, the TX WTRU can transmit activation triggers in both the first resource pool associated with its own zone and the first resource pool associated with the neighboring zone.

[1029] The TX WTRU determines whether to use the first RX pool or the second RX pool for transmission (to the RX WTRU)

[1030] In one solution, the TX WTRU is configured to perform transmission in the first resource pool and the second resource pool. When the first condition is triggered, the second resource pool can be used for transmitting data in addition to the first resource pool. If the second condition is triggered, the WTRU can stop transmitting in the second resource pool and fall back to transmitting in the first resource pool.

[1031] For example, consider a sidelink procedure initiated when new data arrives in the buffer associated with one or more LCHs, which is intended for transmission to one or more peer WTRUs. The TX WTRU can determine the amount of data associated with LCHs based on the LCP procedure for a given number of grants, which can be multiplexed and combined in one or more TBs. Next, based on knowing the resource availability in the first resource pool and the second resource pool, and the resource pool monitoring configuration applied in the peer WTRU, the TX WTRU can determine whether the first resource pool or the second resource pool or both the first resource pool and the second resource pool can be used to perform the transmission. The determination to use the second resource pool based on satisfying the first condition, which in turn can depend on several factors. Likewise, the TX WTRU can also determine whether the second condition can be satisfied by identifying triggers that can be applied to terminate the use of the second resource pool for transmission.

[1032] If the first condition and possibly the second condition for transmission in the second resource pool are satisfied, the TX WTRU can identify an activation trigger to be sent to the peer WTRU to indicate the activation and monitoring of the second resource pool. The activation trigger can also include conditions that the peer WTRU can apply to terminate the monitoring of the second resource pool. Thus, before transmitting data in the second resource pool and possibly in the first resource pool, the activation trigger for activating the second resource pool is transmitted in the first resource pool. When the second condition is satisfied, the TX WTRU stops the data transmission in the second resource pool and returns to transmission in the first resource pool only.

[1033] The condition for transmitting data in the second resource pool can be one of the following factors or a combination of the following factors:

[1034] - LCP procedure for determining the use of the first resource pool and the second resource pool: For example, after the LCP procedure, the TX WTRU can determine whether the data in the buffer associated with certain LCHs can be combined in a MAC PDU for the grant associated with the first resource pool. If the grant in the first resource pool is not sufficient to accommodate the data in the buffer for the LCHs, and another grant associated with the second resource pool is available for the LCHs, the resources in the grant associated with the first resource pool can be used to transmit the activation trigger in the first resource pool. The grant associated with the second resource pool can then be used to transmit the data in the buffer associated with the LCHs. For example, if the transmission is to be performed using the first resource pool and the second resource pool, the activation trigger is generated and assigned a priority value that is higher than the priority value assigned to the data in all LCHs in the buffer. Next, the activation trigger and the data in certain high priority LCHs can be multiplexed based on the priority order in the grant associated with the first resource pool. The data in the other remaining LCHs can be multiplexed according to the priority order in the grant associated with the second resource pool.

[1035] - Data traffic type (periodic / aperiodic) of the sidelink procedure: For example, if the data traffic type of the sidelink procedure is periodic, where TBs are transmitted to the peer WTRU with a certain periodicity, the TX WTRU can determine that an activation trigger that can match the periodic transmission of data can be possible. The activation trigger can then be transmitted in the first resource pool followed by the transmission of periodic data in the second resource pool. In another example, if the sidelink procedure is aperiodic (e.g., a single transmission or burst transmission of multiple TBs in a short duration), the TX WTRU can determine an activation trigger that can indicate the duration of the second resource pool that will be activated. For example, the activation trigger can be a periodic signal where the periodicity indicates the ON duration of the second resource pool.

[1036] - Packet delay budget (PDB) requirement: For example, after the LCP procedure, the TX WTRU can determine whether the data in the buffer can be transmitted using the grant associated with the first resource pool within the PDB time limit. If the grant in the first resource pool is not sufficient to accommodate the data in the buffer and another grant associated with the second resource pool can satisfy the PDB requirement, the resources in the grant associated with the first resource pool can be used to transmit the activation trigger in the first resource pool. The grant associated with the second resource pool can then be used to transmit the data in the buffer associated with the LCH.

[1037] - Amount of data in the buffer: For example, if the amount of data in the buffer intended for a particular L2 ID is greater than a threshold, the WTRU can transmit the activation trigger in the first pool. The WTRU can transmit some of the data in the first pool and some of the data in the second pool. The WTRU can continue to transmit data in the first pool as long as the data in the buffer is above the threshold.

[1038] The activation trigger that the TX WTRU can transmit in the first resource pool to indicate the activation and monitoring of the second pool can be any of the following:

[1039] - Transmission of a periodic signal with a certain periodicity, where the periodicity can be associated with the rate / frequency of transmitting data for the periodic procedure.

[1040] - Transmission of an explicit command, which can be the following:

[1041] a. A MAC CE, RRC message that can be transmitted with data, which can be transmitted periodically by the peer WTRU.

[1042] b. A new SCI, an explicit indication within the SCI, or a SCI that schedules data in the second pool.

[1043] c. A certain field value in the SCI that is expected to not be received correctly in the first pool.

[1044] The WTRU can determine whether to perform one or any combination of the following in the first resource pool.

[1045] - Establish a sidelink procedure for a semi-persistent reservation.

[1046] - Transmit an explicit indication (e.g., a new SCI, a SCI or MAC CE or RRC message scheduling data in the second resource pool) based on one or any combination of the following:

[1047] a. QoS of the data.

[1048] b. Traffic type of the expected data.

[1049] c. Broadcast type of the data.

[1050] d. CBR of the first resource pool and / or the second resource pool.

[1051] For example, the TX WTRU can send in the activation trigger the type of scheduling mode for using resources in the second pool for the sidelink procedure. Specifically, the TX WTRU can use the activity level of data traffic in the sidelink procedure and possibly other attributes described above in “TX WTRU behavior when communicating with a WTRU, the WTRU can be in active / inactive state” to determine the scheduling information that will be indicated in the first resource pool and thus transmitted in the second resource pool. For a sidelink procedure that can have both periodic and aperiodic (bursty) data arrival, the TX WTRU can monitor the data arrival in the buffer associated with the LCH for a certain duration and determine the scheduling mode that will be indicated in the activation trigger. In this case, if the data arrival in the buffer is regular with a certain duration during the monitoring interval, the TX WTRU can perform the transmission periodically with a certain periodicity. The TX WTRU can indicate in the activation trigger a semi-persistent reservation consisting of a start / offset timing information and a periodicity for accessing the second resource pool. Alternatively, if the data arrives irregularly in the buffer for the monitoring interval, the TX can perform the transmission aperiodically. The TX WTRU can indicate in the activation trigger a dynamic grant consisting of a time slot / subchannel for accessing the second resource pool. Essentially, the TX WTRU can dynamically change the scheduling mode for using the second resource pool (i.e., change the semi-persistent reservation to a dynamic grant and vice versa) based on the variation of data traffic activity.

[1052] In one example, a WTRU can select a TX pool for transmission based on knowledge of the activation status of other RX WTRUs. Specifically, when a WTRU expects one or more WTRUs or all WTRUs to be decoded according to a first RX pool, the WTRU can select a TX pool associated with the first RX pool. When a WTRU expects one or more WTRUs or all WTRUs to be decoded according to a second RX pool, the WTRU can select a TX pool associated with the second RX pool.

[1053] - A WTRU can determine when to use the first TX pool or the second TX pool for transmission based on a "time-related condition", as defined above in the section "TX WTRU behavior when communicating with a WTRU, WTRU can be in active / inactive state", where active resources can be associated with resources of the second RX / TX pool and inactive resources can be associated with the first RX / TX pool.

[1054] a. For example, a TX WTRU can perform transmission using the first TX pool and can start a timer. While such a timer is running, the TX WTRU can transmit using the second TX pool (and possibly also using the first TX pool). The WTRU can reset such a timer after transmission on the second TX pool. Alternatively or additionally, the WTRU can reset such a timer after transmission on the first TX pool. When the timer expires, for any subsequent transmission after the timer expires, the WTRU can transmit on the first pool.

[1055] b. For example, a TX WTRU can perform transmission on the first resource pool periodically or occasionally while performing transmission on the second resource pool. Such transmission can be performed to avoid expiration of a timer at the RX WTRU (i.e., to keep the RX WTRU active on the second resource pool).

[1056] - A WTRU can further constrain transmission on the second pool based on QoS ("quality-related condition"), as defined above in the section "TX WTRU behavior when communicating with a WTRU, WTRU can be in active / inactive state". The WTRU can further customize resource selection and / or LCP for transmission on the second pool.

[1057] (A). WTRU limits transmission on the first resource pool

[1058] A WTRU can be configured to limit transmission in the first resource pool to avoid congestion on the pool and allow multiple WTRUs to use it to reach the WTRU in DRX.

[1059] In one example, a WTRU can have a limit on the number of resources allowed to be used on the first resource pool and / or aperiodic resources. For example, the WTRU can have a limit on any one or a combination of the following on the first resource pool:

[1060] - the number of TX sidelink processes it can use on the first resource pool.

[1061] - the maximum usage (CR) it can have in the first pool.

[1062] - the maximum number of sub-channels it can select for grant in the first pool.

[1063] - the minimum periodicity of transmissions on the first pool.

[1064] Upon reaching any one of these limits, the WTRU can ensure that additional data transmissions that exceed such limits are performed on the second pool.

[1065] In another example, the WTRU can perform transmissions on the first resource pool only during a period of time in which the RX WTRU is assumed to be inactive. After the RX WTRU transitions from an inactive state to an active state, the TX WTRU can be allowed to perform transmissions only on the second resource pool. For example, the TX WTRU can maintain an inactivity timer associated with its transmissions to a peer WTRU. Upon expiration of such timer, the TX WTRU can be allowed to perform transmissions in the first resource pool. Such constraints can further apply to a subset of transmissions (e.g., a subset of LCHs) based on, for example, the QoS of the data associated with such transmissions.

[1066] In another example, which can be used in conjunction with the previous example, the WTRU can use the second pool for lower priority data as long as the resources in the first pool meet the delay requirements of high priority data. Specifically, when the WTRU performs transmissions on the first pool (with the intention of also transmitting on the second pool), the WTRU can constrain LCHs with a certain QoS (e.g., low priority) to only send on the second pool. Such constraints can come into play when the WTRU has any ongoing transmissions in the first pool, which means that it is allowed to transmit on the second pool (as described herein). In addition, such constraints can further come into play when the WTRU has reached any one of the constraints on the first pool described in the previous example. When the conditions that allow the WTRU to transmit on the second pool are not met, all logical channels can be constrained to use the first pool.

[1067] (B). Dynamic changes to the active resource pool only in relation to the WTRU configuration

[1068] In one example implementation, a WTRU can determine that control and / or data are transmitted on resources of a pool (e.g., on resources of the second pool Y) based on a listening procedure. A WTRU can determine that control and / or data are transmitted on resources of a pool (e.g., on resources of the first pool X) based on the presence of control signaling indicating a data transmission associated with a configured V2x session of the WTRU, e.g., only reception or also transmission. In both cases, the transmission performed by the WTRU can be further considered as a transmission of control and / or data, e.g., the WTRU will first perform the listening, then transmit and / or will include control information to indicate the configured session of the WTRU for the purpose of the above logic.

[1069] (C). Dynamic change of resource pool, one dynamic change is for normal operation and one dynamic change is for wake-up

[1070] In another example implementation, a WTRU can determine that control and / or data are transmitted on resources of a pool (e.g., on resources of the second pool Y) based on a listening procedure. A WTRU can determine that control and / or data are transmitted on resources of a pool (e.g., on resources of the first pool X) based on the presence of control signaling indicating a data transmission associated with a configured V2x session of the WTRU, e.g., only reception or also transmission. In both cases, the transmission performed by the WTRU can be further considered as a transmission of control and / or data, e.g., the WTRU will first perform the listening, then transmit and / or will include control information to indicate the configured session of the WTRU for the purpose of the above logic.

[1071] WTRU behavior in the presence of grants associated and not associated with listening

[1072] WTRU grants can have an associated level of listening

[1073] In the presence of grants derived with or without the result of listening and / or with different amount of listening strength / reliability, a WTRU can perform a transmission, which can be to the same or different WTRU and / or be any of unicast, groupcast or broadcast. In particular, a WTRU can have a grant obtained using random selection and another grant obtained using the result of listening. In particular, a WTRU can have a grant obtained using a first level of result of listening and a second grant obtained using a second level of result of listening. The level of result of listening can be determined by any of:

[1074] - the number of resources monitored to derive the result of listening.

[1075] - the number of different periodicities of resources used by the WTRU to monitor PSCCH.

[1076] - the amount of time the WTRU has monitored PSCCH to derive the result of listening.

[1077] - Threshold used for determining resource occupancy when deriving availability.

[1078] - Whether or how much to increase the threshold (e.g., increase by 3 dB) during resource selection in order to obtain an acceptable amount of resources to perform resource selection.

[1079] The WTRU can quantify / indicate / distinguish between a grant with listening or a grant without listening, which can have a given level. Specifically, the PHY layer can indicate to the MAC layer whether a grant is associated with no listening or with listening, which can have a certain level.

[1080] The WTRU selects data for transmission based on the association of the level of listening and the characteristics of the data

[1081] The WTRU can select data for transmission according to the grant depending on the association with listening or level of listening. The WTRU can prioritize certain transmissions for use over transmissions with listening results or with listening results of a certain level. The WTRU can do such prioritization based on any one or a combination of the following:

[1082] - QoS of the data, such as priority, reliability, etc., or any associated parameters in the SLRB / LCH configuration

[1083] a. For example, the WTRU can prioritize the use of a grant with listening results when transmitting with high priority.

[1084] b. For example, the WTRU can prioritize the use of a grant selected at random when transmitting with high priority.

[1085] c. For example, the SLRB / LCH configuration can allow transmitting LCHs according to grants with a certain level of listening or subset of levels.

[1086] - Type of cast of the transmission (unicast, groupcast, broadcast)

[1087] - Whether the transmission is configured with HARQ feedback

[1088] a. For example, the WTRU can allow a transmission with HARQ feedback to be performed using a grant without listening (random selection only).

[1089] - Remaining PDB associated with the transmission

[1090] a. For example, the WTRU can be allowed to use a grant with random selection if the remaining PDB is below a threshold.

[1091] - whether a transmission to a RX WTRU configured in DRX is performed and / or whether such WTRU falls in a scheduled active time

[1092] a. For example, a TX WTRU can use a listen to perform a first transmission to a WTRU in DRX (i.e., to force the WTRU to start its inactivity timer)

[1093] - whether an alternative grant with a listen result is available

[1094] a. For example, if a grant with a listen result is not available to meet the delay requirement of data for transmission, the TX WTRU can transmit data according to a grant with a random selection

[1095] (A) A WTRU is configured with SLRB configurations associated with a listen on LCHs with different listen requirements / configurations and / or LCP constraints

[1096] In one example solution, a WTRU can be configured with LCP constraints to multiplex LCPs with their listen requirements / characteristics. Specifically, a LCH can be configured with specific / required listen characteristics, such as but not limited to:

[1097] - required full listen

[1098] - required (at least) partial listen

[1099] - allowed random selection

[1100] - minimum set of parameters required for listen (e.g., minimum number of listen slots, required values K, k, N, etc. as described herein, etc.)

[1101] - listen level as described herein

[1102] A WTRU performing mode 2 transmission can transmit data according to a grant according to the listen requirements / characteristics defined in the LCH / SLRB configuration. For example, a TX WTRU can transmit its data for a LCH configured with “allowed random selection” according to a grant selected using a random selection. For example, a TX WTRU can only transmit data from a LCH configured with “required full listen” according to a grant selected using a full listen procedure. For example, some LCH configurations (e.g., “allowed random listen”) can be transmitted according to a grant associated with a random selection and a grant associated with partial listen and / or full listen.

[1103] A WTRU can be configured with LCP constraints associated with mapping a specific LCH to a grant associated with different listen characteristics. Specifically, based on the listen characteristics associated with a grant, the grant can allow for a certain LCH but not for other LCHs.

[1104] In an alternative solution, such LCP constraints on the type of listening for grant can be (implicitly) configured based on other parameters configured in the SLRB / LCH configuration and / or measured values at the WTRU. Specifically, such LCP constraints can be based on the following:

[1105] - L2 priority of the LCH or any related QoS parameters,

[1106] - HARQ configuration (e.g., HARQ enabled / disabled) associated with the LCH,

[1107] - and so on.

[1108] Specifically, such LCP constraints can also depend on the following:

[1109] - measured CBR, CSI, RSRP or similar information of the sidelink

[1110] For example, the WTRU can be configured with a priority list that allows the use of randomly selected transmissions. Such priority list can also depend on the measured CBR.

[1111] Interaction between DRX and listening activities

[1112] The WTRU can utilize different behaviors / rules for performing combined monitoring of RX slots / pools for DRX and listening slots / pools

[1113] The WTRU can determine the number of resources in which the WTRU will monitor for sidelink. The WTRU can be configured to monitor a set of resources (in the form of a reception / transmission resource pool or a set or pattern of time / frequency resources within a separate resource pool for monitoring) for any of the following configurations or a combination of the following configurations:

[1114] - each WTRU that has a unicast link, or a group of such WTRUs that have a unicast link.

[1115] - each group or groupcast communication (e.g., configured by upper layers).

[1116] - each L2 ID configured for transmission.

[1117] - each SLRB.

[1118] - each independent configuration of listening resources for resource selection when transmitting to the WTRU or WTRUs, which can be determined through coordination with other WTRUs or selected by the WTRU.

[1119] A WTRU can monitor sidelink on a slot associated with its reception activity behavior and in addition thereto, can monitor sidelink on a slot (or in one or more resource pools) associated with one or more of the above. The WTRU's overall sidelink monitoring can consist of the combination of sidelink resources associated with its RX activity behavior and the listening slots / pools associated with one or more of the above. The WTRU can determine a set of time / frequency resources within the TX resource pool for each of the above. Alternatively, the WTRU can be configured with and / or determine a separate resource pool for each of the above.

[1120] A WTRU can perform listening during its RX activity behavior of its configured RX active time and also collect the listening results. The WTRU can further determine whether it needs to perform additional listening (outside of the RX active time) for transmission to a peer WTRU based on the amount and / or timing of the listening performed during the RX active time. Such determination can be made using the mechanisms described further herein.

[1121] As described further herein, a WTRU can perform monitoring of resources associated with its RX activity behavior that are different from the resources associated with listening (i.e., resources in the TX resource pool or separate resource pool for listening). Specifically, a WTRU can perform monitoring of PSCCH and PSSCH for slots associated with its RX activity behavior, while a WTRU can monitor only PSCCH for slots associated only with listening. Specifically, a WTRU can monitor only SCI1 for slots associated only with listening and can further decode SCI2 only on slots associated with the WTRU's activity behavior (when SCI1 matches the WTRU L1 destination ID). Alternatively, for slots associated with RX activity behavior and slots associated with listening, the WTRU can have different behavior with respect to reception and / or activity behavior (e.g., timers such as an activity timer or other DRX related behavior described herein), such as:

[1122] - The WTRU can assign different priorities to slots (e.g., whereby the priority can be used to decide whether to monitor different carriers, different links (e.g., Uu), etc. on that slot or subsequent / related slots).

[1123] - The WTRU can use different thresholds for detecting SCI.

[1124] - The WTRU monitors different number of frequency resources on that slot.

[1125] a. For example, a WTRU can monitor all resources associated with slots for its RX activity behavior and can monitor only a subset of frequency resources for listening slots.

[1126] -WTRU can use different DRX related timers, such as inactivity timer, on duration timer, etc.

[1127] -WTRU can use different triggers for starting / restarting such timers:

[1128] a. For example, for RX pool, the timer can be triggered by a reception trigger as described above, while for TX pool, the timer can be triggered by a transmission trigger (e.g., arrival of a packet for transmission from upper layers) and / or a listening related trigger (e.g., number of available resources reaches a threshold).

[1129] WTRU can monitor the sidelink associated with its reception activity behavior on the slot and in addition thereto, it can monitor the sidelink associated with one or more of the above on the slot (or in one or more resource pools). The overall sidelink monitoring of the WTRU can consist of the combination of the sidelink resources associated with its RX activity behavior and the listening resources / pools associated with one or more of the above configurations.

[1130] In the following solutions, it is assumed that each configuration associated with listening is in the form of a separate set of time-frequency resources in a TX resource pool. However, the same idea can be applied to the case where each configuration is in the form of a different resource pool and the solution applies to this case as well.

[1131] WTRU activity behavior on the sidelink can be defined by the resources in which the WTRU decodes SCI-2.

[1132] Activity behavior as defined herein can be defined by the resources (slot, subchannel, etc.) in which the WTRU performs decoding of SCI-2. Specifically, a WTRU in DRX or with configured activity behavior can perform SCI-1 decoding on all resources configured in the RX pool. Such WTRU can only perform SCI-2 decoding (associated with SCI-1) on resources defined by the activity behavior (e.g., DRX configuration) as described herein.

[1133] SCI-1 only decoding can be associated with the following WTRU behavior:

[1134] -WTRU can monitor SCI-1 (PSCCH) and store information about the reserved resources and their related priority (i.e., listening result carried in SCI).

[1135] -WTRU can ignore SCI-2 decoding corresponding to any control information decoding of SCI-1 (i.e., not monitor control information in PSSCH). Alternatively, WTRU can ignore SCI-2 decoding but except for specific transmissions in SCI-1, which can be associated with specific content of SCI-1 such as:

[1136] a. A specific value of a reserved field in SCI-1 or a new field created by SCI-1.

[1137] b. A specific value of SCI-2 format.

[1138] c. A specific value of time / frequency allocation in SCI-1.

[1139] d. A specific value of a reservation period in SCI-1.

[1140] WTRU determines resources for partial listening based on DRX / active behavior

[1141] In one solution, a WTRU can be configured to perform partial listening when configured with DRX or reduced PSCCH monitoring behavior (active behavior) as defined herein. The WTRU can further determine resources for partial listening according to the configured active behavior. Specifically, the WTRU can determine resources on which it can perform listening based on the active behavior or a function of the active behavior of the WTRU itself or one or more other WTRUs (e.g., other WTRUs with configured unicast connections). Specifically, the WTRU can perform listening on time slots associated only with the DRX wake-up timer or a number of time slots around the DRX wake-up time or a number of time slots spaced apart by a specific period from the DRX wake-up time, where such number of time slots can further depend on:

[1142] - QoS of any active transmission of data in the WTRU buffer.

[1143] - LCHs or SLRBs configured at the WTRU and / or with data available for transmission.

[1144] - QoS (e.g., priority) of the most recently received data at the WTRU.

[1145] - Measured CBR.

[1146] - WTRU battery power.

[1147] - WTRU type (e.g., pedestrian WTRU, wearable device, etc.) or any capabilities configured at the WTRU.

[1148] For example, a WTRU can determine its partial listen slots (i.e., slots in which the WTRU performs listening) as slots associated with its DRX on-duration. For example, a WTRU can determine its partial listen slots (i.e., slots in which the WTRU performs listening) as slots corresponding to active reception on its currently configured power saving RX resource pool. In particular, a WTRU can determine listen slots as slots in which it needs to collect listening results in order to have sufficient listening results to perform transmission during the active time of the WTRU or a group of WTRUs.

[1149] (A.) WTRU determines slots in the DRX active period of a peer WTRU that it can use for transmission

[1150] A WTRU can first determine slots in the DRX active period of a peer WTRU that it can use for transmission. Such a WTRU can then determine listen slots from the slots in the active period, as further described herein.

[1151] A WTRU can determine the number (e.g., minimum number) of slots and / or the actual slots (subset of slots) in the DRX active period based on any one or a combination of the following:

[1152] - measured CBR:

[1153] a. For example, a WTRU can be configured with a first number of slots that it can use for transmission for a first CBR range, and a second number of slots that it can use for transmission for a second CBR range.

[1154] b. For example, a WTRU can be configured with a plurality of different resource modes (which include the actual number of slots available within the active period of a peer WTRU) and rules for selecting between resource modes according to the measured CBR.

[1155] - whether data can be waiting at a certain time before the start of the active period of a peer WTRU for transmission to the peer WTRU.

[1156] a. For example, a transmitting WTRU can be configured with a first number of slots and / or a configuration of allowed transmission slots to use in the active time of a peer WTRU when the transmitting WTRU has data available in its buffer for transmission to the peer WTRU, and a second number of slots and / or a configuration of allowed transmission slots to use in the active time of a peer WTRU when the transmitting WTRU has data available in its buffer for transmission to the peer WTRU. Such a decision can further be made at a certain time before the start of the active time of a peer WTRU (e.g., a configurable number of slots before).

[1157] b. For example, the transmitting WTRU can not be configured with any slots that allow for transmission in the active period of the peer WTRU and thus does not have an associated resource (possibly associated with that particular peer WTRU) to perform listening to that slot.

[1158] c. For example, the transmitting WTRU can make such determination at a time instance related to the active SLRB at the WTRU.

[1159] (i) For example, the WTRU can be configured with a number of slots prior to the active time for performing such decision, where such number of slots is determined based on the priority of the highest / lowest logical channel.

[1160] - QoS (e.g., priority) of the data to be transmitted and / or SLRB configuration:

[1161] a. For example, the WTRU can be configured with a number of slots or a range of number of slots that it can select based on the QoS of the data that it can transmit to a particular peer WTRU. For example, the WTRU can be configured with a maximum / minimum number / percentage of slots that it can select from within the DRX active period of the peer WTRU in each SLRB configured with such peer WTRU; then, the WTRU will assume the maximum / minimum of the maximum / minimum number of slots configured across all SLRBs for the peer WTRU.

[1162] b. For example, the WTRU can be configured with a resource pattern in the SLRB configuration, where such resource pattern indicates resources within the active period of the peer WTRU that the WTRU can select resources for transmission.

[1163] c. For example, the WTRU can determine the number or pattern of resources in the active time of the peer WTRU based on the QoS / priority of the data waiting at that WTRU for transmission to the peer WTRU. Specifically, the WTRU can determine which slots are in the active time of the peer WTRU or the amount of slots that can be considered for transmission based on the priority of the data arriving at the WTRU at some time prior to the active time (e.g., when the peer WTRU is in DRX and is not reachable).

[1164] - WTRU type (which can be related to WTRU capability, listening capacity, etc.):

[1165] a. For example, the WTRU can determine the number of resources and / or resource pattern in the active period of the peer WTRU based on (possibly partially based on) the configuration of the peer WTRU.

[1166] b. For example, one WTRU type can allow selection of all slots in the ON duration, while another WTRU type can limit the number of slots in the ON duration to a configured number or percentage of slots.

[1167] - the amount of listening results available....

Claims

1. A wireless transmit / receive unit (WTRU), the WTRU comprising: a processor configured to: receive, from a network node, a plurality of discontinuous reception (DRX) configurations, each DRX configuration associated with one or more sets of quality of service (QoS) parameters, each DRX configuration comprising a sidelink (SL) DRX cycle value and a SL on-duration value, the plurality of DRX configurations associated with SL broadcast and / or groupcast transmissions; in a case where a plurality of SL DRX cycle values are associated with a 2nd destination layer ID, wherein the plurality of SL DRX cycle values are included in the received plurality of DRX configurations associated with the one or more sets of QoS parameters, select a minimum SL DRX cycle value from the plurality of SL DRX cycle values associated with the 2nd destination layer ID; in a case where a plurality of SL on-duration values are associated with the 2nd destination layer ID, wherein the plurality of SL on-duration values are included in the received plurality of DRX configurations associated with the one or more sets of QoS parameters, select a maximum SL on-duration value from the plurality of SL on-duration values associated with the 2nd destination layer ID; and monitor the sidelink based on the selected SL DRX cycle value and the selected SL on-duration value.

2. The WTRU of claim 1, wherein the plurality of DRX configurations are received from the network node in a system information block (SIB).

3. The WTRU of claim 1, wherein each DRX configuration comprises a SL inactivity timer value.

4. The WTRU of claim 1, wherein the processor is further configured to: in a case where a plurality of SL inactivity timer values are associated with the 2nd destination layer ID, wherein the plurality of SL inactivity timer values are included in the received plurality of DRX configurations associated with the one or more sets of QoS parameters, select a maximum SL inactivity timer value from the plurality of SL inactivity timer values associated with the 2nd destination layer ID; and monitor the sidelink based on the selected SL inactivity timer value.

5. The WTRU of claim 1, wherein the one or more sets of QoS parameters comprise a PC5 QoS identifier (PQI).

6. The WTRU of claim 1, wherein the one or more sets of QoS parameters comprise a range value.

7. The WTRU of claim 1, wherein the processor is configured to: receive data via the sidelink during an active time determined based on the selected SL DRX cycle value and the selected SL on-duration value.

8. The WTRU of claim 7, wherein the data received via the sidelink during the active time comprises physical sidelink control channel (PSCCH) transmissions and physical sidelink shared channel (PSSCH) transmissions associated with the 2nd destination layer ID. ​ 9. The WTRU of claim 1, wherein the plurality of DRX configurations are received from the network node in a radio resource control (RRC) message.

10. The WTRU of claim 1, wherein the processor is further configured to: receive configuration information indicating that the WTRU is to monitor for synchronization (sync) transmissions sent from a plurality of peer WTRUs; select a synchronization source based on the sync transmissions sent from the plurality of peer WTRUs; determine an active state configuration based on the selected synchronization source, wherein the active state configuration is determined based on a timing of a received physical sidelink broadcast channel (PSBCH) transmission from the selected synchronization source and information provided in the PSBCH transmission from the selected synchronization source, wherein the information provided in the PSBCH transmission includes an indication of an active period; and determine a slot to start an on period relative to a slot in which the PSBCH transmission from the selected synchronization source is received; and wake up in the determined slot to start the on period.

11. A method implemented by a wireless transmit / receive unit (WTRU), the method comprising: receiving, from a network node, a plurality of discontinuous reception (DRX) configurations, each DRX configuration associated with one or more sets of quality of service (QoS) parameters, each DRX configuration including a sidelink (SL) DRX cycle value and a SL on duration value, the plurality of DRX configurations associated with SL broadcast and / or groupcast transmissions; selecting, in response to a plurality of SL DRX cycle values being associated with a 2nd destination layer ID, a minimum SL DRX cycle value from the plurality of SL DRX cycle values associated with the 2nd destination layer ID, wherein the plurality of SL DRX cycle values are included in the received plurality of DRX configurations associated with the one or more sets of QoS parameters; selecting, in response to a plurality of SL on duration values being associated with the 2nd destination layer ID, a maximum SL on duration value from the plurality of SL on duration values associated with the 2nd destination layer ID, wherein the plurality of SL on duration values are included in the received plurality of DRX configurations associated with the one or more sets of QoS parameters; and monitoring the sidelink based on the selected SL DRX cycle value and the selected SL on duration value.

12. The method of claim 11, wherein the plurality of DRX configurations are received from the network node in a system information block (SIB).

13. The method of claim 11, wherein each DRX configuration includes a SL inactivity timer value.

14. The method of claim 11, further comprising: selecting, in response to a plurality of SL inactivity timer values being associated with the 2nd destination layer ID, a maximum SL inactivity timer value from the plurality of SL inactivity timer values associated with the 2nd destination layer ID, wherein the plurality of SL inactivity timer values are included in the received plurality of DRX configurations associated with the one or more sets of QoS parameters; and monitor the sidelink based on the selected SL inactivity timer value.

15. The method of claim 11, wherein the one or more sets of QoS parameters comprise a PC5 QoS identifier (PQI).

16. The method of claim 11, wherein the one or more sets of QoS parameters comprise a range value.

17. The method of claim 11, further comprising: receiving data via the sidelink during an active time determined based on the selected SL DRX cycle value and the selected SL on duration value.

18. The method of claim 17, wherein the data received via the sidelink during the active time comprises physical sidelink control channel (PSCCH) transmissions and physical sidelink shared channel (PSSCH) transmissions associated with the 2nd destination layer ID.

19. The method of claim 11, wherein the plurality of DRX configurations are received from the network node in a radio resource control (RRC) message.

20. The method of claim 11, further comprising: receiving configuration information indicating that the WTRU is to monitor for synchronization (sync) transmissions sent from a plurality of peer WTRUs; selecting a synchronization source based on the sync transmissions sent from the plurality of peer WTRUs; determining an active state configuration based on the selected synchronization source, wherein the active state configuration is determined based on a timing of a received physical sidelink broadcast channel (PSBCH) transmission from the selected synchronization source and information provided in the PSBCH transmission from the selected synchronization source, wherein the information provided in the PSBCH transmission comprises an indication of an active period; and determining a slot to start an on period relative to a slot in which the PSBCH transmission from the selected synchronization source is received; and waking up in the determined slot to start the on period.

Images