Partially Sensitive Resource Allocation

Abstract

This invention provides a wireless transmit / receive unit (WTRU) and method for partial sensing-based resource allocation. [Solution] Tx WTRU receives configuration information indicating parameters. It associates the parameters with resource selection. Tx WTRU determines first and second resource selection windows. It associates the first resource selection window with the active time of Rx WTRU. It associates the second resource selection window with the inactive time of Rx WTRU. Tx WTRU determines the first number of candidate resources associated with the first resource selection window. Tx WTRU determines the first number of candidate resources associated with the second resource selection window. In the example, Tx WTRU increments the first number of candidate resources associated with the first resource selection window to the second number of candidate resources associated with the first resource selection window.

Description

Technical Field

[0001] (Cross - Reference to Related Applications) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 168,052, filed Mar. 30, 2021; U.S. Provisional Patent Application No. 63 / 185,675, filed May 7, 2021; U.S. Provisional Patent Application No. 63 / 228,812, filed Aug. 3, 2021; U.S. Provisional Patent Application No. 63 / 249,384, filed Sep. 28, 2021; and U.S. Provisional Patent Application No. 63 / 275,212, filed Nov. 3, 2021, the disclosures of which are hereby incorporated herein by reference in their entireties.

Background Art

[0002] Device - to - device (D2D) communication and vehicle - to - everything (V2X) communication may enable a wireless transmit / receive unit (WTRU) to communicate directly, e.g., via a PC5 interface. Coverage - in and coverage - out modes of D2D and V2X communication may be provided. However, current mechanisms for D2D communication and V2X communication may not be suitable in some V2X - based use cases.

Summary of the Invention

[0003] The transmitting wireless transmitter / receiver unit (Tx WTRU) can receive configuration information indicating one or more parameters. These parameters may be associated with resource selection. The Tx WTRU can determine a first resource selection window and a second resource selection window. The first resource selection window may be associated with the active time of the receiving wireless transmitter / receiver unit (Rx WTRU). The second resource selection window may be associated with the inactive time of the Rx WTRU. The Tx WTRU can determine a first number of candidate resources associated with the first resource selection window. The Tx WTRU can determine a first number of candidate resources associated with the second resource selection window. In some examples, the Tx WTRU can increase the first number of candidate resources associated with the first resource selection window to a second number of candidate resources associated with the first resource selection window. The second number of candidate resources associated with the first resource selection window may exceed a resource threshold (e.g., the first resource threshold). A Tx WTRU may select one or more (re)transmit resources. The selected one or more (re)transmit resources may be from the second number of candidate resources associated with the first resource selection window. The number of selected one or more (re)transmit resources may be based on the second number of candidate resources associated with the first resource selection window. Instructions for one or more selected (re)transmit resources may be sent, and the Tx WTRU may send data on one or more selected (re)transmit resources.

[0004] A Tx WTRU can select resources for transmission to another WTRU, which may be, for example, an Rx WTRU (e.g., a DRX Rx WTRU). A Tx WTRU can select a resource selection trigger time (e.g., slot n before the start of the resource selection window) such that the resource selection window contains at least a certain number of active slots of the Rx WTRU (e.g., a (pre-configured) number of active slots of the Rx WTRU). If a Tx WTRU cannot find a trigger time that satisfies the condition that the number of active slots of the Rx WTRU in the resource selection window is greater than a threshold, the Tx WTRU can drop the transport block (TB) and / or select another resource pool for transmission of the TB.

[0005] A Tx WTRU can select a set of candidate slots. The Tx WTRU can select a set of candidate slots within the resource selection window. The set of candidate slots may include at least a certain number of active slots of the Rx WTRU (for example, a (pre-configured) number of active slots of the Rx WTRU). The number of active slots of the Rx WTRU may, for example, be placed at the beginning of the set of candidate slots in terms of time.

[0006] The Tx WTRU can determine the set of selectable resources, for example, by excluding unavailable resources. The Tx WTRU can increase the number of selectable resources if the number of selectable resources in the set of active slots of the Rx WTRU is less than a threshold (e.g., a (pre-configured) threshold) and / or the percentage of selectable resources in the set of candidate slots is less than a threshold (e.g., another threshold). For example, the Tx WTRU can increase the reference signal received power (RSRP) threshold (for example, to determine the availability of resources in the set of candidate slots) if the number of selectable resources in the set of active slots of the Rx WTRU is less than a threshold (e.g., a (pre-configured) threshold) and / or the percentage of selectable resources in the set of candidate slots is less than a threshold (e.g., another threshold).

[0007] A Tx WTRU can select a transmission resource from a set of selectable resources for sending a transport block (TB). The transmission resource may be within the Rx WTRU's active time and within a range (e.g., a pre-configured range, such as greater than a first threshold and less than a second threshold). The WTRU can then perform the transmission of the TB using the selected set of transmission resources.

[0008] The Tx WTRU performs congestion control on the DRX. The Tx WTRU can perform a CBR_drx measurement to determine the congestion level of resources associated with the configuration of the DRX of the TB's Tx WTRU or the Rx WTRU's DRX. The Tx WTRU can determine an acceptable set of resource selection trigger times (e.g., a set of n values) based on one or more of the TB's quality of service, CBR_drx, or the resource pool's channel busy ratio (CBR). The Tx WTRU can select a resource selection trigger time from the acceptable set (e.g., randomly).

[0009] A Tx WTRU can perform sensing to detect periodic resource reservations. A Tx WTRU can (pre-configure) a set of reservation intervals, perform sensing (e.g., for periodic sensing and / or detection of periodic reservations), and / or extract sensing results. A Tx WTRU can determine a subset of reservation intervals based on the traffic type (e.g., whether the WTRU performs periodic reservations for selected resources) and / or the QoS of the TB. If a Tx WTRU performs periodic reservations for selected resources, it can sense and / or extract sensing results from (pre-configured) reservation periods (e.g., each of the pre-configured reservation periods). If a Tx WTRU does not perform periodic reservations, it can determine a set of reservation periods for sensing and / or extracting sensing results based on the QoS of the TB. [Brief explanation of the drawing]

[0010] [Figure 1A] This is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] This is a system diagram illustrating an exemplary wireless transmit / receive unit (WTRU) that may be used in a communication system illustrated in Figure 1A, according to one embodiment. [Figure 1C]This is a system diagram illustrating an exemplary radio access network (RAN) and an exemplary core network (CN) that may be used in a communication system illustrated in Figure 1A according to one embodiment. [Figure 1D] This is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used in the communication system illustrated in Figure 1A according to one embodiment. [Figure 2] This shows an example of establishing a secure Layer 2 link via a PC5 interface. [Figure 3] This displays the resource selection window for the transport block (TB) associated with the wireless transmit / receive unit (WTRU). [Figure 4] This shows an exemplary reference signal received power (RSRP) threshold increment for resource selection. [Figure 5] An exemplary periodic sensing scenario is shown. [Figure 6] This section presents various examples of sensing associated with different types of TB. [Figure 7] Here's an example of a WTRU that determines whether to trigger resource allocation before a potential set of candidate slots. [Figure 8] This shows an exemplary selection of selectable slots outside the set of candidate slots. [Figure 9] This shows an example of a WTRU that initializes the set of selectable slots. [Figure 10] An example of a WTRU for determining the short-term partial sensing window is shown. [Figure 11] This indicates the WTRU (Wait Time Unit) during which resource reevaluation or preemption of a resource is performed in time slot m. [Modes for carrying out the invention]

[0011] Figure 1A shows an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, message transmission, and broadcast to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 may use 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 filtering OFDM, and filter bank multicarrier (FBMC).

[0012] As shown in Figure 1A, the communication system 100 may include radio transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, but it will be understood that the disclosed embodiments intend any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a radio environment. For example, WTRU102a, 102b, 102c, and 102d, any of which may be referred to as “station” and / or “STA”, may be configured to transmit and / or receive radio signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscriber-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, radio sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other radio devices operating in an industrial and / or automated processing chain context), consumer electronics devices, and devices operating in commercial and / or industrial radio networks. Any of WTRU102a, 102b, 102c, and 102d may interchangeably be referred to as UE.

[0013] The communication system 100 may also include base stations 114a and / or base stations 114b. Each of the base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106 / 115, the Internet 110, and / or other networks 112. As an example, base stations 114a and 114b may be base transceiver stations (BTS), Node-B, eNode-B, Home Node-B, Home eNode-B, gNB, NR Node-B, site controller, access point (AP), wireless router, etc. Although base stations 114a and 114b are shown as single elements, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0014] Base station 114a can be part of RAN 104 / 113 and can also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. Base station 114a and / or base station 114b can be configured to transmit and / or receive radio signals at one or more carrier frequencies, which can be referred to as a cell (not shown). These frequencies can be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. The cell can provide wireless service coverage to a specific geographic area that can be relatively fixed or can change over time. The cell can be further divided into cell sectors. For example, the cell associated with base station 114a can be divided into three sectors. Thus, in one embodiment, base station 114a can include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, base station 114a can use multiple-input multiple-output (MIMO) technology and can utilize multiple transceivers for each sector of the cell. For example, beamforming can be used to transmit and / or receive signals in a desired spatial direction.

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

[0016] More specifically, as described above, the communication system 100 may be a multiple access system and may use one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 / 113 may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish air interfaces 115 / 116 / 117 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink Packet Access (HSDPA) and / or High-Speed ​​UL Packet Access (HSUPA).

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

[0018] In one embodiment, base stations 114a and WTRUs 102a, 102b, and 102c can implement radio technologies such as NR radio access, which can establish an air interface 116 using New Radio (NR).

[0019] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Thus, the air interfaces utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies transmitted to / from multiple types of base stations (e.g., eNBs and gNBs) and / or transmissions.

[0020] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c may implement wireless technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, 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), etc.

[0021] The base station 114b in Figure 1A may be, for example, a wireless router, Home Node B, Home eNode B, or access point, and any suitable RAT may be used to facilitate wireless connectivity in local areas such as offices, homes, vehicles, campuses, industrial facilities, aerial corridors (for use by drones), roads, etc. In one embodiment, the base station 114b and WTRU 102c, 102d may implement wireless technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and WTRU 102c, 102d may implement wireless technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base stations 114b and WTRUs 102c, 102d may establish picocells or femtocells using cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As shown in Figure 1A, base station 114b may have a direct connection to the internet 110. Therefore, base station 114b may not need to access the internet 110 via CN 106 / 115.

[0022] RAN104 / 113 can communicate with CN106 / 115, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU102a, 102b, 102c, and 102d. The data may have various quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements. CN106 / 115 may provide call control, billing services, mobile location-based services, prepaid calls, internet connectivity, video distribution, etc., and / or perform high-level security functions such as user authentication. Although not shown in Figure 1A, it will be understood that RAN104 / 113 and / or CN106 / 115 may communicate directly or indirectly with other RANs employing the same RAT as RAN104 / 113 or different RATs. For example, in addition to being connected to RAN104 / 113 which can utilize NR radio technology, CN106 / 115 may also communicate with another RAN (not shown) using GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0023] CN106 / 115 may also function as a gateway for WTRU102a, 102b, 102c, 102d to access PSTN108, the Internet 110, and / or other networks 112. PSTN108 may include a public switched telephone network providing plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices, where these networks and devices use common communication protocols such as the transmission control protocol (TCP), the user datagram protocol (UDP), and / or the Internet protocol (IP) of the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may employ the same RAT as RAN104 / 113 or a different RAT.

[0024] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multimode capability (for example, WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different radio networks via different radio links). For example, WTRU 102c shown in Figure 1A may be configured to communicate with base station 114a, which may use cellular-based radio technology, and base station 114b, which may use IEEE 802 radio technology.

[0025] Figure 1B is a system diagram showing an exemplary WTRU102. As shown in Figure 1B, the WTRU102 may include, among other things, 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 supply 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be understood that the WTRU102 may include any partial combination of the aforementioned elements while maintaining consistency with one embodiment.

[0026] The processor 118 may be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may 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 may be coupled to a transceiver 120 which may be coupled to a transmit / receive element 122. Figure 1B shows the processor 118 and transceiver 120 as separate components, but it will be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

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

[0028] Although the transmit / receive element 122 is shown as a single element in Figure 1B, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may utilize MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving radio signals via the air interface 116.

[0029] The transceiver 120 may be configured to modulate the signal transmitted by the transmit / receive element 122 and demodulate the signal received by the transmit / receive element 122. As described above, the WTRU 102 may have multimode capability. Therefore, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

[0030] The processor 118 of the WTRU102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit) and may receive user input from these. The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from any type of suitable memory, such as non-removable memory 130 and / or removable memory 132, and store data in such memory. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may 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 may access information from memory not physically located on the WTRU 102, such as on a server or home computer (not shown), and store data in such memory.

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

[0032] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 may acquire location information by any preferred location determination method while maintaining consistency with one embodiment.

[0033] The processor 118 may be further coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, and the like. The peripheral device 138 may include one or more sensors, which may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, compass sensor, proximity sensor, temperature sensor, time sensor, geolocation sensor, altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor, and / or humidity sensor.

[0034] WTRU102 may include a full-duplex radio in which the transmission and reception of some or all of the signals (e.g., associated with specific subframes for both UL (e.g., transmission) and downlink (e.g., reception) may be in parallel and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference either through hardware (e.g., chokes) or signal processing via a processor (e.g., via a separate processor (not shown) or processor 118). In one embodiment, WRTU102 may include a half-duplex radio for the transmission and reception of any of the signals (e.g., associated with specific subframes for either UL (e.g., transmission) or downlink (e.g., reception)).

[0035] Figure 1C is a system diagram illustrating RAN104 and CN106 according to one embodiment. As described above, RAN104 can communicate with WTRU102a, 102b, and 102c via the air interface 116 using E-UTRA wireless technology. RAN104 can also communicate with CN106.

[0036] RAN104 may include eNode-B160a, 160b, and 160c, but it will be understood that RAN104 may include any number of eNode-B while maintaining consistency with one embodiment. Each of eNode-B160a, 160b, and 160c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, eNode-B160a, 160b, and 160c may implement MIMO technology. Thus, eNode-B160a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU102a.

[0037] Each of the eNode-B160a, 160b, and 160c may be associated with a specific cell (not shown) and may be configured to handle wireless resource management decisions, handover decisions, user scheduling, etc., in UL and / or DL. As shown in Figure 1C, the eNode-B160a, 160b, and 160c may communicate with each other via the X2 interface.

[0038] The CN106 shown in Figure 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. Although each of the aforementioned elements is shown as part of CN106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0039] The MME162 can be connected to each of the eNode-B162a, 162b, and 162c in RAN104 via the S1 interface and can function as a control node. For example, the MME162 may perform roles such as authenticating users of WTRU102a, 102b, and 102c, activating / deactivating bearers, and selecting gateways for specific services during the initial attachment of WTRU102a, 102b, and 102c. The MME162 may provide control plane functionality for switching between RAN104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0040] The SGW164 can be connected to each of the eNode-B160a, 160b, and 160c in RAN104 via the S1 interface. The SGW164 can generally route and forward user data packets to and from WTRU102a, 102b, and 102c. The SGW164 can also perform other functions, such as anchoring the user plane during eNode B handovers, triggering paging when DL data is available to WTRU102a, 102b, and 102c, and managing and remembering the context of WTRU102a, 102b, and 102c.

[0041] SGW164 may be connected to PGW166, which may provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices.

[0042] CN106 can facilitate communication with other networks. For example, CN106 can provide WTRU102a, 102b, and 102c with access to a circuit-switched network such as PSTN108 to facilitate communication between WTRU102a, 102b, and 102c and conventional terrestrial line communication devices. For example, CN106 may include, or communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that functions as an interface between CN106 and PSTN108. In addition, CN106 may provide WTRU102a, 102b, and 102c with access to another network 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0043] Although the WTRU is shown as a wireless terminal in Figures 1A to 1D, in certain representative embodiments, such a terminal is intended to be able to use a wired communication interface (e.g., temporary or permanent) with a communication network.

[0044] In a typical embodiment, the other network 112 may be a WLAN.

[0045] A WLAN in Infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) of the BSS and one or more stations (STAs) associated with the AP. The AP may have access to or interfaces with another type of wired / wireless network that carries traffic entering and / or leaving the Distribution System (DS) or BSS. Traffic originating outside the BSS and destined for the STA may reach and be delivered to the STA via the AP. Traffic originating from the STA to destinations outside the BSS may be sent to the AP and then delivered to their respective destinations. Traffic between STAs within the BSS may be transmitted, for example, via the AP; a source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be transmitted between a source STA and a destination STA (for example, directly between them) in a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using Independent BSS (IBSS) mode may not have APs, and STAs within or using IBSS (e.g., all STAs) may communicate directly with each other. The IBSS mode of communication may be referred to herein as “ad hoc” communication mode.

[0046] When using the 802.11ac infrastructure operating mode or a similar operating mode, an AP may transmit beacons on a fixed channel, such as the primary channel. The primary channel may be of a fixed width (e.g., a 20 MHz bandwidth) or a width dynamically set via signaling. The primary channel may be the operating channel of the BSS and may be used by the STA to establish a connection with the AP. In certain typical embodiments, for example, in an 802.11 system, Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) may be implemented. In the case of CSMA / CA, the STA, including the AP (e.g., all STAs), may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, that STA may be backed off. A single STA (e.g., only one station) may transmit at any given time on a given BSS.

[0047] High-throughput (HT) STAs may use a 40 MHz wide channel for communication, which may be formed, for example, through a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels.

[0048] Very High Throughput (VHT) STAs may support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. The 40 MHz and / or 80 MHz channels mentioned above may be formed by combining multiple consecutive 20 MHz channels. A 160 MHz channel may be formed by combining eight consecutive 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. In the 80+80 configuration, after channel coding, the data may pass through a segment parser that can split the data into two streams. Inverse Fast Fourier Transform (IFFT) and time-domain processing may be performed separately for each stream. The streams may be mapped to two 80 MHz channels, and the data may be transmitted by a transmitting STA. At the receiver of a receiving STA, the operation described above for the 80+80 configuration may be reversed, and the combined data may be transmitted to Medium Access Control (MAC).

[0049] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using the non-TVWS spectrum. According to a typical embodiment, 802.11ah may support meter-type control / machine-type communications, such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, including support for specific and / or limited bandwidths (e.g., support only for that). MTC devices may include batteries with battery life exceeding a threshold (e.g., to maintain very long battery life).

[0050] A WLAN system capable of supporting multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah includes a channel that can be designated as the primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by an STA from among all STAs operating in a BSS that support the minimum bandwidth operating mode. In the 802.11ah example, the primary channel may be 1 MHz wide for an STA (e.g., an MTC type device) that supports (e.g., only) the 1 MHz mode, even if other STAs in the AP and BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) settings may depend on the state of the primary channel. For example, if the primary channel is busy due to an STA (which only supports 1MHz operating mode) transmitting to the AP, a large portion of the frequency band may remain idle and could be considered busy, even if it were available.

[0051] In the United States, the available frequency band that can be used by 802.11ah is 902MHz to 928MHz. In South Korea, the available frequency band is 917.5MHz to 923.5MHz. In Japan, the available frequency band is 916.5MHz to 927.5MHz. The total bandwidth available for 802.11ah is 6MHz to 26MHz, depending on the country code.

[0052] Figure 1D is a system diagram illustrating RAN113 and CN115 according to one embodiment. As described above, RAN113 can communicate with WTRU102a, 102b, and 102c via the air interface 116 using NR radio technology. RAN113 can also communicate with CN115.

[0053] RAN113 may include gNB180a, 180b, and 180c, but it will be understood that RAN113 may include any number of gNBs while maintaining consistency with one embodiment. Each of gNB180a, 180b, and 180c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, gNB180a, 180b, and 180c may implement MIMO technology. For example, gNB180a and 108b may use beamforming to transmit and / or receive signals to gNB180a, 180b, and 180c. Thus, gNB180a may, for example, use multiple antennas to transmit and / or receive radio signals from WTRU102a. In one embodiment, gNB180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB180a may transmit multiple component carriers to WTRU102a (not shown). A subset of these component carriers may be on the unauthorized spectrum, and the remaining component carriers may be on the authorized spectrum. In one embodiment, gNB180a, 180b, and 180c may implement coordinated multi-point (CoMP) technology. For example, WTRU102a may receive coordinated transmissions from gNB180a and gNB180b (and / or gNB180c).

[0054] WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using transmissions associated with scalable numerology. For example, OFDM symbol intervals and / or OFDM subcarrier intervals may vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of varying or scalable lengths (e.g., containing varying numbers of OFDM symbols and / or having varying absolute time durations).

[0055] gNB180a, 180b, and 180c can be configured to communicate with WTRU102a, 102b, and 102c in standalone and / or non-standalone configurations. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c without accessing other RANs (e.g., eNode-B160a, 160b, and 160c). In a standalone configuration, WTRU102a, 102b, and 102c can utilize one or more of gNB180a, 180b, and 180c as mobility anchor points. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using signals in unlicensed bands. In a non-standalone configuration, WTRU102a, 102b, and 102c can communicate with and connect to gNB180a, 180b, and 180c, while also communicating with and connecting to other RANs such as eNode-B160a, 160b, and 160c. For example, WTRU102a, 102b, and 102c can implement DC principles for substantially simultaneous communication with one or more gNB180a, 180b, and 180c and one or more eNode-B160a, 160b, and 160c. In a non-standalone configuration, eNode-B160a, 160b, and 160c can function as mobility anchors for WTRU102a, 102b, and 102c, while gNB180a, 180b, and 180c can provide additional coverage and / or throughput to service WTRU102a, 102b, and 102c.

[0056] Each of the gNB180a, 180b, and 180c may be associated with a specific cell (not shown) and may be configured to handle wireless resource management decisions, handover decisions, user scheduling in UL and / or DL, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a and 182b, and so on. As shown in Figure 1D, the gNB180a, 180b, and 180c may communicate with each other via the Xn interface.

[0057] The CN115 shown in Figure 1D may include at least one AMF182a, 182b, at least one UPF184a, 184b, at least one Session Management Function (SMF)183a, 183b, and optionally a Data Network (DN)185a, 185b. Although each of the aforementioned elements is shown as part of the CN115, it will be understood that any of these elements may be owned and / or operated by entities other than the CN operator.

[0058] AMF182a and 182b can be connected to one or more gNB180a, 180b, and 180c in RAN113 via the N2 interface and can function as control nodes. For example, AMF182a and 182b can perform roles such as user authentication for WTRU102a, 102b, and 102c, support network slicing (e.g., handling different PDU sessions with different requirements), selection of specific SMF183a and 183b, management of registration areas, termination of NAS signaling, and mobility management. Network slices may be used by AMF182a and 182b to customize CN support for WTRU102a, 102b, and 102c based on the type of service utilizing WTRU102a, 102b, and 102c. For example, different network slices may be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, and / or similar. AMF162 may provide control plane functionality for switching between RAN113 and other RANs (not shown) employing other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0059] SMF183a and 183b can be connected to AMF182a and 182b in CN115 via the N11 interface. SMF183a and 183b can also be connected to UPF184a and 184b in CN115 via the N4 interface. SMF183a and 183b can select and control UPF184a and 184b and configure the routing of traffic through UPF184a and 184b. SMF183a and 183b can perform other functions such as managing and assigning UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0060] UPF184a and 184b may be connected via the N3 interface to one or more gNB180a, 180b, and 180c in RAN113, thereby providing WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices. UPF184 and 184b may perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

[0061] CN115 can facilitate communication with other networks. For example, CN115 may include, or communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that functions as an interface between CN115 and PSTN108. In addition, CN115 may provide WTRU102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRU102a, 102b, 102c may be connected to local data networks (DN) 185a, 185b via UPF184a, 184b through an N3 interface to UPF184a, 184b, and an N6 interface between UPF184a, 184b and DN185a, 185b.

[0062] As can be seen from Figures 1A to 1D and their corresponding descriptions, one or more of the functions described herein relating to one or more of the WTRU102a to d, base stations 114a to b, eNode-B160a to c, MME162, SGW164, PGW166, gNB180a to c, AMF182a to b, UPF184a to b, SMF183a to b, DN185a to b, and / or any other devices described herein may be implemented by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0063] Emulation devices may be designed to implement testing of one or more other devices in a laboratory and / or operator network environment. For example, one or more emulation devices may perform one or more or all functions while fully or partially implemented and / or deployed as part of a wired and / or wireless network to test other devices in a communications network. One or more emulation devices may perform one or more or all functions while temporarily implemented / deployed as part of a wired and / or wireless network. Emulation devices may be directly coupled to another device for testing purposes and / or may perform testing using terrestrial radio communication.

[0064] One or more emulation devices may perform one or more functions, including all of the above, while not implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device may be used in a test laboratory test scenario, and / or in a wired and / or wireless communication network that is not deployed (e.g., for testing purposes), to implement testing of one or more components. One or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation device to transmit and / or receive data.

[0065] Vehicle communication is a communication mode that may include multiple WTRUs communicating with each other. WTRUs can communicate directly, for example, via a PC5 interface (e.g., a side-link interface). Vehicle communication can utilize vehicle-to-everything (V2X) communication for WTRUs to communicate. V2X communication between WTRUs can operate in in-coverage mode or out-of-coverage mode. Operating in in-coverage mode may include one or more V2X WTRUs receiving assistance from a network node that enables the V2X WTRUs to send and / or receive V2X messages. In out-of-coverage mode, V2X WTRUs may be pre-configured with parameters that enable the V2X WTRUs to send and / or receive V2X messages.

[0066] V2X communication may be based on device-to-device (D2D) communication. A V2X communication service may include one or more of the following: vehicle-to-vehicle (V2V) communication where vehicle WTRUs can communicate directly with each other; vehicle-to-infrastructure (V2I) communication where vehicle WTRUs can communicate with one or more roadside units (RSUs) and / or one or more base stations (e.g., eNBs or gNBs); vehicle-to-network (V2N) communication where vehicle WTRUs can communicate with a core network; and / or vehicle-to-pedestrian (V2P) communication where vehicle WTRUs can communicate with other WTRUs under special conditions, such as low battery capacity.

[0067] NR V2X access technology systems may support use cases including, for example, enhanced mobile broadband (eMBB) and ultra-high reliability and low latency communications (URLLC). Enhanced V2X (eV2X) communications may be supported by NR-based systems. eV2X may provide services for safe and / or non-safe scenarios (e.g., sensor sharing, autonomous driving, vehicle platooning, remote driving, etc.). The performance of eV2X services may have latency of, for example, around 3ms.

