Partial sensing based resource allocation

Abstract

A transmitting wireless transmit / receive unit (Tx WTRU) can receive configuration information indicating one or more parameters. The one or more parameters can 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 can be associated with an active time of a receiving wireless transmit / receive unit (Rx WTRU). The second resource selection window can be associated with an 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 an example, 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.

Description

[0001] This application is a divisional application of Chinese Patent Application No. 202280031463.7 entitled “Resource Allocation Based on Partial Sensing”, filed on March 28, 2022, the contents of which are incorporated herein by reference.

[0002] Cross-references to related applications

[0003] This application claims the benefit of Provisional U.S. Patent Application No. 63 / 168,052, filed March 30, 2021; Provisional U.S. Patent Application No. 63 / 185,675, filed May 7, 2021; Provisional U.S. Patent Application No. 63 / 228,812, filed August 3, 2021; Provisional U.S. Patent Application No. 63 / 249,384, filed September 28, 2021; and Provisional U.S. Patent Application No. 63 / 275,212, filed November 3, 2021, the disclosures of which are incorporated herein by reference in their entirety. Background Technology

[0004] Device-to-device (D2D) communication and vehicle-to-everything (V2X) communication enable wireless transmitter / receiver units (WTRUs) to communicate directly, for example, via a PC5 interface. In-coverage and out-of-coverage modes are available for D2D and V2X communication. However, the current mechanisms for D2D and V2X communication may be insufficient for some V2X-based use cases. Summary of the Invention

[0005] A transmitting wireless transmit / receive 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 a receiving wireless transmit / receive 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 an example, the Tx WTRU may 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 be higher than a resource threshold (e.g., a first resource threshold). The 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 (re)transmission resources may be based on a second number of candidate resources associated with the first resource selection window. An indication may be transmitted for the selected (re)transmission resources, and the Tx WTRU may transmit data in the selected (re)transmission resources.

[0006] A Tx WTRU can select resources for transmission, such as to another WTRU, which can be an RxWTRU (e.g., a DRX Rx WTRU). The 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 includes at least a certain number of active slots for Rx WTRUs (e.g., a (pre-)configured number of active slots for Rx WTRUs). If the Tx WTRU cannot find a trigger time that satisfies the condition that the number of active slots for Rx WTRUs within the resource selection window is greater than a threshold, the Tx WTRU can discard the transport block (TB) and / or select another resource pool for transmitting the TB.

[0007] The Tx WTRU can select a set of candidate time slots. The Tx WTRU can select a set of candidate time slots within a resource selection window. The set of candidate time slots can include at least a certain number of active time slots of the Rx WTRU (e.g., a (pre-)configured number of active time slots of the Rx WTRU). This number of active time slots of the Rx WTRU can, for example, be located at the beginning of the candidate time slot set in time.

[0008] A Tx WTRU may determine the set of selectable resources, for example, by excluding unavailable resources. If the number of selectable resources in the active slot set of the Rx WTRU is less than a threshold (e.g., a (pre)configured threshold) and / or the percentage of selectable resources in the candidate slot set is less than a threshold (e.g., another threshold), the Tx WTRU may increase the number of selectable resources. For example, if the number of selectable resources in the active slot set of the Rx WTRU is less than a threshold (e.g., a (pre)configured threshold) and / or the percentage of selectable resources in the candidate slot set is less than a threshold (e.g., another threshold), the Tx WTRU may increase its Reference Signal Received Power (RSRP) threshold (e.g., to determine the availability of resources in the candidate slot set).

[0009] The Tx WTRU can select transport resources from a set of selectable resources for transmitting a Transport Block (TB). The transport resources can be those available during 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 use the selected set of transport resources to perform the transmission of the TB.

[0010] The Tx WTRU performs congestion control in DRX. The Tx WTRU can perform CBR_drx measurements to determine the congestion level of resources associated with the DRX configuration of the Tx WTRU or the DRX configuration of the Rx WTRU of the TB. The Tx WTRU can determine a set of permissible resource selection trigger times (e.g., a set of values ​​for n) based on one or more of the following: the TB's Quality of Service (QoS), CBR_drx, or the channel busy rate (CBR) of the resource pool. The Tx WTRU can select (e.g., randomly select) a resource selection trigger time within the permissible set.

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

[0012] Figure 1AThis is a system diagram illustrating an exemplary communication system that can be implemented in one or more of the disclosed embodiments.

[0013] Figure 1B It is shown in the implementation plan. Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) used within the communication system shown.

[0014] Figure 1C It is shown in the implementation plan. Figure 1A The diagram shows an exemplary radio access network (RAN) and an exemplary core network (CN) used within the communication system.

[0015] Figure 1D It is shown in the implementation plan. Figure 1A The system diagram shown illustrates another exemplary RAN and another exemplary CN used within the communication system.

[0016] Figure 2 An example of establishing a secure Layer 2 link over a PC5 interface is shown.

[0017] Figure 3 The resource selection window for the Transport Block (TB) associated with the Wireless Transmit / Receive Unit (WTRU) is shown.

[0018] Figure 4 An exemplary reference signal received power (RSRP) threshold increment is shown for resource selection.

[0019] Figure 5 An exemplary periodic sensing scenario is shown.

[0020] Figure 6 Various examples of sensing associated with different types of TB are shown.

[0021] Figure 7 An example is shown of WTRU determining whether to trigger resource allocation before a potential set of candidate time slots.

[0022] Figure 8 An exemplary selection of available time slots outside the candidate time slot set is shown.

[0023] Figure 9 An example of a selectable set of time slots for WTRU initialization is shown.

[0024] Figure 10 An example of how WTRU determines the short-term partial sensing window is shown.

[0025] Figure 11 This demonstrates how WTRU performs resource reassessment or preemption for resources at time slot m. Detailed Implementation

[0026] Figure 1A This is a schematic diagram illustrating an exemplary communication system 100 that can be implemented in one or more of the disclosed embodiments. Communication system 100 can be a multiple access system providing content such as voice, data, video, messaging, and broadcasting to multiple wireless users. Communication system 100 enables multiple wireless users to access such content through the sharing of system resources (including wireless bandwidth). For example, communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail Unique Word DFT Extended OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0027] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, Public Switched Telephone Network (PSTN) 108, Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a wireless environment. As examples, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile user units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain environments), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0028] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106 / 115, Internet 110, and / or other networks 112. As an example, base stations 114a and 114b may be base transceiver stations (BTS), Node Bs, evolved Node Bs, home Node Bs, home evolved Node Bs, gNBs, NR Node Bs, site controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are each depicted as a single element, it should be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0029] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies (which may be referred to as cells (not shown)). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of radio services to a specific geographic area, which may be relatively fixed or changeable over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in an embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In an embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in desired spatial directions.

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

[0031] More specifically, as noted above, the communication system 100 may be a multiple access system and may employ 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 use Wideband CDMA (WCDMA) to establish air interfaces 115 / 116 / 117. WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​UL Packet Access (HSUPA).

[0032] In the implementation scheme, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as evolved UMTS terrestrial radio access (E-UTRA), which can use Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro) to establish air interface 116.

[0033] In the implementation scheme, base station 114a and WTRUs 102a, 102b, 102c can enable radio technology such as NR radio access, which can use New Radio (NR) to establish air interface 116.

[0034] In the implementation scheme, base station 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can, for example, use a dual connectivity (DC) principle to implement both LTE and NR radio access together. Therefore, the air interface utilized by WTRUs 102a, 102b, and 102c can be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

[0035] In other implementations, base station 114a and WTRUs 102a, 102b, and 102c can implement radio technologies such as IEEE 802.11 (i.e., WiFi), IEEE 802.16 (i.e., WiMAX), CDMA2000, CDMA2000 1X, CDMA2000EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), GSM Enhanced Data Rate Evolution (EDGE), and GSM EDGE (GERAN).

[0036] Figure 1A Base station 114b can be, for example, a wireless router, a home node B, a home evolution node B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in localized areas such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for use by drones), roads, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106 / 115.

[0037] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU 102a, 102b, 102c, and 102d. Data can have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication. Although not explicitly stated... Figure 1AAs shown, but it should be understood that RAN 104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs that use the same RAT as RAN 104 / 113 or a different RAT. For example, in addition to being connected to RAN 104 / 113 which can utilize NR radio technology, CN 106 / 115 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0038] CN 106 / 115 may also act as a gateway for WTRU 102a, 102b, 102c, 102d to access PSTN 108, Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication 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 use the same RAT as RAN 104 / 113 or a different RAT.

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

[0040] Figure 1B This is a system diagram illustrating an exemplary WTRU 102. (See diagram below.) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmitting / receiving 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 peripheral devices 138, etc. It should be understood that, while remaining consistent with the implementation, WTRU 102 may include any sub-combination of the foregoing elements.

[0041] Processor 118 can be a general-purpose processor, a special-purpose 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. Processor 118 can perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 can be coupled to transceiver 120, which can be coupled to transmitting / receiving element 122. Although Figure 1B The processor 118 and transceiver 120 are depicted as separate components, but it should be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0042] Transmitting / receiving element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via air interface 116. For example, in one embodiment, transmitting / receiving element 122 may be an antenna configured to transmit and / or receive RF signals. In one embodiment, transmitting / receiving element 122 may be a transmitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, transmitting / receiving element 122 may be configured to transmit and / or receive RF and optical signals. It should be understood that transmitting / receiving element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0043] Although the transmitting / receiving element 122 is in Figure 1B While depicted as a single element, WTRU 102 may include any number of transmitting / receiving elements 122. More specifically, WTRU 102 may employ MIMO technology. Therefore, in one embodiment, WTRU 102 may include two or more transmitting / receiving elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interface 116.

[0044] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As noted above, WTRU 102 may have multi-mode capability. For example, transceiver 120 may therefore include multiple transceivers to enable WTRU 102 to communicate via various RATs (such as NR and IEEE 802.11).

[0045] The processor 118 of WTRU 102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit) and may receive user input data therefrom. The processor 118 may also output user data to the speaker / microphone 124, keypad 126, and / or display / touchpad 128. Furthermore, 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 any type of suitable memory. 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. Removable memory 132 may include a user identity module (SIM) card, memory stick, secure digital storage (SD) card, etc. In other embodiments, the processor 118 may access information from memory that is not physically located on WTRU 102 (such as on a server or home computer (not shown)) and store data in that memory.

[0046] The processor 118 may receive power from the power supply 134 and may 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 powering the WTRU 102. For example, the power supply 134 may include one or more dry cell battery packs (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0047] 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 air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that, while remaining consistent with the implementation, the WTRU 102 may acquire location information using any suitable location determination method.

[0048] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral device 138 may include an accelerometer, electronic compass, satellite transceiver, digital camera (for photos and / or video), Universal Serial Bus (USB) port, vibration device, television transceiver, hands-free headset, etc. Modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral devices 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

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

[0050] Figure 1C This is a system diagram illustrating RAN 104 and CN 106 according to one implementation scheme. As noted above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with CN 106.

[0051] RAN 104 may include evolved Node Bs 160a, 160b, and 160c; however, it should be understood that RAN 104 may include any number of evolved Node Bs while remaining consistent with the implementation scheme. Each evolved Node B 160a, 160b, and 160c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In the implementation scheme, evolved Node Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, evolved Node B 160a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a.

[0052] Each of the evolved nodes B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, and user scheduling in the UL and / or DL, etc. Figure 1C As shown, evolution nodes B 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0053] Figure 1C The CN 106 shown 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 foregoing elements is depicted as part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0054] The MME 162 can connect to each of the evolved nodes B 162a, 162b, and 162c in RAN 104 via the S1 interface and can be used as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, etc. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0055] The SGW 164 can connect to each of the evolved Nodes B 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 typically routes and forwards user data packets to and from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions such as anchoring the user plane during inter-evolved Node B handovers, triggering paging when DL data is available for WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

[0056] SGW 164 can be connected to PGW 166, which provides WTRU 102a, 102b, 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0057] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, and 102c with access to a circuit-switched network (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and conventional landline communication equipment. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 106 and PSTN 108, or be able to communicate with such an IP gateway. Furthermore, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0058] Despite WTRU in Figures 1A to 1D While described as a wireless terminal, it is conceivable that in some representative implementations, such a terminal may (e.g., temporarily or permanently) use a wired communication interface with a communication network.

[0059] In a representative implementation, the other network 112 may be a WLAN.

[0060] A WLAN in Infrastructure Basic Services Set (BSS) mode may have an access point (AP) for the BSS and one or more sites (STAs) associated with the AP. The AP may have an access or interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or carries traffic out of the BSS. Traffic originating outside the BSS and destined for a STA can reach and be delivered to the STA via the AP. Traffic originating from a STA and destined for a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as point-to-point traffic. Point-to-point traffic can be sent between source and destination STAs (e.g., directly between them) using Direct Link Establishment (DLS). In some representative implementations, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). WLANs using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as the "ad-hoc" communication mode in this document.

[0061] When operating in 802.11ac infrastructure mode or a similar mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of fixed width (e.g., a 20 MHz wide bandwidth) or dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative implementations, such as in an 802.11 system, Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) can be implemented. For CSMA / CA, each STA (including the AP) can listen to the primary channel. If the primary channel is listened to / detected and / or determined to be busy by a particular STA, that STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

[0062] High-throughput (HT) STAs can communicate using a 40MHz wide channel, for example, by combining a primary 20MHz channel with adjacent or non-adjacent 20MHz channels to form a 40MHz wide channel.

[0063] The Very High Throughput (VHT) STA supports channels with widths of 20MHz, 40MHz, 80MHz, and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining eight consecutive 20MHz channels, or by combining two non-consecutive 80MHz channels (this can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, data can be processed by a segment parser that can split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed separately on each stream. These streams can be mapped to two 80MHz channels, and data can be transmitted via the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration can be reversed, and the combined data can be sent to Media Access Control (MAC).

[0064] 802.11af and 802.11ah support operating modes below 1 GHz. Compared to those used in 802.11n and 802.11ac, 802.11af and 802.11ah reduce channel operating bandwidth and carrier. 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 non-TVWS spectrum. According to representative implementations, 802.11ah may support instrument-type control / machine-type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support (e.g., only support) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain a very long battery life).

[0065] WLAN systems supporting multiple channels, as well as channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include channels that can be designated as primary channels. A primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by STAs operating in the BSS (each supporting a minimum bandwidth operating mode). In the 802.11ah example, for STAs supporting (e.g., only supporting) a 1MHz mode (e.g., MTC type devices), the primary channel can be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, because an STA (supporting only the 1MHz operating mode) is transmitting to the AP, the entire available band can be considered busy even if most of the band remains idle and potentially available.

[0066] In the United States, the available frequency band for 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 available bandwidth for 802.11ah is 6MHz to 26MHz, depending on the country code.

[0067] Figure 1DThis is a system diagram illustrating RAN 113 and CN 115 according to one implementation scheme. As noted above, RAN 113 may employ NR radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 113 may also communicate with CN 115.

[0068] RAN 113 may include gNBs 180a, 180b, and 180c, but it should be understood that RAN 113 may include any number of gNBs while remaining consistent with the implementation. Each gNB 180a, 180b, and 180c may include one or more transceivers for communication with WTRUs 102a, 102b, and 102c via air interface 116. In the implementation, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit and / or receive signals from gNBs 180a, 180b, and 180c. Therefore, gNB 180a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In the implementation, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In an implementation, gNBs 180a, 180b, and 180c may implement coordinated multipoint (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0069] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable parameter sets. For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary depending on different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing different numbers of OFDM symbols and / or continuously varying absolute time lengths).

[0070] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., evolved Node Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can use one or more of gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate or connect to gNBs 180a, 180b, and 180c, and also communicate or connect to other RANs (such as evolved Node Bs 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c and one or more evolved Node Bs 160a, 160b, and 160c. In a non-standalone configuration, evolved Node Bs 160a, 160b, and 160c can be used as mobility anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0071] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slicing support, dual connectivity, interoperability between NR and E-UTRA, routing of user plane data to User Plane Functions (UPF) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0072] Figure 1DThe CN 115 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. Although each of the foregoing elements is depicted as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0073] AMF 182a and 182b can connect to one or more of the gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can be used as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating NAS signaling, mobility management, etc. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the type of service used by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services that rely on Ultra-Reliable Low Latency (URLLC) access, services that rely on Enhanced Mobile Broadband (eMBB) access, services for Machine Type Communication (MTC) access, etc. The AMF162 can provide control plane functions for switching between RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies (such as WiFi)).

[0074] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 115 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 115 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure traffic routing through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating 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.

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

[0076] CN 115 can facilitate communication with other networks. For example, CN 115 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 115 and PSTN 108, or be able to communicate with such an IP gateway. Furthermore, CN 115 may provide WTRUs 102a, 102b, and 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, WTRUs 102a, 102b, and 102c may be connected to DN 185a and 185b via UPF 184a and 184b through their N3 interfaces and the N6 interface between UPF 184a and 184b and local data networks (DNs) 185a and 185b.

[0077] Given Figures 1A to 1D as well as Figures 1A to 1D The corresponding descriptions herein refer to one or more of the functions described below, which may be performed by one or more emulation devices (not shown): WTRU102a-d, base station 114a-b, evolved Node B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device described herein. An emulation device may be one or more devices configured to mimic 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.

[0078] Simulation devices can be designed to perform one or more tests on other devices in laboratory and / or carrier network environments. For example, the one or more simulation devices may perform one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. The one or more simulation devices may perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices may be directly coupled to another device for testing purposes and / or may use over-the-air wireless communication to perform tests.

[0079] The one or more simulation devices may perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation devices may be used in test scenarios within a test laboratory and / or non-deployed (e.g., testing) wired and / or wireless communication networks to perform testing of one or more components. The one or more simulation devices may be test equipment. Direct RF coupling and / or wireless communication via an RF circuit system (e.g., which may include one or more antennas) may be used by the simulation devices to transmit and / or receive data.

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

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

[0082] This enables NR V2X access technology systems to support use cases including, for example, enhanced mobile broadband (eMBB), ultra-reliable and low-latency communication (URLLC). NR-based systems can support enhanced V2X (eV2X) communication. eV2X can include services for secure and / or unsecured scenarios (e.g., sensor sharing, autonomous driving, vehicle platooning, remote driving, etc.). For example, the performance of eV2X services can be characterized by a latency of approximately 3ms.

[0083] NR V2X can support one or more of the following use cases: vehicle platooning, advanced driving, extended sensors, remote driving, etc.

[0084] Vehicle platooning allows multiple vehicles to dynamically form groups, enabling them to travel together. Vehicles in the platoon receive data (e.g., periodic data) from the lead vehicle. This data allows for platooning maneuvers. It allows vehicles in the platoon to adjust the distances between them. For example, the distances between vehicles can be small. In this example, the gap between vehicles can be low when converted to time (e.g., approximately a sub-second value). Placing applications can allow vehicles as part of a platoon to drive autonomously.

[0085] Advanced driving enables semi-autonomous or fully autonomous driving. Longer vehicle-to-vehicle distances can be assumed. One or more vehicles and / or RSUs (e.g., each vehicle and / or RSU) can share data obtained from their local sensors with nearby vehicles, allowing vehicles to coordinate their trajectories or maneuvers. In the example, a vehicle can share its driving information with other vehicles in its vicinity. This sharing of driving information between a vehicle and other vehicles in its vicinity enables safer driving, collision avoidance, and / or improved traffic efficiency.

[0086] Extended sensors enable the exchange of raw and / or processed data collected by local sensors and / or data collected from video devices (e.g., cameras) via other vehicles, RSUs, pedestrian equipment, and / or V2X application servers. This data sharing between vehicles, RSUs, pedestrian equipment, and / or V2X application servers enhances awareness of the environment beyond what their own sensors can detect. This data sharing allows vehicles or other devices to have a more comprehensive view of the local situation.

[0087] Remote driving enables remote drivers and / or V2X applications to operate remote vehicles, suitable for passengers who cannot drive themselves and / or remote vehicles in hazardous environments. For situations with limited variation and predictable routes (such as public transportation), cloud-based driving can be used. In this example, access to a cloud-based backend service platform could be considered for this use case group.

[0088] QoS can be provided for NR V2X communication. For example, QoS on PC5 can be supported using ProSe Per-Packet Priority (PPPP) associated with the application. The application layer can utilize PPPP to label packets. PPPP can indicate the QoS level used. In the example, packet delay measurement (e.g., packet delay budget (PDB)) can be derived from PPPP.

[0089] One or more of the following parameters can be provided for one or more QoS Key Performance Indicators (KPIs): payload (e.g., in bytes); transmission rate (e.g., in messages per second); maximum end-to-end latency (e.g., in milliseconds); reliability (e.g., percentage); data rate (e.g., in megabits per second (Mbps)); or minimum communication range (e.g., in meters).

[0090] The service requirement set can be applied to PC5-based V2X communication and / or Uu-based V2X communication. QoS characteristics can be represented by the NR QoS identifier (5QI). A unified QoS model can be provided for PC5 and / or Uu. 5QI can be used for V2X communication on PC5, enabling the WTRU application layer to have a consistent mechanism for indicating QoS requirements, regardless of the link used.

[0091] WTRUs with V2X capabilities can support different types of traffic: broadcast, multicast, and / or unicast. In the case of unicast traffic, the Uu QoS model can be utilized. For example, a unicast link (e.g., each in a unicast link) can be designated as a bearer. One or more QoS flows can be associated with a unicast link (e.g., each in a unicast link). QoS characteristics and parameters defined in 5QI (e.g., data rate) can be applied. The minimum required communication range can be specified as parameters for PC5 use.

[0092] Multicast traffic can be viewed as a special case of unicast traffic, for example, similar to it. For instance, a multicast traffic situation can be viewed as a unicast traffic situation with multiple defined receivers for the traffic. In the case of broadcast traffic, the bearer may not be specified. Therefore, broadcast messages (e.g., each in a broadcast message) may have characteristics depending on the application requirements. 5QIs can be used in a manner similar to PPP / PPPR. In the example, 5QIs can be labeled with broadcast packets (e.g., each in a broadcast packet). 5QIs can represent one or more characteristics associated with PC5 broadcast operations. For example, 5QIs can represent one or more of delay, priority, reliability, etc. A set of V2X broadcast-specific 5QIs (e.g., VQIs) can be provided for PC5 use.

