New radio (NR) vehicle everything (V2X) method for sensing and resource allocation

Abstract

A new radio (NR) vehicle-to-everything (V2X) method for sensing and resource allocation. A wireless transmit receive unit (WTRU) may determine a selectable set of resources by performing resource re-evaluation based on a previously selected set of resources. The WTRU may select at least one first resource from the previously selected set of resources. The at least one first resource may not be in the selectable resource set. The WTRU may replace the first resource with at least one second resource. The at least one second resource may be in the selectable resource set. The WTRU may select at least one third resource from the selectable set of resources based on an association with the at least one second resource. The WTRU may then transmit a first transport block (TB) using the at least one second resource. In addition, the association with the at least one first resource may be based on at least one of a HARQ state or a grant.

Description

[0001] Cross-reference to related applications

[0002] This application claims the benefits of U.S. Provisional Application No. 62 / 886,160, filed August 13, 2019; U.S. Provisional Application No. 62 / 908,089, filed September 30, 2019; and U.S. Provisional Application No. 62 / 975,552, filed February 12, 2020, the contents of which are incorporated herein by reference. Background Technology

[0003] Generally speaking, in wireless communication systems, considering other devices, including those communicating with, devices may need to operate within resources (such as a certain time and frequency). Various technologies and methods may be required to manage and share available resources for wireless communication. Long Term Evolution (LTE) Vehicle-to-Everything (V2X) features support fundamental security features.

[0004] New radio (NR) V2X operation has been developed. V2X communication can include one or more of vehicle-to-vehicle (V2V) communication, vehicle-to-pedestrian (V2P) communication, vehicle-to-infrastructure (V2I) communication, and vehicle-to-network (V2N) communication. V2X wireless transmit / receive units (WTRUs) can participate in V2X communication. Summary of the Invention

[0005] This document discloses systems, methods, and apparatuses for sensing and resource allocation in New Radio (NR) Vehicle-to-Everything (V2X) scenarios. A Wireless Transmitter-Receiver Unit (WTRU) performs resource selection and determines a set of resources to be used for transmission. For example, resources may be available for transmission of one or more transport blocks (TBs). The set of resources to be used for transmission may be referred to as the previously selected resource set.

[0006] Furthermore, the WTRU can dynamically determine when to trigger a resource reassessment. The WTRU can make this determination based on the feasibility of meeting latency requirements. Additionally, latency requirements may include the remaining PDB in TB. Furthermore, latency requirements may include the time gap between the previously selected resource and the remaining PDB in a second TB.

[0007] In one example, the WTRU can determine a set of selectable resources by performing resource re-evaluation based on a previously selected set of resources. Further, the WTRU can select at least one first resource from the previously selected set of resources. In one example, the at least one first resource can not be in the set of selectable resources. Further, the WTRU can replace the first resource with at least one second resource. In one example, the at least one second resource can be in the set of selectable resources. Further, the WTRU can select at least one third resource from the set of selectable resources based on an association with the at least one second resource. The WTRU can then transmit a first TB using the at least one second resource.

[0008] In another example, the association with the at least one second resource can be based on a HARQ status of the first TB. In one example, the HARQ status can be an enabled HARQ status of the TB. Further, the at least one third resource can be used for a HARQ transmission associated with the first TB.

[0009] In an additional example, the association with the at least one second resource can be based on a grant. In one example, the grant can be a periodic reservation grant. Thus, the association with the at least second first resource can be based on a periodic reservation grant associated with the first TB. Further, the additional resources can include resources associated with the periodic reservation grant. For example, the at least one third resource can be associated with the periodic reservation grant. Further, the preempted resource can also be a periodically reserved resource. In another example, one or more resources can be removed based on a collision. BRIEF DESCRIPTION OF DRAWINGS

[0010] A more detailed understanding can be had from the following description, given by way of example in conjunction with the accompanying drawings wherein like reference numerals indicate like parts. For a better understanding of the disclosure, reference is made to the following drawings:

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

[0012] FIG. 1B is a system diagram illustrating an example wireless access network (WAN) that can be used within the communications system illustrated in FIG. 1A FIG. 1 shows a diagram of an example wireless transmit / receive unit (WTRU) that can be used within the communications system shown in

[0013] FIG. 1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that can be used within the communications system illustrated in FIG. 1A

[0014] FIG. 1D is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that can be used within the communications system illustrated in FIG. 1A ​a system diagram of another example RAN and another example CN for use in the illustrated communication system;

[0015] FIG. 2 is a diagram illustrating an example of a potentially reserved slot when a WTRU does not monitor in a slot;

[0016] FIG. 3A is a diagram illustrating an example of resource selection and sensing;

[0017] FIG. 3B is a diagram illustrating an example of resource reevaluation including a resource reevaluation trigger;

[0018] FIG. 4 is a diagram illustrating an example of resource reevaluation including a transmission block (TB) with hybrid automatic repeat request (HARQ) enabled;

[0019] FIG. 5 is a diagram illustrating an example of resource reevaluation including a TB with HARQ disabled; and

[0020] FIG. 6 is a diagram illustrating an example of a WTRU determining a retransmission type based on timing of an initial transmission, a retransmission, and uplink (UL) HARQ feedback. DETAILED DESCRIPTION

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

[0022] As FIG. 1AAs shown, the communication system 100 can include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 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, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which can be referred to as a station (STA)) can be configured to transmit and / or receive wireless signals, and can include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot or other wireless devices operating in an industrial and / or an automated processing chain environment), a consumer electronics, a device operating on a commercial and / or industrial wireless network, and the like. Any of the WTRUs 102a, 102b, 102c, and 102d can be interchangeably referred to as a UE.

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

[0024] The base stations 114a can be part of a RAN 104 that also can include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base stations 114a and / or the base stations 114b can be configured to transmit and / or receive wireless signals on one or more carrier frequencies. These frequencies can be licensed or unlicensed frequencies. The base stations 114a and / or 114b can be communicatively coupled to one another, for example, via an X2 or other suitable interface.

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

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

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

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

[0029] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement multiple radio access technologies. For example, the base station 114a and WTRUs 102a, 102b, 102c can implement LTE wireless access using a dual connectivity (DC) principle. Thus, the air interface 116 utilized by WTRUs 102a, 102b, 102c can be characterized as a hybrid air interface.

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

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

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

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

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

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

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

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

[0038] Although the transmit / receive element 122 is depicted in the WTRU 102 FIG. 1B In one embodiment, the WTRU 102 can include two or more transmit / receive elements 122 (e.g., multiple antennas) to enable MIMO technology. Thus, the WTRU 102 can

[0039] The transceiver 120 can be configured to modulate the signals that are to be transmitted by the transmit / receive element 122 and to demodulate the signals that are received by the transmit / receive element 122. As noted above, the WTRU 102 can have multi-mode capabilities. Thus, the transceiver 120 can include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11, for example.

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

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

[0042] The processor 118 can also be coupled to the GPS chipset 136, which can be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 can receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on

[0043] The processor 118 can further be coupled to other peripherals 138, which can include one or more software and / or hardware modules that provide additional features, functionality and / or wired or wireless connectivity. For example, the peripherals 138 can include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands- free headset, a Bluetooth® 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] FIG. 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 one implementation, 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. FIG. 1C As shown, evolution nodes B 160a, 160b, and 160c can communicate with each other via the X2 interface.

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

[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 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 in a given BSS at any given time.

[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 split into two streams by a segment parser. Each stream can be processed individually using Inverse Fast Fourier Transform (IFFT) and time-domain processing. 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, the entire available frequency band can be considered busy even if most of the 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] FIG. 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 of gNBs 180a, 180b, and 180c may include one or more transceivers for communication with WTRUs 102a, 102b, and 102c via air interface 116. In one implementation, 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 one implementation, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In one implementation, gNBs 180a, 180b, and 180c may implement Cooperative Multipoint (CoMP) technology. For example, WTRU 102a may 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 scalable parameter sets. For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary depending on different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing different numbers of OFDM symbols and / or continuously varying absolute time lengths).

[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 eNode-B160a, 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. FIG. 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0067] FIG. 1DThe 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 possibly a 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 gNB 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] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 106 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 106 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure traffic routing through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing 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 WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRUs 102a, 102b, and 102c may be connected to DNs 185a and 185b via UPFs 184a and 184b through an N3 interface to UPFs 184a and 184b and an N6 interface between UPFs 184a and 184b and local DNs 185a and 185b.

[0072] Given FIGS. 1A-1D as well as FIGS. 1A-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 emulation 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 emulation 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 emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0075] In LTE vehicle-to-everything (V2X) communication, traffic models can exist, namely one or more types of traffic, such as periodic and event-triggered (the latter can be referred to as, for example, aperiodic). For periodic traffic, a 300-byte message can be followed by four 190-byte messages; furthermore, the arrival interval between two packets can be a multiple of 100ms. For event-triggered traffic, when an event is triggered (which follows a Poisson process), six messages can be generated in a 100ms time interval.

[0076] Considering the parameters of the LTE V2X traffic model above, generally speaking, event-triggered traffic and periodic traffic can be considered similar to or the same as periodic traffic.

[0077] Resources may need to be sensed and selected in LTE V2X. In LTE V2X, the Physical Sidelink Control Channel (PSCCH) and the Physical Sidelink Shared Channel (PSSCH) can be transmitted in the same subframe. The PSCCH may contain Sidelink Control Information (SCI), which may contain information about PSSCH transmission. By decoding the PSCCH, the receiving WTRU can decode the following information: the frequency and time of pre-booked PSSCH; the priority of the PSSCH; and / or the frequency and time of PSSCH retransmission.

[0078] Generally, in LTE V2X, the vehicle WTRU performs the sensing and resource selection process. First, the WTRU performs sensing to decode the SCI of other WTRUs. By decoding the SCI, the WTRU obtains information about pre-reserved PSSCHs and their corresponding priorities. If its Reference Received Power (RSRP) PSSCH is greater than a threshold, the WTRU considers the pre-reserved PSSCH occupied and excludes it from resource selection. The WTRU then sorts the remaining resources in ascending order of Received Signal Strength Indication (RSSI) and selects 20% of the total resources, represented as the selectable resource set S for the final resource selection. A Finally, it can be found in S. A A resource is randomly selected from the data for transmission.

[0079] NR V2X supports various traffic models. Similar to LTE V2X, New Radio (NR) V2X supports two types of traffic: periodic and aperiodic. However, NR V2X can support many different types of packet sizes, packet arrival rates, and latency requirements. Specifically, Model 2 aperiodic traffic can have the following characteristics: a packet size range between 10,000 and 30,000 bytes; an average arrival interval rate of 20 ms; and / or a latency requirement of 10 ms.

[0080] Additionally, mode 3 periodic traffic may have the following characteristics: a packet size range between 30,000 and 60,000 bytes; an average arrival interval rate of 30 ms; and / or a delay requirement of 30 ms.

[0081] For NR V2X, long-term sensing and short-term sensing may need to be addressed. As noted, NR V2X can support both periodic and non-periodic traffic. 3GPP RAN1 supports semi-persistent (SPS) resource reservation, which can be enabled / disabled. When SPS resource reservation is enabled, long-term sensing, utilized before resource selection is triggered, can be used to avoid conflicts in periodic traffic. For non-periodic traffic, short-term sensing, performed after resource selection is triggered, can be supported in the exemplary solution described herein. The interaction between long-term and short-term sensing can be considered in NR V2X sensing and resource selection.

[0082] Additionally, for NR V2X, it may be necessary to address Hybrid Automatic Repeat Request (HARQ) transmission within the resource pool. NR V2X supports three broadcast types: unicast, multicast, and broadcast, with HARQ operation supported for multicast and unicast sidelink transmissions. HARQ feedback resources can be configured and / or pre-configured in the resource pool, occurring periodically every N time slots (N = 1, 2, 4). Resource reservation for HARQ-based retransmissions can be supported in NR V2X. Therefore, in the exemplary solution described herein, NR V2X sensing and resource selection can be considered for both broadcast type and HARQ operation.

[0083] Furthermore, for NR V2X, burst traffic can be addressed. In LTE V2X, resource selection allocates resources for individual transport blocks (TBs). However, in NR V2X, burst traffic is anticipated. Performing sensing and resource selection for individual TBs may not guarantee the QoS requirements of TBs within burst traffic. Therefore, in the exemplary solution described herein, NR sensing and resource selection are designed to support burst traffic.

[0084] Additionally, preemption techniques can be used for NR V2X. NR V2X supports latency requirements as low as 3ms. Resource selection within a 3ms resource selection window can lead to a high probability of collisions. To guarantee QoS for such stringent TBs, preemption can be used. Preemption can be addressed in the exemplary solutions described herein during NR V2X sensing and resource selection.

[0085] The terms receiver WTRU, receiving WTRU, receiver, receiving, Rx WTRU, or Rx are used interchangeably and remain consistent with the examples and embodiments provided herein. Similarly, the terms transmitter WTRU, transmitting WTRU, transmitter, transmitting, Tx WTRU, or Tx are used interchangeably and remain consistent with the examples and embodiments provided herein. Furthermore, in one or more examples and embodiments provided herein, selection and reselection are used interchangeably.

[0086] In some exemplary cases, methods for HARQ-based transmissions may exist. Specifically, in some exemplary cases, methods supporting HARQ feedback transmissions may exist. For example, the WTRU may prioritize physical side-link feedback channel (PSFCH) transmissions and receptions in the same time slot based on HARQ status, data QoS, and the number of PSSCH / PSCCHs transmitted and received per TB.

[0087] In one exemplary case, the WTRU may prioritize PSFCH transmissions and receptions in the same time slot based on at least one or more of the following: HARQ status; index of the associated PSSCH / PSCCH for HARQ feedback; QoS of the data associated with PSFCH transmissions and receptions; broadcast type of the associated PSSCH / PSCCH; feedback type of multicast transmissions; whether the PSSCH / PSCCH Tx or Rx is in the same time slot; and / or Channel Busy Rate (CBR).

[0088] Regarding HARQ status, the WTRU may need to send an acknowledgment (ACK) or a negative ACK (NACK), and the number of bits required for the WTRU to send HARQ feedback to indicate the status of one or more TBs. For example, if the WTRU may need to send a HARQ-NACK, then a PSFCH transmission (PSFCH-Tx) may have a higher priority than a PSFCH reception. Conversely, if the WTRU may need to send a HARQ-ACK, then a PSFCH reception (PSFCH-Rx) may have a higher priority than a PSFCH reception. The WTRU may choose the higher priority option.

