Methods for power-saving listening and resource allocation

Abstract

A first wireless transmit / receive unit (WTRU) can receive sidelink control information (SCI) from a second WTRU. The SCI includes first information indicating whether a resource is reserved by the second WTRU, and second information indicating whether the second WTRU is power-saving or not. The first WTRU can measure the reference signal received power (RSRP) of the signal transmitted by the second WTRU. If the first information indicates that the resource is not reserved by the second WTRU, the first WTRU can add the resource to a group of available resources. If the resource is reserved, the WTRU can set an RSRP threshold to a first setting or a second threshold based on the second WTRU's power-saving mode. If the measured RSRP is less than the selected RSRP threshold, the first WTRU can add the resource to the group of available resources.

Description

[0001] Cross-references to related applications

[0002] This application claims the benefit of the following U.S. provisional applications: No. 62 / 975,489, filed February 12, 2020; No. 63 / 061,707, filed August 5, 2020; No. 63 / 091,662, filed October 14, 2020; and No. 63 / 136,530, filed January 12, 2021, the contents of which are incorporated herein by reference. Background Technology

[0003] During vehicle-to-owner (V2X) operations, vehicle communication may include multiple wireless transmit / receive units (WTRUs) (e.g., vehicles and / or wireless devices with wireless communication capabilities) communicating directly with each other via an air interface. When within coverage area, the WTRU may receive assistance from the network to initiate the transmission and reception of V2X messages. When outside coverage area, the WTRU may use one or more pre-configured parameters to initiate the transmission and reception of V2X messages.

[0004] V2X communication is supported in, for example, Long Term Evolution (LTE) and New Radio (NR), and may include, but is not limited to, any of the following: vehicle-to-vehicle (V2V) communication, where vehicle WTRUs can communicate directly with each other; vehicle-to-infrastructure (V2I) communication, where vehicle WTRUs can communicate with roadside units (RSUs) and / or evolved Node Bs (eNBs); vehicle-to-network (V2N) communication, enabling vehicle WTRUs to communicate with the core network; and / or vehicle-to-pedestrian (V2P) communication, where vehicle WTRUs can communicate with WTRUs with special conditions (e.g., low battery capacity or low power). Summary of the Invention

[0005] The system and method can be used for power-saving listening and resource allocation in side-link (SL) communication. A first wireless transmit / receive unit (WTRU) can receive side-link control information (SCI) from a second WTRU. The SCI may include first information and second information, the first information indicating whether the resource in the resource pool is reserved by the second WTRU, and the second information indicating whether the second WTRU is a power-saving WTRU or a non-power-saving WTRU. The first WTRU is capable of measuring the reference signal received power (RSRP) of the signal transmitted by the second WTRU. The first WTRU may perform resource selection for each resource in the resource pool by adding the resource to a set of available resources if the first information indicates that the resource is not reserved by the second WTRU. For each resource in the resource pool, if the first information indicates that the resource is reserved by the second WTRU: if the second information indicates that the second WTRU is a power-saving WTRU, the WTRU may set a selected RSRP threshold or increment to a first set of RSRP thresholds or increments to determine resource availability; and if the second information indicates that the second WTRU is a non-power-saving WTRU, the first WTRU may set the selected RSRP threshold or increment to a second set of RSRP thresholds or increments to determine resource availability. If the measured RSRP is less than the selected RSRP threshold, the first WTRU may add the resource to the group of available resources. The first WTRU may select resources from the group of available resources for launch. Attached Figure Description

[0006] A more detailed understanding can be obtained from the following description given by way of example in conjunction with the accompanying drawings, wherein similar reference numerals in the drawings indicate similar elements, and wherein:

[0007] Figure 1A This is a system diagram illustrating an exemplary communication system that can be implemented in one or more of the disclosed embodiments;

[0008] Figure 1B This illustrates that, according to one implementation scheme, it is possible to Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) used within the communication system shown;

[0009] Figure 1C This illustrates that, according to one implementation scheme, it is possible to Figure 1A A system diagram of an exemplary radio access network (RAN) and an exemplary core network (CN) used within the communication system shown;

[0010] Figure 1D This illustrates that, according to one implementation scheme, it is possible to Figure 1AA system diagram of another exemplary RAN and another exemplary CN used in the communication system shown;

[0011] Figure 2 A signaling diagram illustrating an exemplary link establishment process is shown;

[0012] Figure 3 A timing diagram of an exemplary listening window and sub-windows that can be used during long-term partial listening is shown;

[0013] Figure 4 A timing diagram of an exemplary listening window and sub-windows that can be used during a short-term partial listening process is shown;

[0014] Figure 5 A timing diagram showing another example of a listening window and sub-windows that can be used during a short-term partial listening process;

[0015] Figure 6 A timing diagram is shown illustrating an exemplary process by which WTRU determines a set of resources to be monitored based on a set of reserved resources;

[0016] Figure 7 A timing diagram of an exemplary listening window, sub-window, and sub-channel that can be used in the listening process is shown;

[0017] Figure 8 A flowchart is shown of an exemplary resource allocation process that can be executed by the first WTRU to determine which resources should be used for sidelink communication;

[0018] Figure 9 A timing diagram of an exemplary resource selection process is shown;

[0019] Figure 10 A timing diagram illustrating an example of the resource selection timing process for a Transport Block (TB) is shown; and

[0020] Figure 11 The resource time of exemplary time-frequency resources for the Physical Side Link Feedback Channel (PSFCH) resource set for power-saving WTRUs and the resource set for non-power-saving WTRUs is shown. Detailed Implementation

[0021] Figure 1AThis 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 Discrete Fourier Transform Extended OFDM (ZT-UW-DFT-S-OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0022] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d (which may be vehicles), a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the 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, 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a station (STA)) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, vehicles (e.g., automobiles, self-driving / autonomous vehicles, buses, trains, bicycles, airplanes, scooters, road rollers, etc.), 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 operating on commercial and / or industrial wireless networks, etc. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as WTRUs.

[0023] 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, Internet 110, and / or other networks 112. As examples, base stations 114a and 114b may be base transceiver stations (BTS), NodeBs, evolved Node Bs (eNBs), home Node Bs, home evolved Node Bs, next-generation NodeBs such as gNode Bs (gNBs), new radio (NR) NodeBs, 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.

[0024] Base station 114a may be part of RAN 104, 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 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. Thus, in this example, base station 114a may include three transceivers, such as one transceiver per sector of the cell. In embodiments, 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.

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

[0026] 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 may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 116. 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 ​​Uplink (UL) Packet Access (HSUPA).

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

[0028] In one implementation, base station 114a and WTRUs 102a, 102b, 102c can enable radio technologies such as NR radio access, which can use NR to establish air interface 116.

[0029] 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).

[0030] 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, CDMA2000 EV-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).

[0031] 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 local areas such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for use by drones), roads, etc. In the example, 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 one implementation, 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 implementation, 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.

[0032] RAN 104 can communicate with CN 106, 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 WTRUs 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 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 and / or CN 106 can communicate directly or indirectly with other RANs that use the same RAT as RAN 104 or a different RAT. For example, in addition to being connected to RAN 104 which can utilize NR radio technology, CN 106 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0033] CN 106 may also act as a gateway for WTRUs 102a, 102b, 102c, and 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The 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 or a different RAT.

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

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

[0036] 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), 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.

[0037] 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 both 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.

[0038] 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. Thus, in this example, 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.

[0039] 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).

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

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

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

[0043] 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. Sensors 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, humidity sensors, etc.

[0044] 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 DL (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 DL ​​(e.g., for reception)) are concurrent.

[0045] Figure 1C This is a system diagram illustrating RAN 104 and CN 106 according to one embodiment. As described 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.

[0046] RAN 104 may include evolved Nodes B 160a, 160b, and 160c; however, it should be understood that RAN 104 may include any number of evolved Nodes B while remaining consistent with the implementation scheme. Evolved Nodes B 160a, 160b, and 160c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In this example, evolved Nodes B 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.

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

[0048] 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 (PGW) 166. Although the foregoing elements are 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.

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

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

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

[0052] 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. Additionally, 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.

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

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

[0055] A WLAN in 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 access or interfaces to a distribution system (DS) or to another type of wired / wireless network carrying services to and / or carrying services away from the BSS. Services originating outside the BSS and destined for a STA can be delivered to the STA via the AP. Services originating from a STA and destined for an external BSS destination can be sent to the AP for delivery to the appropriate destination. Services between STAs within the BSS can be sent via the AP, for example, where a source STA can send services to the AP, and the AP can deliver the services to the destination STA. Services between STAs within the BSS can be considered and / or referred to as point-to-point services. Point-to-point services 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.

[0056] 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 configured. 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, Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) can be implemented, for example, in an 802.11 system. 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.

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

[0058] 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).

[0059] 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 communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including supporting (e.g., only supporting) 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).

[0060] WLAN systems supporting multiple channels, and 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, all available frequency bands can be considered busy even if most available bands remain idle.

[0061] In the United States, the available frequency bands for 802.11ah are 902MHz to 928MHz. In South Korea, the available frequency bands are 917.5MHz to 923.5MHz. In Japan, the available frequency bands are 916.5MHz to 927.5MHz. The total available bandwidth for 802.11ah ranges from 6MHz to 26MHz, depending on the country code.

[0062] Figure 1D 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 NR radio technology. RAN 104 can also communicate with CN 106.

[0063] RAN 104 may include gNBs 180a, 180b, and 180c; however, it should be understood that RAN 104 may include any number of gNBs while remaining consistent with the implementation scheme. 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 this example, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to 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 scheme, gNBs 180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers can be on unlicensed spectrum, while the remaining component carriers can be on licensed spectrum. In the implementation scheme, gNBs 180a, 180b, and 180c can implement Cooperative Multipoint (CoMP) technology. For example, WTRU 102a can receive cooperative transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0064] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with an scalable set of parameters. 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).

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

[0066] 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, interoperability between DC, 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.

[0067] Figure 1D The CN 106 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 Data Network (DN) 185a, 185b. Although the foregoing elements are depicted as part of CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0068] AMF 182a and 182b can connect to one or more of gNBs 180a, 180b, and 180c via the N2 interface in RAN 104 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 Protocol Data Unit (PDU) sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating Non-Access Stratum (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, and services for MTC access. AMF 182a and 182b can provide control plane functions for handover between RAN 104 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.

[0069] SMF 183a and 183b can connect to AMF 182a and 182b in CN 106 via the N11 interface. SMF 183a and 183b can also connect to UPF 184a and 184b in CN 106 via the N4 interface. SMF 183a and 183b can select and control UPF 184a and 184b, and configure service routing through UPF 184a and 184b. SMF 183a and 183b can perform other functions, such as managing and allocating WTRU IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing DL data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0070] UPF 184a and 184b can connect via the N3 interface to one or more of the gNBs 180a, 180b, and 180c in RAN 104. 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, 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 DL packets, and providing mobility anchoring.

[0071] CN 106 may facilitate communication with other networks. 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 may communicate with such an IP gateway. Additionally, CN 106 may provide WTRU 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 this example, WTRU 102a, 102b, and 102c may be connected to DN 185a and 185b via UPF 184a and 184b through the N3 interface to UPF 184a and 184b and the N6 interface between UPF 184a and 184b and local DN 185a and 185b.

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

[0073] 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 use over-the-air wireless communication to perform tests.

[0074] 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 RF circuitry (e.g., which may include one or more antennas) may be used by the simulation devices to transmit and / or receive data.

[0075] The new radio (NR) system currently under development by 3GPP is expected to support a variety of use cases, such as enhanced mobile broadband (eMBB), ultra-reliable and low-latency communications (URLLC). Support for enhanced vehicle-to-everything (eV2X) communications is under development for the NR system. eV2X in NR can support new services for both safe and unsafe scenarios, including but not limited to sensor sharing, autonomous driving, vehicle platooning, and remote driving. Different eV2X services may require different performance requirements and / or time delays (e.g., 3ms latency).

[0076] NR V2X enables new use cases, including but not limited to vehicle platooning, advanced driving, extended sensors, and remote driving. Vehicle platooning allows vehicles to dynamically form groups to travel together. Two or more vehicles in a given platoon (e.g., all vehicles) can receive periodic data from the lead vehicle for platooning operations. This data allows the distance between vehicles (gap distance) to become extremely small, so that the gap distance converted to time can be very low (e.g., sub-second). Placing applications can allow vehicles in a platoon to drive autonomously. Advanced driving enables semi-autonomous or fully autonomous driving. Longer distances between vehicles can be assumed. Each vehicle and / or roadside unit (RSU) can share data obtained from its local sensors with approaching vehicles, allowing vehicles to coordinate their trajectories or activities. Furthermore, each vehicle can share its driving intentions with approaching vehicles. Such use groups can provide safer travel, conflict avoidance, and improved traffic efficiency.

[0077] Extended sensors enable the exchange of raw or processed data collected via local sensors, or real-time video data between, for example, vehicles, WTRUs, RSUs, pedestrian devices, and / or V2X application servers. Vehicles can enhance their awareness of their environment beyond the range of their own sensors and gain a more comprehensive understanding of the local environment based on sensor data collected for various devices. Remote driving enables remote drivers or V2X applications to operate remote vehicles (e.g., for passengers who cannot drive themselves) or remote vehicles in hazardous environments. Cloud-based driving can be used in situations with limited variation and predictable routes, such as public transportation. In the example, access to a cloud-based backend service platform can be used to remove driving.