[0068] NR V2X can support one or more of the following use cases, namely vehicle platooning, advanced driving, enhanced sensors, and remote driving.

[0069] Vehicle platooning can allow multiple vehicles to dynamically form a group, enabling the vehicles in the platoon to travel together. Vehicles in the platoon can receive data (e.g., periodic data) from the lead vehicle in the platoon. This data may enable the vehicles to platoon. The data may also enable the vehicles in the platoon to adjust the distance between them. For example, the distance between vehicles may be small. In some examples, the gap distance between vehicles when converted to time may be small (e.g., less than one second). Platooning applications may also enable vehicles that are part of the platoon to be driven autonomously.

[0070] Advanced driving may enable semi-autonomous or fully autonomous driving. Longer following distances may be assumed. One or more vehicles and / or RSUs (e.g., each vehicle and / or RSU) may share data obtained from their local sensors with nearby vehicles, which may allow the vehicles to adjust their trajectories and / or steering. In some examples, a vehicle may share its driving information with other nearby vehicles. Sharing driving information by a vehicle with other nearby vehicles in this way may enable safer driving, collision avoidance, and / or improved traffic efficiency.

[0071] Extended sensors may enable the exchange of raw and / or processed data collected via local sensors, as well as data collected from video devices (e.g., cameras), with other vehicles, RSUs, pedestrian devices, and / or V2X application servers. Such data sharing among vehicles, RSUs, pedestrian devices, and / or V2X application servers can improve environmental awareness beyond what their own sensors can detect. Such data sharing may enable vehicles or other devices to have a more holistic view of the local situation.

[0072] Remote driving can enable remote drivers and / or V2X applications to operate passenger vehicles that they themselves cannot drive, and / or remote vehicles deployed in hazardous environments. Cloud computing-based driving may be used in situations with little variability and predictable routes, such as public transport. In some examples, access to a cloud-based backend service platform may be considered for this set of use cases.

[0073] QoS may be provided for NR V2X communication. For example, QoS on PC5 may be supported using application-associated ProSe packet-per-packet priority (PPPP). The application layer may mark packets using PPPP. PPPP can indicate the QoS level to be used. In some examples, a packet delay metric (e.g., packet delay budget, PDB) may be derived from PPPP.

[0074] One or more QoS key performance indicators (KPIs) may be provided along with one or more of the following parameters: payload (e.g., in bytes), transmission rate (e.g., messages / second); maximum end-to-end latency (e.g., in milliseconds); reliability (e.g., as a percentage); data rate (e.g., in megabits per second (Mbps)); or minimum communication range (e.g., in meters).

[0075] A set of service requirements can be applied to PC5-based V2X communications and / or Uu-based V2X communications. QoS characteristics can be represented by NR QoS identifiers (5QI). A unified QoS model may be provided for PC5 and / or Uu. 5QI can be used for V2X communications over PC5 so that the application layer of a WTRU can have a consistent mechanism for indicating QoS requirements, for example, regardless of the link used.

[0076] A V2X-enabled WTRU can support different types of traffic, namely broadcast, multicast, and / or unicast. For unicast traffic, the Uu QoS model can be used. For example, a unicast link (e.g., each of the unicast links) may be designated as a bearer. One or more QoS flows may be associated with a unicast link (e.g., each of the unicast links). QoS characteristics and parameters defined in 5QI (e.g., data rate) may be applied. A minimum required communication range may be specified as a parameter for PC5.

[0077] Multicast traffic may be treated as a special case of unicast traffic (for example, similarly). For example, the case of multicast traffic may be treated as the case of unicast traffic having multiple defined receivers of the traffic. In the case of broadcast traffic, it is possible not to specify a bearer. Therefore, broadcast messages (e.g., each broadcast message) may have characteristics according to application requirements. 5QI may be used in the same way as PPPP / PPPR. In some examples, 5QI may be tagged on broadcast packets (e.g., each broadcast packet). 5QI may represent one or more characteristics associated with PC5 broadcast operation. For example, 5QI may represent one or more of latency, priority, reliability, etc. A group of V2X broadcast-specific 5QIs (e.g., VQI) may be provided for PC5.

[0078] PC5 QoS parameters may be negotiated. For example, PC5 QoS parameters may be negotiated when establishing one-to-one communication between WTRUs (e.g., two WTRUs). To support PC5 QoS parameter negotiation between WTRUs (e.g., two WTRUs), a communication establishment procedure may be provided. Once PC5 QoS parameters are negotiated, the same QoS can be used bidirectionally between WTRUs (e.g., two WTRUs).

[0079] Figure 2 illustrates the establishment of a secure Layer 2 link via PC5. As shown in Figure 2, WTRUs (e.g., WTRU-1 and WTRU-2) may engage in one-to-one communication to negotiate PC5 QoS parameters during the link establishment procedure. WTRU-1 may, for example, send a direct communication request message to WTRU-2 to trigger mutual authentication. The direct communication request message may include the requested PC5 QoS parameters. WTRU-2 may then initiate the procedure for mutual authentication. WTRU-2 may include the accepted PC5 QoS parameters in its response message. WTRU-2 can send a response message in response to a direct communication request message.

[0080] An NR V2X traffic model may be provided. NR V2X may provide traffic types (e.g., two types), e.g., periodic traffic and aperiodic traffic. The traffic types (e.g., two types) can support multiple types of packet sizes, packet arrival rates, and / or latency requirements. For example, aperiodic traffic in Model 2 may support one or more of the following characteristics: a packet size range of 10,000 to 30,000 bytes, an average arrival rate of 20 ms, or a latency requirement of 10 ms. Periodic traffic in Model 3 may support one or more of the following characteristics: a packet size range of 30,000 to 60,000 bytes, an average arrival rate of 30 ms, or a latency requirement of 30 ms.

[0081] Partial sensing and / or random selection may be provided. Partial sensing may be used as a power saving mechanism (e.g., in V2X). The WTRU may be configured with a minimum number of candidate subframes in a resource selection window [T1, T2] (e.g., configured by a higher layer). Candidate subframes (e.g., specific candidate subframes) may be selected by the WTRU implementation. The WTRU can perform sensing on subframes in a sensing window, which is an integer number of reserved periods from the candidate subframes. Such a sensing mechanism can reduce the amount of resources that the WTRU can use to perform sensing (e.g., sensing within a sensing window). In some examples, a pedestrian WTRU can perform random selection from a resource pool. For example, if the resource pool is configured for random selection, the WTRU can perform resource selection (e.g., without considering the sensing results during the sensing procedure).

[0082] For power saving purposes, discontinuous reception (DRX) may be used in NR. DRX may be used on the Uu interface, for example, in CONNECTED mode. For example, a WTRU in RRC_CONNECTED mode may utilize DRX for power saving purposes. The DRX configuration may be based on a configured schedule for the wake-up time of the WTRU. For example, if a WTRU receives a physical downlink control channel (PDCCH) scheduling during its wake-up time, the WTRU may remain awake until no further transmit scheduling is received. The WTRU may be configured with one or more of the following DRX parameters: drx-onDurationTimer, drx-SlotOffset, drx-InactivityTimer, drx-RetransmissionTimerDL, drx-RetransmissionTimerUL, drx-LongCycleStartOffset, drx-ShortCycle, drx-ShortCycleTimer, drx-HARQ-RTT-TimerDL, or drx-HARQ-RTT-TimerUL. The drx-onDurationTimer parameter can indicate the duration at the start of a DRX cycle. The drx-SlotOffset parameter can indicate the delay before activating drx-onDurationTimer. The drx-InactivityTimer parameter can indicate the duration after a PDCCH opportunity in which a PDCCH transmission indicates an uplink (UL) or downlink (DL) transmission of a MAC entity. The drx-RetransmissionTimerDL parameter may be provided for each DL HARQ process, for example, except for broadcast processes. The drx-RetransmissionTimerDL parameter can indicate the maximum duration until a DL retransmission is received. The drx-RetransmissionTimerUL parameter may be provided for each UL HARQ process.The drx-RetransmissionTimerUL parameter can indicate the maximum duration until permission for UL retransmission is received. The drx-LongCycleStartOffset parameter can indicate a long DRX cycle and a drx-StartOffset that defines the subframes from which the long and short DRX cycles begin. The drx-ShortCycle parameter can indicate a short DRX cycle. The drx-ShortCycleTimer parameter can indicate the duration for which a WTRU can follow a short DRX cycle. The drx-HARQ-RTT-TimerDL parameter may be provided for each DL HARQ process, for example, excluding broadcast processes. The drx-HARQ-RTT-TimerDL parameter can indicate the minimum duration before a DL allocation for HARQ retransmission is expected by the MAC entity. The drx-HARQ-RTT-TimerUL parameter may be provided for each UL HARQ process. The drx-HARQ-RTT-TimerUL parameter can indicate the minimum duration before permission for UL HARQ retransmission is expected by the MAC entity.

[0083] A WTRU configured with DRX may determine its active time. Active time can be the time during which the WTRU actively monitors PDCCH transmissions. If a DRX cycle is configured, active time may include the time during which one or more of the following are running: drx-onDurationTimer, drx-InactivityTimer, drx-RetransmissionTimerDL, drx-RetransmissionTimerUL, or ra-ContentionResolutionTimer. Active time may include the time while a scheduling request is sent via PUCCH and is pending. Active time may include the time after a successful receipt of a random access response to a preamble not selected by the MAC entity, while PDCCH indicates that no transmissions addressed to the MAC entity's C-RNTI have been received.

[0084] A receiving WTRU (Rx WTRU) may receive DRX configuration information. The Rx WTRU can be configured using the received DRX configuration information. The Rx WTRU may miss opportunities to send data (e.g., transport blocks (TBs)) from the transmitting WTRU (Tx WTRU) if, for example, the transmission does not occur within the Rx WTRU's active time. For resource pools with DRX-configured services, slots during DRX ON time may be more congested than slots during OFF time. For example, if a DRX Rx WTRU has a significant amount of data, collisions may occur in DRX ON time slots.

[0085] Periodic sensing may be used to detect semi-persistent resource reservations. A WTRU may perform sensing for a period of up to 1000ms, for example, before performing resource selection within a set of candidate slots. For periodic traffic, a WTRU may recognize the traffic pattern and perform sensing for up to 1000ms before the actual data arrives. Support for aperiodic traffic may be provided. For aperiodic traffic patterns, a WTRU may not be able to predict the arrival of traffic. In such cases, sensing for up to 1000ms before the arrival of traffic may not be feasible (e.g., impossible). Support for sensing, resource allocation, and / or congestion control may be provided. For example, such support for sensing, resource allocation, and / or congestion control may be provided to a WTRU configured with DRX. Support for sensing, resource allocation, and / or congestion control may be provided to reduce transmission collisions and / or improve reliability of a WTRU configured with DRX.

[0086] The WTRU's active window, WTRU's active time, and WTRU's DRX ON time can be used interchangeably in this specification. The WTRU's inactive time and DRX OFF time can be used interchangeably in this specification. The candidate slot set and the candidate slot window can be used interchangeably in this specification.

[0087] Resource allocation for transmission from Tx WTRU to WTRU (e.g., DRX Rx WTRU) may be provided. The WTRU may decide whether to trigger resource selection and / or determine the set of slots that trigger resource selection (e.g., for TB targeting DRX WTRU).

[0088] The WTRU may determine whether to trigger resource selection based on one or more of the TB's QoS, the Tx WTRU's active time, the Rx WTRU's active time, the resource pool's channel busy rate (CBR), or the TB's cast type, and / or, if an SL DRX is (pre-)configured on the Tx WTRU, it may determine the set of slots to trigger resource (re)selection (for example, for a TB targeting a DRX Rx WTRU).