[0089] Regarding HARQ states, the WTRU may need to determine the number of HARQ feedback transmissions. If PSFCH-Tx is used for the N1st retransmission and PSFCH-Rx is used for the N2nd retransmission, the WTRU can execute either PSFCH-Tx or PSFCH-Rx based on the higher of N1 and N2. Alternatively, if N1 = N2, other conditions can be applied to determine between PSFCH Rx and PSFCH Tx.

[0090] Regarding the associated PSSCH / PSCCH broadcast type, several examples may apply. For instance, if the WTRU needs to receive a PSFCH for multicast and transmit a PSFCH for unicast, the WTRU may prioritize PSFCH reception regardless of other parameters.

[0091] Regarding the feedback type for multicast transmissions, several examples are applicable. For instance, the WTRU can prioritize based on whether the feedback is NACK-based (which can be considered option 1). Furthermore, the WTRU can prioritize based on whether the feedback is ACK / NACK-based (which can be considered option 2). Additionally, the WTRU can prioritize based on whether the feedback is a combination of option 1 and option 2.

[0092] Regarding whether PSSCH / PSCCH Tx or Rx is in the same time slot, in one example, if the WTRU transmits PSSCH / PSCCH transmissions in the same time slot (in which the WTRU may need to perform at least one of PSFCH-Tx and PSFCH-Rx), then the WTRU may perform PSFCH-Tx. Furthermore, if the WTRU receives PSSCH / PSCCH in the same time slot, then the WTRU may perform PSFCH-Rx. Additionally, if PSSCH / PSCCH Tx or Rx is not present in the time slot, the WTRU may determine PSFCH-Tx or PSFCH-Rx based on other conditions described herein.

[0093] Regarding CBR, in one example, if CBR is above a threshold, the WTRU may perform PSFCH-Rx in that time slot and skip transmitting PSFCH. Otherwise, the WTRU may determine PSFCH-Tx or PSFCH-Rx based on other conditions described herein.

[0094] In one exemplary method, the WTRU may prioritize PSFCH transmissions and receptions based on the HARQ status of the received PSSCH / PSCCH. Specifically, if the PSFCH feedback is ACK, the WTRU may discard the PSFCH transmission to prioritize PSFCH reception. Alternatively or additionally, if the PSFCH feedback is NACK, the WTRU may prioritize the PSFCH transmission or perform PSFCH transmission or reception based on the QoS of the associated PSSCH / PSCCH transmission.

[0095] In another exemplary approach, the WTRU can prioritize PSFCH transmissions or receptions based on the order of HARQ retransmissions. Specifically, the WTRU can utilize higher indices of the associated PSSCH / PSCCH to prioritize PSFCH transmissions or receptions.

[0096] In one exemplary scenario, the WTRU may determine whether it can transmit multiple PSFCHs in the same time slot. The WTRU may determine this based on one or any combination of the following: the maximum frequency distance between two PSFCH resources; the power level of each PSFCH; the minimum frequency distance between the PSFCH and the carrier boundary; the maximum power backoff for each PSFCH; and / or the number of symbols configured for the PSFCH resources. In one example, the symbols may be OFDM symbols. In another example, the symbols may be DFT-s-OFDM symbols.

[0097] In one exemplary method, the WTRU can determine the maximum power level of each PSFCH based on the frequency distance between two PSFCHs when it is simultaneously transmitting multiple PSFCHs. Specifically, a set of maximum power backoff values ​​for a single PSFCH transmission can be configured for the WTRU based on the frequency distance between two PSFCH resources. Based on the configured maximum power backoff values, the WTRU can determine the maximum power level of each PSFCH when it determines whether multiple PSFCHs can be transmitted simultaneously. Furthermore, the WTRU can determine the minimum power level required for each HARQ feedback, which can be based on one or more of the following: the QoS of the associated PSSCH / PSCCH; the WTRU's required PSFCH receive power; and / or sidelink path loss.

[0098] If the maximum power level of each PSFCH resource is greater than its minimum required power level, the WTRU can determine that it can transmit multiple PSFCHs simultaneously. Conversely, if the maximum power level of each PSFCH resource is less than or equal to its minimum required power level, the WTRU can determine that it cannot transmit multiple PSFCHs simultaneously.

[0099] In another exemplary method, if the maximum frequency distance between two PSFCH resources is less than a threshold, the WTRU may determine to transmit multiple PSFCHs simultaneously. Alternatively, if the minimum frequency distance between a PSFCH and a carrier boundary is greater than a threshold, the WTRU may determine to transmit multiple PSFCHs in the same time slot.

[0100] In another exemplary method, the WTRU may determine whether more than one PSFCH can be transmitted in the same time slot based on the number of symbols configured in the time slot containing PSFCH resources. If Ns symbols are configured for PSFCH resources, the WTRU may transmit Ns PSFCHs in the same time slot, wherein the symbol position may be determined based on one or more of the following: the source-id (and / or destination-id) of the WTRU receiving the PSFCH; the subchannel index (e.g., the first subchannel or the last subchannel) of the received associated PSSCH / PSCCH; and / or the time slot index of the received associated PSSCH / PSCCH.

[0101] In one exemplary scenario, the WTRU may perform prioritization among multiple PSFCH transmissions based on at least one of HARQ status, data QoS, and / or the index of PSSCH / PSCCH per TB. When the WTRU receives multiple PSSCH / PSCCH transmissions associated with a PSFCH slot, the WTRU may have multiple PSFCH-Tx transmissions in a single slot. In this case, the WTRU may need to prioritize the PSFCH-Tx transmissions and discard / skip lower-priority PSFCH-Tx transmissions.

[0102] In one exemplary method, the WTRU can perform PSFCH transmission prioritization by dropping one or more PSFCHs or reducing the power of non-priority PSFCHs. The WTRU can apply similar rules for PSFCH transmission and reception prioritization to perform prioritization among multiple PSFCH transmissions. Specifically, WTRU prioritization can be determined based on one or more of the following: HARQ status; the index of the associated PSSCH / PSCCH used for HARQ feedback; the QoS of the data associated with PSFCH transmission and reception; the broadcast type of the associated PSSCH / PSCCH; the feedback type of the multicast transmission; and / or the time position of the associated received PSSCH / PSCCH. In one example, HARQ status may involve whether the WTRU needs to send an ACK or NACK and the number of bits required for the WTRU to send HARQ feedback to indicate the status of one or more TBs.

[0103] In another example, the feedback type for multicast transmission can include whether the feedback is NACK-based. This feedback type can be referred to as Option 1 or Option 1. Alternatively, the feedback type can include ACK / NACK-based feedback. Therefore, this feedback type can be referred to as Option 2 or Option 1. Furthermore, the feedback type can be a combination of Option 1 and Option 2.

[0104] In another example, the timing of the associated PSSCH / PSCCH may include the PSFCH-Tx associated with the PSSCH / PSCCH received in slot #n. This PSFCH-Tx can be assigned a higher priority than the PSFCH-Tx associated with the PSSCH / PSCCH received in slot #n+k, where k>0.

[0105] In some exemplary cases, there may be methods for sensing and resource selection for HARQ-based transmissions. In one exemplary case, the WTRU may determine whether to reserve resources for retransmission of a unicast / multicast TB. The WTRU may determine to perform resource reservation for one or more retransmissions based on one or any combination of the following: the data state in the MAC buffer; the QoS of the data; and / or the CBR of the resource pool.

[0106] In one exemplary method, if it has data in its buffer for another TB, the WTRU may determine to reserve one or more resources for HARQ-based retransmission of the unicast / multicast TB. This method can help improve the spectral efficiency of the system because the resources reserved for HARQ-based retransmission can be used for the transmission of another TB, and the WTRU can use the reserved resources upon receiving a HARQ ACK.

[0107] In another exemplary approach, the WTRU may determine, based on the QoS of the TB, to reserve one or more resources for HARQ-based retransmissions and / or blind retransmissions of the unicast / multicast TB. Specifically, if the TB has strict QoS requirements, the WTRU may determine to reserve the resource for both HARQ-based and blind retransmissions. Alternatively, if the TB has moderate QoS requirements, the WTRU may decide to reserve the resource only for HARQ-based retransmissions. Furthermore, if the TB has low QoS requirements, the WTRU may determine not to reserve the resource for retransmissions.

[0108] The WTRU can determine the amount of resources reserved for a TB of transmission based on the resource pool's CBR. Specifically, the maximum and minimum number of reserved resources for each CBR range can be configured for the WTRU based on the data's QoS. The WTRU can then determine the exact amount of resources reserved for each TB based on its QoS and the resource pool's CBR. If the CBR is greater than a threshold, the WTRU can determine not to reserve any resources for HARQ-based retransmissions.

[0109] In one exemplary scenario, the WTRU may determine to allocate its HARQ-based retransmission resources to another TB based on the QoS of the TB. In one exemplary method, the WTRU may determine to allocate reserved HARQ-based retransmission resources to another TB if the QoS of the TB is higher or lower than a threshold. Additionally or alternatively, the WTRU may determine to use reserved HARQ-based resources if the relative QoS between the successfully transmitted TB and the new TB is within a predefined range. Thus, in one example, if the relative QoS between the two TBs is greater than a threshold, the WTRU may determine to use reserved HARQ-based resources. In another example, if the relative QoS between the two TBs is lower than a threshold, the WTRU may determine to use reserved HARQ-based resources.

[0110] In another exemplary scenario, the unicast-transmitting Rx WTRU can determine to use reserved HARQ-based retransmission resources of the Tx WTRU. Specifically, the Rx WTRU can determine to use reserved HARQ-based retransmission resources after successfully decoding the TB and transmitting an ACK feedback to the Tx WTRU. Therefore, the Rx WTRU can be configured to reuse such reserved resources using one or any combination of the following criteria: the QoS of the TB is greater than or less than a threshold; the relative QoS between the two TBs is within a predefined range; the Tx-Rx distance is less than / greater than a threshold; the CBR of the resource pool is higher than / lower than a threshold; and / or the CQI and / or RI of the reserved resources are higher than a threshold. The Rx WTRU can be configured to implicitly send its indication of using reserved resources to the Tx WTRU. Such indications can be sent by using different HARQ feedback resources (including time-frequency resources, sequence, or cyclic shift).

[0111] In one exemplary scenario, when the WTRU performs sensing and resource allocation, it can determine the priority and RSRP of reserved HARQ-based retransmission resources. In another exemplary scenario, when the WTRU performs sensing and resource allocation, it can determine the priority and Reference Signal Received Quality (RSRQ) of reserved HARQ-based retransmission resources. In yet another exemplary scenario, when the WTRU performs sensing and resource allocation, it can determine the priority and RSRP / RSRQ / RSSI of reserved HARQ-based retransmission resources.

[0112] Such information (e.g., priority and RSRP / RSRQ / RSSI) can be used to determine resource availability during the resource allocation process. The WTRU may determine the priority and RSRP / RSSI / RSRQ of reserved HARQ-based retransmission resources based on one or any combination of the following: the transmission used to reserve the HARQ-based retransmission resources; the priority and RSRP / RSSI / RSRQ of the PSSCH / PSCCH used to reserve the HARQ-based retransmission resources; the HARQ feedback status associated with the previous transmission of the TB; and / or the broadcast type of the TB and the HARQ feedback options used for the TB.

[0113] Regarding transmissions used to reserve HARQ-based retransmission resources, WTRU can determine whether the transmissions used to reserve HARQ-based retransmission resources are from the same TB or a different TB. In one example, resource reselection can also be used.

[0114] Regarding the HARQ feedback state associated with the previous transmission of the TB, the WTRU can determine the state associated with the previous transmission of the TB, such as: the WTRU received a HARQ ACK feedback; the WTRU received a HARQ NACK feedback; and the WTRU did not receive HARQ information. For the WTRU not receiving HARQ information, this state can be determined by any of the following: the WTRU did not decode the HARQ feedback; the WTRU was unable to decode the HARQ feedback; and the WTRU performed sensing and resource allocation before the HARQ feedback time.

[0115] Regarding the broadcast type, the WTRU can determine whether the reserved HARQ-based retransmission resources are used for unicast or multicast. Furthermore, if the resources are used for multicast transmission, the WTRU can further determine which HARQ feedback option is used for that transmission, where such information can be implicitly / explicitly conveyed in the SCI.

[0116] In one exemplary scenario, the WTRU can determine the priority and RSRP / RSRQ / RSSI of the reserved HARQ-based retransmission resource based on the resource reservation characteristics used to reserve the resource. Initially, the WTRU can decode an SCI with priority p and its measured RSRP / RSRQ / RSSI for PSCCH / PSSCH is E. If the WTRU uses a reservation with another TB characteristic to reserve the HARQ-based retransmission resource, the WTRU can determine the priority and RSRP / RSRQ / RSSI of the reserved HARQ-based retransmission resource as p and E, respectively. Additionally or alternatively, if the WTRU uses an initial transmission or retransmission of one TB to reserve the same TB of HARQ-based retransmission resource, the WTRU can determine the priority and RSRP / RSRQ / RSSI of the reserved HARQ-based retransmission resource as p+Δp and E+ΔE, respectively. The values ​​of Δp and ΔE can be pre-configured, configured, or explicitly indicated in the SCI. This exemplary method can support adjustment of retransmissions based on HARQ feedback.

[0117] In another exemplary scenario, the WTRU can determine the priority and RSRP / RSRQ / RSSI of reserved HARQ-based retransmission resources based on the HARQ state of the previous transmission of the same TB. Initially, the WTRU can decode an SCI with priority p and its measured RSRP / RSRQ / RSSI for PSCCH / PSSCH is E. In one exemplary method, if the WTRU receives a HARQ ACK and a HARQ NACK for the previous PSSCH / PSCCH transmission of the TB, respectively, the WTRU can apply different offsets to the priority and RSRP / RSRQ / RSSI. Additionally or alternatively, if the WTRU receives a HARQ ACK feedback for the previous PSSCH / PSCCH transmission of the TB, the WTRU can determine that the reserved HARQ-based retransmission resources are available and include them in the set of selectable resources for random selection. If the WTRU receives a HARQ NACK feedback, the WTRU can consider the resource unavailable.

[0118] In another exemplary scenario, the WTRU may divide the selectable resource set into two sets and select resources for a TB of transmission from one of these sets. In one example, one set may contain resources in slots with PSFCH and the other set may contain slots without PSFCH resources. The WTRU may select one set to choose resources for a TB of transmission. The WTRU may determine which set to select resources from based on one or more of the following: resource pool configuration; TB size; QoS of the TB; number of selectable resources in each set; CBR of the resource pool; and / or broadcast type of the TB.