[0078] In the examples described herein, the terms vehicle, WTRU, RSU, UE, and pedestrian equipment are used interchangeably. For example, as used herein, WTRU may refer to a portable wireless device mounted on or integrated into a vehicle (a vehicle with wireless communication capabilities) or a portable wireless device carried by a pedestrian. WTRU may refer to a pedestrian user equipment (PUE) and may be referred to as a power-saving WTRU. WTRU may refer to a vehicle user equipment (VUE) and may be referred to as a vehicle WTRU. In some examples, a vehicle WTRU (VUE) may be a non-power-saving device that is less restricted in terms of available power compared to a power-saving WTRU (such as a pedestrian-carried mobile device (e.g., PUE)).

[0079] This can describe the QoS model for NR V2X. QoS on LTE-V2X air interfaces (such as the PC5 interface) can be supported by ProSe Per-Packet Priority (PPPP). Application layers can be allowed to label packets with PPPP, which indicates the desired QoS level. Certain enhancements can be added, such as allowing the packet delay budget (PDB) to be derived from PPPP.

[0080] Examples of key performance indicators (KPIs) for NR V2X may include payload (e.g., bytes), transmit rate (e.g., messages / second), maximum end-to-end latency (e.g., ms), reliability (%), data rate (e.g., Mbps), and / or minimum required communication range (e.g., meters).

[0081] The same set of service requirements (or different service requirements) can be applied to both PC5-based V2X communication and Uu-based V2X communication. These QoS characteristics can be represented using the 5G QoS identifier (5QI). In the example, a unified QoS model can be used for both the PC5 and Uu interfaces, making 5QI available for V2X communication over PC5 and allowing the application layer to consistently indicate QoS requirements regardless of the link used.

[0082] In the example, a WTRU (including vehicles) supporting 5G / NR V2X can utilize one or more of the following service types: broadcast, multicast, and / or unicast. For unicast services, the same QoS model as Uu can be used, allowing each unicast link to be treated as a bearer and associated with a QoS flow separately. Additional parameters for QoS characteristics and / or data rates defined in 5QI can be applied. In the example, the minimum required communication range can be considered as an additional parameter used by PC5. Similar considerations may apply to multicast services, as it can be considered a special case of unicast (e.g., with multiple defined service receivers). For broadcast services, there may be no bearer concept. In this case, each message may have different characteristics depending on the given application requirements. 5QI can be used in a manner similar to PPPP and / or ProSe per-packet reliability (PPPR) (e.g., to label each packet). 5QI can represent the characteristics required for PC5 broadcast operations (e.g., latency, priority, and / or reliability). A set of V2X broadcast-specific 5QIs (e.g., called VQIs) can be defined for PC5 use.

[0083] In the example, PC5 QoS parameters can be negotiated during the establishment of a one-to-one communication process, which can be enhanced to support PC5 QoS parameter negotiation between two WTRUs. Following the PC5 QoS parameter negotiation process, the same QoS can be used in both directions. Figure 2 A signaling diagram of an exemplary link establishment process 200 is shown, which can be used to establish a secure communication link, such as a Layer 2 (L2) link, on a PC5 interface. Figure 2 As shown, WTRU 201 and WTRU 202 can communicate one-to-one via a direct air interface such as a PC5 interface, and can negotiate PC5 QoS parameters during link establishment procedure 200. For example, WTRU 201 can send a direct communication request message 204 to WTRU 202 to trigger a mutual authentication procedure 206 between WTRU 201 and 202. The direct communication request message 204 may include (e.g., the requested) PC5 QoS parameters. WTRU 202 can initiate the mutual authentication procedure 206. For example, WTRU 202 can send a response message (not shown) to WTRU 201 as part of the mutual authentication procedure 206, and may include the accepted PC5 QoS parameters in the response message sent back to WTRU 201.

[0084] According to the NR V2X service model, NR V2X can support, but is not limited to, one or more of the following service types: periodic and aperiodic. NR V2X can support additional different types of packet sizes, packet arrival rates, and / or latency requirements. For example, Mode 2 aperiodic service can support packet sizes between approximately 10,000 and 30,000 bytes, an average arrival rate of approximately 20 ms, and / or a latency requirement of approximately 10 ms. In another example, Mode 3 periodic service can support packet sizes between approximately 30,000 and 60,000 bytes, an average arrival rate of approximately 30 ms, and / or a latency requirement of approximately 30 ms.

[0085] Partial listening and / or random selection can be used as a power-saving mechanism in LTE V2X (e.g., for use by a pedestrian WTRU). In the case of partial listening, the WTRU can be configured by an upper layer with a minimum number of candidate subframes in a resource selection window [T1, T2], where specific subframes can be selected by the WTRU implementation. The WTRU can perform listening only on subframes within an integer number of reserved periods from the candidate subframes in the listening window, thereby reducing the amount of resources the WTRU needs to perform listening in the listening window. Another implementation of the pedestrian WTRU can be random selection of a resource pool. If the resource pool is configured for random selection, the WTRU can perform resource selection regardless of any listening results during the listening process.

[0086] Discontinuous Receive (DRX) can be used via the NR Uu interface. A connection mode DRX can be specified for power saving in the NR Uu of a WTRU in RRC_CONNECTED. DRX can be scheduled based on the wake-up time configuration at the WTRU. If the WTRU receives a Physical Downlink Control Channel (PDCCH) schedule during its wake-up time, it can remain awake for a period until no further schedule is received. The WTRU can be configured with parameters, including but not limited to any of the following exemplary parameters: drx-onDurationTimer: the duration at the start of the DRX cycle; drx-SlotOffset: the delay before starting drx-onDurationTimer; drx-InactivityTimer: the duration after which the PDCCH indicates the timing of a new uplink (UL) or downlink (DL) transmission for a Media Access Control (MAC) entity; drx-RetransmissionTimerDL (by DL Hybrid Automatic Repeat Request (HARQ) process, which may or may not include a broadcast process): the maximum duration until a DL retransmission is received; drx-RetransmissionTimerUL (by UL) HARQ process: The maximum duration until an authorization for UL retransmission is received; drx-LongCycleStartOffset: Long DRX cycle; drx-StartOffset: The subframe at the start of the long and short DRX cycles; drx-ShortCycle: Short DRX cycle; drx-ShortCycleTimer: The duration for which the WTRU should follow the short DRX cycle; drx-HARQ-RTT-TimerDL (per DL HARQ process, which may or may not include the broadcast process): The minimum duration before the MAC entity anticipates a DL assignment for HARQ retransmission; and / or drx-HARQ-RTT-TimerUL (per UL HARQ process): The minimum duration before the MAC entity anticipates an authorization for UL HARQ retransmission.

[0087] A WTRU configured with DRX can determine its active time (e.g., the time during which the WTRU actively monitors the PDCCH), such that when DRX is configured for cyclical operation, the active time may include: the duration of time a timer (e.g., drx-onDurationTimer, drx-InactivityTimer, drx-RetransmissionTimerDL, drx-RetransmissionTimerUL, and / or ra-ContentionResolutionTimer) runs; the time or duration of sending a scheduling request on the PUCCH and waiting; and / or the time or duration of not receiving a newly transmitted PDCCH signal or message indicating a C-RNTI addressed to the MAC entity after successfully receiving a random access response message with no preamble selected by the MAC entity.

[0088] Long-term partial listening and short-term listening can be implemented based on the topics disclosed herein. NR V2X supports both periodic and non-periodic services. When semi-persistent resource reservation is enabled, long-term partial listening (e.g., in LTE V2X) can be used to avoid conflicts with periodic services. However, long-term partial listening may not detect reservations for dynamically allocated resources. Furthermore, semi-persistent resource reservation can be enabled / disabled in resource pools. Therefore, long-term partial listening may not be used in resource pools where semi-persistence is disabled.

[0089] To reduce resource conflicts in dynamic resource allocation, the WTRU may need to perform short-term listening, which can be performed immediately before the WTRU is launched. Additionally, to conserve power, partial listening can be used within the short-term listening window. Power-saving listening and resource selection can take into account the interaction between long-term and short-term partial listening.

[0090] In LTE V2X, it is expected that the power-saving WTRU (also known as the power-saving user equipment (PUE)) will use the same resource pool as non-power-saving devices, such as the vehicle WTRU (also known as the vehicle user equipment (VUE)) of a non-power-saving device. The power-saving WTRU can be configured in a large resource pool to perform listening. Performing listening in all sub-channels configured in the resource pool can result in listening overhead and power inefficiency. Therefore, in this example, the power-saving WTRU may selectively select a set of sub-channels from the resource pool to monitor and perform listening to save power. In this case, listening adaptation in the frequency domain can be used.

[0091] This document discloses techniques for sidelink power saving including power listening. In the example, the WTRU can perform long-term partial listening within one or more listening sub-windows. For example, the WTRU can monitor the semi-persistent reservations of other WTRUs. Within a long-term listening window, the WTRU can partially perform listening in K time slots of each sub-window listening of X time slots, where K ≤ X. The WTRU can perform resource selection within K time slots of a resource selection sub-window of X time slots. The resource selection sub-windows, the time intervals between each listening sub-window, and / or the number of sub-window listening occurrences can be configured or pre-configured.

[0092] Figure 3 A timing diagram of an exemplary listening window and sub-windows that can be used by WTRU 301 in a long-term partial listening process 300 is shown. During the long-term partial listening window 302, WTRU 301 may perform partial listening on K time slots in each of X time slots in sub-windows 304 before selecting resources during resource selection window 306, for example, to monitor and determine the semi-persistent reservations of other WTRUs. Resource selection window 306 starts at time T1 and ends at time T2. The time gap between the first sub-window 304 in the long-term partial listening window 302 and the resource selection sub-window 308 is j*P, where the values ​​of j and P can be (pre-)configured. Other sub-windows 304 may have time gaps to the resource selection sub-window 308 that are multiples of P (e.g., P, 2P). WTRU 301 can trigger resource allocation at time n and before the start of resource selection window 306 at time T1, and can select resources for communication from a set of K selectable time slots 320 during resource selection sub-window 308. WTRU 301 can determine the values ​​of X and / or K based on one or more of the following: the bandwidth of the resource pool; the number of sub-channels that WTRU 301 performs listening in each time slot; the QoS or sidelink radio bearer (SLRB) / logical channel (LCH) associated with the pending transport block (TB) or expected TB; the broadcast type of the pending TB (e.g., unicast, multicast, or broadcast); the channel busy rate (CBR) of the resource pool; the HARQ type of the TB; and / or the power saving mode or state of WTRU 301. Detailed examples of the selection parameters X and K are described below.

[0093] For example, the values ​​of X and / or K can be determined based on the bandwidth of the resource pool and / or the number of sub-channels that the WTRU performs listening in each time slot. For instance, the WTRU can determine the value of K based on the number of sub-channels used for listening. If the number of sub-channels used for listening is large, the WTRU can choose a smaller K value, and if the number of sub-channels used for listening is small, a larger K value can be chosen. This approach can be incentivized to ensure that the WTRU can select sufficient available resources for resource selection. Alternatively, the values ​​of X and / or K can be determined based on the QoS or SLRB / LCH associated with the pending TB or the expected TB. For example, the WTRU can determine larger K and / or X values ​​when the pending TB has a high priority, and smaller K and / or W values ​​when the pending TB has a low priority.

[0094] For example, the values ​​of X and / or K can be determined based on the broadcast type of the TB to be processed (e.g., unicast, multicast, or broadcast). In one example, the WTRU may be configured with different values ​​of K and / or X based on the broadcast type. Then, the WTRU can determine the value of K based on the broadcast type of the TB. In another example, the WTRU may determine whether to perform listening or whether to use the listening results for resource selection or reselection based on the broadcast type of the TB. For example, the WTRU might perform listening on broadcast traffic instead of unicast / multicast traffic. For another example, the values ​​of X and / or K can be determined based on the CBR of the resource pool. For example, when the CBR is high, the WTRU may increase the values ​​of K and / or X, while when the CBR is low, the WTRU may decrease the values ​​of K and / or X.

[0095] For example, the values ​​of X and / or K can be determined based on the HARQ type of the TB. For instance, the WTRU can be (pre-)configured with at least two sets of minimum values ​​for K and X, one set for disabling HARQ transmission and the other for enabling HARQ transmission. The WTRU can then determine the values ​​of K and X based on the HARQ type of the TB. In another example, the values ​​of X and / or K can be determined based on one or more power-saving modes / states of the WTRU. For instance, the WTRU can be (pre-configured) with a set of power-saving modes / states, and each power-saving mode / state can be associated with a partial listen configuration. A partial listen configuration can include the minimum amount of resources (e.g., a minimum number of time slots, sub-channels for listening) used to perform listening before transmission is performed. Therefore, the WTRU can determine the amount of listening resources based on the current power-saving state.