[0089] For example, the WTRU may decide whether to trigger resource selection based on the TB's QoS and / or, if an SL DRX is (pre-configured) on the Tx WTRU, it may decide which set of slots will trigger resource (re)selection (for example, for a TB targeting the DRX Rx WTRU). In some examples, data may arrive in a DRX cycle (e.g., the current DRX cycle). The WTRU may decide whether to trigger resource selection based on the TB's QoS (e.g., the TB's PDB) if, for example, the time gap between the data arrival time and the last active time of the Rx WTRU is smaller than a threshold. The WTRU may, for example, trigger resource selection if the TB's PDB is smaller than the threshold. Otherwise, for example, if the TB's PDB is larger than the threshold, the WTRU may refrain from triggering resource selection in the DRX cycle (e.g., the current DRX cycle) (e.g., it may not trigger it). The WTRU may, for example, wait until the next DRX cycle to trigger resource reselection. The threshold may be configured (in advance) or determined based on the DRX cycle of the Rx WTRU.

[0090] For example, the WTRU may determine whether to trigger resource selection based on the active time of the Tx WTRU, and / or, if SL DRX is configured (pre-configured) on the Tx WTRU, it may determine a set of slots to trigger resource (re)selection (e.g., for a TB targeting the DRX Rx WTRU). For example, the WTRU can trigger resource selection within the active time of the Tx WTRU. The WTRU can trigger resource selection if, for example, the time gap between slot n and the last active slot in the Tx WTRU's DRX cycle is greater than a threshold. Otherwise, the WTRU may refrain from triggering resource selection (e.g., not trigger it). The threshold may be fixed (e.g., 31 slots) and / or (pre-configured) (e.g., the threshold may be based on the TB's QoS and / or minimum contiguous partial sensing (CPS) window). A WTRU can trigger resource allocation if, for example, the time gap between resource selection trigger slot n and the first active slot of the DRX Tx WTRU in a cycle (e.g., the current cycle) is smaller than a threshold. Otherwise, the WTRU can refrain from triggering resource allocation (e.g., not trigger). The threshold may be fixed (e.g., 31 slots) and / or (e.g., based on TB's QoS and / or minimum CPS sensing window) (pre-configured).

[0091] For example, a WTRU may determine whether to trigger resource selection based on the active time of the Rx WTRU, and / or, if an SL DRX is (pre-configured) on the Tx WTRU, determine a set of slots to trigger resource (re)selection (e.g., for a TB targeting the DRX Rx WTRU). In some examples, a WTRU can trigger resource selection within the active time of the Rx WTRU. A WTRU may trigger resource allocation for a TB if, for example, the time gap between resource selection slot n and the last slot of active time in one DRX cycle of the WTRU (e.g., the last slot of DRX ON time in the current cycle for the current active time) is greater than a threshold. The threshold may be (pre-configured) based on the TB's QoS, the resource pool's CBR, and / or the TB's cast type. A WTRU may trigger resource allocation if, for example, the time gap between resource selection trigger slot n and the first active slot of the DRX Rx WTRU in the current cycle is less than a threshold. Otherwise, the WTRU may refrain from triggering resource allocation (e.g., not trigger at all). The threshold may be fixed (e.g., 31 slots) and / or (e.g., based on QoS and / or minimum CPS sensing window for TB) (pre-configured).

[0092] A WTRU can, for example, determine the CPS window for a TB targeting an Rx WTRU on a DRX. In some examples, a WTRU can determine the CPS window [n+TA,n+TB] (e.g., TA=TB) for resource allocation for a TB targeting an Rx WTRU on a DRX, or for resource allocation for a TB, if the SL DRX is (pre-)configured to a Tx WTRU. The CPS window may be determined based on, for example, whether the CPS window is fixed or (pre-)configured, the active time of the Tx WTRU, the active time of the Rx WTRU, the QoS of the TB, the cast type of the TB, or the CPS parameters used for resource allocation targeting a non-DRX WTRU, and / or the CPS parameters used for resource allocation when the DRX is not (pre-)configured to a WTRU.

[0093] The CPS window may be determined based on, for example, whether the CPS window is fixed or (pre-configured). For example, the CPS window for resource allocation for TBs targeting Rx WTRUs on a DRX may be fixed (e.g., 31 slots). The CPS window for resource allocation for TBs targeting Rx WTRUs on a DRX may also be (pre-configured) based on, for example, the TB's QoS and / or the resource pool's CBR.

[0094] The CPS window may be determined, for example, based on the active time of the Tx WTRU. For example, the WTRU can determine the CPS window based on the time gap between the resource selection trigger slot n and the last active time of the Tx WTRU in the DRX cycle (e.g., the current DRX cycle). The WTRU can select the CPS window such that the time gap between the last active time of the Rx WTRU and the last slot in the CPS window is greater than a threshold. The threshold may be configured (pre-configured) based, for example, the QoS of the TB, the CBR of the resource pool, and / or the cast type of the TB. The WTRU can determine the CPS window such that it satisfies the time gap between the last slot in the CPS window and the last active time of the Tx WTRU.

[0095] The CPS window may be determined, for example, based on the active time of the Rx WTRU. For example, the WTRU can determine the CPS window based on the time gap between the resource selection trigger slot n and the last active time of the Rx WTRU in the DRX cycle (e.g., the current DRX cycle). The WTRU can select the CPS window such that the time gap between the last active time of the Rx WTRU and the last slot in the CPS window is greater than a threshold. The threshold may be configured (pre-configured) based, for example, the QoS of the TB, the CBR of the resource pool, and / or the cast type of the TB. The WTRU can determine the CPS window such that it satisfies the time gap between the last slot in the CPS window and the last active time of the Rx WTRU.

[0096] The CPS window may be determined based on, for example, the CPS parameters used for resource allocation targeting non-DRX WTRUs and / or the CPS parameters used for resource allocation when DRX is not (pre-configured) for the WTRU. For example, the WTRU can determine the CPS window for resource allocation targeting DRX Rx WTRUs based on the CPS window used for initial resource allocation. In some examples, the WTRU may (pre-configure) an offset between the minimum or maximum CPS window, the CPS window used for resource allocation targeting DRX Rx WTRUs, and / or the CPS window used for normal resource allocation (e.g., resource allocation targeting non-DRX WTRUs and / or resource allocation when DRX is not (pre-configured)). The offset may be fixed or (pre-configured) based on the QoS of the TB.

[0097] For example, a WTRU behavior may be provided if the minimum CPS window for resource allocation for a TB targeting a DRX WTRU is not met. In some examples, a WTRU may not meet (e.g., be unable to meet) the minimum or maximum CPS sensing window. A WTRU may do one or more of the following: wait until the next DRX cycle to sense and / or allocate resources if the TB's PDB is greater than a threshold (e.g., a DRX cycle); drop the TB and / or send it in another resource pool (e.g., an exception resource pool); reduce the number of (re)transmissions of the TB; change from a semi-persistent reservation to a periodic transmission if the CPS sensing window (e.g., the required CPS sensing window) is (pre-configured) for a semi-persistent reservation; or perform a random resource selection for the TB if the resource pool allows random resource allocation.

[0098] A WTRU (e.g., a Tx WTRU) can determine a resource selection window for transmission to a DRX Rx WTRU. In some examples, a WTRU can determine one or more of the following parameters to perform resource selection for a TB target to a DRX Rx WTRU: a resource selection window (e.g., [n+T1, n+T2]), a set of candidate slots within the resource selection window, or a window of candidate slots (e.g., [n+Y1, n+Y2]). The parameters may be selected to allow the Tx WTRU to select one or more transmission resources within the Rx WTRU's active time. The parameters may also be selected based on the Rx WTRU's DRX ON time, the Tx WTRU's DRX ON time, the Tx WTRU's active time, and / or the Rx WTRU's active time.

[0099] A WTRU (e.g., Tx WTRU) may select a resource selection window and a set of candidate slots within that window. The WTRU can make a selection based on the determination that the overlap area (e.g., the number of overlapping slots) between the candidate slot window and the active window of the Rx WTRU is greater than a threshold. A WTRU (e.g., Tx WTRU) may select a resource selection window and a set of candidate slots within that window. The WTRU can make a selection based on the determination that the first slot (e.g., n+Y1) of the candidate slot window occurs within the active window of the Rx WTRU. The WTRU can select a set of candidate slots such that the overlap area between the candidate slot window and the active window of the Rx WTRU is greater than a threshold. The threshold for the number of overlapping slots may be determined based on one or more of the following: (pre-configured) per resource pool, DRX configuration, resource pool CBR, TB QoS (e.g., priority), or TB HARQ type (e.g., whether the TB is HARQ-enabled or not).

[0100] Figure 3 shows the resource selection window for a TB associated with a DRX Rx WTRU. As shown in Figure 3, the WTRU can trigger resource selection in the resource selection window [n+T1, n+T2], which may be the active window of the Rx WTRU in slot n. The WTRU can select candidate windows (e.g., [n+Y1, n+Y2]) and / or a set of Y candidate slots such that the set of overlapping windows and / or overlapping slots is greater than a threshold.

[0101] A WTRU can determine a set of slots for initializing a set of candidate resources (e.g., set A). In some examples, a WTRU can determine a set of slots for initializing (e.g., set A) based on the cast type of the TB. A WTRU can initialize set A in a set of overlapping slots between a set of candidate slots in the candidate window [n+Y1, n+Y2] and the active time of the Rx WTRU for broadcast. A WTRU can initialize set A in the candidate window [n+Y1, n+Y2] for unicast and / or groupcast TBs. A WTRU may terminate set A by performing resource exclusions on each initialized set A (e.g., each initialized set A).

[0102] A WTRU can initialize a set of candidate resources for resource allocation (e.g., set A) based on multiple (e.g., two) active times (e.g., the current and future active times of the Rx WTRU in DRX). A WTRU can determine the active times that may be used to initialize set A based on, for example, the cast type of the TB. A WTRU can initialize set A within a first active time (e.g., the current active time) for a broadcast TB. A WTRU can initialize set A within a second active time (e.g., future active time) for a unicast or groupcast TB.

[0103] A WTRU can determine a resource selection window [n+T1, n+T2] based on multiple active times (e.g., two active times). For example, a resource selection window may include a first resource selection window (e.g., a window in which Y candidate slots overlap with the active window of the Rx WTRU, which may also be called an overlapping slot window) and a second resource selection window (e.g., a window in which Y candidate slots do not overlap with the active window of the Rx WTRU). The first resource selection window may be associated with a first active time, and the second resource selection window may be associated with a second active time. Multiple active times (e.g., two active times) may be determined by the Tx WTRU (e.g., the first active time may be the current active time and may be associated with an overlapping slot window, and the second active time may be a future active time and may be associated with a window in which Y candidate slots do not overlap with the active window of the Rx WTRU). The WTRU may determine the active time available to initialize Set A, for example, based on the cast type of the TB. The WTRU may select T2 within a first active time (e.g., the current active time) for a broadcast TB. The WTRU may select T2 within a second active time (e.g., a future active time) for a unicast or groupcast TB.

[0104] The WTRU can determine, for example, the resource selection window [n+T1, n+T2] for a TB targeting an Rx WTRU in DRX (for example, based on the cast type). The WTRU may receive instructions (for example, in configuration information which may include one or more parameters) indicating the active time of the Rx WTRU. For example, if the TB is for a unicast or groupcast (for example, indicated via one or more parameters included in the configuration information), the value of T2 may be selected to be within or outside the active time range of the Tx WTRU. For example, if the TB is for a broadcast (for example, indicated via one or more parameters included in the configuration information), the WTRU may select T2 within the active time of the Rx WTRU.

[0105] The WTRU can determine whether to trigger a resource allocation process (e.g., a subsequent resource allocation process) for TB retransmission. In some examples, the WTRU can initialize a set of candidate resources A within the active window (e.g., only within the active window), as shown in Figure 3, for example. The WTRU can determine whether to trigger a resource allocation process (e.g., a subsequent resource allocation process) for TB based on one or more of the following: the TB's cast type, the TB's QoS, or the TB's Rx HARQ feedback from the WTRU.

[0106] A WTRU can, for example, determine whether to trigger a resource allocation process for a TB (e.g., a subsequent resource allocation process) based on the TB's cast type. For example, a WTRU can refrain from triggering a resource allocation process for a broadcast (e.g., a subsequent resource allocation process). A WTRU can trigger a resource allocation process for a unicast or groupcast (e.g., a subsequent resource allocation process).

[0107] A WTRU can, for example, determine whether to trigger a resource allocation process for a TB (e.g., a subsequent resource allocation process) based on the TB's QoS. For example, a WTRU may trigger a resource allocation process (e.g., a subsequent resource allocation process) if, for example, the TB's priority and / or reliability are greater than a threshold. Otherwise, the WTRU may refrain from triggering (e.g., not trigger) a resource allocation process for the TB.

[0108] A WTRU can, for example, determine whether to trigger a resource allocation process for a TB (e.g., a subsequent resource allocation process) based on HARQ feedback from the TB's Rx WTRU. For example, a WTRU can trigger a resource allocation process for a TB (e.g., a subsequent resource allocation process) if, for example, the WTRU receives a Negative Response (NACK) to a unicast or groupcast.

[0109] If the number of duplicate slots is less than a threshold, and / or if the WTRU cannot select a resource selection window that satisfies one or more of the (pre-defined) conditions, the WTRU may perform one or more of the following actions: change the resource selection method (for example, the WTRU may switch to a random resource allocation method), drop the TB, or perform resource selection in a different resource pool for sending the TB.

[0110] A WTRU can determine a set of selectable resources for transmitting one or more TBs. Within a window of candidate slots, a WTRU may exclude resources reserved by other WTRUs, for example, if the sidelink reference signal received power (SL-RSRP) measured within a reserved message is greater than a threshold.

[0111] WTRU may increase the SL-RSRP threshold, for example, based on the number of selectable resources within one or more windows. WTRU may use the increased SL-RSRP threshold to determine the availability of a single reserved resource. For example, WTRU may use the increased SL-RSRP threshold to determine the availability of a single reserved resource based on the number and / or percentage of selectable resources within one or more windows. The WTRU can increase the number of available resources within a selection window (e.g., the overlapping slot window in Figure 3, the Rx WTRU active window in Figure 4, the Rx WTRU inactive window in Figure 4, etc.) by increasing the SL-RSRP threshold, and this increase may be based on one or more of the following conditions: the number and / or percentage of selectable resources in the active window of the Rx WTRU is less than the threshold; the number and / or percentage of selectable resources in the candidate slot window is less than the threshold; or the number and / or percentage of selectable resources in non-overlapping slots between the candidate window [n+Y1, n+Y2] and the Rx active window is less than the threshold. The threshold may be fixed, but may be determined based on the resource pool configuration, DRX configuration, TB priority, the size of the active window for Rx WTRU, the resource pool CBR, the CBR associated with DRX, the TB cast type, and / or the size of the candidate window [n+Y1, n+Y2].

[0112] In some cases, WTRU can increase the number of available resources in a selection window (e.g., the overlapping slot window in Figure 3, the Rx WTRU active window in Figure 4, the Rx WTRU inactive window in Figure 4, etc.) by determining the set of selectable resources in a candidate slot window, for example, by increasing the RSRP threshold if the number and / or percentage of selectable resources in a candidate slot window is less than the threshold (e.g., limit). WTRU can increase the RSRP threshold to determine the set of selectable resources in a candidate slot window. WTRU can determine whether to increase the RSRP threshold (e.g., limit) if the number and / or percentage of selectable resources in a candidate slot window is greater than the threshold. WTRU can determine whether to increase the RSRP threshold (e.g., limit) based on the number and / or percentage of selectable resources in the Rx WTRU active window. WTRU may, for example, not change (e.g., not increase) the RSRP limit if the number and / or percentage of selectable resources within the active window of the Rx WTRU is greater than the threshold. WTRU may, for example, change (e.g., increase) the RSRP threshold if the number and / or percentage of selectable resources within the active window of the Rx UE is less than the threshold.

[0113] In some cases, WTRU can increase the number of available resources in a selection window (e.g., the duplicate slot window in Figure 3, the Rx WTRU active window in Figure 4, the Rx WTRU inactive window in Figure 4, etc.) by increasing the RSRP threshold (e.g., the limit value) to determine the set of selectable resources within the candidate slot window.

[0114] Figure 4 illustrates how to increase the number of available resources in a resource selection window (e.g., a window within a resource selection window) by changing a parameter (e.g., the parameter may be an exemplary RSRP threshold increase / increment for resource selection, where RSRP increase may be used herein as an exemplary parameter for illustrative purposes). A first number of candidate resources can be initialized (e.g., determined) in the Rx WTRU active window, as shown in Figure 4A. A first number of candidate resources can be initialized (e.g., determined) in the Rx WTRU inactive window, as shown in Figure 4A. A first number of candidate resources associated with the Rx WTRU active window can be increased. A first number of candidate resources associated with the Rx WTRU inactive window can be increased. For example, if the number of candidate / selectable resources in the active window of the Rx WTRU is less than a threshold (for example, if the resource threshold for the active window is 3, as shown in Figure 4), then the WTRU (e.g., Tx WTRU) may increase the number of available / candidate resources associated with the Rx WTRU active window (for example, by increasing the RSRP (e.g., SL-RSRP) limit). The WTRU can first determine the set of selectable resources (e.g., candidate resources, where available resources, selectable resources, and candidate resources can be used interchangeably) using, for example, the initial RSRP (for example, in part (A) of Figure 4). If the number of selectable resources in the active window of the Rx WTRU is 2 (for example, less than the resource threshold), then the WTRU can increase the number of resources (for example, by increasing the RSRP threshold) and (re)determine the set of selectable resources (for example, resulting in part (B) of Figure 4). In such cases, the first number of candidate resources in the Rx WTRU active window may be increased to the second number of candidate resources in the Rx WTRU active window, as shown in Figure 4A.As shown in Figure 4A, if the first number of candidate resources in the Rx WTRU inactive window is less than the resource threshold, the first number of candidate resources in the Rx WTRU inactive window may be increased to the second number of candidate resources in the Rx WTRU inactive window by, for example, increasing the RSRP threshold (resulting, for example, as shown in Figure 4B). The increased number of selectable resources in the active and inactive windows of the Rx WTRU (e.g., the second number of candidate resources) is 4, and this increase may be achieved by using modified parameters such as an increased RSRP. In this example, the increased number of selectable resources is greater than the resource threshold of 3. The WTRU can select one or more resources from a second number of candidate resources (e.g., based on the second number of candidate resources) for, for example, the transmission of one or more TBs (e.g., transmission or retransmission). Information (e.g., control information) may be transmitted to indicate the selected resources. The examples described herein may also be applied to Figure 3, where the overlapping slot window corresponds to the Rx WTRU active window, and where a window with Y candidate slots that do not overlap with the overlapping slot window corresponds to the Rx WTRU inactive window, as shown in Figure 3.

[0115] In some examples, the Rx WTRU active window and the Rx WTRU inactive window may be associated with their respective resource thresholds (e.g., a first resource threshold associated with the Rx WTRU active window and a second resource threshold associated with the Rx WTRU inactive window). In such examples, if the first number of candidate resources in the Rx active window is less than the first resource threshold, the first number of candidate resources in the Rx active window may be increased to the second number of candidate resources in the Rx WTRU active window, and the second number of candidate resources in the Rx WTRU active window may be greater than the first resource threshold. If the first number of candidate resources in the Rx inactive window is less than the second resource threshold, the first number of candidate resources in the Rx WTRU inactive window may be increased to the second number of candidate resources in the Rx WTRU inactive window, and the second number of candidate resources in the Rx WTRU inactive window may be greater than the second resource threshold.

[0116] The WTRU can determine a set of available resources A (e.g., a second number of candidate resources that exceed the resource threshold) for each window (e.g., an Rx WTRU active window and an Rx WTRU inactive window). In some examples, the WTRU can determine a set of available resources (e.g., a second number of candidate resources) by, for example, performing slot exclusion by unmonitored slots and / or increasing the RSRP threshold to obtain more available resources (e.g., increasing the RSRP threshold until a second number of candidate resources associated with an Rx WTRU active window and / or an Rx WTRU inactive window exceed the resource threshold). A WTRU can perform resource exclusion based on one or more of the following: for example, that the number and / or percentage of resources available during the active time of the Rx WTRU (e.g., the second number of candidate resources) is greater than X1; that the number and / or percentage of resources available in the inactive window of the Rx WTRU (e.g., the second number of candidate resources) is greater than X2; or that the number and / or percentage of resources available in the set of candidate slots in the candidate slot window [n+Y1, n+Y2] (e.g., the second number of candidate resources) is greater than X.

[0117] The values ​​of X1, X2, and X, and / or which conditions should be met, may be determined based on, for example, whether the values ​​are (pre-determined), the cast type of the TB, the size of the window (e.g., each window) and / or the number of candidate slots within the window (e.g., each window), or one or more of the QoS of the TB.

[0118] The values ​​of X1, X2, and X, and / or which conditions should be met, may be determined, for example, based on whether the values ​​are (pre-determined). For example, X1 may be pre-determined as 20% of the candidate slots in the window, X2 as 20% of the candidate slots in the window, and X as 20% of the candidate slots in the window. For example, X1 may be pre-determined as 20% of the candidate slots in the window, X2 as 0% of the candidate slots in the window, and X as 20% of the candidate slots in the window. For example, X1 may be determined as 20%, X2 as 0%.

[0119] The values ​​of X1, X2, and X, and / or which conditions should be met, may be determined, for example, based on the TB cast type. For example, a set of values ​​for X1, X2, and X may be predetermined based on the TB cast type. The WTRU may use one set of (X1,X2,X) for unicast or groupcast (e.g., X1=X2=X3=20%) and another set of (X1,X2,X) for broadcast (e.g., X1=20%, X2=X=0%).

[0120] In some cases, the WTRU can determine the set of slots and / or windows for initializing set A (for example, based on the cast type of the TB). For example, in the case of a broadcast TB, the WTRU can initialize set A in the overlapping slots (for example, the active window as shown in Figure 4) between the active window of the Rx WTRU and the set of candidate slots in the window of candidate slots [n+Y1, n+Y2]. The WTRU can perform resource exclusion, for example, by excluding unmonitored resources and / or by increasing the RSRP threshold (for example, so that the percentage and / or number of available resources in set A is greater than X1 (e.g., 20%)). For example, in the case of a unicast or groupcast TB, the WTRU can initialize set A in the set of candidate slots in the window of candidate slots. WTRU can perform resource exclusion by excluding unmonitored slots and / or by increasing the RSRP threshold (for example, such that the percentage and / or number of available resources called the second number of candidate resources in the window active time of the Rx WTRU is greater than X1 (e.g., 20%) and the percentage and / or number of available resources in the set of candidate slots in the window of candidate slots [n+Y1, n+Y2] is greater than X (e.g., 20%)).

[0121] In some examples, the interference level of selectable resources may change (e.g., increase) as the RSRP threshold changes (e.g., increases). The WTRU may, for example, change its resource selection method (e.g., the WTRU may switch to random resource selection within the active window of the Rx WTRU), reduce the number of resources to send, drop TBs, or perform resource selection in a different resource pool for sending TBs if the increased RSRP threshold is greater than the threshold.

[0122] A WTRU (e.g., Tx WTRU) may determine the number of transmission resources for sending TBs. For example, a WTRU can determine the number of transmission resources (e.g., the minimum number of transmission resources) for sending a TB (e.g., one TB) within the resource selection window and the active window of the Rx WTRU. As illustrated with respect to Figure 3, the instruction for the number of transmission resources may be sent to the Rx WTRU via control information (e.g., as a parameter). A WTRU may (pre-configure) a range of transmission resources (e.g., more than a first limit and less than a second limit) for TBs within the candidate slot window and the active slot window of the Rx WTRU. For example, the maximum number of transmissions may be associated with a TB (e.g., indicated via control information as a parameter). A WTRU can determine one or more of a range of transmission resources or the actual number of transmission resources. For example, if a WTRU is configured with a range of transmission resources, the WTRU can select the maximum value, the minimum value, or randomly select a value within the range (e.g., one value).

[0123] The range of the number of transmit resources for sending TBs and / or the determination of the actual number of transmit resources may be based on one or more of the following, pre-configured per resource pool: DRX configuration, resource pool CBR, set of selectable resources within a window (e.g., each window), CBR associated with the WTRU's DRX configuration, RSRP threshold, TB QoS, or TB HARQ type. In an exemplary resource pool configuration, the WTRU may be pre-configured with a range of transmit resources within the active window of the Rx WTRU and / or a range of transmit resources within the window of candidate slots. In an exemplary DRX configuration, the WTRU may be pre-configured with a range of transmit resources within the active window of the Rx WTRU and within the window of candidate slots per DRX configuration. In an exemplary selectable resource within a window (e.g., each window), the WTRU may select the number of transmit resources for TBs within the active window of the Rx WTRU based on the number of selectable resources within the window. For example, a WTRU can select a small or large number of transmit resources, depending on whether there are few or many selectable resources. The CBR associated with the WTRU's DRX configuration may indicate CBR_drx. The RSRP threshold may be the final RSRP threshold that can be used to determine the set of selectable resources. The TB's QoS may indicate priority (e.g., priority level). The TB's HARQ type may indicate whether the TB is HARQ-enabled or not. For example, a WTRU may be (pre-configured) with a number of transmit resources in two ranges within the active window of the Rx WTRU and / or within the window of candidate slots. The first range of the two ranges may be (pre-configured) for HARQ-enabled TBs, and the second range of the two ranges may be (pre-configured) for HARQ-inenabled TBs.

[0124] A WTRU may use sidelink control information (SCI) associated with a transmission during DRX ON time to reserve a transmission during DRX OFF time. A WTRU may select one or more transmission resources for a TB during DRX OFF time. For example, if one or more transmissions during DRX ON time indicate and / or reserve a resource during DRX OFF time, the WTRU can decide whether to send a transmission through the resource associated with DRX OFF time. For example, if none of the transmissions during DRX ON time indicate and / or reserve a resource during DRX OFF time, the WTRU may stop transmitting TBs in the DRX cycle (e.g., the current DRC cycle). By using SCI associated with a transmission during DRX ON time to reserve a transmission during DRX OFF time, the Rx WTRU can receive TBs during DRX OFF time.

[0125] A WTRU may transmit HARQ-enabled TBs. If a transmitting WTRU does not receive HARQ feedback from a transmission during a DRX ON time (e.g., a discontinuous transmission, DTX is detected), the WTRU may perform one or more of the following actions during a DRX OFF time: drop selected and / or reserved resources; perform a (pre-configured) number of retransmissions during the Rx WTRU's DRX OFF time; or retransmit a TB during the next DRX ON time. For example, if a DTX is detected after a (pre-configured) number of retransmissions during a DRX OFF time, the WTRU may stop transmitting in the DRX cycle (e.g., the current DRX cycle) and / or drop the TB. In some examples, the (pre-configured) number of retransmissions during a DRX OFF time may be (pre-configured) according to the QoS of the TBs and / or CBRs in the resource pool. For example, if a transmission during the next DRX ON time satisfies the TB's PDB, the WTRU may retransmit a TB during the next DRX time. WTRU may drop a TB if transmissions within the next DRX ON time do not fill the TB's PDB.

[0126] The WTRU may determine the number of transmission resources to be selected for the resource (re)selection process. For example, the WTRU may determine the number of transmission resources to be selected for the resource (re)selection process based on one or more of the following: the resource selection window and / or the set of selectable slots within the resource selection window, the HARQ type of the TB, or the remaining SL DRX ON time and / or remaining active time of the Rx WTRU.

[0127] The WTRU may determine the number of transmission resources to be selected for a resource (re)selection process based on the resource selection window and / or the set of selectable slots within the resource selection window. The WTRU may (pre-configure) a maximum number of transmission resources to select based on the number of selectable slots, the number of selectable resources, and / or the size of the resource selection window. The WTRU can choose the number of transmission resources to select for a resource (re)selection process (e.g., one resource (re)selection process). The number of selected transmission resources may be less than the (pre-configured) maximum number of transmission resources.

[0128] The WTRU may determine the number of transmission resources to be selected for the resource (re)selection process based on the TB's HARQ type. The WTRU may (pre-configure) a set of a certain number (e.g., up to two) of transmission resources for each resource (re)selection process based on the TB's HARQ type. One of the maximum number of transmission resources may be used for the HARQ-enabled TB. The second of the maximum number of transmission resources may be used for the HARQ-non-HARQ-enabled TB. The WTRU can determine the maximum number of transmission resources that may be used based on the TB's HARQ type.

[0129] The WTRU may determine the number of transmit resources to be selected for the resource (re)selection process based on the remaining SL DRX ON time and / or remaining active time of the Rx WTRU. The WTRU may (pre-configure) the maximum number of transmit resources to be selected based on the remaining SL DRX ON time and / or remaining active time of the Rx WTRU. The WTRU can determine the number of transmit resources to be selected based on the remaining SL DRX ON time and / or active time of the Rx WTRU.

[0130] The WTRU may decide whether to perform short-term partial sensing of resource selection for a TB (e.g., one TB) to the DRX WTRU. The WTRU may decide whether to perform short-term partial sensing of a TB targeting the DRX WTRU. The WTRU can make this decision based on the time gap between the resource selection trigger and, for example, the last active slot of the Rx WTRU in the DRX period (e.g., the current DRX period). The WTRU may decide that short-term partial sensing cannot be performed if, for example, the time gap between the resource selection trigger and the last active slot of the Rx WTRU in the DRX period (e.g., the current DRX period) is smaller than a threshold (e.g., a limit). In some examples, the WTRU may decide that short-term partial sensing can be performed if, for example, the time gap is larger than a threshold (e.g., a limit). The time gap threshold may be configured (in advance). For example, the time gap threshold may be configured (in advance) for each resource pool.

[0131] The WTRU may determine the short-term sensing window for TBs targeting the DRX WTRU. In some examples, the WTRU can determine the short-term partial sensing window for TBs targeting the DRX WTRU based on the time gap between the resource selection trigger and the last active slot of the Rx WTRU in the DRX period (e.g., the current DRX period). If the time gap between the resource selection trigger and the last active slot of the Rx WTRU is greater than a threshold, the WTRU may select a fixed short-term sensing window (e.g., 31 slots). If the time gap is smaller than a threshold, the WTRU may select a short-term partial sensing window to balance the resource selection window and the sensing window. If the time gap between the trigger slot and the last active slot is small, the WTRU may select a small short-term sensing window. If the time gap between the trigger slot and the last active slot is large, the WTRU may select a large short-term sensing window.

[0132] Partial sensing and / or resource allocation may be provided. The WTRU may perform sensing (e.g., periodic sensing) to detect, for example, resource reservations (e.g., periodic resource reservations) associated with periodic traffic of fluctuating periodicity. The WTRU may be (pre-configured) for use in monitoring ahead of the window of candidate slots. The set of periodicity may be (pre-configured). For example, the set of periodicity may be (pre-configured) based on a set of resource reservation intervals associated with a resource pool (e.g., supported in the resource pool).

[0133] Figure 5 shows an exemplary periodic sensing scenario. As shown in Figure 5, a resource may support two resource reservation intervals (e.g., 100ms and 150ms). The WTRU may monitor windows 504 and 502 to select a transmit resource within a window of Y candidate slots. Windows 502 and 504 are 150ms and 100ms from the window of Y candidate slots, respectively. Periodic sensing and monitoring may enable the WTRU to detect resource reservations within the set of candidate resources made by transmits within windows 504 and 502.

[0134] The WTRU can determine the number of subsets and durations of reservation intervals to monitor and / or extract sensing results. The decision may be based on one or more of the following: traffic type (e.g., periodic or aperiodic traffic), TB QoS, resource pool CBR, one or more reservation intervals for periodic traffic, resource allocation, preemption, or whether periodic partial sensing is used for resource reassessment, or whether SL DRX is (pre-)configured in the WTRU. With respect to periodic traffic types, the WTRU can perform semi-persistent resource reservations of one or more selected resources, for example, to reserve transmit resources for TB in subsequent intervals. For example, for periodic traffic, the WTRU may monitor (pre-)configured reservation intervals (e.g., all (pre-)configured reservation intervals). For aperiodic traffic, the WTRU may skip periodic reservations (e.g., not monitor reservation intervals), or the WTRU may monitor a subset of reservation intervals.

[0135] For non-periodic traffic, the WTRU may determine the reservation intervals to monitor based on the TB's QoS (e.g., PDB). For example, for TB with a high PDB (e.g., above a threshold), the WTRU can monitor a number of reservation intervals, including long and / or short intervals. For TB with a low PDB, the WTRU can monitor short reservation intervals (e.g., only monitor them) or not monitor any intervals at all.

[0136] Based on decisions made based on the resource pool's CBR, one or more of the following may apply: The WTRU may be pre-configured with multiple sets of reserved intervals to be monitored. Each set of reserved intervals may be associated with a CBR range. The WTRU may determine which sets to monitor based, for example, the resource pool's CBR and / or associated configuration.

[0137] Based on decisions made based on the reservation intervals for periodic traffic, one or more of the following may apply: For example, a WTRU for a periodic traffic type may include a reservation interval for traffic associated with the WTRU in a set of reservation intervals for periodic partial sensing (e.g., Preserve_Tx).

[0138] Based on a decision made on whether periodic-based partial sensing is used for resource allocation, preemption, or resource reassessment, one or more of the following may apply: The WTRU may (pre-)configure multiple sets of reservation intervals. A first set of multiple sets of reservation intervals may be used for resource allocation, a second set of multiple sets of reservation intervals may be used for resource reassessment, and a third set of multiple sets of reservation intervals may be used for preemption. The WTRU can determine which set of multiple sets of reservation intervals is used for resource allocation, preemption, or resource reassessment, based on the purpose for which periodic-based partial sensing is being used.

[0139] Based on a decision made on whether or not SL DRX is configured, one or more of the following may apply: A WTRU may be configured in advance with multiple sets (e.g., two sets) of reserved intervals to be monitored for periodic-based partial sensing (PBPS). For example, a first set of reserved intervals may be used by a WTRU that is configured with SL DRX, and a second set of reserved intervals may be used by a WTRU that is not configured with SL DRX. A WTRU may determine which set of reserved intervals to monitor for PBPS. The set of reserved intervals may be based on whether or not SL DRX is configured. For example, if a WTRU is configured with SL DRX, it may use the first set of reserved intervals. For example, if a WTRU is not configured with SL DRX, it may use the second set of reserved intervals.

[0140] Figure 6 shows various examples of sensing associated with different types of TB. As shown in Figure 6, the WTRU may determine the set of reservation intervals to monitor based on the traffic type and / or TB priority. For example, if the traffic is of a periodic type, the WTRU may monitor (pre-configured) reservation intervals (e.g., all (pre-configured) reservation intervals). In some examples, if the traffic is of a periodic type, the WTRU may monitor a subset of (pre-configured) reservation intervals. In the case of a periodic type traffic with a low QoS TB (e.g., low priority), the WTRU may monitor more reservation intervals. In the case of a periodic type traffic with a high QoS TB (e.g., high priority), the WTRU may monitor fewer reservation intervals.

[0141] A WTRU may trigger periodic sensing of TB. A WTRU can determine when periodic monitoring may be triggered. A WTRU can determine the trigger time based on the traffic type. For non-periodic traffic, a WTRU can trigger periodic monitoring based on packet arrival. For periodic traffic, a WTRU can perform periodic sensing. For example, a WTRU can perform periodic sensing for a (pre-configured) maximum interval before a resource selection trigger. A WTRU can trigger periodic sensing based on the intended resource selection trigger time.

[0142] In an exemplary partially sensing-based resource allocation, a WTRU may decide whether to select a transmit resource outside the candidate slot window based on one or more of the following: the TB's QoS, the resource pool's CBR, the TB's HARQ type, the number of retransmit resources the WTRU selects for the TB's transmit, the TB's traffic type, whether the WTRU semi-permanently reserves resources, or whether the WTRU performs resource selection by resource re-evaluation. If the TB's priority is greater than a threshold, the WTRU may select a transmit resource outside the candidate slot window. Otherwise, the WTRU may select a transmit resource within the candidate slot window. Thresholds may be configured (pre-configured) for each resource pool. For example, if the TB's priority is greater than a threshold, the WTRU may select a transmit resource within the candidate slot window. Otherwise, the WTRU can select a transmission resource both within and outside the set of candidate slots.

[0143] With regard to the WTRU's decision, based on the resource pool's CBR, whether to select a transmit resource outside the candidate slot window, one or more of the following may apply: In some examples, the WTRU may be (pre-configured) for transmitting TBs (e.g., those with priority levels). The WTRU can select transmit resources outside the candidate slot window for each CBR range. For TBs with priority, the WTRU can determine whether it can select one or more transmit resources outside the candidate slot window. The WTRU can make a decision based on the measured CBR and the corresponding configuration.

[0144] With regard to the WTRU's decision on whether to select a transmit resource outside the candidate slot window based on the TB's HARQ type, one or more of the following may apply: The WTRU may decide whether to select a transmit resource outside the set of candidate slots. The WTRU may make a decision based on whether the TB is HARQ-enabled or HARQ-incompatible. For example, for a TB with priority (e.g., priority level), the WTRU may select a transmit resource outside the set of candidate slots if the HARQ type associated with the TB is configured as HARQ-enabled. In some examples, for a TB with priority (e.g., priority level), the WTRU may not select a transmit resource outside the set of candidate slots if the HARQ type associated with the TB is configured as HARQ-incompatible. The WTRU may (pre-configure) a set of priority levels (e.g., two priority levels) that allows for the selection of resources outside the set of candidate slots. The first priority level may be used for HARQ-enabled TBs, and the second priority level may be used for HARQ-incompatible TBs.

[0145] Regarding the WTRU's decision on whether to select a transmit resource outside the candidate slot window, based on the number of retransmit resources the WTRU selects for TB transmission, one or more of the following may apply: The WTRU may select a transmit resource outside the set of candidate slots if, for example, the number of retransmissions of TB (e.g., one TB) is greater than a threshold. Otherwise, the WTRU may select a transmit resource for TB (e.g., one TB) within the set of candidate slots. A threshold may be configured (in advance) for each resource pool.

[0146] The WTRU may decide whether to select a transmit resource outside the candidate slot window based on at least the TB traffic type. The TB traffic type may be periodic or aperiodic. For periodic traffic, the WTRU may perform a semi-persistent reservation of one or more transmit resources for the TB. For aperiodic traffic, the WTRU may not perform a semi-persistent reservation of a transmit resource. In some examples, the WTRU may select a transmit resource outside the set of candidate slots for aperiodic traffic. For periodic traffic, the WTRU may select a transmit resource within the set of candidate slots.

[0147] Regarding the WTRU's decision on whether to select a transmission resource outside the candidate slot window, based on whether the WTRU semi-permanently reserves the resource, one or more of the following may apply: For example, if the WTRU semi-permanently reserves the selected resource, the WTRU can select a transmission resource within the set of candidate slots. For example, if the WTRU does not semi-permanently reserve the resource, the WTRU can select a transmission resource within or outside the set of candidate slots.

[0148] A WTRU can determine whether to select a send resource outside the candidate slot window, at least based on whether the WTRU performs resource selection through resource reevaluation. A WTRU can select a send resource within and / or outside the set of candidate slots for resource reevaluation.

[0149] A WTRU can decide whether to drop a HARQ-enabled TB. In the case of a HARQ-enabled TB, if the WTRU receives NACK feedback from an Rx WTRU (e.g., one of the Rx WTRUs) or detects a DTX, the WTRU may drop the TB and / or select a resource outside the candidate slot window (e.g., if the WTRU cannot select a transmit resource within the candidate slot). The WTRU may decide whether to drop the TB and / or select a resource outside the candidate slot window based on one or more of the TB's QoS, the resource pool's CBR, or the number of (re)transmissions of the TB made by the WTRU. In some examples, if the TB's priority is below a threshold, the WTRU may drop the TB. In some examples (e.g., if the TB's priority is above a threshold), the WTRU may select a resource outside the candidate slot window and continue transmitting the TB. The WTRU may be (pre-configured) with a range of CBRs (e.g., each range), a set of priorities for dropping TBs, and / or a set of priorities for making selections outside the set of candidate slots and continuing to send TB transmissions. A WTRU can decide whether to drop a TB or continue sending a TB based on the priority of the CBR and / or TB in the resource pool. A WTRU can decide whether to drop a TB transmission. A WTRU can make a decision based on whether the number of (re)transmissions of WTRUs associated with a TB is within a range. If a WTRU determines that the number of (re)transmissions of WTRUs associated with a TB is not within a range, the WTRU can continue selecting resources outside the candidate slot window.