[0119] In one example, the resource pool configuration may include the periodicity of slots with one or more PSFCH resources. In another example, if the TB size is greater than a threshold, the WTRU may select a resource set without PSFCH resources. Otherwise, the WTRU may select any resource set. In examples related to TB QoS, if the resource pool's QoS is less than a threshold, the WTRU may select a resource set with PSFCH resources. Additionally or alternatively, the WTRU may select a resource set without PSFCH resources. In examples related to CBR, if the resource pool's CBR is less than a threshold, the WTRU may select a resource set without PSFCH resources.

[0120] In the examples described herein, a procedure for HARQ feedback reporting for unknown location information is provided. In one exemplary case, the receiving WTRU may determine to transmit HARQ NACK feedback when it can decode the SCI. The WTRU may perform unicast / multicast-based NACK-based feedback, where the WTRU transmits NACK only if it cannot decode the message and the Tx-Rx distance is less than the minimum communication range (indicated in the SCI). In contrast, if the location information of the Rx WTRU is unknown, the WTRU may transmit NACK when it cannot decode the message. In one example, the message may be a PSSCH message.

[0121] In some exemplary cases, when its location is unknown, the receiving WTRU may determine not to send HARQ feedback. Additionally, in other exemplary cases, the receiving WTRU may determine whether to send HARQ feedback based on its past location information. In some exemplary cases, the receiving WTRU may determine to send HARQNACK feedback based on location information obtained from its last location information. In one exemplary scenario, when the time interval between the last location information of the Rx WTRU and the TB transmission may not exceed a threshold, the Rx WTRU may determine to use the last location information to calculate the Tx-Rx distance associated with the received TB. This threshold may be pre-configured, configured, or determined by the Rx WTRU based on at least one of WTRU speed, channel conditions, and / or QoS requirements. In one example, QoS requirements may include reliability.

[0122] In some other exemplary cases, when its location is unknown and the time period up to the last time it received location information is greater than a threshold, the receiving WTRU may determine not to send HARQ feedback. In another example, when its location is unknown but the time period up to the last time it received location information is less than or equal to a threshold, the receiving WTRU may determine to send HARQ feedback.

[0123] In some exemplary cases, the WTRU may perform one or more procedures for resource reservation. In one exemplary case, the WTRU may determine whether feature reservation for another TB is permitted. Generally, the WTRU may support feature reservation for another TB, which allows the WTRU to use the transport of one TB to reserve the resource for another TB. This feature may include one or any combination of the following: semi-persistent resource reservation; and / or dynamic resource reservation. In one example, semi-persistent resource reservation may include a procedure in which the SCI associated with one TB in a periodic flow reserves the resource for another TB in the same periodic flow. In another example, dynamic resource reservation may include a procedure in which the SCI associated with one TB reserves the resource for any other TB. In an exemplary method, the WTRU may indicate in the SCI which type of resource reservation it uses to support other WTRUs during sensing and resource allocation processes.

[0124] The WTRU can be configured to determine whether to allow a feature reservation for another TB based on one or any combination of the following: resource pool configuration; resource pool CBR; TB QoS; and / or minimum communication range (MCR). Examples involving MCR include whether the WTRU is inside or outside the MCR. In one example, the WTRU can be the receiving WTRU. Alternatively, in one example, being inside the MCR may be referred to as being within the MCR. In another example, being outside the MCR may be referred to as being outside the MCR. In one example, if the WTRU is inside the MCR, reservation for another TB may be allowed. Otherwise, reservation for another TB may not be allowed.

[0125] WTRU can be configured with a resource pool of one or any combination of the following instances that have reservations for another TB feature: First instance (which may be referred to as instance-1): allows SPS resource reservations; Second instance (which may be referred to as instance-2): allows dynamic resource reservations; and / or Third instance (which may be referred to as instance-3): allows both SPS and dynamic resource reservations; and / or Fourth instance (which may be referred to as instance-4): does not allow resource reservations.

[0126] Which instance is reserved for another TB feature can be determined based on one or more of the following: the resource pool's CBR; the resource pool configuration; the QoS of the packet or TB; coverage; MCR; and packet size. In one example, coverage may include within or outside the coverage area. In another example, MCR may include within or outside the MCR.

[0127] In another method, the WTRU may be configured to enable / disable each feature based on the CBR of the resource pool. For example, the WTRU may be configured to enable both SPS and dynamic resource reservation when CBR <= CRB1; enable SPS resource reservation when CBR1 < CBR <= CBR2; enable dynamic resource reservation when CBR2 < CBR <= CBR3, and have no reservation when CBR > CBR3.

[0128] In another exemplary method, the WTRU may be configured to determine which type of resource reservation to use for another TB feature. For example, the WTRU may be configured to use SPS resource reservation, dynamic resource reservation, both SPS and dynamic resource reservation, or no resource reservation based on the QoS of the data. For example, the WTRU may be configured to perform dynamic resource reservation for a TB if the priority, reliability, or latency of the TB is less than or greater than a threshold.

[0129] In one exemplary case, the WTRU may determine the amount of resources reported from the physical (PHY) layer to the MAC layer based on whether the feature reservation of another TB is enabled / disabled. For example, the WTRU may determine a first amount of resources reported from the PHY layer to the MAC layer based on the enabled feature reservation of another TB. In another example, the WTRU may determine a second amount of resources reported from the PHY layer to the MAC layer based on the disabled feature reservation of another TB.

[0130] The WTRU may be configured to determine an alternative resource set for random selection based on any one or combination of the following: whether the feature reservation of another TB is enabled or disabled; and / or the CBR of the resource pool. In one example, the alternative resource set for random selection may include the resource set reported from the PHY layer to the MAC layer.

[0131] In one example, the WTRU may be configured to determine the alternative resource set for random selection as X% and Y% of the total resources within the resource selection window when the feature reservation of another TB is enabled and disabled, respectively. This method may allow the WTRU to balance between the conflict probability and quality of the selected resources.

[0132] In one exemplary case, the WTRU may determine the amount of reserved resources for an arriving TB by using the feature reservation of another TB based on one or more of CBR, QoS, and / or broadcast type. The range of the amount of reserved resources for each TB may be configured for the WTRU based on the CBR of the resource pool, the QoS of the TB, and / or the broadcast type.

[0133] In one exemplary method, if the resource pool's CBR is higher or lower than a threshold, the WTRU may determine to reserve resources for all transmissions of a TB by using the feature reservation of another TB. However, if the resource pool's CBR is lower or higher than the threshold, the WTRU may reserve a resource for the initial transmission or retransmission of the TB by using the SCI associated with another TB.

[0134] In another exemplary approach, the WTRU may determine to reserve one or more resources for all transmissions of a TB by reserving a feature of another TB for the TB with high QoS requirements. In the example, high QoS requirements may include one or more TBs with high priority, high reliability, or low latency. Additionally or alternatively, the WTRU may determine to reserve a resource for the initial transmission or retransmission of a TB with low QoS requirements by reserving a feature of another TB. Because all transmission resources for the TB are reserved in advance, this method allows the WTRU to reduce conflicts for TBs with high QoS requirements.

[0135] In another exemplary approach, the WTRU may determine to reserve one resource for the initial transmission of a TB when associated with unicast / multicast traffic, and to reserve one or more resources for all transmissions of another TB when associated with broadcast traffic. Then, if the WTRU reserves resources only for the initial transmission, the WTRU may perform dynamic resource selection for one or more retransmissions of the TB.

[0136] In one exemplary scenario, the WTRU can determine the sensing window based on which reservation in the resource pool supports another TB feature. The WTRU can determine the sensing window in a resource pool based on whether SPS and / or dynamic resource reservation are supported / enabled in the resource pool. Specifically, multiple resource pools can be configured for the WTRU, with each resource pool configured with a sensing window depending on which resource reservation feature is supported in the resource pool.

[0137] In some exemplary cases, the WTRU may perform one or more procedures for resource selection and / or reselection. In one exemplary case, one or more procedures for resource exclusion may exist. During the resource allocation process, the WTRU may determine whether to exclude resources in the time slots required for its monitoring of a reserved target PSSCH / PSCCH transmission. The reserved target PSSCH / PSCCH transmission may belong to a service operated by the WTRU. This determination may be based on one or more of the following: the QoS of the TB; the QoS of the reserved target PSSCH / PSCCH; the relative QoS between the WTRU's TB and the TB associated with the reserved PSSCH / PSCCH; the amount of selectable resources before and after excluding the reserved time slots; and / or the CBR of the resource pool.

[0138] In an example involving QoS of a TB, if the QoS priority of the TB is higher / lower than a threshold, the WTRU may determine not to exclude any time slot with a reserved target PSSCH / PSCCH, and if the priority of the TB is lower / higher than the threshold, it may determine to exclude all reserved PSSCH / PSCCGs. In another example involving QoS of a reserved target PSSCH / PSCCH, the WTRU may exclude time slots with a reserved target PSSCH / PSCCH transmission whose associated TB's QoS is greater than a threshold. Otherwise, if the associated TB is less than the threshold, the WTRU may not exclude the associated time slot. In an example involving the amount of selectable resources before and after excluding reserved time slots, the WTRU may progressively exclude time slots with reserved target PSSCH / PSCCH transmissions from highest to lowest priority until the set of selectable resources is greater than a threshold.

[0139] In one exemplary scenario, the Tx WTRU can semi-persistently reserve resources for non-periodic or periodic traffic. The WTRU can determine one or more of the following parameters for the reserved resource: the effective period of the reserved resource; the minimum and maximum values ​​of the effective period; and / or the probability of retaining the reserved resource. For example, after each effective period, the WTRU can randomly select a value. If the value is less than the probability of retaining the reserved resource, the WTRU can continue to use the reserved resource. Otherwise, the WTRU can perform resource reselection.

[0140] These parameters for reserving resources can be determined based on one or more of the following: resource pool configuration; data QoS; and / or the congestion level of the resource pool or the channel occupancy rate of the WTRU. Regarding data QoS, in one example, the WTRU can be pre-configured or configured using a mapping between the effective time period or the probability of reserving the resource and the priority of the TB. This method can be encouraged to allow high-priority data to retain the resource for longer periods, thereby avoiding conflicts with other / lower-priority data.

[0141] In one exemplary scenario, the WTRU can divide resources reserved by other WTRUs into multiple groups and gradually remove each resource from the selectable resource set or gradually add each resource to the selectable resource set. Similar to LTE V2X, during the resource allocation process, the WTRU can consider all resources within the resource selection window as candidate resources. The WTRU can then determine the unexcluded resource set, which may be the candidate resource set after excluding some resources reserved by other WTRUs. The WTRU can then determine the selectable resource set by selecting a certain percentage (e.g., 20%) of the candidate resources from the unexcluded resource set. Subsequently, the WTRU can randomly select one or more resources from the selectable resource set for its transmission.

[0142] In an example applicable to NR V2X, the WTRU can group resources reserved by other WTRUs and progressively remove each resource from each group from either the unexcluded resource set or the selectable resource set. Additionally or alternatively, the WTRU can progressively add each resource from each group to the excluded resource set. The addition or removal process can terminate if one or more of the following conditions are met: the number of unexcluded resources is greater than X% of the total resources; the number of unexcluded resources is greater than X; the number of selectable resources is greater than X% of the total resources; the number of selectable resources is greater than X; the number of excluded resources is greater than X% of the total resources; and / or the number of excluded resources is greater than X.

[0143] The criteria for grouping reserved resources can be determined based on one or more of the following: the QoS of the reserved resources; potential timing conflicts; and / or the type of reserved resources. Regarding the QoS of reserved resources, the WTRU can group them into high-QoS resources and low-QoS resources. Regarding the type of reserved resources, in one example, the WTRU can group the reserved resource set into one of the following: a group of dynamically reserved resources; a group of semi-persistently reserved resources; and / or a group of feedback-based HARQ retransmission resources. In one example, a group of dynamically reserved resources can be used for one transmission within a TB. Additionally, a group of semi-persistently reserved resources can be used semi-statically for multiple transmissions. Furthermore, a group of feedback-based HARQ retransmission resources can be used for feedback-based HARQ retransmissions.

[0144] In one exemplary method, the WTRU may divide the resource set reserved by other WTRUs into multiple groups, wherein the set of groups may contain at least a group of low QoS (such as priority) resources and a group of high QoS resources. The WTRU may progressively add resources from the low QoS resource group to the excluded resource set, and then add resources from the high QoS resource group, until an addition condition is met. Additionally or alternatively, the WTRU may progressively remove resources from the selectable resource set from the high QoS group, and then remove resources from the low QoS group, until a removal condition is met. This method may be activated to allow the WTRU to avoid selecting reserved resources from high QoS data.

[0145] In another exemplary approach, the WTRU may divide the set of reserved resources into at least two groups, wherein the first group may include reserved resources with potential conflicts in a first window (e.g., a resource selection window), and the second group may include reserved resources with potential conflicts in a second window (e.g., a window with a resource reservation window). The WTRU may sequentially add reserved resources from the second group and the first group to the excluded resource set. This approach may be activated to allow the WTRU to determine that current transmissions take precedence over future transmissions.

[0146] In one exemplary scenario, the WTRU may determine a threshold for excluding reserved resources during the resource selection process. If the sidelink-RSSI (SL-RSSI) or RSRP of a resource is greater than the threshold, the WTRU may exclude the resource reserved by another WTRU. This threshold may be determined based on one or more of the following: the QoS of the TB; the congestion level of the resource pool; and / or the type of reserved resource.

[0147] Regarding the QoS of TBs, similar to LTE V2X, a threshold for determining the availability of resource pools can be determined based on the priority of reserved TBs and the priority of pending TBs. However, this threshold can also be determined based on the minimum communication range of pending TBs and / or the minimum communication range of TBs with reserved resources.

[0148] Regarding the congestion level of the resource pool, specifically, the WTRU can be configured using different thresholds based on the CBR range of the resource pool. For example, the WTRU can be configured using a threshold of the first CBR range, and the threshold of the second CBR range can be determined by the offset of the threshold of the first CBR range.

[0149] Regarding the type of reserved resources, in one example, WTRU can be configured with a threshold for each of the following reserved resources: reserved resources for blind retransmission; reserved resources for feedback-based blind retransmission; and / or reserved resources for initial transmission.

[0150] In another exemplary case, a method for considering time slots is provided. In the example, a method for considering non-monitored time slots may be considered.

[0151] FIG. 2 This is a schematic diagram illustrating an example of a potentially reserved time slot when the WTRU is not monitoring it in a time slot. Generally, the WTRU can determine the availability of a potentially reserved time slot when it is not monitoring a time slot. As shown in the example of schematic diagram 200, a time slot starting from time m can be referred to as time slot m. Furthermore, time slot m may include transmission resources, such as transmission resources 210 and 220, where resource 210 can be used for control transmission and resource 220 can be used for data transmission. In one example, the WTRU may trigger resource selection at time slot n to select a transmission resource in the resource selection window [n+T1, n+T2]. In another example, the WTRU may exclude time slots with time gaps P1, P2, and P3 along with time slot m.