[0093] PC5 QoS parameters can be negotiated. For example, PC5 QoS parameters can be negotiated when establishing one-to-one communication between WTRUs (e.g., two WTRUs). Communication establishment procedures can be provided to support PC5 QoS parameter negotiation between WTRUs (e.g., two WTRUs). Once the PC5 QoS parameters are negotiated, the same QoS can be used in both directions between WTRUs (e.g., two WTRUs).

[0094] Figure 2 This illustrates establishing a secure Layer 2 link over the PC5 interface. (Example:) Figure 2 As shown, WTRUs (e.g., WTRU-1 and WTRU-2) can participate in one-to-one communication to negotiate PC5 QoS parameters during link establishment procedures. WTRU-1 can send a Direct Communication Request message to WTRU-2 to, for example, trigger mutual authentication. The Direct Communication Request message may include the requested PC5 QoS parameters. WTRU-2 can initiate procedures for mutual authentication. WTRU-2 can include the accepted PC5 QoS parameters in a response message. WTRU-2 can send a response message in response to the Direct Communication Request message.

[0095] NR V2X traffic models are available. NR V2X can provide various types of traffic (e.g., two types), such as periodic and non-periodic traffic. Each type of traffic (e.g., two types) can support multiple packet sizes, packet arrival rates, and / or latency requirements. For example, Model 2 non-periodic traffic can support one or more of the following characteristics: a packet size range between 10,000 and 30,000 bytes; an average arrival rate of 20 ms; or a latency requirement of 10 ms. Model 3 periodic traffic can support one or more of the following characteristics: a packet size range between 30,000 and 60,000 bytes; an average arrival rate of 30 ms; or a latency requirement of 30 ms.

[0096] Partial sensing and / or random selection can be provided. Partial sensing can be used as a power-saving mechanism (e.g., in V2X). The WTRU can be configured (e.g., configured by the upper layer) with a minimum number of candidate subframes in a resource selection window [T1, T2]. Candidate subframes (e.g., specific subframes) can be selected by the WTRU implementation. The WTRU can perform sensing on subframes within the sensing window, which are an integer number of reserved time periods from the candidate subframes. This sensing mechanism reduces the amount of resources the WTRU can use to perform sensing (e.g., sensing within the sensing window). In the example, the 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., regardless of any sensing results during the sensing procedure).

[0097] Discontinuous Receive (DRX) can be used in NR to save power. DRX can be used on the Uu interface, for example, in CONNECTED mode. For example, a WTRU in RRC_CONNECTED mode can utilize DRX to save power. DRX configuration can be scheduled based on the wake-up time at the WTRU. For example, if the WTRU receives a Physical Downlink Control Channel (PDCCH) transmission schedule during its wake-up time, the WTRU can remain awake for a specific duration until no further schedule is received. The WTRU can 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 indicates the duration at the start of a DRX cycle. The `drx-SlotOffset` parameter indicates the delay before `drx-onDurationTimer` is initiated. The `drx-InactivityTimer` parameter indicates the duration after the PDCCH timing where the PDCCH indicates an uplink (UL) or downlink (DL) transmission of a MAC entity. For example, in addition to broadcast procedures, the `drx-RetransmissionTimerDL` parameter can be provided for each DL HARQ procedure. The `drx-RetransmissionTimerDL` parameter indicates the maximum duration until a DL retransmission is received. The `drx-RetransmissionTimerUL` parameter can be provided for each UL HARQ procedure. The `drx-RetransmissionTimerUL` parameter indicates the maximum duration until an authorization for a UL retransmission is received. The `drx-LongCycleStartOffset` parameter indicates the `drx-StartOffset` for a long DRX cycle and defines the subframe that initiates a long and short DRX cycle. The `drx-ShortCycle` parameter indicates a short DRX cycle. The `drx-ShortCycleTimer` parameter indicates the duration for which the WTRU can follow a short DRX cycle. For example, in addition to broadcast procedures, the `drx-HARQ-RTT-TimerDL` parameter can be provided for each DL HARQ procedure.The drx-HARQ-RTT-TimerDL parameter indicates the minimum duration prior to the MAC entity's expected DL assignment for HARQ retransmission. The drx-HARQ-RTT-TimerUL parameter is available for each UL HARQ procedure. The drx-HARQ-RTT-TimerUL parameter indicates the minimum duration prior to the MAC entity's expected UL HARQ retransmission authorization.

[0098] A WTRU configured with DRX can determine its active time. Active time can be the time during which the WTRU actively monitors PDCCH transmissions. When DRX is configured for cyclical operation, active time can 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 can include the time during which a scheduling request is sent via PUCCH and waits. Active time can include the time during which a PDCCH transmission indicating a C-RNTI addressed to a MAC entity has not been received after successfully receiving a random access response with a preamble not selected by the MAC entity.

[0099] The receiving WTRU (Rx WTRU) can receive DRX configuration information. The received DRX configuration information can be used to configure the RxWTRU. For example, if a transmission is not within the active duration of the Rx WTRU, the Rx WTRU may miss transmissions (e.g., transport blocks (TB)) from the transmitting WTRU (TxWTRU). For resource pools of services with DRX configuration, time slots during the DRX ON duration may be more congested than time slots during the OFF duration. For example, if there is a large amount of data for the DRX Rx WTRU, collisions may occur during the DRX ON duration time slots.

[0100] Periodic sensing can be used to detect semi-persistent resource reservations. For example, the WTRU can perform sensing for periods up to 1000 ms before performing resource selection from a set of candidate time slots. For periodic traffic, the WTRU can be aware of the traffic pattern and can perform sensing for up to 1000 ms before the actual data arrives. Support for aperiodic traffic can be provided. In the case of aperiodic traffic patterns, the WTRU may not be able to predict the arrival of traffic. In this case, sensing for up to 1000 ms before the traffic arrives may be impractical (e.g., possible). Support for sensing, resource allocation, and / or congestion control can be provided. For example, such support for sensing, resource allocation, and / or congestion control can be provided for WTRUs configured with DRX. Support for sensing, resource allocation, and / or congestion control can be provided to reduce collisions and / or improve the reliability of transmissions by WTRUs configured with DRX.

[0101] The WTRU's activity window, WTRU activity duration, and WTRU DRX ON duration are used interchangeably in this document. The WTRU's inactivity duration and DRX OFF duration are also used interchangeably. The candidate slot set and candidate slot window are used interchangeably in this document.

[0102] Resource allocation can be provided for transports from Tx WTRU to WTRU (e.g., DRX Rx WTRU). The WTRU can determine whether to trigger resource selection and / or determine the set of time slots used to trigger resource selection (e.g., for a TB targeting a DRX WTRU).

[0103] The WTRU may determine whether to trigger resource selection and / or the set of time slots used to trigger resource (re)selection (e.g., for a TB targeting a DRX Rx WTRU) and / or whether the SL DRX is (pre)configured to the Tx WTRU based on one or more of the following: the QoS of the TB, the active time of the Tx WTRU, the active time of the Rx WTRU, the channel busy rate (CBR) of the resource pool, or the broadcast type of the TB.