[0096] In the example, the WTRU can perform short-term partial listening. A WTRU performing short-term partial listening allows it to detect dynamic reservations in a TB (Territory Block). For example, the WTRU can perform short-term partial listening after a packet arrives, after the WTRU triggers resource selection, or before the WTRU triggers resource selection. Figure 4A timing diagram of exemplary listening windows and sub-windows that can be used by WTRU 401 in short-term partial listening process 400 is shown. In addition to long-term partial listening window 402 and listening sub-window 404, as... Figure 4 As shown in the example, WTRU 401 may be able to perform short-term partial listening using the set (subset) of listening slots 412 during a short-term partial listening window 410. The short-term partial listening window 410 may begin after WTRU 401 triggers resource allocation at time n. The short-term partial listening window 410 may end before the start of a resource selection sub-window 408 (which may include a set of K optional slots 420), and may end after (or, not shown, before) the start time T1 of a resource selection window 406 as shown.

[0097] Figure 5 A timing diagram showing another example of a listening window and sub-windows that can be used by WTRU 501 in a short-term partial listening process 500 is illustrated. Although not shown, Figure 5 This can include a long-term listening window and listening sub-windows. For example... Figure 5 As shown in the example, WTRU 501 may be able to perform short-term partial listening using a set (subset) of listening slots 512 during a short-term partial listening window 510. The short-term partial listening window 510 may occur before WTRU 501 triggers resource allocation at time n. The short-term partial listening window 510 may end before the start of resource selection window 506 and before the start of resource selection sub-window 508 (which may include a set of K optional slots 520). In the example, WTRU 501 may perform short-term partial listening after it triggers resource selection for non-periodic services and before it triggers resource selection for periodic services. Figure 4 and Figure 5 In the exemplary case shown, the short-term partial listening window can be determined based on one or more of the following criteria: the time interval between the packet arrival time and the first optional time slot in the resource selection sub-window; the QoS or SLRB / LCH of the pending TB or the expected TB; and / or whether the WTRU performs long-term partial listening.

[0098] In the example, the short-term partial listener window can be determined based on the time gap between the packet arrival time and the first optional time slot in the resource selection sub-window. For example, if the time gap is less than a threshold W, the short-term partial listener window is less than W. If the time gap is greater than the threshold, the short-term partial listener window can be equal to W. The value of W can be fixed or (pre-)configured by the network.

[0099] In the example, the short-term partial listener window can be determined based on the QoS or SLRB / LCH of the TB to be processed or the expected TB. In the example, the WTRU can be configured with multiple minimum short-term partial listener windows, each of which can be associated with one or more priorities of the TB. The WTRU can determine the size of the short-term partial listener window based on the QoS of the TB to be processed. For example, the WTRU can use a smaller short-term partial listener window for low-priority TBs and a larger short-term partial listener window for high-priority TBs.

[0100] In the example, if the WTRU performs long partial listening, it may perform short partial listening over a set of time slots between the resource selection trigger and the first candidate resource selection time slot. In another example, if the WTRU does not perform long partial listening, it may perform short partial listening according to a (pre-)configured listening window. This (pre-configured) short partial listening window may be associated with the QoS of the TB, or it may be fixed at X time slots (e.g., 32 time slots).

[0101] In the example, the WTRU may determine a set of time slots within a short-term partial listening window to perform listening. This set of time slots may be determined based on one or more of the following criteria: configuration / pre-configuration; QoS or SLRB / LCH associated with the TB; CBR of the resource pool; whether resource (re)evaluation of the TB is enabled or disabled; HARQ type of the TB (e.g., TBs with HARQ enabled and HARQ disabled); broadcast type of the TB (e.g., broadcast, unicast, or multicast); number of candidate time slots and / or number of candidate resources within a period; DRX status of the WTRU; whether the WTRU performs resource selection for initial selection, (re)evaluation of selected resources, or (re)evaluation of reserved resources; and / or whether semi-persistence is enabled / disabled in the resource pool.

[0102] In the example, the group of time slots can be determined based on configuration / pre-configuration. For example, the WTRU can configure / pre-configure a set of time slots between each available time slot and the time slots to be listened to in the resource selection sub-window. In the example, the group of time slots can be determined based on QoS or SLRB / LCH associated with the TB. For example, the WTRU can configure / pre-configure a minimum number of time slots to be listened to in the short-term partial listening window. The WTRU can then select the group of time slots to perform listening if the number of time slots listened to is greater than the configured / pre-configured threshold. The WTRU can select the group of time slots at the beginning / end of the short-term listening window, or it can select the group of time slots randomly.

[0103] In the example, the group of time slots can be determined based on the resource pool's CBR. In one example, if the resource pool's CBR is greater than a threshold, the WTRU can perform short-term partial listening, and if the resource pool's CBR is less than the threshold, short-term partial listening can be omitted. In another example, the WTRU can determine the short-term partial listening window based on the resource pool's CBR. For example, the WTRU can configure / pre-configure the short-term listening window for each CBR range. Then, the WTRU can determine the actual short-term partial listening window based on the measured CBR of the resource pool.

[0104] In the example, the group of time slots can be determined based on whether resource (re)evaluation TB is enabled / disabled. For example, the WTRU can determine the short-term listening window size based on whether resource (re)evaluation TB is enabled / disabled. For example, when resource (re)evaluation is enabled, the WTRU can be (pre-)configured with one short-term listening window, and when resource (re)evaluation is disabled, the WTRU can be (pre-configured) with another short-term listening window. The short-term listening window can be further determined based on the QoS of the TB and / or the CBR of the resource pool. Then, the WTRU can determine the short-term listening window based on whether resource (re)evaluation is enabled / disabled.

[0105] In the example, the group of slots can be determined based on the HARQ type of the TB (e.g., TBs with HARQ enabled and TBs with HARQ disabled). In the example, the group of slots can be determined based on the broadcast type of the TB (e.g., broadcast, unicast, or multicast). In the example, the group of slots can be determined based on the number of candidate slots and / or the number of candidate resources within a period. For example, the WTRU can determine a short-term listener window based on the number of candidate slots in a period (e.g., the period from packet arrival time to PDB). For example, if the number of candidate resources is less than the minimum required number of candidate slots, the WTRU may not perform a short-term listener. If the number of candidate slots is greater than the minimum required candidate resources, the WTRU may initiate a short-term listener when a packet arrives until the number of candidate resources equals the minimum required number and / or the short-term listener window is greater than or equal to the minimum required short-term listener window.

[0106] In the example, the group of time slots can be determined based on the DRX status of the WTRU. For example, the DRX status of the WTRU can include any one or more of the following: whether DRX is configured; and / or whether the WTRU is in an on or off duration. In the example, the group of time slots can be determined based on the WTRU's power-saving mode. In the example, the group of time slots can be determined based on whether the WTRU is performing resource selection for initial selection, (re)evaluation of the selected resource, or (re)evaluation of the reserved resource. For example, the WTRU may be (pre-)configured with three minimum short-term listen windows for initial resource selection, (re)evaluation of the selected resource, and / or (re)evaluation of the reserved resource. The WTRU can accordingly determine the short-term listen for initial selection, (re)evaluation of the selected resource, and / or (re)evaluation of the reserved resource. In the example, the group of time slots can be determined based on whether semi-persistence is enabled / disabled in the resource pool.

[0107] In the example, the WTRU may determine the trigger for listening (e.g., long-term partial listening and / or short-term partial listening) based on one or more of the following criteria: when / whether a packet arrives at the access layer (AS); the value of a counter associated with resource selection / reselection reaches a threshold; the arrival of p periodic traffic; and / or the WTRU determines to perform a resource reassessment on semi-persistent reserved resources.

[0108] In the example, when a packet arrives at the AS layer and the WTRU needs to perform resource selection / reselection on the packet, the WTRU may trigger a short partial listener. Alternatively, the WTRU may trigger a short partial listener for W time slots only before the resource selection window or a resource selection sub-window. The value of W may be determined based on one or more pre-configurations of the network (e.g., the minimum duration of the short partial listener may be configured / pre-configured by the WTRU before the resource reselection window), the QoS of the pending or expected TB, and / or the CBR of the resource pool.

[0109] In the example, the WTRU can trigger a listener when the resource selection / reselection counter is below a threshold. For instance, the WTRU can maintain resource selection / reselection counters for one or more sidelink procedures. If the counter reaches zero, the WTRU can perform a resource selection / reselection on that sidelink procedure. Then, when the counter is below the threshold, the WTRU can determine to perform a long-term partial listener. This approach can be triggered to ensure that the WTRU has sufficient listener data when a resource selection / reselection needs to be performed.

[0110] In the example, the WTRU can trigger long-term partial listening in response to the arrival of periodic traffic. The WTRU can use random resource selection and / or short-term listening-based resource selection for the first N periods of the periodic traffic. The value of N can be based on the periodicity of the periodic traffic and / or a (pre-)configured long-term listening period. The WTRU can then use long-term partial listening and / or short-term partial listening to perform resource selection for the next period when the long-term partial listening result is available.

[0111] In the example, the WTRU can trigger a long-term partial listener for resource reassessment of semi-persistently reserved resources. For example, the WTRU can perform a long-term partial listener to determine the availability of semi-persistently reserved resources. Prior to a resource reassessment event, the WTRU can determine to perform a long-term partial listener to collect the listening results of the resource reassessment event. In the example, the WTRU can perform a short-term partial listener based on one or more of the following: configuration / pre-configuration (e.g., the WTRU can perform a short-term partial listener only if semi-persistent reservation is disabled in the resource pool), the QoS of the pending or expected TB, the type of service (e.g., unicast / multicast / broadcast, or periodic / aperiodic service), the HARQ retransmission type of the TB, and / or whether the WTRU performs semi-persistent reservation for the TB. In the example, the WTRU can perform long-term partial listening or short-term partial listening based on the HARQ retransmission type of the TB, or perform both listening procedures (e.g., HARQ feedback-based retransmission, blind retransmission, or a mixture of HARQ feedback-based retransmission and blind retransmission). For example, the WTRU can perform short-term partial listening only on resource selection for TBs with HARQ feedback-based retransmission, and it can perform both short-term and long-term partial listening on resource selection for TBs with blind retransmission.

[0112] In the example, the WTRU may perform short-term partial listening only for resource allocations without semi-persistent reservations (e.g., resource allocations for non-periodic services, or resource allocations for periodic services in resource pools where semi-persistent reservations are disabled). In this example, the WTRU may perform short-term partial listening only if the priority of the TB is above a threshold. This implementation allows the WTRU to reduce conflicts with high-priority TBs. In another example, the WTRU may perform short-term partial listening only if the priority of the TB is below a threshold; otherwise, it may perform both short-term and long-term partial listening.

[0113] In one example, the WTRU may perform long-term partial listening only when the WTRU makes a resource selection with semi-persistent reservations. In another example, the WTRU may perform long-term partial listening only when the priority of the pending TB or the expected TB is less than / greater than a threshold.

[0114] In one example, when the WTRU performs resource selection with semi-persistent reservations, it can perform both long-term partial listening and short-term partial listening. In another example, when the priority of the TB is greater than a threshold, the WTRU can perform both long-term partial listening and short-term partial listening. This implementation reduces the probability of collisions with high-priority TBs. In yet another example, when the size of the TB is greater than a threshold or the number of sub-channels used to transmit the TB is less than a threshold, the WTRU can perform both long-term and short-term partial listening.

[0115] In the example, the WTRU may determine the set of time slots and / or sub-channels for performing listening and / or resource allocation based on one or more of the following: configuration / pre-configuration, QoS or SLRB / LCH associated with the TB to be processed or the expected TB, the size of the TB to be processed or the expected TB, the size of the listening window and / or the number of time slots listened to in the listening window, the CBR of the resource pool, the channel occupancy (CR) of the WTRU, the location of the WTRU, random selection, listening results, resource assessment results, the reserved resources of the group, the transmission activity of the WTRU, and / or the listening type (e.g., short-term listening or long-term listening).

[0116] The WTRU can determine the set of sub-channels and / or time slots to be listened to based on configuration / pre-configuration. For example, the WTRU can configure / pre-configure a minimum number of sub-channels and / or time slots to perform listening and / or resource allocation. The WTRU can select a number of sub-channels and / or time slots for listening and / or resource selection that is greater than or equal to the minimum configured value.

[0117] The WTRU can be configured with different minimum listening bandwidths and / or different numbers of listening slots based on the priority or SLRB / LCH associated with the TB to be processed or the expected TB. The WTRU can then determine the number of listening bandwidths and / or listening slots based on the priority of the TB to be processed or the expected TB.

[0118] The WTRU can determine the listening bandwidth based on the size of the pending or expected TB. For example, if the size of the pending or expected TB is greater than a threshold, the WTRU can perform listening in one listening bandwidth, and if the size of the pending or expected TB is greater than the threshold, it can determine to perform listening in another listening bandwidth. This threshold can be determined by the WTRU, or it can be configured / pre-configured by the network per resource pool.

[0119] For example, the WTRU can be configured / pre-configured with a minimum number of resources to listen within a listening window. The WTRU can determine the number of time slots and the number of sub-channels in each listened time slot to perform listening, ensuring that the total number of resources to be listened to is greater than the configured / pre-configured value. Then, the WTRU can determine the number of sub-channels to perform listening based on the number of time slots listened to within the listening window.