[0152] In a specific example, when the WTRU is not monitoring in time slot m, the WTRU can move time slot m+k*P. i Considered as potentially reserved time slots, where k is an integer and P i Reserve all possible time slots supported in the resource pool. FIG. 2 In the example shown, Pi It may include at least P1, P2 and P3.

[0153] In one exemplary method, during a resource allocation period when the WTRU is not monitoring a time slot, the WTRU can determine the availability of any potentially reserved time slots. In one example, the WTRU may not be monitoring a time slot when it needs to transmit. The availability of a potentially reserved time slot can be determined based on one or more of the following: the resource pool's CBR; the QoS of the TB; and / or the TB's traffic type.

[0154] Regarding the resource pool's CBR, in one example, when the resource pool's CBR is greater than a threshold, the WTRU may determine a potentially reserved time slot as unavailable. Conversely, when the resource pool's CBR is less than a threshold, the WTRU may determine a potentially reserved time slot as available. If the WTRU considers a potentially reserved time slot available, it may include resources from those time slots for use in the selectable resource set. Conversely, if the WTRU considers those time slots unavailable, it may exclude resources from those time slots from the selectable resource set.

[0155] Regarding TB QoS, in one example, if the TB's priority / delay threshold is exceeded, the WTRU can determine whether a potentially reserved time slot is available or unavailable. In another example, only the priority threshold can be used. In yet another example, only the threshold example can be used.

[0156] Regarding the TB traffic type, this determination criterion is suitable for situations where the WTRU determines whether a potentially reserved time slot is available or unavailable based on whether it performs dynamic resource selection or semi-persistent resource selection. Specifically, if the WTRU performs dynamic resource selection, it can determine that the potentially reserved time slot is available, and if the WTRU performs resource selection for semi-persistent use, it can determine that the potentially reserved time slot is unavailable.

[0157] In an exemplary scenario, the WTRU may perform one or more processes for resource sorting as provided herein. In one exemplary method, the WTRU may divide a set of resources in a resource selection window into multiple groups, each group being associated with a resource group sort. The WTRU may then perform sorting on the resources within each group. Specifically, the WTRU may divide the set of resources in the resource selection window into any combination or more of the following groups: a first group, which may be referred to as group 1, and may consist of resource sets not reserved by other WTRUs or by itself; and / or a second group, which may be referred to as group 2, and may include resource sets reserved by other WTRUs.

[0158] In one example, the WTRU can perform ordering of resources within a group of resources reserved by other WTRUs based on an incrementing or decrementing value of f(QoS)*g(RSRP / RSRQ / RSSI)]. In an exemplary method, the WTRU can perform ordering of resources within a group of resources reserved by other WTRUs based on an incrementing or decrementing value of f(QoS, RSRP, or RSRQ). For example, the WTRU can base its order on... The values ​​are used to sort the reserved resources in these groups, where the higher-ranked resources (which may not be selectable) are... The low value is associated with it.

[0159] In another example, WTRU can progressively include resources from a group into a selectable set of resources. In one approach, WTRU can select a group sequentially from lowest to highest sort order, and then progressively include each resource in each group sequentially from lowest to highest sort order until the number of selectable resources exceeds a threshold. Alternatively, WTRU can select a group sequentially from highest to lowest sort order, and then progressively exclude each resource in each group sequentially from highest to lowest sort order until the number of excluded resources exceeds a threshold.

[0160] In an exemplary scenario, the WTRU may perform one or more procedures for determining a resource selection window. In one exemplary method, the WTRU may determine a resource selection window for the next resource in a TB based on the time resources of a previously selected resource and the maximum reservation signaling between the two resources. Specifically, for the first selected resource of the TB, similar to LTE V2X, the WTRU may determine the resource selection window as [n+T1, n+T2], where the value of T1 may be determined based on the WTRU's capabilities and the value of T2 may be determined based on the TB's latency and reliability. We can assume the earliest and latest WTRU times for the previously selected resources to be n+Tmin and n+Tmax, respectively, where Tmin = Tmax when the WTRU selects the first resource for retransmission. Additionally, we can assume the maximum reservation signaling between the two resources to be N. The WTRU may determine the resource selection window for the following resources as [min(n+Tmin-N, n+T1), max(n+Tmax+N, n+T2)].

[0161] In another exemplary approach, the WTRU may determine a fixed selection window size for a transmission and may determine a resource selection window for the next transmission based on the resources selected in the previous transmission. In one exemplary approach, we may assume that the WTRU may select n+k time slots for the previous transmission of the TB, and the WTRU may determine the resource selection window for the next transmission as [n+k, n+k+C]. The WTRU may determine the resource selection window for the initial transmission as [n+T1, n+T1+C]. In another exemplary approach, the WTRU may determine the resource selection window for a transmission within the window [n+T1+(k-1)*C, n+T1+k*C], where k is an integer value. In both exemplary approaches, C may be fixed or configurable based on one or any combination of: the QoS of the TB; and / or the CBR of the resource pool.

[0162] In one exemplary scenario, the WTRU can determine which type of resource selection to perform for a unicast / multicast TB. The WTRU can support one or more of the following resource allocation types for unicast / multicast TBs: HARQ-based retransmission only; and / or a combination of blind retransmission and HARQ-based retransmission.

[0163] For HARQ-based retransmissions only, the resources for the next transmission of the TB can occur before the HARQ feedback time of the previous transmission. For a combination of blind retransmissions and HARQ-based retransmissions, the next transmission of the TB can occur before or after the HARQ feedback time of the previous transmission.

[0164] The WTRU may determine the type of resource selection to perform based on one or more of the following: the QoS of the TB; pool configuration; the time interval between the PSSCH / PSCCH and its associated PSFCH; and / or the time interval between the PSFCH and the next HARQ-based PSSCH / PSCCH retransmission. In the example, the QoS of the TB may include priority, latency, and reliability. In one example, if the latency is greater than a threshold, the WTRU may perform resource selection based solely on HARQ-based retransmissions. Alternatively, if the latency is less than a threshold, the WTRU may perform a combination of blind retransmissions and HARQ-based retransmissions.

[0165] In some exemplary cases, the WTRU may determine the selection window for the next resource based on the result of a previously selected resource allocation type for HARQ-based retransmissions only. The WTRU may determine the resource selection window for that resource as [n+T1, n+T2]. The value of T2 may be determined based on the delay of the TB and the number of transmissions required for the TB. We may assume that the WTRU selects the first resource at time slot n+k and the associated PSFCH at subframe n+k+a. The WTRU may determine the resource selection window for the next resource as [n+k+a+Δ, n+T2], where Δ may be fixed based on the time gap between the PSFCH and the next HARQ-based PSSCH / PSCCH retransmission. If n+k+a+Δ > n+T2, the WTRU can complete the resource selection process.

[0166] In one exemplary scenario, the WTRU may determine selection windows for initial transmission resources and HARQ-based retransmission resources. In one exemplary method, the WTRU may determine the resource selection windows for initial transmission and HARQ-based retransmission as [n+T1, n+T3] and [n+T3, n+T2], respectively, where the value of T2 may be determined based on the latency requirement of the TB, and the value of T3 may be fixed or may be determined based on one or more of the following: the number of selectable resources; the QoS of the TB; the CBR of the resource pool; and / or the QoS of the TB; and / or the CBR of the resource pool. Regarding the QoS of the TB, the value of T3 may be determined as half of the latency requirement of the TB.

[0167] Specifically, regarding the number of selectable resources, the value of T3 can be determined such that the number of selectable resources within [n+T1, n+T3] is greater than a threshold. Alternatively, the value of T3 can be determined such that the number of selectable resources within the window [n+T1, n+T3] is greater than X% of the total number of selectable resources within the window [n+T1, n+T2]. The value of X can be fixed or determined based on one or more of the following: the QoS of the TB and / or the CBR of the resource pool.

[0168] In another exemplary method, the WTRU may determine the first resource selection window and the second resource selection window as [n+T1, n+T3] and [n+k+a+Δ, n+T2], respectively, where n+k and n+k+a are the time slots used for the initial transmission and its associated PSFCH. The value of Δ may be fixed according to the time interval between the PSFCH and the next HARQ-based PSSCH / PSCCH retransmission.

[0169] In one exemplary scenario, the WTRU can determine, based on the availability of selectable resources, to change from a resource allocation type of HARQ-only retransmission to a combination of blind retransmission and HARQ-based retransmission resource allocation types. Specifically, during the resource selection process for the HARQ-only retransmission resource allocation type, if the amount of selectable resources within the resource selection window is less than a threshold, the WTRU can switch to a combination of blind retransmission and HARQ-based retransmission resources to guarantee the QoS of the TB.

[0170] In one exemplary scenario, the WTRU can determine, based on the timing of the PSFCH resource, which PSFCH resource feeds back the status of multiple PSSCH / PSCCH transmissions for use in one or more TBs of transmission. For example, the WTRU can receive one PSSCH / PSCCH transmission and one blind PSSCH / PSCCH retransmission for one TB, where each PSSCH / PSCCH transmission can be associated with a PSFCH resource. Furthermore, the WTRU may need to determine which PSFCH resource feeds back the HARQ status of these PSSCH / PSCCH transmissions. The WTRU can determine which PSFCH resource feeds back the status of multiple PSSCH / PSCCH transmissions based on the timing of the PSFCH resource. Specifically, in one approach, if it has sufficient time to decode the PSSCH / PSCCH transmission and prepare the HARQ feedback, the WTRU can select the PSFCH resource associated with the first PSSCH / PSCCH transmission; otherwise, the WTRU can select the PSFCH associated with the second PSSCH / PSCCH transmission. In another approach, the WTRU can use the PSFCH associated with the second PSSCH / PSCCH.

[0171] In one exemplary scenario, the WTRU can determine the time slot for transmitting the initial transmission message based on the selected resources used for the initial transmission and the QoS of the TB. For example, the WTRU may need to determine the time slot for transmitting the initial transmission reservation message in order to reserve that resource for the initial transmission of the TB. The WTRU can be configured with different sets of time slots between the reserved PSSCH / PSCCH resources and the initial transmission indication transmission. The range of time slots can be determined based on QoS, such as the priority of the TB. Since WTRUs with different priorities can receive reservation messages from each other and can perform conflict avoidance if necessary, this method can reduce conflicts between low-priority TBs and high-priority TBs.

[0172] In one exemplary scenario, the WTRU may determine two resource selection windows for the initial transmission and one or more retransmissions. For example, the WTRU may determine two resource selection windows, one window for resource selection of the initial transmission and the other window for resource selection of one or more retransmissions. Furthermore, the WTRU may use the initial transmission in the first resource selection window to reserve the resource for retransmissions in the second resource selection window.

[0173] In one exemplary method, the WTRU may determine a first resource selection window and a second resource selection window as [n+T1, n+T3] and [n+T3, n+T2], respectively. In another method, the WTRU may determine a first resource selection window and a second resource selection window as [n+T1, n+T3] and [n+k+Δ, n+T2], where n+k is the time slot used for initial transmission and Δ can be determined based on the WTRU's processing capacity. In both methods, the values ​​of T2 and T3 can be determined based on the QoS of the TB and the CBR of the resource pool. Specifically, the value of T2 can be determined based on the latency requirements of the TB and the CBR of the resource pool. The value of T3 can be determined based on the latency requirements of the TB, reliability, and / or the CBR of the resource pool.

[0174] In one exemplary scenario, the WTRU may perform a resource contention process for an initial transmission in a first resource selection window and use the SCI of the initial transmission to reserve resources for one or more retransmissions in a second resource selection window. Specifically, the resource contention process may include one or more of the following processes: a backoff process; and / or an idle channel assessment (CCA) process.

[0175] For the backoff process, the WTRU can generate a backoff value after triggering resource allocation. The WTRU can then decrease this backoff value until it is equal to or less than zero. The backoff value can be decreased when the WTRU determines that one or more resources in a time slot are available for its transmission.

[0176] For the CCA process, WTRU can determine the availability of resources by measuring the received signal strength (RSS) of one or more resources.

[0177] In one exemplary scenario, the WTRU may perform a random selection of selectable resources for retransmission in a second resource selection window. The selectable resource set can be determined through a resource selection process similar to that in LTE V2X. Specifically, the selectable resource set may be determined after excluding resources reserved by other WTRUs and selecting the best resource after sorting the remaining resources.

[0178] In the examples provided herein, the WTRU can perform resource reselection. In one exemplary case, the WTRU can perform resource reselection for a set of reserved resources if the resource utilization of reserved resources is less than a threshold. Specifically, the WTRU can be configured with a resource utilization threshold for a set of reserved resources corresponding to a sidelink procedure. The utilization threshold can be configured based on the QoS of the data and / or the CBR of the resource pool. The WTRU can determine the resource utilization of a set of reserved resources as the ratio of used to unused resources over a period of time.

[0179] In one exemplary method, if the successful transmission rate is less than a threshold, the WTRU may perform resource reselection for the reserved resource set used for unicast / multicast. If the Tx WTRU receives a HARQ ACK feedback, the Tx WTRU may consider the transmission successful. If the WTRU receives a HARQ NACK from the Rx WTRU or does not receive feedback, the WTRU may consider the transmission a failure.

[0180] In another exemplary approach, if the WTRU is operating in network scheduling mode, the WTRU may report resource utilization to the network to support the network during scheduling. Additionally or alternatively, the WTRU may report transmission success rate to the network based on HARQ feedback from the receiver WTRU. Reporting in both approaches may be configured periodically or based on triggering conditions. Triggering conditions may include, for example, when the utilization of the reserved resource set or the transmission success rate is less than a threshold.

[0181] In some exemplary cases, the WTRU may perform resource assessment, reassessment, or both. Based on the initial design of NR V2X, the WTRU may perform resource assessment or reassessment for the resources selected and / or reserved by the WTRU to determine whether resources need to be reselected due to potential conflicts with other WTRUs.

[0182] In one example, the WTRU may determine whether to trigger a resource re-evaluation of the selected set of resources. In one exemplary approach, the WTRU may determine whether it needs to trigger a resource re-evaluation of the selected set of one or more resources based on one or any combination of the following: the time between the time slot in which it selects the resource and the time slot in which the resource was initially selected; and / or the remaining latency budget in TB.