[0150] A WTRU can determine whether a semi-persistent resource reservation is possible for a selected resource. The WTRU can make this determination based on whether periodic sensing is performed and / or the set of reservation intervals being monitored, or one or more of the windows of the selected resource. In some examples, the WTRU may not be able to perform a semi-persistent reservation if periodic sensing is not performed. The WTRU may also not be able to perform a semi-persistent reservation if one or more reservation intervals are not being monitored. A WTRU may, for example, pre-configure a set of reservation intervals to be monitored before executing a semi-persistent reservation. If one or more intervals in the pre-configured set are not monitored, the WTRU may not execute a semi-persistent reservation.

[0151] With regard to determining whether a semi-persistent resource reservation is possible for a selected resource, based on the window of the selected resource, one or more of the following may apply: A WTRU can determine whether a semi-persistent reservation is possible for a selected resource based on the window of the selected resource. For example, a WTRU may semi-persistently reserve a resource if the resource is within the window of the candidate slot (for example, a WTRU may perform periodic sensing before the window of the candidate slot). A WTRU may not be able to semi-persistently reserve a resource if, for example, the selected resource is outside the window of the candidate slot.

[0152] A WTRU can determine whether to trigger a resource re-evaluation. The WTRU can make this decision based on one or more of the following: the overlap window between the active slot and candidate slot windows in the Rx WTRU, the DRX ON time, or the remaining DRX ON time. For example, a WTRU may skip resource re-evaluation if the overlap window between the active slot and candidate slot windows in the resource selection window is smaller than a threshold. Thresholds can be configured (pre-configured) per resource pool. In some examples, a WTRU may skip resource re-evaluation if the DRX ON time and / or remaining DRX ON time are smaller than a threshold. Thresholds can be configured (pre-configured) per resource pool and / or per DRX configuration.

[0153] The WTRU can decide whether to remove a slot (e.g., one slot) from the set of candidate slots. The WTRU may be (pre-configured) to monitor k (e.g., k>1) periods of the reservation interval before selecting a send resource from the set of candidate slots. For example, if the WTRU does not monitor for one or more of the k periods, the WTRU can decide whether to remove the associated candidate slot (e.g., one associated candidate slot) from the set of candidate slots. A WTRU may not exclude relevant candidate slots if it monitors the most recent period. A WTRU may not exclude relevant candidate slots if it monitors over the duration of a (pre-configured) booking interval. If a WTRU does not monitor the most recent period of a booking interval, it may exclude relevant candidate slots. In some examples, a WTRU may exclude relevant candidate slots if it does not monitor the (pre-configured) duration of a booking interval.

[0154] A WTRU can determine whether to exclude a slot (e.g., one slot) from a set of candidate slots based on the set of reservation intervals that the WTRU can monitor. In some examples, a WTRU can determine whether to exclude a slot (e.g., one slot) from a set of candidate slots based on the set of reservation intervals that the WTRU can monitor. A WTRU may (pre-configure) a set of reservation intervals to monitor for periodic partial sensing. A WTRU may skip one or more reservation intervals. A WTRU can determine whether to exclude the associated candidate slot from resource selection based on the set of reservation intervals that the WTRU may have skipped. If a WTRU skips a reservation interval (e.g., one reservation interval) from a set of reservation intervals that the WTRU has (pre-configured), the WTRU may exclude the associated candidate slot. A WTRU may exclude the associated candidate slot if the number of skipped reservation intervals is greater than a threshold. Thresholds may be configured (in advance) within the resource pool and / or determined based on one or more of the following: TB QoS, traffic type (e.g., periodic or aperiodic traffic), TB HARQ type, or resource pool CBR.

[0155] A WTRU can determine a set of reservation intervals to monitor. The WTRU can make this determination before receiving a resource selection trigger. In some examples, a WTRU may (pre-configure) a set of reservation intervals (e.g., one set) to monitor before performing resource selection within a set of candidate slots. A WTRU can split a set of reservation intervals into multiple subsets (e.g., two subsets). For one of these subsets of reservation intervals, the WTRU can perform sensing before packet arrival. For another subset of reservation intervals, the WTRU can perform sensing after packet arrival. This can provide support for periodic-based partial sensing in the case of aperiodic traffic.

[0156] A WTRU can perform periodic sensing before packet arrival. For example, a WTRU may perform periodic sensing before packet arrival for periodic partial sensing resource selection, and / or follow a sensing pattern. A WTRU can perform sensing of Y slots (e.g., Y consecutive slots) every 100ms. By performing such sensing, a WTRU can detect a reservation interval of k*100ms. The Y consecutive slots (e.g., each of the future Y consecutive slots) may be a set of Y candidate slots that could be used for resource selection.

[0157] The WTRU may decide whether to trigger resource selection. The WTRU may make such a decision before a potential set of candidate slots. The WTRU may make this decision based on the time gap between the packet arrival time and the potential set of candidate slots, the reservation interval that the WTRU can monitor (e.g., the required reservation interval), and / or the size of the continuous sensing window. For example, if the time gap between the packet arrival time and the potential set of candidate slots is greater than the monitored continuous sensing window (e.g., the required continuous sensing window) and reservation interval (e.g., the required reservation interval), the WTRU may trigger resource selection before a set of Y candidate slots. Otherwise, the WTRU may wait for the next set of Y candidate slots.

[0158] Figure 7 shows an example of a WTRU that determines whether to trigger resource allocation before a potential set of Y candidate slots. As shown in Figure 7, the WTRU can perform periodic sensing of Y candidate slots every 100ms. The sensing subwindow (e.g., all sensing subwindows) may be a potential set of Y candidate slots. The WTRU can trigger resource selection before a first set of Y candidate slots if the packet arrives at time x1 or earlier. The WTRU can trigger resource selection before a second set of Y candidate slots if, for example, the packet arrives at time x2.

[0159] A WTRU can determine whether to perform periodic partial sensing before or after a resource selection trigger. A WTRU can determine whether to perform periodic partial sensing (e.g., further sensing) after a resource selection trigger (e.g., slot n). A WTRU can determine whether to perform periodic partial sensing (e.g., further sensing) based at least on the reserved interval of the monitored resource and / or the time gap between the resource selection trigger and the candidate slot window. For example, if the time gap between the resource selection trigger and the candidate slot window is greater than a threshold, a WTRU can perform periodic partial sensing (e.g., further sensing). A WTRU can perform periodic partial sensing after a resource selection trigger. The threshold may be determined based on the reserved interval of the monitored resource for periodic partial sensing (e.g., the required reserved interval).

[0160] A WTRU may be configured to determine a short-term partial sensing window. For example, a WTRU may determine a short-term partial sensing window (e.g., continuous sensing) to detect aperiodic transmissions from another WTRU. A WTRU may trigger resource (re)selection, preemption, and / or resource reevaluation in slot n, for example. A WTRU may perform short-term partial sensing within the window [n+TA, n+TB]. A WTRU may determine the values ​​of TA and / or TB. The values ​​of TA, TB, and / or TB-TA may be determined based on one or more of the following: whether semi-persistent reservations are enabled or disabled in the resource pool, whether the WTRU performs long-term partial sensing of TB, the HARQ type of TB, or whether DRX is configured for Rx WTRUs and / or Tx WTRUs.

[0161] The values ​​of TA, TB, and / or TB-TA may be determined based on whether semi-persistent reservations are enabled or disabled in the resource pool. In some examples, TA may be a fixed number of slots that can be used to account for WTRU processing time, for example, when semi-persistent reservations are disabled in the resource pool. In some examples, TA may be set to a value of 0 or 1 slot for a 15 kHz subcarrier interval. For example, TB-TA may be selected to be a fixed number of slots (e.g., 31 slots).

[0162] The values ​​of TA, TB, and / or TB-TA may be determined based on whether semi-persistent reservations are enabled or disabled in the resource pool. In some examples, a WTRU may perform long-term partial sensing to monitor semi-persistent resource reservations from another WTRU if semi-persistent reservations are enabled in the resource pool. A WTRU may determine TA, TB, and / or TB-TA based on the position of a set of Y candidate slots for resource selection. For example, a short-term partial sensing window may be located before a set of Y candidate slots.

[0163] The values ​​of TA, TB, and / or TB-TA may be determined based on whether the WTRU performs long-term partial sensing of TB. If the WTRU performs long-term partial sensing of TB, the short-term partial sensing may be located immediately before the set of Y candidate slots. In some examples, the short-term partial sensing window may be located immediately after resource selection trigger slot n, for example, if the WTRU does not perform long-term partial sensing of TB.

[0164] The values ​​of TA, TB, and / or TB-TA may be determined based on the HARQ type of the TB, for example, whether the TB is HARQ-enabled or HARQ-incompatible. The WTRU may be (pre-configured) with the TB-TA values ​​(e.g., two values). One value may be used for the HARQ-enabled TB, and the other value may be used for the HARQ-incompatible TB.

[0165] The values ​​of TA, TB, and / or TB-TA can be determined based on whether the DRX is configured to Rx WTRU and / or Tx WTRU. The WTRU may be (pre-configured) with a set of short-term partial sensing windows (e.g., two sets) based on whether the DRX is configured to Tx WTRU and / or Rx WTRU. The WTRU can determine, for example, which set of short-term partial sensing to use based on whether the DRX is configured to Tx WTRU and / or Rx WTRU.

[0166] The WTRU may determine the set of selectable resources. In some examples, the WTRU can determine the minimum size (e.g., X min%) of the set of selectable resources for resource selection based on one or more of the TB's HARQ type or DRX configuration (e.g., DRX for Tx and / or Rx). The WTRU may (pre-configure) X min% sets (e.g., two sets). The first set may be used for HARQ-enabled TBs, and the second set for non-HARQ-enabled TBs. The WTRU can determine which X min% set to use based on the TB's HARQ type.

[0167] The WTRU can determine the minimum size (e.g., X min%) of the set of selectable resources for resource selection based on the DRX configuration. For example, the WTRU may be pre-configured with X min% of a set (e.g., two sets). The first set can be used when the DRX is configured as a Tx WTRU and / or Rx WTRU, and the second set can be used when the DRX is not configured as a Tx WTRU and / or Rx WTRU.

[0168] A WTRU can decide whether to select a set of selectable slots from a set of Y candidate slots. In some examples, a WTRU can decide whether to select a set of selectable slots from a set of Y candidate slots based on whether there are Ymin candidate slots in the WTRU's PDB, which may be a subset of Y. For example, if there are Ymin candidate slots in TB's PDB, the WTRU can select a set of selectable slots from a set of Y candidate slots. If the set of candidate slots in the PDB is smaller than a threshold (e.g., less than Ymin), the WTRU can select a set of selectable slots both within and outside the set of Ymin candidate slots.

[0169] Figure 8 shows an exemplary selection of selectable slots outside the set of candidate slots. As shown in Figure 8, in Option 1, the set of Ymin candidate slots is within the PDB of the WTRU. In Option 1, the WTRU can determine the set of selectable slots as the set of Y candidate slots. In Option 2, the set of Ymin candidates extends beyond the PDB of the TB. In Option 2, the WTRU can select a set of candidate slots that is both within and outside the set of Y candidate slots. As shown in Figure 8, the WTRU can select a set of Y candidate slots within the window [n+TC,n+PDB].

[0170] In some cases, if the earliest set of Ymin candidate slots is not within the range to satisfy the TB's QoS, the WTRU may do one or more of the following: The WTRU may reduce the number of retransmission resources for the TB. For example, the WTRU may be (pre-configured) with a maximum number of retransmission resources per Ymin. The WTRU may determine the number of resources available for selection based, for example, on how many Ymin candidate slots the WTRU can have in the TB's PDB. A WTRU can lower the priority of a TB. For example, a WTRU may (pre-configure) Ymin for each priority of a TB. A WTRU can decide which priority to put into the SCI based on the number of Ymin candidate slots in the TB's PDB. A WTRU can indicate sensing information via the SCI. For example, a WTRU can indicate via the SCI that it does not have enough sensing information. Other WTRUs can avoid such resources by triggering preemption and / or resource reevaluation. A WTRU can drop a TB. A WTRU can switch to a different resource selection scheme (e.g., a random resource allocation scheme). For example, a WTRU can switch to a random resource selection scheme if it fails to find Ymin candidate slots in the TB's PDB. A WTRU can perform resource selection for a TB in another resource pool (e.g., an exceptional resource pool).

[0171] WTRU can determine which slots trigger resource (re)selection. In some examples, WTRU can trigger resource selection for at least T slots before a set of Y candidate slots. WTRU can determine whether to trigger resource selection based on the time gap between the intended trigger slot and the set of Y candidate slots.

[0172] A WTRU can determine whether to select a set of selectable slots from a set of Y candidate slots for aperiodic traffic. In some examples, a WTRU can determine, based on one or more conditions, whether to select a set of selectable slots within a set of Y candidate slots, or both within and outside a set of Y candidate slots. A WTRU can determine whether to select a set of selectable slots within a set of Y candidate slots for a resource (re)selection process (e.g., for aperiodic TB) based on one or more of the following: a given mechanism, preconfiguration, QoS of the TB, remaining PDBs of the TB, time gap between the resource (re)selection trigger slot and the set of Y candidate slots, CBR of the resource pool, HARQ type of the TB, whether SL-DRX is configured in the WTRU, the number of transmit resources that the WTRU can select, the number of candidate slots, or the number of available resources within the Y candidate slots.

[0173] Whether the set of selectable slots is selected from a set of Y candidate slots may be determined in advance for the WTRU. For example, the WTRU may decide not to limit the set of selectable slots to a set of Y candidate slots for aperiodic traffic, regardless of, for example, the location of a set of Ymin candidate slots.

[0174] The WTRU may be configured (pre-configured) on a per-resource pool basis to determine whether it can limit the set of selectable slots to a set of Y candidate slots for aperiodic transmissions. The WTRU may be configured (pre-configured) not to limit the set of selectable slots to a set of Y candidate slots for aperiodic transmissions. The WTRU can, for example, select a set of selectable slots independently of the Y candidate slots. In some examples, the WTRU may be configured (pre-configured) to limit the set of selectable slots to a set of Y candidate slots for aperiodic transmissions. WTRU can, for example, limit the set of selectable slots to a set of Y candidate slots if there are Y candidate slots in the resource selection window.

[0175] The WTRU can decide, based on the TB's QoS, whether to select a set of selectable slots from a set of Y candidate slots, or to select both within and outside the set. For example, for aperiodic traffic, the WTRU can limit the set of selectable slots to a set of Y candidate slots if the TB's priority is below a threshold. Otherwise, the WTRU can not limit the set of selectable slots to a set of Y candidate slots. The threshold (e.g., priority value threshold) may be configured (pre-configured) for each resource pool. By making decisions based on the TB's priority being below a threshold, collisions with high-priority TBs can be reduced. For aperiodic traffic, the WTRU can limit the set of selectable slots to a set of Y candidate slots if the TB's priority is above a threshold. Otherwise, WTRU can not limit the set of selectable slots to a set of Y candidate slots. A threshold (e.g., a priority value threshold) can be configured (pre-configured) for each resource pool. The resource selection window for high-priority TBs can be increased by making decisions based on whether the priority of a TB is greater than the threshold.

[0176] The WTRU can decide, based on the remaining PDBs in the TB, whether to select a set of selectable slots within a set of Y candidate slots, or to select both within and outside of the set of Y candidate slots. For example, if the remaining PDBs in the TB are less than a threshold, the WTRU can limit the set of selectable slots to a set of Y candidate slots. If the remaining PDBs in the TB are greater than a threshold, the WTRU can not limit the set of selectable slots to a set of Y candidate slots. The remaining PDB threshold may be configured (pre-configured) for each resource pool. The WTRU can limit the set of selectable slots to a set of Y candidate slots if the remaining PDBs in the WTRU are greater than a threshold. If the remaining PDBs in the WTRU are less than a threshold, the WTRU can not limit the set of selectable slots to a set of Y candidate slots. The remaining PDB threshold may be configured (pre-configured) for each resource pool.

[0177] The WTRU can determine whether to select a set of selectable slots within the set of Y candidate slots, or both within and outside the set of Y candidate slots, based on the time gap between the resource (re)selection trigger slot and the set of Y candidate slots. For example, if the time gap between resource (re)selection trigger n and the Y candidate slots is within a range (e.g., greater than a first threshold and less than a second threshold), the WTRU can limit the set of selectable slots to the set of Y candidate slots. If the time gap is outside a range, the WTRU can choose not to limit the set of selectable slots to the set of Y candidate slots. The time gap threshold range can be configured (pre-configured) for each resource pool. The time gap threshold range may be based on the QoS of TB.

[0178] The WTRU can determine whether to select a set of selectable slots within a set of Y candidate slots, or both within and outside a set of Y candidate slots, based on the time gap between the resource (re)selection trigger and the window of Y candidate slots. The time gap between the resource (re)selection trigger and the window of Y candidate slots may include the time gap between the resource (re)selection trigger (e.g., slot n) and the first slot of the Y candidate slots, and / or the time gap between slot n and the last slot of the Y candidate slots. For example, if the time gap between slot n and the Y candidate slots is less than a threshold, the WTRU may limit the set of selectable slots to within Y candidate slots. If the time gap between slot n and the Y candidate slots is greater than a threshold, the WTRU may not limit the set of selectable slots to within Y candidate slots. The time gap threshold may be configured (pre-configured) based on the remaining PDBs of the TB. The WTRU may limit the set of selectable slots to within a set of Y candidate slots if a set of Y min candidate slots is within the resource selection window. Alternatively, if there is no set of Ymin candidate slots within the resource selection window, WTRU may not limit the set of selectable slots to a set of Y candidate slots. In such cases, the set of selectable slots may be both within and outside the set of Y candidate slots.

[0179] The WTRU can determine, based on the resource pool's CBR, whether to select a set of selectable slots within a set of Y candidate slots, or within and outside of a set of Y candidate slots. For example, if the resource pool's CBR is greater than a threshold, the WTRU can limit the set of selectable slots to a set of Y candidate slots. Otherwise, the WTRU can choose not to limit the set of selectable slots to a set of Y candidate slots. The CBR threshold may be configured (pre-configured) for each resource pool. The CBR threshold may be based on the TB's QoS. If the resource pool's CBR is less than a threshold, the WTRU can limit the set of selectable slots to a set of Y candidate slots. Otherwise, the WTRU can choose not to limit the set of selectable slots to a set of Y candidate slots. The CBR threshold may be configured (pre-configured) for each resource pool based on the TB's QoS.

[0180] The WTRU can determine, based on the TB's HARQ type, whether to select a set of selectable slots from a set of Y candidate slots, or from both a set of Y candidate slots and outside of a set. For non-HARQ-enabled TBs, the WTRU can limit the set of selectable slots to a set of Y candidate slots. However, for HARQ-enabled TBs, the WTRU can choose not to limit the set of selectable slots to a set of Y candidate slots. If the TB's HARQ type is HARQ-enabled, the WTRU can limit the set of selectable slots to a set of Y candidate slots. However, for non-HARQ-enabled TBs, the WTRU can choose not to limit the set of selectable slots to a set of Y candidate slots.

[0181] The WTRU can decide whether to select a set of selectable slots from a set of Y candidate slots, or from within and outside a set of Y candidate slots, based on whether the SL-DRX is configured in the WTRU. If the SL-DRX is (pre-)configured in the WTRU, the WTRU can limit the set of selectable slots to a set of Y candidate slots. Otherwise, if the SL-DRX is not (pre-)configured in the WTRU, the WTRU can not limit the set of selectable slots to a set of Y candidate slots. In some examples, if the SL-DRX is (pre-)configured in the WTRU, the WTRU can not limit the set of selectable slots to a set of Y candidate slots. If the SL-DRX is not (pre-)configured in the WTRU, the WTRU can limit the set of selectable slots to a set of Y candidate slots.

[0182] The WTRU can decide whether to select a set of selectable slots from a set of Y candidate slots, or from within and outside a set of Y candidate slots, based on whether the SL-DRX is (pre) configured in the target Rx WTRU. If the SL-DRX is (pre) configured in the target WTRU, the WTRU can limit the set of selectable slots to a set of Y candidate slots. Otherwise, if the SL-DRX is not (pre) configured in the target Rx WTRU, the WTRU can choose not to limit the set of selectable slots to a set of Y candidate slots. If the SL-DRX is (pre) configured in the target WTRU, the WTRU can choose not to limit the set of selectable slots to a set of Y candidate slots. Otherwise, if the SL-DRX is not (pre) configured in the target Rx WTRU, the WTRU can choose not to limit the set of selectable slots to a set of Y candidate slots.

[0183] A WTRU can decide whether to select a set of selectable slots within a set of Y candidate slots, or within and outside of a set of Y candidate slots, based on the number of transmit resources that the WTRU can select. For example, if the number of transmit resources that the WTRU can select is less than a threshold, the WTRU can limit the set of selectable slots to a set of Y candidate slots. If, however, the number of transmit resources that the WTRU can select is greater than the threshold, the WTRU can choose not to limit the set of selectable slots to a set of Y candidate slots. The threshold for the number of transmit resources may be configured (in advance) for each resource pool. The threshold for the number of transmit resources may be based on the number of slots in Y or the number of available resources in Y.

[0184] Based on the number of slots in Y, WTRU can decide whether to select a set of selectable slots from a set of Y candidate slots, or from both a set of Y candidate slots and outside of that set. For example, if the number of slots in Y is greater than a threshold, WTRU can limit the set of selectable slots to a set of Y candidate slots. Conversely, if the number of slots in Y is less than a threshold, WTRU can choose not to limit the set of selectable slots to a set of Y candidate slots. Thresholds can be configured (pre-configured) for each resource pool.

[0185] WTRU can determine, based on the number of available resources in Y, whether to select a set of selectable slots from a set of Y candidate slots, or from both a set of Y candidate slots and outside of that set. For example, if the number of available resources in Y is greater than a threshold, WTRU can limit the set of selectable slots to a set of Y candidate slots. If the number of available resources in Y is less than a threshold, WTRU can not limit the set of selectable slots to a set of Y candidate slots. Thresholds can be configured (in advance) for each resource pool.

[0186] If the time gap between a resource (re)selection trigger slot (e.g., slot n) and the first slot of Ymin candidate slots is greater than a threshold, and Ymin slots are within the resource selection window of the resource (re)selection process, the WTRU may limit the set of selectable slots to the set of Ymin candidate slots. A time gap threshold may be provided so that the WTRU has enough slots to perform short-term partial sensing (e.g., the threshold may be fixed to 31 slots plus some WTRU processing time).

[0187] WTRU may not limit the set of selectable slots to the set of Ymin candidate slots if the time gap between slot n and the set of Ymin candidate slots is smaller than a threshold. The set of selectable slots may include slots within and outside the range of Ymin. The set of selectable slots may include slots within and outside the range of Ymin if the set of Ymin candidate slots is outside the resource selection window (e.g., [n+T1, n+T2]).

[0188] A WTRU can determine whether to initialize a period-based partial sensing (PBPS) for a non-periodic TB. In some examples, a WTRU can initialize a PBPS (e.g., a new PBPS) based on a resource (re)selection trigger in slot n for a TB. A WTRU can initialize a PBPS (e.g., a new PBPS) by performing one or more of the following based on the sensing results of the monitored slot: monitoring one or more reservation periods between resources, or performing resource exclusions.

[0189] The WTRU may decide whether to initialize a PBPS (e.g., a new PBPS for resource (re)selection triggered in slot n, which may be for a non-periodic TB) based on one or more of the following: whether the WTRU has an existing PBPS and / or the position of a set of Y candidate slots in the current PBPS; a set of monitored reservation periods (e.g., required reservation periods) and / or the remaining set of monitored reservation periods (e.g., required reservation periods); whether a short-term partial sensing window includes a (pre-configured) reservation period; the QoS of the TB, the HARQ type of the TB, whether an SL-DRX is (pre-configured) in the WTRU, whether an SL-DRX is (pre-configured) in the target Rx WTRU, or whether the process is used for initial resource allocation or for re-evaluation and / or preemption.

[0190] The WTRU can determine whether to initialize a PBPS (e.g., a new PBPS) for resource (re)selection triggered in slot n, based on whether the WTRU has an existing PBPS and / or the position of the set of Y candidate slots for the current PBPS. In some examples, the WTRU may choose not to start a PBPS process (e.g., a new PBPS process) if the WTRU has an existing PBPS process and the set of Y candidate slots is within the WTRU's resource selection window. The WTRU may also choose not to start a PBPS process (e.g., a new PBPS process) if the WTRU does not have an existing PBPS and / or the set of Y candidate slots is outside the resource selection window.

[0191] A WTRU can decide whether to initialize a PBPS (e.g., a new PBPS) based on the set of monitored reservation periods (e.g., required reservation periods) and / or the remaining set of monitored reservation periods (e.g., required reservation periods). For example, a WTRU can initialize a PBPS (e.g., a new PBPS) for TB resource allocation if the remaining set of monitored reservation periods is in the WTRU's PDB. Otherwise, the WTRU may choose not to initialize the PBPS (e.g., a new PBPS).

[0192] A WTRU can determine whether to initialize a PBPS (e.g., a new PBPS) based on whether a short-term partial sensing window includes a (pre-configured) reservation period. For example, a WTRU can determine whether to initialize a PBPS process for aperiodic TB resource (re)allocation based on whether a short-term partial sensing window includes a (pre-configured) reservation period. A WTRU can monitor a set of reservation periods for aperiodic TB resource (re)selection. A WTRU may choose not to initialize a PBPS (e.g., a new PBPS) if the short-term partial sensing window includes the monitored set of reservation periods (e.g., all required reservation periods). A WTRU may, for example, initialize a PBPS process (e.g., a new PBPS process) if the short-term partial sensing does not include one or more monitored reservation periods (e.g., required reservation periods).

[0193] WTRU can decide whether to initialize a PBPS (e.g., a new PBPS) based on the TB's QoS (e.g., TB's priority and / or remaining PDBs). For example, WTRU can initialize a PBPS process (e.g., a new PBPS process) if the WTRU's remaining PDBs are greater than a threshold. Otherwise, WTRU may choose not to initialize a PBPS process (e.g., a new PBPS process). Thresholds can be configured (in advance) for each resource pool.

[0194] The WTRU can decide whether to initialize a PBPS (e.g., a new PBPS) based on the TB's HARQ type. For example, the WTRU may initialize a PBPS process (e.g., a new PBPS process) for non-HARQ-enabled TBs, but may not initialize a PBPS (e.g., a new PBPS) for HARQ-enabled TBs.