[0120] The WTRU can determine the set of subchannels and / or time slots to be used for listening based on the CBR of the resource pool and / or the CR of the WTRU. For example, as shown in Tables 1 and 2, the WTRU can configure / pre-configure a minimum listening bandwidth and / or a minimum number of time slots to perform listening based on the CBR of the resource pool and / or the CR of the WTRU. Then, the WTRU can determine a minimum number of listening bandwidth and / or time slots to perform listening based on the measured CBR of the resource pool and / or the CR of the WTRU.

[0121] CBR Minimum listening bandwidth and / or minimum number of listening time slots CBR≤CBR1 BW1, K1 CBR1<CBR≤CBR2 BW2, K2 … CBRn-1<CBR≤CBRn BWn, Kn

[0122] Table 1: Relationship between minimum listening bandwidth configuration and CBR

[0123] CR Minimum listening bandwidth and / or minimum number of listening time slots CR≤CR1 BW1, K1 CR1<CR≤CR2 BW2, K2 … CRn-1<CR≤CRn BWn, Kn

[0124] Table 2: Relationship between minimum listening bandwidth configuration and CR

[0125] The WTRU can determine the set of sub-channels and / or time slots to be listened to based on its location. For example, the WTRU can be configured to map its location (e.g., area) to the set of listening sub-channels. The WTRU can then determine the set of listening sub-channels based on its location. In another example, the WTRU can randomly select a set of sub-channels to perform listening and resource allocation. This implementation allows the transmit resources of all WTRUs to be evenly distributed across a large resource pool.

[0126] The WTRU can determine the group of subchannels and / or time slots to be monitored based on its listening results. In one example, if the amount of reserved resources in the group of monitoring / listening time slots is greater than a threshold, the WTRU can exclude any time slot in that group. In another example, if the amount of reserved resources in a group of subchannels is greater than a threshold, the WTRU can exclude that group of subchannels from all listening time slots or a subset of listening time slots. The WTRU can stop monitoring a group of subchannels by not decoding the Side Link Control Information (SCI) in these subchannels and / or not using the listening results obtained from these subchannels for the resource reassessment process. These implementations can help the WTRU save power because the WTRU may not need to monitor / listen in time slots that have already been reserved by other WTRUs. The WTRU can determine the duration for excluding occupied slots from the group of listening slots based on one or more of the following: configured / pre-configured settings, random selection, QoS or SLRB / LCH associated with the pending or expected TB and / or QoS of the TB associated with the occupied slot, and / or Channel Busy Rate (CBR) of the resource pool.

[0127] In the example, the WTRU can determine the duration for which it excludes an occupied time slot from the group of listening time slots based on configured / pre-configured settings. For example, the WTRU can be configured to exclude an occupied time slot from the group of monitoring / listening time slots for a fixed duration / period. In the example, the WTRU can determine the duration for which it excludes an occupied time slot from the group of listening time slots based on random selection. For example, the WTRU can randomly select time intervals (e.g., the number of time slots) to exclude an occupied time slot from the group of monitoring time slots. This time interval can be randomly selected within a range that can be configured / pre-configured by the network. In the example, the WTRU can determine the duration for which it excludes an occupied time slot from the group of listening time slots based on the QoS or SLRB / LCH associated with the pending or anticipated TB and / or the QoS of the TB associated with the occupied time slot. For example, for high-priority TBs, the WTRU can exclude the time slot from monitoring / listening for a long duration, while for low-priority TBs, the WTRU can exclude the time slot for a short duration. In the example, the WTRU can determine the duration for which it should exclude occupied time slots from the group of listening time slots based on the resource pool's CBR. For example, if the CBR is low, the WTRU can stop monitoring occupied time slots for a longer period of time, while if the resource pool's CBR is high, the WTRU can stop monitoring occupied time slots for a shorter period of time.

[0128] The WTRU can adjust a set of listening resources based on resource assessment results. For example, the WTRU can adjust the set of time slots and / or the set of sub-channels to perform listening based on the results of one or more of the resource assessment processes described herein. For example, the WTRU can increase the amount of listening resources by increasing the number of listening time slots or listening sub-channels if one or more of the following exemplary conditions are met: the amount of available resources is less than a certain threshold after the resource assessment process; and / or the RSRP threshold increases more than the (pre-)configured time. In another example, the WTRU can decrease the amount of listening resources if one or more of the following exemplary conditions are met: the WTRU reports a resource amount greater than a certain amount after the resource assessment process; and / or the RSRP threshold increases less than the (pre-)configured time.

[0129] The WTRU can determine the group of time slots and / or sub-channels based on the group of reserved resources to perform eavesdropping. For example, the WTRU can be configured / pre-configured to perform resource evaluation / re-evaluation on the reserved resources and / or the time gaps between the reserved resources and the eavesdropping time slots to determine potential conflicts between the WTRU's reserved resources and those of other WTRUs.

[0130] Figure 6 A timing diagram is shown of an exemplary process 600 in which WTRU 601 determines a set of resources to be monitored based on a set of reserved resources. Figure 6In the example, WTRU 601 may reserve resource 610 in time slot 624 for transmission in each reservation period 602. WTRU 601 may use resource 606, including subchannel 610, in listening time slot 622 to listen / monitor the reservations of other WTRU 603. WTRU 601 may perform monitoring / listening in subchannel 606 of listening resource 622, where other WTRU 603 may reserve resources for transmission in time slot 624 that conflicts with subchannel 610. This set of time slots 622 used for performing listening may have a time gap of J*P time slots prior to the reserved time slot 624 reserved for the transmission of WTRU 601.

[0131] According to another example, the WTRU may skip monitoring one or more listening sub-windows to save power. The WTRU may determine whether to skip monitoring one or more listening sub-windows based on the QoS of the TB and / or the CBR of the resource pool. For example, the WTRU may be configured / pre-configured for monitoring multiple listening sub-windows. If the priority of the TB is less than a threshold and / or the CBR of the resource pool is less than a threshold, the WTRU may skip monitoring one or more listening sub-windows. If the priority of the TB is greater than a threshold and / or the CBR of the resource is greater than a threshold, the WTRU may not skip any configured monitoring sub-windows.