[0183] In one example, the WTRU may determine whether to trigger a resource reassessment based on the time between the time slot it selects for the resource and the time slot of the first resource selected. Specifically, in one example, the WTRU may trigger a resource reassessment if the time between the time slot it selects for the resource and the time slot of the first resource selected is less than a threshold. Otherwise, the WTRU may not trigger a resource reassessment. This threshold may be determined based on one or any combination of the following: a fixed, configured, or pre-configured threshold; the QoS of the TB; and / or the CBR of the resource pool. For example, the WTRU may be configured or pre-configured using a time slot threshold based on the resource pool's CBR. Specifically, if the CBR is low, the WTRU may be configured or pre-configured using a long time slot threshold, and if the CBR is high, the WTRU may be configured or pre-configured using a short time slot threshold. In examples related to fixed, configured, or pre-configured thresholds, the time slot threshold may be a fixed value, configured or pre-configured according to the resource pool. In examples related to the QoS of the TB, the time slot threshold may be configured or pre-configured based on the TB's priority. For example, for high-priority TBs, short time interval thresholds can be used to configure or pre-configure WTRUs, while for low-priority TBs, long time interval thresholds can be used to configure or pre-configure WTRUs.

[0184] In another example, the WTRU can determine whether it needs to perform a resource reassessment based on the remaining latency budget of the TB. Specifically, in one example, if the remaining latency budget of the TB is greater than a threshold, the WTRU can trigger a resource reassessment. Otherwise, the WTRU may not trigger a resource reassessment. The latency budget threshold can be determined based on one or any combination of the following: a fixed, configured, or pre-configured threshold; the CBR of the resource pool; and / or the resource reselection type of the TB. For example, for HARQ-based retransmissions, a high latency budget threshold can be used to configure or pre-configure the WTRU, and for blind retransmissions, a low latency budget threshold can be used. Regarding the CBR of the resource pool, in one example, the WTRU can be configured or pre-configured using a latency budget threshold based on the CBR of the resource pool. For example, if the CBR is low, a high latency budget threshold can be used to configure or pre-configure the WTRU, and if the CBR is high, a low latency budget threshold can be used. Furthermore, this method allows the WTRU to select sufficient available resources after a resource reassessment. In examples related to fixed, configured, or pre-configured thresholds, the latency budget threshold can be a fixed value, configured or pre-configured according to the resource pool.

[0185] In one exemplary method, the WTRU may trigger a resource reassessment in a time slot between the time slot in which the WTRU initially selects a resource and the time slot in which the initially selected resource is used. The WTRU may determine the resource reassessment triggering timing based on one or any combination of the following: the QoS of the resource pool (TB) and / or the CBR of the resource pool. In an example related to the QoS of the TB, the WTRU may be configured or pre-configured based on the QoS of the TB using the maximum and / or minimum time slot between the initially selected resource and the reassessment trigger, and then the WTRU may determine the resource reassessment timing to satisfy the configured or pre-configured time slots. Furthermore, in an example related to the CBR of the resource pool, if the CBR of the resource pool is low, the time slot between the resource reassessment trigger and the initially selected resource may be large, and if the CBR of the resource pool is high, the time slot between the resource reassessment trigger and the initially selected resource may be small.

[0186] In one example, the WTRU determines the value of the time interval. In one exemplary case, the time interval can be used to configure or pre-configure the WTRU. For example, the time interval may be referred to as T3. In one exemplary case, the WTRU can be configured or pre-configured using the time interval T3 between the maximum resource reassessment timing and the first selected resource. The value of T3 can be determined based on the QoS of the TB and / or the CBR of the resource pool. Specifically, T3 can be larger for low-priority TBs and smaller for high-priority TBs.

[0187] In one exemplary approach, the WTRU may change one or more resources from the previous iteration to one or more resources from the current iteration. After resource re-evaluation, the WTRU's PHY layer may report a set of selectable resources, such as set A, to the MAC layer, which may then randomly select a set of resources for the TB transmission. The WTRU's MAC layer may randomly reselect the set of resources for retransmission. If one or more of the previously selected resources are not in the selectable set, the MAC layer may perform resource selection. If the MAC layer determines to perform resource selection, it may perform one or more of the following: reselect at least one of the conflicting resources; and / or reselect the entire set of previously selected resources. In one example, reselection may be performed based on association. For example, reselection may be performed based on association with the initially selected resources. Furthermore, reselection may be performed based on association with the first resource.

[0188] The WTRU can determine whether to reselect at least one of the conflicting resources or the entire set of previously selected resources based on one or any combination of the following: the transport type of the TB and / or the QoS of the TB. Regarding the transport type of the TB, in one example, if the WTRU uses HARQ-based retransmissions for the TB, the WTRU can determine to reselect the entire set of previously selected resources. In another example, if the WTRU uses HARQ-based retransmissions for the TB, the WTRU can determine to reselect the entire set of previously selected resources, and if blind retransmissions are used for the TB, the WTRU reselects at least one of the conflicting resources. Therefore, the WTRU can determine to reselect additional resources based on the HARQ state of the first resource. Furthermore, regarding the QoS of the TB, in one example, if the priority of the TB is higher than a threshold, the WTRU can determine to perform resource selection for that at least one of the conflicting resources. Otherwise, the WTRU can perform resource selection for the entire set of previously selected resources.

[0189] In one exemplary method, the WTRU may determine to reselect at least one of the conflicting resources. The WTRU may then randomly reselect one or more resources for transmission based on the number of conflicting resources. The WTRU may then determine a window for reselecting one or more resources based on the timing of the remaining resources and the HARQ round-trip time (RTT). For example, if the WTRU performs resource reselection for the first resource in the resource set used for a HARQ-based retransmission TB, the WTRU may exclude the second resource from the set of selectable resources within the HARQ RTT.

[0190] In one exemplary scenario, when the WTRU needs to perform resource selection for unicast and / or multicast traffic, the WTRU may select resources based on the availability of CSI reports. Specifically, in one example, if the CSI measured in a set of sub-channels is available, the WTRU may perform resource selection in that set of sub-channels with the relevant CSI report. Otherwise, if the CSI report or the wideband CSI report is unavailable, the WTRU may perform resource selection across the entire resource pool. In another exemplary approach, the WTRU may apply different sets of RSRP thresholds between resources with CSI reports and resources without CSI reports.

[0191] In another exemplary approach, the WTRU may determine when to stop RSRP increments while performing a resource assessment or reassessment to determine the available resource set. Specifically, the WTRU may be configured or pre-configured during the resource reassessment process with a maximum RSRP threshold and / or a maximum number of RSRP increments. The maximum RSRP threshold and / or the maximum number of RSRP increments may be determined based on one or any combination of the following: the configured or pre-configured increments, the QoS of the TB, and / or the CBR of the resource pool.

[0192] In examples relating to configured or pre-configured increments, a fixed number of RSRP increments can be configured or pre-configured for the WTRU. Furthermore, the WTRU can subsequently stop RSRP incrementing when the number of RSRP increments reaches a threshold.

[0193] Regarding the QoS of a TB, in one example, the WTRU can be configured or pre-configured. For example, the WTRU can be configured or pre-configured based on the TB's priority using the maximum number of RSRP increments. Furthermore, for high-priority WTRUs, the WTRU can be configured or pre-configured using a high value of the maximum number of RSRP increments, and for low-priority TBs, the WTRU can be configured or pre-configured using a low value of the maximum number of RSRP increments.

[0194] Regarding the resource pool's CBR, in one example, if the resource pool's CBR is high, the WTRU can be (pre-)configured using the high value of the maximum RSRP increment. Conversely, if the resource's CBR is low, the WTRU can be configured or pre-configured using the low value of the maximum RSRP increment.

[0195] In an exemplary scenario, the WTRU can perform resource selection for burst traffic. In one exemplary approach, the WTRU can perform resource selection for burst traffic by performing resource contention for each TB in a sub-band. Specifically, in one example, the WTRU can divide the frequency domain of the resource pool into multiple sub-bands. The bandwidth of each sub-band may depend on the size of each TB in the burst traffic. The WTRU can then independently perform a resource contention process for each TB in a sub-band.

[0196] In another exemplary approach, the WTRU may perform a free channel assessment (CCA) and occupy one or more sub-bands to transmit one or more TBs. This approach allows the WTRU to reduce CCA overhead, since the WTRU may need to perform a CCA once for one or more transmissions of one TB or more TBs.

[0197] The WTRU can determine the Maximum Channel Occupied Time (MCOT) each time it accesses a channel, or the WTRU can determine the MCOT over a certain period of time. The MCOT can be determined based on one or any combination of the following: the number of TBs required for resource allocation; the QoS per TB; the bandwidth of the occupied resources; and / or the CBR of the resource pool. For example, if the CBR is low, the WTRU can be configured for a higher MCOT, but if the CBR is high, the WTRU can be configured for a lower MCOT. In the example relating to QoS per TB, the WTRU can determine the MCOT based on the number of transmissions per TB, which can be determined based on the reliability of the TB. Regarding the bandwidth of the occupied resources, in one example, if the WTRU uses higher bandwidth, a smaller MCOT can be configured for the WTRU to balance time and frequency resource usage.

[0198] In one exemplary approach, WTRUs can be combined for backoff processes across multiple TBs. For example, WTRUs can determine resource allocation for burst traffic by determining one or both of the following: the range of the backoff counter; and / or the value of the backoff counter.

[0199] The WTRU can then sequentially perform a backoff process for each TB. This method allows the WTRU to find early resources for transmission. The range or value of the backoff counter can be determined based on one or more of the following: the number of TBs required for resource allocation; the QoS of each TB; and / or the CBR of the resource pool.

[0200] For example, a WTRU can be configured to randomly select a backoff value for a TB within the range [0, N] if it performs a resource selection process for a TB. However, when the WTRU performs a resource selection process for two TBs in a burst of traffic, the WTRU can sequentially select a backoff value for the first TB and the second TB within the range [0, N / 2].

[0201] In an exemplary scenario, the WTRU may perform resource selection that supports congestion control. In one exemplary method, the WTRU may determine a set of resources that are not selectable. Specifically, in one example, the WTRU may determine RSRP / RSRQ / RSSI thresholds to determine whether a resource is selectable. This threshold may be determined based on one or more of the following: the QoS of reserved resources; the QoS of pending TBs; and / or the CBR of the resource pool.

[0202] In one exemplary method, the WTRU may determine an unselectable resource set if it meets the following conditions: the set is reserved by an SCI; and / or the measured RSRP / RSRQ / RSSI of the PSSCH / PSCCH used to reserve the resource set is greater than a threshold. In another example, the threshold may be configured or pre-configured based on the relative priority of the two TBs.

[0203] In another exemplary approach, the WTRU may determine an unselectable resource set if it is reserved by an SCI and the priority indicated in the SCI is one or more of the following: below a threshold; and / or below the priority of the TB to be processed minus Δ. Furthermore, in one example, the value of Δ may be configured or pre-configured.

[0204] In one exemplary scenario, if the number of selectable resources is less than a threshold or the number of unselectable resources is greater than a threshold, the WTRU may determine to perform congestion control by one or more of the following: adjusting transmission parameters; dropping TBs; and / or preempting one or more resources. In one example, adjusting the transmission may include one or more of the following: changing the transmission power, such as reducing the transmission power; changing the number of sub-channels selected per transmission; and / or changing the modulation and coding scheme (MCS). The threshold for performing congestion control may be determined by a fixed TB-based QoS and / or a CBR based on the resource pool.

[0205] In an exemplary scenario, the WTRU may execute one or more methods for preemption. In one method, the WTRU may determine which resource pool is available and which type of reserved resource is allowed to be preempted. The WTRU may determine any combination of the following for preemption in a resource pool based on a pool configuration that can be configured or pre-configured in the WTRU or sent to the WTRU via SIB or RRC: whether preemption is allowed; the priority range or another QoS parameter range of the TB for which preemption is allowed by the WTRU; the priority range or another QoS parameter range of the reserved resources that can be preempted; the minimum priority difference or any QoS parameter difference between the pending TB and the reserved resources that can be preempted; the CBR threshold for allowing preemption; and / or the set of source-ids and / or destination-ids that can be associated with the preemptible reserved resources.

[0206] In one exemplary approach, the WTRU can be configured with a different set of priorities that allow it to preempt reserved resources based on the resource pool's CBR. Specifically, in one example, for a TB, the WTRU can determine whether it is eligible for preemption based on the TB's priority and the resource pool's CBR.

[0207] In another exemplary approach, WTRU can determine whether preemption is allowed based on the resource pool's CBR. Specifically, in one example, preemption may be disallowed if the CBR is greater than / below a threshold. Otherwise, preemption may be allowed if the CBR is less than / greater than the threshold.

[0208] In one exemplary scenario, the WTRU may determine the set of resources that can be preempted based on the characteristics of its TB and the characteristics of reserved resources. Specifically, in one example, the characteristics of the TB to be processed may include one or more of the following: the QoS of the TB; the broadcast type of the TB; and / or the size of the TB.

[0209] In addition, the characteristics of reserved resources may include any combination of the following: QoS of reserved resources; broadcast type of reserved resources; size of reserved resources; initial transmission of reserved resources based on HARQ; retransmission of reserved resources based on HARQ; blind retransmission of reserved resources; and / or initial blind transmission of reserved resources.

[0210] In one exemplary method, the WTRU may determine whether to allow resource preemption based on the QoS of its TB and the QoS of reserved resources. The WTRU may be configured to preempt resources having a priority or other QoS information within a certain range, or having a priority difference or other QoS parameter difference with the WTRU's pending TB greater than a configured or pre-configured threshold. Additionally or alternatively, the WTRU may be configured to preempt one or more resources having the lowest or highest priority difference with its pending TB.

[0211] In another exemplary approach, the WTRU may determine which resources to preempt based on the broadcast type of the TB to be processed, which are associated with one or more broadcast types. For example, if the TB to be processed is unicast, it may only be allowed to preempt unicast traffic. Alternatively, if the TB to be processed is broadcast, it may be allowed to preempt all broadcast types of reserved resources.

[0212] In one exemplary scenario, the WTRU can determine the type of preemption based on the characteristics of the TB. One such preemption could be semi-persistent preemption, where the WTRU preempts a reserved resource and uses the preempted resource semi-persistently. Additionally or alternatively, preemption could be dynamic preemption, where the WTRU preempts a reserved resource and uses the preempted resource for a single transmission.

[0213] WTRU can determine the preemption type in a preemption indication message, where one bit in the preemption indication message can be used to indicate which type of preemption is available. Regarding the duration of the preempted resource, WTRU can determine to perform one of the following: slot-based preemption; and / or symbol-based preemption.