[0195] The WTRU can decide whether to initialize the PBPS (e.g., a new PBPS) based on whether the SL-DRX is (pre-) configured in the WTRU. For example, if SL-DRX is (pre-configured) to be a WTRU, it is possible for the WTRU not to initialize the PBPS (e.g., a new PBPS). If SL-DRX is not (pre-configured) to be a WTRU, the WTRU can initialize the PBPS process (e.g., a new PBPS process).

[0196] The WTRU can decide whether to initialize the PBPS (e.g., a new PBPS) based on whether the SL DRX is (pre-configured) on the target Rx WTRU. For example, if the TB targets a WTRU that has the SL DRX (pre-configured), the WTRU may choose not to initialize the PBPS (e.g., a new PBPS). Otherwise, the WTRU may initialize the PBPS process (e.g., a new PBPS process).

[0197] The WTRU can decide whether to initialize a PBPS (e.g., a new PBPS) based on whether the process will be used for initial resource allocation or for re-evaluation and / or preemption. For example, the WTRU may decide to start a PBPS process (e.g., a new PBPS process) for initial resource (re)selection. The WTRU may decide not to start a PBPS process (e.g., a new PBPS process) for resource re-evaluation and / or preemption checks.

[0198] The WTRU may prioritize the selection of transmission resources from a set of Y candidate slots. The WTRU may prioritize the selection of transmission resources that have sensing results (e.g., CPS results and / or PBPS results). In some examples, the WTRU may prioritize the selection of transmission resources that have both PBPS and CPS sensing results. In some examples, the WTRU may prioritize the selection of resources that have either CPS or PBPS sensing results. The WTRU may decide to select several transmission resources for a TB (e.g., one TB) and / or resource allocation process (e.g., one resource allocation process) that have PBPS and / or CPS sensing results. The WTRU may prioritize the selection of X transmission resources that have PBPS and / or CPS sensing results by, for example, selecting X resources in a slot that have PBPS and / or CPS sensing results (e.g., randomly selecting them). The maximum, minimum, and / or number (e.g., exact number) of selectable transmission resources having PBPS and / or CPS sensing results may be based on one or more of the following: (pre-determined) QoS of TB, or the number of available resources / slots having PBPS and / or CPS sensing results.

[0199] In some examples, the maximum, minimum, and / or exact number (e.g., exact number) of transmission resources to be selected that have PBPS and / or CPS sensing results may be determined, for example, based on a prior determination. The WTRU may prioritize the selection of X (e.g., X=1) transmission resources that have PBPS sensing results. In some examples, the WTRU may prioritize the selection of X (e.g., X=1) transmission resources that may have CPS sensing results. The WTRU may prioritize the selection of X transmission resources that may have either CPS or PBPS sensing results. The WTRU may prioritize the selection of X transmission resources that have both CPS and PBPS sensing results (e.g., both CPS and PBPS sensing results). The WTRU may, for example, select X transmission resources (e.g., those with PBPS and / or CPS sensing results) and then select the remaining resources for transmission in set A (e.g., randomly).

[0200] In some examples, the maximum, minimum, and / or exact number (e.g., the exact number) of selectable transmit resources having PBPS and / or CPS sensing results may be determined, for example, based on TB's QoS. WTRU may prioritize the selection of X transmit resources having PBPS and / or CPS sensing results. The value of X may be (pre-configured) based on TB's QoS (e.g., TB's priority and / or TB's PDB).

[0201] In some examples, the maximum, minimum, and / or exact number of selectable transmit resources having PBPS and / or CPS sensing results may be determined, for example, based on the number of available resources and / or slots having PBPS and / or CPS sensing results. The WTRU can determine the number of selectable transmit resources having PBPS and / or CPS sensing results based, for example, on the number of available resources and / or slots having PBPS and / or CPS sensing results. The WTRU may, for example, prioritize the selection of X transmit resources having PBPS and / or CPS sensing results if the number of resources and / or slots having PBPS and / or CPS sensing results is greater than a threshold. Otherwise, the WTRU may refrain from prioritizing (e.g., not prioritizing) the selection of transmit resources having PBPS and / or CPS sensing results. The threshold may be configured (pre-configured) based on the priority of the TB and / or CBR of the resource pool.

[0202] A WTRU may, for example, prioritize the selection of a transmit resource within a set of Y candidate slots (e.g., with PBPS sensing results) when the WTRU initiates a resource (re)selection process (e.g., for aperiodic traffic). The WTRU may select several transmit resources within the set of Y candidate slots. The number of transmit resources that the WTRU can select may be based on one or more of the following: the size of the Y candidate slots, the QoS in TB, the remaining PDBs in TB, or the CBR of the resource pool.

[0203] In some examples, a WTRU can select a transmission resource either within or outside of a set of Y candidate slots, for example, if the number of resources that the WTRU can select is greater than the number of resources that the WTRU has selected within a set of Y candidate slots.

[0204] In one example, the WTRU can determine one or more windows for initializing a set of resources available for resource selection (e.g., set SA). The windows may be determined based on one or more of the following: a set of Y candidate slots in the resource selection window (e.g., the number of Y candidate slots exceeds a threshold, as described herein), QoS of TB, or a continuous partial sensing window.

[0205] The window may be determined based on a set of Y candidate slots within the resource selection window. For example, WTRU may be (pre-configured) to include at least a certain number of slots (e.g., a number of slots above a threshold) from a set of Y candidate slots (e.g., all of the Y candidate slots, or X% of the Y candidate slots) within the resource selection window. WTRU can choose to include a (pre-configured) number of slots from the set of Y candidate slots within the resource selection window for initializing set SA. In some examples, WTRU may preferentially include these slots from the set of Y candidate slots within the resource (re)selection window.

[0206] The window can be determined based on the TB's QoS. For example, the WTRU may have a minimum window size configured (in advance) for initializing a set SA. The WTRU can then determine the set SA based on the (in advance) configured minimum window size.

[0207] The window may be determined based on a continuous partial sensing window. In some examples, the WTRU may include at least a certain number of slots that have CPS results. The set of slots with CPS results may be the 31 slots after the CPS window (e.g., the next 31 slots). The WTRU may select at least X% of the 31 slots. The WTRU may include at least a certain number of slots after the CPS window. The WTRU may preferentially include resources with CPS results (e.g., slots with a time gap of no more than 31 slots from the last slot in the CPS window).

[0208] Figure 9 shows an example of a WTRU initializing a set of selectable slots. As shown in Figure 9, a WTRU may also be able to select a window. A window can contain a set of selectable slots within a resource allocation window for initializing a set of selectable resources (e.g., set SA). A WTRU can determine a set of selectable slots based on one or more sets of slots having CPS results or sets of slots having PBPS results.

[0209] In some examples, WTRU can select a set of selectable slots in the resource (re)selection window that includes slots with CPS results (e.g., all slots) and slots with PBPS results (e.g., all slots). WTRU can select a set of selectable slots in the resource (re)selection window that includes slots with CPS results (e.g., all slots). WTRU can select a set of selectable slots (e.g., a set of Y candidate slots) that includes slots with PBPS results (e.g., all slots).