[0132] In the example, the dynamic adjustment of the resources used for listening can be a function of transmission activity. The WTRU can dynamically adjust the resources on which it performs listening based on scheduling activity and / or resource usage (e.g., the WTRU's channel occupancy). While the DRX timer T is running, the WTRU can perform listening on a first set of resources or a first resource pool. When the WTRU determines that there is transmission activity, it can start or restart the DRX timer (e.g., based on listening to resources associated with the resource pool currently being used by the WTRU), and when the DRX timer expires, it can perform listening on a second set of resources or a resource pool. If the WTRU determines that the transmission is for a session configured by the WTRU (e.g., an L2 identity (ID) of interest), the WTRU can start or restart the DRX timer. If a resource pool is only used for the purpose of restarting a timer (e.g., if a transmission in one of these resource pools does not enable the WTRU to determine whether the transmission is for a session configured by the WTRU, such as a wake-up signal), the WTRU can use transmissions from another resource pool in these resource pools to make such a determination. The WTRU can also use the first resource for listening according to a fixed (e.g., configured) period.

[0133] The transition between resources on which the listening is performed can be similar to the transition between resource pools as described herein. The WTRU may determine the presence of scheduling activity based solely on the listening, based on the listening and decoding of control information, based solely on the decoding of control information, or based on its transmission, and / or whether the WTRU determines that the transmission is associated with a session configured by the WTRU.

[0134] The WTRU can determine the number of candidate time slots for listening based on transmission activity. In the example, the WTRU can determine the number of candidate time slots for listening based on transmission activity. For example, in the absence of any transmission / reception (e.g., L2ID) associated with the V2X service configured at the WTRU, the WTRU can use a first number of candidate time slots K1 for its listening process. Upon reception / transmission associated with that V2X service, the WTRU can then use a second number of candidate time slots K2 within a period associated with a timer. The WTRU can reset the timer at each reception / transmission associated with such a V2X service. The WTRU can return to using K1 candidate time slots for listening when the timer expires.

[0135] In the example, the WTRU can determine the number of candidate time slots for its listening process based on the amount of reception / transmission associated with the V2X service of interest within the most recent period or a configurable time window. For example, the WTRU can be configured / pre-configured with a time window (e.g., a time sliding window relative to the current time slot) within which the WTRU measures the amount of reception / transmission associated with the V2X service of interest (e.g., the set of L2 IDs of interest). The WTRU can be configured with a mapping between a number of reception / transmission ranges and a number of candidate time slots for listening. For example, if the amount of reception / transmission in the time window is in the range X = [x1, x2], the WTRU can use the corresponding configured number of candidate time slots K within the selection window [T1, T2].

[0136] In the example, the number of candidate time slots for transmitting / listening of the WTRU can be determined based on another parameter or aspect related to the activity behavior, which can be defined as the WTRU's DRX activity or listening activity. For example, the WTRU can be configured to have a first number of candidate time slots during the WTRU's on duration (or a certain number of time slots before or after the on duration), and a second number of candidate time slots outside its on duration (or outside that number of time slots). The on duration can correspond to the on duration of another WTRU or a group of WTRUs, and / or can be the WTRU's own on duration. In the example, the WTRU can be configured with a number of candidate time slots determined by the on duration repetition frequency (e.g., DRX cycle) at the WTRU, and the number of candidate time slots can change due to changes in the on duration frequency.

[0137] Dynamic adjustment of the listen window as a function of transmission activity is possible. For example, the WTRU can dynamically adjust its listen activity and / or its listen window based on scheduling activities and / or resource usage (e.g., within specific resources of a V2X session in a given period), which can be determined based on the WTRU's channel occupancy (CR). While the DRX timer T is running, the WTRU can use a first listen window size; when the WTRU determines that transmission activity exists, it can start or restart the timer and use a second listen window size when the timer expires.

[0138] The WTRU can determine the presence of scheduling activity based on, for example, listening (e.g., listening only), listening to and decoding control information, decoding control information only, and / or transmitting control information. The WTRU can determine that the transmission of control information is associated with a session configured for the WTRU. The WTRU may also use a first listening window size according to a fixed (e.g., configured) period.

[0139] In the example, the WTRU may determine a set of time slots and / or sub-channels to perform listening based on the listening type (e.g., short-term listening or long-term listening). For example, for short-term listening, the WTRU may perform listening on all sub-channels in the resource pool. The WTRU may perform listening on a subset of sub-channels in the resource pool. The subset of sub-channels may be determined based on sub-channels reserved for resources and / or sub-channels used for resource selection. For example, the WTRU may perform long-term listening to re-evaluate resources reserved for periodic transmission. The WTRU may then perform listening on that set of sub-channels reserved for periodic transmission. In the example, the WTRU may perform long-term listening on that set of sub-channels used for resource selection.

[0140] Figure 7An exemplary timing diagram of the listening window, sub-window, and sub-channels that can be used in a listening process 700 performed by the WTRU 701 is shown, wherein the listening process 700 includes long-term partial listening and short-term partial listening. Figure 7 In the example, WTRU 701 can perform long-term listening during one or more long-term partial listening windows / sub-windows 704 in the group of sub-channels used for resource selection, and WTRU 701 performs short-term listening during short-term partial listening windows 710 in all sub-channels of the resource pool. Figure 7 In the example, the short-term partial listening window 710 appears after WTRU 701 triggers resource allocation at time n and occurs during resource selection window 706. The short-term partial listening window 710 ends before the start of resource selection sub-window 708. The group of sub-channels in resource selection sub-window 708 is the same group of sub-channels monitored in long-term partial listening window / sub-window 704.

[0141] In the example, the WTRU can perform partial listening for preemption. The WTRU may determine that it will perform full listening for resource selection. The WTRU can perform partial listening for resource re-evaluation. The WTRU can perform partial listening for resource re-evaluation of selected resources (e.g., resources not yet reserved by SCI) and / or reserved resources (e.g., resources already reserved by SCI).

[0142] In the example, the WTRU can trigger listener adaptation by changing the set of resources to perform listenership based on one or more of the following conditions: the WTRU performs a resource evaluation / re-evaluation (e.g., after each resource allocation and reservation, the WTRU may trigger a change in the set of resources used for listenership); and / or if the CBR is greater than or less than a threshold (e.g., if the CBR is greater than and / or less than a threshold, the WTRU may trigger a change in the set of resources used for listenership). In the example, the WTRU may perform listener adaptation periodically. For example, the WTRU may periodically perform a resource evaluation to determine whether it needs to adjust the set of resources to perform listenership. If the listener adaptation criteria are met, the WTRU may change the set of resources used for listenership accordingly.

[0143] In the example, a power-saving WTRU can use a bit field in the SCI to indicate its WTRU type, listening type, and / or capacity. For example, for this bit field, one code point can be used to indicate that the WTRU is a power-saving WTRU (e.g., PUE), while another code point can be used to indicate that the WTRU is a non-power-saving WTRU (e.g., VUE).

[0144] In the example, the WTRU can differentiate between resources reserved by power-saving WTRUs and non-power-saving WTRUs during resource assessment / reassessment. The WTRU can consider WTRU type and / or power-saving type (e.g., power-saving vs. non-power-saving) differently during resource (re)assessment. In the example, the WTRU can be (pre-)configured with two sets of RSRP thresholds, where the first set of RSRP thresholds can be associated with power-saving WTRUs (e.g., PUE) and the second set of RSRP thresholds can be associated with non-power-saving WTRUs such as vehicle WTRUs (e.g., VUE). In another example, the WTRU can be (pre-configured) to apply different RSRP increment steps for resources reserved by power-saving WTRUs than for resources reserved by vehicle WTRUs (e.g., non-power-saving WTRUs). In yet another example, the WTRU can be (pre-configured) with a maximum number of different sets of RSRP increments based on the WTRU type. For example, the maximum number of the first set of RSRP increments associated with a power-saving WTRU (e.g., PUE) can be set to a first configuration value (e.g., zero or a non-zero value), and the maximum number of the second set of RSRP increments associated with a non-power-saving WTRU (e.g., VUE) can be set to a second configuration value (e.g., infinity or other values ​​that may be different from the first configuration value).

[0145] In the example, a WTRU (e.g., a PUE) can modify the QoS parameters of its TB and can indicate the modified QoS in the SCI associated with a TB transmitted by the WTRU to another WTRU. For example, a power-saving WTRU can lower the priority of data by a certain offset value and indicate the modified value in the transmitted SCI. This offset can be fixed or can be (pre-)configured based on the priority of the TB. This approach can be incentivized to help another non-power-saving WTRU (VUE) prioritize transmissions made by the power-saving WTRU and / or avoid (not use) the reserved resources of the power-saving WTRU.

[0146] Figure 8A flowchart of an exemplary resource allocation process 800, which can be performed by a first WTRU to determine which resources should be used for sidelink communication, is shown. According to the resource allocation process 800, the first WTRU may determine different threshold parameters to be used during listening based on the power-saving mode of another WTRU and / or the power-saving type of another WTRU that reserves resources. Examples of power-saving types of WTRUs include power-saving WTRUs (e.g., PUE) and non-power-saving WTRUs (e.g., VUE, vehicle WTRU). Examples of power-saving modes include WTRUs operating in a first power-saving mode and WTRUs operating in a second power-saving mode, such that operating under the first power-saving mode uses less power than operating under the second power-saving mode. In the example, a power-saving WTRU and a WTRU operating in the first power-saving mode may have similar priorities and may use the same threshold (i.e., they may be considered equivalent), and a non-power-saving WTRU and a WTRU operating in the second power-saving mode (e.g., a non-power-saving mode or a power-saving mode that uses more power compared to the first power-saving mode) may have similar priorities and may use the same threshold (i.e., they may be considered equivalent). The first WTRU may perform listening during a listening window (e.g., a long-term partial listening window, a short-term partial listening window), which may appear before or after the first WTRU triggers a resource selection.

[0147] At 802, the first WTRU can perform listening by decoding the SCI and measuring the RSRP of the transmission associated with the SCI received from the other (second) WTRU. At 804, the first WTRU can determine when it triggers resource selection. For example, the first WTRU can trigger resource selection when it has data to be transmitted to another (second) WTRU via a sidelink. Under the condition that the first WTRU triggers resource selection, at 806, the first WTRU can determine the availability of each of the multiple resources in the resource selection window by repeating the steps in 809 for each of the multiple resources allocated to the resource selection window. For example, the multiple resources could be a resource pool for transmission. For example, the resource pool for transmission could be configured / (pre-)configured at the WTRU for possible sidelink transmissions (e.g., by an eNB or by another WTRU). In the example, the resources in the resource pool could be a set of consecutive sub-channels in a time slot. At 808, for each resource, the first WTRU can determine, for example, whether the resource is reserved by the other (second) WTRU based on the last transmission of the SCI received by the first WTRU from the second WTRU. If the resource is not reserved by another (second) WTRU, then at 818, the first WTRU can add the resource to a set of available resources.

[0148] If a resource is reserved by another (second) WTRU, at 810, the first WTRU may determine whether the resource is reserved by a second WTRU for a power-saving WTRU (e.g., PUE) and / or a WTRU in power-saving mode. For example, the first WTRU may determine whether the resource is reserved by a second WTRU for a power-saving WTRU and / or a WTRU in power-saving mode by verifying an indicator of power-saving mode and / or power-saving type in an SCI received from the second WTRU or another WTRU. If the first WTRU determines that the resource is reserved by a second WTRU for a power-saving WTRU and / or a WTRU in power-saving mode, at 814, the first WTRU may apply a first set of RSRP parameters and / or RSRP increments as selected RSRP parameters and / or selected RSRP increments for determining resource availability. If the first WTRU determines that a resource is reserved for a second WTRU that is not in power-saving mode and / or is not in power-saving mode, then at 812, the first WTRU may apply a second set of RSRP parameters and / or RSRP increments as selected RSRP parameters and / or selected RSRP increments for determining resource availability. In one example, when the second WTRU is a power-saving mode WTRU, the first WTRU may be configured / pre-configured with a lower RSRP threshold, while when the second WTRU is a non-power-saving mode WTRU, the first WTRU may be configured / pre-configured with a higher RSRP threshold. Using different thresholds, the first WTRU may be able to avoid reserving resources for another WTRU selected as a power-saving mode WTRU, which can help protect the launch of the power-saving mode WTRU. RSRP parameters may include at least one RSRP threshold for determining resource usage.

[0149] At 816, the first WTRU uses an RSRP threshold from the selected RSRP parameter and determines whether the measured RSRSP of the considered resource is below the RSRP threshold. If the measured RSRSP of the resource is below the RSRP threshold, then at 818, the first WTRU adds the resource to a set of available resources. Steps 808 to 818 are repeated for all resources in the resource selection window. At 820, the first WTRU performs resource selection from the determined set of available resources (e.g., during the resource selection window).

[0150] Figure 9 A timing diagram of an exemplary resource selection (resource allocation) process 900 that can be executed by the first WTRU 901 is shown. Figure 9 The exemplary resource selection process 900 shown may correspond to Figure 8 The exemplary resource allocation process 800 shown, or any subset thereof. Reference Figure 9The first WTRU 901 may, for example, perform listening for the availability of multiple resources 904 by receiving and decoding SCI from other (second) WTRUs to determine whether any of the multiple resources 904 are reserved by any of the other (third) WTRUs. This listening may occur during listening window 902 and may occur before WTRU 901 triggers resource selection at time n. Figure 9 In the example, other WTRUs can make transmissions in all of the multiple resources 904, as determined during the listening window 902. The SCI associated with each transmission in resource 904 reserves one resource 908 in the resource selection window 906. Therefore, during the resource selection window 906, all of the multiple resources 908 can be reserved by other WTRUs and may not be used for transmission by the first WTRU 901.

[0151] In the example, the WTRU can perform CBR measurements based on the set of monitored sub-channels and time slots. The WTRU can use one or more of the following to measure CBR: long-term partial listening, short-term partial listening, or both long-term and short-term partial listening. In the example, the WTRU can use long-term partial listening to perform CBR measurements. The WTRU can measure the sidelink Received Signal Strength Indicator (RSSI) in the set of sub-channels and time slots used for long-term partial listening. The WTRU can calculate CBR as the ratio of the number of busy sub-channels to the total number of sub-channels. If the RSSI is greater than a threshold, the sub-channel is considered busy. In the example, the WTRU can use short-term partial listening to perform CBR measurements. The WTRU can measure the sidelink RSSI in the set of sub-channels and time slots used for short-term partial listening. The WTRU can calculate CBR as the ratio of the number of busy sub-channels to the total number of sub-channels. In the example, the WTRU can use both short-term and long-term partial listening to perform CBR measurements. The WTRU can measure the sidelink RSSI in the set of sub-channels and time slots used for both short-term and long-term partial listening. Then, WTRU can calculate CBR as the ratio of the number of busy subchannels to the total number of subchannels.

[0152] In the example, WTRU can determine the timing of resource selection for TB. Figure 10 A timing diagram of an example of a TB resource selection timing process 1000 that can be executed by WTRU 1001 is shown. Figure 10An example of timing parameters for the resource selection timing of the TB is shown. For example, WTRU 1001 may determine any or more of the following resource selection timing parameters that may be associated with resource selection window 1006: resource selection trigger time (i.e., timing of n); the start of the initial resource selection window 1020 (i.e., timing of n+T1); the end time of resource selection window 1020 (i.e., timing of n+T2); the timing of the first candidate time slot 1008 (i.e., timing of n+m), such that the candidate time slot can be a time slot in which the WTRU can evaluate the availability of resources for potential resource selection; and / or the timing of the last candidate time slot 1010 (i.e., timing of n+M). In the example, WTRU 1001 may determine the resource selection timing parameters in response to the arrival of TB at time T0.

[0153] In the example, the WTRU may determine one or more parameters related to the timing of resource selection for the TB (e.g., minimum / maximum values ​​of T1, T2, T2-T1, m, M, Mm, etc.) based on one or more of the following conditions: resource selection type (e.g., based on random, based on full listening, and / or based on partial listening); QoS of the TB; CBR of the resource pool and / or CR of the WTRU; timing of the first candidate slot, packet arrival time, and / or the gap between the packet arrival time and the first candidate slot; whether resources are enabled / disabled (re-) (New) Evaluation; Size of the pending or expected TB; Number of candidate time slots and / or candidate resources within a period; HARQ type of the TB (e.g., TBs with HARQ enabled and TBs with HARQ disabled); Broadcast type of the TB (e.g., broadcast, unicast, or multicast); DRX status of the WTRU; Power saving mode of the WTRU; Whether the WTRU performs resource selection for initial selection, (re)evaluation of selected resources, or (re)evaluation of reserved resources; Whether semi-persistence is enabled / disabled in the resource pool; and / or Resource selection type of the TB.

[0154] For this resource selection type, if the WTRU performs random resource selection, the WTRU may trigger resource selection for the TB upon packet arrival. The WTRU may trigger resource selection for the TB at least / at most Tx time slots before the first candidate time slot. For example, regarding enabling / disabling resource (re)evaluation, if resource (re)evaluation is enabled, the WTRU may trigger resource selection for the TB at least or at most Tx time slots before the first candidate time slot. In another example, if resource (re)evaluation is disabled, the WTRU may trigger resource selection for the TB at least or at most Ty time slots before the first candidate time slot. The values ​​of Tx and / or Ty may be (pre-)configured per resource pool based on other parameters such as the QoS of the TB, the time interval between packet arrival time and the first candidate time slot.

[0155] For the QoS of a TB, the WTRU can be (pre-)configured using the minimum / maximum values ​​(i.e., m and M) of the first and / or last candidate time slots, based on the QoS of the TB (e.g., the priority of the TB). The WTRU can then determine the values ​​of m and M accordingly based on the QoS of the TB.

[0156] For the resource pool's CBR and / or WTRU's CR, the WTRU can be (pre-)configured with multiple sets of resource selection timing parameters (e.g., minimum / maximum values ​​of T1, T2, T2-T1, m, M, Mm, etc.), where each set of parameters can be associated with a certain range of the CBR and / or a certain range of the CR. The WTRU can then determine which set of resource selection timing parameters to use based on the resource pool's CBR and / or the WTRU's CR.

[0157] For DRX, a WTRU can be (pre-configured) with multiple sets of resource selection timing parameters (e.g., minimum / maximum values ​​of T1, T2, T2-T1, m, M, Mm, etc.), where each set of parameters can be associated with a DRX state of the WTRU. In the example, when DRX is not (pre-configured), the WTRU can be (pre-configured) with one set of resource selection timing parameters, while when DRX is configured, the WTRU can be configured with another set of parameters. In the example, the WTRU can be (pre-configured) with multiple sets of resource selection timing parameters, where the first set of parameters can be used when DRX is not configured, the second set of parameters can be used when the WTRU is in the DRX-on duration, and the third set of parameters can be used when the WTRU is in the DRX-off duration.

[0158] For power-saving modes, the WTRU can be (pre-)configured with multiple power-saving modes, and in each power-saving mode, the WTRU can be (pre-configured) with a corresponding set of resource selection timing parameters. The WTRU can then determine which set of resource selection timing parameters to use based on its power-saving mode.

[0159] For each resource selection type, the WTRU can be (pre-)configured with multiple sets of resource selection timing parameters (e.g., minimum / maximum values ​​of T1, T2, T2-T1, m, M, Mm, etc.), where each set of resource selection timing parameters can be associated with a corresponding resource selection type. The WTRU can then determine the range of the CBR and / or the CR. The WTRU can then determine which set of resource selection timing parameters to use based on the resource pool's CBR and / or the WTRU's CR.

[0160] For example, given the number of candidate time slots and / or candidate resources within a period, the WTRU can determine the resource selection trigger time based on the number of candidate time slots within a period (e.g., the period from packet arrival time to PDB). For instance, if the number of candidate time slots is greater than the minimum required number, the WTRU can continue listening and triggering resource selection when the number of candidate time slots equals the minimum. Otherwise, the WTRU can trigger resource selection when a packet arrives.

[0161] For example, for a TB's HARQ type (e.g., TBs with HARQ enabled and TBs with HARQ disabled), the WTRU can be (pre-configured) with a minimum number of candidate slots and / or a minimum resource selection window (e.g., a minimum of [n+m, n+M]) based on the TB's HARQ type. The WTRU can determine the resource selection window based on whether the TB has HARQ enabled / disabled to accordingly satisfy the minimum number of candidate resources and / or the minimum resource selection window. For example, for a TB with HARQ enabled, the WTRU can be (pre-configured) with a first value (Mm), while for a TB with HARQ disabled, the WTRU can be (pre-configured) with a second value (Mm), where the second value of (Mm) is less than the first value of (Mm).

[0162] In the example, the DRX status of the WTRU may include any or more of the following criteria: whether DRX is configured; and / or whether the WTRU is in an on or off duration. In the example, the WTRU may determine whether to use the Physical Side Link Shared Channel (PSSCH) Demodulation Reference Signal (DMRS) or the Physical Side Link Control Channel (PSCCH) to measure channel availability based on whether DRX is configured and / or whether the WTRU is in an on or off duration. For example, if DRX is configured and / or the WTRU is in an on duration, the WTRU may determine to use PSCCH DMRS. In the example, if DRX is not configured and / or the WTRU is in an off duration, the WTRU may determine to use PSSCH DMRS.

[0163] In the example, regarding whether the WTRU performs resource selection for initial selection, (re)evaluation of the selected resource, or (re)evaluation of the reserved resource, the WTRU can be (pre-configured) with three numbers of candidate time slots for initial resource selection, (re)evaluation of the selected resource, and (re)evaluation of the reserved resource. The WTRU can then determine the resource selection window accordingly to satisfy the minimum number of candidate time slots required for initial selection, (re)evaluation of the selected resource, or (re)evaluation of the reserved resource.

[0164] Based on the resource allocation example, the WTRU can determine the resource selection type. The WTRU can determine any of the following resource allocation types for a TB: listen-based (e.g., based on full listen or partial listen); and / or random. The resource allocation type for a TB can be determined based on one or more of the following criteria: configuration / pre-configuration; packet arrival time; data QoS; resource pool CBR; availability of listen results; number of listen slots listened to within the resource selection window; and / or remaining available battery life.

[0165] In the example, the resource pool can allow both random resource allocation and listener-based resource selection. The WTRU can determine whether to perform random resource allocation or listener-based resource selection based on the QoS of the TB. For example, if the priority of the TB is less than a threshold, the WTRU can perform random resource selection, and if the priority of the TB is less than a threshold, the WTRU can perform listener-based resource selection.

[0166] In the example, WTRU can determine whether to perform listener-based resource allocation or random resource selection in the resource pool based on the number of time slots listened to in the listener window (e.g., the number of time slots listened to could refer to the number of time slots listened to in the long-term part of the listener window, the short-term part of the listener window, or both). For example, if the number of time slots listened to in the listener window is less than a threshold, WTRU can determine to perform random resource selection or discard the TB. Otherwise, WTRU can determine to perform listener-based resource allocation.

[0167] In the example, the WTRU can be configured / pre-configured with two sets of resource pools, one set associated with transmissions to power-saving WTRUs (e.g., PUEs) and the other set associated with transmissions to non-power-saving WTRUs (e.g., VUEs). The WTRU can further be configured / pre-configured with two sets of destinations (or any indications related to services that can be used to distinguish target WTRUs as VUEs and / or PUEs), one set of destinations not associated with power-saving WTRUs (e.g., PUEs) and the other set of destinations associated with power-saving WTRUs (e.g., PUEs). The WTRU can determine the transmission resource pool to use based on whether a destination is associated with a power-saving WTRU (e.g., PUE).

[0168] In the example, the WTRU can be configured / pre-configured with a resource pool. The WTRU can determine the group of sub-channels and / or time slots to perform resource allocation for transmitting the TB based on the target WTRUs within the resource pool, such as whether the target WTRUs have power-saving WTRUs (e.g., PUE). For example, if the PUE is not included in the group of target WTRUs, the WTRU can perform resource allocation in all sub-channels; otherwise, the WTRU can perform resource selection in a subset of sub-channels. This subset of sub-channels can be determined based on one or both of the WTRU's location, the resource pool's CBR, and / or the TB's QoS.

[0169] In the example, a WTRU (e.g., a PUE) can apply timing constraints between two selected resources when performing resource selection. The WTRU can select two transmission resources with a time interval (e.g., the time interval between an initial transmission and the first retransmission) higher than a threshold. This threshold can be (pre-)configured based on transmission priority, or it can be fixed per resource pool. This approach can be triggered to support other WTRUs (e.g., VUEs) in resource re-evaluation to detect potential conflicts. In the example, the WTRU can determine the set of optional resources (e.g., the set of resources to be reported to the MAC layer) based on its time / frequency region. In one approach, the WTRU can divide the set of time / frequency resources into multiple of the following groups: a set of listener-based selected resources; and / or a set of randomly selected resources. The WTRU can determine the set of optional resources by first selecting from the set of listener-based resources. If the set of optional resources in the listener-based time / frequency resources is less than a threshold, the WTRU can further select resources from the set of randomly selected resources.

[0170] The mechanism can be used for resource evaluation / re-evaluation. In the example, the physical (PHY) layer of a WTRU (e.g., VUE) can perform resource evaluation by determining a set of optional resources to report to the media access control (MAC) layer. The MAC layer can then randomly select one or more resources from the set of resources reported by the PHY layer for transmitting a TB.

[0171] In the example, the WTRU can perform resource assessment / reassessment. The WTRU can perform resource assessment / reassessment by performing one or more of the following actions: determining whether its selected / reserved resources conflict with any reserved resources from other WTRUs, selecting new resources for WTRU launch, discarding TBs and / or discarding reserved resources that conflict with another WTRU.

[0172] In the example, a WTRU can perform a resource evaluation / re-evaluation to determine whether its selected / reserved resources conflict with any reserved resources from other WTRUs by performing one or more of the following actions: A WTRU can determine whether its reserved resources conflict with any reserved resources from other WTRUs by evaluating the listening results of a subset of the listening resources. For example, a WTRU can evaluate time slots and / or sub-channels where transmissions in these time slots and / or sub-channels may reserve resources that could potentially conflict with the WTRU's transmissions. A WTRU can perform this type of resource evaluation / re-evaluation periodically or based on an event. This event may be based on the WTRU performing resource selection / reselection, and / or the resource pool's CBR being greater than / less than a threshold, or either.

[0173] The WTRU can perform resource evaluation / re-evaluation in one of the following: evaluation / re-evaluation of selected resources and / or evaluation / re-evaluation of reserved resources. In the evaluation / re-evaluation of selected resources, the WTRU can perform the evaluation / re-evaluation after it has selected the resource for the launch TB and before it launches the SCI to reserve that resource. In the evaluation / re-evaluation of reserved resources, the WTRU can perform the evaluation / re-evaluation of resources that have already been reserved by the WTRU's SCI. Resources can be reserved semi-persistently for different TBs, or dynamically for retransmissions of the same TB. The WTRU can perform evaluation / re-evaluation before launching the TB for semi-persistent reservation. In another example, it can perform evaluation / re-evaluation after the initial launch of the TB for dynamic reservation.

[0174] The WTRU may perform resource evaluation upon triggering resource selection. For example, the WTRU may determine whether to trigger resource evaluation / re-evaluation (evaluation / re-evaluation of selected resources and / or evaluation / re-evaluation of reserved resources) or not to trigger resource evaluation / re-evaluation based on one or more of the following exemplary criteria: whether the WTRU performs short-term partial listening; the QoS of the TB; the CBR of the resource pool; the amount of optional resources for the resource; the HARQ retransmission type of the TB; whether the WTRU performs semi-persistent reservation for the TB; the reservation period of the semi-persistent reservation; the period of resource evaluation / re-evaluation; and / or whether semi-persistent reservation is enabled / disabled.

[0175] In the example, the WTRU can determine whether to trigger a resource assessment / reassessment based on whether it performs short-term partial listening. For example, if it does not perform short-term partial listening, the WTRU may not trigger a reassessment of the selected resource. In the example, the WTRU can also determine whether to trigger a resource assessment / reassessment based on the QoS of the TB. For example, if the TB's priority is greater than a threshold, the WTRU may trigger a resource reassessment, and if the TB's priority is less than a threshold, it may not trigger a resource reassessment.

[0176] In the example, WTRU can determine whether to trigger a resource assessment / reassessment based on the resource pool's CBR. For instance, if the resource pool's CBR is greater than a threshold, WTRU can trigger a resource reassessment. Otherwise, WTRU can determine not to trigger a resource reassessment.

[0177] In the example, the WTRU can determine whether to trigger a resource evaluation / re-evaluation based on the amount of available resources used for resource selection. For example, if the amount of available resources in the last resource evaluation / re-evaluation is less than a threshold, the WTRU may trigger a resource evaluation / re-evaluation. Otherwise, the WTRU may not trigger a resource evaluation / re-evaluation. In the example, the WTRU can also determine whether to trigger a resource evaluation / re-evaluation based on the HARQ retransmission type of the TB. For example, if the WTRU performs a blind retransmission on the TB, the WTRU may trigger a resource re-evaluation, and if the WTRU performs a HARQ-based retransmission or a mixture of HARQ-based and blind retransmission, a resource re-evaluation may not be triggered.

[0178] In the example, the WTRU can determine whether to trigger a resource assessment / reassessment based on whether it performs semi-persistent reservation for the TB. For example, if the WTRU performs semi-persistent reservation, it may trigger a resource reassessment; if it does not perform semi-persistent reservation, it may not trigger a resource reassessment. In the example, the WTRU can also determine whether to trigger a resource assessment / reassessment based on the reservation period of the semi-persistent reservation. For example, if the reservation period is less than a threshold, the WTRU may perform a resource assessment / reassessment; if the reservation period is greater than the threshold, it may not perform a resource assessment or reassessment. The threshold for the reservation period used to determine whether the WTRU needs to perform a resource assessment / reassessment can be configured / pre-configured per resource pool.

[0179] In the example, the WTRU can determine whether to trigger a resource assessment / reassessment based on the resource assessment / reassessment cycle. For example, the WTRU can configure / pre-configure a minimum cycle to perform resource assessment / reassessment for each sidelink procedure. The WTRU can also determine whether to perform a resource assessment / reassessment for a specific TB's launch based on the time gap between the reserved resources of the current TB and the reserved resources of the last TB being assessed / reassessed. For example, if the time gap is greater than a threshold, the WTRU can perform a resource assessment / reassessment; otherwise, the WTRU may not trigger a resource assessment / reassessment. This approach can be triggered to allow the WTRU to skip monitoring for a period of time to save power. In the example, the WTRU can also determine whether to trigger a resource assessment / reassessment based on whether semi-persistent retention is enabled / disabled. For example, if semi-persistence is disabled in the resource pool, the WTRU can trigger a resource assessment / reassessment; otherwise, the WTRU may not trigger a resource assessment / reassessment.

[0180] The WTRU can trigger resource evaluation and / or resource allocation based on one or more of the following: the timing of the first detected / optional time slot in the resource selection sub-window, the termination of a short-term partial listenership, or periodicity. In the example, the WTRU can trigger resource evaluation and / or resource allocation based on the timing of the first detected / optional time slot in the resource selection sub-window. For example, the WTRU can trigger resource selection and / or resource evaluation at least T3 time slots before the first listenership time slot in the resource selection window. The value of T3, or the minimum / maximum value of T3, can be configured or determined by the WTRU based on TB-based QoS (pre-configured). This approach allows the WTRU to have available resources to select within the detected time slots. In the example, the WTRU can trigger resource evaluation and / or resource allocation based on the termination of a short-term partial listenership. For example, when the WTRU completes a short-term partial listenership, the WTRU can trigger a resource re-evaluation.

[0181] In the example, the WTRU can trigger resource assessments and / or periodic resource allocation. For instance, the WTRU can determine to periodically perform resource (re)assessments for semi-persistent reservations in sidelink processes. For example, the WTRU can perform a resource (re)assessment every N TB of transmission. The value of N can be configured / pre-configured and / or determined based on the reservation period of the sidelink process.

[0182] The WTRU can perform resource (re)evaluation on semi-persistent reserved resources. In the example, the WTRU can perform resource (re)evaluation on semi-persistent reserved resources. The WTRU can be (pre-)configured based on one or more of the following criteria: QoS of TB; and / or periodicity of semi-persistent reservation. In the example, the WTRU can perform resource (re)evaluation to meet the minimum number of resources and / or periods to be (re)evaluated. For example, the WTRU can be (pre-configured) to perform resource (re)evaluation at least once every N time slots. The value of N can be (pre-configured) according to the QoS of TB. The WTRU can then determine the period to perform resource (re)evaluation after every N time slots. The WTRU can determine to perform resource (re)evaluation periodically and / or dynamically.

[0183] The WTRU can determine the set of sub-channels to select based on the resource selection type. For example, if the WTRU performs random resource selection, it can select resources from all sub-channels configured for the resource pool. However, if the WTRU performs listen-based resource selection, it can select resources from the sub-channels that are being listened to. In the example, the WTRU can perform resource selection to determine a set of resources for transmission. The WTRU can further select one or more other sets of resources for backup. If the WTRU detects a potential collision in the first set of transmission resources, it can select that set of backup resources for the potential transmission.

[0184] The WTRU can apply time / frequency constraints between the set of resources used for transmission and the set of resources used for backup. The WTRU can select transmission resources and their associated backup resources that meet one or more of the following criteria: the time gap between the two selected resources is less than or equal to a threshold (this time gap threshold can be zero, for example, in which case the two selected resources can be in the same time slot); the frequency gap between the two resources is less than the threshold or the two selected resources belong to a subset of subchannels; and / or the frequency gap between the two selected resources is greater than the threshold, or the two selected resources belong to different subsets of subchannels. In the example, the WTRU can select a transmission resource and its associated backup resource in the same time slot and / or in the same set of subchannels. This approach reduces the WTRU's listening time.

[0185] In the example, the WTRU may perform a short-term partial listening operation before performing a resource reassessment of reserved and / or backup resources. The size of this listening window may be (pre-)configured based on one or more of the following criteria: the QoS of the TB and / or the CBR of the resource pool (e.g., the WTRU may be (pre-)configured with a minimum listening window and / or a minimum number of listening slots based on the priority of the TB and / or the CBR of the resource pool before performing resource reassessment, and the WTRU may then determine the listening window based on these parameters); and / or the periodicity of the reserved resources (e.g., if the periodicity of the reserved slots is large, the WTRU may choose a long listening window, or the WTRU may choose a short listening window). In the example, the WTRU may be (pre-configured) with this set of time / frequency resources to perform listening, thereby detecting potential conflicts in the time / frequency resources. The WTRU may then determine the listening resources to detect potential conflicts based on the (pre-configured time / frequency relationship and the set of time / frequency resources that the WTRU targets for performing listening.

[0186] The WTRU can determine how often to perform resource reassessments on its reserved and / or backup resources. The WTRU can determine the frequency of resource reassessments on a set of semi-persistent reserved resources (e.g., SPS processes) and / or backup resources based on one or more of the following criteria: QoS of the TB (e.g., for each transmit priority, the WTRU may be (pre-)configured with a minimum number of resource reassessments per N reservation periods, and / or a minimum number of resource reassessments per fixed duration (e.g., 1 s), and the WTRU may then randomly determine the transmit periods for which resource reassessments are performed to meet the required resource reassessment criteria); reservation periodicity (e.g., the WTRU may be (pre-configured) to perform reassessments for Y... At least X resources are re-evaluated for each launch, such that the WTRU can subsequently randomly select X resources from Y launches for re-evaluation, and the value of X can be configured according to the priority of the TB, such that when the value of X can be zero, the WTRU can determine that no resource re-evaluation is performed; the number of reserved resources per reservation period (e.g., the WTRU can determine the number of resource re-evaluations based on the number of more resources reserved in the reservation period); and / or the CBR of the resource pool (e.g., when the CBR is high, the WTRU may need to perform more resource re-evaluations, while when the CBR is low, the WTRU may need to perform fewer resource re-evaluations).

[0187] If the WTRU detects a conflict, it can reselect a launch resource. For example, if the WTRU detects a potential conflict in a launch resource, it may perform one or more of the following actions: In a first exemplary action, the WTRU may replace the launch resource with the corresponding resource. In a second exemplary action, the WTRU may replace the set of launch resources with the set of backup resources. The WTRU may perform the first exemplary action on a TB with HARQ disabled, and the WTRU may perform the second exemplary action on a TB with HARQ enabled. In the example, if the WTRU detects a potential conflict in a backup resource, it can reselect a backup resource. If the WTRU cannot select a backup resource that meets time and / or frequency limits, it can reselect both the backup resource and the corresponding launch resource.

[0188] In the example, the WTRU may perform silencing of the SPS sidelink process. The WTRU may perform one or more of the following exemplary processes: the WTRU may determine not to use reserved resources for one or more reservation periods; the WTRU may determine not to use one or more reserved resources for a period; and / or the WTRU may determine not to use reserved resources for one or more reservation periods and determine not to use one or more reserved resources for one period. For example, the WTRU may use a first exemplary method in a first time period and a second exemplary method in another time period. In the example, the WTRU may determine which period and / or which resource to silence based on any or more of the following criteria: QoS of the TB; periodicity of the reserved resources; and / or CBR of the resource pool (e.g., the WTRU may silence more resources in congested scenarios, such as when the CBR is high, and the WTRU may silence fewer resources in non-congested scenarios, such as when the CBR is low). In the example, the WTRU may double the resource reservation period used for transmission before the silencing period. If the WTRU determines to silence transmission in the current cycle, the WTRU may indicate twice the reservation period in the SCI of the previous cycle. If resources are available, this method will reserve resources in the next cycle.

[0189] The WTRU can perform resource selection for a TB during a quiet period. If the TB is available during the quiet period, the WTRU can use another resource pool to perform a transmission during this period. The WTRU can use a resource pool that allows random resource selection (e.g., an exceptional resource pool) to transmit the TB. In the example, the WTRU can use dynamic resource selection to select a transmission resource for the current TB. The WTRU can perform resource reassessment to determine the availability of reserved SPS sidelink processes. For example, when the WTRU is not transmitting in a reserved resource, the WTRU can perform reception in a reserved slot to determine if there are any overlapping transmissions in the reserved slot. If there are no transmissions in the reserved resources, the WTRU can continue using those reserved slots in the next period. If the WTRU detects a transmission in a reserved resource, the WTRU can decode the SCI of that transmission, and the WTRU can do one or more of the following: if the SCI indicates a dynamic transmission, the WTRU can continue using the reserved resource in the next period; and / or if the SCI indicates an SPS transmission, the WTRU can determine whether to use the reserved slot in the next period based on the collision percentage. For example, if the percentage of conflicts in the SPS side link process is higher than a threshold (which can be zero or greater than zero), the WTRU may determine to reselect another resource. However, if the percentage of conflicts is lower than the threshold, the WTRU may continue to use the SPS side link process.

[0190] A mechanism can be used to switch resource pools on / off for listening. A WTRU can be configured / pre-configured for multiple resource pools associated with different broadcast types, service types, and / or listening types. In the example, a WTRU can be configured to monitor multiple resource pools. Each resource pool can be associated with one or more of the listening type, broadcast type, and / or service type.

[0191] In the examples, each resource pool can be associated with a listener type. For example, a WTRU can be configured / pre-configured with a resource pool to perform default listening, in which the WTRU can perform continuous listening. A WTRU can be further configured / pre-configured with one or more other resource pools to perform discontinuous listening. For example, a WTRU can perform listening in these resource pools partially or based on event triggers. In the examples, each resource pool can be associated with a broadcast type. For example, a WTRU can be configured with one resource pool associated with broadcast or all broadcasts and one or more other resource pools associated with unicast and / or multicast. In the examples, each resource pool can be associated with a broadcast type. For example, a WTRU can be configured with one or more resource pools associated with basic security services and one or more resource pools associated with advanced services. In another example, a WTRU can be configured with one set of resource pools associated with power-saving WTRUs (e.g., PUE) and another set of resource pools associated with non-power-saving WTRUs (e.g., VUE).

[0192] A WTRU can trigger or initiate listening in another resource pool. In the example, when a WTRU receives (implicitly or explicitly) data / control from a second resource pool that triggers listening in the second resource pool, the WTRU can perform listening in the first resource pool. For example, a WTRU can be configured to monitor multiple resource pools, each of which may be associated with one or more services. The WTRU can be further configured in a resource pool where it performs listening to continuously or periodically determine listening activity in other resource pools. According to the example, a WTRU can be configured / pre-configured in a first default resource pool to perform continuous monitoring, and in a second default resource pool for discontinuous monitoring. In the first default resource pool, the WTRU can receive control and / or data from a second WTRU (e.g., a peer WTRU with which it has a unicast session), which can trigger the first WTRU to perform listening in another second resource pool. Control or data from the second (peer) WTRU may include any of the following: the second (peer) WTRU initiates a unicast / multicast session in another resource pool; the second (peer) WTRU switches the unicast / multicast data to another resource pool; and / or time / frequency resources for the unicast / multicast session.

[0193] The WTRU can switch off listening in a resource pool. In the example, the WTRU may determine to switch off listening in a resource pool based on one or more of the following criteria: the WTRU detects / declares a Radio Link Failure (RLF) for one or more links with services associated with that resource pool (e.g., by the WTRU using an Access Layer (AS) or upper-layer scheme); the WTRU receives (implicitly or explicitly) an instruction from a gNB, other node, or peer WTRU to terminate a unicast / multicast session (e.g., the WTRU may receive an SCI that does not reserve resources for transmitting future TBs in the same unicast / multicast session, and the WTRU may then terminate the unicast session and shut down listening in the associated resource pool); the WTRU fails to detect control and / or data for the unicast / multicast session in one or more reserved resources in one or more sidelink processes for the unicast / multicast session; and / or the WTRU terminates a unicast session in a discontinuous listening resource pool.

[0194] In the example, the process can be used for random resource selection. In the example, the WTRU can determine whether to use listener-based or random resource selection in the resource pool. The WTRU can be configured with resource pools that allow both random and listener-based resource selection. The WTRU can determine which resource selection scheme to use based on one or more of the following criteria: the WTRU's power saving mode / state; the resource pool's CBR; the WTRU's CR; the TB's broadcast type; and / or the TB's QoS; and / or the timing of the first candidate time slot, the timing of the last candidate time slot, the packet arrival time, and / or the gap between the packet arrival time and the first candidate time slot.

[0195] In an example of a time-based resource selection scheme standard, if the time interval between the packet arrival time and the first candidate time slot is less than a threshold, the WTRU may perform a random selection. This threshold may be (pre-)configured based on the QoS of the TB and / or the CBR of the resource pool. In another example, if the number of candidate time slots satisfying the PDB of the TB is less than a threshold, the WTRU may determine to perform a random resource selection. This threshold may be (pre-configured) based on the QoS (e.g., priority) of the TB and / or the CBR of the resource pool.

[0196] In the example, the WTRU can determine whether it can perform random resource allocation based on its power-saving mode and / or power-saving state. For example, the WTRU can be configured with two sets of power-saving modes / states. In the first set of power-saving modes / states, random resource selection may be allowed, while in the second set of power-saving modes or states, random selection may not be allowed. The WTRU's power-saving mode / state can be modeled by the WTRU's sidelink and / or Uu interface activity.

[0197] In the example, the WTRU can determine whether it can perform random resource allocation based on the CBR of the resource pool. For example, the WTRU can perform random resource selection when the CBR of the resource pool is less than a threshold, and can perform listen-based resource allocation if the CBR of the resource pool is greater than another threshold. In the example, the WTRU can determine whether it can perform random resource allocation based on its Channel Occupancy Ratio (CR). For example, the WTRU can perform random resource selection when the CR is less than a threshold; otherwise, the WTRU may need to perform listen-based resource selection. The WTRU's CR can be calculated / determined based on resources transmitted and / or reserved from different resource selection types (e.g., random, partially listen-based, and fully listen-based). For example, the WTRU can calculate three CRs, where a first CR can be used to evaluate the channel occupancy of the selected resource using random selection, a second CR can be used to evaluate the occupancy of the selected resource using listen-based selection, and a third CR can be used to evaluate the occupancy ratio of all resources. The WTRU can then determine whether to randomly select resources based on the first CR.

[0198] In the example, the WTRU may determine whether it can perform random resource allocation based on the broadcast type and / or HARQ type of the TB. For example, the WTRU may be allowed to perform random selection for broadcast TBs, but may not be allowed to perform random selection for unicast / multicast TBs. In another example, the WTRU may be allowed to perform random selection for TBs with HARQ disabled, but may not be allowed to perform random selection for TBs with HARQ enabled. In the example, the WTRU may determine whether it can perform random resource allocation based on the TB's QoS. For example, the WTRU may be allowed to perform random selection for one set of priorities, and may not be allowed to perform random selection for another set of priorities. For example, if the TB's priority and / or TB's latency are less than a threshold, the WTRU may be allowed to perform random selection. Otherwise, the WTRU may not be allowed to perform random selection. This priority and / or latency threshold may be configured per resource pool and / or per service.

[0199] In the example, the WTRU may indicate a resource selection mode and / or power saving mode in the message. For example, the WTRU may use an SCI (e.g., SCI 1 or SCI) to indicate the resource allocation mode and / or power saving mode of the launch resource. The WTRU may use one or more of the following exemplary fields or indicators to indicate the resource allocation mode and / or power saving mode of the launch resource: a field in a first SCI and / or a second SCI; and / or a second SCI format. For example, the WTRU may use one SCI format for one set of power saving modes and / or resource allocation modes and another second SCI format for another set of power saving modes and / or resource allocation modes. In the example, the WTRU may prioritize resources reserved by different resource selection modes and / or power saving modes. For example, the WTRU may decode the SCI to determine the resource selection mode and / or power saving mode associated with the reserved resource. When determining the availability of each reserved resource, the WTRU may then use different RSRP thresholds (e.g., such as...). Figure 8 (as shown in the exemplary process 800).

[0200] In the example, the WTRU can determine whether to reselect conflicting resources based on the resource selection mode and / or power-saving mode indicated in the SCI. The WTRU can also determine whether it should reselect resources due to a resource re-evaluation process based on the resource selection mode and / or power-saving mode associated with the reserved resource. For example, if the resource selected / reserved by the WTRU conflicts with a resource reserved by a random selection process, the WTRU can perform a resource reselection regardless of the priority associated with that resource. This approach avoids conflicts with randomly selected resources.

[0201] In the example, the WTRU can determine a resource selection window for the TB. The WTRU can use different groups of time slots to select resources for the initial transmission and retransmission of the TB. For example, the WTRU can determine the partially detected and partially undetected time slots in that group of resource selection windows. The WTRU can then randomly select the initial transmission from the available / optional resources in that group of partially detected time slots. The WTRU can then randomly select retransmission resources from the detected and / or undetected resources in that group. This approach reduces the probability of collisions during the initial transmission of the TB.

[0202] In the example, the WTRU may perform a resource re-evaluation after random selection. The WTRU may determine whether to perform a resource (re)evaluation on the randomly selected resource based on one or more of the following criteria: resource pool configuration; QoS of the TB; CBR of the resource pool and / or CR of the WTRU; timing between the resource selection time and the first selected resource; HARQ type of the TB (e.g., TB with HARQ enabled and TB with HARQ disabled); DRX status of the WTRU; power saving mode of the WTRU; and / or whether semi-persistent resource reservation is enabled / disabled in the resource pool.

[0203] In the resource pool configuration example, the WTRU can be (pre-)configured to perform resource re-evaluation on randomly selected resources in the resource pool. The WTRU can determine accordingly whether to perform resource (re)evaluation on the selected resources. In the TB's QoS example, if the TB's QoS is greater than a threshold, the WTRU can determine to perform resource (re)evaluation on the randomly selected resources. Otherwise, the WTRU can determine not to perform resource (re)evaluation. This threshold can be (pre-configured) per resource pool. In the timing example between resource selection time and the first selected resource, if the time interval between resource selection and the first selected resource is greater than a threshold, the WTRU can determine to perform resource (re)evaluation on the randomly selected resources. Otherwise, the WTRU may not perform resource (re)evaluation on the randomly selected resources. This threshold can be (pre-configured) per resource pool. This threshold can be configured based on the TB's QoS. In the WTRU's DRX state example, if the TB's QoS is greater than a threshold, the WTRU can determine to perform resource (re)evaluation on the randomly selected resources. Otherwise, the WTRU can determine not to perform resource (re)evaluation. This threshold can be (pre-configured) per resource pool. In the example of enabling / disabling semi-persistent resource reservation in a resource pool, WTRU may determine whether to perform a resource (re)evaluation on a randomly selected resource based on whether semi-persistence is enabled / disabled. For example, if semi-persistent resource reservation is disabled, WTRU may perform a resource (re)evaluation on a randomly selected resource. Otherwise, WTRU may not perform a resource (re)evaluation on a randomly selected resource.

[0204] In one example, the WTRU can determine a listening window for resource re-evaluation after random selection. The WTRU can determine a listening window for resource (re)evaluation of the randomly selected resource. In this example, the listening window can begin when the WTRU performs resource selection and end T3 time slots before the first randomly selected resource. T3 can be fixed based on the WTRU's processing capacity. In another example, the WTRU can be (pre-)configured with a minimum listening window for resource (re)evaluation of the randomly selected resource. The WTRU can begin listening when resource selection is triggered and stop listening when the minimum listening window is reached. The WTRU can begin listening for T0 time slots before resource selection is triggered. When the minimum required listening window and / or T3 time slots before the first randomly selected resource are reached, the WTRU can stop listening to perform resource (re)evaluation.

[0205] In the example, the mechanism supports unicast / multicast. In the example, the WTRU can determine the resources used for HARQ feedback. The WTRU can be configured with one set of HARQ feedback resources for one resource selection mode, power-saving mode, and / or WTRU type, and another set of HARQ feedback resources for another resource selection mode, power-saving mode, and / or WTRU type. This resource selection mode, power-saving mode, and / or WTRU type can be indicated in the SCI. The receiving WTRU (the WTRU receiving the SCI) can then determine which HARQ feedback resource to use based on the resource selection mode, power-saving mode, and / or WTRU type indicated in the SCI (the WTRU transmitting the SCI). Figure 11 Exemplary time-frequency resources 1100 are shown for the Physical Side Link Feedback Channel (PSFCH) resource set for power-saving WTRU 1101 (e.g., PUE) and the resource set for non-power-saving WTRU 1102 (e.g., VUE). Figure 11 In the example, the WTRU can be configured with two HARQ resource sets: the first resource set, appearing every 2 slots, can be used for the non-power-saving WTRU 1102 (e.g., VUE), while the second resource set, appearing every 6 slots, can be used for the power-saving WTRU 1101 (e.g., PUE). This approach can benefit the limited processing capacity of the power-saving WTRU (e.g., PUE).

[0206] In the example, the WTRU can determine whether to transmit HARQ feedback for PSCCH / PSSCH. The WTRU can determine whether to transmit HARQ feedback to the Tx WTRU after each PSCCH / PSSCH reception based on one or more factors. An exemplary determining factor could be the number of TBs transmitted. For example, the WTRU can transmit HARQ feedback after a certain number of TBs. For example, the WTRU can transmit (report) HARQ feedback after a maximum of X TBs. The value of X can be (pre-)configured per resource pool based on the TB's QoS (e.g., priority). An exemplary factor could be resource reservation information in the SCI. For example, if the SCI reserves fewer than N resources for the same TB, the WTRU can report HARQ feedback after a PSCCH / PSSCH transmission. If the SCI reserves at least N resources for the same TB, the WTRU may not report HARQ feedback. An exemplary factor could be the QoS of the TB. For example, the WTRU can determine whether to transmit HARQ feedback for PSCCH / PSSCH based on the TB's QoS. For example, if the priority of a TB is greater than a threshold, the WTRU may transmit (report) HARQ feedback; if the priority of a TB is less than the threshold, it may not report HARQ feedback. An exemplary factor could be the CBR of the resource pool. An exemplary factor could be the resource selection mode for TB transmission resources. For example, if the TxWTRU performs random resource selection, the WTRU may report HARQ feedback for PSCCH / PSSCH transmission; otherwise, the WTRU may not perform HARQ feedback. In contrast, if the TxWTRU performs listen-based resource allocation, the receiving WTRU may perform HARQ feedback; otherwise, the WTRU may not perform HARQ feedback.

[0207] In the example, the WTRU can adjust the group of listener resources based on HARQ feedback and / or the average number of transmissions per TB. In one approach, the WTRU can adjust the group of listener resources based on the HARQ feedback status of a TB. For example, if the WTRU receives more than X NACK feedbacks for a TB, the WTRU can increase the number of resources used for listening. If the WTRU receives fewer than Y NACK feedbacks for a TB, the WTRU can decrease the number of listener resources. The values ​​of X and Y can be configured by priority per resource pool.

[0208] In the example, the WTRU can adjust the group of listener resources based on the average number of transmissions per TB per priority. In one approach, the WTRU can adjust the group of listener resources based on the average number of transmissions per TB. For example, if the average number of transmissions per TB is greater than a threshold, the WTRU can increase the number of listener resources, and if the average number of transmissions per TB is less than the threshold, it can decrease the number of listener resources. This threshold can be configured per priority per resource pool.

[0209] In the example, the WTRU may perform one or more of the following: determine whether to use listener-based or random resource selection in the resource pool; indicate the resource selection mode and / or power-saving mode in the message; determine the resource selection window for TB; determine the resource selection for HARQ feedback; determine whether to transmit HARW feedback for PSCCH / PSSCH; adjust a set of listener resources based on HARQ feedback and / or the average number of transmissions per TB; and / or adjust a set of listener resources based on the average number of transmissions per TB per priority.

[0210] This document describes an exemplary method for congestion control. The WTRU can determine the TB transmission behavior for congestion control. In the example, the WTRU can determine one or more of the following TB transmission parameters: the number of (re)transmissions of the TB; the number of subchannels used for each transmission; the transmission power; the MCS in a TB; and / or which MCS table is used.

[0211] The WTRU can use any one or more of the following criteria to determine the transmission parameters of the TB. In the example, resource selection types (e.g., random-based, fully-listened, and partially-listened) can be used. For example, the WTRU can be (pre-)configured to use multiple resource selection types for the TB. The WTRU can be (pre-configured) with multiple sets of transmission parameter ranges for the TB (e.g., maximum and / or minimum values), where one set can be (pre-configured) for one (or more) resource selection types (e.g., random-based, fully-listened, and partially-listened), and another set can be (pre-configured) for another resource selection type. The WTRU can then determine which set of ranges to use based on the TB's resource selection type.

[0212] For example, the WTRU can be (pre-)configured with two maximum (re)transmit times per TB, one threshold can be (pre-configured) for resource allocation based on randomness, and the other threshold can be (pre-configured) for resource allocation based on listening. The WTRU can then determine the threshold to use based on the resource selection type of the TB.

[0213] In one example, the number of candidate time slots and / or candidate resources in the resource selection window can be used. For example, the WTRU can determine the maximum number of (re)transmissions of a TB based on the maximum number of candidate time slots in the resource selection window. In another example, the number of available resources in the resource selection window can be used. In yet another example, the HARQ type of the TB can be used (e.g., TBs with HARQ enabled and TBs with HARQ disabled).

[0214] In another example, the DRX status of the WTRU can be used. For example, the DRX status of the WTRU may include one or more of the following criteria: whether DRX is configured; and / or whether the WTRU is in an on or off duration. In another example, resource (re)evaluation of selected resources can be used to determine whether they are enabled / disabled. In another example, resource (re)evaluation of reserved resources can be used to determine whether they are enabled / disabled. In other examples, the broadcast type of the TB (e.g., broadcast, unicast, or multicast) and / or the power-saving mode of the WTRU can be used. In another example, the QoS of the TB, the CBR of the resource pool, and / or the CR of the WTRU can be used. For example, the WTRU may determine which MCS table to use based on the QoS of the TB, the CBR of the resource pool, and / or the CR of the WTRU.

[0215] Although features and elements have been described above in specific combinations, those skilled in the art will understand that each feature or element may be used alone or in any combination with other features and elements. Furthermore, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via a wired or wireless connection) and 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 internal hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and digital versatile optical discs (DVDs)). A processor associated with the software may be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A wireless transmit / receive unit (WTRU), comprising: transceiver; and Processor, wherein the transceiver and the processor are configured to: Receive information from network nodes including duration information for a listening window, wherein the listening window includes multiple time slots; Based on the duration information and the periodic characteristics of the reserved resources, the duration of the listening window is determined according to the minimum number of time slots. Perform listening for the duration of the determined listening window; Based on the performed snooping and the reserved resources, resources are selected for sidelink data transmissions performed by the WTRU; Perform a channel busy rate (CBR) measurement on the side link in at least one time slot of the plurality of time slots in the listening window; and Use the selected resources to transmit sidelink data.

2. The WTRU of claim 1, wherein the characteristic of the sidelink data transmission includes Quality of Service (QoS).

3. The WTRU according to claim 1, wherein the periodicity characteristic includes whether the sidelink data transmission is periodic or aperiodic.

4. The WTRU of claim 1, wherein the listening is performed in response to a service arriving at the WTRU for transmission.

5. The WTRU of claim 1, wherein the listening is performed in response to the WTRU requesting resources for transmission.

6. The WTRU of claim 1, wherein the transmission of the side link data is based on a performed CBR measurement.

7. The WTRU of claim 1, wherein the transceiver and the processor are further configured to: The value of the modulation and coding scheme (MCS) is determined based on the CBR measurements performed, and the transmission of the sidelink data uses the determined MCS value.

8. A method performed by a wireless transmit / receive unit (WTRU), the method comprising: Receive information from network nodes including duration information for a listening window, wherein the listening window includes multiple time slots; Based on the duration information and the periodic characteristics of the reserved resources, the duration of the listening window is determined according to the minimum number of time slots. Perform listening for the duration of the determined listening window; Based on the performed snooping and the reserved resources, resources are selected for sidelink data transmissions performed by the WTRU; Perform a channel busy rate (CBR) measurement on the side link in at least one time slot of the plurality of time slots in the listening window; and Use the selected resources to transmit sidelink data.

9. The method of claim 8, wherein the characteristic of the sidelink data transmission includes Quality of Service (QoS).

10. The method of claim 8, wherein the periodicity characteristic includes whether the sidelink data transmission is periodic or aperiodic.

11. The method of claim 8, wherein the listening is performed in response to a service arriving at the WTRU for transmission.

12. The method of claim 8, wherein the listening is performed in response to the WTRU requesting resources for transmission.

13. The method of claim 8, wherein the transmission of the sidelink data is based on a performed CBR measurement.

14. The method of claim 8, further comprising: The value of the modulation and coding scheme (MCS) is determined based on the CBR measurements performed, and the transmission of the sidelink data uses the determined MCS value.

Images