[0214] The duration of a preempted resource can be determined based on one or any combination of the following: the QoS of the pending TB; the size of the pending TB; the information transmitted in the TB; and / or the frequency of reserved resources.

[0215] In one exemplary approach, if the size of the TB is less than a threshold, the WTRU may perform symbol-based preemption. Additionally or alternatively, the WTRU may perform symbol-based preemption for TBs transmitting information such as CSI reports, PC5-RRCs, etc. This approach allows the WTRU to preempt smaller TBs with less time-consuming resource usage.

[0216] In one example, the WTRU can indicate its preemption type in the preemption message to support the receiver WTRU during the sensing and resource selection process. Specifically, for example, the WTRU can implicitly / explicitly indicate whether the preemption type is semi-persistent or dynamic. Furthermore, in one example, the WTRU can also indicate whether preemption is symbol-based or slot-based.

[0217] In one example, a WTRU can implicitly or explicitly represent the set of preempted WTRUs by indicating the preempted resource. In one exemplary approach, a WTRU can implicitly represent the set of preempted WTRUs by indicating the preempted resource in the preemption message. After successfully decoding the preemption message, the receiver WTRU can identify whether it has been preempted by recognizing whether any of its reserved resources overlap with the preempted resource. In another exemplary approach, a WTRU can explicitly indicate the set of preempted WTRUs and the preempted resource in the preemption message.

[0218] In one exemplary scenario, the WTRU can determine the resources used for sending and monitoring preemption messages. In one exemplary method, the WTRU can be configured to send preemption messages in a sub-channel / slot / symbol dedicated to PSCCH. In one example, the WTRU can determine the preemption message in a preemption-dedicated SCI format.

[0219] In another exemplary approach, one or more resource pools can be configured for the WTRU to send preemption messages. Additionally or alternatively, a dedicated sub-channel / time slot can be configured for the WTRU to send preemption messages. The receiver WTRU can monitor preemption indications of dedicated resources to determine whether its reserved resources have been preempted and supports sensing and resource allocation processes.

[0220] In another exemplary approach, the WTRU can be configured with rules relating to the time gap between preemption indication transmission and data transmission. The time gap between preemption indication and data transmission can be configured or pre-configured based on the resource pool. The configured or pre-configured value can be determined based on the time required for the WTRU to decode the preemption indication and cancel its transmission. Additionally or alternatively, it can be configured based on one or any combination of: the QoS of the preempted resource; the QoS of the pending TB; and / or the CBR of the resource pool.

[0221] In one exemplary method, the WTRU can be configured using the time gap between the preemption indication and data transmission based on the QoS of the preempted resource. Therefore, the preempted WTRU can monitor the preemption indication in the configured time slot for preemption based on the QoS of its reserved resources.

[0222] In one exemplary scenario, the WTRU may determine a preemption monitoring indication based on the configuration of its reserved resources and resource pools. In one exemplary method, the WTRU may determine a preemption monitoring indication if it has reserved resources that are allowed to be preempted. Specifically, the WTRU may determine preemption monitoring if one or more of the following apply: the reserved resources belong to a preemptible resource reservation type; the reserved resources belong to a preemptible configuration or pre-configured resource set; the reserved resources are TBs with a preemptible priority; and / or the reserved resources belong to a preemptible broadcast type. In one example, a resource pool may allow preemption of unicast or multicast. In one example, regarding the reserved resources belonging to a preemptible resource reservation type, in one example, the resource pool may allow preemption of semi-persistently reserved resources. Regarding the reserved resources belonging to a preemptible configuration or pre-configured resource set, in one example, the resource set may be preemptible sub-channels and time slots. Regarding the reserved resources of TBs with a preemptible priority, the resources may be a subset of lower priority resources.

[0223] The WTRU can determine the number of preemption messages used for transmission. The Tx WTRU can determine the number of preemption messages for a TB based on one or any combination of the following: the QoS of the preempted resource; the QoS of the pending TB; and / or the CBR of the resource pool.

[0224] In one exemplary method, the WTRU can be configured to send a fixed number of preemption messages for one TB. Additionally or alternatively, the WTRU can determine the number of preemption messages for one TB based on the resource pool's CBR. This method can be activated to guarantee the reliability of the preemption messages.

[0225] In one exemplary scenario, a Tx WTRU may determine the trigger for preempting its TB based on one or any combination of the following: the number of selectable resources during the resource selection process; the CBR of the resource pool; the QoS of the TB; and / or the backoff duration.

[0226] In one exemplary approach, the WTRU may determine to perform preemption if the QoS of the TB exceeds a threshold. For example, the TB's priority may be less than the threshold. Specifically, for example, the WTRU may perform preemption if the TB's latency requirement is less than the threshold or the TB's priority is greater than the threshold.

[0227] In another exemplary approach, the WTRU may perform resource selection for the pending TB. However, if the set of selectable resources is less than a threshold, or the set of reserved or unavailable resources is greater than a threshold, the WTRU may perform preemption. In one example, this threshold may be fixed or may be determined based on the TB's QoS.

[0228] In another exemplary approach, the WTRU may perform contention resolution, which may require the WTRU to perform CCA and / or backoff procedures to determine resources for the transfer of the TB. In one example, if the number of CCAs is greater than a threshold or the backoff time is higher than a threshold, the WTRU may determine to perform preemption. This threshold may be configured or pre-configured based on the QoS of the TB to be processed, or it may be determined based on the QoS of the TB to be processed.

[0229] In one exemplary scenario, specific Rx WTRU behavior may exist when the Rx WTRU detects a preemption indication. In one exemplary method, when the Rx WTRU successfully decodes a preemption indication that preempts a resource overlapping with its reserved resources, the Rx WTRU may determine whether it needs to perform conflict avoidance (which may be performed by the WTRU to minimize resource conflicts between multiple transmissions) based on one or any combination of the following: the RSRP / RSSI of the preemption indication; the QoS of the preempted TB; the QoS of the preempted TB; and / or the QoS associated with one or more preempted resources.

[0230] In one exemplary method, if the WTRU successfully decodes the preemption indication, the WTRU can perform conflict avoidance. In another exemplary method, if the WTRU successfully decodes the preemption indication and the RSRP / RSSI measured from the emption indication message is greater than a threshold, the WTRU can perform conflict avoidance. This threshold can be fixed, configured or pre-configured based on the QoS of the preempted TB or the relative QoS of the preempted TB and the preempted TB.

[0231] The receiving WTRU can perform conflict avoidance by performing one or any combination of the following: performing resource reselection; recoding the TB; and / or discarding the pending TB. In one exemplary approach, the WTRU can perform conflict avoidance by performing resource reselection. For example, the WTRU can perform conflict avoidance by performing resource reselection for a sidelink procedure. Alternatively, the WTRU can perform conflict avoidance by performing resource reselection in other types of procedures. In one example, if the preempting WTRU preempts a resource to use it semi-persistently, the WTRU can perform resource reselection. The WTRU can perform dynamic resource selection for TBs that should be transmitted in the preempted resource. Additionally or alternatively, in one example, if the QoS of the reserved resource is greater than a threshold, the WTRU can perform resource reselection.

[0232] In another exemplary approach, if the percentage or amount of preempted resources is less than a threshold, the receiving WTRU can determine the resources preempted for recoding and / or pruning / rate matching of the TB. This threshold can be determined to ensure that transmission of the TB within the remaining resources still meets the TB's QoS requirements.

[0233] In an exemplary scenario, other WTRUs may exist to determine the availability of a preempted semi-persistent resource. The WTRU may determine the availability of a preempted reserved semi-persistent resource based on the type of preemption. Specifically, in one example, if preemption is used for dynamic transport, the WTRU may determine that the reserved semi-persistent resource remains reserved. Additionally or alternatively, if preemption is used for semi-persistent resource allocation, the WTRU may determine that the reserved semi-persistent resource is released and can be replaced with another semi-persistent resource.

[0234] FIG. 3A This is a schematic diagram illustrating an example of resource selection and sensing. In FIG. 3AIn the example shown, the WTRU can use resources according to the time shown on the x-axis and the frequency shown on the y-axis. The WTRU can reach resource selection trigger at time n and select resources for future transmissions, such as resources 310A, 320A, and 330A. Furthermore, the WTRU can select resources such as resources 310A, 320A, and 330A to be located at and after time m and within the packet delay budget (PDB). In one example, the selected resources can be considered as pre-selected resources. The WTRU can further perform sensing. For example, the WTRU can perform sensing to decode the SCI of one or more other WTRUs. Furthermore, in one example, as a result of sensing, the WTRU can determine the priority and RSRP / RSRQ / RSSI of reserved resources (such as resources 310A, 320A, and 330A). Sensing can be performed according to exemplary procedures described elsewhere in this document. Additionally, the WTRU can perform resource re-evaluation based on the time gap between the selected resources and the remaining PDB. The time gap can be determined according to examples provided elsewhere in this document.

[0235] In one example, the WTRU could be a receiver WTRU. In another example, the WTRU could be a V2X WTRU. In yet another example, the WTRU could be an SL WTRU.

[0236] FIG. 3B This is a diagram illustrating an example of resource reassessment, including resource reassessment triggers. FIG. 3B In the example shown, WTRU can determine to re-evaluate execution resources. Furthermore, FIG. 3B The process can be done in FIG. 3A Those processes occur afterward. In one example, the WTRU may determine that a trigger can be satisfied to perform a resource reassessment. Furthermore, the WTRU may make this determination based on exemplary processes described elsewhere in this document, such as sensing, QoS, latency requirements, or PDB, or any combination thereof. Additionally, the WTRU makes this determination at time k, as... FIG. 3B As shown.

[0237] In one example, the WTRU may determine to re-evaluate the resource and determine not to make any changes to the resource. In another example, the WTRU may determine to re-evaluate the resource and determine to make changes to the resource. For example, the WTRU may determine that one or more pre-selected resources must be removed from the resources to be used. Therefore, one or more resources must be re-selected from the available resources to replace the one or more removed pre-selected resources. For example, the WTRU may determine that one or more pre-selected resources must be removed due to a conflict. For example, the WTRU may determine that one or more pre-selected resources will be used by another WTRU, potentially causing a conflict, as described in examples elsewhere in this document. By performing a resource re-evaluation, the WTRU may perform conflict avoidance accordingly. Furthermore, the WTRU may complete the re-evaluation at time k+T1.

[0238] exist FIG. 3B In the example shown, the WTRU can perform a reassessment and determine that resource 310B must be replaced due to a conflict. Alternatively, the WTRU can replace resource 310B with one or more of resources 320B, 330B, 340, 350, 360, 370, 380, and 390. These resources can be located in the time interval between time m and time k+T2. Furthermore, these resources can be used for one or more TBs. In one example, these TBs may include one or more HARQ-enabled TBs, and in another example, these TBs may include one or more HARQ-disabled TBs, as further described below.

[0239] FIG. 4 This is a schematic diagram illustrating an example of resource reassessment, including TBs with HARQ enabled. In the example shown in schematic diagram 400, the WTRU performs a resource reassessment and reselects resources for the TB or for one or more TBs to enable the HARQ process. FIG. 4 In the example shown, the WTRU must determine the resources to be reselected, which are sufficiently far apart in time to allow the HARQ process to function correctly. For example, the WTRU could reselect resource 450 to replace resource 310B, which had to be replaced due to a conflict, as noted above. However, the WTRU could then choose not to reselect resource 420, as it is too close in time to allow the HARQ process to function correctly. Instead, the WTRU could reselect resource 470, which is sufficiently far apart in time to allow the HARQ process to function correctly. Furthermore, the WTRU could then choose not to reselect resource 430, as it is too close in time to allow the HARQ process to function correctly. Therefore, the WTRU could reselect resource 490, which is sufficiently far apart in time to allow the HARQ process to function correctly.

[0240] In this way, the WTRU can reselect the first resource 310B and replace it with the second resource 450. Furthermore, the WTRU can reselect the third resource 470 based on its association with the second reselected resource 450. Additionally, resource 490 can be reselected. Therefore, since the second resource is associated with the HARQ enabling process, resources 470 and 490 can also be reselected. Thus, resources are reselected based on association.

[0241] In one example, resources 440, 460, and 480 are typically selectable resources, and these resources can potentially be reselected. For example, WTRU can reselect resource 440 instead of resource 450.

[0242] FIG. 5 This is a schematic diagram illustrating an example of resource re-evaluation, including a TB with HARQ disabled. In the example shown in schematic diagram 500, the WTRU performs a resource re-evaluation and reselects resources for TB or one or more TBs to disable the HARQ process. Therefore, the WTRU can determine the resources to be reselected regardless of the time interval required for the HARQ process to function. For example, the WTRU can reselect resource 550 to replace resource 310B, which had to be replaced due to a conflict, as noted above. In one example, the WTRU can continue to use resource 520 even if it is temporally adjacent to resource 550. For example, resource 520 can be reselected and the WTRU can determine to use resource 520 again. Similarly, the WTRU can continue to use resource 530 even if it is temporally adjacent to resource 520.

[0243] In this way, the WTRU can reselect the first resource 310B and replace it with the second resource 550. Furthermore, the WTRU reselects the third resource 520 based on its association with the second reselected resource 550, and in this reselection, resource 520 is reserved as a resource to be used. Additionally, the WTRU can reselect resource 530, and in this reselection, resource 530 is reserved as a resource to be used. Therefore, resources are reselected based on association.

[0244] In one example, resources 540, 560, 570, 580, and 590 are selectable resources that can also potentially be reselected. For example, WTRU can reselect resource 440 instead of resource 550.

[0245] In one example, the WTRU can perform resource selection and determine the set of resources to be used for the transfer. For example, resources may be available for a transfer of one or more TBs. Furthermore, the set of resources to be used for the transfer may be referred to as the previously selected set of resources.

[0246] Furthermore, WTRU can dynamically determine triggers for resource reassessment. WTRU can make this determination based on the feasibility of meeting latency requirements. For example, it may be found that one or more resources can meet latency requirements. In another example, it may be found that one or more resources cannot meet latency requirements. Therefore, these one or more resources may need to be replaced with one or more other resources. Resource reassessment may include the identification of one or more potential conflicts among one or more resources in a previously selected resource set.

[0247] In addition, latency requirements may include the remaining PDB in TB. Furthermore, latency requirements may include the time gap between the previously selected resource and the remaining PDB in the second TB.

[0248] In one example, the WTRU can determine a selectable resource set by performing a resource re-evaluation based on a previously selected resource set and removing one or more resources from the previously selected resource set. Furthermore, the WTRU can reselect at least one first resource from the previously selected resource set. In one example, this at least one first resource may not be in the selectable resource set. Furthermore, the WTRU can reselect the at least one first resource and replace it with at least one second resource from the selectable resource set. Additionally, the WTRU can reselect at least one third resource from the selectable resource set based on its association with the at least one second resource. The WTRU can then use the at least one second resource to launch the first TB.