[0104] For example, the WTRU can determine whether to trigger resource selection, the set of time slots used to trigger resource (re)selection (e.g., for a TB targeting a DRX Rx WTRU), and / or whether the SL DRX is (pre)configured for the Tx WTRU based on the QoS of the TB. In the example, data may arrive in a DRX cycle (e.g., the current DRX cycle). For example, if the time slot between the data arrival time and the last activity time of the RxWTRU is less than a threshold, the WTRU can determine whether to trigger resource selection based on the QoS of the TB (e.g., the TB's PDB). For example, if the TB's PDB is less than the threshold, the WTRU may trigger resource selection. Otherwise, for example, if the TB's PDB is greater than the threshold, the WTRU may prevent (e.g., not trigger) resource selection in the DRX cycle (e.g., the current DRX cycle). The WTRU may wait until the next DRX cycle, for example, to trigger resource reselection. The threshold may be (pre)configurable or may be configured based on the Rx WTRU's DRX cycle.

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

[0106] For example, a WTRU can determine whether to trigger resource selection, the set of time slots used to trigger resource (re)selection (e.g., for a TB targeting a DRX Rx WTRU), and whether an SL DRX is (pre)configured for a Tx WTRU based on the activity time of the Rx WTRU. In the example, the WTRU can trigger resource selection during the activity time of the Rx WTRU. For example, if the time gap between the resource selection time slot n and the last time slot of the activity time in a DRX cycle of the WTRU (e.g., the last time slot of the DRX ON duration in the current cycle for the current activity time) is greater than a threshold, the WTRU can trigger resource allocation for the TB. The threshold can be (pre)configured and can be based on the TB's QoS, the resource pool's CBR, and / or the TB's broadcast type. For example, if the time gap between the resource selection trigger time slot n and the first active time slot of the DRX Rx WTRU in the current cycle is less than the threshold, the WTRU can trigger resource allocation. Otherwise, the WTRU can disable (e.g., not trigger) resource allocation. The threshold can be fixed (e.g., 31 time slots) and / or (pre)configured (e.g., it can be based on QoS of TB and / or minimum CPS sensing window).

[0107] The WTRU can determine a CPS window, for example, for a TB targeting an Rx WTRU in a DRX. In the example, when the SLDRX is (pre)configured to a Tx WTRU, the WTRU can determine a CPS window [n+TA,n+TB] (e.g., which may include TA=TB), for example, for resource allocation targeting an Rx WTRU in a DRX or for resource allocation for a TB. The CPS window can be determined, for example, based on one or more of the following: whether the CPS window is fixed or (pre)configured; the activity time of the Tx WTRU; the activity time of the Rx WTRU; the QoS of the TB; the broadcast type of the TB; or CPS parameters for resource allocation targeting non-DRX WTRUs and / or CPS parameters for resource allocation when the WTRU is not (pre)configured with a DRX.

[0108] The CPS window can be determined, for example, based on whether the CPS window is fixed or (pre)configured. For example, the CPS window used for resource allocation to a TB targeting Rx WTRU in a DRX can be fixed (e.g., 31 time slots). The CPS window used for resource allocation to a TB targeting Rx WTRU in a DRX can be (pre)configured, for example, it can be based on the TB's QoS and / or the CBR of the resource pool.

[0109] For example, the CPS window can be determined based on the activity 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 activity time of the Tx WTRU in the DRX cycle (e.g., the current DRX cycle). The WTRU can select a CPS window to satisfy a time gap between the last activity time of the Rx WTRU and the last slot in the CPS window that is greater than a threshold. For example, the threshold can be (pre)configured and can be based on the QoS of the TB, the CBR of the resource pool, and / or the broadcast type of the TB. For example, the WTRU can determine a CPS window to satisfy a time gap between the last slot of the CPS window and the last activity time of the Tx WTRU.

[0110] For example, the CPS window can be determined based on the activity time of the Rx WTRU. For instance, the WTRU can determine the CPS window based on the time gap between the resource selection trigger slot n and the last activity time of the Rx WTRU in the DRX cycle (e.g., the current DRX cycle). The WTRU can select a CPS window to satisfy a time gap between the last activity time of the Rx WTRU and the last slot in the CPS window that is greater than a threshold. For example, the threshold can be (pre)configured and may be based on the QoS of the TB, the CBR of the resource pool, and / or the broadcast type of the TB. The WTRU can determine the CPS window to satisfy the time gap between the last slot of the CPS window and the last activity time of the Rx WTRU.

[0111] The CPS window can be based, for example, on CPS parameters used for resource allocation targeting non-DRX WTRUs and / or CPS parameters used for resource allocation if the WTRU is not (pre-)configured with DRX. 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 the example, the WTRU can be (pre-)configured with an offset between a minimum or maximum CPS window, a CPS window for resource allocation targeting DRX Rx WTRUs, and / or a CPS window for normal resource allocation (e.g., resource allocation targeting non-DRX WTRUs and / or resource allocation in the absence of (pre-)configuration of DRX). This offset can be fixed or (pre-)configurable, and can be based on the QoS of the TB.

[0112] For example, WTRU behavior can be provided if the minimum CPS window for resource allocation to a TB targeted by a DRX WTRU is not met. In the example, the WTRU may not (e.g., be able to) meet the minimum or maximum CPS sensing window. The WTRU may perform one or more of the following: wait until the next DRX cycle for performing sensing and / or resource allocation, for example, if the TB's PDB is greater than a threshold (e.g., DRX cycle); discard the TB and / or perform a transfer in another resource pool (e.g., an anomalous resource pool); reduce the number of (re)transfers of the TB; change from semi-persistent reservation to non-periodic transfer, for example, if the CPS sensing window (e.g., the required CPS sensing window) is (pre)configured for semi-persistent reservation; or perform random resource selection for the TB, for example, if the resource pool allows random resource allocation.

[0113] A WTRU (e.g., a Tx WTRU) can determine a resource selection window for transmission to a DRX Rx WTRU. In the example, the WTRU can determine one or more of the following parameters to perform resource selection for a TB targeting the DRX Rx WTRU: a resource selection window (e.g., [n+T1, n+T2]); a set of candidate time slots within the resource selection window; or a window of candidate time slots (e.g., [n+Y1, n+Y2]). Parameters can be selected such that the Tx WTRU can select one or more transmission resources during the Rx WTRU's active time. Parameters can be selected based on the Rx WTRU's DRX ON duration, the Tx WTRU's DRX ON duration, the Tx WTRU's active time, and / or the Rx WTRU's active time.

[0114] A WTRU (e.g., a Tx WTRU) can select a resource selection window and a set of candidate time slots within that window. The WTRU may make a selection based on the overlap between the window determining the candidate time slots and the active window of the Rx WTRU (e.g., the number of overlapping time slots) being greater than a threshold. The WTRU may also make a selection based on the first time slot (e.g., n+Y1) of the window determining the candidate time slots appearing within the active window of the Rx WTRU. The WTRU may select a set of candidate time slots satisfying that the overlap between the window of the candidate time slots and the active window of the Rx WTRU is greater than a threshold. The threshold for the number of overlapping time slots may be determined based on one or more of the following: (pre)configured by resource pool, DRX configuration, CBR of the resource pool, QoS (e.g., priority) of the TB, or HARQ type of the TB (e.g., whether the TB is HARQ enabled or HARQ disabled).

[0115] Figure 3A resource selection window is shown for the TB associated with the DRX Rx WTRU. (Example) Figure 3 As shown, the WTRU can trigger resource selection at slot n in the resource selection window [n+T1,n+T2], which can be the active window of the Rx WTRU. The WTRU can select a candidate window (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.

[0116] The WTRU can determine a set of time slots to initialize a set of candidate resources (e.g., set A). In the example, the WTRU can determine the set of time slots to initialize (e.g., set A) based on the broadcast type of the TB. The WTRU can initialize set A for broadcasting, for example, in the set of overlapping time slots between the candidate time slot set in the candidate window [n+Y1, n+Y2] and the active time of the Rx WTRU. The WTRU can initialize set A in the candidate window [n+Y1, n+Y2] for unicast and / or multicast TBs. The WTRU can perform resource exclusion, for example, to complete set A for each initialization set A (e.g., each initialization set A).

[0117] A WTRU may initialize a set of candidate resources (e.g., set A) for resource allocation based, for example, on multiple (e.g., two) activity times (e.g., the current activity time and future activity time of the Rx WTRU in a DRX). The WTRU may determine the activity time available for initializing set A, for example, based on the broadcast type of the TB. The WTRU may initialize set A during a first activity time (e.g., the current activity time) for a broadcast TB. The WTRU may initialize set A during a second activity time (e.g., a future activity time) for a unicast or multicast TB.

[0118] The WTRU may determine a resource selection window [n+T1, n+T2] based, for example, on multiple active times (e.g., two active times). For example, the resource selection window may include a first resource selection window (e.g., a window where Y candidate time slots overlap with the active window of the Rx WTRU, which may be referred to as an overlapping time slot window) and a second resource selection window (e.g., a window where Y candidate time 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., a first active time, which may be the current active time and may be associated with the overlapping time slot window; and a second active time, which may be a future active time and may be associated with a window where Y candidate time slots do not overlap with the active window of the Rx WTRU). The WTRU may determine the active time available for initializing set A based, for example, on the broadcast type of the TB. The WTRU may select T2 within a first active time (e.g., the current active time) used for broadcasting the TB. WTRU can select T2 within a second activity time (e.g., future activity time) for unicast or multicast TB.

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

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

[0121] The WTRU can, for example, determine whether to trigger a resource allocation procedure (e.g., a subsequent resource allocation procedure) for a TB based on the broadcast type of the TB. For example, the WTRU can prevent (e.g., not trigger) the triggering of a resource allocation procedure (e.g., a subsequent resource allocation procedure) for broadcast. The WTRU can trigger a resource allocation procedure (e.g., a subsequent resource allocation procedure) for unicast or multicast.

[0122] The WTRU may, for example, determine whether to trigger a resource allocation process (e.g., a subsequent resource allocation process) for the TB based on the QoS of the TB. For example, if the priority and / or reliability of the TB is greater than a threshold, the WTRU may trigger a resource allocation process (e.g., a subsequent resource allocation process). Otherwise, the WTRU may prevent (e.g., not trigger) the resource allocation process (e.g., a subsequent resource allocation process) for the TB.

[0123] The WTRU can, for example, determine whether to trigger a resource allocation process for the TB (e.g., a subsequent resource allocation process) based on HARQ feedback from the Rx WTRU of the TB. For example, if the WTRU receives a negative acknowledgment (NACK) for unicast or multicast, the WTRU can trigger a resource allocation process for the TB (e.g., a subsequent resource allocation process).

[0124] For example, if the number of overlapping time 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: change the resource selection scheme (e.g., the WTRU may switch to a random resource allocation scheme); discard the TB; or perform resource selection in another resource pool for the transmission of the TB.

[0125] The WTRU can determine a set of selectable resources for transmitting one or more TBs. For example, if the Side Link Reference Signal Received Power (SL-RSRP) measured in the reservation message is greater than a threshold, the WTRU can exclude resources reserved by other WTRUs within the candidate slot window.

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

[0127] In the example, WTRU can increase the selection window, for example, by increasing the RSRP threshold (e.g., Figure 3 Overlapping time slot windows in Figure 4 The Rx WTRU active window in the middle, Figure 4 The WTRU determines the set of selectable resources in a candidate time slot window by considering the number of available resources in the inactive window of the Rx WTRU (e.g., the Rx WTRU in the Rx WTRU). For example, if the number and / or percentage of selectable resources in the candidate time slot window is less than a threshold, the WTRU may increase the RSRP threshold to determine the set of selectable resources in the candidate time slot window. For example, if the number and / or percentage of selectable resources in the candidate time slot window is greater than a threshold, the WTRU may determine whether to increase the RSRP threshold. The WTRU may also determine whether to increase the RSRP threshold based on the number and / or percentage of selectable resources in the active window of the Rx WTRU. For example, if the number and / or percentage of selectable resources in the active window of the Rx WTRU is greater than a threshold, the WTRU may not change (e.g., not increase) the RSRP threshold. For example, if the number and / or percentage of selectable resources in the active window of the Rx UE is less than a threshold, the WTRU may change (e.g., increase) the RSRP threshold.

[0128] In the example, WTRU can increase the selection window, for example, by increasing the RSRP threshold (e.g., Figure 3 Overlapping time slot windows in Figure 4 The Rx WTRU active window in the middle, Figure 4 The number of available resources in the Rx WTRU inactive window (e.g., in the candidate slot) is used to determine the set of selectable resources in the window. In the example, WTRU can increase the selection window (e.g., by increasing the RSRP threshold, for example) Figure 3 Overlapping time slot windows in Figure 4 The Rx WTRU active window in the middle, Figure 4The number of available resources in the Rx WTRU inactive window (e.g., the number of Rx WTRU inactive window) is used to determine the set of selectable resources in the active window of the Rx WTRU.

[0129] Figure 4 The diagram illustrates increasing the number of available resources in a resource selection window (e.g., a window within a resource selection window) by, for example, changing a parameter (e.g., an exemplary RSRP threshold increase / increment for resource selection, and RSRP increase can be used as an exemplary parameter herein for illustration). Figure 4 As shown in Figure A, the first number of candidate resources can be initialized (e.g., determined) within the Rx WTRU activity window. Figure 4 As shown in Figure A, a first number of candidate resources can be initialized (e.g., determined) during the Rx WTRU inactive window. The first number of candidate resources associated with the Rx WTRU active window can be increased. The first number of candidate resources associated with the Rx WTRU inactive window can also be increased. For example, a WTRU (e.g., a TxWTRU) can increase the number of available / candidate resources associated with the Rx WTRU active window (e.g., by increasing an RSRP (e.g., SL-RSRP) threshold), for example, if the number of candidate / selectable resources in the Rx WTRU active window is less than the threshold (e.g., where...). Figure 4 As shown, for the active window, the resource threshold can be 3). WTRU can first use, for example, the initial RSRP (e.g., in...). Figure 4 In part (A), the set of selectable resources (e.g., candidate resources, where available resources, selectable resources, and candidate resources are used interchangeably) is determined. If the number of selectable resources in the active window of the Rx WTRU is 2 (e.g., less than a resource threshold), the WTRU may increase the number of resources (e.g., by increasing the RSRP threshold) and (re)determine the set of selectable resources (e.g., Figure 4 The results in part (B). In this case, as Figure 4 The first number of candidate resources in the Rx WTRU activity window shown in A can be increased to, for example, Figure 4 B shows the second number of candidate resources in the Rx WTRU activity window. If as Figure 4 If the first number of candidate resources in the Rx WTRU inactive window shown in A is lower than the resource threshold, then... Figure 4 The first number of candidate resources in the Rx WTRU inactive window shown in A can be increased, for example, by increasing the RSRP threshold to a second number of candidate resources in the Rx WTRU inactive window (e.g., the result is as follows). Figure 4(As shown in B). The number of additional selectable resources (e.g., a second number of candidate resources) in the active and inactive windows of the RxWTRU is 4, where the increase can come from using changed parameters, such as an increased RSRP. In the example, the number of additional selectable resources is greater than the resource threshold of 3. The WTRU can select one or more resources from the second number of candidate resources (e.g., based on the second number of candidate resources) for, for example, one or more TB of transmission (e.g., transmission or retransmission). Information (e.g., control information) can be emitted to indicate the selected resources. The examples in this document can be applied to... Figure 3 ,in Figure 3 The overlapping time slot window in the table can correspond to the Rx WTRU active window, and the Y candidate time slots do not overlap with the Rx WTRU active window. Figure 3 The overlapping time slot windows shown can correspond to the inactive windows of Rx WTRU.

[0130] In the example, the Rx WTRU active window and the Rx WTRU inactive window can be associated with corresponding 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 this case, if the first number of candidate resources in the Rx active window is lower than the first resource threshold, the first number of candidate resources in the Rx active window can be increased to a second number of candidate resources in the Rx WTRU active window, where the second number of candidate resources in the Rx WTRU active window is greater than the first resource threshold. If the first number of candidate resources in the Rx inactive window is lower than the second resource threshold, the first number of candidate resources in the Rx WTRU inactive window can be increased to a second number of candidate resources in the Rx WTRU inactive window, where the second number of candidate resources in the Rx WTRU inactive window is greater than the second resource threshold.

[0131] WTRU can determine a set A of available resources (e.g., a second number of candidate resources above a resource threshold) for each window (e.g., an Rx WTRU active window and an Rx WTRU inactive window). In the example, WTRU can determine the set of available resources (e.g., a second number of candidate resources) for example by performing slot exclusion due to non-monitoring slots and / or increasing the RSRP threshold to obtain more available resources (e.g., increasing the RSRP threshold to a level that results in a second number of candidate resources associated with the Rx WTRU active window and / or Rx WTRU inactive window being above the resource threshold). WTRU can perform resource exclusion based, for example, on one or more of the following: the number and / or percentage of available resources during the active time of the Rx WTRU (e.g., a second number of candidate resources) (e.g., as...). Figure 4(As shown) is greater than X1; Rx WTRU is the number and / or percentage of available resources in the second resource selection window of the inactivity window associated with the inactivity time (e.g., the second number of candidate resources) (as shown) Figure 4 (as shown) is greater than X2; or the number and / or percentage of available resources in the candidate slot set within the candidate slot window [n+Y1,n+Y2] (e.g., as shown) Figure 4 (As shown) is greater than X.

[0132] The values ​​of X1, X2, and X and / or the conditions to be met can be determined, for example, based on one or more of the following: whether the value is (pre-)determined; the broadcast type of the TB; the size of the window (e.g., per window) and / or the number of candidate time slots in the window (e.g., per window); or the QoS of the TB.

[0133] The values ​​of X1, X2, and X, and / or which condition must be met, can be determined, for example, based on whether the values ​​are (pre-)determined. For example, it can be pre-determined that X1 = 20% of the candidate time slots in its window, X2 = 20% of the candidate time slots in its window, and X = 20% of the candidate time slots in its window. Alternatively, it can be pre-determined that X1 = 20% and X2 = X = 0%. For example, it can be determined that X1 = 20% and X2 = X = 0%.

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

[0135] In the example, the WTRU can determine which set of slots and / or windows is used to initialize set A (e.g., broadcast type based on TB). The WTRU can also determine which set of slots (e.g., ...) overlaps between the active window of the Rx WTRU and the set of candidate slots in the window [n+Y1, n+Y2] of the candidate slots (e.g., ...). Figure 4As shown, set A is initialized in the active window, for example, for broadcast TB. WTRU can perform resource exclusion, for example, by excluding unmonitored resources and / or by increasing the RSRP threshold (e.g., such that the percentage and / or number of available resources in set A is greater than X1 (e.g., 20%)). WTRU can initialize set A in the candidate slot set within the window of candidate slots, for example, for unicast or multicast TB. WTRU can perform resource exclusion by excluding unmonitored slots and / or by increasing the RSRP threshold (e.g., such that the percentage and / or number of available resources (referred to as the second number of candidate resources) in the window of active time of Rx WTRU is greater than X1 (e.g., 20%), and the percentage and / or number of available resources in the candidate slot set within the window of candidate slots [n+Y1, n+Y2] is greater than X (e.g., 20%)).

[0136] In the example, the interference level of the selectable resources may change as the RSRP threshold changes (e.g., increases). For example, if the increased RSRP threshold is greater than the threshold, the WTRU may perform one or more of the following: change the resource selection scheme (e.g., the WTRU may switch to random resource selection during the Rx WTRU's active window); reduce the number of transport resources; drop TBs; or perform resource selection in another resource pool for transporting TBs.

[0137] A WTRU (e.g., a Tx WTRU) determines the number of transmission resources used to transmit a TB. For example, a WTRU determines the number (e.g., the minimum number of transmission resources) of transmission resources used to transmit a TB (e.g., one TB) within a resource selection window and within an Rx WTRU's active window. This is relative to... Figure 3 As described, an indication of the number of transmission resources can be sent to the Rx WTRU via control information (e.g., as a parameter). The WTRU can be (pre-)configured with a range of transmission resources for a TB (e.g., greater than a first threshold and less than a second threshold) within a window of candidate time slots and a window of active time slots of the RxWTRU. For example, the maximum number of transmissions can be associated with the TB (e.g., indicated via control information as a parameter). The WTRU can determine one or more of the following: a range of transmission resources or the actual number of transmission resources. For example, if the WTRU is configured with a range of transmission resources, the WTRU can select a maximum value, a minimum value, or a value randomly selected from the range (e.g., a single value).

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

[0139] The WTRU can reserve transmissions during the DRX OFF duration using Side Link Control Information (SCI) associated with transmissions during the DRX ON duration. The WTRU can select one or more transmission resources for a TB during the DRX OFF duration. For example, if one or more transmissions during the DRX ON duration indicate and / or reserve resources during the DRX OFF duration, the WTRU can determine whether to send a transmission via resources associated with the DRX OFF duration. For example, if no transmission indication and / or resource reservation during the DRX OFF duration occurs during the DRX ON duration, the WTRU can stop transmission of the TB in the DRX cycle (e.g., the current DRC cycle). Using the SCI associated with transmissions during the DRX ON duration to reserve transmissions during the DRX OFF duration allows the Rx WTRU to receive TBs during the DRX OFF duration.

[0140] The WTRU can transmit a transport for a TB with HARQ enabled. If the transmitting WTRU does not receive HARQ feedback from a transport during the DRX ON duration (e.g., a discontinuous transmission (DTX) is detected), the WTRU can perform one or more of the following: discard the selected and / or reserved resources during the DRX OFF duration; send a retransmission of the (pre)configured number of times during the DRX OFF duration of the Rx WTRU; or send a retransmission of the TB during the next DRX ON duration. For example, if a DTX is detected after a (pre)configured number of retransmissions during the DRX OFF duration, the WTRU can stop the transport in the DRX cycle (e.g., the current DRX cycle) and / or discard the TB. In the example, the (pre)configured number of retransmissions during the DRX OFF duration can be (pre)configured based on the TB's QoS and / or the resource pool's CBR. For example, if a transport in the next DRX ON duration satisfies the TB's PDB, the WTRU can perform a retransmission of the TB during the next DRX duration. If a transport in the next DRX ON duration does not satisfy the TB's PDB, the WTRU can discard the TB.

[0141] The WTRU can determine the number of transport resources to be selected for the resource (re)selection process. For example, the WTRU can determine the number of transport 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 time slots in 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.

[0142] The WTRU can determine the number of transport resources to be selected for a resource (re)selection process based on a resource selection window and / or the set of selectable time slots within that window. The WTRU can be (pre)configured with a maximum number of transport resources to be selected based on the number of selectable time slots, the number of selectable resources, and / or the size of the resource selection window. The WTRU can select the number of transport resources to be selected for a resource (re)selection process (e.g., a resource (re)selection process). The selected transport resources may be less than the (pre)configured maximum number of transport resources.

[0143] The WTRU can determine the number of transport resources to be selected for the resource (re)selection process based on the HARQ type of the TB. Based on the TB's HARQ type, the WTRU can (pre-)configure multiple (e.g., a maximum of two) sets of transport resources for the resource (re)selection process. One of the maximum number of transport resources can be used for a TB with HARQ enabled. The second of the maximum number of transport resources can be used for a TB with HARQ disabled. Based on the TB's HARQ type, the WTRU can determine the maximum number of transport resources that can be used.

[0144] The WTRU can determine the number of transport resources to be selected for the resource (re)selection process based on the remaining SL DRX ON time and / or the remaining active time of the Rx WTRU. The WTRU can be (pre)configured with a maximum number of transport resources to be selected based on the remaining SL DRX ON time and / or the remaining active time of the Rx WTRU. The WTRU can determine the number of transport resources to be selected based on the remaining SL DRX ON time and / or the active time of the Rx WTRU.

[0145] The WTRU can determine whether to perform short-term partial sensing for resource selection of a TB (e.g., a TB) targeting a DRX WTRU. The WTRU can determine whether to perform short-term partial sensing for a TB targeting a DRX WTRU. The WTRU can make this determination based on the time gap between the resource selection trigger and the last active slot of the Rx WTRU (e.g., within a DRX period (e.g., the current DRX period)). For example, if the time gap between the resource selection trigger and the last active slot of the Rx WTRU in a DRX period (e.g., the current DRX period) is less than a threshold, the WTRU can determine that short-term partial sensing may not be performed. In the example, for example, if the time gap is greater than the threshold, the WTRU can determine that short-term partial sensing can be performed. The time gap threshold can be (pre)configured. For example, the time gap threshold can be (pre)configured per resource pool.

[0146] The WTRU can determine a short-term sensing window for a TB targeting a DRX WTRU. In the example, the WTRU can determine a short-term partial sensing window for the TB targeting a 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 can select a fixed short-term sensing window (e.g., 31 slots). For example, if the time gap is less than the threshold, the WTRU can select a short-term partial sensing window to balance between the resource selection window and the sensing window. For example, if the time gap between the trigger slot and the last active slot is small, the WTRU can select a small short-term sensing window. For example, if the time gap between the trigger slot and the last active slot is large, the WTRU can select a large short-term sensing window.

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

[0148] Figure 5 An exemplary periodic sensing scenario is illustrated. For example... Figure 5 As shown, the resource can support two resource reservation intervals (e.g., 100ms and 150ms). To select transmission resources within a window of Y candidate time slots, the WTRU can monitor windows 504 and 502. Windows 502 and 504 are located 150ms and 100ms away from the windows of the Y candidate time slots, respectively. Periodic sensing and monitoring enable the WTRU to detect the reservation of resources in the candidate resource set by transmissions in windows 504 and 502.

[0149] The WTRU can determine the subset and number of reserved intervals to monitor and / or extractable sensing results. This determination can be based on one or more of the following: traffic type (e.g., periodic or non-periodic traffic); QoS of the TB; CBR of the resource pool; one or more reserved intervals for periodic traffic; determination of whether periodic partial sensing is used for resource allocation, preemption, or resource reassessment; or whether the SL DRX is (pre)configured for the WTRU. Regarding the periodic traffic type, the WTRU can perform semi-persistent resource reservation for one or more selected resources, for example, to reserve transmission resources for the TB in subsequent intervals. For example, for periodic traffic, the WTRU can monitor (pre)configured reserved intervals (e.g., all (pre)configured reserved intervals). For non-periodic traffic, the WTRU can skip periodic reservations (e.g., no reserved intervals can be monitored) or the WTRU can monitor a subset of reserved intervals.

[0150] In the case of non-periodic traffic, the WTRU can determine the reserved intervals to monitor based on the QoS of the TB (e.g., PDB). For example, for a TB with a high PDB (e.g., above a threshold), the WTRU can monitor a large number of reserved intervals, including long and / or short intervals. For a TB with a low PDB, the WTRU can monitor (e.g., only) short reserved intervals or not monitor any intervals.

[0151] The determination is based on the resource pool's CBR, and 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 within a reserved interval set (e.g., each set) may be associated with a CBR range (e.g., a CBR range). The WTRU may determine the set to be monitored, for example, based on the resource pool's CBR and / or associated configuration.

[0152] The determination is based on the reserved intervals for periodic traffic, and one or more of the following may apply. For example, for periodic traffic types, the WTRU may include reserved intervals for traffic associated with the WTRU (e.g., Preserve_Tx) in the set of reserved intervals for periodic partial sensing.

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

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

[0155] Figure 6 Various examples of sensing associated with different types of TB are shown. For example... Figure 6 As shown, the WTRU can determine the set of reserved intervals to monitor based on traffic type and / or TB priority. For example, if the traffic is periodic, the WTRU can monitor (pre-)configured reserved intervals (e.g., all (pre-)configured reserved intervals). In the example, if the traffic is non-periodic, the WTRU can monitor a subset of the (pre-)configured reserved intervals. In the example of non-periodic traffic with low QoS TB (e.g., low priority), the WTRU can monitor more reserved intervals. In the example of non-periodic traffic with high QoS TB (e.g., high priority), the WTRU can monitor fewer reserved intervals.

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

[0157] In an exemplary partially sense-based resource allocation, the WTRU may determine whether to select transmission resources outside the candidate time slot window based on one or more of the following: the QoS of the TB, the CBR of the resource pool, the HARQ type of the TB, the number of retransmission resources selected by the WTRU for the TB's transmission, the traffic type of the TB, whether the WTRU semi-persistently reserves resources, or whether the WTRU performs resource selection due to resource reassessment. If the priority of the TB is greater than a threshold, the WTRU may select transmission resources outside the candidate time slot window. Otherwise, the WTRU may select transmission resources within the candidate time slot window. The threshold may be (pre)configured per resource pool. For example, if the priority of the TB is greater than a threshold, the WTRU may select transmission resources within the candidate time slot window. Otherwise, the WTRU may select transmission resources both within and outside the candidate time slot set.

[0158] Regarding the WTRU's determination of whether to select transmission resources outside the window of candidate time slots based on the resource pool's CBR, one or more of the following may apply. In the example, the WTRU may be (pre-)configured for transmitting TBs (e.g., with priority). The WTRU may select transmission resources outside the window of candidate time slots according to the CBR range. For a priority TB, the WTRU may determine whether one or more transmission resources outside the window of candidate time slots can be selected. The WTRU may make this determination based on the measured CBR and the corresponding configuration.

[0159] Regarding the WTRU's determination of whether to select transport resources outside the candidate slot window based on the TB's HARQ type, one or more of the following may apply: The WTRU may determine whether to select transport resources outside the candidate slot set. The WTRU may make this determination based on whether the TB has HARQ enabled or disabled. For example, for a TB with a priority (e.g., a priority level), if the HARQ type associated with the TB is configured to be enabled, the WTRU may select transport resources outside the candidate slot set. In the example, for a TB with a priority (e.g., a priority level), if the HARQ type associated with the TB is configured to be disabled, the WTRU may not select transport resources outside the candidate slot set. The WTRU may be (pre-)configured with priority sets (e.g., two priority sets) that allow selection of resources outside the candidate slot set. A first priority set may be used for TBs with HARQ enabled and a second priority set may be used for TBs with HARQ disabled.

[0160] Regarding whether the WTRU selects transmission resources outside the candidate slot window based on the number of retransmission resources selected by the WTRU for a TB, one or more of the following may apply. For example, if the number of retransmissions for a TB (e.g., one TB) is greater than a threshold, the WTRU may select transmission resources outside the candidate slot set. Otherwise, the WTRU may select transmission resources for a TB (e.g., one TB) within the candidate slot set. The threshold may be (pre)configured per resource pool.

[0161] The WTRU can determine whether to select transport resources outside the candidate time slot window based at least on the traffic type of the TB. The traffic type of the TB can be periodic or aperiodic. In the case of periodic traffic, the WTRU can perform semi-persistent reservation for one or more transport resources of the TB. In the case of aperiodic traffic, the WTRU may not perform semi-persistent reservation of transport resources. In the example, in the case of aperiodic traffic, the WTRU can select transport resources outside the candidate time slot set. In the case of periodic traffic, the WTRU can select transport resources within the candidate time slot set.

[0162] Regarding whether the WTRU semi-persistently reserves resources to determine whether to select transmission resources outside the window of candidate time slots, one or more of the following may apply. For example, if the WTRU semi-persistently reserves the selected resources, the WTRU may select transmission resources within the candidate time slot set. For example, if the WTRU does not semi-persistently reserve resources, the WTRU may select transmission resources within or outside the candidate time slot set.

[0163] The WTRU may determine whether to select transport resources outside the window of the candidate slots, at least based on whether the WTRU performs resource selection due to resource reassessment. The WTRU may select transport resources within and / or outside the candidate slot set for resource reassessment.

[0164] The WTRU can determine whether to drop a HARQ-enabled Transport Target (TB). In an example of a HARQ-enabled TB, if the WTRU receives a NACK feedback or detects a DTX from an Rx WTRU (e.g., one of the Rx WTRUs), the WTRU can drop the TB and / or select resources outside the candidate time slot window (e.g., if the WTRU cannot select transport resources within the candidate time slot). The WTRU can determine whether to drop the TB and / or select resources outside the candidate time slot window based on one or more of the following: the TB's QoS, the resource pool's CBR, or the number of (re)transmissions performed by the WTRU for the TB. In the example, if the TB's priority is less than a threshold, the WTRU can drop the TB. In the example, the WTRU can select resources outside the candidate time slot window and continue transmitting the TB (e.g., if the TB's priority is greater than a threshold). The WTRU can be (pre)configured with a range for CBR (e.g., per range), a priority set for dropping TBs, and / or a priority set for continuing to perform the selection and transmission of TBs outside the candidate time slot set. The WTRU can determine whether to discard a TB or continue sending TB transmissions based on the priority of the resource pool's CBR and / or TB. The WTRU can determine whether to discard a TB transmission. The WTRU can make this determination based on whether the number of (re)transmissions by the WTRU associated with the TB is within a certain range. If the WTRU determines that the number of (re)transmissions by the WTRU associated with the TB is not within a certain range, the WTRU can continue selecting resources outside the window of the candidate time slot.

[0165] The WTRU determines whether semi-persistent resource reservations are permitted for a selected resource. The WTRU may make this determination based on one or more of the following: whether a set of reservation intervals for periodic sensing and / or monitoring is performed; or a window of the selected resource. In the example, if periodic sensing is not performed, the WTRU may not be allowed to perform semi-persistent reservations. If one or more reservation intervals are not monitored, the WTRU may not be allowed to perform semi-persistent reservations. For example, the WTRU may be (pre)configured with a set of reservation intervals to monitor before performing semi-persistent reservations. If one or more intervals in the (pre)configured set are not monitored, the WTRU may not perform semi-persistent reservations.

[0166] Regarding determining whether semi-persistent resource reservation is permitted for a selected resource based on a window of that selected resource, one or more of the following may apply: The WTRU may determine whether semi-persistent reservation is permitted for the selected resource based on a window of the selected resource. For example, if the resource is within the window of the candidate time slot, the WTRU may semi-persistently reserve the resource (e.g., the WTRU may perform periodic sensing before the window of the candidate time slot). For example, if the selected resource is outside the window of the candidate time slot, the WTRU may not be allowed to semi-persistently reserve the resource.

[0167] The WTRU can determine whether to perform a resource reassessment. The WTRU can make this determination based on one or more of the following: the overlap window between the active slot of the Rx WTRU and the candidate slot window, the DRX ON duration, or the remaining DRX ON duration. For example, if the overlap window between the active slot of the Rx WTRU and the candidate slot window in the resource selection window is less than a threshold, the WTRU can skip the resource reassessment. The threshold can be (pre)configured per resource pool. In the example, if the DRX ON duration and / or the remaining DRX ON duration is less than the threshold, the WTRU can skip the resource reassessment. The threshold can be (pre)configured per resource pool and / or per DRX configuration.

[0168] The WTRU can determine whether to exclude a time slot (e.g., a single time slot) from the candidate time slot set. For example, before selecting a transmission resource from the candidate time slot set, the WTRU may be (pre)configured to monitor k (e.g., k > 1) time periods for a reserved interval. For example, if the WTRU does not monitor one or more of the k time periods, the WTRU can determine whether to exclude an associated candidate time slot (e.g., a single associated candidate time slot) from the candidate time slot set. If the WTRU monitors the most recent time period, the WTRU may not exclude the associated candidate time slot. If the WTRU monitors a time period for a (pre)configured reserved interval, the WTRU may not exclude the associated candidate time slot. If the WTRU does not monitor the most recent time period for a reserved interval, the WTRU may exclude the associated candidate time slot. In the example, if the WTRU does not monitor a (pre)configured time period for a reserved interval, the WTRU may exclude the associated candidate time slot.

[0169] The WTRU can determine whether to exclude a time slot (e.g., a time slot) from the candidate time slot set based on the set of reserved intervals that the WTRU can monitor. In the example, the WTRU can determine whether to exclude a time slot (e.g., a time slot) from the candidate time slot set based on the set of reserved intervals that the WTRU can monitor. The WTRU can be (pre)configured with a set of reserved intervals to monitor for periodic partial sensing. The WTRU can skip one or more reserved intervals. The WTRU can determine whether to exclude an associated candidate time slot from resource selection based on the set of reserved intervals that the WTRU may have skipped. If the WTRU skips a reserved interval from the set of (pre)configured reserved intervals (e.g., a reserved interval), the WTRU can exclude the associated candidate time slot. If the number of reserved intervals skipped is greater than a threshold, the WTRU can exclude the associated candidate time slot. The threshold can be (pre)configured in the resource pool and / or determined based on one or more of the following: the QoS of the TB; the traffic type (e.g., periodic or non-periodic traffic); the HARQ type of the TB; or the CBR of the resource pool.

[0170] The WTRU can determine the set of reserved intervals to monitor. The WTRU can make this determination before receiving a resource selection trigger. In the example, the WTRU can be (pre-)configured with the set of reserved intervals to monitor (e.g., a set) before performing resource selection from the candidate slot set. The WTRU can divide the set of reserved intervals into multiple subsets of reserved intervals (e.g., two subsets). The WTRU can perform sensing before packets arrive for one subset of the reserved intervals. For example, the WTRU can perform sensing after packets arrive for another subset of the reserved intervals. This can provide support for periodic-based partial sensing in the case of non-periodic traffic.

[0171] The WTRU can perform periodic sensing before the arrival of packets. The WTRU can perform periodic sensing and / or follow a sensing pattern, for example, before the arrival of packets for resource selection based on periodic partial sensing. The WTRU can perform sensing on Y time slots (e.g., Y consecutive time slots) every 100 ms. By performing such sensing, the WTRU can detect a reserved interval of k*100 ms. The Y consecutive time slots (e.g., each future Y consecutive time slots) can be a set of Y candidate time slots available for resource selection.

[0172] The WTRU can determine whether to trigger resource selection. The WTRU can make this determination before the potential set of candidate time slots. The WTRU can make this determination based on the time gap between the packet arrival time and the potential set of candidate time slots, the reserved interval that the WTRU can monitor (e.g., the required reserved 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 time slots is greater than the continuous sensing window (e.g., the required continuous sensing window) and the reserved interval to be monitored (e.g., the required reserved interval), the WTRU can trigger resource selection before the set of Y candidate time slots. Otherwise, the WTRU can wait for the next set of Y candidate time slots.

[0173] Figure 7 This illustrates an example of WTRU determining whether to trigger resource allocation before a potential set of Y candidate time slots. Figure 7 As shown, the WTRU can perform periodic sensing of Y candidate time slots every 100 ms. A sensing sub-window (e.g., each sensing sub-window) can be a potential set of Y candidate time slots. If a packet arrives at or before time x1, the WTRU can trigger resource selection before the first set of Y candidate time slots. For example, if a packet arrives at time x2, the WTRU can trigger resource selection before the second set of Y candidate time slots.

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

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

[0176] The values ​​of TA, TB, and / or TB-TA can be determined based on whether semi-persistent reservation is enabled or disabled in the resource pool. In the example, TA can be a fixed number of slots, which can be used to account for the processing time of the WTRU, for example, if semi-persistent reservation is disabled in the resource pool. In the example, TA can be set to a value of zero or one slot with a 15 kHz subcarrier spacing. For example, TB-TA can be selected as a fixed number of slots (e.g., 31 slots).

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

[0178] The values ​​of TA, TB, and / or TB-TA can be determined based on whether the WTRU performs long-term partial sensing for TB. If the WTRU performs long-term partial sensing for TB, then short-term partial sensing can be placed just before the set of Y candidate slots. In the example, for instance, if the WTRU does not perform long-term partial sensing for TB, then the short-term partial sensing window can be placed just after the resource selection trigger slot n.

[0179] The values ​​of TA, TB, and / or TB-TA can be determined based on the HARQ type of the TB, such as whether the TB is HARQ enabled or HARQ disabled. WTRUs can be (pre-)configured with TB-TA values ​​(e.g., two values). One of these values ​​can be used for TBs with HARQ enabled, and the other value can be used for TBs with HARQ disabled.

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

[0181] WTRU determines the set of selectable resources. In the example, WTRU determines the minimum size (e.g., Xmin%) of the set of selectable resources for resource selection based on one or more of the following: the HARQ type of the TB or the DRX configuration (e.g., DRX for Tx and / or Rx). WTRU may be (pre-)configured with sets of Xmin% (e.g., two sets). The first set can be used for TBs with HARQ enabled and the second set can be used for TBs with HARQ disabled. WTRU determines which Xmin% set to use based on the HARQ type of the TB.

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

[0183] The WTRU can determine whether to select a set of selectable time slots within a set of Y candidate time slots. In the example, the WTRU can determine whether to select a set of selectable time slots within a set of Y candidate time slots based on whether Ymin candidate time slots (which may be a subset of Y) are within the WTRU's PDB. For example, if Ymin candidate time slots are within the TB's PDB, the WTRU can select a set of selectable time slots within the set of Y candidate time slots. If the set of candidate time slots within the PDB is smaller than a threshold (e.g., smaller than Ymin), the WTRU can select a set of selectable time slots both within and outside the set of Ymin candidate time slots.

[0184] Figure 8 An exemplary selection of available time slots outside the candidate time slot set is shown. Figure 8 As shown, in Option 1, the set of Ymin candidate time slots is within the PDB of the WTRU. In Option 1, the WTRU can determine that the set of selectable time slots is the set of Y candidate time slots. In Option 2, the set of Ymin candidates exceeds the PDB of TB. In Option 2, the WTRU can select the set of candidate time slots both within and outside the set of Y candidate time slots. Figure 8 As shown, WTRU can select a set of Y candidate time slots in the window [n+TC,n+PDB].

[0185] In the example, if the earliest set of Ymin candidate time slots is not within the range that satisfies the QoS of the TB, the WTRU may perform 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 the maximum number of retransmission resources per Ymin. The WTRU may determine how many resources it can select, for example, based on how many Ymin candidate time slots it has within the TB's PDB. The WTRU may lower the priority of the TB. For example, the WTRU may be (pre-configured) with Ymin priority per TB. The WTRU may determine which priority to place in the SCI based on the number of Ymin candidate time slots within the TB's PDB. The WTRU may indicate sensing information via the SCI. For example, the WTRU may indicate via the SCI that it does not have sufficient sensing information. Other WTRUs may trigger preemption and / or resource reassessment to avoid such resources. The WTRU may drop the TB. The WTRU may switch to another resource selection scheme (e.g., a random resource allocation scheme). For example, if the WTRU fails to find Ymin candidate time slots within the PDB of the TB, the WTRU can switch to a random resource selection scheme. The WTRU can perform resource selection for the TB in other resource pools (e.g., an anomalous resource pool).

[0186] The WTRU can determine the time slot used to trigger resource (re)selection. In the example, the WTRU can trigger resource selection at least T time slots before the set of Y candidate time slots. The WTRU can determine whether to trigger resource selection based on the time gap between the expected trigger time slot and the set of Y candidate time slots.

[0187] The WTRU can determine whether to select a set of selectable time slots from a set of Y candidate time slots for aperiodic traffic. In the example, the WTRU can determine whether to select a set of selectable time slots within or outside the set of Y candidate time slots based on one or more conditions. The WTRU can determine whether to select a set of selectable time slots within the set of Y candidate time slots for a resource (re)selection process (e.g., for aperiodic TB) based on one or more of the following: a pre-defined mechanism, pre-configuration, the QoS of the TB, the remaining PDB of the TB, the time interval between the resource (re)selection trigger time slot and the set of Y candidate time slots, the CBR of the resource pool, the HARQ type of the TB, whether SL-DRX is configured for the WTRU, the number of transport resources that the WTRU can select, the number of Y candidate time slots, or the number of available resources within the Y candidate time slots.

[0188] For a WTRU, the determination of whether to select the set of selectable time slots within the set of Y candidate time slots can be predetermined. For example, the WTRU can determine, for non-periodic traffic, not to restrict the set of selectable time slots to the set of Y candidate time slots, regardless of the position of the set of Ymin candidate time slots.

[0189] The WTRU can be (pre)configured based on whether the resource pool allows limiting the set of selectable time slots to a set of Y candidate time slots for aperiodic transmissions. The WTRU can also be (pre)configured to not limit the set of selectable time slots to a set of Y candidate time slots for aperiodic transmissions. The WTRU can select the set of selectable time slots, for example, regardless of the Y candidate time slots. In the example, the WTRU can be (pre)configured to limit the set of selectable time slots to a set of Y candidate time slots for aperiodic transmissions. For example, if the Y candidate time slots are within the resource selection window, the WTRU can limit the set of selectable time slots to the set of Y candidate time slots.

[0190] The WTRU can determine, based on the QoS of a TB, whether to select a set of selectable time slots within or outside of a set of Y candidate time slots. For example, for non-periodic traffic, if the TB's priority is less than a threshold, the WTRU may restrict the set of selectable time slots to the set of Y candidate time slots. Otherwise, the WTRU may not restrict the set of selectable time slots to the set of Y candidate time slots. The pthreshold (e.g., a priority value threshold) can be (pre-)configured per resource pool. Making a determination based on the TB's priority being less than the threshold reduces conflicts between high-priority TBs. For non-periodic traffic, if the TB's priority is greater than the threshold, the WTRU may restrict the set of selectable time slots to the set of Y candidate time slots. Otherwise, the WTRU may not restrict the set of selectable time slots to the set of Y candidate time slots. The threshold (e.g., a priority value threshold) can be (pre-)configured per resource pool. Making a determination based on the TB's priority being greater than the threshold increases the resource selection window for high-priority TBs.

[0191] The WTRU can determine whether to select a set of selectable time slots within or outside the set of Y candidate time slots based on the remaining PDB of the TB. For example, if the remaining PDB of the TB is less than a threshold, the WTRU may restrict the set of selectable time slots to the set of Y candidate time slots. If the remaining PDB of the TB is greater than the threshold, the WTRU may not restrict the set of selectable time slots to the set of Y candidate time slots. The remaining PDB threshold can be (pre-)configured by resource pool.

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

[0193] The WTRU can determine whether to select a set of selectable time slots within or outside the set of Y candidate time slots based on the time gap between the resource (re)selection trigger and the window of Y candidate time slots. The time gap between the resource (re)selection trigger and the window of Y candidate time slots may include the time gap between the resource (re)selection trigger (e.g., time slot n) and the first time slot among the Y candidate time slots and / or the time gap between time slot n and the last time slot among the Y candidate time slots. For example, if the time gap between time slot n and the Y candidate time slots is less than a threshold, the WTRU may restrict the set of selectable time slots to within the Y candidate time slots. If the time gap between time slot n and the Y candidate time slots is greater than the threshold, the WTRU may not restrict the set of selectable time slots to within the Y candidate time slots. The time gap threshold may be (pre)configured based on the remaining PDB of the TB. If the set of Ymin candidate time slots is within the resource selection window, the WTRU may restrict the set of selectable time slots to within the set of Y candidate time slots. Otherwise, if the set of Ymin candidate time slots is not within the resource selection window, WTRU may not restrict the set of selectable time slots to the set of Y candidate time slots. In this case, the set of selectable time slots can be both within and outside the set of Y candidate time slots.

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

[0195] The WTRU can determine, based on the HARQ type of the time slot TB, whether to select a set of selectable time slots within or outside of the set of Y candidate time slots. For a time slot TB with HARQ disabled, the WTRU can restrict the set of selectable time slots to the set of Y candidate time slots. Otherwise, for a time slot TB with HARQ enabled, the WTRU may not restrict the set of selectable time slots to the set of Y candidate time slots.

[0196] The WTRU can determine whether to select a set of selectable time slots within or outside the set of Y candidate time slots based on whether the SL-DRX is configured for the WTRU. If the SL-DRX is (pre-)configured for the WTRU, the WTRU can restrict the set of selectable time slots to the set of Y candidate time slots. Otherwise, if the SL-DRX is not (pre-)configured for the WTRU, the WTRU may not restrict the set of selectable time slots to the set of Y candidate time slots. In the example, if the SL-DRX is (pre-)configured for the WTRU, the WTRU may not restrict the set of selectable time slots to the set of Y candidate time slots. If the SL-DRX is not (pre-)configured for the WTRU, the WTRU may restrict the set of selectable time slots to the set of Y candidate time slots.

[0197] The WTRU can determine whether to select a set of selectable time slots within or outside the set of Y candidate time slots based on whether the target Rx WTRU is (pre-)configured with an SL-DRX. If the SL-DRX is (pre-)configured for the target WTRU, the WTRU can restrict the set of selectable time slots to the set of Y candidate time slots. Otherwise, if the SL-DRX is not (pre-)configured for the target Rx WTRU, the WTRU may not restrict the set of selectable time slots to the set of Y candidate time slots.

[0198] The WTRU can determine whether to select a set of selectable time slots within or outside the set of Y candidate time slots based on the number of transmission resources available to the WTRU. For example, if the number of transmission resources available to the WTRU is less than a threshold, the WTRU may restrict the set of selectable time slots to the set of Y candidate time slots. Otherwise, if the number of transmission resources available to the WTRU is greater than the threshold, the WTRU may not restrict the set of selectable time slots to the set of Y candidate time slots. The transmission resource quantity threshold can be (pre)configured per resource pool. The transmission resource quantity threshold may depend on the number of time slots in Y or the number of available resources in Y.

[0199] The WTRU can determine whether to select a set of selectable time slots within or outside the set of Y candidate time slots based on the number of time slots in Y. For example, if the number of time slots in Y is greater than a threshold, the WTRU may restrict the set of selectable time slots to the set of Y candidate time slots. Otherwise, if the number of time slots in Y is less than the threshold, the WTRU may not restrict the set of selectable time slots to the set of Y candidate time slots. The threshold can be (pre)configured per resource pool.

[0200] WTRU can determine whether to select a set of selectable time slots within or outside of the set of Y candidate time slots based on the amount of available resources within Y. For example, if the amount of available resources within Y is greater than a threshold, WTRU may restrict the set of selectable time slots to the set of Y candidate time slots. If the amount of available resources within Y is less than the threshold, WTRU may not restrict the set of selectable time slots to the set of Y candidate time slots. The threshold can be (pre)configured per resource pool.

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

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

[0203] The WTRU can determine whether to initialize periodic partial sensing based on a non-periodic resource limit (TB). In the example, the WTRU can initialize the PBPS (e.g., a new PBPS) based on resource (re)selection triggering at slot n for the TB. The WTRU can initialize the PBPS (e.g., a new PBPS) by performing one or more of the following: monitoring one or more reserved periods between resources or performing resource exclusion based on sensing results of the monitored slots.

[0204] WTRU may determine whether to initialize PBPS (e.g., for a new PBPS for resource (re)selection triggered at slot n, which can be used for a non-periodic TB) based on one or more of the following: whether WTRU has an existing PBPS and / or a set of Y candidate slots for PBPS; the set of reserved time periods to be monitored (e.g., required reserved time periods) and / or the remaining set of reserved time periods to be monitored (e.g., required reserved time periods); whether the short-term partial sensing window includes (pre)configured reserved time periods; whether the TB's QoS, the TB's HARQ type, SL-DRX are (pre)configured for WTRU, whether the target RxWTRU is (pre)configured with SL DRX, or whether the process is used for initial resource allocation or re-evaluation and / or preemption.

[0205] The WTRU can determine whether to initialize a PBPS (e.g., a new PBPS) for resource (re)selection based on whether the WTRU has an existing PBPS and / or the location of a set of Y candidate time slots for the PBPS. In the example, if the WTRU has an existing PBPS procedure and the set of Y candidate time slots is within the WTRU's resource selection window, the WTRU may not initiate a PBPS procedure (e.g., a new PBPS procedure). If the WTRU does not have an existing PBPS and / or the set of Y candidate time slots is outside the resource selection window, the WTRU may not initiate a PBPS procedure (e.g., a new PBPS procedure).

[0206] The WTRU may determine whether to initialize a PBPS (e.g., a new PBPS) based on the set of reserved time periods to be monitored (e.g., required reserved time periods) and / or the remaining set of reserved time periods to be monitored (e.g., required reserved time periods). For example, if the remaining set of reserved time periods to be monitored is within the WTRU's PDB, the WTRU may initialize a PBPS for resource allocation in the TB (e.g., a new PBPS). Otherwise, the WTRU may not initialize a PBPS (e.g., a new PBPS).

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

[0208] The WTRU can determine whether to initialize a PBPS (e.g., a new PBPS) based on the QoS of the TB (e.g., the TB's priority and / or remaining PDB). For example, if the WTRU's remaining PDB is greater than a threshold, the WTRU may initialize a PBPS procedure (e.g., a new PBPS procedure). Otherwise, the WTRU may not initialize a PBPS procedure (e.g., a new PBPS procedure). The threshold can be (pre)configured per resource pool.

[0209] The WTRU can determine whether to initialize the PBPS (e.g., new PBPS) based on the HARQ type of the TB. For example, the WTRU can initialize the PBPS procedure (e.g., new PBPS procedure) for TBs with HARQ disabled and can not initialize the PBPS (e.g., new PBPS) for TBs with HARQ enabled.

[0210] The WTRU can determine whether to initialize the PBPS (e.g., a new PBPS) based on whether the SL-DRX is (pre-)configured for the WTRU. For example, if the SL-DRX is (pre-)configured for the WTRU, the WTRU may not initialize the PBPS (e.g., a new PBPS). If the SL-DRX is not (pre-)configured for the WTRU, the WTRU may initialize the PBPS procedure (e.g., a new PBPS procedure).

[0211] The WTRU can determine whether to initialize the PBPS (e.g., a new PBPS) based on whether the target Rx WTRU is (pre-)configured with an SL DRX. For example, if the TB targets a WTRU that is (pre-)configured with an SL DRX, the WTRU may not initialize the PBPS (e.g., a new PBPS). Otherwise, the WTRU may initialize the PBPS procedure (e.g., a new PBPS procedure).

[0212] The WTRU may determine whether to initialize a PBPS (e.g., a new PBPS) based on whether the process is used for initial resource allocation or re-evaluation and / or preemption. For example, the WTRU may determine to initiate a PBPS process for initial resource (re)selection (e.g., a new PBPS process). The WTRU may determine not to initiate a PBPS process for resource re-evaluation and / or preemption checks (e.g., a new PBPS process).

[0213] The WTRU can prioritize the selection of resources for transmission from a set of Y candidate time slots. The WTRU can prioritize the selection of transmission resources with sensing results (e.g., CPS and / or PBPS results). In one example, the WTRU can prioritize the selection of transmission resources with both PBPS and CPS sensing results. In another example, the WTRU can prioritize the selection of resources with either CPS or PBPS sensing results. The WTRU can determine multiple transmission resources for a TB (e.g., one TB) and / or a resource allocation process (e.g., one resource allocation process) that have both PBPS and / or CPS sensing results. The WTRU can prioritize the selection of X transmission resources with PBPS and / or CPS sensing results, for example, by selecting (e.g., randomly selecting) X resources within a time slot that have both PBPS and / or CPS sensing results. The maximum, minimum and / or number (e.g., exact number) of the transmission resources to be selected with PBPS sensing results 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 / time slots with PBPS and / or CPS sensing results.

[0214] In the example, the maximum, minimum, and / or number (e.g., an exact number) of transmission resources to be selected, having PBPS sensing results and / or CPS sensing results, can be determined, for example, based on a predetermined value. The WTRU can prioritize the selection of X (e.g., X=1) transmission resources with PBPS sensing results. In the example, the WTRU can prioritize the selection of X (e.g., X=1) transmission resources with CPS sensing results. The WTRU can prioritize the selection of X transmission resources with either CPS or PBPS sensing results. The WTRU can prioritize the selection of X transmission resources with both CPS and PBPS sensing results (e.g., both CPS and PBPS sensing results). For example, after selecting X transmission resources (e.g., with PBPS and / or CPS sensing results), the WTRU can select (e.g., randomly select) the remaining resources for transmission within set A.

[0215] In the example, the maximum, minimum, and / or number (e.g., exact number) of transport resources to be selected with PBPS and / or CPS sensing results can be determined, for example, based on the QoS of the TB. The WTRU can prioritize the selection of X transport resources with PBPS and / or CPS sensing results. The value of X can be (pre)configured, which may depend on the QoS of the TB (e.g., the priority of the TB and / or the PDB of the TB).

[0216] In the example, the maximum, minimum, and / or exact number of transport resources to be selected with PBPS and / or CPS sensing results can be determined, for example, based on the number of available resources and / or time slots with PBPS and / or CPS sensing results. The WTRU can determine the number of transport resources with PBPS and / or CPS sensing results to be selected, for example, based on the number of available resources and / or time slots with PBPS and / or CPS sensing results. For example, if the number of resources and / or time slots with PBPS and / or CPS sensing results is greater than a threshold, the WTRU can prioritize the selection of X transport resources with PBPS and / or CPS sensing results. Otherwise, the WTRU can prohibit prioritization (e.g., not prioritize) the selection of transport resources with PBPS and / or CPS sensing results. The threshold can be (pre)configured, which may depend on the priority of the TB and / or the CBR of the resource pool.

[0217] For example, when the WTRU initiates a resource (re)selection process (e.g., for aperiodic traffic), the WTRU may prioritize the selection of transmission resources within a set of Y candidate time slots (e.g., with PBPS sensing results). The WTRU may select multiple transmission resources from the set of Y candidate time slots. The number of transmission resources that the WTRU can select may be based on one or more of the following: the size of the Y candidate time slots, the QoS of TB, the remaining PDB of TB, or the CBR of the resource pool, etc.

[0218] In the example, for instance, if the number of resources that the WTRU can select is greater than the number of resources that the WTRU selects from the set of Y candidate time slots, then the WTRU can select transmission resources within or outside the set of Y candidate time slots.

[0219] In one example, the WTRU may determine one or more windows to initialize a set of available resources (e.g., a set SA) for resource selection. 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 is higher than a threshold as described herein); the QoS of the TB; or a continuous partial sensing window.

[0220] The window can be determined based on a set of Y candidate time slots in the resource selection window. For example, the WTRU can be (pre)configured to include at least a certain number of time slots (e.g., the number of time slots is higher than a threshold) in the set of Y candidate time slots within the resource selection window (e.g., all Y candidate time slots, X% of the Y candidate time slots, etc.). The WTRU can select a (pre)configured number of time slots to include in the set of Y candidate time slots to initialize the set SA in the resource selection window. In the example, the WTRU can prioritize including time slots in the set of Y candidate time slots within the resource (re)selection window.

[0221] The window can be determined based on the QoS of the TB. For example, the WTRU can be (pre)configured with a minimum window size for initializing the set SA. The WTRU can determine the set SA based on the (pre)configured minimum window size.

[0222] The window can be determined based on a continuous partial sensing window. In the example, the WTRU may include at least a specific number of time slots with CPS results. The set of time slots with CPS results may be 31 time slots following the CPS window (e.g., the next 31 time slots). The WTRU may select at least X% of the 31 time slots. The WTRU may include at least multiple time slots following the CPS window. The WTRU may prioritize including resources with CPS results (e.g., time slots with time slots within the 31 time slots starting from the last time slot of the CPS window).

[0223] Figure 9 An example of a set of selectable time slots for WTRU initialization is shown. Figure 9 As shown, WTRU can be allowed to select a window. The window can include a set of selectable time slots within the resource allocation window to initialize a set of selectable resources (e.g., set SA). WTRU can determine the set of selectable time slots based on one or more of the following: a set of time slots with CPS results or a set of time slots with PBPS results.

[0224] In the example, the WTRU can select a set of selectable time slots within the resource (re)selection window, including time slots with CPS results (e.g., all time slots) and time slots with PBPS results (e.g., all time slots). The WTRU can also select a set of selectable time slots within the resource (re)selection window, including time slots with CPS results (e.g., all time slots). The WTRU can further select a set of selectable time slots (e.g., a set of Y candidate time slots) including time slots with PBPS results (e.g., all time slots).

[0225] The WTRU can prioritize time slots with PBPS and / or CPS sensing results from a set of Y' candidate time slots. For example, if the number of time slots with PBPS and / or CPS sensing results is less than the (pre)configured value Y'min, the WTRU can select time slots from the set of Y' candidate time slots that do not have sensing results within the Resource Selection Window (RSW). The WTRU can prioritize including time slots that are earlier in time into the set of Y' candidate time slots. In the example, the WTRU can prioritize (e.g., first) including time slots with PBPS sensing results into the set of Y' candidate time slots. The WTRU can prioritize (e.g., after prioritizing including time slots with PBPS sensing results into the set of Y' candidate time slots) including time slots with either PBPS or CPS sensing results into the set of Y' candidate time slots. WTRU may (e.g., after prioritizing the inclusion of time slots with PBPS sensing results and subsequently time slots with PBPS or CPS sensing results into the set of Y' candidate time slots) include time slots without PBPS and CPS sensing results into the set of Y' candidate time slots.

[0226] For example, if / when CPS is performed, the WTRU may initialize set A (e.g., based on time slots with CPS results). The WTRU may include (e.g., initially include) X time slots or X% of time slots with CPS results in the set of Y' candidate time slots. The WTRU may include additional time slots (e.g., after including X time slots or X% of time slots with CPS results in the set of Y' candidate time slots) into the set of Y' candidate time slots, for example, until Y' ≥ Y'min. The value of X or X% may be predetermined (e.g., X may include all time slots with CPS results in the RSW) and / or may be (pre)configured.

[0227] The WTRU can be (pre)configured to select Y'≥Y'min candidate time slots in the RSW to initialize the candidate resource set (e.g., set SA). For example, if Y'min candidate time slots are not satisfied, WTRU behavior can be provided. The WTRU can perform one or more of the following: discard the TB and / or perform a transfer in another resource pool (e.g., an anomalous resource pool); reduce the number of (re)transfers of the TB; change from semi-persistent reservation to non-periodic transfer, for example, if the required CPS sensing window is (pre)configured for semi-persistent reservation; or perform random resource selection for the TB, for example, if the resource pool allows random resource allocation.

[0228] The WTRU may determine whether to perform CPS (e.g., 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 less than a threshold, the WTRU may skip CPS. The WTRU may initialize a set of selectable slots within the set of Y candidate slots. If the priority of the TB is greater than a threshold and / or the remaining PDB of the TB is less than a threshold, the WTRU may initiate CPS. Otherwise, the WTRU may not initiate CPS for resource (re)selection for the TB. If the priority of the TB is less than a threshold and / or the remaining PDB of the TB is greater than a threshold, the WTRU may initiate CPS. Otherwise, the WTRU may not initiate CPS for resource (re)selection for the TB. In the example, the WTRU may initiate CPS for a TB with HARQ disabled. WTRU may not initiate CPS against TBs that have HARQ enabled.

[0229] In the example, the WTRU may determine the short-term partial sensing window (e.g., for non-periodic traffic in a resource pool with semi-persistent reservations enabled) based on one or more of the following: whether the WTRU has a set of Ymin candidate slots in the resource selection window, the time gap between the resource (re)selection trigger slot and the Ymin candidate slots, or the QoS of TB and / or the remaining PDB of TB.

[0230] The WTRU can determine the short-term partial sensing window based on whether it has a set of Ymin candidate time slots within the resource selection window. If the WTRU has Ymin candidate time slots within the window (e.g., the resource (re)selection window), the short-term partial sensing window can be placed before (e.g., immediately before) the set of Y candidate time slots, taking into account the WTRU processing time. If the WTRU does not have a set of Ymin candidate time slots within the window (e.g., the resource (re)selection window), the short-term partial sensing window can be placed after (e.g., immediately after) the resource (re)selection trigger time slot n, taking into account the WTRU processing time. In the example, if the WTRU has a set of Ymin candidate time slots within the 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 time slots. For example, the WTRU can use the first time slot of the set of Ymin candidate time slots as a reference time for determining the short-term partial sensing window. For example, the WTRU can determine n+TB as n+ty0-Tproc, where n+TB is the last time slot for short-term partial sensing, n+ty0 is the first time slot in the set of Ymin candidate time slots, and Tproc is a parameter used to account for WTRU processing time. In this case, n+TA can be determined based on the size of the short-term partial sensing window. In the example, if the WTRU does not have a set of Ymin candidate time slots within the resource (re)selection window, the WTRU can determine the location of the short-term partial sensing window based on the resource (re)selection trigger time. For example, the WTRU can determine n+TA based on n+Tproc, where n+TA is the first time slot of the short-term partial sensing window, and Tproc can be used to account for WTRU processing time.

[0231] WTRU can determine the short-term partial sensing window based on the (re)selection of the trigger slot and the time interval between Ymin candidate slots. Figure 10 An example of how WTRU determines the short-term partial transmission window is shown. Figure 10 As shown, the WTRU can determine a short-term partial sensing window based on the time interval between the (re)selected trigger slot and Ymin candidate slots. For example, in the first case (e.g., Figure 10 In case 1), if the time gap between time slot n and the Ymin candidate time slots is greater than a threshold (e.g., greater than X0 = 31 time slots + Tproc), then the short-term partial sensing can be fixed (e.g., 31 time slots) and can be placed before the set of Ymin candidate time slots (e.g., just before them). In the second case (e.g., Figure 10In case 2), if the time gap between time slot n and the set of Ymin candidate time slots is greater than a threshold (e.g., X1 in the figure) and less than another threshold (e.g., X0), then short-term partial sensing can be determined based on the time gap between time slot n and the set of Ymin candidate time slots. In the third case (e.g., Figure 10 In case 3), if the time gap between time slot n and the set of Ymin candidate time slots is less than a threshold (e.g., X1), the WTRU may determine 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 time slots; or, taking into account the WTRU processing time (e.g., n+Tproc), perform short-term partial sensing immediately after time slot n for a (pre)configured number of time slots (e.g., 31 time slots) and initialize a set of selectable resources (e.g., set SA) after the short-term partial sensing window, which may include resources outside of the Ymin candidate time slots and may include resources within the Ymin candidate time slots. The WTRU may include the set of selectable time slots in a window [n+TB+Tproc, n+TC], where TB may be the last time slot of the short-term partial sensing window, and TC may be defined by the T2 and PDB of TB. The WTRU may determine the short-term partial sensing window based on the QoS of TB and / or the remaining PDB of TB.

[0232] The WTRU can determine whether to exclude time slots in the RSW, for example, based on non-monitored time slots within a PBPS window. For associated time slots in the RSW (e.g., each associated time slot), the WTRU can be (pre-)configured with a set of reserved time periods and / or a set of sensing opportunities for each reserved time period. The WTRU may not monitor one or more opportunities within one or more reserved time periods.

[0233] WTRU may determine whether to exclude associated time slots based on one or more of the following: pre-determined, traffic type, whether DRX is configured for WTRU, the timing of reserved periods and / or reserved periods not monitored by WTRU (e.g., a reserved period), whether WTRU monitors a subset of reserved periods, whether the unmonitored time slot is during the DRX OFF or DRX ON duration, TB QoS, resource pool CBR, remaining resources and / or time slots after resource exclusion and / or time slot exclusion, or whether the time slot has a CPS result.

[0234] The determination made by the WTRU regarding whether to exclude associated time slots can be predetermined. For example, if the WTRU does not monitor reserved time periods (e.g., required reserved time periods), the WTRU may not exclude associated time slots from the resource selection window.

[0235] The WTRU can determine whether to exclude associated time slots based on traffic type (e.g., periodic or non-periodic traffic). In the example, if the WTRU does not monitor one or more (pre)configured times in one or more reserved periods (e.g., desired reserved periods), the WTRU may exclude associated time slots from the set of Y candidate time slots for periodic traffic. For non-periodic traffic, the WTRU may not exclude time slots from the set of Y candidate time slots.

[0236] WTRU can determine whether to exclude associated time slots based on whether a DRX is configured for WTRU. For example, if an SL DRX is not configured, WTRU may exclude associated time slots. Otherwise, if an SL DRX is configured, WTRU may not exclude associated time slots.

[0237] The WTRU can determine whether to exclude an associated time slot based on which reserved time period and / or at what point within a reserved time period (e.g., a single reserved time period) the WTRU has not yet detected. In the example, the WTRU may be (pre)configured with two sets of reserved time periods. If the WTRU has not yet detected a reserved time period in one set (e.g., a single reserved time period), the WTRU may exclude an associated time slot in the RSW. If the WTRU has not yet detected a reserved time period in the other set (e.g., a single reserved time period), the WTRU may not exclude an associated time slot in the RSW. In the example, if more than X% of the reserved time periods are not detected, the WTRU may exclude an associated time slot. Otherwise, if less than X% of the reserved time periods are detected, the WTRU may not exclude an associated time slot. If multiple sensing opportunities for each reserved time period are (pre)configured, the WTRU may determine whether to exclude an associated time slot. If the most recent sensing opportunity for one or more reserved time periods has not been detected, the WTRU may exclude an associated time slot. If the (pre)configured sensing opportunities for one or more reserved time periods have not been detected, the WTRU may exclude an associated time slot. If the (pre)configured sensing timing of each of the (pre)configured reserved time periods (e.g., all (pre)configured required reserved time periods) is monitored, the WTRU may not exclude associated time slots.

[0238] The WTRU can determine whether to exclude associated time slots based on whether it monitors a subset of reserved time periods. For example, the WTRU may be (pre-)configured with a subset of reserved time periods. If the WTRU does not monitor a subset of reserved time periods, it may exclude associated time slots. If the WTRU monitors a subset of reserved time periods, it may not exclude associated time slots.

[0239] The WTRU can determine whether to exclude associated time slots based on whether the unmonitored time slot is during the DRX OFF or DRX ON duration. For example, if the unmonitored time slot is during the DRX OFF period, the WTRU may not exclude associated time slots. If the unmonitored time slot is during the WTRU's DRX ON duration, the WTRU may exclude associated time slots.

[0240] The WTRU can determine whether to exclude associated time slots based on the QoS of the TB. In the example, if the TB's priority is greater than a threshold, the WTRU can exclude the associated time slot. If the TB's priority is less than a threshold, the WTRU can not exclude the associated time slot.

[0241] WTRU can determine whether to exclude associated time slots based on the resource pool's CBR. In the example, if the resource pool's CBR is greater than a threshold, WTRU can exclude associated time slots. If the resource pool's CBR is less than a threshold, WTRU can not exclude associated time slots.

[0242] The WTRU can determine whether to exclude associated time slots based on the remaining resources and / or time slots after resource exclusion and / or time slot exclusion. For example, if the amount of remaining time slots and / or resources after exclusion is greater than X%, the WTRU may exclude associated time slots in the RSW. Otherwise, the WTRU may not exclude associated time slots. The value of X may be (pre)configured by resource pool and / or by QoS (e.g., TB priority).

[0243] WTRU can determine whether to exclude associated time slots based on whether the time slot has a CPS result. For example, if the associated time slot has a CPS result (e.g., the time gap between the last time slot of the CPS window and the associated time slot is less than 31 time slots), then WTRU may not exclude the associated time slot. Otherwise, if the associated time slot does not have a CPS result (e.g., the time gap between the last time slot of the CPS window and the associated time slot is greater than 31 time slots), then WTRU may exclude the associated time slot.

[0244] Based on one or more unmonitored time slots in the CPS window, the WTRU can determine whether to exclude associated time slots in the RSW. In the example, if the WTRU does not monitor a time slot (e.g., one time slot) in a short-term partial sensing window (e.g., a continuous partial sensing window), the WTRU can determine which time slot to exclude in the resource selection window. The WTRU can be (pre-)configured with a set of reserved time periods to be excluded due to unmonitored time slots in the CPS. If the WTRU does not monitor a time slot in the CPS (e.g., one time slot), the WTRU can exclude a time slot from a set of reserved time periods at a distance equal to one of the (pre-)configured time periods. In the example, the WTRU may not perform time slot exclusion due to unmonitored time slots in the CPS window.

[0245] The WTRU may determine whether to perform slot exclusion due to unmonitored slots in the CPS window based on one or more of the following: Exclusion of associated slots in the RSW may be predetermined. For example, if the WTRU does not monitor reserved time periods (e.g., required reserved time periods), the WTRU may not exclude associated slots in the resource selection window. The WTRU may determine whether to perform slot exclusion based on the QoS of the TB. In the example, if the TB's priority is less than a threshold, the WTRU may perform slot exclusion due to unmonitored slots in the CPS. Otherwise, if the TB's priority is greater than a threshold, the WTRU may not perform slot exclusion due to unmonitored slots in the CPS. In the example, if the TB's priority is greater than a threshold, the WTRU may perform slot exclusion due to unmonitored slots in the CPS. Otherwise, if the TB's priority is less than a threshold, the WTRU may not perform slot exclusion due to unmonitored slots in the CPS.

[0246] The WTRU can determine whether to perform slot exclusion due to unmonitored slots in the CPS window based on the traffic type (e.g., periodic or non-periodic traffic). In the example, the WTRU may perform slot exclusion due to unmonitored slots in the CPS window for non-periodic traffic. The WTRU may not perform slot exclusion due to unmonitored slots in the CPS window for periodic traffic. The WTRU may perform slot exclusion due to unmonitored slots in the CPS window for periodic traffic. The WTRU may not perform slot exclusion due to unmonitored slots in the CPS window for non-periodic traffic.

[0247] The WTRU can determine whether to perform slot exclusion due to unmonitored slots in the CPS window based on whether the DRX is configured for the WTRU. In the example, if the SL DRX is configured for the WTRU, the WTRU may not perform slot exclusion due to unmonitored slots in the CPS. Otherwise, the WTRU may perform slot exclusion due to unmonitored slots in the CPS.

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

[0249] WTRU can determine whether to exclude a time slot due to it being a non-monitored time slot in the CPS window based on whether the time slot has a PBPS result. For example, WTRU can exclude a time slot with a gap equal to one of the (pre)configured reserved time periods from the non-monitored time slots in the CPS window. If the time slot under consideration belongs to a set of Y candidate time slots, WTRU may not exclude such time slots.

[0250] The WTRU can be provided with DRX sensing and / or resource allocation. The WTRU can determine whether to perform sensing outside the DRX ON duration. The WTRU can be (pre-)configured with multiple sets (e.g., two sets) of desired sensing slots for resource selection based on partial sensing. For each set of desired sensing slots (e.g., each set), the WTRU can be configured to determine whether it is allowed to skip sensing when it is in the DRX OFF duration. For example, if the sensing slot is outside the DRX ON duration, the WTRU may skip the set of desired sensing slots (e.g., one set). The WTRU may not skip the set of desired sensing slots, for example, regardless of whether the desired sensing slot is within or outside the DRX ON duration. The WTRU may determine whether to skip a desired sensing slot during the DRX OFF duration time interval, for example, based on whether it belongs to a desired set (e.g., a set that allows the WTRU to skip sensing during the DRX OFF duration or a set that does not allow the WTRU to skip sensing during the DRX OFF duration).

[0251] In the example, for instance, if periodic partial sensing occurs outside the DRX ON duration, the WTRU may skip periodic partial sensing slots. The WTRU may not skip continuous partial sensing slots, regardless of whether the slot is within or outside the DRX ON duration.

[0252] The WTRU can determine whether to wake up before the DRX ON duration to perform sensing and / or resource allocation. In the example, the WTRU may have data that arrived before its DRX ON duration. The WTRU can perform resource selection based on partial sensing. For example, the WTRU can determine whether to perform one or more of the following: wake up to perform sensing and / or resource allocation, wait for the DRX ON duration to perform sensing and / or resource allocation, or drop the TB. The WTRU can make a decision based on one or more of the following: the QoS of the TB (e.g., the priority of the TB), the CBR of the resource pool, the sensing type, the HARQ type of the TB, whether the WTRU performs semi-persistent resource reservation, or whether the WTRU performs sensing for resource reassessment and / or preemption. The WTRU can wake up to perform sensing and / or resource allocation for high-priority and / or low-latency TBs. In the case of low-priority and / or high-PDB TBs, the WTRU may wait for the DRX ON duration to expire before performing sensing and / or resource allocation. In the case of a TB with low priority, the WTRU may drop the TB. For example, if the resource pool's CBR is high, the WTRU may wake up to perform sensing. Otherwise, the WTRU may wait for the DRX ON duration to expire before performing sensing and / or resource allocation. The WTRU may determine whether to wake up to perform sensing, for example, based on the sensing type. In the example, based on the sensing type, the WTRU may wake up to perform short-term sensing. Otherwise, the WTRU may not wake up (e.g., to perform long-term sensing). The WTRU may wake up to perform long-term sensing based on the sensing type. Otherwise, the WTRU may not wake up (e.g., to perform short-term sensing). The WTRU may wake up to perform sensing for TBs with HARQ enabled and / or the WTRU may not wake up to perform sensing for TBs with HARQ disabled. In the example, the WTRU may wake up to perform sensing for TBs with HARQ disabled, and the WTRU may not wake up to perform sensing for TBs with HARQ enabled. If the WTRU performs semi-persistent resource reservation, the WTRU may wake up to perform sensing. In the example, if the WTRU does not perform semi-persistent resource reservation, the WTRU may not wake up to perform sensing. For example, if the WTRU is in a DRX OFF cycle, the WTRU may decide to perform sensing for resource reassessment and / or preemption.

[0253] The WTRU can determine the data to be considered when triggering resource selection. Based on the data arrival buffer (e.g., MAC buffer), the WTRU can trigger resource (re)selection for the arriving data. The WTRU can determine the destination for triggering resource allocation based on the priority of the logical channel (e.g., LCH) and / or the DRX type of the destination. The WTRU can trigger resource selection for the LCH with the highest priority. If multiple LCHs with the same highest priority exist, the WTRU can prioritize the LCH associated with the SL DRX RxWTRU. The WTRU can trigger resource selection for the LCH associated with the DRX Rx WTRU (e.g., targeting the DRX Rx WTRU), for example, regardless of priority.

[0254] For example, WTRU behavior can be provided if the minimum CPS window is not met. In the example, the WTRU may not (e.g., be able to) meet the minimum and / or maximum CPS sensing windows. The WTRU may perform one or more of the following: discard the TB and / or perform a transfer in another resource pool (e.g., an anomalous resource pool); reduce the number of (re)transfers of the TB; change from semi-persistent reservation to non-periodic transfer, for example, if the required CPS sensing window is (pre)configured for semi-persistent reservation; or perform random resource selection for the TB, for example, if the resource pool allows random resource allocation.

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

[0256] For example, if the number of candidate slots in the resource selection window is less than the minimum number of candidate slots, the WTRU may do one or more of the following: not perform resource re-evaluation, discard the selected resources and not perform resource re-selection for the pre-selected resources, or extend the resource selection window beyond the set of candidate slots.

[0257] The WTRU can determine a set of candidate time slots for resource reassessment. The WTRU can determine a set of candidate time slots for resource reassessment (e.g., a set of time slots for determining the set of resources to be reported to higher layers). The set of candidate time slots can be determined based on one or more of the following: the set of candidate time slots 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 can select a set of candidate time slots within the set of candidate time slots used by the WTRU for initial resource selection. For example, if the CBR of the resource pool is less than a threshold, the WTRU can select a set of candidate time slots within the set of candidate time slots used for initial resource selection. For example, if the CBR of the resource pool is greater than a threshold, the WTRU can select a set of candidate time slots both within and outside the set of candidate time slots used for initial resource selection, as well as outside the set of candidate time slots. For example, if the number of retransmissions associated with the TB is less than a threshold, the WTRU can select a set of candidate time slots within the set of candidate time slots used for initial resource selection. If the number of retransmissions associated with a TB exceeds a threshold, the WTRU can select a set of candidate time slots both within and outside the set used for initial resource selection. The threshold can be (pre)configured. For example, the threshold can be (pre)configured per resource pool.

[0258] The WTRU can determine the reserved time slot for performing preemption checks. The WTRU can determine, for example, whether to perform a preemption check for a reserved time slot (e.g., a reserved time slot) based on whether the reserved resource is within a set of candidate time slots designated for periodic partial sensing resource allocation. For example, if the reserved time slot is within the set of candidate time slots, the WTRU can perform a preemption check. Otherwise, the WTRU can skip the preemption check.

[0259] The WTRU determines the set of sensing slots available for preemption checks. The WTRU performs periodic partial sensing for preemption checks. The WTRU performs sensing and extracts the sensing results for detecting semi-persistent reservations. For example, if the selected resource conflicts with another semi-persistent reservation with a higher priority, the WTRU performs resource reselection.

[0260] Figure 11 This illustrates how WTRU performs resource reassessment and / or preemption for resources at time slot m. For example... Figure 11 As shown, WTRU can perform resource reassessment and / or preemption for reserved / selected resources at time m-T3. The set of candidate time slots is within a rectangle labeled "Set of Y candidate time slots", and the set of remaining candidate time slots is within a rectangle labeled "Set of remaining candidate time slots".

[0261] The WTRU can determine whether to trigger resource re-evaluation and / or preemption for pre-selected and / or reserved resources. In the example, the WTRU can determine whether to trigger resource re-evaluation and / or preemption for 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 to be re-evaluated; or the possibility of having a CPS window for resource re-evaluation.

[0262] The WTRU can determine whether to trigger a reassessment / preemption for a pre-selected / reserved resource based on the time gap between the resource selection time slot and the time slot for the first selected resource used for reassessment. For example, if the time gap between the resource selection time slot and the time slot for the first selected resource used for reassessment is less than a threshold, the WTRU can prevent (e.g., not trigger) resource reassessment. Otherwise, for example, if the time gap between the resource selection time slot and the time slot for the first selected resource used for reassessment is greater than the threshold, the WTRU can trigger resource reassessment. The threshold can be fixed (e.g., 31 time slots) and / or (pre)configured, which can be determined based on the QoS of the TB.

[0263] The WTRU may, for example, determine whether to trigger resource reassessment and / or preemption for pre-selected and / or reserved resources based on the probability of having a CPS window for resource reassessment. For example, if the CPS window is greater than a threshold, the WTRU may trigger resource reassessment. Otherwise, for example, if the CPS window is less than the threshold, the WTRU may prevent (e.g., not trigger) resource reassessment. The threshold may be (pre)configured and may be a function of the QoS of the TB (e.g., the priority of the TB or the remaining PDB of the TB).

[0264] The WTRU can determine the type of sensing used for resource reassessment and / or preemption. In the example, the WTRU can perform CPS (e.g., CPS only) for resource reassessment and / or preemption. The WTRU can perform PBPS (e.g., PBPS only) for resource reassessment and / or preemption. The WTRU can perform both CPS and PBPS for preemption and resource reassessment. The WTRU can be limited to initiating (e.g., not allowed to initiate) PBPS for resource reassessment and / or preemption (e.g., new PBPS). The WTRU can reuse PBPS sensing results from a PBPS process (e.g., an existing PBPS process) that may target another TB and / or another resource allocation process.

[0265] The WTRU can trigger sensing for resource reassessment and / or preemption. In the example, the WTRU can trigger CPS and / or PBPS for resource reassessment / preemption. Triggering can be based on one or more of the following: resource selection slot; first transmission slot in a first time period; arrival of TB; resources for first pre-selected and / or reserved resource reassessment and / or preemption; or QoS of TB.

[0266] Triggers for sensing resource reassessment and / or preemption may be based on, for example, a resource selection time slot. In an example, the WTRU may trigger a PBPS for preemption if / when it performs a resource selection for semi-persistent reservation. The WTRU may determine a set of reservation periods for the PBPS and / or a periodic sensing opportunity (PSO) for each period (e.g., each period), for example, based on the timing between the resource selection and a first selected resource for reservation in the next period (e.g., a subsequent period). The WTRU may select a reservation period for the PBPS, for example, a reservation period shorter than the time gap between the resource selection time slot and a time slot with reserved resources in the next period (e.g., a subsequent period). In an example, the WTRU may trigger a CPS for resource reassessment based on the resource selection time slot. For example, if the time gap between the resource selection time slot and the first resource for reassessment is less than a threshold, the WTRU may trigger a CPS for resource reassessment for the pre-selected resource. Otherwise, for example, if the time gap is greater than a threshold, the WTRU may disable (e.g., not trigger) the CPS for resource reassessment. The threshold can be fixed (e.g., 31 slots) or (pre)configured, which can be based on QoS in TB.

[0267] Triggers for sensing resource reassessment and / or preemption may be based on, for example, a first transmission slot within a first time period. For instance, if / when the WTRU performs transmission and / or reservation of a selected resource during the first time period, the WTRU may trigger a PBPS for the reserved resource. The WTRU may determine, for example, a set of reservation periods for PBPS and / or PSO for each reservation period (e.g., each reservation period) based on the resource reservation period. The WTRU may select a reservation period for a PBPS, for example, that is shorter than the reservation period.

[0268] Triggers for sensing resource reassessment and / or preemption may be based on, for example, the arrival of a TB. In an example, the WTRU may trigger a CPS for preemption of a reserved resource based, for example, on the arrival of periodic data transmitted in the reserved resource (e.g., expected).

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

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

[0271] In the example, the WTRU may trigger preemptive CPS based, for example, on the arrival of the TB and the first reserved resource for preemption. In the example, the WTRU may trigger CPS sensing based on either the arrival of the TB or the first reserved resource. For example, if periodic data arrives, the WTRU may trigger sensing. For example, if data has not yet arrived, the WTRU may trigger CPS M slots before the first reserved resource. In the example, the WTRU may trigger CPS based on both the arrival of the TB and the first reserved resource. For example, if periodic data arrives, the WTRU may trigger CPS (e.g., at least) M slots before the first reserved resource. For example, if periodic data has not yet arrived, the WTRU may disable triggering (e.g., not trigger). M may be (pre)configured (e.g., TB-based QoS) and / or fixed (e.g., 31 slots).

[0272] The WTRU can determine whether to execute CPS for resource reassessment and / or preemption. In the example, the WTRU can determine whether to execute CPS for resource reassessment and / or preemption based on one or more of the following: the existence of (pre)configuration; the QoS of the TB; the time interval between the last sensing slot in the initial resource selection and the resource (re)assessment / preemption trigger slot n; the time interval between the last sensing slot in the initial resource selection and the first resource (r0) undergoing resource reassessment; the resource reservation period; or whether the WTRU executes CPS for initial resource allocation.

[0273] For example, based on the presence or absence of (pre)configuration, the WTRU can determine whether to execute CPS for resource reassessment and / or preemption. For instance, the WTRU may be (pre)configured with information associated with the resource pool (e.g., receiving configuration information) indicating whether CPS for resource reassessment and / or preemption is enabled or disabled. For example, if CPS is enabled, the WTRU may execute CPS for resource reassessment and / or preemption. Otherwise, the WTRU may disable (e.g., not execute) CPS for resource reassessment and / or preemption.

[0274] For example, based on the QoS of a resource TB, the WTRU can determine whether to execute CPS for resource reassessment and / or preemption. For instance, if the PDB of a resource TB is less than a threshold, the WTRU can disable (e.g., not execute) CPS. Otherwise, the WTRU can execute CPS.

[0275] The WTRU may determine whether to execute 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 resource (re)assessment and / or preemption trigger slot n. For example, if the time gap between the last sensing slot in the initial resource selection and the resource reassessment and / or preemption trigger slot n is less than a threshold, the WTRU may disable (e.g., not execute) CPS. Otherwise, the WTRU may execute CPS. The threshold may be (pre)configured, which may be based on the QoS of the TB.

[0276] For example, based on the time gap between the last sensing slot in the initial resource selection and the first resource (r0) undergoing resource reassessment, the WTRU can determine whether to execute CPS for resource reassessment and / or preemption. For instance, if the time gap between the last sensing slot in the initial resource selection and the first resource (r0) undergoing resource reassessment is less than a threshold, the WTRU can disable (e.g., not execute) CPS. Otherwise, the WTRU can execute CPS. The threshold can be (pre)configured, which may be based on the QoS of the TB.

[0277] For example, based on the resource reservation period, the WTRU can determine whether to execute CPS for resource reassessment and / or preemption. For instance, if the resource reservation period is less than a threshold, the WTRU can disable (e.g., not execute) CPS. Otherwise, the WTRU can execute CPS for preemption. The threshold can be (pre)configured, which can be based on the QoS of the TB.

[0278] For example, based on whether the WTRU executes the CPS for initial resource allocation, the WTRU may determine whether to execute the CPS for resource reassessment and / or preemption. In this example, for instance, if the WTRU executes the CPS for initial resource allocation, the WTRU may execute (e.g., determine to execute) the CPS for resource reassessment and / or preemption. Otherwise, for instance, if the WTRU does not execute the CPS for resource reassessment, the WTRU may disable (e.g., not execute) the CPS for initial resource allocation and / or preemption. In this example, for instance, if the WTRU does not execute the CPS for initial resource allocation, the WTRU may execute (e.g., determine to execute) the CPS for resource reassessment and / or preemption. Otherwise, for instance, if the WTRU does not execute the CPS for initial resource allocation, the WTRU may execute the CPS for resource reassessment / preemption.

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

[0280] WTRU may determine one or more of the following CPS parameters for resource reassessment and / or preemption based on: (pre)configuration; CPS window for initial resource allocation; QoS of TB; time interval between the last sensing slot in initial resource selection and the first resource (r0) undergoing resource reassessment; time interval between preemption trigger slot n and the first preempted resource (r0'); resource reservation period; or CPS parameters for initial resource allocation.

[0281] The WTRU can determine one or more of the CPS parameters for resource re-evaluation and / or preemption based on (pre)configuration. In the example, the WTRU may be (pre)configured with information indicating the minimum and / or maximum CPS windows for resource re-evaluation and / or preemption (e.g., receiving configuration information). For example, the WTRU may perform CPS within a window to satisfy the minimum and / or maximum CPS windows.

[0282] The WTRU can determine one or more of the CPS parameters used for resource re-evaluation and / or preemption based on the CPS window used for initial resource allocation. For example, the WTRU can use the same CPS window size for initial resource allocation and / or resource re-evaluation and / or preemption for the same TB. For example, the WTRU can use the same CPS window size for preemption in other time periods (e.g., all time periods).

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

[0284] Based on the time gap between the last sensing slot in the initial resource selection and the first resource (r0) undergoing resource re-evaluation, the WTRU can determine one or more of the CPS parameters for resource re-evaluation and / or preemption. For example, if the time gap between slot n and the first preempted resource is less than a threshold, the WTRU can perform CPS in the time gaps (e.g., all slots) between slot n and the first preempted resource (e.g., except for the slot used for WTRU processing). The threshold can be (pre)configured. Otherwise, for example, if the time gap between slot n and the first preempted resource is greater than the threshold, the WTRU can perform CPS (e.g., at least) in the M time gaps preceding the first preempted resource (r0'). The value of M can be fixed and / or (pre)configured, which can be based on the QoS of the TB.

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

[0286] The WTRU can determine one or more of the CPS parameters used for resource reassessment and / or preemption based on the resource reservation period. For example, the WTRU can be (pre-)configured with multiple minimum CPS windows (e.g., receiving configuration information indicating them). Each CPS window (e.g., each CPS window) can be associated with one or more reservation periods. The WTRU can determine the CPS window, for example, based on the reservation period of the reserved resource. In the example, the WTRU can be (pre-)configured with multiple minimum CPS windows (e.g., two minimum CPS windows) (e.g., receiving configuration information indicating them), wherein a first window (e.g., M < 31 slots) can be associated with a first set of reservation periods (e.g., for a small reservation period), and a second window (e.g., M = 31 slots) can be associated with a second set of reservation periods (e.g., for a large reservation period). The WTRU can determine the CPS window based on the reservation period of the reserved resource.

[0287] The WTRU can determine one or more of the 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 a minimum and / or maximum CPS window and / or a CPS window for resource re-evaluation and / or preemption, for instance, based on the CPS window used for initial resource allocation. In an example, the WTRU can be (pre-)configured with 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 (e.g., receiving configuration information indicating this). The offset can be fixed and / or (pre-)configurable, which can be based on QoS of TB. For example, the WTRU can be (pre-configured) with a CPS window for initial resource allocation of M time slots (e.g., receiving configuration information indicating this). The WTRU can determine the CPS window for resource re-evaluation and / or preemption as an M offset (e.g., time slot). For example, the WTRU can be (pre-configured) with a minimum and / or maximum CPS window for M time slots (e.g., receiving configuration information indicating this). WTRU determines the minimum and / or maximum CPS window used for resource reassessment and / or preemption as the M offset (e.g., time slot). The offset can be negative, positive, or zero. WTRU determines the CPS window to satisfy the (pre)configured minimum window.

[0288] WTRU can determine PBPS parameters for resource reassessment and / or preemption. PBPS parameters for resource reassessment and / or preemption may include one or more of the following parameters: the triggered CPS sensing slot and / or the triggered resource reassessment and / or preemption slot; the set of reserved time periods to be sensed; the set of sensing opportunities by reserved time period; and the sensing window [n-T0,n].

[0289] WTRU may determine one or more of the following PBPS parameters for resource reassessment and / or preemption based on: (pre)configuration; resource reservation period; or parameters of PBPS for initial resource allocation.

[0290] The WTRU can determine one or more of the PBPS parameters for resource reassessment and / or preemption based on (pre)configuration. For example, the WTRU may be (pre)configured with a set of reserved time periods and / or a set of SPOs (e.g., to monitor resource reassessment and / or preemption) (e.g., receiving configuration information indicating them). The WTRU can perform sensing in the set of reserved time periods and / or the PSOs of each time period (e.g., each time period). For example, the WTRU may be (pre)configured with a set of reserved time periods to monitor resource reassessment and / or preemption (e.g., receiving configuration information indicating them). The WTRU may not be (pre)configured with a set of PSOs for each resource reserved time period (e.g., the configuration information may not indicate a set of PSOs for each resource reserved time period). The WTRU can perform sensing in the most recent PSO for each resource reserved time period for resource reassessment and / or preemption.

[0291] The WTRU can determine one or more of the PBPS parameters used for resource reassessment and / or preemption based on the resource reservation period. In the example, the WTRU can determine the set of reservation periods to monitor and / or the set of PSOs for each reservation period based on the reserved resource reservation period. The WTRU can perform PBPS within a reservation period (e.g., determined to be) less than or equal to the reservation period of the reserved resource.

[0292] The WTRU can determine one or more of the CPS parameters for resource reassessment and / or preemption based on the parameters of the PBPS used for initial resource allocation. For example, the WTRU can perform the PBPS for resource reassessment and / or preemption during the time period (pre-configured) for initial resource allocation. The WTRU can perform sensing in the most recent PSO for the time period (e.g., only each time period), regardless of the set of PSOs (pre-configured) for initial resource allocation.

[0293] The WTRU can determine a set of Y candidate time slots for a PBPS used for resource reassessment and / or preemption. In the example, the WTRU can determine the set of Y candidate time slots for a PBPS used for resource reassessment and / or preemption based on one or more of the following: (pre)configuration; or a set of Y0 candidate time slots for the initial resource allocation of the same TB by the WTRU.

[0294] The WTRU can determine a set of Y candidate time slots for PBPSs used for resource re-evaluation and / or preemption based on (pre)configuration (e.g., received configuration information). For example, the WTRU can be (pre)configured with Ymin candidate time slots for PBPSs used for resource re-evaluation and / or preemption (e.g., receiving configuration information indicating them). The WTRU can select Y>Ymin candidate time slots for PBPSs used for resource re-evaluation and / or preemption.

[0295] The WTRU can determine the set of Y candidate time slots for resource reassessment and / or preemption based on the set of Y0 candidate time slots for the initial resource allocation of the WTRU for the same TB. For example, the WTRU can determine the set of Y candidate time slots based on the remaining set of Y0 candidate time slots within the RSW for the initial resource allocation of the WTRU for the same TB. The WTRU can include the remaining Y0 candidate time slots (e.g., all remaining Y0 candidate time slots) within the RSW for the PBPS.

[0296] WTRU can determine the resource selection window for resource reassessment. The resource selection window parameters used for resource reassessment and / or preemption may include one or more of the following parameters: trigger slot n; values ​​of T1 and T2; or resource selection window [n+T1, n+T2].

[0297] WTRU may determine one or more of the resource selection window parameters for resource reassessment and / or preemption based on one or more of the following: the set of resources undergoing resource reassessment and / or preemption; or the QoS of TB.

[0298] The WTRU may determine one or more of the resource selection window parameters for resource reassessment and / or preemption based on the set of resources undergoing resource reassessment and / or preemption. In the example, the WTRU may determine the trigger slot n for resource reassessment and / or preemption based on the timing of the first resource undergoing resource reassessment and / or preemption. The WTRU may trigger (e.g., be required to trigger) resource reassessment and / or preemption (e.g., at least) X slots before the first resource undergoing resource reassessment and / or preemption. The value of X may be fixed (e.g., 31 slots). The value of X may be (pre)configured, which may be further (pre)configured based on the QoS of the TB, the CBR of the resource pool, and / or the resource reservation period. In the example, the WTRU may determine the resource selection window [n+T1, n+T2] for resource reassessment and / or preemption based on the set of resources undergoing resource reassessment and / or preemption.

[0299] 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 (e.g., the set of candidate resource set A initialized for resource reassessment and / or preemption): a window [n+Y1, n+Y2] for initializing the set of candidate resources A; or a set of time slots within the candidate resource window for initializing the candidate resource set. Parameters (e.g., for determining the set of time slots used to initialize set A) can be determined based on one or more of the following: whether the WTRU semi-persistently reserves pre-selected resources; whether the WTRU semi-permanently reserves reselected resources; the set of Y0 candidate time slots for initial resource allocation or the set of Y0 candidate time slots for initial resource selection, and the set of remaining time slots; or whether there are existing Ymin candidate time slots with PBPS results within the RSW used for resource reassessment.

[0300] Parameters (e.g., the set of time slots used to initialize set A) can be determined based on whether the WTRU semi-persistently reserves pre-selected resources. For example, if the WTRU semi-persistently reserves pre-selected resources, the WTRU may select Y candidate time slots with PBPS results (e.g., for resource reassessment). The WTRU may initialize set A for resource reassessment from the set of Y candidate time slots. Otherwise, for example, if the WTRU does not semi-persistently reserve pre-selected resources, the WTRU may initialize set A from the set of time slots (e.g., regardless of whether the time slots have PBPS sensing results).

[0301] Parameters (e.g., the set of time slots used to initialize set A) can be determined based on whether the WTRU semi-persistently reserves resources for reselection. For example, if the WTRU semi-persistently reserves resources for reselection, the WTRU may select Y candidate time slots with PBPS results. The WTRU may initialize set A from the set of Y candidate time slots. Otherwise, for example, if the WTRU does not semi-persistently reserve resources for reselection, the WTRU may initialize set A from the set of time slots (e.g., regardless of whether the time slots have PBPS sensing results).

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

[0303] Parameters (e.g., the set of slots used to initialize set A) can be determined based on the existence of Ymin candidate slots with PBPS results within the RSW used for resource reassessment. For example, the WTRU can determine the set of slots to initialize set A of candidate resources for resource reassessment and / or preemption based on the existence of Ymin candidate slots with PBPS results within the RSW. For example, if Ymin candidate slots with PBPS results exist, the WTRU can initialize candidate resource set A in Ymin candidate slots (e.g., all Ymin candidate slots). The WTRU can perform semi-persistent reservation for the reselected resources. Otherwise, for example, if there are no Ymin candidate slots within the RSW, the WTRU can initialize candidate resource set A in a window [n+Y1, n+Y2] (e.g., regardless of whether the slots have PBPS results). The WTRU can disable (e.g., not perform) semi-persistent reservation for the reselected resources.

[0304] Due to resource re-evaluation and / or preemption based on set A with PBPS results, the WTRU may prioritize the reselection of transport resources. In the example, due to resource re-evaluation and / or preemption, the WTRU may detect conflicts between pre-selected and / or reserved resources. The WTRU may reselect another resource from the candidate resource set (e.g., set A). The WTRU may prioritize resources with PBPS results. For example, if the number of resources in set A with PBPS sensing results is greater than a threshold, the WTRU may reselect one or more resources to replace conflicting resources in the time slot set with PBPS results. The WTRU may reselect the remaining resources in the entire set A. The threshold may be (pre)configurable. For example, if the reselected resource is within the set of Y candidate time slots with PBPS sensing results, the WTRU may perform semi-persistent reservation for the reselected resource. Otherwise, if the reselected resource is outside the Y candidate time slots, the WTRU may prohibit (e.g., not perform) semi-persistent reservation for the reselected resource.

[0305] Due to preemption within the same time slot as the reserved resource, the WTRU can reselect a resource. In the example, the WTRU can detect a conflict with the reserved resource. The WTRU can then reselect another resource to replace the reserved resource. The WTRU can prioritize reselecting a resource within the same time slot as the conflicting resource. For example, based on the WTRU reselecting a resource due to preemption within the same time slot as the reserved resource, the perception of preemption can be reduced.

[0306] WTRU may determine whether to perform resource reassessment and / or preemption based on one or more of the following: whether WTRU performs semi-persistent resource reservation for the resource; the set of candidate time slots for possible resource reselection; the HARQ type of the TB; or the CBR of the resource pool.

[0307] The WTRU can determine whether to perform resource re-evaluation and / or preemption based on whether it performs semi-persistent resource reservation for the resource. In the example, the WTRU may perform resource re-evaluation and / or preemption for semi-persistently reserved resources, and may not perform resource re-evaluation and / or preemption for one-transmission resources (e.g., one-time transmission resources). The WTRU may perform resource re-evaluation for one-transmission resources (e.g., one-time transmission resources), and may not perform resource re-evaluation for semi-permanently reserved resources.

[0308] The WTRU can determine whether to perform resource reassessment and / or preemption based on the set of candidate time slots for possible resource reselection. In the example, if the set of remaining candidate time slots for possible resource reselection is greater than a threshold, the WTRU may perform resource reassessment and / or preemption. Otherwise, the WTRU may not perform resource reassessment and / or preemption. The threshold can be (pre)configured per resource pool. The threshold can be a function of the priority of the TB.

[0309] The WTRU can determine whether to perform resource reassessment and / or preemption based on the TB's HARQ type. In the example, the WTRU can perform resource reassessment and / or preemption for TBs with HARQ disabled, and it can not perform resource reassessment and / or preemption for TBs with HARQ enabled.

[0310] WTRU can determine whether to perform resource reassessment and / or preemption based on the resource pool's CBR. For example, if the resource pool's CBR is greater than a threshold, WTRU may perform resource reassessment and / or preemption. Otherwise, WTRU may not perform resource reassessment and / or preemption. The threshold can be (pre)configured per resource pool.

[0311] The WTRU can determine the time slot used to trigger resource reassessment and / or preemption. In the example, the WTRU can determine the time slot used to trigger resource reassessment and / or preemption based on the set of remaining candidate time slots. For example, the WTRU can be (pre)configured with a minimum number of candidate time slots for resource reassessment and / or preemption. The WTRU can trigger resource reassessment and / or preemption such that the set of remaining candidate time slots is greater than a threshold.

[0312] The WTRU can determine a resource selection window for resource re-evaluation and / or preemption. In the example, the WTRU can determine the resource selection window for resource re-evaluation and / or preemption based on the size of the set of remaining candidate slots. For example, the WTRU can be (pre-)configured with a minimum number of candidate slots for resource re-evaluation and / or preemption. In the example, if the set of remaining candidate slots is greater than a threshold, the resource selection window can be within the set of remaining candidate slots. If the set of remaining candidate slots is less than the threshold, the WTRU can perform one or more of the following: expand the resource selection window to include both the set of remaining candidate slots and slots outside the set of remaining candidate slots; do not perform resource re-evaluation and / or preemption for the resource; discard the TB; discard the resource that has undergone resource re-evaluation and / or preemption.

[0313] The WTRU can trigger preemption checks. In the example, the WTRU may determine whether to perform a preemption check based on one or more of the following: a change in the QoS of the TB, a change in the CBR of the resource pool, the number of transmissions made by the WTRU for the TB (e.g., a TB) in a previous period, the number of transmissions made by the WTRU for a reserved resource (e.g., a reserved resource), the number of NACKs and / or DTXs received by the WTRU for a reserved resource (e.g., a reserved resource), the percentage of NACKs and / or DTXs that the WTRU has received for a reserved resource (e.g., a reserved resource), a check on the reserved resource set after the WTRU has sufficient PBPS and / or CPS results for the preemption check of the reserved resource set, or a periodic preemption check (e.g., a preemption check for a required period).

[0314] WTRU can determine whether to perform a preemption check based on changes in the QoS of a resource pool (TB). For example, if the priority of a TB in the current time period has changed compared to the priority of a TB in the last time period, WTRU can trigger a preemption check for reserved resources in a future reserved time period. WTRU can also trigger a preemption check if the priority gap between the current and last time periods is greater than a threshold. The threshold can be (pre)configured per resource pool.

[0315] WTRU can determine whether to perform a preemption check based on changes in the resource pool's CBR. For example, if the resource pool's CBR becomes greater than a threshold, WTRU can trigger a preemption check. The threshold can be (pre)configured per resource pool.

[0316] The WTRU can determine whether to perform a preemption check based on the number of transfers it has already made for a TB (e.g., one TB) in a previous time period. For example, if the number of transfers for a TB (e.g., one TB) exceeds a threshold, the WTRU can trigger a preemption check for future resource reservation periods. The threshold can be (pre)configured per resource pool, which may depend on the priority of the TB.

[0317] The WTRU can determine whether to perform a preemption check based on the number of transfers it has already made for a reserved resource (e.g., a single reserved resource). For example, the WTRU can semi-persistently reserve resources. The WTRU can perform a preemption check on the reserved resource after N reservation periods and / or after N transfers within the reserved resource. The value of N can be (pre)configured per resource pool.

[0318] The WTRU can determine whether to perform a preemption check based on the number of NACKs and / or DTXs it has received for a reserved resource (e.g., one reserved resource). For example, if the WTRU has received N (e.g., N consecutive) NACKs and / or DTXs for a reserved resource (e.g., one reserved resource), the WTRU can determine to perform a preemption check. The value of N can be (pre)configured per resource pool, which may depend on the QoS of the TB.

[0319] The WTRU can determine whether to perform a preemption check based on the percentage of NACKs and / or DTXs it has received for a reserved resource (e.g., a reserved resource). For example, if the WTRU receives X% NACKs and / or DTXs, it can determine to perform a preemption check for a reserved resource (e.g., a reserved resource). The value of X can be (pre)configured per resource pool. The value of X can depend on the QoS of the TB (e.g., the priority of the TB).

[0320] After the WTRU has sufficient PBPS and / or CPS results for preemption checks on a set of reserved resources, the WTRU may determine whether to perform a preemption check. The WTRU may trigger a preemption check after it has sufficient PBPS and / or CPS results. The WTRU may semi-persistently reserve resources. The WTRU may perform transmissions for one or more reservation periods. The WTRU may monitor a set of reservation periods (e.g., a specific set) for PBPS. When the WTRU has monitored sufficient reservation periods for PBPS and when it has collected sufficient CPS results for preemption checks on a resource (e.g., a single resource) within a period (e.g., a specific period), the WTRU may perform a preemption check (e.g., perform a preemption check thereafter).

[0321] WTRU can determine whether to perform a preemption check based on periodic preemption checks (e.g., preemption checks for required time periods). For example, WTRU can periodically perform preemption checks for resource reservation procedures (e.g., a resource reservation procedure).

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

[0323] The triggering of sensing (e.g., for preemption checks) may be based on one or more of the following: the WTRU performing resource (re)selection for a semi-persistently reserved transport resource; the WTRU sending a transport in a semi-persistently reserved resource; a change in the QoS of the TB; a change in the CBR of the resource pool; the number of transports that the WTRU has already made for a TB (e.g., a TB) in a previous period; the number of transports that the WTRU has already made for a reserved resource (e.g., a reserved resource); the number of NACKs and / or DTXs that the WTRU has already received for a reserved resource (e.g., a reserved resource); or the percentage of NACKs and / or DTXs that the WTRU has already received for a reserved resource (e.g., a reserved resource).

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

[0325] Sensing can be triggered based on the WTRU sending a transmission in a semi-persistently reserved resource. For example, the WTRU can trigger sensing for a preemption check of a reserved resource in a future reservation period. During the procedure, the WTRU can send a transmission on the selected resource. In the example, after the WTRU constructs TB to send a transmission on the selected resource, the WTRU can trigger a PBPS procedure (e.g., a new PBPS procedure). In this case, the WTRU's MAC layer can notify the PHY layer of the set of semi-persistently reserved resources in the current period. The MAC layer can initialize a PBPS (e.g., a new PBPS) for potential preemption checks of reserved resources in a future reservation period.

[0326] Sensing can be triggered based on changes in the QoS of a resource pool (TB). For example, if the priority of a TB in the current time period has changed compared to the priority of a TB in the last time period, the WTRU can trigger sensing for preemption checks of reserved resources in future reserved time periods. Alternatively, if the priority gap between the current and last time periods is greater than a threshold, the WTRU can trigger sensing for preemption checks. Thresholds can be (pre)configured per resource pool.

[0327] Sensing can be triggered based on changes in the resource pool's CBR. For example, if the resource pool's CBR is greater than a threshold, the WTRU can trigger sensing for preemption checks. The threshold can be (pre)configured per resource pool.

[0328] Sensing can be triggered based on the number of transfers the WTRU has already made for a TB (e.g., one TB) in a previous time period. For example, if the number of transfers the WTRU has already made for a TB (e.g., one TB) exceeds a threshold, the WTRU can trigger sensing for a preemption check for future resource reservation periods. The threshold can be (pre)configured per resource pool, and it can depend on the priority of the TB.

[0329] Sensing can be triggered based on the number of transmissions the WTRU has already sent for a reserved resource (e.g., a single reserved resource). For example, the WTRU may semi-persistently reserve resources. The WTRU may trigger sensing for a preemption check of the reserved resource after N reservation periods and / or after sending N transmissions within the reserved resource. The value of N can be (pre)configured per resource pool.

[0330] Sensing can be triggered based on the number of NACKs and / or DTXs that the WTRU has received for a reserved resource (e.g., a reserved resource). For example, if the WTRU has received N (e.g., N consecutive) NACKs and / or DTXs for a transmission in a reserved resource (e.g., a reserved resource), the WTRU can trigger sensing for preemption. The value of N can be (pre)configured per resource pool. The value of N can depend on the QoS of the TB.

[0331] Sensing can be triggered based on the percentage of NACKs and / or DTXs that the WTRU has received for a reserved resource (e.g., a reserved resource). For example, if the WTRU receives X% NACKs and / or DTXs, the WTRU can trigger sensing for a preemption check for a reserved resource (e.g., a reserved resource). The value of X can be (pre)configured per resource pool, which may depend on the QoS of the TB.

[0332] The WTRU can initialize a set of candidate slots for resource reassessment. The WTRU can determine the window for initializing the set SA for resource reassessment based on one or more of the following: whether the set of resources initially selected for resource reassessment will be semi-persistently reserved, and whether the WTRU reselects resources for semi-persistent resource reservation; or the set of Y candidate slots in the resource selection window for resource reassessment.

[0333] The WTRU can determine the window for initializing the set SA for resource reassessment based on whether the set of initially selected resources undergoing resource reassessment will be semi-persistently reserved. For example, if the initially selected resources undergoing resource reassessment will be semi-persistently reserved, the WTRU can initialize the set SA within the set of Y candidate time slots. Otherwise, the WTRU can initialize the set SA regardless of the Y candidate time slots (e.g., the WTRU can initialize the SAS both within and outside the set of Y candidate time slots).

[0334] The WTRU can determine the window for initializing the set of SAs used for resource re-evaluation based on whether the WTRU reselects resources for semi-persistent resource reservation. For example, if the WTRU intends to semi-persistently reserve the selected resources, the WTRU can initialize the set of SAs within the set of Y candidate time slots. Otherwise, the WTRU can initialize the set of SAs regardless of the Y candidate time slots (e.g., the WTRU can initialize SASs both within and outside the set of Y candidate time slots).

[0335] The WTRU can determine the window for initializing the set SA for resource reassessment based on the set of Y candidate slots in the resource selection window for resource reassessment. For example, the set of Y candidate slots may be a subset of the set of candidate slots available for initializing the set SA for a pre-selected resource (e.g., a resource undergoing resource reassessment). For instance, if the set of Y candidate slots is larger than the resource (re)selection window for resource reassessment (greater than Ymin), the WTRU may initialize the set SA within the set of Y candidate slots. Otherwise, the WTRU may initialize the set SA regardless of the set of Y candidate slots (e.g., the WTRU may initialize the set SA to include slots within and outside the set of Y candidate slots).

[0336] In the example, WTRU can determine whether to semi-persistently reserve the reselected resource based on whether the pre-selected resource is semi-persistently reserved and whether there are at least Ymin candidate slots (e.g., within a set of Y candidate slots) in the resource (re)selection window. If both conditions (e.g., both conditions) are met, WTRU can determine to semi-persistently reselect the resource by initializing the set SA within the set of Y candidate slots.

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

[0338] The WTRU can determine a reservation period that can be used to perform a preemption check for a reservation process (e.g., a reservation process). In the example, the WTRU can determine the reservation period for monitoring the preemption check process based on the time interval between two preemption check processes of a semi-persistent reservation process (e.g., a semi-persistent reservation process). For example, the WTRU can perform a preemption check for a semi-persistent reservation (e.g., a semi-persistent reservation) every Nms. The set of reservation periods to be monitored may include configured reservation periods for PBPS (e.g., all configured reservation periods) with reservation intervals less than Nms.

[0339] The WTRU can determine the frequency of preemption checks. In the example, the WTRU can determine the frequency of preemption checks based on one or more of the following: the reservation period for resources already reserved by the WTRU, the QoS of the TB, the maximum reservation period for monitoring PBPS (e.g., the required reservation period), the HARQ type of the TB, the CBR of the resource pool, whether the SL-DRX is (pre)configured, or whether the RxWTRU is configured with an SL DRX.

[0340] The WTRU can determine the frequency of preemption checks based on the reservation periods in which resources are already reserved. For example, the WTRU can be (pre-)configured with the frequency of preemption checks for each reservation period (e.g., a minimum frequency and / or a maximum frequency). For example, the WTRU can be (pre-configured) with a minimum number of preemption checks for each certain number of reservation periods and / or each elapsed time. The WTRU can determine the frequency of preemption checks to satisfy the preemption check frequency (e.g., the desired preemption check frequency).

[0341] The WTRU can determine the frequency of preemption checks based on the QoS of the TB. For example, the WTRU can be (pre)configured with the frequency of preemption checks for each reserved period (e.g., minimum and / or maximum frequency). For example, the WTRU can be (pre)configured with a minimum number of preemption checks for each certain number of reserved periods and / or each elapsed time. The WTRU can determine the frequency of preemption checks to satisfy the preemption check frequency (e.g., the desired preemption check frequency).

[0342] The WTRU can determine the frequency of preemption checks based on the maximum reservation period (e.g., the required reservation period) used to monitor the PBPS. For example, the WTRU can determine the time interval between two preemption checks for a semi-persistent reservation process (e.g., a semi-persistent reservation process) to be greater than the maximum reservation period (e.g., the required reservation period) used to monitor the PBPS.

[0343] The WTRU can determine the preemption check frequency based on the TB's HARQ type. For example, the WTRU can be (pre-)configured with multiple preemption check frequencies (e.g., two preemption check frequencies), where a first frequency can be used for TBs with HARQ enabled and another preemption check frequency can be used for TBs with HARQ disabled. The WTRU can determine which preemption check frequency to use based on the TB's HARQ type. For example, if the TB is HARQ enabled, the WTRU can use the first preemption check frequency, and if the TB is HARQ disabled, the WTRU can use the second preemption check frequency.

[0344] The WTRU can determine the preemption check frequency based on the resource pool's CBR. For example, the WTRU can be (pre-)configured with a preemption check frequency based on the resource pool's CBR. The WTRU can determine which preemption check frequency to use based on the measured resource pool's CBR.

[0345] The WTRU can determine the preemption check frequency based on whether the SL-DRX is (pre-)configured. For example, the WTRU can be (pre-)configured with multiple preemption check frequencies (e.g., two preemption check frequencies). When the SL-DRX is (pre-)configured, a first preemption check frequency can be used, and when the SL-DRX is not configured for the WTRU, a second preemption check frequency can be used. The WTRU can determine the available preemption check frequencies based on whether the SL-DRX is (pre-)configured for the WTRU.

[0346] The WTRU can determine the preemption check frequency based on whether the Rx WTRU is configured with an SL-DRX. For example, the WTRU can be (pre-)configured with multiple preemption check frequencies (e.g., two preemption check frequencies), where a first preemption check frequency can be used when the target Rx WTRU is configured with an SL-DRX, and a second preemption check frequency can be used when the target Rx WTRU is not (pre-)configured with an SL-DRX. The WTRU can determine which preemption check frequency to use based on whether the target Rx WTRU is (pre-)configured with an SL-DRX.

[0347] In the example, the WTRU can be (pre-)configured with a range of time intervals (e.g., the number of reserved periods and / or start-to-end time) to perform preemption checks for each resource reservation process. The WTRU can select (e.g., randomly select) a range of periods to perform preemption checks. The range can be determined based on one or more of the following: reserved periods, TB's QoS, the maximum reserved period used to monitor PBPS (e.g., the required reserved period), TB's HARQ type, or resource pool's CBR.

[0348] The WTRU can determine whether to perform a preemption check during a reserved period (e.g., a reserved period). In the example, a WTRU (pre-)configured with SL DRX can determine whether to perform a preemption check for a resource reservation during a period (e.g., an open period) based on whether the resource reservation period is within the WTRU's DRX ON duration. For example, if the semi-persistently reserved resource is within the WTRU's DRX ON duration, the WTRU can perform a preemption check. If the semi-persistently reserved resource is not within the WTRU's DRX ON duration, the WTRU can determine not to perform a preemption check for the reserved resource. The WTRU can then perform a transfer within the reserved resource without a preemption check.

[0349] The WTRU can determine whether to semi-persistently reserve the reselected resource. In the example, the WTRU may perform resource reselection for a pre-selected resource due to resource re-evaluation and / or preemption. The WTRU may determine whether to semi-persistently reserve the reselected resource based on one or more of the following: pre-determination; whether the reselected resource is within Y candidate time slots (e.g., it may have PBPS sensing results); whether the pre-selected and / or reserved resource is semi-permanently reserved; or whether the WTRU performs PBPS for the reselected resource.

[0350] The WTRU may, for example, determine whether to semi-persistently reserve a reselected resource based on a pre-determined basis. Due to resource re-evaluation and / or preemption, the WTRU may not (e.g., be required) perform semi-persistent reservation for the reselected resource. Due to resource re-evaluation and / or preemption, the WTRU may perform dynamic transfer for the reselected resource (e.g., any reselected resource).

[0351] The WTRU can determine whether to semi-persistently reserve the reselected resource based, for example, on whether the reselected resource is within the set of Y candidate time slots (e.g., it may have PBPS sensing results). For example, when the WTRU detects a conflict in the semi-persistent reservation of a resource, the WTRU can reselect another resource to replace the pre-selected resource. The WTRU can also determine whether to semi-persistently reserve the reselected resource based on whether the selected resource is within the set of Y candidate time slots. For example, if the reselected resource is within the set of Y candidate time slots, the WTRU can semi-persistently reserve the resource. If the reselected resource is outside the set of candidate time slots, the WTRU can choose not to semi-persistently reserve the resource.

[0352] WTRU may, for example, determine whether to semi-persistently reserve reselected resources based on whether pre-selected and / or reserved resources are semi-persistently reserved. For instance, if pre-selected and / or reserved resources are not semi-persistently reserved, WTRU may prohibit semi-persistent reservation (e.g., not reserve) of reselected resources. If pre-selected and / or reserved resources are semi-persistently reserved, WTRU may determine to semi-persistently reserve reselected resources and / or WTRU may prohibit semi-persistent reservation (e.g., not reserve) of reselected resources.

[0353] The WTRU may determine whether to semi-persistently reserve the reselected resource based on whether the WTRU performs a PBPS for the reselected resource. For example, if the WTRU performs a PBPS for a resource selection process involving re-evaluation and / or preemption, the WTRU may semi-persistently reserve the reselected resource. Otherwise, for example, if no PBPS is performed for a resource selection process involving re-evaluation and / or preemption, the WTRU may prohibit semi-persistent reservation (e.g., not reserve) of the reselected resource.

[0354] WTRU can use different RSRP thresholds for semi-persistently reserved resources. In the example, WTRU can apply different RSRP thresholds to semi-persistently reserved resources compared to dynamically reserved resources. For example, WTRU can perform one or more of the following to apply different RSRP thresholds to multiple types (e.g., two types) of resources: WTRU uses a different initial RSRP threshold for semi-persistently reserved resources; or WTRU uses a different RSRP increment step for semi-persistently reserved resources compared to dynamically reserved resources. WTRU can use a different initial RSRP threshold for semi-persistently reserved resources. For example, the initial RSRP threshold applied to semi-persistently reserved resources can be lower than the threshold applied to dynamically reserved resources. WTRU can use a different RSRP increment step size for semi-persistently reserved resources compared to dynamically reserved resources. For example, WTRU can be (pre-)configured with RSRP increment steps (e.g., two RSRP increment steps), where a first step can be associated with semi-persistently reserved resources and another step can be associated with dynamically reserved resources. WTRU can determine the available RSRP increment steps, for example, based on whether resources are reserved semi-persistently or dynamically.

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

[0356] The WTRU can perform SL-RSSI measurements during both DRX ON and DRX OFF durations. CBR_drx can be calculated as a weighted CBR during the DRX ON and DRX OFF durations. The weight vector can be (pre)configured by resource pool and / or by DRX configuration. The CBR during the DRX ON duration can have a higher weight than the CBR during the DRX OFF duration. Such CBR_drx measurements enable the WTRU to reduce congestion (e.g., congestion level) during, for example, the DRX ON duration.

[0357] The WTRU may be (pre-)configured with a measurement window (e.g., the duration of the measurement window) that can be used to calculate CBR_drx. CBR_drx may be associated with TB QoS (e.g., QoS of the TB). The WTRU can determine the duration of CBR_drx that can be used to perform CBR_drx calculation based on TB QoS. In the example, CBR and / or CBR_drx may be received from the peer WTRU via the PC5 interface, Radio Resource Control (RRC) messages, or Media Access Control Element (MAC CE). CBR and / or CBR_drx may also be received from the peer WTRU via messages (e.g., sidelink messages).

[0358] A WTRU may receive a CBR and / or CBR_drx from another WTRU. The receiving WTRU may perform congestion control based on the received CBR and / or CBR_drx. The CBR and / or CBR_drx may be indicated in one or more synchronization signals (e.g., via the sidelink physical broadcast channel (SL-PBCH)).

[0359] The WTRU may determine one or more transmission parameters during the DRX ON duration, for example, based on CBR_drx. For transmissions during DRX ON and / or DRX OFF durations, the WTRU may determine one or more of the following parameters based on the WTRU's CBR_drx: the range of modulation and coding schemes (e.g., MCS) supported by a given MCS table within the resource pool, the range of the number of subchannels used for TB transmissions (e.g., a TB transmission), the range of the number of TB (re)transmissions, or the range of transmission power.

[0360] The WTRU determines the time slots used to trigger resource selection for a TB (e.g., a TB). The WTRU may be (pre-)configured with a set of allowable resource selection triggering time slots for the TB. The WTRU may be (pre-)configured by resource pool and / or DRX configuration. The WTRU may select (e.g., randomly) a resource selection triggering time slot for the TB within the set of allowable resource selection triggering time slots. The set of allowable resource selection triggering time slots may be (pre-)configured based on one or more of the following: the TB's QoS, CBR_drx measured in the resource pool, or the resource pool's DRX configuration and / or CBR. The WTRU may determine the set of allowable resource selection triggering time slots based on the TB's priority. For example, a high-priority TB may be allowed to trigger resource selection in a time slot (e.g., any time slot). A low-priority TB may not be allowed to trigger resource selection in a time slot (e.g., the time slot at the beginning of the DRX ON duration in a DRX cycle). In the example, a set (e.g., each set) associated with the range of CBR and / or CBR_drx can be provided to multiple sets that allow resource-selective trigger slots. WTRU can select the set of resource-selective trigger slots based on CBR and / or CBR_drx.

[0361] The WTRU determines a window and / or a set of candidate time slots for resource selection. The WTRU may be (pre-)configured with a set of allowable time slots for resource selection. The set of allowable time slots for resource selection may be determined based on one or more of the following: TB's QoS, resource pool's CBR, or CBR_drx. The WTRU may determine the time slots available for performing resource selection based on these parameters and / or associated configurations.

[0362] In the example, for partially sensed resource allocation, the WTRU can randomly select candidate time slots for the starting window (e.g., randomly selecting time slot n+Y1 for a window of candidate time slots [n+Y1, n+Y2]). Random selection of candidate time slots for the starting window allows the WTRU to avoid selecting similar windows of candidate time slots for resource selection.

[0363] The WTRU can perform CR_drx calculation. The WTRU can calculate the channel occupancy rate of the DRX (e.g., CR_drx) to determine the WTRU's channel occupancy rate during the DRX ON duration. The CR_drx at time slot n can be calculated based on the amount of resources used for transmission in the past X DRX ON periods and / or the amount of resources reserved and / or selected for transmission in the future Y DRX ON periods. The values ​​of X and / or Y can be fixed and / or (pre)configured according to the DRX configuration of each resource pool.

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

[0365] The WTRU can determine whether to measure the Channel Utilization Rate (CBR) before reserving resources (e.g., one reserved resource). The WTRU can be (pre-)configured to have multiple CBRs (e.g., two CBRs). The CBR can include a default CBR and a measured CBR. The WTRU can use the CBR to determine whether to use sidelink resources to perform a transmission. If the WTRU's channel occupancy rate (e.g., channel occupancy rate, CR) and / or CBR is greater than a threshold, the WTRU may not perform a transmission in the sidelink resource. If the WTRU's CR and / or CBR is less than a threshold, the WTRU can use the sidelink resource to transmit. The CR threshold can be (pre-)configured based on the CBR. For reserved sidelink resources, the WTRU can determine which CBR to use. The WTRU can make this determination based on whether the WTRU performs a preemption check for the reserved sidelink resource. If the preemption check is not performed, the WTRU can use the default CBR. Otherwise, the WTRU can use the measured CBR.

[0366] The WTRU can determine the window for the CBR used for the compute resource pool. In the example, the WTRU can determine the window for the CBR used for the compute resource pool based on one or more of the following: (pre)configured by resource pool; whether semi-persistent reservation is enabled or disabled in the resource pool; the QoS of the TB; the HARQ type of the TB (e.g., TBs with HARQ enabled and disabled); or whether the WTRU can perform semi-persistent reservation for the selected resource regardless of whether the SL DRX is configured to the WTRU.

[0367] In the example, the WTRU can determine the window used to compute the CBR for the resource pool based on whether semi-persistent reservations are enabled or disabled in the resource pool. For example, the WTRU can be (pre-)configured with a set of sensing windows (e.g., two sets) to compute the CBR. The first set of sensing windows can be used for resource pools with semi-persistent reservations enabled. The second set of sensing windows can be used for resource pools with semi-persistent reservations disabled.

[0368] The WTRU can determine the window for CBR (Computational Boundary Rate) of the compute resource pool based on the QoS of the TB. For example, the WTRU can be (pre-)configured with a window based on the priority of the TB. The WTRU can determine the window for measuring CBR based on the priority of the TB.

[0369] The WTRU can determine the window for the Computational Resource Pool (CBR) based on the HARQ type of the TB (e.g., a TB with HARQ enabled or disabled). For example, the WTRU can be (pre-)configured with sensing windows (e.g., two sending windows) for determining the CBR. One of the sensing windows can be used for a TB with HARQ enabled. The other sensing window can be used for a TB with HARQ disabled. The WTRU can determine which sensing window to use based on the TB's HARQ type.

[0370] The WTRU can determine the window for the Compute Resource Pool (CBR) based on whether the WTRU can perform semi-persistent reservation for the selected resource. For example, the WTRU can be (pre-)configured with sensing windows (e.g., two sending windows) for determining the CBR. One sensing window can be used for semi-persistently selected resources and the other sensing window can be used for dynamically selected resources.

[0371] The WTRU can determine the window for the Compute Resource Pool (CBR) based on whether the SL DRX is configured to the WTRU. For example, the WTRU may be (pre-)configured with sensing windows (e.g., two sensing windows) for determining the CBR. If the SL DRX is configured to the Tx WTRU and / or Rx WTRU, one of the sensing windows can be used. If the DRX is not configured to either the Tx WTRU or Rx WTRU, the other sensing window can be used.

[0372] The WTRU can be (pre-)configured with a sliding window (e.g., 100 time slots) for calculating the CBR per resource pool. The WTRU can be (pre-)configured with a minimum number of time slots within each sliding window (e.g., per sliding window) to determine the CBR for the resource pool. If the WTRU measures more than the minimum number of time slots within the sliding window, the WTRU can use the measured CBR. If the WTRU measures less than the minimum required number of time slots, the WTRU can do one or more of the following: discard the TB; or use the default CBR, which can be (pre-configured) per resource pool.

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

[0374] The minimum number of sensing slots within the sliding window and / or the sliding window size can be determined based on whether semi-persistent reservation is enabled or disabled in the resource pool. For example, the WTRU can be (pre-)configured with a set (e.g., two sets) of minimum number of sensing slots within the sliding window size to calculate the CBR, where one of the two sets can be used for a resource pool with semi-persistent reservation enabled. The other set can be used for a resource pool with semi-persistent reservation disabled.

[0375] The minimum number of sensing slots within the sliding window and / or the sliding window size can be configured based on the QoS of the TB. For example, the WTRU can be configured with one or more sets of minimum number of sensing slots and / or a sliding window size to calculate the CBR according to the priority of the TB. The WTRU can determine the set to be used for measuring the CBR based on the priority of the TB.

[0376] The minimum number of sensing slots and / or the sliding window size within the sliding window can be configured based on the HARQ type of the TB. For example, the WTRU may have (pre-)configured sets (e.g., two sets) of minimum number of sensing slots and / or sliding window sizes for calculating the CBR, where one set is available for a TB with HARQ enabled and the other for a TB with HARQ disabled. Based on the HARQ type of the TB, the WTRU can determine which set of minimum number of sensing slots and / or sliding window size is available for calculating the CBR.

[0377] The minimum number of sensing slots within the sliding window and / or the sliding window size can be configured based on whether the WTRU performs semi-persistent reservations for the selected resource. For example, the WTRU may be (pre-)configured with a minimum number of sets of sensing slots (e.g., two sets) and / or a sliding window size to calculate the CBR. One set of the configured sets can be used for semi-persistently selected resources. The second set of the configured sets can be used for dynamically selected resources.

[0378] The minimum number of sensing slots within the sliding window and / or the sliding window size can be configured based on whether the SL DRX is configured for WTRU. For example, the WTRU can be (pre-)configured with a minimum set of sensing slots (e.g., two sets) and / or a sliding window size to determine the CBR. One set of configurations can be used when the SL DRX is configured for Tx WTRU and / or Rx WTRU. A second set of configurations can be used when the DRX is not configured for either Tx WTRU or Rx WTRU.

[0379] Enhanced random resource allocation can be provided. The Tx WTRU can be (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. A resource pool may include a set of subchannels that can be (pre-)configured within the SL bandwidth portion (BWP) and / or within the SL carrier and / or identified using a resource pool index. Subbands of a resource pool may include a set of subchannels (e.g., consecutive subchannels) that are (pre-configured) within the resource pool. The set of subchannels can be identified using a subband index.

[0380] The Tx WTRU can reselect resource allocations from the pre-configured resource allocations for SL transports in SL TB. The Tx WTRU can also randomly reselect resources for SL transports within the selected resource allocations. The Tx WTRU can reselect resource allocations for SL TB transports as described herein.

[0381] The Tx WTRU can randomly (re)select resource allocations for SL transport selection. For example, the Tx WTRU can be (pre)configured with multiple SL transport resource pools (e.g., eight SL transport resource pools). As part of resource selection for SL transport, the Tx WTRU can randomly (re)select one of the (pre)configured SL transport resource pools. The Tx WTRU can be (pre)configured with multiple subbands within a resource pool (e.g., four subbands). The Tx WTRU can randomly (re)select one subband (e.g., from multiple subbands) for resource selection.

[0382] The Tx WTRU can (re)select resource allocations for SL transmission based on the priority of the SL TB to be transmitted and / or the WTRU ID. For example, resource allocations (e.g., resource pools and / or subbands of resource pools) can be (pre)configured for priority ranges. The Tx WTRU can (re)select resource allocations associated with the priority of the SL TB to be transmitted. The Tx WTRU can use L1 destination and / or source IDs to determine the index of the resource allocation (e.g., resource pools and / or subbands of resource pools). The L1 destination and / or source IDs can be configured by higher layers. An operation is performed to determine the total number of (pre)configured resource allocations modulo the decimal version of the WTRU L1 destination and / or source IDs. The Tx WTRU can (re)select resource allocations identified by the resource allocation index.

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

[0384] Time slot conflict information can be specific to one or more time slots that are unavailable for reception, such as time slots scheduled by the Rx WTRU for SL and / or UL transmissions in reserved resources. This type of conflict can be resolved, for example, to prevent the Rx WTRU from losing TBs that could be transmitted by the Tx WTRU. Bit fields in the PSICH can indicate such time slots in a conflict. For example, the Time Resource Indicator (TRIV) value can be calculated based on the time offset of the conflicting time slot relative to the reserved time slot of the Tx WTRU.

[0385] Reserved resource conflict information can be specific to the reserved resource (e.g., the number of sub-channels in the SL time slot). For example, the reserved resource can be reserved for SL transmissions of multiple Tx WTRUs. Conflicts can be resolved, for example, by one of the WTRUs reselecting another resource for transmission. In this case, conflict can be avoided.

[0386] The information indicated in the PSICH may include a resource busy indicator. The resource busy indicator may be based on one or more resource busy metrics measured by the Rx WTRU. The resource busy indicator may include an indication of resource allocations that can be used for resource (re)selection of the Tx WTRU. For example, the number of a resource pool and / or a sub-band of a resource pool may be indicated in the bit field of the PSICH or SCI of the PSCCH. The indicated resource allocation may be based on CBR, RSSI, priority, and / or priority-specific CBR measured and / or evaluated within the resource allocation. The resource busy indicator may include a bitmap. Bits in the bitmap (e.g., each bit) may indicate (pre)configured resource allocations (e.g., resource pools and / or sub-bands of resource pools). The bitmap can provide information about resource allocations available for (re)selection of the Tx WTRU. For example, a bit (e.g., each bit) may be set to one when the measured resource busy metric corresponding to a bit is below a (pre)configured threshold (e.g., recommended for resource (re)selection).

[0387] The Rx WTRU can measure and / or evaluate resource busyness indicators based on a resource busyness metric evaluation window and / or a resource busyness metric. In the case of a resource busyness metric evaluation window, the Rx WTRU can be (pre-)configured with an evaluation window length (L). The placement of the resource busyness metric evaluation window can be based on the evaluation window (L) and / or PSICH transmission slots (n). For example, the resource busyness metric can be determined by the Rx WTRU within a (nLT) time slot. proc ) begins with (nT) procThe resource busyness metric is evaluated within the window ending. Resource busyness metrics may include one or more of the following: CBR, RSSI, priority, priority-specific CBR, or priority-specific RSSI. The Rx WTRU may measure and / or evaluate the CBR of a resource allocation (e.g., the resource pool and / or sub-bands of the resource pool within a (pre)configured resource busyness metric evaluation window). A resource allocation with a low CBR may indicate that the resource allocation is less busy and / or may indicate a low probability of transmission collisions using randomly selected resources. The Rx WTRU may measure and / or evaluate the RSSI of the resources (e.g., each resource) of a resource allocation (e.g., the resource pool and / or sub-bands of the resource pool within a (pre)configured resource busyness metric evaluation window). For a resource allocation (e.g., each resource allocation), the Rx WTRU may determine the resource busyness metric based on the average, minimum, and / or maximum RSSI of the sub-channels belonging to the resource allocation (e.g., all sub-channels). A resource allocation with a low RSSI metric may indicate that the resource allocation is less busy and / or a low probability of transmission collisions using randomly selected resources. The Rx WTRU can measure and / or evaluate the L1 priority associated with decoded SCIs (e.g., each decoded SCI) within a (pre)configured resource busyness metric evaluation window in a resource allocation. For a resource allocation (e.g., each resource allocation), the Rx WTRU can determine a resource busyness metric based on the average, minimum, and / or maximum L1 priority of decoded SCIs (e.g., each decoded SCI) within the resource allocation. The Rx WTRU can measure and / or evaluate the CBR of resources (e.g., all resources) belonging to a resource allocation specific to a (pre)configured priority (e.g., each pre-configured priority). CBR measurement and / or evaluation may include resources (e.g., all resources) where the priority of decoded SCIs within them is lower than the associated priority. For example, a CBR specific to an L1 priority of 3 can be measured and / or evaluated in subchannels where the decoded L1 priority is less than 3. The Rx WTRU can indicate a priority-specific CBR via PSICH corresponding to the priority indicated by the Tx WTRU in resource reservation. Rx WTRUs can indicate resource allocation and / or associated priorities via PSICH. Rx WTRUs can measure and / or evaluate the RSSI of resources (e.g., each resource) belonging to resource allocations that may be specific to (pre)configured priorities (e.g., each pre-configured priority). RSSI measurement and / or evaluation may include resources within which the decoded SCI has a priority lower than the associated priority (e.g., each of the resources). For example, RSSI specific to an L1 priority of 3 can be measured and / or evaluated in subchannels within which the decoded L1 priority is less than 3. Rx WTRUs can determine RSSI metrics specific to associated priorities, for example, based on average, minimum, and / or maximum RSSI. Rx WTRUs can indicate resource allocation and / or associated priorities via PSICH.

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

[0389] A Tx WTRU can exclude resource allocations indicated via PSICH from a random selection of resources. For example, a Tx WTRU can exclude indicated SL slots where slot conflicts are indicated via received PSCCH.

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

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

[0392] The Tx WTRU can indicate a random resource allocation via a PSCCH associated with a PSSCH transmitted in the (re)selected resource. The SCI carried in the PSCCH may include a bit field indicating the type of resource allocation to be performed. For example, a 2-bit SCI field may be applied, and code points may be (pre)defined to indicate full sensing, partial sensing, or random selection.

[0393] WTRU can determine whether to semi-persistently reserve randomly selected resources. In the example, WTRU can determine whether to semi-persistently reserve randomly selected resources based on one or more of the following: QoS of the TB; traffic type (e.g., periodic or non-periodic traffic); HARQ type of the TB; CBR of the resource pool; or whether DRX is configured for WTRU.

[0394] The WTRU can determine whether to semi-persistently reserve randomly selected resources based on the QoS of the TB. The WTRU can be (pre-)configured with a priority threshold. If the TB's priority is less than the threshold, the WTRU can semi-persistently reserve resources. If the TB's priority is greater than the threshold, the WTRU may not be allowed to semi-persistently reserve resources. In the example, the WTRU can be (pre-)configured with a priority threshold. If the TB's priority is greater than the threshold, the WTRU can semi-persistently reserve resources. If the TB's priority is less than the threshold, the WTRU may not be allowed to semi-persistently reserve resources.

[0395] WTRU can determine whether to semi-persistently reserve randomly selected resources based on the TB's HARQ type. For example, WTRU can semi-persistently reserve resources for TBs with HARQ enabled. WTRU can non-persistently reserve resources for TBs with HARQ disabled.

[0396] WTRU can determine whether to semi-persistently reserve randomly selected resources based on the resource pool's CBR. For example, if the resource pool's CBR is greater than a threshold, WTRU may semi-persistently reserve resources. Otherwise, WTRU may not be allowed to semi-persistently reserve resources.

[0397] WTRU can determine whether to semi-persistently reserve randomly selected resources based on whether DRX is configured for WTRU. For example, if WTRU is configured with DRX, semi-persistent resource reservation is allowed. If WTRU is not configured with DRX, semi-persistent resource reservation is not allowed.

[0398] A transmitting wireless transmit / receive 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 a receiving wireless transmit / receive 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 an example, the Tx WTRU may 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 be higher than a resource threshold (e.g., the first resource threshold). The Tx WTRU can select one or more (re)transmit resources. The selected one or more (re)transmit resources may come 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 can be transmitted for one or more selected (re)transmission resources, and the TxWTRU can transmit data in one or more selected (re)transmission resources.

[0399] A Tx WTRU can select resources for transmission, such as to another WTRU, which can be an RxWTRU (e.g., a DRX Rx WTRU). The 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 includes at least a certain number of active slots for Rx WTRUs (e.g., a (pre-)configured number of active slots for Rx WTRUs). If the Tx WTRU cannot find a trigger time that satisfies the condition that the number of active slots for Rx WTRUs within the resource selection window is greater than a threshold, the Tx WTRU can discard the transport block (TB) and / or select another resource pool for transmitting the TB.

[0400] The Tx WTRU can select a set of candidate time slots. The Tx WTRU can select a set of candidate time slots within a resource selection window. The set of candidate time slots can include at least a certain number of active time slots of the Rx WTRU (e.g., a (pre-)configured number of active time slots of the Rx WTRU). This number of active time slots of the Rx WTRU can, for example, be located at the beginning of the candidate time slot set in time.

[0401] A Tx WTRU may determine the set of selectable resources, for example, by excluding unavailable resources. If the number of selectable resources in the active slot set of the Rx WTRU is less than a threshold (e.g., a (pre)configured threshold) and / or the percentage of selectable resources in the candidate slot set is less than a threshold (e.g., another threshold), the Tx WTRU may increase the number of selectable resources. For example, if the number of selectable resources in the active slot set of the Rx WTRU is less than a threshold (e.g., a (pre)configured threshold) and / or the percentage of selectable resources in the candidate slot set is less than a threshold (e.g., another threshold), the Tx WTRU may increase its Reference Signal Received Power (RSRP) threshold (e.g., to determine the availability of resources in the candidate slot set).

[0402] The Tx WTRU can select transport resources from a set of selectable resources for transmitting a Transport Block (TB). The transport resources can be those available during 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 use the selected set of transport resources to perform the transmission of the TB.

[0403] The Tx WTRU performs congestion control in DRX. The Tx WTRU can perform CBR_drx measurements to determine the congestion level of resources associated with the DRX configuration of the Tx WTRU or the DRX configuration of the Rx WTRU of the TB. The Tx WTRU can determine a set of permissible resource selection trigger times (e.g., a set of values ​​for n) based on one or more of the following: the TB's Quality of Service (QoS), CBR_drx, or the channel busy rate (CBR) of the resource pool. The Tx WTRU can select (e.g., randomly select) a resource selection trigger time within the permissible set.

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

[0405] 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.

[0406] While the specific implementations described herein may consider 3GPP-specific protocols, it should be understood that these implementations are not limited to this scenario and are applicable to other wireless systems. For example, although the solutions described herein consider LTE, LTE-A, New Radio (NR), or 5G-specific protocols, it should be understood that the solutions described herein are not limited to this scenario and are also applicable to other wireless systems. For example, although the system has been described with reference to 3GPP, 5G, and / or NR network layers, the contemplated implementations extend beyond implementations using specific network layer technologies. Similarly, potential implementations extend to all types of service layer architectures, systems, and implementations. The technologies described herein can be applied independently and / or in combination with other resource configuration technologies.

[0407] The processes described herein may be implemented in computer programs, software, and / or firmware incorporated in a computer-readable medium for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via wired 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, magnetic media (such as, but not limited to, internal hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and / or digital versatile optical discs (DVDs)). The processor associated with the software may be used to implement a radio frequency transceiver for WTRUs, terminals, base stations, RNCs, and / or any host computer.

[0408] It should be understood that the entity performing the processes described herein can be a logical entity capable of being implemented in the form of software (e.g., computer-executable instructions) stored in the memory of a mobile device, network node, or computer system and executed on its processor. That is, the process can be implemented in the form of software (e.g., computer-executable instructions) stored in the memory of a mobile device and / or network node (such as a node or computer system), which executes the process in question when executed by the node's processor. It should also be understood that any of the transmit and receive processes shown in the figures can be executed via the node's communication circuitry under the control of the node's processor and the computer-executable instructions (e.g., software) executing thereon.

[0409] The various techniques described herein can be implemented in combination with hardware or software, or, where appropriate, in combination of both. Therefore, embodiments and apparatuses of the subject matter described herein, or certain aspects or portions thereof, may take the form of program code (e.g., instructions) embodied in a tangible medium, including any other machine-readable storage medium, wherein when the program code is loaded into and executed by a machine (such as a computer), the machine becomes an apparatus for practicing the subject matter described herein. Where program code is stored on a medium, it is possible that the program code under consideration is stored on one or more media that collectively perform the considered action; that is, the one or more media together contain code for performing the action. However, in the presence of more than one single medium, it is not required that any particular portion of the code be stored on any particular medium. In the case of program code execution on a programmable device, the computing device typically includes a processor, a storage medium readable by the processor (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device. One or more programs may implement or utilize the processes described in connection with the subject matter described herein, for example, through the use of APIs, reusable controls, etc. Such programs are preferably implemented in high-level procedural or object-oriented programming languages ​​to communicate with computer systems. However, if desired, one or more programs may be implemented in assembly or machine language. In any case, the language may be a compiled or interpreted language and may be used in conjunction with hardware implementations.

[0410] While exemplary embodiments may relate to utilizing aspects of the subject matter described herein within the context of one or more independent computing systems, the subject matter described herein is not so limited, but can be implemented in conjunction with any computing environment, such as a networked or distributed computing environment. Furthermore, aspects of the subject matter described herein can be implemented in or across multiple processing chips or devices, and can similarly affect storage across multiple devices. Such devices may include personal computers, network servers, handheld devices, supercomputers, or computers integrated into other systems, such as automobiles and aircraft.

[0411] In describing preferred embodiments of the subject matter of this disclosure as illustrated in the accompanying drawings, specific terminology has been used for clarity. However, the claimed subject matter is not intended to be limited to the specific terminology chosen so far, and it should be understood that each specific element includes all technical equivalents that operate in a similar manner to achieve a similar purpose.

Claims

1. A wireless transmit / receive unit (WTRU), the WTRU comprising: a processor configured to: receive configuration information indicating channel busy ratio (CBR) measurement information, wherein the CBR measurement information comprises a default CBR value and a measurement slot threshold; perform measurements for CBR determination within a CBR measurement window; determine a number of slots associated with the performed measurements within the CBR measurement window; select a CBR value based on whether the determined number of slots within the CBR measurement window is less than the measurement slot threshold, wherein the selected CBR value is the default CBR value if the determined number of slots within the CBR measurement window is less than the measurement slot threshold, and wherein the selected CBR value is a measured CBR value if the determined number of slots within the CBR measurement window is greater than or equal to the measurement slot threshold; determine a transmission parameter based on the selected CBR value; and transmit a transmission using the transmission parameter.

2. The WTRU of claim 1, wherein, the processor is further configured to: determine a quality of service (QoS) associated with a transmission block, wherein the CBR value is further selected based on the QoS associated with the transmission block.

3. The WTRU of claim 1, wherein, the processor is further configured to: determine whether periodic reservation is enabled for a resource pool, wherein the CBR value is further selected based on whether periodic reservation is enabled for the resource pool.

4. The WTRU of claim 1, wherein, the default CBR value is associated with a resource pool.

5. The WTRU of claim 1, wherein, the number of slots associated with the performed measurements within the CBR measurement window is determined based on one or more of whether periodic reservation is enabled, a quality of service (QoS) associated with a transmission block (TB), a hybrid automatic repeat request (HARQ) type associated with the TB, or whether sidelink discontinuous reception is enabled.

6. The WTRU of claim 1, wherein, the processor is further configured to: determine a measured CBR value, wherein the measured CBR is determined based on the determined number of slots associated with the performed measurements within the CBR measurement window.

7. The WTRU of claim 1, wherein, the transmission parameter is one or more of a number of retransmissions, a number of sub-channels for transmission, a transmission power, or a modulation and coding scheme.

8. A method comprising: receiving configuration information indicating channel busy ratio (CBR) measurement information, wherein the CBR measurement information comprises a default CBR value and a measurement slot threshold; performing measurements for CBR determination with a CBR measurement window; determining a number of slots associated with the performed measurements within the CBR measurement window; selecting a CBR value based on whether the determined number of slots within the CBR measurement window is less than the measurement slot threshold, wherein the selected CBR value is the default CBR value if the determined number of slots within the CBR measurement window is less than the measurement slot threshold, and wherein the selected CBR value is a measured CBR value if the determined number of slots within the CBR measurement window is greater than or equal to the measurement slot threshold; determining a transmission parameter based on the selected CBR value; and transmitting a transmission using the transmission parameter. transmitting a transmission using the transmission parameters.

9. The method of claim 8, wherein, The method further includes: determining a quality of service (QoS) associated with a transport block, wherein the CBR value is further selected based on the QoS associated with the transport block.

10. The method of claim 8, wherein, The method further includes: determining whether periodic reservation is enabled for a resource pool, wherein the CBR value is further selected based on whether periodic reservation is enabled for the resource pool.

11. The method of claim 8, wherein, The default CBR value is associated with a resource pool.

12. The method of claim 8, wherein, The number of slots associated with performed measurements within the CBR measurement window is determined based on one or more of: whether periodic reservation is enabled, a quality of service (QoS) associated with a transport block (TB), a hybrid automatic repeat request (HARQ) type associated with the TB, or whether sidelink discontinuous reception is enabled.

13. The method of claim 8, wherein, The method further includes: determining a measured CBR value, wherein the measured CBR is determined based on the determined number of slots associated with performed measurements within the CBR measurement window.

14. The method of claim 8, wherein, The transmission parameters are one or more of: a number of retransmissions, a number of sub-channels used for transmission, a transmission power, or a modulation and coding scheme.

Images