[0210] The WTRU can prioritize slots with PBPS sensing results and / or CPS sensing results from a set of Y' candidate slots. For example, if the number of slots with PBPS sensing results and / or CPS sensing results is smaller than a (pre-configured) value Y'min, the WTRU can select slots without sensing results from the set of Y' candidate slots in the Resource Selection Window (RSW). The WTRU can preferentially include slots that are earlier in time in the set of Y' candidate slots. In some examples, the WTRU can preferentially include slots with PBPS sensing results in the set of Y' candidate slots (e.g., first). The WTRU may preferentially include slots with PBPS sensing results or CPS sensing results in the set of Y' candidate slots (e.g., after preferentially including slots with PBPS sensing results in the set of Y' candidate slots). WTRU may include in the set of Y' candidate slots slots slots that do not have PBPS or CPS sensing results (for example, slots with PBPS sensing results, then slots with PBPS sensing results or CPS sensing results) in the set of Y' candidate slots.

[0211] WTRU can initialize set A (for example, based on slots that have CPS results) when CPS is performed. WTRU can include (for example, initially include) X slots or X% of slots that have CPS results in a set of Y' candidate slots. WTRU can include additional slots in the set of Y' candidate slots (for example, after including X slots or X% of slots that have CPS results in the set of Y' candidate slots) until Y' ≥ Y'min. The value of X or X% may be predetermined (for example, X may include all slots with CPS results in the RSW) and / or configured (in advance).

[0212] The WTRU may be (pre-configured) to select Y'≧Y'min candidate slots within the RSW to initialize a set of candidate resources (e.g., set SA). For example, if Y'min candidate slots are not filled, WTRU behavior may be provided. The WTRU may perform one or more of the following: drop the TB and / or drop it from another resource pool and / or perform a transmission in another resource pool (e.g., an exceptional resource pool); reduce the number of (re)transmissions of the TB, for example, change from a semi-persistent reservation to a non-periodic transmission if the required CPS sensing window is (pre-configured) for a semi-persistent reservation; or, for example, perform a random resource selection for the TB if the resource pool allows random resource allocation.

[0213] The WTRU can determine whether to run CPS (for example, for non-periodic traffic in a resource pool with semi-persistent reservations enabled) based on one or more of the following: the time gap between the resource (re)selection trigger (e.g., slot n) and the set of Ymin candidate slots in the resource (re)selection window, the QoS of the TB, or the HARQ type of the TB. If the time gap between slot n and the set of Ymin candidate slots is smaller than the threshold, the WTRU can skip CPS. The WTRU can initialize the set of selectable slots in the set of Y candidate slots. The WTRU can start CPS if the priority of the TB is greater than the threshold and / or the remaining PDBs of the TB are less than the threshold. Otherwise, the WTRU may not start CPS for resource (re)selection for the TB. The WTRU can start CPS if the priority of the TB is less than the threshold and / or the remaining PDBs of the TB are greater than the threshold. Otherwise, the WTRU may not start CPS for resource (re)selection for the TB. In some cases, a WTRU can initiate a CPS for non-HARQ-enabled TBs. A WTRU may choose not to initiate a CPS for HARQ-enabled TBs.

[0214] In some examples, a WTRU can determine a short-term partial sensing window (for example, for non-periodic traffic in a resource pool where semi-persistent reservations are enabled) based on whether the WTRU has a set of Ymin candidate slots within the resource selection window, the time gap between the resource (re)selection trigger slot and the Ymin candidate slots, or one or more of the QoS of TB and / or the remaining PDBs of TB.

[0215] A WTRU can determine the short-term partial sensing window based on whether the WTRU has a set of Ymin candidate slots within a resource selection window. If the WTRU has Ymin candidate slots within a window (e.g., a resource (re)selection window), the short-term partial sensing window can be placed before (e.g., immediately before) the set of Y candidate slots, taking into account the WTRU processing time. If the WTRU does not have a set of Ymin candidate slots within a window (e.g., a resource (re)selection window), the short-term partial sensing window can be placed after (e.g., immediately after) resource (re)selection trigger slot n, taking into account the WTRU processing time. In some examples, if the WTRU has a set of Ymin candidate slots within a resource (re)selection window, the WTRU can determine the position of the short-term partial sensing window based on the position of the Ymin candidate slots. For example, the WTRU can use the first slot of the set of Ymin candidate slots as a reference time for determining the short-term partial sensing window. For example, WTRU can determine n+TB as n+ty0-Tproc, where n+TB is the last slot for short-term partial sensing, n+ty0 is the first slot in a set of Ymin candidate slots, and Tproc is a parameter for considering WTRU processing time. In such cases, n+TA can be determined based on the size of the short-term partial sensing window. In some examples, WTRU can determine the position of the short-term partial sensing window based on the resource (re)selection trigger time if WTRU does not have a set of Ymin candidate slots within the resource (re)selection window. For example, WTRU can determine n+TA based on n+Tproc, where n+TA is the first slot in the short-term partial sensing window, and Tproc can be used to consider WTRU processing time.

[0216] A WTRU can determine a short-term partial sensing window based on the time gap between a resource (re)selection trigger slot and Ymin candidate slots. Figure 10 shows an example of a WTRU that determines a short-term partial sensing window. As shown in Figure 10, a WTRU can determine a short-term partial sensing window based on the time gap between a resource (re)selection trigger slot and Ymin candidate slots. For example, in the first case (e.g., Case 1 in Figure 10), if the time gap between slot n and Ymin candidate slots is greater than a threshold (e.g., greater than X0 = 31 slots + Tproc), the short-term partial sensing may be fixed (e.g., 31 slots) and placed before (e.g., immediately before) the set of Ymin candidate slots. In the second case (e.g., Case 2 in Figure 10), if the time gap between slot n and Ymin candidate slots is greater than a threshold (e.g., X1 in the figure) and less than another threshold (e.g., X0), the short-term partial sensing may be determined based on the time gap between slot n and the set of Ymin candidate slots. In the third case (for example, case 3 in Figure 10), if the time gap between slot n and the set of Ymin candidate slots is smaller than a threshold (e.g., X1), the WTRU may decide to perform one or more of the following: not perform short-term partial sensing and initialize a set of selectable resources (e.g., set SA) within the set of Ymin candidate slots; and, taking into account the WTRU processing time (e.g., n+Tproc), perform short-term partial sensing on a (pre-configured) number of slots immediately following slot n (e.g., 31 slots) and initialize a set of selectable resources (e.g., set SA) after the short-term partial sensing window, which may include resources outside the Ymin candidate slots and possibly resources within the Ymin candidate slots. The WTRU may include a set of selectable slots within a window [n+TB+Tproc, n+TC], where TB may be the last slot in the short-term partial sensing window, and TC may be surrounded by T2 and PDB of TB. WTRU can determine a short-term partial sensing window based on the QoS of TB and / or the remaining PDB of TB.

[0217] A WTRU can determine whether to exclude a slot in an RSW based, for example, on an unmonitored slot within a PBPS window. A WTRU may (pre-configure) a set of reservation periods and / or a set of sensing opportunities for each relevant slot in the RSW (e.g., each relevant slot). A WTRU may choose not to monitor one or more opportunities over one or more reservation periods.

[0218] The WTRU may decide whether to exclude a relevant slot based on one or more of the following: prior determination, traffic type, whether DRX is configured for the WTRU, reservation periods and / or opportunities for reservation periods not monitored by the WTRU (e.g., one reservation period), whether the WTRU monitors a subset of reservation periods, whether the unmonitored slot is in DRX OFF time or DRX ON time, QoS of TB, CBR of the resource pool, remaining resources and / or slots after resource exclusion and / or slot exclusion, or whether the slot has CPS results.

[0219] The decision made by the WTRU regarding whether to exclude relevant slots may be predetermined. For example, if the WTRU is not monitoring the reservation period (e.g., the required reservation period), it may not exclude relevant slots in the resource selection window.

[0220] WTRU can determine whether to exclude relevant slots based on the traffic type (e.g., periodic or aperiodic traffic). In some examples, WTRU may exclude relevant slots in a set of Y candidate slots for periodic traffic if it does not monitor one or more (pre-configured) opportunities within one or more reservation periods (e.g., required reservation periods). For aperiodic traffic, WTRU may not exclude slots in a set of Y candidate slots.

[0221] The WTRU can decide whether to exclude the relevant slot based on whether the DRX is configured in the WTRU. For example, if the WTRU does not have an SL DRX configured, it can exclude the relevant slot. However, if an SL DRX is configured, the WTRU can choose not to exclude the relevant slot.

[0222] A WTRU can decide whether to exclude a relevant slot based on which reservation periods and / or which opportunities within those reservation periods (e.g., one reservation period) the WTRU is not monitoring. In some examples, a WTRU may (pre-configure) two sets of reservation periods. If a WTRU is not monitoring a reservation period in one set (e.g., one reservation period), the WTRU may exclude a relevant slot in the RSW. If a WTRU is not monitoring a reservation period in another set (e.g., one reservation period), the WTRU may not exclude a relevant slot in the RSW. In some examples, if more than X% of the reservation period is not monitored, the WTRU may exclude a relevant slot. If less than X% of the reservation period is monitored, the WTRU may not exclude a relevant slot. If multiple sensing opportunities are (pre-configured) for each reservation period, the WTRU can decide whether to exclude a relevant slot. A WTRU may exclude a relevant slot if the most recent sensing opportunity for one or more reservation periods is not monitored. WTRU may exclude a relevant slot if one or more pre-configured sensing opportunities for a reservation period are not monitored. WTRU may not exclude relevant slots if each (pre-configured) sensing opportunity within a (pre-configured) booking period (e.g., all (pre-configured) required booking periods) is monitored.

[0223] A WTRU can decide whether to exclude a relevant slot based on whether the WTRU monitors a subset of the reservation period. For example, a subset of the reservation period may be configured in the WTRU (in advance). If the WTRU does not monitor a subset of the reservation period, it may exclude a relevant slot. If the WTRU does monitor a subset of the reservation period, it may not exclude a relevant slot.

[0224] WTRU can decide whether to exclude a related slot based on whether the unsupervised slot is in DRX OFF time or DRX ON time. For example, WTRU may not exclude a related slot if the unsupervised slot falls within the DRX OFF period. WTRU may exclude a related slot if the unsupervised slot falls within the WTRU's DRX ON time.

[0225] WTRU can determine whether to exclude the relevant slot based on the TB's QoS. In some cases, WTRU can exclude the relevant slot if the TB's priority is greater than a threshold. WTRU can not exclude the relevant slot if the TB's priority is less than a threshold. WTRU can not exclude the relevant slot if the TB's priority is greater than a threshold. WTRU can exclude the relevant slot if the TB's priority is less than a threshold.

[0226] WTRU can determine whether to exclude related slots based on the resource pool's CBR. In some cases, WTRU can exclude related slots if the resource pool's CBR is greater than a threshold. WTRU can not exclude related slots if the resource pool's CBR is less than a threshold. In some cases, WTRU can not exclude related slots if the resource pool's CBR is greater than a threshold. WTRU can exclude related slots if the resource pool's CBR is less than a threshold.

[0227] WTRU can determine whether to exclude a relevant slot based on the remaining resources and / or slots after resource exclusion and / or slot exclusion. For example, WTRU may exclude a relevant slot in the RSW if the number of slots and / or resources remaining after exclusion is greater than X%. Otherwise, WTRU may choose not to exclude the relevant slot. The value of X may be configured (in advance) for each resource pool and / or QoS (e.g., TB priority).

[0228] WTRU can decide whether to exclude a relevant slot based on whether the slot has a CPS result. For example, WTRU may not exclude a relevant slot if it has a CPS result (e.g., the time gap between the last slot in the CPS window and the relevant slot is less than 31 slots). Conversely, if the relevant slot does not have a CPS result (e.g., the time gap between the last slot in the CPS window and the relevant slot is greater than 31 slots), WTRU may exclude the relevant slot.

[0229] A WTRU can determine whether to exclude relevant slots in the RSW due to one or more unmonitored slots within a CPS window. In some examples, a WTRU can determine which slots to exclude in the resource selection window if it does not monitor a slot (e.g., one slot) within a short-term partial sensing window (e.g., consecutive partial sensing windows). A WTRU may (pre-configure) a set of reservation periods to exclude due to unmonitored slots in a CPS. A WTRU can exclude slots that are equal in distance to one of the reservation periods in the (pre-configured) set of periods if it does not monitor a slot (e.g., one slot) within a CPS. In some cases, WTRU may not perform slot exclusion due to unsupervised slots within the CPS window.

[0230] The WTRU can decide whether to perform slot exclusion due to unsupervised slots in the CPS window based on one or more of the following: Exclusion of the relevant slot in the RSW can be predetermined. For example, if the WTRU is not monitoring the reservation period (e.g., the required reservation period), it may not exclude the relevant slot in the resource selection window. The WTRU can decide whether to perform slot exclusion based on the TB's QoS. In some cases, the WTRU may perform slot exclusion due to unsupervised slots in the CPS if the TB's priority is below a threshold. Otherwise, if the TB's priority is above a threshold, the WTRU may not perform slot exclusion due to unsupervised slots in the CPS. In some cases, the WTRU may perform slot exclusion due to unsupervised slots in the CPS if the TB's priority is above a threshold. Otherwise, if the TB's priority is below a threshold, the WTRU may not perform slot exclusion due to unsupervised slots in the CPS.

[0231] The WTRU can determine whether to perform slot exclusion due to unsupervised slots within a CPS window based on the traffic type (e.g., periodic or aperiodic traffic). In some cases, the WTRU can perform slot exclusion due to unsupervised slots within a CPS window for aperiodic traffic. The WTRU may choose not to perform slot exclusion due to unsupervised slots within a CPS window for periodic traffic. The WTRU can perform slot exclusion due to unsupervised slots within a CPS window for periodic traffic. The WTRU may choose not to perform slot exclusion due to unsupervised slots within a CPS window for aperiodic traffic.

[0232] The WTRU can determine whether to perform slot exclusions due to unsupervised slots in the CPS window based on whether the DRX is configured for the WTRU. In some cases, if the SL DRX is configured for the WTRU, the WTRU may not perform slot exclusions due to unsupervised slots in the CPS. Otherwise, the WTRU can perform slot exclusion due to unsupervised slots in the CPS. If an SL DRX is configured in the WTRU, the WTRU can perform slot exclusion due to unsupervised slots in the CPS. Otherwise, the WTRU may choose not to perform slot exclusion due to unsupervised slots in the CPS.

[0233] WTRU can determine whether to perform slot exclusion due to unsupervised slots within a CPS window based on the resource pool's CBR. For example, WTRU may perform slot exclusion due to unsupervised slots within a CPS if the TB priority is lower than a threshold. Otherwise, WTRU may choose not to perform slot exclusion due to unsupervised slots within a CPS.

[0234] WTRU can determine whether to perform slot exclusion due to unsupervised slots within a CPS window based on whether the slot has a PBPS result. For example, WTRU may exclude slots that have a gap equal to one of the (pre-configured) reservation periods, making them unsupervised slots within a CPS window. If a slot under consideration belongs to a set of Y candidate slots, WTRU may choose not to exclude such slots.

[0235] DRX sensing and / or resource allocation may be provided to the WTRU. The WTRU can decide whether to perform sensing outside of DRX ON time. The WTRU may be (pre-configured) with multiple sets (e.g., two sets) of sensing slots required for partial sensing-based resource selection. For each set of required sensing slots, the WTRU may be configured to determine whether sensing can be skipped if the required sensing slot is within DRX OFF time. The WTRU may skip a required set of sensing slots (e.g., one set) if, for example, the sensing slots are outside of DRX ON time. The WTRU may not skip a required set of sensing slots, regardless of whether the required sensing slots are within or outside of DRX ON time. The WTRU may decide whether to skip a required sensing slot during DRX OFF time based, for example, whether the required sensing slots belong to a required set (e.g., a set that allows the WTRU to skip sensing during DRX OFF time, or a set that does not allow the WTRU to skip sensing during DRX OFF time).

[0236] In some cases, the WTRU can skip periodic partial sensing slots, for example, if the periodic partial sensing is outside of the DRX ON time. The WTRU can also choose not to skip consecutive partial sensing slots, regardless of whether the slot is within or outside of the DRX ON time.

[0237] A WTRU can decide whether to wake up before the DRX ON time to perform sensing and / or resource allocation. In some examples, a WTRU may have data arriving before its DRX ON time. A WTRU can perform partially sensing-based resource selection. For example, a WTRU can decide whether to wake up to perform sensing and / or resource allocation, wait during the DRX ON time to perform sensing and / or resource allocation, or drop the TB. A WTRU can make decisions based on one or more of the following: the TB's QoS (e.g., the TB's priority), the resource pool's CBR, the sensing type, the TB's HARQ type, whether the WTRU performs semi-persistent resource reservation, or whether the WTRU performs resource reassessment and / or preemption sensing. A WTRU can wake up to perform sensing and / or resource allocation for high-priority and / or low-latency TBs. For low-priority and / or high-PDB TBs, a WTRU can wait until the DRX ON time expires before performing sensing and / or resource allocation. If a TB has a low priority, the WTRU can drop the TB. The WTRU can wake up to perform sensing if, for example, the resource pool's CBR is high. Otherwise, the WTRU can wait until the DRX ON time expires before performing sensing and / or resource allocation. The WTRU can decide whether to wake up to perform sensing based on, for example, the sensing type. In some cases, the WTRU can wake up to perform short-term sensing based on the sensing type. Otherwise, the WTRU may not wake up (for example, to perform long-term sensing). The WTRU can wake up to perform long-term sensing based on the sensing type. Otherwise, the WTRU may not wake up (for example, to perform short-term sensing).A WTRU can wake up to perform sensing of HARQ-enabled TBs, and / or it can not wake up to perform sensing of non-HARQ-enabled TBs. In some cases, a WTRU can wake up to perform sensing of non-HARQ-enabled TBs, and it can not wake up to perform sensing of HARQ-enabled TBs. A WTRU can wake up to perform sensing if it performs semi-persistent resource reservations. In some cases, a WTRU can not wake up to perform sensing if it does not perform semi-persistent resource reservations. For example, a WTRU may decide to perform sensing for resource reassessment and / or preemption if the WTRU is in a DRX OFF cycle.

[0238] A WTRU can determine the data to be considered when triggering resource selection. Based on data arrival in a buffer (e.g., MAC buffer), a WTRU can trigger resource (re)selection for the arriving data. A WTRU can determine destinations to trigger resource allocation based on the priority of a logical channel (e.g., LCH) and / or the destination's DRX type. A WTRU can trigger resource selection for the LCH with the highest priority. If multiple LCHs have the same highest priority, a WTRU can prioritize the LCH associated with the SL DRX Rx WTRU. A WTRU can trigger resource selection for an LCH associated with a DRX Rx WTRU (e.g., a target) regardless of priority, for example.

[0239] For example, WTRU behavior may be provided when the minimum CPS window is not met. In some examples, the WTRU cannot (e.g., cannot) meet the minimum CPS sensing window and / or the maximum CPS sensing window. The WTRU may do one or more of the following: drop the TB and / or drop it from another resource pool and / or perform the transmission in another resource pool (e.g., an exceptional resource pool); reduce the number of (re)transmissions of the TB, for example, change from a semi-persistent reservation to a non-periodic transmission when the required CPS sensing window is (pre-)configured for a semi-persistent reservation; or, for example, perform a random resource selection for the TB when the resource pool allows random resource allocation.

[0240] Resource reassessment and / or preemption may be provided. In some examples, the WTRU can determine whether to trigger resource reassessment. The WTRU may be (pre-configured) with multiple values ​​for the minimum number of candidate slots. The first of the multiple values ​​may be used for resource selection. The second of the multiple values ​​may be used for resource reassessment. The third of the multiple values ​​may be used for preemption. The minimum number of candidate slots may be determined based on one or more of the resource pool's CBR, TB QoS value, or TB resource reservations.

[0241] WTRU may, for example, if the number of candidate slots in the resource selection window is less than the minimum number of candidate slots, perform one or more of the following actions: not perform resource re-evaluation, drop the selected resources and not perform resource re-selection for the previously selected resources, or expand the resource selection window beyond the set of candidate slots.

[0242] WTRU can determine a set of candidate slots for resource reassessment. WTRU can determine a set of candidate slots for resource reassessment (for example, a set of slots for determining which resources to report to higher levels). The set of candidate slots may be determined based on one or more of the following: the set of candidate slots used for resource selection by the WTRU, the QoS of the TB, the number of retransmissions associated with the TB, or the CBR of the resource pool. The WTRU may select a set of candidate slots within the set of candidate slots used for initial resource selection. For example, if the resource pool's CBR is below a threshold, the WTRU may select a set of candidate slots within the set of candidate slots for initial resource selection. For example, if the resource pool's CBR is above a threshold, the WTRU may select a set of candidate slots within and outside the set of candidate slots for initial resource selection, as well as outside the set of candidate slots. For example, if the number of retransmissions associated with the TB is below a threshold, the WTRU may select a set of candidate slots within the set of candidate slots for initial resource selection. For example, if the number of retransmissions associated with the TB is below a threshold, the WTRU may select a set of candidate slots within the set of candidate slots for initial resource selection and outside the set of candidate slots. Thresholds can be configured (in advance). For example, thresholds can be configured (in advance) for each resource pool.

[0243] A WTRU can determine the reservation period for performing a preemption check. For example, a WTRU might decide whether to perform a preemption check over a reservation period (e.g., one reservation period) based on whether the reserved resource is within a set of candidate slots specified for periodic, partially sensing resource allocation. For example, if the reserved slot is within a set of candidate slots, the WTRU can perform a preemption check. Otherwise, the WTRU can skip the preemption check.

[0244] The WTRU can determine a set of sensing slots that can be used for preemption checks. The WTRU can perform periodic, partial sensing for preemption checks. The WTRU can perform sensing to detect semi-persistent reservations and extract the sensing results. The WTRU can perform resource reselection, for example, if a selected resource conflicts with another semi-persistent reservation with a higher priority.

[0245] Figure 11 shows a WTRU that performs resource reevaluation and / or preemption of resources in time slot m. As shown in Figure 11, the WTRU can perform resource reevaluation and / or preemption of the reserved / selected resources at time m-T3. The set of candidate slots is in the rectangle marked "Set of Y Candidate Slots", and the set of remaining candidate slots is in the rectangle marked "Set of Remaining Candidate Slots".

[0246] A WTRU can determine whether to trigger resource reevaluation and / or preemption of pre-selected and / or reserved resources. In some examples, a WTRU can determine whether to trigger resource reevaluation and / or preemption of pre-selected and / or reserved resources based on one or more of the following: the time gap between the resource selection slot and the slot of the first selected resource for reevaluation, or the possibility of having a CPS window for resource reevaluation.

[0247] The WTRU can determine whether to trigger resource reassessment / preemption of a pre-selected / reserved resource based on the time gap between the resource selection slot and the slot of the first selected resource for reassessment. For example, if the time gap between the resource selection slot and the slot of the first selected resource for reassessment is smaller than a threshold, the WTRU may refrain from triggering resource reassessment (e.g., not trigger it). Conversely, if the time gap between the resource selection slot and the slot of the first selected resource for reassessment is larger than a threshold, the WTRU may trigger resource reassessment. The threshold may be fixed (e.g., 31 slots) and / or (pre-configured), and the (pre-configured) setting may be determined based on the QoS of the TB.

[0248] The WTRU can determine whether to trigger resource reassessment and / or preemption of pre-selected and / or reserved resources, for example, based on the possibility of having a CPS window for resource reassessment. The WTRU can, for example, trigger resource reassessment if the CPS window is greater than a threshold. Conversely, if the CPS window is smaller than a threshold, the WTRU may refrain from triggering resource reassessment (e.g., not trigger it). The threshold can be configured (in advance) and may be a function of the TB's QoS (e.g., TB's priority or TB's remaining PDB).

[0249] The WTRU can determine the sensing type for resource reassessment and / or preemption. In some examples, the WTRU can perform a CPS (e.g., CPS only) for resource reassessment and / or preemption. The WTRU can perform a PBPS (e.g., PBPS only) for resource reassessment and / or preemption. The WTRU can perform both a CPS and a PBPS for preemption and resource reassessment. The WTRU may be restricted from starting a PBPS (e.g., a new PBPS) for resource reassessment and / or preemption (e.g., it may be impossible to start one). The WTRU may reuse PBPS sensing results from a PBPS process (e.g., an existing PBPS process) that can target another TB and / or another resource allocation process.

[0250] A WTRU can trigger sensing for resource reassessment and / or preemption. In some examples, a WTRU can trigger CPS and / or PBPS for resource reassessment / preemption. The trigger may be based on one or more of the following: a resource selection slot, a first transmit slot in a first period, TB arrival, a first pre-selected and / or reserved resource for resource reassessment and / or preemption, or TB QoS.

[0251] Sensing triggers for resource reassessment and / or preemption may be based, for example, on resource selection slots. In some examples, a WTRU may trigger a PBPS for preemption when the WTRU performs resource selection for semi-persistent reservations. A WTRU may determine a set of reservation periods for PBPS and / or period (e.g., each period) based, for example, on the timing between resource selection and a first selected resource for reservation in the next period (e.g., a subsequent period). A WTRU may select a reservation period for PBPS that is smaller than the time gap between a resource selection slot and a slot with a reserved resource in the next period (e.g., a subsequent period). In some examples, a WTRU may trigger a CPS for resource reassessment based on resource selection slots. A WTRU may trigger a CPS for resource reassessment of a pre-selected resource if, for example, the time gap between a resource selection slot and a first resource for reassessment is smaller than a threshold. Instead, for example, if the time gap is greater than a threshold, WTRU may refrain from triggering CPS for resource reassessment (e.g., not trigger at all). The threshold can be configured (pre-configured) based on a fixed (e.g., 31 slots) or TB QoS.

[0252] The trigger for sensing resource reassessment and / or preemption may, for example, be based on a first transmit slot in a first period. The WTRU may, for example, trigger a PBPS for a reserved resource when it performs a transmit and / or reservation for a selected resource in a first period. The WTRU may, for example, determine a set of PBPS and / or PSO reservation periods for each reservation period (e.g., each reservation period) based on the resource reservation period. The WTRU may, for example, select a PBPS reservation period shorter than the reservation period.

[0253] Sensing triggers for resource reassessment and / or preemption may be based, for example, on the arrival of TBs. In some examples, a WTRU can trigger a CPS for preemption of a reserved resource based, for example, on the arrival of periodic data that is sent (e.g., intended to be sent) to the reserved resource.

[0254] The trigger for sensing for resource reassessment and / or preemption may be based, for example, on a first pre-selected and / or reserved resource for resource reassessment and / or preemption. For example, WTRU may trigger CPS sensing based on the timing of a first pre-selected and / or reserved resource for resource reassessment and / or preemption. WTRU may trigger sensing (for example, at least) M slots before the first pre-selected and / or reserved resource. The value of M may be (pre-configured) based on a fixed (e.g., 31 slots) and / or TB QoS.

[0255] The trigger for sensing resource reassessment and / or preemption may be based, for example, on the QoS of TB. The QoS of TB may include one or more of the following: the QoS of TB transmitted in the last period, the QoS of TB available in the current period, or the QoS of TB expected to be transmitted in the current period.

[0256] In some examples, a WTRU can trigger a CPS for preemption based, for example, on the arrival of a TB and a first reserved resource for preemption. In some examples, a WTRU can trigger a CPS sensing based on either the arrival of a TB or the first reserved resource. A WTRU can trigger sensing, for example, when periodic data arrives. A WTRU can trigger a CPS before M slots of the first reserved resource, for example, when no data has arrived. In some examples, a WTRU can trigger a CPS based on both the arrival of a TB and the first reserved resource. A WTRU can trigger a CPS before (for example, at least) M slots of the first reserved resource, for example, when periodic data arrives. A WTRU can refrain from triggering (not trigger) a CPS, for example, when periodic data has not arrived. M can be configured (in advance) (for example, based on the QoS of the TB) and / or fixed (for example, to be 31 slots).

[0257] A WTRU can determine whether to perform a CPS for resource reassessment and / or preemption. In some examples, a WTRU may determine whether to perform a CPS for resource reassessment and / or preemption based on one or more of the following: TB QoS, the time gap between the last sensing slot in initial resource selection and resource (re)assessment / preemption trigger slot n, the time gap between the last sensing slot in initial resource selection and the first resource (r0) subject to resource reassessment, the resource reservation period, or whether the WTRU performs a CPS for initial resource allocation.

[0258] WTRU can, for example, determine whether to run CPS for resource reassessment and / or preemption based on whether (pre)configuration exists. For example, a WTRU may be pre-configured with information associated with the resource pool (e.g., incoming configuration information) indicating whether CPS for resource reassessment and / or preemption is enabled or disabled. If CPS is enabled, the WTRU can perform CPS for resource reassessment and / or preemption. Otherwise, the WTRU can refrain from performing CPS for resource reassessment and / or preemption (e.g., not perform it).

[0259] A WTRU can, for example, decide whether to perform CPS for resource reassessment and / or preemption based on the QoS of the TB. For example, a WTRU can refrain from performing CPS (e.g., not perform it) if the PDB of the TB is smaller than a threshold. Otherwise, the WTRU can perform CPS.

[0260] The WTRU can determine whether to perform CPS for resource reevaluation and / or preemption based, for example, on the time gap between the last sensing slot in initial resource selection and resource reevaluation and / or preemption trigger slot n. For example, if the time gap between the last sensing slot in initial resource selection and resource reevaluation and / or preemption trigger slot n is smaller than a threshold, the WTRU can refrain from performing CPS (e.g., not perform it). Otherwise, the WTRU can perform CPS. The threshold can be configured (in advance) based on the TB's QoS.

[0261] The WTRU can determine whether to perform CPS for resource reassessment and / or preemption based, for example, on the time gap between the last sensing slot in the initial resource selection and the first resource (r0) subject to resource reassessment. For example, if the time gap between the last sensing slot in the initial resource selection and the first resource (r0) subject to resource reassessment is smaller than a threshold, the WTRU may refrain from performing CPS (e.g., not perform it). Otherwise, the WTRU may perform CPS. The threshold can be configured (in advance) based on the QoS of the TB.

[0262] A WTRU can, for example, decide whether to perform a CPS for resource reassessment and / or preemption based on the resource reservation period. For example, if the resource reservation period is shorter than a threshold, the WTRU may refrain from performing a CPS (e.g., not perform one). Otherwise, the WTRU may perform a CPS for preemption. The threshold can be configured (in advance) based on the QoS of the TB.

[0263] A WTRU can decide whether to run a CPS for resource allocation based, for example, on whether to run a CPS for resource reassessment and / or preemption. In some cases, a WTRU can run a CPS for resource reassessment and / or preemption (for example, decide to run it) if, for example, the WTRU runs a CPS for initial resource allocation. Otherwise, a WTRU can refrain from running a CPS for resource reassessment and / or preemption (for example, not run it) if, for example, the WTRU does not run a CPS for initial resource allocation. In some cases, a WTRU can run a CPS for resource reassessment and / or preemption (for example, decide to run it) if, for example, the WTRU does not run a CPS for initial resource allocation. Otherwise, a WTRU can run a CPS for resource reassessment / preemption if, for example, the WTRU does not run a CPS for initial resource allocation.

[0264] WTRU can determine CPS parameters for resource reassessment and / or preemption. The CPS parameters for resource reassessment and / or preemption may include one or more of the following parameters: the slot that triggers CPS sensing and / or resource reassessment and / or preemption (e.g., slot n), the first slot of the CPS window n+TA, the last slot of the CPS window n+TB, or the minimum and / or maximum CPS window (e.g., CPS window[n+TA,n+TB]), which may include the case where TA=TB.

[0265] The WTRU can determine one or more CPS parameters for resource reassessment and / or preemption based on the CPS window used for initial resource allocation, TB QoS, the time gap between the last sensing slot in initial resource selection and the first resource (r0) subject to resource reassessment, the time gap (r0') between the preemption trigger slot n and the first resource for preemption, the resource reservation period, or one or more CPS parameters used for initial resource allocation.

[0266] The WTRU can determine one or more CPS parameters for resource reevaluation and / or preemption based on (pre)configuration. In some examples, the WTRU may be (pre)configured with information indicating minimum and / or maximum CPS windows for resource reevaluation and / or preemption (e.g., incoming configuration information). The WTRU can then perform CPS within a window, for example, to ensure that the minimum and / or maximum CPS window is met.

[0267] A WTRU can determine one or more CPS parameters for resource reassessment and / or preemption based on the CPS window used for initial resource allocation. For example, a WTRU can use the same CPS window size for initial resource allocation and / or resource reassessment and / or preemption for the same TB. For example, a WTRU can use the same CPS window size for preemption in other periods (e.g., all periods).

[0268] The WTRU can determine one or more CPS parameters for resource reassessment and / or preemption based on the TB's QoS. For example, the WTRU may be (pre-configured) with information indicating the minimum and / or maximum CPS window (e.g., receive configuration information) based on the TB's QoS (e.g., priority, remaining PDBs, etc.). The WTRU can determine the QoS of a TB, for example, when the WTRU performs a resource reassessment of the TB. The WTRU can determine the CPS window of a TB, for example, such that the CPS window satisfies a (pre-configured) minimum and / or maximum CPS window that may be a function of the QoS of the TB.

[0269] The WTRU can determine one or more CPS parameters for resource reassessment and / or preemption based on the time gap between the last sensing slot in the initial resource selection and the first resource (r0) subject to resource reassessment. For example, if the time gap between slot n and the first resource to be preempted is smaller than a threshold, the WTRU can perform CPS in the slots between slot n and the first resource to be preempted (e.g., all slots) except for the slot used for WTRU processing. The threshold can be configured (in advance). Otherwise, for example, if the time gap between slot n and the first resource to be preempted is larger than the threshold, the WTRU can perform CPS (e.g., at least) M slots before the first resource (r0') to be preempted. The value of M can be configured (in advance) based on a fixed and / or TB QoS.

[0270] The WTRU can determine one or more CPS parameters for resource reevaluation and / or preemption based on the time gap between the preemption trigger slot n and the first resource to be preempted (r0'). For example, if the time gap between slot n and the first resource to be preempted is less than a threshold, the WTRU can perform CPS in the slots between slot n and the first resource to be preempted (e.g., all slots) except for the slot used for WTRU processing. The threshold can be configured (in advance). Otherwise, for example, if the time gap between slot n and the first resource to be preempted is greater than the threshold, the WTRU can perform CPS (e.g., at least) M slots before the first resource to be preempted (r0'). The value of M can be configured (in advance) based on a fixed and / or TB QoS.

[0271] The WTRU can determine one or more CPS parameters for resource revaluation and / or preemption based on the resource reservation period. For example, the WTRU may (pre-configure) multiple minimum CPS windows (e.g., receive configuration information indicating such windows). A CPS window (e.g., each CPS window) may be associated with one or more reservation periods. The WTRU can determine a CPS window based on the reservation period of a reserved resource, for example. In some examples, the WTRU may (pre-configure) multiple minimum CPS windows (e.g., two minimum CPS windows) (e.g., receive configuration information indicating such windows), where a first window (e.g., M<31 slots) may be associated with a first set of reservation periods (e.g., in the case of a short reservation period), and a second window (e.g., M=31 slots) may be associated with a second set of reservation periods (e.g., in the case of a long reservation period). The WTRU can determine a CPS window based on the reservation period of a reserved resource.

[0272] The WTRU can determine one or more CPS parameters for resource re-evaluation and / or preemption based on the CPS parameters used for initial resource allocation. For example, the WTRU can determine the minimum and / or maximum CPS window and / or the CPS window for resource re-evaluation and / or preemption based on the CPS window used for initial resource allocation. In some examples, the WTRU may (pre-configure) an offset between the minimum and / or maximum CPS window and the CPS window used for initial resource allocation and resource re-evaluation and / or preemption (for example, it may receive configuration information indicating such an offset). The offset may (pre-configure) based on fixed and / or TB QoS. For example, the WTRU may (pre-configure) a CPS window for initial resource allocation of M slots (for example, it may receive configuration information indicating such a window). The WTRU can determine the CPS window for resource re-evaluation and / or preemption as an offset of M slots. For example, the WTRU may (pre-configure) minimum and / or maximum CPS windows for M slots (e.g., it may receive configuration information indicating such windows). The WTRU may determine the minimum and / or maximum CPS windows for resource re-evaluation and / or preemption as M offsets (e.g., slots). The offsets can be negative, positive, or zero. The WTRU may determine the CPS windows to satisfy the (pre-configured) minimum windows.

[0273] WTRU can determine PBPS parameters for resource reassessment and / or preemption. The PBPS parameters for resource reassessment and / or preemption may include one or more of the following parameters: triggered CPS sensing slots and / or triggered resource reassessment and / or preemption slots, a set of reservation periods to sense, sensing opportunities set for each reservation period, and sensing windows [n-T0,n].

[0274] WTRU can determine one or more PBPS parameters for resource reassessment and / or preemption based on one or more parameters used for the resource reservation period or the PBPS for initial resource allocation.

[0275] The WTRU can determine one or more PBPS parameters for resource reassessment and / or preemption based on its (pre-)configuration. For example, the WTRU may (pre-)configure a set of reservation periods and / or PSOs (e.g., monitored for resource reassessment and / or preemption) (e.g., it can receive configuration information indicating such a set). The WTRU can perform sensing over a period (e.g., each period) in the set of reservation periods and / or PSOs. For example, the WTRU may (pre-)configure a set of monitored reservation periods for resource reassessment and / or preemption (e.g., it can receive configuration information indicating a set of reservation periods). The WTRU does not have to (pre-)configure a set of PSOs for each resource reservation period (e.g., the configuration information does not have to indicate a set of PSOs for each resource reservation period). The WTRU can perform sensing in the latest PSO for each resource reservation period for resource reassessment and / or preemption.

[0276] The WTRU can determine one or more of the PBPS parameters for resource re - evaluation and / or pre - emption based on the resource reservation period. In some examples, the WTRU can determine a set of reservation periods and / or a set of PSOs to be monitored for each reservation period based on the reserved resource reservation period. The WTRU can perform PBPS in a reservation period that is less than or equal to the reservation period of the reserved resource (e.g., determined as the reservation period).

[0277] The WTRU can determine one or more of the PBPS parameters for resource re - evaluation and / or pre - emption based on the parameters used for the PBPS of the initial resource allocation. For example, the WTRU can perform PBPS for resource re - evaluation and / or pre - emption in a period (pre - configured) for the initial resource allocation. The WTRU can perform sensing in the latest PSO of a period (e.g., only each period) independent of the set of PSOs (pre - configured) for the initial resource allocation.

[0278] The WTRU can determine a set of Y candidate slots for PBPS for resource re - evaluation and / or pre - emption. In some examples, the WTRU can determine the set of Y candidate slots for PBPS for resource re - evaluation and / or pre - emption based on one or more of a (pre - configured) set or the set of Y0 candidate slots that the WTRU uses for the initial resource allocation of the same TB.

[0279] The WTRU can determine a set of Y candidate slots for PBPS for resource re-evaluation and / or preemption based on (pre-)configuration (e.g., received configuration information). For example, the WTRU may be (pre-)configured with Ymin candidate slots for PBPS for resource re-evaluation and / or preemption (e.g., it may receive configuration information indicating such candidate slots). The WTRU can select Y > Ymin candidate slots for PBPS for resource re-evaluation and / or preemption.

[0280] The WTRU can determine a set of Y candidate slots for PBPS for resource re-evaluation and / or preemption based on a set of Y0 candidate slots that the WTRU uses for the initial resource allocation of the same TB. For example, the WTRU can determine the set of Y candidate slots based on the remaining set of Y0 candidate slots within the RSW that the WTRU used for the initial resource allocation for the same TB. The WTRU can include the remaining Y0 candidate slots (e.g., all of the remaining Y0 candidate slots) within the RSW for PBPS.

[0281] The WTRU can determine a resource selection window for resource re-evaluation. The resource selection window parameters for resource re-evaluation and / or preemption may include one or more of the following parameters, namely, the values of T1, T2, or the resource selection window [n + T1, n + T2].

[0282] The WTRU may determine one or more of the resource selection window parameters for resource re-evaluation and / or preemption based on one or more of the set of resources that are the subject of resource re-evaluation and / or preemption, or one or more of the QoS of the TB.

[0283] The WTRU can determine one or more resource selection window parameters for resource revaluation and / or preemption based on the set of resources subject to resource revaluation and / or preemption. In some examples, the WTRU can determine a trigger slot n for resource revaluation and / or preemption based on the timing of a first resource subject to resource revaluation and / or preemption. The WTRU can trigger (e.g., be requested to trigger) resource revaluation and / or preemption (e.g., at least) X slots before the first resource subject to resource revaluation and / or preemption. The value of X can be fixed (e.g., 31 slots). The value of X may be (pre-configured) and may also be (pre-configured) based on TB QoS, resource pool CBR, and / or resource reservation periods. In some examples, the WTRU can determine a resource selection window [n+T1, n+T2] for resource revaluation and / or preemption based on the set of resources subject to resource revaluation and / or preemption.

[0284] The WTRU can initialize a set of candidate resources (e.g., set A) for resource reassessment. The WTRU can determine one or more of the following (for example, to initialize a set of candidate resources set A for resource reassessment and / or preemption): a window [n+Y1, n+Y2] for initializing set A of candidate resources, or a set of slots within the window of candidate resources for initializing the set of candidate resources. The parameters (for example, for determining the set of slots for initializing set A) may be determined based on one or more of the following: whether the WTRU semi-permanently reserves pre-selected resources, whether the WTRU semi-permanently reserves re-selected resources, a set of Y0 candidate slots used for initial resource allocation, or the remaining set of slots from a set of Y0 candidate slots used for initial resource selection, or whether there are existing Ymin candidate slots with PBPS results in the RSW for resource reassessment.

[0285] The parameters (for example, for determining the set of slots to initialize set A) may be determined based on whether the WTRU semi-permanently reserves pre-selected resources. If the WTRU semi-permanently reserves pre-selected resources, for example, it can select Y candidate slots that have PBPS results (for example, for resource re-evaluation). The WTRU can initialize set A for resource re-evaluation with the set of Y candidate slots. Otherwise, for example, if the WTRU does not semi-permanently reserve pre-selected resources, the WTRU can initialize set A from a set of slots (regardless of whether the slots have PBPS sensing results).

[0286] The parameters (for example, for determining the set of slots to initialize set A) can be determined based on whether the WTRU semi-permanently reserves the re-selected resources. For example, if the WTRU semi-permanently reserves the re-selected resources, the WTRU can select Y candidate slots that have PBPS results. The WTRU can initialize set A within the set of Y candidate slots. Otherwise, for example, if the WTRU does not semi-permanently reserve the re-selected resources, the WTRU can initialize set A from a set of slots (regardless of whether the slots have PBPS sensing results).

[0287] The parameters (for example, for determining the set of slots to initialize set A) may be determined based on the set of Y0 candidate slots used for initial resource allocation, or the remaining set of slots from the set of Y0 candidate slots used for initial resource selection. For example, WTRU may determine the set of slots to initialize set A of candidate resources for resource reevaluation and / or preemption based on the set of Y0 candidate slots used for initial resource allocation. For example, WTRU may include the remaining set of Y0 candidate slots used for initial resource allocation in RSW to initialize set A (e.g., all of the remaining set of Y0 candidate slots). WTRU may include other slots outside the remaining set of Y0 candidate slots if, for example, the remaining set of Y0 candidate slots is less than Ymin.

[0288] The parameters (for example, for determining the set of slots to initialize set A) may be determined based on whether there are existing Ymin candidate slots in the RSW that have PBPS results for resource reevaluation. For example, the WTRU can determine the set of slots to initialize set A of candidate resources for resource reevaluation and / or preemption based on whether there are Ymin candidate slots in the RSW that have PBPS results. The WTRU can initialize set A of candidate resources in Ymin candidate slots (e.g., all Ymin candidate slots) if there are Ymin candidate slots that have PBPS results. WTRU can perform a semi-persistent reservation of the re-selected resources. Alternatively, for example, if there are no Ymin candidate slots in RSWE, WTRU can initialize a set A of candidate resources in window [n+Y1, n+Y2] (without considering, for example, whether the slots have PBPS results). WTRU can refrain from performing a semi-persistent reservation of the re-selected resources (for example, by not performing it).

[0289] A WTRU can preferentially reselect a transmission resource due to resource reevaluation and / or preemption from set A that has PBPS results. In some examples, a WTRU can detect a collision of pre-selected and / or reserved resources due to resource reevaluation and / or preemption. A WTRU can reselect another resource within a set of candidate resources (e.g., set A). A WTRU can preferentially select resources that have PBPS results. For example, if the number of resources in set A with PBPS sensing results is greater than a threshold, a WTRU can reselect one or more resources to replace a conflicting resource in the set of slots with PBPS results. A WTRU can reselect the remaining resources in the entire set A. The threshold can be configured (in advance). A WTRU can perform a semi-persistent reservation of a reselected resource if, for example, the reselected resource is within a set of Y candidate slots with PBPS sensing results. Otherwise, if the reselected resource is outside of the Y candidate slots, the WTRU can refrain from performing a semi-persistent reservation of the reselected resource (e.g., not perform one).

[0290] A WTRU can reselect a resource due to preemption in the same slot as a reserved resource. In some cases, a WTRU can detect a conflict with a reserved resource. A WTRU can reselect another resource to replace the reserved resource. A WTRU can preferentially reselect a resource in the same slot as the conflicted resource. Sensing for preemption can be mitigated, for example, by having a WTRU reselect a resource due to preemption in the same slot as a reserved resource.

[0291] A WTRU may decide whether to perform resource revaluation and / or preemption based on one or more of the following: whether the WTRU performs semi-persistent resource reservation of a resource, the set of candidate slots for possible resource re-selection, the HARQ type of the TB, or the CBR of the resource pool.

[0292] A WTRU may decide whether to perform resource revaluation and / or preemption based on whether the WTRU performs semi-persistent resource reservation for the resource. In some cases, a WTRU may perform resource revaluation and / or preemption for semi-persistent reserved resources, but may not perform resource revaluation and / or preemption for shot-transmit resources (e.g., one-shot-transmit resources). A WTRU may perform resource revaluation for shot-transmit resources (e.g., one-shot-transmit resources), but may not perform resource revaluation for semi-persistent reserved resources.

[0293] A WTRU can decide whether to perform resource reevaluation and / or preemption based on the set of candidate slots for possible resource reselection. In some examples, a WTRU may perform resource reevaluation and / or preemption if the set of remaining candidate slots for possible resource reselection is greater than a threshold. Otherwise, the WTRU may choose not to perform resource reevaluation and / or preemption. The threshold can be configured (in advance) for each resource pool. The threshold may also be a function of the TB priority.

[0294] The WTRU can decide whether to perform resource reassessment and / or preemption based on the TB's HARQ type. In some cases, the WTRU may perform resource reassessment and / or preemption for non-HARQ TBs, but may not perform resource reassessment and / or preemption for HARQ TBs.

[0295] A WTRU can determine whether to perform resource reevaluation and / or preemption based on the resource pool's CBR. In some cases, a WTRU may perform resource reevaluation and / or preemption if the resource pool's CBR is greater than a threshold. Otherwise, the WTRU may choose not to perform resource reevaluation and / or preemption. The threshold can be configured (in advance) for each resource pool.

[0296] A WTRU can determine which slots trigger resource reevaluation and / or preemption. In some examples, a WTRU can determine which slots trigger resource reevaluation and / or preemption based on the set of remaining candidate slots. For example, a WTRU may (pre-)configure a minimum candidate slot for resource reevaluation and / or preemption. A WTRU can then trigger resource reevaluation and / or preemption so that the set of remaining candidate slots exceeds a threshold.

[0297] The WTRU can determine a resource selection window for resource reevaluation and / or preemption. In some examples, the WTRU can determine a resource selection window for resource reevaluation and / or preemption based on the size of the set of remaining candidate slots. For example, the WTRU may (pre-configure) a minimum number of candidate slots for resource reevaluation and / or preemption. In some examples, the resource selection window may be within the set of remaining candidate slots if the set of remaining candidate slots is greater than a threshold. If the set of remaining candidate slots is less than a threshold, the WTRU may expand the resource selection window to include both the set of remaining candidate slots and those outside the set of remaining candidate slots, not perform resource reevaluation and / or preemption on the resource, drop the TB, or drop the resource that is subject to resource reevaluation and / or preemption.

[0298] A WTRU can trigger a preemption check. In some examples, a WTRU may decide whether to perform a preemption check based on one or more of the following: changes in the QoS of a TB, changes in the CBR of a resource pool, the number of transmissions the WTRU has made to a TB (e.g., one TB) in the past period, the number of transmissions the WTRU has made to a reserved resource (e.g., one reserved resource), the number of NACKs and / or DTXs the WTRU has received to a reserved resource (e.g., one reserved resource), the percentage of NACKs and / or DTXs the WTRU has received to a reserved resource (e.g., one reserved resource), a check of a set of reserved resources after the WTRU has obtained sufficient PBPS and / or CPS results for a preemption check of the set of reserved resources, or periodic preemption checks (e.g., preemption checks for the required period).

[0299] The WTRU can determine whether to perform a preemption check based on a change in the QoS of the TB. For example, if the priority of the TB in the current period has changed compared to the priority of the TB in the last period, the WTRU can trigger a preemption check for the reserved resources in the future reservation period. The WTRU can trigger a preemption check if the priority gap between the current period and the last period is greater than a threshold value. The threshold value can be configured (in advance) for each resource pool.

[0300] The WTRU can determine whether to perform a preemption check based on a change in the CBR of the resource pool. For example, if the CBR of the resource pool becomes greater than a threshold value, the WTRU can trigger a preemption check. The threshold value can be configured (in advance) for each resource pool.

[0301] The WTRU can determine whether to perform a preemption check based on the number of transmissions the WTRU has made for a TB (e.g., one TB) in the past period. For example, if the number of transmissions for a TB (e.g., one TB) is greater than a threshold value, the WTRU can trigger a preemption check for the future resource reservation period. The threshold value can be configured (in advance) for each resource pool based on the priority of the TB.

[0302] The WTRU can determine whether to perform a preemption check based on the number of transmissions the WTRU has made for a reserved resource (e.g., one reserved resource). For example, the WTRU can reserve the resource semi - permanently. The WTRU can perform a preemption check for the reserved resources after N reservation periods and / or after N transmissions in the reserved resources. The value of N can be configured (in advance) for each resource pool.

[0303] A WTRU may decide whether to perform a preemption check based on the number of NACKs and / or DTXs it receives for a reserved resource (e.g., one reserved resource). For example, a WTRU may decide to perform a preemption check if it receives N (e.g., N consecutive) NACKs and / or DTXs for a reserved resource. The value of N can be configured (in advance) for each resource pool based on the TB QoS.

[0304] A WTRU can decide whether to perform a preemption check for a reserved resource (e.g., one reserved resource) based on the percentage of NACKs and / or DTXs it receives. For example, if a WTRU receives X% of NACKs and / or DTXs, it can decide to perform a preemption check for that reserved resource. The value of X can be configured (in advance) for each resource pool. The value of X may also be based on the TB's QoS (e.g., TB's priority).

[0305] A WTRU can decide whether to perform a preemption check after it has obtained sufficient PBPS and / or CPS results for a preemption check of a reserved set of resources. A WTRU can trigger a preemption check after it has obtained sufficient PBPS and / or CPS results. A WTRU can reserve resources semi-permanently. A WTRU can perform transmissions over one or more reservation periods. A WTRU can monitor a set of reservation periods for PBPS (e.g., a set). A WTRU can perform a preemption check (e.g., perform a preemption check afterward) when it has monitored a sufficient reservation period for PBPS and has collected sufficient CPS results for a preemption check of a resource (e.g., a single resource) over a period (e.g., a specific period).

[0306] A WTRU can decide whether to perform a preemption check based on periodic preemption checks (e.g., preemption checks for a required period). For example, a WTRU can periodically perform preemption checks on a resource reservation process (e.g., a single resource reservation process).

[0307] A WTRU can trigger sensing for preemption checks. A WTRU can trigger sensing by performing one or more of the following: triggering sensing for a PBPS process (e.g., a new PBPS process) or triggering a CPS sensing process.

[0308] The triggers for sensing (for example, for preemption checks) may be based on one or more of the following: a WTRU performing resource (re)selection for a semi-permanently reserved sending resource; a WTRU making a transmission within a semi-permanently reserved resource; a change in the QoS of a TB; the resource pool's CBR; the number of transmissions a WTRU has made to a TB (e.g., one TB) in the past period; the number of transmissions a WTRU has made to a reserved resource (e.g., one reserved resource); the number of NACKs and / or DTXs a WTRU has received to a reserved resource (e.g., one reserved resource); or the percentage of NACKs and / or DTXs a WTRU has received to a reserved resource (e.g., one reserved resource).

[0309] The trigger for sensing may be based on the WTRU performing resource (re)selection for semi-persistently reserved transmission resources. For example, the WTRU may, after performing resource (re)selection for, for example, a TB and intending to semi-persistently reserve the resource, trigger sensing for preemption checks of the reserved resource in a future reservation period. For example, the MAC layer may notify the physical (PHY) layer of a set of semi-persistently reserved resources in the current period. The MAC layer may initialize a PBPS (e.g., a new PBPS) for potential preemption checks of the reserved resource in a future reservation period.

[0310] The trigger for sensing may be based on the WTRU making a transmission on a semi-persistently reserved resource. For example, the WTRU may trigger sensing for preemption checks on reserved resources in a future reservation period. During the procedure, the WTRU may make a transmission on the selected resource. In some examples, the WTRU may trigger a PBPS process (e.g., a new PBPS process) after the WTRU has built a TB to make a transmission on the selected resource. In such cases, the WTRU's MAC layer may notify the PHY layer of a set of semi-persistently reserved resources in the current period. The MAC layer may initialize a PBPS (e.g., a new PBPS) for potential preemption checks on reserved resources in a future reservation period.

[0311] Sensing triggers may also be based on changes in TB QoS. For example, a WTRU may trigger sensing for preemption checks of reserved resources in future reservation periods if the priority of a TB in the current period has changed compared to the priority of a TB in the last period. For example, a WTRU may trigger sensing for preemption checks if the priority gap between the current period and the last period is greater than a threshold. Thresholds may be configured (in advance) for each resource pool.

[0312] The sensing trigger may also be based on changes in the resource pool's CBR. For example, WTRU can trigger sensing for a preemption check if the resource pool's CBR is greater than a threshold. The threshold can be configured (in advance) for each resource pool.

[0313] The sensing trigger may also be based on the number of transmissions a WTRU has made to a TB (e.g., one TB) in the past. For example, a WTRU may trigger sensing for a preemption check for a future resource reservation period if the number of transmissions it has made to a TB (e.g., one TB) exceeds a threshold. The threshold may be configured (in advance) for each resource pool based on the priority of the TB.

[0314] The sensing trigger may be based on the number of transmissions made by the WTRU to a reserved resource (e.g., a single reserved resource). For example, a WTRU can reserve a resource semi-permanently. After N reservation periods and / or after N transmissions on the reserved resource, the WTRU can trigger sensing for a preemption check of the reserved resource. The value of N can be configured (in advance) for each resource pool.

[0315] The sensing trigger may be based on the number of NACKs and / or DTXs received by the WTRU for a reserved resource (e.g., one reserved resource). For example, a WTRU may trigger sensing for preemption if it receives N (e.g., N consecutive) NACKs and / or DTXs for a transmission on a reserved resource (e.g., one reserved resource). The value of N may be configured (in advance) for each resource pool. The value of N may be based on the QoS of TB.

[0316] The sensing trigger may be based on the percentage of NACKs and / or DTXs received by the WTRU for a reserved resource (e.g., one reserved resource). For example, if the WTRU receives X% of NACKs and / or DTXs, it may trigger sensing for a preemption check for a reserved resource (e.g., one reserved resource). The value of X can be configured (in advance) for each resource pool based on TB's QoS.

[0317] WTRU can initialize a set of candidate slots for resource re-evaluation. WTRU can determine the window for initializing the set SA for resource re-evaluation based on whether the initially selected set of resources to be re-evaluated should be reserved semi-permanently, whether WTRU re-selects resources for semi-permanent resource reservations, or one or more of the Y sets of candidate slots in the resource selection window for resource re-evaluation.

[0318] WTRU can determine the window for initializing the set SA for resource reevaluation based on whether the initially selected set of resources for resource reevaluation should be reserved semi-permanently. For example, if the initially selected resources for resource reevaluation should be reserved semi-permanently, WTRU can initialize the set of SAs within the set of Y candidate slots. Otherwise, WTRU can initialize the set of SAs regardless of the Y candidate slots (for example, WTRU can initialize SAs within and outside the set of Y candidate slots).

[0319] The WTRU can determine a window for initializing a set of SAs for resource re-evaluation based on whether the WTRU is re-selecting a resource for semi-persistent resource reservation. For example, if the WTRU intends to semi-persistently reserve the selected resource, it can initialize a set of SAs within a set of Y candidate slots. Otherwise, the WTRU can initialize a set of SAs regardless of the Y candidate slots (for example, the WTRU can initialize SAs both within and outside the set of Y candidate slots).

[0320] The WTRU can determine the window in which to initialize the set SA for resource re-evaluation based on a set of Y candidate slots within the resource selection window for resource re-evaluation. For example, the set of Y candidate slots may be a subset of a set of candidate slots that could be used to initialize the set SA for a pre-selected resource (e.g., a resource subject to resource re-evaluation). For example, if the set of Y candidate slots is greater than the resource (re)selection window for resource re-evaluation and greater than Ymin, the WTRU can initialize the set SA within the set of Y candidate slots. Otherwise, the WTRU can initialize the set SA independently of the set of Y candidate slots (for example, the WTRU can initialize the set SA to include slots both within and outside the set of Y candidate slots).

[0321] In some examples, the WTRU may decide whether to semi-permanently reserve a re-selected resource based on whether a pre-selected resource is semi-permanently reserved and whether there are at least Ymin candidate slots (e.g., in a set of Y candidate slots) within the resource (re)selection window. If the conditions (e.g., both conditions) are met, the WTRU may decide to semi-permanently re-select the resource by initializing set SA in the set of Y candidate slots.

[0322] A WTRU can initialize a set of candidate slots for preemption. In some examples, a WTRU can initialize a set of candidate slots for preemption checks. The set of candidate slots may be determined based on the target resources for which the WTRU intends to perform preemption checks. For example, a set of Y candidate slots may be initialized to cover a set of target resources for which the WTRU intends to perform preemption checks.

[0323] A WTRU can determine a reservation period that can be used to perform a preemption check on a reservation process (e.g., one reservation process). In some examples, a WTRU can determine a monitored reservation period for a preemption check process based on the time gap between two preemption check processes for a semi-persistent reservation process (e.g., one semi-persistent reservation process). For example, a WTRU can perform a preemption check on a semi-persistent reservation (e.g., one semi-persistent reservation) every Nms. The set of monitored reservation periods may include configured reservation periods for PBPSs with reservation intervals smaller than Nms (e.g., all configured reservation periods).

[0324] A WTRU can determine the frequency of preemption checks. In some examples, a WTRU can determine the frequency of preemption checks based on one or more of the following: the reservation period for which the WTRU reserved the resource, the QoS of the TB, the maximum reservation period to be monitored for PBPS (e.g., the required reservation period), the HARQ type of the TB, the CBR of the resource pool, whether SL-DRX is configured (in advance), or whether SL DRX is configured for the Rx WTRU.

[0325] A WTRU can determine the frequency of preemption checks based on the reservation period for which the WTRU reserves a resource. For example, a WTRU may (pre-configure) the frequency of preemption checks per reservation period (e.g., minimum and / or maximum frequency). For example, a WTRU may (pre-configure) the minimum number of preemption checks per reservation period and / or per elapsed time. A WTRU can determine the frequency of preemption checks to satisfy a preemption check frequency (e.g., required preemption check frequency).

[0326] WTRU can determine the frequency of preemption checks based on TB's QoS. For example, WTRU can (pre-configure) the frequency of preemption checks per reservation period (e.g., minimum and / or maximum frequencies). For example, WTRU can (pre-configure) the minimum number of preemption checks per reservation period and / or per elapsed time. WTRU can determine the frequency of preemption checks to satisfy the required preemption check frequency (e.g., the desired preemption check frequency).

[0327] WTRU can determine the frequency of preemption checks based on the maximum reservation period (e.g., required reservation period) of the monitored PBPS. For example, WTRU can determine that the time gap between two preemptions checking a semi-persistent reservation process (e.g., one semi-persistent reservation process) is greater than the maximum reservation period (e.g., required reservation period) for the monitored PBPS.

[0328] The WTRU can determine the frequency of preemption checks based on the HARQ type of the TB. For example, the WTRU may (pre-configure) multiple preemption check frequencies (e.g., two preemption check frequencies), where the first frequency may be used for HARQ-enabled TBs and the other preemption check frequencies may be used for HARQ-incompatible TBs. The WTRU can determine which preemption check frequency to use based on the HARQ type of the TB. For example, the WTRU may use the first preemption check frequency if the TB is HARQ-enabled, and the WTRU may use the second preemption check frequency if the TB is HARQ-incompatible.

[0329] A WTRU can determine the frequency of preemption checks based on the resource pool's CBR. For example, a WTRU can (pre-configure) the preemption check frequency as a function of the resource pool's CBR. A WTRU can determine, for example, which preemption check frequency to use based on the resource pool's measured CBR.

[0330] The WTRU can determine the frequency of preemption checks based on whether the SL-DRX is configured (in advance). For example, the WTRU may (in advance) configure multiple preemption check frequencies (e.g., two preemption check frequencies). A first preemption check frequency may be used if the SL-DRX is configured (in advance), and a second preemption check frequency may be used if the SL-DRX is not configured in the WTRU. The WTRU can determine which preemption check frequencies may be used based on whether the SL-DRX is configured (in advance) in the WTRU.

[0331] The WTRU can determine the frequency of preemption checks based on whether an SL-DRX is configured on the Rx WTRU. For example, the WTRU may (pre-configure) multiple preemption check frequencies (e.g., two preemption check frequencies), where the first preemption check frequency may be used if an SL-DRX is configured on the target Rx WTRU, and the other preemption check frequencies may be used if an SL-DRX is not (pre-configured) on the target Rx WTRU. The WTRU can determine which preemption check frequency to use based on whether an SL-DRX is (pre-configured) on the target Rx WTRU.

[0332] In some examples, a WTRU may (pre-configure) a range of time gaps (e.g., the number of reservation periods and / or the time from start to end) for performing preemption checks for each resource reservation process. A WTRU may select (e.g., randomly) a range of periods for performing preemption checks. The scope may be determined based on one or more of the following: the reservation period, the QoS of TB, the maximum reservation period to be monitored for PBPS (e.g., the required reservation period), the HARQ type of TB, or the CBR of the resource pool.

[0333] A WTRU can decide whether to perform a preemption check during a reservation period (e.g., a single reservation period). In some examples, a WTRU configured with SL DRX (pre-configured) can decide whether to perform a preemption check for a resource reservation during a period (e.g., an on period) based on whether the resource reservation period falls within the WTRU's DRX ON time. For example, a WTRU can perform a preemption check if a semi-permanently reserved resource falls within the WTRU's DRX ON time. If a semi-permanently reserved resource does not fall within the WTRU's DRX ON time, the WTRU can decide not to perform a preemption check for the reserved resource. The WTRU can then perform a transmission on the reserved resource without a preemption check.

[0334] The WTRU can decide whether to semi-permanently reserve a re-selected resource. In some cases, the WTRU may perform resource re-selection for a pre-selected resource due to resource re-evaluation and / or preemption. The WTRU may decide whether to semi-permanently reserve a re-selected resource based on one or more of the following pre-determinions: whether the re-selected resource is within Y candidate slots (which may have PBPS sensing results), whether the pre-selected and / or reserved resources are semi-permanently reserved, or whether the WTRU performs PBPS on the re-selected resource.

[0335] A WTRU can, for example, decide, based on a prior decision, whether to semi-permanently reserve a reselected resource. A WTRU may choose not to semi-permanently reserve a reselected resource due to resource re-evaluation and / or preemption (e.g., it may not be requested to do so). A WTRU may dynamically send a reselected resource (e.g., any reselected resource) due to resource re-evaluation and / or preemption.

[0336] The WTRU may decide whether to semi-permanently reserve a re-selected resource based, for example, on whether the re-selected resource is within Y candidate slots (which may have PBPS sensing results). For example, if the WTRU detects a conflict with a semi-permanently reserved resource, the WTRU may re-select another resource to replace the previously selected resource. The WTRU may decide whether to semi-permanently reserve a re-selected resource based on whether the selected resource is within a set of Y candidate slots. For example, if the re-selected resource is within a set of Y candidate slots, the WTRU may semi-permanently reserve the resource. If the re-selected resource is outside the set of candidate slots, the WTRU does not have to semi-permanently reserve the resource.

[0337] A WTRU may decide whether to semi-permanently reserve a re-selected resource, for example, based on whether a previously selected and / or reserved resource is semi-permanently reserved. For example, if a previously selected and / or reserved resource is not semi-permanently reserved, a WTRU may refrain from semi-permanently reserving the re-selected resource (e.g., not reserving it). If a previously selected and / or reserved resource is semi-permanently reserved, a WTRU may decide to semi-permanently reserve the re-selected resource, and / or, a WTRU may refrain from semi-permanently reserving the re-selected resource (e.g., not reserving it).

[0338] A WTRU can decide whether to semi-permanently reserve a re-selected resource based on whether the WTRU runs a PBPS on the re-selected resource. For example, if the WTRU runs a PBPS on a resource selection process for re-evaluation and / or preemption, the WTRU may semi-permanently reserve the re-selected resource. Otherwise, for example, if a PBPS is not run on a resource selection process for re-evaluation and / or preemption, the WTRU may refrain from semi-permanently reserving the re-selected resource (e.g., not reserving it).

[0339] A WTRU can use different RSRP thresholds for semi-permanently reserved resources. In some cases, a WTRU can apply different RSRP thresholds to semi-permanently reserved resources compared to dynamically reserved resources. For example, a WTRU can apply different RSRP thresholds to multiple types of resources (e.g., two types) by using different initial RSRP thresholds for semi-permanently reserved resources, or by using different RSRP increment steps for semi-permanently reserved resources compared to dynamically reserved resources. A WTRU can use different initial RSRP thresholds for semi-permanently reserved resources. For example, the initial RSRP threshold applied to semi-permanently reserved resources may be lower than the threshold applied to dynamically reserved resources. A WTRU can use different RSRP increment steps for semi-permanently reserved resources compared to dynamically reserved resources. For example, a WTRU may (pre-configure) RSRP increment steps (e.g., two RSRP increment steps), where the first step may be associated with a semi-permanently reserved resource and the other step with a dynamically reserved resource. The WTRU can determine which RSRP increment steps are available based, for example, whether the resource is semi-permanently reserved or dynamically reserved.

[0340] Congestion control may be provided. The WTRU may measure the channel busy rate of the DRX (e.g., CBR_drx) to determine the congestion level of resources associated with the DRX configuration, for example. The WTRU may perform sidelink received signal strength indicator (SL-RSSI) measurements within a set of DRX ON resources. For CBR_drx calculation in slot n, the WTRU may perform SL-RSSI measurements over a (pre-configured) number of DRX ON periods. CBR_drx may be determined as a weighted sum of CBRs measured during DRX ON times (e.g., each DRX ON time). The weight vectors may be (pre-configured) by the network for each resource pool and / or each DRX configuration.

[0341] WTRU can perform SL-RSSI measurements during DRX ON and DRX OFF times. CBR_drx can be calculated as a weighted CBR during DRX ON times and CBR during DRX OFF times. Weight vectors can be configured (in advance) for each resource pool and / or DRX configuration. The CBR during DRX ON times may have higher weights than the CBR during DRX OFF times. Such CBR_drx measurements may allow WTRU to reduce congestion (e.g., congestion level) during DRX ON times, for example.

[0342] A WTRU may (pre-configure) a measurement window that can be used to calculate CBR_drx (e.g., measurement window time). CBR_drx may be associated with TB QoS (e.g., TB QoS). A WTRU may determine the time of CBR_drx that can be used to perform CBR_drx calculations based on TB QoS. In some examples, CBR and / or CBR_drx may be received from a peer WTRU via a PC5 interface, radio resource control (RRC) messages, or a medium access control element (MAC CE). CBR and / or CBR_drx may also be received from a peer WTRU via messages, e.g., sidelink messages.

[0343] One WTRU can receive the CBR and / or CBR_drx from another WTRU. The receiving WTRU can perform congestion control based on the received CBR and / or CBR_drx. The CBR and / or CBR_drx may be indicated by one or more synchronization signals (for example, via a sidelink physical broadcast channel (SL-PBCH)).

[0344] The WTRU can determine, for example, one or more transmit parameters during DRX ON time based on CBR_drx. With respect to transmission during DRX ON and / or DRX OFF time, the WTRU can determine, based on its CBR_drx, one or more of the following parameters: the range of modulation and coding schemes (e.g., MCS) with respect to a given MCS table supported in the resource pool, the range of the number of subchannels used for TB transmission (e.g., one TB transmission), the range of the number of TB(re)transmissions, or the range of transmit power.

[0345] A WTRU can determine the slots for triggering resource selection for a TB (e.g., one TB). A WTRU may be pre-configured with a set of acceptable resource selection trigger slots for a TB. A WTRU may be pre-configured for each resource pool and / or relay service. A WTRU can select a resource selection trigger slot for a TB from the set of acceptable resource selection trigger slots (e.g., randomly). The set of acceptable resource selection trigger slots may be pre-configured based on one or more of the TB's QoS, the CBR_drx measured within the resource pool, or the resource pool's DRX configuration and / or CBR. A WTRU can determine the set of acceptable resource selection trigger slots based on the TB's priority. For example, a high-priority TB may be able to trigger resource selection in a slot (e.g., any slot). A low-priority TB may not be able to trigger resource selection in a slot (e.g., the slot at the start of the DRX ON time in a DRX cycle). In some examples, multiple sets of acceptable resource selection trigger slots may include sets associated with ranges of CBR and / or CBR_drx (e.g., each set). The WTRU can select a set of acceptable resource selection trigger slots based on CBR and / or CBR_drx.

[0346] The WTRU can determine a window of candidate slots and / or sets of candidate slots for resource selection. The WTRU can (pre-configure) a set of acceptable slots for resource selection. This set of acceptable slots for resource selection can be determined based on one or more of the following: TB QoS, resource pool CBR, or CBR_drx. Based on these parameters and / or related configurations, the WTRU can determine which slots may be used to perform resource selection.

[0347] In some cases, with partially sensing-based resource allocation, the WTRU may randomly select a candidate starting window slot (for example, randomly selecting slot n+Y1 for a candidate slot window [n+Y1, n+Y2]). Random starting window candidate slot selection may allow the WTRU to avoid selecting a similar window for the candidate slot for resource selection.

[0348] WTRU can perform CR_drx calculations. WTRU can calculate the DRX channel occupancy (e.g., CR_drx) to determine WTRU's channel occupancy during DRX ON time. CR_drx in slot n may be calculated based on the number of resources used for transmission during past XDRX ON periods, and / or the number of resources reserved and / or selected for transmission during future YDRX ON periods. The values ​​of X and / or Y may be fixed and / or (pre-configured) for each DRX configuration per resource pool.

[0349] The WTRU can perform congestion control based on CR_drx. For example, if CR_drx is greater than a threshold, the WTRU may drop a TB transmission and retransmit the TB during the next DRX ON time. In some examples, if a transmission (e.g., one transmission) is dropped due to congestion control, the WTRU may drop one or more subsequence transmissions of the TB if subsequent transmissions are not signaled and / or if subsequent transmissions fall within a DRX OFF time.

[0350] A WTRU can determine whether to measure the CBR before a reserved resource (e.g., one reserved resource). A WTRU may (pre-configure) multiple CBRs (e.g., two CBRs). The CBRs may include a default CBR and a measured CBR. A WTRU can use the CBRs to determine whether to perform a transmission using a sidelink resource. A WTRU may not perform a transmission on a sidelink resource if the WTRU's channel occupancy (e.g., CR) and / or CBR are greater than a threshold. A WTRU may perform a transmission using a sidelink resource if the WTRU's CR and / or CBR are less than a threshold. The CR threshold may (pre-configure) as a function of the CBR. For reserved sidelink resources, a WTRU can determine which CBR to use. A WTRU can make a decision based on whether it performs a preemption check on the reserved sidelink resource. If a preemption check is not performed, the WTRU can use the default CBR. Otherwise, the WTRU can use the measured CBR.

[0351] A WTRU can determine the window for calculating the CBR of a resource pool. In some examples, a WTRU can determine the window for calculating the CBR of a resource pool based on one or more of the following: whether semi-persistent reservations are enabled or disabled in the resource pool, the QoS of the TB, the HARQ type of the TB (e.g., HARQ-enabled or non-enabled TB), whether the WTRU can perform semi-persistent reservations for selected resources, or whether SL DRX is configured in the WTRU.

[0352] In some cases, a WTRU can determine a window for calculating the Resource Pool's Common Value Rating (CBR) based on whether semi-persistent reservations are enabled or disabled in the resource pool. For example, a WTRU may (pre-configure) a set of sensing windows (e.g., two sets) for calculating the CBR. The first set of sensing windows may be used for resource pools where semi-persistent reservations are enabled. The second set of sensing windows may be used for resource pools where semi-persistent reservations are disabled.

[0353] WTRU can determine the window for calculating the CBR of a resource pool based on the QoS of the TBs. For example, WTRU may (pre-configure) one window for each TB priority. WTRU can determine the window for measuring CBR based on the TB priority.

[0354] The WTRU can determine the window for calculating the CBR of a resource pool based on the HARQ type of the TB (e.g., HARQ-enabled or non-HARQ-enabled TB). For example, the WTRU may (pre-configure) sensing windows (e.g., two sensing windows) for determining the CBR. One of the sensing windows may be used for HARQ-enabled TBs. The other sensing window may be used for non-HARQ-enabled TBs. The WTRU can determine which sensing window to use based on the TB's HARQ type.

[0355] A WTRU can determine a window for calculating the CBR of a resource pool based on whether the WTRU can perform a semi-persistent reservation of the selected resources. For example, a WTRU may (pre-) configure sensing windows (e.g., two sensing windows) for determining the CBR. One of the sensing windows may be used for semi-persistently selected resources, and the other sensing window may be used for dynamically selected resources.

[0356] The WTRU can determine the window for calculating the resource pool's CBR based on whether the SL DRX is configured as a WTRU. For example, the WTRU may (pre-configure) sensing windows (e.g., two sensing windows) for determining the CBR. If the SL DRX is configured as a Tx WTRU and / or Rx WTRU, one of these sensing windows can be used. If the DRX is not configured as either a Tx WTRU or an Rx WTRU, the other sensing window can be used.

[0357] A WTRU may (pre-configure) a sliding window (e.g., 100 slots) for calculating the CBR for each resource pool. A WTRU may (pre-configure) the minimum number of slots within the sliding window (e.g., each sliding window) for determining the CBR of a resource pool. If a WTRU measures more slots than the minimum number within the sliding window, it can use the measured CBR. If a WTRU measures fewer slots than the minimum required, it can either drop the TB or use the default CBR that may (pre-configure) for each resource pool.

[0358] The minimum number of sensing slots within a sliding window and / or the sliding window size may be determined based on one or more of the following: whether semi-persistent reservations are enabled or disabled in the resource pool, the QoS of TB, the HARQ type of TB, whether the WTRU performs semi-persistent reservations for selected resources, or whether an SL DRX is configured for the WTRU.

[0359] The minimum number of sensing slots within a sliding window and / or the sliding window size may be configured based on whether semi-persistent reservations are enabled or disabled in the resource pool. For example, the WTRU may be (pre-configured) with a minimum set of sensing slots within the sliding window size for calculating the CBR (e.g., two sets), one of which set may be used for resource pools where semi-persistent reservations are enabled, and the other set may be used for resource pools where semi-persistent reservations are disabled.

[0360] The minimum number of sensing slots within a sliding window and / or the sliding window size may be configured based on the QoS of the TBs. For example, the WTRU may be configured with one or more sets of minimum sensing slots within a sliding window size and / or sliding window sizes for calculating the CBR for each TB priority. The WTRU can determine the set used to measure the CBR based on the TB priority.

[0361] The minimum number of sensing slots within a sliding window and / or the sliding window size may be configured based on the HARQ type of the TB. For example, a WTRU may (pre-configure) a minimum set of sensing slots within a sliding window size for calculating the CBR (e.g., two sets) and / or a sliding window size, one set of which may be used for HARQ-enabled TBs and another set for non-HARQ-enabled TBs. The WTRU can determine, based on the HARQ type of the TB, which set of the minimum number of sensing slots within a sliding window size can be used to calculate the CBR.

[0362] The minimum number of sensing slots within a sliding window and / or the sliding window size may be configured based on whether the WTRU performs a semi-persistent reservation of selected resources. For example, the WTRU may (pre-configure) a minimum set of sensing slots within the sliding window size for calculating the CBR (e.g., two sets) and / or the sliding window size. One of the configured sets may be used for semi-persistently selected resources. A second set of the configured sets may be used for resources that may be dynamically selected.

[0363] The minimum number of sensing slots within the sliding window and / or the sliding window size may be configured based on whether the SL DRX is configured as a WTRU. For example, the WTRU may (pre-configure) a minimum set of sensing slots within the sliding window size for determining the CBR (e.g., two sets) and / or the sliding window size. One of the configured sets may be used if the SL DRX is configured as a Tx WTRU and / or Rx WTRU. The second set of configured sets may be used if the DRX is not configured as either a Tx WTRU or an Rx WTRU.

[0364] Random resource allocation extensions may be provided. The Tx WTRU may be configured (pre-configured) with a set of resource allocations for random selection of resources for SL transmission. Resource allocations may include resource pools and / or subbands of resource pools. Resource pools may include a set of subchannels that may be configured (pre-configured) within the SL bandwidth part (BWP) and / or SL carrier, and / or identified by a resource pool index. Subbands of resource pools may include a set of subchannels (e.g., consecutive subchannels) that may be configured (pre-configured) within the resource pool. Sets of subchannels may be identified using a subband index.

[0365] The Tx WTRU can (re)select a resource allocation from the (pre)configured resource allocations for SL transmission of SL TB. The Tx WTRU can randomly (re)select resources within the selected resource allocation for SL transmission. The Tx WTRU can (re)select a resource allocation for transmission of SL TB as described herein.

[0366] A Tx WTRU can randomly (re)select resource allocations for resource selection for SL transmission. For example, a Tx WTRU may (pre) configure several SL transmission resource pools (e.g., eight SL transmission resource pools). As part of resource selection for SL transmission, the Tx WTRU can randomly (re)select one of the (pre) configured SL transmission resource pools. A Tx WTRU may (pre) configure several subbands within a resource pool (e.g., four subbands). The Tx WTRU can randomly (re)select one subband for resource selection (e.g., from several subbands).

[0367] The Tx WTRU can (re)select resource allocations for SL transmission based on the priority and / or WTRU ID of the SL TB being transmitted. For example, a range of priorities may be (pre) configured for resource allocations (e.g., resource pools and / or subbands of resource pools). The Tx WTRU can (re)select resource allocations associated with the priority of the SL TB being transmitted. A Tx WTRU can use L1 destination and / or source IDs to determine the index of a resource allocation (e.g., a resource pool and / or a subband of a resource pool). The L1 destination and / or source IDs may be configured by the upper layer. The determination may also be based on the behavior of the decimal version of the WTRU L1 destination and / or source IDs modulo the total number of (pre-configured) resource allocations. A Tx WTRU can (re)select a resource allocation identified by the resource allocation index.

[0368] The Tx WTRU can (re)select resource allocations for SL transmission resource selection based on information received from the Rx WTRU via the PSICH (Physical SL Indication Channel) and / or PSCCH. The information indicated by the PSICH may include one or more types of expected and / or detected conflicts in the resources reserved by the Tx WTRU, such as slot conflict information and / or reserved resource conflict information, or resource busy indication information.

[0369] Slot conflict information may be specific to one or more time slots that are unavailable for reception, for example, slots scheduled for SL and / or UL transmissions by Rx WTRUs in reserved resources. This type of conflict may be resolved, for example, to prevent Rx WTRUs from losing track of TBs that could be transmitted by Tx WTRUs. Bit fields in PSICH may indicate such conflicted slots. For example, the time resource indicator value (TRIV) may be calculated based on the time offset of the conflicted slot relative to the reserved slot of Tx WTRU.

[0370] Reserved resource conflict information may be specific to the reserved resource (e.g., the number of subchannels in an SL slot). For example, a reserved resource may be reserved by SL transmissions of multiple Tx WTRUs. The conflict may be resolved, for example, by one of the WTRUs to re-select another resource for transmission. In such cases, the conflict can be avoided.

[0371] The information presented in PSICH may include resource busy indicators. Resource busy indicators may be based on one or more resource busy metrics measured by Rx WTRU. Resource busy indicators may include indicators of resource allocations that can be used for Tx WTRU resource (re)selection. For example, indices of resource pools and / or subbands of resource pools may be presented in the PSICH or SCI bitfield of PSCCH. The presented resource allocations may be based on CBR, RSSI, priority, and / or priority-specific CBR measured and / or evaluated within the resource allocation. Resource busy indicators may include bitmaps. Bits in the bitmap (e.g., each bit) may represent (pre-)configured resource allocations (e.g., resource pools and / or subbands of resource pools). Bitmaps can provide information about resource allocations that can be used for Tx WTRU (re)selection. For example, a bit (e.g., each bit) may be set to 1 if the measured resource busy metric for the resource allocation corresponding to that bit is below a (pre-configured) threshold (e.g., recommended for use in resource (re)selection).

[0372] Rx WTRU can measure and / or evaluate resource busy indicators based on the resource busy metric evaluation window and / or resource busy metrics. For resource busy metric evaluation windows, the Rx WTRU may be configured (in advance) with an evaluation window length (L). The arrangement of resource busy metric evaluation windows may be based on the evaluation window (L) and / or PSICH transmission slots (n). For example, resource busy metric may be (nLT proc ) starts with (nT proc In a window ending at ), it can be evaluated by Rx WTRU. Resource busy metrics may include one or more of the following: CBR, RSSI, priority, priority-specific CBR, or priority-specific RSSI. Rx WTRU can measure and / or evaluate the CBR of resource allocations (e.g., resource pools and / or subbands of resource pools within a (pre-configured) resource busy metric evaluation window). A low CBR of a resource allocation can indicate that the resource allocation is not busy and / or that the probability of transmission collisions using randomly selected resources is low. The Rx WTRU can measure and / or evaluate the RSSI of resources (e.g., each of the resources) in a resource allocation (e.g., a resource pool and / or subbands of a resource pool within a (pre-configured) resource busy metric evaluation window). For each resource allocation, the Rx WTRU can determine the resource busy metric based on the mean, minimum, and / or maximum RSSI of the subchannels belonging to the resource allocation (e.g., all subchannels). A low RSSI metric of a resource allocation can indicate that the resource allocation is not busy and / or that the probability of transmission collisions using randomly selected resources is low. The Rx WTRU can measure and / or evaluate the L1 priority associated with each decoded SCI (e.g., each of the decoded SCIs) in a resource allocation within a (pre-configured) resource busy metric evaluation window. With respect to resource allocation (e.g., each resource allocation), the Rx WTRU can determine the resource busy metric based on the average, minimum, and / or maximum L1 priority of the decoded SCIs in the resource allocation (e.g., each of the decoded SCIs). The Rx WTRU can measure and / or evaluate the CBR of resources (e.g., all resources) belonging to resource allocations specific to (pre-configured) priorities (e.g., each pre-configured priority). The CBR measurement and / or evaluation may include resources (e.g., all resources) whose decoded SCI priority is less than the relevant priority. For example, the CBR specific to L1 priority 3 may be measured and / or evaluated on subchannels where the decoded L1 priority is less than 3. The Rx WTRU can indicate priority-specific CBRs corresponding to the priorities indicated in the resource reservation by the Tx WTRU via PSICH. The Rx WTRU can indicate resource allocations and / or related priorities via PSICH.The Rx WTRU can measure and / or evaluate the RSSI of resources (e.g., each of the resources) belonging to resource assignments that may be specific to (pre-configured) priorities (e.g., each (pre-configured) priorities. RSSI measurement and / or evaluation may include resources (e.g., each of the resources) whose decoded SCI priority is less than the relevant priority. For example, the RSSI specific to L1 priority 3 may be measured and / or evaluated on subchannels where the decoded L1 priority is less than 3. The Rx WTRU can determine RSSI metrics specific to the relevant priority, for example, based on mean, minimum, and / or maximum RSSIs. The Rx WTRU can indicate resource assignments and / or relevant priorities via PSICH.

[0373] A Tx WTRU can perform a random selection of resources within the resource allocation indicated via PSICH. For example, a Tx WTRU can perform a random (re)selection within the resource pool corresponding to the index indicated via the received PSICH. In some examples, a Tx WTRU can perform a random (re)selection within the subband corresponding to "1" in the bitmap received via PSICH.

[0374] A Tx WTRU can exclude resource allocations indicated via PSCCH from random resource selection. For example, a Tx WTRU can exclude an indicated SL slot where slot contention is indicated via the received PSCCH.

[0375] The Tx WTRU may decide whether to perform a random selection for resource (re)selection based on the priority of the transmitted TB and / or priority-specific CBR indicated via PSICH. If the priority-specific CBR is higher than a threshold configured in the resource allocation, the Tx WTRU may exclude the resource allocation from the random selection of resources for TBs with a priority lower than or equal to the priority specific to the CBR.

[0376] The Tx WTRU may determine whether to perform a random selection for resource (re)selection based on the priority of the transmitted TB and / or the priority-specific RSSI metric indicated via PSICH. If the priority-specific CBR is higher than a (pre-configured) threshold within the resource allocation, the Tx WTRU may exclude the resource allocation from the random selection of resources for TBs with a priority lower than or equal to the priority specific to the CBR.

[0377] A Tx WTRU may indicate a random selected resource assignment via a PSCCH associated with a PSSCH transmitted with the (re)selected resource. The SCI carried in the PSCCH may include a bit field indicating the type of resource assignment to be performed. For example, a 2-bit SCI field may be applied, and the code point may be (pre-defined) to indicate fully sensing, partially sensing, or random selection.

[0378] A WTRU can decide whether to semi-permanently reserve a randomly selected resource. In some examples, a WTRU can decide whether to semi-permanently reserve a randomly selected resource based on one or more of the following: TB's QoS, traffic type (e.g., periodic or aperiodic traffic), TB's HARQ type, resource pool's CBR, or whether DRX is configured for the WTRU.

[0379] A WTRU can decide whether to semi-permanently reserve a randomly selected resource based on the TB's QoS. A priority threshold may be configured (in advance) for the WTRU. The WTRU can semi-permanently reserve a resource if the TB's priority is lower than the threshold. The WTRU may not be able to semi-permanently reserve a resource if the TB's priority is higher than the threshold. In some examples, a single priority threshold may be configured (in advance) for the WTRU. The WTRU can semi-permanently reserve a resource if the TB's priority is higher than the threshold. The WTRU may not be able to semi-permanently reserve a resource if the TB's priority is lower than the threshold.

[0380] A WTRU can decide whether to semi-permanently reserve a randomly selected resource based on the HARQ type of the TB. For example, a WTRU can semi-permanently reserve a resource for a HARQ-enabled TB. A WTRU may not be able to permanently reserve a resource for a non-HARQ-enabled TB.

[0381] A WTRU can decide whether to semi-permanently reserve a randomly selected resource based on the resource pool's CBR. For example, a WTRU can semi-permanently reserve a resource if the resource pool's CBR is greater than a threshold. Otherwise, a WTRU may not be able to semi-permanently reserve a resource.

[0382] A WTRU can decide whether to semi-permanently reserve a randomly selected resource based on whether a DRX is configured for the WTRU. For example, if a DRX is configured for a WTRU, the WTRU may be able to semi-permanently reserve a resource. If a DRX is not configured for a WTRU, the WTRU may not be able to semi-permanently reserve a resource.

[0383] The transmitting wireless transmitter / receiver unit (Tx WTRU) can receive configuration information indicating one or more parameters. These parameters may be associated with resource selection. The Tx WTRU can determine a first resource selection window and a second resource selection window. The first resource selection window may be associated with the active time of the receiving wireless transmitter / receiver unit (Rx WTRU). The second resource selection window may be associated with the inactive time of the Rx WTRU. The Tx WTRU can determine a first number of candidate resources associated with the first resource selection window. The Tx WTRU can determine a first number of candidate resources associated with the second resource selection window. In some examples, the Tx WTRU can increase the first number of candidate resources associated with the first resource selection window to a second number of candidate resources associated with the first resource selection window. The second number of candidate resources associated with the first resource selection window may exceed a resource threshold (e.g., the first resource threshold). A Tx WTRU may select one or more (re)transmit resources. The selected one or more (re)transmit resources may be from the second number of candidate resources associated with the first resource selection window. The number of selected one or more (re)transmit resources may be based on the second number of candidate resources associated with the first resource selection window. Instructions for one or more selected (re)transmit resources may be sent, and the Tx WTRU may send data on one or more selected (re)transmit resources.

[0384] A Tx WTRU can select resources for transmission to another WTRU, which may be, for example, an Rx WTRU (e.g., a DRX Rx WTRU). A Tx WTRU can select a resource selection trigger time (e.g., slot n before the start of the resource selection window) such that the resource selection window contains at least a certain number of active slots of the Rx WTRU (e.g., a (pre-configured) number of active slots of the Rx WTRU). If a Tx WTRU cannot find a trigger time that satisfies the condition that the number of active slots of the Rx WTRU in the resource selection window is greater than a threshold, the Tx WTRU can drop the transport block (TB) and / or select another resource pool for transmission of the TB.

[0385] A Tx WTRU can select a set of candidate slots. The Tx WTRU can select a set of candidate slots within the resource selection window. The set of candidate slots may include at least a certain number of active slots of the Rx WTRU (for example, a (pre-configured) number of active slots of the Rx WTRU). The number of active slots of the Rx WTRU may, for example, be placed at the beginning of the set of candidate slots in terms of time.

[0386] The Tx WTRU can determine the set of selectable resources, for example, by excluding unavailable resources. The Tx WTRU can increase the number of selectable resources if the number of selectable resources in the set of active slots of the Rx WTRU is less than a threshold (e.g., a (pre-configured) threshold) and / or the percentage of selectable resources in the set of candidate slots is less than a threshold (e.g., another threshold). For example, the Tx WTRU can increase the reference signal received power (RSRP) threshold (for example, to determine the availability of resources in the set of candidate slots) if the number of selectable resources in the set of active slots of the Rx WTRU is less than a threshold (e.g., a (pre-configured) threshold) and / or the percentage of selectable resources in the set of candidate slots is less than a threshold (e.g., another threshold).

[0387] A Tx WTRU can select a transmission resource from a set of selectable resources for sending a transport block (TB). The transmission resource may be within the Rx WTRU's active time and within a range (e.g., a pre-configured range, such as greater than a first threshold and less than a second threshold). The WTRU can then perform the transmission of the TB using the selected set of transmission resources.

[0388] The Tx WTRU performs congestion control on the DRX. The Tx WTRU can perform a CBR_drx measurement to determine the congestion level of resources associated with the configuration of the DRX of the TB's Tx WTRU or the Rx WTRU's DRX. The Tx WTRU can determine an acceptable set of resource selection trigger times (e.g., a set of n values) based on one or more of the TB's quality of service, CBR_drx, or the resource pool's channel busy ratio (CBR). The Tx WTRU can select a resource selection trigger time from the acceptable set (e.g., randomly).

[0389] A Tx WTRU can perform sensing to detect periodic resource reservations. A Tx WTRU can (pre-configure) a set of reservation intervals, perform sensing (e.g., for periodic sensing and / or detection of periodic reservations), and / or extract sensing results. A Tx WTRU can determine a subset of reservation intervals based on the traffic type (e.g., whether the WTRU performs periodic reservations for selected resources) and / or the QoS of the TB. If a Tx WTRU performs periodic reservations for selected resources, it can sense and / or extract sensing results from (pre-configured) reservation periods (e.g., each of the pre-configured reservation periods). If a Tx WTRU does not perform periodic reservations, it can determine a set of reservation periods for sensing and / or extracting sensing results based on the QoS of the TB.

[0390] Although the features and elements described above are described in specific combinations, each feature or element may be used alone without other features and elements of the preferred embodiment, or in various combinations with or without other features and elements.

[0391] While the implementations described herein may take into account 3GPP-specific protocols, it is understood that the implementations described herein are not limited to this scenario and may be applicable to other wireless systems. For example, while the solutions described herein take into account LTE, LTE-A, New Radio (NR), or 5G-specific protocols, it is understood that the solutions described herein are not limited to this scenario and may be further applicable to other wireless systems. For example, while systems have been described with reference to 3GPP, 5G, and / or NR network layers, the envisioned embodiments extend beyond implementations using specific network layer technologies. Similarly, potential implementations encompass all types of service layer architectures, systems, and embodiments. The technologies described herein can be applied independently and / or used in combination with other resource configuration technologies.

[0392] The processes described herein may be implemented in computer programs, software, and / or firmware embedded in computer-readable media for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, internal hard disks, and removable disks, as well as magnetic media, magneto-optical media, and / or optical media such as compact disc (CD)-ROM discs and / or digital versatile disks (DVD). A processor associated with the software may be used to implement radio frequency transceivers for use in WTRUs, terminals, base stations, RNCs, and / or any host computer.

[0393] It is understood that entities performing the processes described herein may be logical entities that can be implemented in the form of software (e.g., computer executable instructions) stored in the memory of a mobile device, a network node, or a computer system and executed on its processor. That is, the process may be implemented in the form of software (e.g., computer executable instructions) stored in the memory of a mobile device and / or a network node such as a node or computer system, and when these computer executable instructions are executed by the node's processor, they perform the process discussed. It is also understood that any transmit and receive processes shown in the drawings may be performed by the node's communication circuitry under the control of the node's processor and the computer executable instructions (e.g., software) it executes.

[0394] The various technologies described herein may be implemented in relation to hardware, software, or a combination of both as appropriate. Therefore, implementations and apparatus of the subject matter described herein, or particular aspects or parts thereof, may take the form of program code (e.g., instructions) embodied in tangible media including any other machine-readable storage medium, and when the program code is loaded and executed on a machine such as a computer, that machine becomes an apparatus for carrying out the subject matter described herein. Where the program code is stored on a medium, the program code may be stored on one or more media that collectively perform the actions, i.e., one or more media together contain the code for performing the actions, provided that if two or more single media exist, it is not necessary to store specific parts of the code on specific media. In the case of program code execution on a programmable device, the computing device generally includes a processor, a processor-readable storage medium (including volatile and non-volatile memory and / or memory elements), at least one input device, and at least one output device. One or more programs may implement or utilize the processes described herein in relation to the subject matter described herein, for example, through the use of APIs, reusable controls, etc. Such programs are preferably implemented in a high-level procedural or object-oriented programming language for communication with a computer system. However, programs may be implemented in assembly language or machine code, if necessary. In either case, the language may be a compiled language or an interpreted language, and may be combined with a hardware implementation.

[0395] While exemplary embodiments may refer to utilizing aspects of the subject matter described herein in the environment of one or more standalone computing systems, the subject matter described herein is not limited in that sense and may rather be implemented in connection with any computing environment, such as a network or distributed computing environment. Furthermore, aspects of the subject matter described herein may be implemented in or across multiple processing chips or devices, and storage may similarly be affected across multiple devices. Such devices may include personal computers, network servers, handheld devices, supercomputers, or computers integrated into other systems such as automobiles or airplanes.

[0396] In describing preferred embodiments of the subject matter of this disclosure, certain terms are used for clarity, as illustrated in the figures. However, it should be understood that the claimed subject matter is not intended to be limited to the specific terms thus selected, and each particular element includes all technical equivalents that operate in a similar manner to achieve a similar purpose.

Claims

1. A wireless transmitter / receiver unit (WTRU), The system receives configuration information indicating a set of periodic partial sensing slots and a set of continuous partial sensing slots. It is determined that the first sensing slot associated with the set of period-based partial sensing slots is within a discontinuous reception (DRX) inactive duration, Based on the determination that the first sensing slot is within the discontinuous reception (DRX) inactive duration, it is decided to skip sensing in the first sensing slot. It is determined that the second sensing slot is associated with the set of continuous partial sensing slots, Based on the determination that the second sensing slot is associated with the set of consecutive partial sensing slots, it is determined to perform sensing in the second sensing slot, and the second sensing slot is within the DRX inactive duration. Detection is performed in the second sensing slot. Processor configured in such a way A WTRU characterized by having the following features.

2. The WTRU according to claim 1, characterized in that the DRX inactive duration is the DRX OFF duration.

3. Receiving configuration information indicating a set of periodic partial sensing slots and a set of continuous partial sensing slots, Determining that the first sensing slot associated with the set of period-based partial sensing slots is within a discontinuous reception (DRX) inactivity duration, Based on the determination that the first sensing slot is within the discontinuous reception (DRX) inactive duration, it is decided to skip sensing in the first sensing slot, It is determined that the second sensing slot is associated with the set of continuous partial sensing slots, Based on the determination that the second sensing slot is associated with the set of continuous partial sensing slots, the determination to perform sensing in the second sensing slot, wherein the second sensing slot is within the DRX inactive duration, The second sensing slot described above will perform sensing. A method characterized by comprising:

4. The method according to claim 3, characterized in that the DRX inactive duration is the DRX OFF duration.

Images