[0249] In another example, the WTRU can determine the selectable resource set by performing a resource re-evaluation based on a previously selected resource set. Furthermore, the WTRU can select at least one first resource from the previously selected resource set. In one example, this at least one first resource may not be in the selectable resource set. Additionally, the WTRU can replace the first resource with at least one second resource. In one example, this at least one second resource may be in the selectable resource set. Furthermore, the WTRU can select at least one third resource from the selectable resource set based on its association with this at least one second resource. The WTRU can then use this at least one second resource to launch the first TB.

[0250] In an additional example, the WTRU may reselect at least one fourth resource based on its association with the at least one second resource. In yet another example, the WTRU may reselect at least one fifth resource based on its association with the at least one second resource. In an additional example, additional resources may be reselected based on their association with the at least one second resource.

[0251] In one example, one or more resources can be removed based on a conflict. For example, a conflict could be a predicted potential conflict with a transport of another WTRU. In one example, the other WTRU could be a V2X WTRU.

[0252] In one example, the association with the at least one second resource may be based on the HARQ status of the first TB. In one example, the HARQ status may be the HARQ-enabled status of the TB. Therefore, the TB may be a HARQ-enabled TB.

[0253] In another example, the HARQ state could be a disabled HARQ state for a TB. Therefore, a TB could be a TB with HARQ disabled. Furthermore, additional resources could include future HARQ transports associated with the first TB. For example, this at least one third resource could be used for HARQ transports associated with the first TB.

[0254] In another example, the association with the at least one second resource may be based on an authorization. In one example, the authorization may be a periodic reservation authorization. Therefore, the association with the at least one second resource may be based on a periodic reservation authorization associated with the first TB. Furthermore, additional resources may include resources associated with a periodic reservation authorization. For example, the at least one third resource may be associated with a periodic reservation authorization.

[0255] Furthermore, preempted resources can also be periodically reserved resources. In one example, periodically reserved resources can be used by the WTRU to transmit periodically reserved transmissions. Therefore, in one example, preempted resources can be used by the WTRU to transmit periodically reserved transmissions. In another example, the WTRU may intend to use preempted resources to transmit periodically reserved transmissions. Additionally, in one example, after selection or reselection, the WTRU may not use the preempted resources for one or more future periodically reserved transmissions. For example, after selection or reselection, the WTRU may not use at least one first resource for a currently periodically reserved transmission and / or one or more future periodically reserved transmissions. Therefore, the WTRU may assume that the preempted resources may be unavailable in future time periods. In one example, the preempted resources may be unavailable due to conflicts.

[0256] In one example, the preempted resource can be one of the one or more removed resources. For example, the preempted resource can be at least one first resource. Furthermore, periodically reserved transfers can be associated with periodically reserved authorizations.

[0257] The exemplary scenarios provided herein include methods for reservations to support initial transmissions. In one exemplary scenario, the WTRU may determine the resource reservation type. For example, the WTRU may support reservations for the same TB characteristics, wherein a first PSCCH+PSSCH using a first frequency resource allocation reserves the resources for a second PSCCH+PSSCH using a second frequency resource allocation to transmit the same TB. The size of the first frequency resource allocation may be less than, equal to, or greater than the size of the second frequency allocation. The WTRU may determine the difference between the size of the first frequency resource allocation and the size of the second frequency resource allocation based on one or more of the following: the size of the frequency resource allocation for the second PSCCH+PSSCH; the size of the TB; the QoS of the TB; and / or the CBR of the resource pool.

[0258] In one exemplary method, the WTRU can determine the difference between the size of the first frequency resource allocation and the size of the second frequency resource allocation based on the size of the frequency resource allocation of the first PSCCH+PSSCH. Specifically, if the size of the frequency resource allocation of the second PSCCH+PSSCH is less than a threshold, the WTRU can determine that the size of the first frequency resource allocation and the size of the second frequency resource allocation are equal. Alternatively or additionally, if the frequency size of the second PSCCH+PSSCH is greater than the threshold, the WTRU can determine that the size of the first frequency resource allocation is less than the size of the second frequency allocation. For example, if the frequency resource allocation of the first PSCCH+PSSCH is less than or equal to two sub-channels, the WTRU can determine that the frequency resource allocation of the first PSCCH+PSSCH and the second PSCCH+PSSCH are equal. However, if the frequency resource allocation of the second PSCCH+PSSCH is greater than two sub-channels, the WTRU can determine that the frequency resource allocation of the second PSCCH+PSSCH is greater than the frequency resource allocation of the first PSCCH+PSSCH. In one example, the frequency resource allocation of the first PSCCH+PSSCH may be one sub-channel.

[0259] In another exemplary method, the WTRU may determine the difference between the size of a first frequency resource allocation and the size of a second frequency resource allocation based on the size of the TB. Specifically, in one example, if the size of the TB is less than a threshold, the WTRU may determine that the first and second sizes of the frequency resource allocation are equal. Alternatively or additionally, if the size of the TB is greater than the threshold, the WTRU may determine that the size of the frequency resource allocation for the first PSCCH+PSSCH is less than the size of the frequency resource allocation for the second PSCCH+PSSCH.

[0260] In another exemplary approach, the WTRU may determine the difference between the size of a first frequency resource allocation and the size of a second frequency resource allocation based on the QoS of the TB. For example, in one instance, if the delay of the TB is less than a threshold, the WTRU may determine that the frequency sizes of the first PSCCH+PSSCH and the second PSCCH+PSSCH are equal.

[0261] In one exemplary scenario, the WTRU may choose between a reservation for the same TB and a reservation for another TB feature. The WTRU may determine whether to use a reservation for the same TB and / or a reservation for another TB feature based on one or more of the following: the size of a TB and / or the required frequency size of a TB; the QoS of a TB; and / or other information available to the WTRU. In an example relating to the size of a TB and / or the required frequency size, if the WTRU has two TBs at the buffer and the size of one TB is less than a threshold or the required frequency size of one TB is less than a threshold, the WTRU may use a reservation for another TB feature. In one example, the frequency may be a subchannel. Regarding the QoS of a TB, in one example, if the WTRU needs to transmit a low QoS TB, the WTRU may determine to use a reservation for another TB feature. Regarding other information available to the WTRU (which may need to be transmitted by the WTRU), in one example, if the WTRU has CSI information for reporting / transmitting, the WTRU may use a reservation for another TB feature.

[0262] The examples provided in this document include methods for supporting network scheduling. For example, in NR V2X, improved methods for supporting network scheduling may exist. For example, methods for supporting MCS table indication may exist. In one case, the WTRU may indicate its MCS table for PSSCH transmission to the receiving WTRU. The WTRU may implicitly or explicitly indicate the MCS table used to the receiving WTRU. The WTRU may explicitly indicate the MCS table by using one or more bit fields in the SCI. Additionally or alternatively, the WTRU may be configured or pre-configured using a mapping between a set of QoS parameters and the MCS table. The WTRU can then implicitly indicate the MCS table used by transmitting the QoS parameters to the receiving WTRU.

[0263] In an exemplary scenario, methods for supporting feedback-based HARQ retransmissions may exist. In one exemplary scenario, the WTRU may determine which TB to transmit within a grant scheduled by the gNB. The WTRU may have TBs at the MAC buffer and one or more TBs at the HARQ buffer. In one exemplary method, the WTRU may determine which TB to transmit within a grant scheduled by the gNB based on one or any combination of the following: the QoS of each TB, the size of the scheduled grant, the buffer of the TB, whether the TB has been transmitted using UL HARQ, and / or the broadcast type of the TB.

[0264] In examples relating to QoS for each TB, the WTRU may prioritize the TB with the highest priority. Regarding the size of the scheduling authorization, in one example, when the WTRU needs to determine which TB in the HARQ buffer to transmit, the WTRU may preferably prioritize the TB requiring the smallest change in MCS compared to the previous transmission. Additionally or alternatively, the WTRU may preferably prioritize TBs whose MCS is less than or equal to the MCS of the previous transmission.

[0265] Regarding the buffers for TBs, in one example, the WTRU may preferably consider TBs in the HARQ buffer. In an example relating to whether a TB has been transmitted in a UL HARQ, when the WTRU needs to determine which TB in the HARQ buffer to transmit, the WTRU may preferably consider TBs whose NACK status has been transmitted to the gNB. Regarding the broadcast type of TBs, in one example, when two TBs have the same priority, the WTRU may preferably consider broadcast transmission.

[0266] In the example, WTRU can determine the transmission type for retransmissions used in unicast / multicast. WTRU supports the following retransmission types: blind retransmission and / or feedback-based retransmission.

[0267] For blind retransmission, the WTRU can perform blind retransmission by using the same or a different redundant version (RV) as the initial transmission. Additionally, the WTRU can indicate to the receiving WTRU that HARQ feedback should be disabled or that the WTRU may not have monitored HARQ feedback for the initial transmission. For feedback-based retransmission, the WTRU can determine whether to perform a retransmission based on HARQ feedback from the receiving WTRU. Furthermore, the WTRU can listen for HARQ feedback from the receiving WTRU and can instruct the receiving WTRU to enable HARQ feedback.

[0268] The WTRU can determine the retransmission type of the TB based on the timing of the resources scheduled for the initial transmission and retransmission, as well as the timing of the UL HARQ feedback and SL HARQ feedback. In one exemplary method, when the WTRU receives the DCI for scheduling resources for the initial transmission and retransmission, the WTRU can determine to perform a blind retransmission, and the timing of the UL HARQ feedback for the transmission is after the retransmission. In another exemplary method, if the WTRU receives the DCI for scheduling the UL HARQ feedback between the initial transmission and the retransmission, the WTRU can determine to perform a HARQ-based retransmission.

[0269] FIG. 6 This is a schematic diagram illustrating an example of a WTRU that determines the retransmission type based on the timing of the initial transmission, retransmission, and UL HARQ feedback. In the example shown in option 1 of schematic diagram 100, the WTRU can perform blind retransmission, and in option 2, the WTRU can perform HARQ-based retransmission.

[0270] Therefore, in Option 1, the WTRU can receive DCI 610, which schedules resources for initial transmission 630 and retransmission 650, and the timing of UL HARQ feedback 670 for transmission is after retransmission 650. Thus, the WTRU can determine to perform blind retransmission.

[0271] Furthermore, in option 2, the WTRU can receive DCI 620 of the UL HARQ feedback 660 between the initial transmission 640 and the retransmission 680. Therefore, the WTRU can determine to perform a HARQ-based retransmission.

[0272] In one exemplary scenario, the WTRU may receive a DCI (Distributed Controlled Interchange) for scheduling the initial transmission and retransmission timing resources. The WTRU may indicate to the gNB (Garden Node Block) the use of the retransmission resources. The UL HARQ feedback may indicate one or more of the following: the WTRU uses the grant for retransmissions of the same TB; the WTRU uses the grant for a transmission of another TB; and / or the WTRU releases the grant. In another exemplary approach, if the WTRU receives an ACK from the receiver WTRU for the previous transmission, the WTRU may determine to use the retransmission resources scheduled in one DCI for a transmission of another TB.

[0273] In one example, the WTRU can determine the retransmission type for the configured authorization. In one exemplary case, the WTRU can be configured with one or more authorizations of type-1 and / or type-2. The WTRU can determine the retransmission type for the configured authorization based on one or more of the following: the availability of UL HARQ feedback for the configured authorization, the number of resources for a TB of transmission, and / or the time gap between two resources for a TB of transmission. Regarding the availability of UL HARQ feedback for the configured authorization, in an example for a unicast / multicast scenario, if the configured authorization does not include UL HARQ feedback, the WTRU can determine to perform blind retransmission. Furthermore, regarding the number of transmission resources for each TB, in one example, if the number of retransmission resources for each TB is greater than a threshold, the WTRU can perform blind transmission. In an example relating to the time gap between two resources for a TB of transmission, if the time gap between two consecutive resources for a TB of transmission is less than a threshold, the WTRU can determine to perform blind retransmission. Additionally or alternatively, if the time gap between two consecutive resources is greater than a threshold, the WTRU may perform feedback-based HARQ retransmission. Furthermore, in one example, the time gap threshold may be determined based on one or more of the following: the QoS of the data and / or resource pool configuration, such as the periodicity of the PSFCH time slot and the bitmap of the resource pool.

[0274] In an exemplary embodiment, methods for supporting in-coverage and out-of-coverage communication may exist. In one exemplary embodiment, the Tx WTRU may transmit information about its Tx pool to the Rx WTRU. Specifically, the Tx WTRU may implicitly or explicitly transmit information about its Tx pool to the Rx WTRU. The information about the Tx pool may include one or more of the following: the time slot belongs to the resource pool, such as a bitmap of the resource pool; the periodicity of the PSFCH time slots; the subchannel size, the number of subchannels in the resource, and the first and last RBs of the resource pool.

[0275] In one exemplary method, the WTRU may send resource pool information during the link establishment process for a unicast scenario. In another exemplary method, the Tx WTRU may implicitly or explicitly send information about the resource pool in the SCI. Specifically, the WTRU may send information about the PSFCH periodicity in the SCI. Additionally or alternatively, the WTRU may be configured or pre-configured with a list of resource pools to be indicated to the Rx WTRU, and the WTRU may indicate the index of the resource pool to the Rx WTRU. In another exemplary method, the Tx WTRU may indicate information about the resource pool in the PSBCH. For example, the WTRU may indicate one or more of the following information about the resource pool: the PSFCH periodicity of the resource pool in the PSBCH; whether HARQ is enabled / disabled; and / or HARQ feedback options.

[0276] In the example, the WTRU can use resource pool information. In one exemplary case, the Rx WTRU can use the resource pool information sent by the Tx WTRU to determine PSFCH resources to transmit sidelink HARQ feedback, and / or perform sensing and resource selection.

[0277] In exemplary cases, methods may exist to support feedback indications to the network. For example, a problem may arise when a set of resources with associated PUCCHs can be scheduled for the WTRU, and the gNB may expect the WTRU to transmit a TB with HARQ enabled. However, during Logical Channel Prioritization (LCP) allocation, the WTRU may transmit a TB with HARQ disabled. Therefore, it may be necessary to address how the WTRU reports HARQ ACK / NACK to the network.

[0278] A PUCCH resource can be provided to the WTRU in a dynamic or configured grant to report the HARQ status (e.g., ACK / NACK) of its transmissions on the associated grant. In the grant associated with the PUCCH resource, the WTRU can determine the TB (Transmission Transaction) that disables HARQ. The WTRU can then determine whether to report HARQ ACK or HARQ NACK based on one or any combination of parameters.

[0279] One such parameter used to determine whether to report a HARQ ACK or NACK can be the QoS of the TB. For example, if the TB's priority and / or reliability is greater than a threshold, the WTRU may report a HARQ ACK, and if the TB's priority and / or reliability is less than a threshold, the WTRU may report a HARQ NACK. This threshold can be configured via the network or pre-configured.

[0280] One such parameter used to determine whether a report is HARQ ACK or NACK can be a set of authorized logical channels: for example, a set of logical channels can be configured for the WTRU, which will trigger a HARQ ACK / NACK indication when multiplexed in the TB.

[0281] One such parameter used to determine whether to report a HARQ ACK or NACK can be the amount of allocated resources. For example, a WTRU can determine whether to report a HARQ ACK or NACK based on the amount of resources allocated to it. Specifically, if the amount of scheduled resources is greater than a threshold, the WTRU can report a HARQ ACK, and if the amount of scheduled resources is less than a threshold, the WTRU can report a HARQ NACK. This threshold can be fixed and (pre-)configured and / or determined based on the QoS of the final TB transmitted in the scheduled resources.

[0282] One such parameter used to determine whether a HARQ ACK or NACK is reported could be the amount of resources emitted for the final TB before reporting HARQ feedback.

[0283] One such parameter used to determine whether to report HARQ ACK or NACK can be the type of authorization assigned. In the example, the authorization can be a configured authorization or a dynamic authorization. For example, for a dynamic authorization, WTRU may always report HARQ ACK, while for a configured authorization, it may determine whether to report HARQ ACK or HARQ NACK.

[0284] One such parameter used to determine whether a report receives a HARQ ACK or NACK can be the broadcast type.

[0285] One such parameter used to determine whether to report a HARQ ACK or NACK can be the buffer status of the WTRU or any indicator of the amount of data the WTRU needs to transmit. For example, if the buffer status of a Logical Channel Group (LCG), which may be related to the QoS of the transmitted TB, is above a threshold, the WTRU may report a NACK.

[0286] One such parameter used to determine whether to report HARQ ACK or NACK could be CBR: for example, WTRU will report ACK if CBR is above a threshold, otherwise report NACK.

[0287] In one exemplary scenario, the WTRU may determine whether to report a HARQ ACK or HARQ NACK based on the number of transmissions it has already made to its last TB and the priority and / or reliability of the TB. Specifically, the WTRU may determine the expected number of transmissions for the TB based on its priority and / or reliability. The WTRU may then determine whether to transmit a HARQ ACK or NACK based on both the expected number of transmissions for the TB and the number of transmissions it has already made to the TB. If the expected number of transmissions is greater than the number of transmissions the WTRU has already made, the WTRU may report a HARQ NACK. Otherwise, the WTRU may report a HARQ ACK.

[0288] In another exemplary scenario, the WTRU may determine whether to report a HARQACK or HARQ NACK based on the timing and / or quantity of future grants. Specifically, if the future timing of a future grant is less than TB of PDB, the WTRU may report a HARQACK. Otherwise, the WTRU may report a HARQ NACK. Future grants may belong to a set of future resource sets configured for grants or a set of future resource sets dynamically granted.

[0289] In another exemplary scenario, the WTRU may determine whether to report a HARQ ACK or HARQ NACK based on its buffer status and future available resources. Specifically, the WTRU may report a HARQ NACK if it still has data in its buffer (e.g., the data may be stored in a MAC, Radio Link Control (RLC) buffer, or HARQ buffer) and / or future resources are insufficient to meet the QoS of the data pending processing in the buffer. Additionally or alternatively, the WTRU may report a HARQ NACK if it has no data in its buffer.

[0290] WTRU may report HARQ ACK under the exemplary conditions. In another exemplary condition, WTRU may report HARQ ACK if the final TB emitted in the resource with the associated PUCCH is a TB with HARQ disabled.

[0291] In another exemplary scenario, the WTRU can determine whether to multiplex a HARQ-enabled sidelink radio bearer (SLRB) or a HARQ-disabled SLRB in a TB. The priority gap between the HARQ-enabled and HARQ-disabled SLRBs can be configured or pre-configured to determine which type of SLRB to multiplex in the TB for a resource with an associated PUCCH. Specifically, in one example, if the priority of the HARQ-enabled SLRB is greater than or equal to the priority of the HARQ-disabled SLRB plus the priority gap, the WTRU can determine that the HARQ-enabled SLRB takes precedence over the HARQ-disabled SLRB. The priority gap can be configured, pre-configured, or fixed. For example, if the priority gap is fixed to zero, the WTRU can determine that the HARQ-enabled SLRB takes precedence over the HARQ-disabled SLRB in a resource with an associated PUCCH if the HARQ-enabled and HARQ-disabled SLRBs have the same priority.

[0292] In the example, the WTRU may determine to trigger a Scheduling Request (SR) and / or a Buffer Status Report (BSR). In another exemplary approach, the WTRU may be configured with an SR associated with a transmission of a TB with HARQ disabled in a resource with an associated PUCCH. The WTRU may trigger an SR and / or BSR if it transmits a HARQ disabled TB in the final resource associated with the PUCCH. The WTRU may further trigger an SR and / or BSR only if it reports a certain value of ACK or NACK; for example, a BSR is triggered when the WTRU reports a NACK based on any of the conditions discussed herein. The WTRU may further calculate a BSR after using the retransmission resources provided by the network following a NACK report. The WTRU may be further configured or pre-configured using one or any combination of the criteria / conditions for triggering SR and / or BSR.

[0293] One criterion / condition could be the QoS of a TB. For example, if the priority of a TB is greater than a threshold, a WTRU could trigger an SR and / or a BSR.

[0294] One criterion / condition could be the number of transmissions the WTRU has made to the TB. For example, if the number of transmissions the WTRU has made to the final TB is less than a threshold, the WTRU may trigger an SR and / or a BSR. This threshold can be determined based on the TB's QoS. Additionally or alternatively, if the WTRU needs more resources to transmit the final TB, the WTRU may trigger an SR and / or a BSR.

[0295] One criterion / condition could be the buffer state of the WTRU. For example, if the WTRU has data in its buffer, the WTRU can trigger an SR and / or a BSR.

[0296] One criterion / condition could be the amount of allocated resources. For example, if the amount of allocated resources is less than a threshold, the WTRU can trigger an SR and / or a BSR. This threshold can be determined based on the QoS of the TB and can be configured or pre-configured.

[0297] One criterion / condition could be the type of resource allocated. For example, if a TB with HARQ disabled is issued in a configured grant, the WTRU may trigger an SR and / or a BSR, while if a TB with HARQ disabled is issued in a dynamic grant, the WTRU may not trigger an SR and / or a BSR.

[0298] One criterion / condition could be the broadcast type. For example, WTRU could trigger SR and / or BSR based on the broadcast type.

[0299] In one scenario, the WTRU may cancel a pending BSR / SR transmission if it reports a NACK to a transmission without HARQ. Specifically, the WTRU may have a pending BSR transmission due to the arrival of new data, which is possible for higher priority logical channels (LCH). The WTRU may also cancel such a BSR if it determines that it can perform a sidelink transmission for new data in the retransmission resources provided by the network. Specifically, the WTRU may cancel a BSR if: the amount of resources associated with the initial TB is large enough to transmit new data in the buffer; and / or the expected retransmission resource timing will meet the delay requirements of the new data triggering the BSR.

[0300] In one or more embodiments disclosed herein, the WTRU may determine whether it needs to trigger a resource re-evaluation for the selected set of one or more resources based on the time between the time slot of its selected resource and the time slot of the first selected resource, and / or the remaining delay budget of the TB. The WTRU may determine when to trigger a resource re-evaluation. The WTRU may determine the value of T3. The WTRU may change one or more resources from the previous iteration to one or more resources from the current iteration. The WTRU may reselect only the one or more conflicting resources. The WTRU may perform resource selection based on the availability of CSI. The WTRU may determine when to stop RSRP incrementing during resource evaluation or re-evaluation. The WTRU may determine to report HARQ ACK or HARQ NACK. The WTRU may determine to report HARQ ACK / NACK based on the number of transmissions the WTRU has made to the TB and its QoS. The WTRU may determine to report HARQ ACK / NACK based on the timing and / or amount of future authorizations. The WTRU may determine to report HARQ ACK or HARQ NACK based on its buffer state and future available resources. The WTRU may report HARQ ACK. The WTRU can select between an SLRB with HARQ enabled and an SLRB with HARQ disabled for multiplexing in a TB. The WTRU can determine the triggering SR and / or BSR.

[0301] 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 over wired or wireless connections) 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 method for a wireless transmit-receive unit (WTRU), the method comprising: Receive the first data on the first physical side link shared channel (PSSCH) transmission; Transmit the second data on the second PSSCH transmission; Receive third data on the third PSSCH transmission; Based on the first priority associated with the first data, the second priority associated with the second data, and the third priority associated with the third data, the priority division between the transmission of the Physical Side Link Feedback Channel (PSFCH) and the reception of the PSFCH is determined. Given that the transmission of PSFCH has been determined in the priority division, the transmission of a single PSFCH transmission or multiple PSFCH transmissions is determined based on the power level of the first PSFCH transmission associated with the first data and the power level of the second PSFCH transmission associated with the third data. Given that a single PSFCH transmission is determined to be transmitted, based on the first priority associated with the first data and the third priority associated with the third data, it is determined whether the single PSFCH transmission is a first PSFCH transmission or a second PSFCH transmission; and The single PSFCH transmission is transmitted, wherein, under the condition that the single PSFCH transmission is determined to be a first PSFCH transmission, a first Hybrid Automatic Repeat Request (HARQ) Acknowledgment (ACK) / Negative ACK (NACK) feedback associated with the first data is transmitted on the first PSFCH transmission, and wherein, under the condition that the single PSFCH transmission is determined to be a second PSFCH transmission, a second HARQ ACK / NACK feedback associated with the third data is transmitted on the second PSFCH transmission.

2. The method according to claim 1, further comprising: Receive first side link control information (SCI) associated with the first PSSCH transmission.

3. The method according to claim 1, further comprising: Transmit the second SCI associated with the second PSSCH transmission.

4. The method of claim 2, wherein the first priority is based on a first priority value.

5. The method of claim 4, wherein the first priority value is received in the first SCI.

6. The method of claim 4, wherein the second priority is based on a second priority value.

7. The method of claim 6, wherein the second priority value is received in the third SCI.

8. The method of claim 1, wherein the first priority is based on a first quality of service (QoS).

9. The method of claim 1, wherein the second priority is based on a second QoS.

10. The method of claim 1, wherein one of the first HARQ ACK / NACK feedback or the second HARQ ACK / NACK feedback is discarded based on the first priority and the third priority.

11. The method of claim 1, further comprising: Under the condition that the PSFCH reception is determined in the priority division, the third PSFCH transmission associated with the second data is received, wherein the third HARQ ACK / NACK feedback associated with the second data is received on the third PSFCH transmission.

12. The method of claim 1, further comprising: Given that multiple PSFCH transmissions are to be transmitted, a first PSFCH transmission and a second PSFCH transmission are transmitted, wherein a first HARQ ACK / NACK feedback associated with first data is transmitted on the first PSFCH transmission, and a second HARQ ACK / NACK feedback associated with third data is transmitted on the second PSFCH transmission.

13. A wireless transmit / receive unit (WTRU), comprising: transceiver; and A processor, operatively coupled to the transceiver; wherein: The transceiver and the processor are configured to receive first data over a first physical side link shared channel (PSSCH) transmission; The transceiver and the processor are configured to transmit second data over a second PSSCH transmission; The transceiver and the processor are configured to receive third data on a third PSSCH transmission; The processor is configured to determine a priority division between the transmission of the Physical Side Link Feedback Channel (PSFCH) and the reception of the PSFCH based on a first priority associated with the first data, a second priority associated with the second data, and a third priority associated with the third data. The transceiver and the processor are configured to, under the condition that the transmission of PSFCH is determined in the priority division determination, determine whether to transmit a single PSFCH transmission or multiple PSFCH transmissions based on the power level of the first PSFCH transmission associated with the first data and the power level of the second PSFCH transmission associated with the third data. The transceiver and the processor are configured to, upon determining that a single PSFCH transmission has been transmitted, determine whether the single PSFCH transmission is a first PSFCH transmission or a second PSFCH transmission based on a first priority associated with first data and a third priority associated with third data; and The transceiver and the processor are configured to transmit the single PSFCH transmission, wherein, if the single PSFCH transmission is determined to be a first PSFCH transmission, a first Hybrid Automatic Repeat Request (HARQ) Acknowledgment (ACK) / Negative ACK (NACK) feedback associated with the first data is transmitted on the first PSFCH transmission, and wherein, if the single PSFCH transmission is determined to be a second PSFCH transmission, a second HARQ ACK / NACK feedback associated with the third data is transmitted on the second PSFCH transmission.

14. The WTRU of claim 13, wherein the transceiver and the processor are further configured to receive first side link control information (SCI) associated with the first PSSCH transmission.

15. The WTRU of claim 13, wherein the transceiver and the processor are further configured to transmit a second SCI associated with the second PSSCH transmission.

16. The WTRU of claim 14, wherein the first priority is based on a first priority value.

17. The WTRU of claim 16, wherein the first priority value is received in the first SCI.

18. The WTRU of claim 16, wherein the second priority is based on a second priority value.

19. The WTRU of claim 18, wherein the second priority value is received in the third SCI.

20. The WTRU of claim 13, wherein the first priority is based on a first quality of service (QoS).

21. The WTRU of claim 13, wherein the second priority is based on the second QoS.

22. The WTRU of claim 13, wherein one of the first HARQ ACK / NACK feedback or the second HARQ ACK / NACK feedback is discarded based on the first priority and the third priority.

23. The WTRU according to claim 13, wherein, The transceiver and the processor are configured to receive a third PSFCH transmission associated with the second data, provided that the reception of PSFCH is determined in the priority division determination, wherein a third HARQ ACK / NACK feedback associated with the second data is received on the third PSFCH transmission.

24. The WTRU according to claim 13, wherein, The transceiver and the processor are configured to transmit a first PSFCH transmission and a second PSFCH transmission when it is determined that multiple PSFCH transmissions will be transmitted, wherein a first HARQ ACK / NACK feedback associated with the first data is transmitted on the first PSFCH transmission, and a second HARQ ACK / NACK feedback associated with the third data is transmitted on the second PSFCH transmission.

Images