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

Abstract

To provide a method for a HARQ-based transmission.SOLUTION: A WTRU may determine prioritization between a transmission and a reception of a physical sidelink feedback channel (PSFCH) on the basis of a priority associated with data that have been transmitted and received, and determine to transmit a single or multiple PSFCH transmissions on the basis of the power levels of the first and second PSFCH transmissions associated with first and third data that have been transmitted when the transmission of the PSFCH is determined in the determination of prioritization. The WTRU may determine whether the single PSFCH transmission is either the first or the second PSFCH transmission on the basis of first and third priorities associated with the first and third data when the transmission of the single PSFCH transmission is determined, and transmit a first or second HARQ feedback associated with the first or third data in the determined first or second PSFCH transmission.SELECTED DRAWING: Figure 3B

Description

[Technical field]

[0001] (CROSS REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Patent Application No. 62 / 886,160, filed August 13, 2019, U.S. Provisional Patent Application No. 62 / 908,089, filed September 30, 2019, and U.S. Provisional Patent Application No. 62 / 975,552, filed February 12, 2020, the contents of which are incorporated herein by reference. [Background technology]

[0002] Generally, in a wireless communication system, a device may need to operate within resources such as time and frequency with respect to other devices, including devices with which it is communicating. Various techniques and methods may be required to manage and share the resources available for wireless communication. Long Term Evolution (LTE) vehicle-to-everything (V2X) features support basic safety functions.

[0003] New radio (NR) V2X operation is being developed. V2X communication may include one or more of vehicle-to-vehicle (V2V), vehicle-to-pedestrian (V2P), vehicle-to-infrastructure (V2I), and vehicle-to-network (V2N) communications. A V2X wireless transmit receive unit (WTRU) may be involved in V2X communications. Summary of the Invention

[0004] Disclosed herein are systems, methods, and devices for sensing and resource allocation in New Radio (NR) vehicle-to-everything (V2X) scenarios. A wireless transmit / receive unit (WTRU) may perform resource selection to determine a set of resources to be used for transmission. For example, the resources may be used to transmit one or more transport blocks (TBs). The set of resources used for transmission may be referred to as a previously selected set of resources.

[0005] Furthermore, the WTRU may dynamically decide to trigger resource re-evaluation. The WTRU may make this decision based on the feasibility of meeting the latency requirement. Furthermore, the latency requirement may include the remaining PDB of the TB. Also, the latency requirement may include the time interval between the previously selected resource and the remaining PDB of the second TB.

[0006] In one example, the WTRU may determine the set of selectable resources by performing resource re-evaluation based on a previously selected set of resources. Furthermore, the WTRU may select at least one first resource from the previously selected set of resources. In one example, the at least one first resource may not be in the set of selectable resources. Furthermore, the WTRU may replace the first resource with at least one second resource. In one example, the at least one second resource may be in the set of selectable resources. Furthermore, the WTRU may 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 may then transmit the first TB using the at least one second resource.

[0007] In a further example, the association with the at least one second resource may be based on a HARQ state of the first TB, which may be an enabled HARQ state of the TB in one example, and the at least one third resource may be used for HARQ transmissions associated with the first TB.

[0008] In an additional example, the association with the at least one second resource may be based on a grant. In one example, the grant may be a periodic reservation grant. Thus, the association with the at least second first resource may be based on a periodic reservation grant associated with the first TB. Furthermore, the additional resources may include resources associated with a periodic reservation grant. For example, the at least one third resource may be associated with a periodic reservation grant. Furthermore, the preempted resource may also be a periodically reserved resource. In another example, one or more resources may be removed based on a collision. [Brief description of the drawings]

[0009] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, in which like reference numbers indicate similar elements and in which:

[0010] [Figure 1A] FIG. 1 is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented.

[0011] [Figure 1B] 1A is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A, according to one embodiment.

[0012] [Figure 1C] FIG. 1B is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system illustrated in FIG. 1A, according to one embodiment.

[0013] [Figure 1D] FIG. 1B is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communication system illustrated in FIG. 1A, according to one embodiment.

[0014] [Diagram 2] 1 shows an example of potentially reserved slots when a WTRU is not monitoring in one slot.

[0015] [Figure 3A] FIG. 1 illustrates an example of resource selection and sensing.

[0016] [Figure 3B] FIG. 1 illustrates an example of a resource re-evaluation including a resource re-evaluation trigger.

[0017] [Figure 4] FIG. 1 illustrates an example of resource re-evaluation including a hybrid automatic repeat request (HARQ) enabled transport block (TB).

[0018] [Diagram 5] FIG. 13 illustrates an example of resource re-evaluation including HARQ disabling TB.

[0019] [Figure 6] 1 illustrates an example of a WTRU determining the type of retransmission based on the timing of the initial transmission, retransmission, and uplink (UL) HARQ feedback. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

[0021] 1A, communications system 100 may 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, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, 102d may 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 may be referred to as a station (STA), may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, mobile phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain context), consumer electronic devices, devices operating in commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0022] The communications system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may 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 communications networks, such as the CN 106, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a NodeB, an eNode B (eNode B, eNB), a home NodeB, a home eNodeB, a gNode B (gNode B, gNB), a new radio (NR) NodeB, a site controller, an access point (AP), a wireless router, or the like. Although the base stations 114a, 114b are each shown as a single element, it will be understood that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

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

[0024] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may 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 may be established using any suitable radio access technology (RAT).

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

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

[0027] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access, which may establish the air interface 116 using NR.

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

[0029] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a wireless technology such as IEEE 802.11 (i.e., Wireless Fidelity, WiFi), IEEE 802.16 (i.e., Worldwide Interoperative for Microword Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), GSM Evolution (Enhanced Data rates for GSM Evolution, EDGE), GSM EDGE (GERAN), or the like.

[0030] 1A may be, for example, a wireless router, a Home Node B, a Home eNode B, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a localized area, such as a location of a business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology, such as IEEE 802.11, to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may 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 may establish a picocell or a femtocell utilizing a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-APro, NR, etc.). As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 through the CN 106.

[0031] The RAN 104 may communicate with the CN 106, which may be any type of network configured to provide voice, data, application, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have various quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 and / or the CN 106 may communicate directly or indirectly with other RANs that use the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may utilize NR radio technology, the CN 106 may also communicate with another RAN (not shown) using GSM, UMTS, CDMA2000, WiMAX, E-UTRA or WiFi radio technologies.

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

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

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

[0035] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

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

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

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

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

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

[0043] The WTRU 102 may include a full-duplex radio where transmission and reception of some or all of the signals (e.g., associated with a particular subframe of both the UL (e.g., for transmission) and DL (e.g., for reception)) may be simultaneous and / or together. The full-duplex radio may include an interference management unit to reduce and or substantially eliminate self-interference via hardware (e.g., chokes) or signal processing via a processor (e.g., via a separate processor (not shown) or processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio where transmission and reception of some or all of the signals (e.g., associated with a particular subframe of either the UL (e.g., for transmission) or DL ​​(e.g., for reception)) may be simultaneous and / or together.

[0044] 1C is a system diagram illustrating the RAN 104 and the CN 106 according to one embodiment. As mentioned above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using E-UTRA radio technology. The RAN 104 may also communicate with the CN 106.

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

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

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

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

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

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

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

[0052] Although the WTRU is depicted in FIGS. 1A-1D as a wireless terminal, it is contemplated that in certain representative embodiments such a terminal may use a wired communications interface (e.g., temporarily or permanently) with the communications network.

[0053] In an exemplary embodiment, the other network 112 may be a WLAN.

[0054] A WLAN in infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) of the BSS and one or more stations (STAs) associated with the AP. The AP may have access or interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic within the BSS and / or outside the BSS. Traffic to the STA originating from outside the BSS may arrive through the AP and be delivered to the STA. Traffic originating from the STA to a destination outside the BSS may be sent to the AP and transmitted to the respective destination. Traffic between STAs in the BSS may be transmitted, for example, through the AP, where the source STA may transmit traffic to the AP, which may deliver the traffic to the destination STA. Traffic between STAs in the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be transmitted in a direct link setup (DLS) between (e.g., directly between) the source STA and the destination STA. In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (e.g., all of the STAs) may communicate directly with each other. The IBSS mode of communication may be referred to herein as an "ad-hoc" communication mode.

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

[0056] A High Throughput (HT) STA may, for example, use a 40 MHz wide channel for communication via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

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

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

[0059] WLAN systems that may support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that may be designated as a primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be configured and / or limited by the STAs among all STAs operating in the BSS that support the smallest bandwidth operating mode. In an 802.11ah example, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only) the 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) settings may depend on the condition of the primary channel. For example, if the primary channel is busy, a STA (that only supports a 1 MHz mode of operation) transmitting to the AP may cause all of the available frequency bands to be considered busy, even if most of the available frequency bands are idle.

[0060] In the United States, the available frequency bands that can be used by 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 bandwidth available for 802.11ah is 6MHz to 26MHz depending on the country code.

[0061] 1D is a system diagram illustrating the RAN 104 and the CN 106 according to one embodiment. As mentioned above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using NR radio technology. The RAN 104 may also communicate with the CN 106.

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

[0063] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of different or scalable lengths (e.g., including varying numbers of OFDM symbols and / or varying lengths of absolute time duration and varying times).

[0064] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without accessing another RAN (e.g., eNode-Bs 160a, 160b, 160c, etc.). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in unlicensed bands. The non-standalone configuration WTRUs 102a, 102b, 102c may communicate with and connect to a gNB 180a, 180b, 180c while also communicating with and connecting to another RAN, such as an eNode-B 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNode-Bs 160a, 160b, 160c may act as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0065] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, support for network slicing, DC, interworking between NR and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a, 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D , the gNBs 180a, 180b, 180c may communicate with each other via an Xn interface.

[0066] 1D 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 shown as part of the CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0067] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N2 interface and may function as a control node. For example, the AMF 182a, 182b may be responsible for user authentication of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling different protocol data unit (PDU) sessions having different requirements), selection of the SMFs 183a, 183b for registration, management of registration areas, termination of non-access stratum (NAS) signaling, mobility management, etc. The network slicing may be used by the AMF 182a, 182b to customize the CN support of the WTRUs 102a, 102b, 102c based on the type of service utilizing the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, etc. The AMF 182a, 182b may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-APro, and / or non-3GPP access technologies, such as WiFi.

[0068] The SMFs 183a, 183b may be connected to the AMFs 182a, 182b in the CN 106 via an N11 interface. The SMFs 183a, 183b may also be connected to the UPFs 184a, 184b in the CN 106 via an N4 interface. The SMFs 183a, 183b may select and control the UPFs 184a, 184b and configure the routing of traffic through the UPFs 184a, 184b. The SMFs 183a, 183b may perform other functions, such as managing and assigning UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

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

[0070] The CN 106 may facilitate communication with other networks. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. Additionally, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In an embodiment, the WTRUs 102a, 102b, 102c may be connected to the local DNs 185a, 185b through the UPFs 184a, 184b via an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

[0071] 1A-1D and the corresponding description thereof, one or more or all of the functions described herein with respect to one or more of the WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other devices described herein may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

[0072] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and / or an operator network environment. For example, one or more emulation devices may perform one or more or all functions while fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices in the communication network. One or more emulation devices may perform one or more or all functions while temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation devices may be directly coupled to another device for the purpose of testing and / or performing tests using over-the-air wireless communication.

[0073] The one or more emulation devices may perform one or more functions, including but not limited to, while not implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in test scenarios in a test lab and / or in an undeployed (e.g., test) wired and / or wireless communication network to implement 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 (which may include, for example, one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0074] In LTE vehicle-to-everything (V2X) communications, there may be traffic models of one or more types of traffic, such as periodic and event-triggered (which may be referred to as aperiodic). For periodic traffic, one 300-byte message may be followed by four 190-byte messages. Furthermore, the inter-arrival time between two packets may be a multiple of 100 ms. For event-triggered traffic, six messages may be generated in a period of 100 ms when an event following a Poisson process is triggered.

[0075] Considering the above parameters for the LTE V2X traffic model, in general, both event-triggered and periodic traffic can be considered similar or the same as periodic traffic.

[0076] 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) may be transmitted in the same subframe. The PSCCH may include sidelink control information (SCI), which may include information about the PSSCH transmission. By decoding the PSCCH, the received WTRU can decode the following information: forward booking PSSCH frequency and time, PSSCH priority, and / or PSSCH retransmission frequency and time.

[0077] Generally, a LTE V2X vehicle WTRU performs procedures for sensing and resource selection. First, a WTRU may perform sensing to decode the SCI of other WTRUs. From the decoding of the SCI, the WTRU may have information of the forward booking PSSCH and its corresponding priority. The WTRU may consider the forward booking PSSCH as occupied and exclude it from resource selection if its reference signal received power (RSRP) PSSCH is greater than a threshold. Then, the WTRU ranks the remaining resources in ascending order of received strength signal indicator (RSSI) and selects a set of selectable resources S for final resource selection. A Finally, we may select 20% of the total resources for transmission, denoted as S A The spooler may randomly select one of the resources.

[0078] NR V2X may apply a traffic model. Similar to LTE V2X, New Radio (NR) V2X may support two types of traffic: periodic and aperiodic. However, NR V2X may support many different types of packet sizes, packet arrival rates, and latency requirements. Specifically, model 2 aperiodic traffic may have the following characteristics: packet size range of 10,000 to 30,000 bytes, average inter-arrival rate of 20 ms, and / or latency requirement of 10 ms.

[0079] In addition, mode 3 periodic traffic may have the following characteristics: a packet size range of 30,000 to 60,000 bytes, an average inter-arrival rate of 30 ms, and / or a latency requirement of 30 ms.

[0080] For NR V2X, long-term and short-term sensing may need to be addressed. As mentioned above, NR V2X may support both periodic and aperiodic traffic. 3GPP RAN1 may support semi-persistent (SPS) resource reservation that may be enabled / disabled. When SPS resource reservation is enabled, long-term sensing utilized before triggering resource selection may be utilized to avoid collisions of periodic traffic. For short-term sensing of aperiodic traffic performed after triggering resource selection may be supported in the example solutions described herein. NR V2X sensing and resource selection may consider the interplay of both long-term and short-term sensing.

[0081] Also, for NR V2X, hybrid automatic repeat request (HARQ) transmissions in the resource pool may need to be addressed. NR V2X may support three cast types, unicast, groupcast, and broadcast, and HARQ operation may be supported for groupcast and unicast sidelink transmissions. In the resource pool, HARQ feedback resources may be configured and / or pre-configured, which occurs periodically every N slots (N=1, 2, 4). Resource reservation for HARQ-based retransmissions may be supported in NR V2X. Thus, NR V2X sensing and resource selection may be considered for cast types and HARQ operation in the example solutions described herein.

[0082] Also, for NR V2X, bursty traffic can be addressed. Resource selection in LTE V2X allocates resources for a single transport block (TB). However, in NR V2X, bursty traffic can be expected. Performing sensing and resource selection for individual TBs may not guarantee the QoS requirements of the TBs in bursty traffic. Therefore, NR sensing and resource selection can be designed to support bursty traffic in the example solutions described herein.

[0083] Also, for NR V2X, preemption techniques can be used. NR V2X supports TB with latency requirements as low as 3 ms. Resource selection within the 3 ms resource selection window may result in high collision probability. To guarantee QoS for such stringent TB, preemption can be used. In NR V2X sensing and resource selection, preemption can be addressed in the example solutions described herein.

[0084] The terms receiver WTRU, receiving WTRU, receiver, receive, Rx WTRU or Rx may be used interchangeably and still be consistent with the examples and embodiments provided herein. Additionally, the terms transmitter WTRU, transmitting WTRU, transmitter, transmit, Tx WTRU or Tx may be used interchangeably and still be consistent with the examples and embodiments provided herein. Additionally, selection and reselection may be used interchangeably in one or more of the examples and embodiments provided herein.

[0085] In some example situations, there may be methods for HARQ-based transmission. Specifically, in some example situations, there may be methods to support HARQ feedback transmission. For example, the WTRU may prioritize between transmitting and receiving a physical sidelink feedback channel (PSFCH) in the same slot based on the HARQ state, the QoS of the data, and the number of transmitted and received PSSCH / PSCCH per TB.

[0086] In an example situation, the WTRU may prioritize between transmission and reception of a PSFCH in the same slot based on at least one or more of the HARQ state, an index of the associated PSSCH / PSCCH for HARQ feedback, the QoS of the data associated with the PSFCH transmission / reception, a cast type of the associated PSSCH / PSCCH, a groupcast transmission of the feedback type, whether the PSSCH / PSCCH Tx or Rx is in the same slot, and / or a channel busy ratio (CBR).

[0087] Regarding the HARQ status, the WTRU may need to send an acknowledgement (ACK) or negative ACK (NACK), or the number of bits the WTRU needs to send HARQ feedback to indicate the status of one or more TBs. For example, if the WTRU needs to send a HARQ-NACK, PSFCH transmission (PSFCH-Tx) may be of higher priority than PSFCH reception. Also, if the WTRU needs to send a HARQ-ACK, PSFCH reception (PSFCH-Rx) may be of higher priority than PSFCH reception. The WTRU may perform whichever has the higher priority.

[0088] Also, with regard to the HARQ state, the WTRU may need to determine the number of HARQ feedback transmissions. If PSFCH-Tx is for the N1-th retransmission and PSFCH-RxI is for the N2-th retransmission, the WTRU may perform one of PSFCH-Tx and PSFCH-Rx based on the higher number of N1 and N2. Also, if N1=N2, other conditions may apply to decide between PSFCHRx and PSFCHTx.

[0089] Regarding the cast type of the associated PSSCH / PSCCH, several examples may apply: For example, if a WTRU needs to receive a PSFCH for groupcast and transmit a PSFCH for unicast, the WTRU may prioritize PSFCH reception regardless of other parameters.

[0090] Regarding the feedback type groupcast transmission, several examples may apply. For example, a WTRU may be prioritized based on whether the feedback is NACK-based feedback, which may be considered as the first option or option 1. Furthermore, a WTRU may be prioritized based on whether the feedback is ACK / NACK based feedback, which may be considered as the second option or option 2. Also, a WTRU may be prioritized based on whether the feedback is a combination of option 1 and option 2.

[0091] With regard to whether PSSCH / PSCCH Tx or Rx is in the same slot, in one example, if the WTRU transmits a Pssch / Pscch transmission in the same slot, which may require the WTRU to perform at least one of PSFCH-Tx and PSFCH-Rx, the WTRU may perform PSFCH-Tx. Furthermore, if the WTRU receives a PSSCH / PSCCH in the same slot, the WTRU may perform PSFCH-Rx. Also, if there is no PSSCH / PSCCH Tx or Rx in the slot, the WTRU may determine PSFCH-Tx or PSFCH-Rx based on other conditions described herein.

[0092] With respect to the CBR, in one example, if the CBR is higher than a threshold, the WTRU may perform PSFCH-Rx and skip transmitting the PSFCH in the slot, otherwise the WTRU may decide PSFCH-Tx or PSFCH-Rx based on other conditions described herein.

[0093] In one example approach, the WTRU may prioritize PSFCH transmission / reception based on the HARQ state of the PSSCH / PSCCH reception. Specifically, if the PSFCH feedback is for an ACK, the WTRU may drop the PSFCH transmission and prioritize the PSFCH reception. Additionally or alternatively, if the PSFCH feedback is a NACK, the WTRU may prioritize the PSFCH transmission or perform PSFCH transmission or reception based on the QoS of the associated PSSCH / PSCCH transmission.

[0094] In another example approach, the WTRU may prioritize PSFCH transmission or reception based on the order of HARQ retransmissions. Specifically, the WTRU may prioritize transmission or reception of PSFCHs with higher indices of the associated PSSCH / PSCCH.

[0095] In an example situation, the WTRU may determine whether it may transmit multiple PSFCHs in the same slot. The WTRU may determine whether it may transmit multiple PSFCHs in the same slot based on one or any combination of the maximum frequency distance between two PSFCH resources, the power level of each PSFCH, the minimum frequency distance between the PSFCH and a carrier boundary, the maximum power backoff of each PSFCH, and / or the number of symbols configured for the PSFCH resource. In one example, the symbol may be an OFDM symbol. In another example, the symbol may be a DFT-s-OFDM symbol.

[0096] In an example approach, the WTRU may determine a maximum power level for each PSFCH when transmitting multiple PSFCHs simultaneously based on the frequency distance between the two PSFCHs. Specifically, the WTRU may be configured with a set of maximum power backoffs for one PSFCH transmission based on the frequency distance between the two PSFCH resources. Based on the configured maximum power backoff values, the WTRU may determine a maximum power level for each PSFCH when determining whether multiple PSFCHs can be transmitted simultaneously. Furthermore, the WTRU may determine a required minimum power level for each HARQ feedback, which may be based on one or more of the QoS of the associated PSSCH / PSCC, the WTRU's required PSFCH received power and / or sidelink path loss.

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

[0098] In another example approach, the WTRU may determine to transmit multiple PSFCHs simultaneously if the maximum frequency distance between two PSFCH resources is less than a threshold. Additionally or alternatively, the WTRU may determine to transmit multiple PSFCHs in the same slot if the minimum frequency distance between a PSFCH and a carrier boundary is greater than a threshold.

[0099] In another example approach, the WTRU may determine whether two or more PSFCHs may be transmitted in the same slot based on the number of symbols configured in the slot that includes the PSFCH resource. If Ns symbols are configured for the PSFCH resource, the WTRU may transmit NsPSFCHs in the same slot, and the location of the symbols may be determined based on one or more of the source id (and / or destination id) of the WTRU receiving the PSFCH, the subchannel index (e.g., the first or last subchannel) of the associated received PSSCH / PSCCH, and / or the slot index of the associated received PSSCH / PSCCH.

[0100] In an example situation, the WTRU may perform prioritization among multiple PSFCH transmissions based on at least one of the HARQ state, the QoS of the data, and / or the index of the PSSCH / PSCCH for each TB. The WTRU may have multiple PSFCH-Tx in a slot when the WTRU receives multiple PSSCH / PSCCH transmissions associated with a PSFCH slot. In this case, the WTRU may need to prioritize the PSFCH-Tx and drop / skip the lower priority PSFCH-Tx.

[0101] In one example approach, the WTRU may perform PSFCH transmission prioritization by dropping one or more PSFCHs or reducing the power of non-prioritized PSFCHs. The WTRU may apply similar rules of PSFCH transmission / reception prioritization to perform prioritization among multiple PSFCH transmissions. In particular, the WTRU prioritization may be determined based on one or more of the HARQ state, the index of the associated PSSCH / PSCCH for the HARQ feedback, the QoS of the data associated with the PSFCH transmission / reception, the cast type of the associated PSSCH / PSCCH, the groupcast transmission of the feedback type, and / or the time location of the associated received PSSCH / PSCCH. In one example, the HARQ state may include whether the WTRU needs to transmit an ACK or NACK and the number of bits the WTRU needs to transmit HARQ feedback to indicate the status of one or more TBs.

[0102] In a further example, the feedback type for a groupcast transmission may include whether the feedback is NACK-based feedback. This feedback type may be referred to as a first option or option 1. The feedback type may also include ACK / NACK-based feedback. Thus, this feedback type may be referred to as a first option or option 2. Furthermore, the feedback type may be a combination of option 1 and option 2.

[0103] In another example, the time location of the associated PSSCH / PSCCH may include a PSFCH-Tx associated with a PSSCH / PSCCH received in slot #n, which may be prioritized higher than a PSFCH-Tx associated with a PSSCH / PSCCH received in slot #n+k, where k>0.

[0104] In some example situations, there may be methods for management and resource selection for HARQ-based transmissions. In example situations, the WTRU may decide whether to reserve resources for unicast / groupcast TB retransmissions. The WTRU may decide to perform resource reservation for one or more retransmissions based on one or any combination of the data status in the MAC buffer, the QoS of the data, and / or the CBR of the resource pool.

[0105] In an example approach, the WTRU may decide to reserve one or more resources for HARQ-based retransmission of a unicast / groupcast TB if it has data in the buffer of another TB. This approach may help improve the spectral efficiency of the system because the reserved resources for HARQ-based retransmission may be used for transmission of another TB, and may allow the WTRU to use the reserved resources when a HARQ ACK is received.

[0106] In another example approach, the WTRU may decide to reserve one or more resources for HARQ-based retransmission and / or blind retransmission of unicast / groupcast TB based on the QoS of the TB. Specifically, if the TB has stringent QoS requirements, the WTRU may decide to reserve resources for both HARQ-based retransmission and blind retransmission. Additionally or alternatively, if the TB has medium QoS requirements, the WTRU may decide to reserve resources only for HARQ-based retransmission. Furthermore, if the TB has low QoS requirements, the WTRU may decide not to reserve resources for retransmission.

[0107] The WTRU may determine the number of reserved resources for transmission of one TB based on the CBR of the resource pool. Specifically, the WTRU may be configured with a maximum and minimum number of reserved resources per CBR range based on the QoS of the data. The WTRU may then determine the exact number of reserved resources per TB based on the QoS and the CBR of the resource pool. If the CBR is greater than a threshold, the WTRU may decide not to reserve resources for HARQ-based retransmission.

[0108] In an example situation, the WTRU may determine to use a HARQ-based retransmission resource of another TB based on the QoS of the TB. In an example approach, the WTRU may determine to use a reserved HARQ-based retransmission resource of another TB if the QoS of the TB is higher or lower than a threshold. Additionally or alternatively, the WTRU may determine to use the HARQ-based reserved resource if the relative QoS between the successfully transmitted TB and the new TB is within a predefined range. Thus, in one example, the WTRU may determine to use the HARQ-based reserved resource if the relative QoS between the two TBs is greater than a threshold. In another example, the WTRU may determine to use the HARQ-based reserved resource if the relative QoS between the two TBs is lower than a threshold.

[0109] In a further exemplary situation, the Rx WTRU of unicast transmission may decide to use the reserved HARQ-based retransmission resource of the Tx WTRU. Specifically, the Rx WTRU after successfully decoding the TB and sending an ACK feedback to the Tx WTRU may decide to use the reserved HARQ-based retransmission resource. Thus, the Rx WTRU may be configured with one or any combination of the following criteria to reuse such reserved resource: the QoS of the TB is greater or less than a threshold, the relative QoS between the two TBs is within a predefined range, the Tx-Rx distance is less / greater than a threshold, the CBR of the resource pool is higher / lower than a threshold, and / or the CQI and / or RI of the reserved resource is higher than a threshold. The Rx WTRU may be configured to send an indication thereof to implicitly use the reserved resource to the Tx WTRU. Such an indication may be sent by using different HARQ feedback resources including time-frequency resources, sequences or cyclic shifts.

[0110] In an example scenario, the WTRU may determine the priority and RSRP of the reserved HARQ-based retransmission resources when performing sensing and resource allocation. In another example scenario, where the WTRU performs sensing and resource allocation, the WTRU may determine the priority and reference signal received quality (RSRQ) of the reserved HARQ-based retransmission resources. In a further example scenario, the WTRU may determine the priority and RSRP / RSRQ / RSSI of the reserved HARQ-based retransmission resources when performing sensing and resource allocation.

[0111] Such information, e.g., priority and RSRP / RSRQ / RSSI, may be used to determine resource availability during resource allocation procedures. The WTRU may determine the priority and RSRP / RSSI / RSRQ of the reserved HARQ-based retransmission resource based on one or any combination of the transmission used to reserve the HARQ-based retransmission resource, the priority and RSRP / RSSI / RSRQ of the PSSCH / PSCCH used to reserve the HARQ-based retransmission resource, the HARQ feedback state associated with a previous transmission of the TB, and / or the cast type of the TB and the HARQ feedback option used for the TB.

[0112] For a transmission used to reserve a HARQ-based retransmission resource, the WTRU may determine whether the transmission used to reserve a HARQ-based retransmission resource is from the same TB or a different TB. In one example, resource reselection may also be used.

[0113] With respect to the HARQ feedback state associated with the previous transmission of the TB, the WTRU may determine a state associated with the previous transmission of the TB, such as: the WTRU receives HARQ ACK feedback, the WTRU receives HARQ NACK feedback, the WTRU does not receive HARQ information, etc. If the WTRU does not receive HARQ information, the state may be determined by either: the WTRU does not decode HARQ feedback, the WTRU is unable to decode HARQ feedback, and the WTRU performs sensing and resource allocation before the HARQ feedback time.

[0114] With regard to the cast type, the WTRU may determine whether the reserved HARQ-based retransmission resource is for unicast or groupcast, and if the resource is for a groupcast transmission, the WTRU may further determine which HARQ feedback option is to be used for the transmission, and such information may be conveyed implicitly / explicitly in the SCI.

[0115] In an example situation, the WTRU may determine the priority and RSRP / RSRQ / RSSI of the reserved HARQ-based retransmission resource based on the resource reservation feature used to reserve the resource. First, the WTRU may decode an SCI with priority p, and the measured RSRP / RSRQ / RSSI of its PSCCH / PSSCH is E. If the WTRU uses the reservation of another TB feature to reserve the HARQ-based retransmission resource, the WTRU may 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 HARQ-based retransmission resource of the same TB, the WTRU may 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 may be preconfigured, configured, or explicitly indicated in the SCI. This example approach may support adjustment of retransmissions based on HARQ feedback.

[0116] In another example situation, the WTRU may determine the priority and RSRP / RSRQ / RSSI of the reserved HARQ-based retransmission resources based on the HARQ state of the previous transmission of the same TB. First, the WTRU may decode the SCI with priority p, and the measured RSRP / RSRQ / RSSI of its PSCCH / PSSCH is E. In an example approach, the WTRU may apply different offsets of priority and RSRP / RSRQ / RSSI when the WTRU receives HARQ ACK and HARQ NACK, respectively, for the previous PSSCH / PSCCH transmission of the TB. Additionally or alternatively, the WTRU may determine the reserved HARQ-based retransmission resources as available and may include them in the set of selectable resources for random selection when the WTRU receives HARQ ACK feedback for the previous PSSCH / PSCCH transmission of the TB. The WTRU may consider the resources unavailable when it receives HARQ NACK feedback.

[0117] In a further example situation, the WTRU may split the set of selectable resources into two sets and select resources for transmitting one TB in one of the two sets. In one example, one set may include resources in slots with PSFCH and another set may include slots without PSFCH resources. The WTRU may select one set to select resources for transmission of one TB. The WTRU may determine which set to select resources from based on one or more of the resource pool configuration, the TB size, the QoS of the TB, the number of selectable resources in each set, the CBR of the resource pool, and / or the cast type of the TB.

[0118] In one example, the resource pool configuration may include a slot periodicity with one or more PSFCH resources. In a further example, if the TB size is greater than a threshold, the WTRU may select a set of resources without PSFCH resources. Otherwise, the WTRU may select any set of resources. In an example for TB QoS, if the QoS of the resource pool is less than a threshold, the WTRU may select a set of resources with PSFCH resources. Additionally or alternatively, the WTRU may select a set of resources without PSFCH resources. In an example for CBR, if the CBR of the resource pool is less than a threshold, the WTRU may select a set of resources without PSFCH resources.

[0119] In the examples described herein, procedures are provided for HARQ feedback reporting for unknown location information. In an exemplary case, the receiving WTRU may decide to send HARQ NACK feedback when it can decode the SCI. The WTRU may perform NACK-based feedback for unicast / groupcast, and the WTRU may only send a NACK when it cannot decode a message, and the Tx-Rx distance is less than the minimum communication range that may be indicated in the SCI. In contrast, if the location information of the Rx WTRU is not known, the WTRU may send a NACK when it cannot decode a message. In one example, the message may be a PSSCH message.

[0120] In some example cases, the receiving WTRU may decide not to transmit HARQ feedback when its location is unknown. Also, in a further example, the receiving WTRU may decide whether to transmit HARQ feedback based on its past location information. In some example cases, the receiving WTRU may decide to transmit HARQ NACK feedback based on location information obtained from the last location information. In an example scenario, the Rx WTRU may decide to use the last location information to calculate a Tx-Rx distance associated with a received TB when the period between the Rx WTRU's last location information and a TB transmission may not exceed a threshold. The 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, the QoS requirements may include reliability.

[0121] In some further example cases, the receiving WTRU may determine not to transmit HARQ feedback when its location is unknown and the time period until the last time it receives location information is greater than a threshold. In a further example, the receiving WTRU may determine to transmit HARQ feedback when its location is unknown but the time period until the last time it receives location information is less than or equal to a threshold.

[0122] In some example situations, the WTRU may perform one or more procedures for resource reservation. In an example situation, the WTRU may determine whether feature reservation of another TB is allowed. In general, the WTRU may support feature reservation of another TB, whereby the WTRU may use a transmission of one TB to reserve resources of another TB. The feature may include one or any combination of semi-persistent resource reservation and / or dynamic resource reservation. In one example, semi-persistent resource reservation may include a procedure where an SCI associated with one TB in a periodic traffic reserves resources of another TB in the same periodic traffic. In a further example, dynamic resource reservation may include a procedure where an SCI associated with one TB reserves resources of any other TB. In an example approach, the WTRU may indicate in the SCI which type of resource reservation is being used to support other WTRUs in the sensing and resource allocation procedure.

[0123] The WTRU may be configured to determine whether a feature reservation of the other TB is allowed based on one or any combination of the resource pool configuration, the CBR of the resource pool, the QoS of the TB, and / or the minimum communication range (MCR). Examples including the MCR include whether the WTRU is in-MCR or out-MCR. In one example, the WTRU may be a receiving WTRU. Also, the in-MCR may be referred to as in-MCR in one example. In a further example, the out-MCR may be referred to as out-MCR. If the WTRU is in-MCR, in one example, reservation of the other TB may be allowed. Otherwise, reservation of the other TB may not be allowed.

[0124] The WTRU may be composed of a resource pool having one or any combination of the following cases for reservation of another TB feature: a first case, referred to as Case-1, where SPS resource reservation is permitted; a second case, referred to as Case-2, where dynamic resource reservation is permitted; and / or a third case, referred to as Case-3, where both SPS and dynamic resource reservation are permitted; and / or a fourth case, referred to as Case-4, where resource reservation is not permitted.

[0125] Which case to use for reservation of another TB feature may be determined based on one or more of the CBR of the resource pool, the resource pool configuration, the QoS of the packet or TB, the coverage, the MCR, and the packet size. In one example, the coverage may include in-coverage or out-of-coverage. In a further example, the MCR may include in-MCR or out-MCR.

[0126] In another approach, 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, to enable SPS resource reservation when CBR1 < CBR <= CBR2, to enable dynamic resource reservation when CBR2 < CBR <= CBR3, and not to enable reservation when CBR > CBR3.

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

[0128] In an example situation, the WTRU may determine a number of resources to report from the physical (PHY) layer to the MAC layer based on whether a feature reservation for another TB is enabled / disabled. For example, the WTRU may determine a first number of resources to report from the PHY layer to the MAC layer based on an enabled feature reservation for another TB. In a further example, the WTRU may determine a second number of resources to report from the PHY layer to the MAC layer based on a disabled feature reservation for another TB.

[0129] The WTRU may be configured to determine a set of selectable resources for random selection based on any one or combination of whether separate TB feature reservation is enabled or disabled and / or the CBR of the resource pool. In one example, the set of selectable resources for random selection may include a set of resources reported from the PHY layer to the MAC layer.

[0130] In one example, the WTRU may be configured to determine the set of selectable resources for random selection as X% and Y% of the total resources in the resource selection window when feature reservation of another TB is enabled and disabled, respectively. With this approach, the WTRU may strike a balance between collision probability and quality of the selected resources.

[0131] In an example situation, the WTRU may determine the number of reserved resources of the reaching TB by using the feature reservation of another TB based on one or more of the CBR, QoS, and / or cast type. The WTRU may be configured with a range of the number of reserved resources for each TB based on the CBR of the resource pool, the QoS of the TB, and / or the cast type.

[0132] In an example approach, the WTRU may decide to reserve resources for all transmissions of a TB by using the feature reservation of another TB if the CBR of the resource pool is higher or lower than a threshold. However, the WTRU may reserve one resource for either the initial transmission or retransmission of the TB by using the SCI associated with another TB if the CBR of the resource pool is lower or higher than a threshold.

[0133] In another example approach, the WTRU may decide to reserve one or more resources of all transmissions of one TB by using a feature reservation of another TB for a TB with high QoS requirements. In an embodiment, the high QoS requirements may include one or more of a TB with high priority, high reliability, or low latency. Additionally or alternatively, the WTRU may decide to reserve one resource for either the initial transmission or retransmission of a TB with low QoS requirements by using a feature reservation of another TB. This approach may enable the WTRU to reduce collisions for TBs with high QoS requirements since all transmission resources of the TB are reserved in advance.

[0134] In a further example approach, the WTRU may decide to reserve one resource for an initial transmission of a TB if it is associated with unicast / groupcast traffic, and may reserve one or more resources for all transmissions of another TB if it is associated with broadcast traffic. The WTRU may perform dynamic resource selection for one or more retransmissions of a TB if the WTRU only reserves resources for the initial transmission.

[0135] In an example situation, the WTRU may determine the sensing window based on which reservations of different TB features are supported in the resource pool. The WTRU may determine the sensing window in one resource pool based on whether SPS and / or dynamic resource reservation are supported / enabled in the resource pool. Specifically, the WTRU may be configured with multiple resource pools, where each resource pool may be configured with a sensing window depending on which resource reservation features are supported in the resource pool.

[0136] In some example situations, the WTRU may perform one or more procedures for resource selection and / or reselection. In an example situation, there may be one or more procedures for resource exclusion. During the resource allocation procedure, the WTRU may decide whether to exclude resources in a slot and needs to monitor the reserved target PSSCH / PSCCH transmission. The reserved target PSSCH / PSCCH transmission may belong to the service in which the WTRU is operating. The decision may be based on one or more of 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 slot, and / or the CBR of the resource pool.

[0137] In one example involving QoS of TB, the WTRU may determine not to exclude slots with reserved target PSSCH / PSCCH if the QoS priority of the TB is higher / lower than a threshold, and may determine to exclude all reserved PSSCH / PSCCG if the priority of the TB is lower / higher than a threshold. In a further example involving QoS of reserved target PSSCH / PSCCH, the WTRU may exclude slots with reserved target PSSCH / PSCCH transmissions with QoS of associated TB greater than a threshold. Otherwise, if the associated TB is less than a threshold, the WTRU may not exclude the associated slot. In an example involving the amount of selectable resources before and after excluding reserved slots, the WTRU may gradually exclude slots with reserved target PSSCH / PSCCH transmissions from highest priority to lowest priority until the set of selectable resources is greater than a threshold.

[0138] In an example situation, a Tx WTRU may semi-persistently reserve resources for either aperiodic or periodic traffic. For the reserved resources, the WTRU may determine one or more of the following parameters: a validity period of the reserved resources, a minimum and maximum validity period, and / or a probability of retaining the reserved resources. For example, after each validity period, the WTRU may randomly select a value. If the value is less than the probability of retaining the reserved resources, the WTRU may continue to use the reserved resources. If not, the WTRU may perform resource reselection.

[0139] These parameters of the reserved resources may be determined based on one or more of the resource pool configuration, the QoS of the data, and / or the congestion level of the resource pool or the channel occupancy of the WTRU. With regard to the QoS of the data, in one example, the WTRU may be pre-configured or configured with a mapping between the validity period or probability of holding the resource and the priority of the TB. This approach may be motivated to allow high priority data to hold the resource for a long time to avoid collision with other / low priority data.

[0140] In an example situation, the WTRU may divide resources reserved by other WTRUs into multiple groups and gradually remove or add each resource in the set of selectable resources. Similar to LTE V2X, during the resource allocation procedure, the WTRU may consider all resources in a resource selection window as candidate resources. The WTRU may then determine a set of non-excluded resources, which may be the set of candidate resources after excluding some resources reserved by other WTRUs. The WTRU may then determine the set of selectable resources by selecting some percentage, e.g., 20%, of the candidate resources in the set of non-excluded resources. The WTRU may then randomly select one or more resources in the set of selectable resources for its transmission.

[0141] In an example that may be applicable to NR V2X, the WTRU may divide resources reserved by other WTRUs into multiple groups and gradually remove each resource in each group from the set of non-excluded resources or from the set of selectable resources. Additionally or alternatively, the WTRU may gradually add each resource in each group to the set of excluded resources. The adding or removing process may be terminated when one or more of the following conditions are met: the number of non-excluded resources is greater than X% of the total resources, the number of non-excluded 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.

[0142] The criteria for separating the reserved resources into different groups may be determined based on one or more of the QoS of the reserved resources, the timing of possible collisions, and / or the type of the reserved resources. With respect to the QoS of the reserved resources, the WTRU may divide the reserved resources into high QoS resources and low QoS resources. With respect to the type of the reserved resources, in one example, the WTRU may divide the set of reserved resources into one of 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, the group of dynamic reserved resources may be used for one transmission of one TB. And the group of semi-persistently reserved resources may be used semi-statically for multiple transmissions. Furthermore, the group of feedback-based HARQ retransmission resources may be used for feedback-based HARQ retransmissions.

[0143] In an example approach, the WTRU may divide the set resources reserved by other WTRUs into multiple groups, where the set of groups may include at least a low QoS group, e.g., a priority, resource and a group of high QoS resources. The WTRU may gradually add resources in the group of low QoS resources and then add resources in the group of high QoS resources to the set of excluded resources until an addition condition is met. Additionally or alternatively, the WTRU may gradually remove resources in the group of high QoS resources and then remove resources in the group of low QoS from the set of selectable resources until a removal condition is met. This approach may be motivated to allow the WTRU to avoid selecting reserved resources from high QoS data.

[0144] In another example approach, the WTRU may divide the set of reserved resources into at least two groups, where a first group may include reserved resources with potential collisions in a first window, e.g., a resource selection window, and a second group may include reserved resources with potential collisions in a second window, e.g., a window with a resource reservation window. The WTRU may sequentially add reserved resources in the second group and the first group to a set of excluded resources. This approach may be motivated to allow the WTRU to prioritize current transmissions over future transmissions.

[0145] In an example situation, a WTRU may determine a threshold for excluding a reserved resource during a resource selection procedure. The WTRU may exclude a resource reserved by another WTRU if the sidelink RSSI (SL-RSSI) or RSRP of the resource is greater than the threshold. The threshold may be determined based on one or more of the QoS of the TB, the congestion level of the resource pool, and / or the type of the reserved resource.

[0146] Regarding QoS of TBs similar to LTE V2X, the threshold for determining the availability of the resource pool may be determined based on the priority of reserved TBs and the priority of pending TBs, however, the threshold may further be determined based on the minimum communication range of pending TBs and / or the minimum communication range of TBs of reserved resources.

[0147] With respect to the congestion level of a resource pool, specifically, the WTRU may be configured with different thresholds based on the CBR range of the resource pool, for example, the WTRU may be configured with a first CBR range threshold, and the second CBR range threshold may be determined by an offset to the first CBR range threshold.

[0148] With regard to the types of reserved resources, in one example, the WTRU may be configured with one 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.

[0149] In a further exemplary situation, a method that takes into account slots is provided. In an embodiment, a method that takes into account non-monitored slots may be considered.

[0150] FIG. 2 illustrates an example of potentially reserved slots when a WTRU is not monitoring in a slot. In general, a WTRU may determine availability of potentially reserved slots when a slot is not monitored. As illustrated in the example of FIG. 200, a slot starting at time m may be referred to as slot m. Furthermore, slot m may include transmission resources such as transmission resources 210 and 220, where resource 210 may be used for control transmission and resource 220 may be used for data transmission. The WTRU may trigger resource selection at slot n in one example and select transmission resources in the resource selection window [n+T1, n+T2]. In a further example, the WTRU may exclude slots having time intervals P1, P2, P3 with slot m.

[0151] In a particular example, when the WTRU does not monitor in slot m, the WTRU i can be considered as potentially reserved slots, k is an integer, and P i are all possible reservation periods supported in the resource pool. In the example shown in Figure 2, P i may include at least P1, P2 and P3.

[0152] In an example approach, the WTRU may determine the availability of any potentially reserved slots during resource allocation when the WTRU does not monitor in a slot. In one example, the WTRU may not monitor in a slot when the WTRU needs to transmit in the slot. The availability of one potentially reserved slot may be determined based on one or more of the CBR of the resource pool, the QoS of the TB, and / or the traffic type of the TB.

[0153] With respect to the CBR of a resource pool, in one example, the WTRU may determine one potentially reserved slot as unavailable when the CBR of one of the resource pools is greater than a threshold. In contrast, the WTRU may determine a potentially reserved slot as available when the CBR of the resource pool is less than a threshold. If the WTRU considers the potentially reserved slots as available, the WTRU may include resources in these slots to the set of selectable resources. Conversely, if the WTRU considers these slots as unavailable, the WTRU may exclude resources in these slots in the set of selectable resources.

[0154] In one example, for TB QoS, the WTRU may determine one potentially reserved slot as either available or unavailable if the TB priority / latency threshold is exceeded. In a further example, only the priority threshold may be used. In another example, only the threshold value may be used.

[0155] For a TB traffic type, this basis for the decision may be appropriate if the WTRU determines one potentially reserved slot as available / unavailable based on dynamic or semi-persistent resource selection. Specifically, if the WTRU performs dynamic resource selection, the WTRU may determine the potentially reserved slot as available, and if the WTRU performs resource selection for semi-persistent use, the WTRU may determine the potentially reserved slot as unavailable.

[0156] In an example situation, the WTRU may perform one or more procedures for resource ranking as provided herein. In an example approach, the WTRU may divide the set of resources in the resource selection window into multiple groups, each of which may be associated with one resource group rank. The WTRU may then perform ranking of the resources within each group. Specifically, the WTRU may divide the resource set of resources in the resource selection window into a first group, which may be referred to as group 1 and may include a set of resources not reserved by other WTRUs or itself, and / or a second group, which may be referred to as group 2 and may include a set of resources reserved by other WTRUs, or any combination of more groups.

[0157] In one example, the WTRU may * In an example approach, the WTRU may perform ranking of resources in the group of resources reserved by other WTRUs based on an increase or decrease value of f(QoS, RSRP or RSRQ). For example, the WTRU may:

number

number

[0158] In a further example, the WTRU may gradually include resources in a group in the set of selectable resources. In one approach, the WTRU may select a group sequentially from lowest ranked to highest ranked, and then gradually include each resource in each group from lowest ranked to highest ranked until the number of selectable resources is greater than a threshold. Additionally or alternatively, the WTRU may select a group sequentially from highest ranked to lowest ranked, and then gradually exclude each resource in each group from highest ranked to lowest ranked until the number of excluded resources is greater than a threshold.

[0159] In an example situation, the WTRU may perform one or more procedures to determine a resource selection window. In an example approach, the WTRU may determine a resource selection window of the next resource of one TB based on the time resource of the previously selected resource and the maximum reservation signaling between the two resources. Specifically, similar to LTE V2X, for the first selected resource of the TB, 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 capability, and the value of T2 may be determined based on the latency and reliability of the TB. The earliest or latest time of the WTRU among the previously selected resources may be assumed as n+Tmin and n+Tmax, respectively, where Tmin=Tmax when the WTRU selects the first resource for retransmission. It may also be assumed that the maximum reservation signaling between the two resources is N. The WTRU may determine the resource selection window of the following resource as [min(n+Tmin-N, n+T1), max(n+Tmax+N, n+T2)].

[0160] In another example approach, the WTRU may determine a fixed selection window size for one transmission, and the resource selection window for the next transmission may be determined based on the selected resources of the previous transmission. In the example approach, it may be assumed that the WTRU may select a slot for the previous transmission of the TB as n+k, and the WTRU may determine the resource selection window for the next transmission as [n+k, n+k+C]. The WTRU may determine a resource selection window for the initial transmission of [n+T1, n+T1+C]. In another example approach, the WTRU may determine a resource selection window for one transmission in the window of [n+T1+(k-1)*C, n+T1+k*C], where k is an integer value. In both example approaches, C may be fixed or may be configured based on one or any combination of the QoS of the TB and / or the CBR of the resource pool.

[0161] In an example situation, the WTRU may decide which type of resource selection for unicast / groupcast TB to perform. The WTRU may support one or more of the following resource allocation types for unicast / groupcast TB: HARQ-based retransmission only and / or a combination of blind and HARQ-based retransmission.

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

[0163] The WTRU may decide to perform one resource selection type based on one or more of the QoS of the TB, the 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 an 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 for HARQ-based retransmission only. Additionally or alternatively, if the latency is less than a threshold, the WTRU may perform a combination of blind and HARQ-based retransmission.

[0164] In some example situations, the WTRU may determine a selection window for the next resource based on the results of previously selected resources for only the resource allocation type of HARQ-based retransmission. The WTRU may determine the resource selection window for the resource as [n+T1, n+T2]. The value of T2 may be determined based on the latency of the TB and the number of transmissions required for the TB. The WTRU may assume that it selects the first resource in slot n+k and the associated PSFCH in 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 interval between the PSFCH and the next HARQ-based PSSCH / PSCCH retransmission. If n+k+a+Δ>n+T2, the WTRU may terminate the resource selection procedure.

[0165] In an example situation, the WTRU may determine selection windows for initial transmission resources and HARQ-based retransmission resources. In an example approach, the WTRU may determine 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 TB latency requirement, and the value of T3 may be fixed or may be determined based on one or more of the number of selectable resources, the TB QoS, the resource pool CBR, and / or the TB QoS and / or the resource pool CBR. With respect to the TB QoS, the value of T3 may be determined as half the TB latency requirement.

[0166] Specifically, with respect to the number of selectable resources, the value of T3 may be determined such that the number of selectable resources is greater than a threshold in [n+T1, n+T3]. Additionally or alternatively, the value of T3 may be determined such that the number of selectable resources in the window [n+T1, n+T3] is greater than X% of the total number of selectable resources in the window [n+T1, +T2]. The value of X may be fixed or may be determined based on one or more of the QoS of the TB and / or the CBR of the resource pool.

[0167] In another example approach, the WTRU may determine that the first and second resource selection windows are [n+T1,n+T3] and [n+k+a+Δ,n+T2], where n+k and n+k+a are the slots of the initial transmission and its associated PSFCH, respectively. The value of Δ may be fixed based on the time interval between the PSFCH and the next HARQ-based PSSCH / PSCCH retransmission.

[0168] In an example situation, the WTRU may decide to change from the HARQ-based retransmission only resource allocation type to a combination of blind and HARQ-based retransmission resource allocation types based on the availability of selectable resources. Specifically, during the HARQ-based retransmission only resource allocation type selection procedure, if the amount of selectable resources in the resource selection window is less than a threshold, the WTRU may switch to a combination of blind and HARQ-based retransmission resources to guarantee the QoS of the TB.

[0169] In an example situation, the WTRU may determine which PSFCH resource to feed back the status of multiple PSSCH / PSCCH transmissions for one or more TB transmissions based on the timing of the PSFCH resource. For example, the WTRU may receive one PSSCH / PSCCH transmission and one PSSCH / PSCCH blind retransmission in one TB, and each PSSCH / PSCCH transmission may be associated with one PSFCH resource. Furthermore, the WTRU may need to determine which PSFCH resource to feed back the HARQ status of these PSSCH / PSCCH transmissions. The WTRU may determine which PSFCH resource to feed back the status of multiple PSSCH / PSCCH transmissions based on the timing of the PSFCH resource. Specifically, in one approach, the WTRU may select the PSFCH resource associated with the first PSSCH / PSCCH transmission if it has enough time to decode both PSSCH / PSCCH transmissions and prepare HARQ feedback. Otherwise, the WTRU may select the PSFCH associated with the second PSSCH / PSCCH transmission. In another approach, the WTRU may use the PSFCH associated with the second PSSCH / PSCCH.

[0170] In an example situation, the WTRU may determine a time slot to transmit the initial transmission message based on the selected resources for the initial transmission of the TB and the QoS. For example, the WTRU may need to determine a time slot to transmit an initial transmission reservation message to reserve resources for the initial transmission of the TB. The WTRU may be configured with a set of different time intervals between the reserved PSSCH / PSCCH resources and the initial transmission indication transmission. The time interval range may be determined based on the QoS, such as the priority of the TB. This approach may reduce collisions between low-priority TBs and high-priority TBs, since WTRUs with different priorities may receive reservation messages from each other and may perform collision avoidance if necessary.

[0171] In an example situation, the WTRU may determine two resource selection windows for an initial transmission and one or more retransmissions. For example, the WTRU may determine two resource selection windows, where one window may be used for resource selection for the initial transmission and another window may be used for resource selection for one or more retransmissions. Furthermore, the WTRU may use the transmission of the initial transmission in the first resource selection window to reserve resources for the retransmission in the second resource selection window.

[0172] In an example approach, the WTRU may determine that the first and second resource selection windows are [n+T1,n+T3] and [n+T3,n+T2], respectively. In another approach, the WTRU may determine that the first and second resource selection windows are [n+T1,n+T3] and [n+k+Δ,n+T2], where n+k is the slot of the initial transmission and Δ may be determined based on the WTRU processing capability. In both approaches, the values ​​of T2 and T3 may be determined based on the QoS of the TB and CBR of the resource pool. Specifically, the value of T2 may be determined based on the latency requirement of the TB and the CBR of the resource pool. The value of T3 may be determined based on the latency requirement of the TB, the reliability and / or the CBR of the resource pool.

[0173] In an example situation, the WTRU may perform a resource contention procedure 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 procedure may include one or more of the following procedures: a backoff procedure and / or a clear channel assessment (CCA) procedure.

[0174] In the backoff procedure, the WTRU may generate a backoff value after resource allocation is triggered. The WTRU may then decrease the backoff until the backoff value is less than or equal to zero. The backoff value may be decreased when it determines that one or more resources in a slot are available for its transmission.

[0175] In a CCA procedure, a WTRU may determine the availability of one or more resources by measuring the received signal strength (RSS) of these resources.

[0176] In an example situation, the WTRU may perform a random selection of selectable resources for retransmission in the second resource selection window. The set of selectable resources may be determined by a resource selection procedure similar to LTE V2X. Specifically, the set of selectable resources may be determined after filtering out resources reserved by other WTRUs and selecting the best resources after ranking the remaining resources.

[0177] In the examples provided herein, the WTRU may perform resource reselection. In an example situation, the WTRU may perform resource reselection for a set of reserved resources if the resource utilization of the reserved resources is less than a threshold. Specifically, the WTRU may be configured with a resource utilization threshold for one reserved resource set corresponding to one sidelink process. The utilization threshold may be configured based on the resource pool data and / or QoS of the CBR. The WTRU may determine the resource utilization of a set of reserved resources as a ratio of used resources to unused resources in a period of time.

[0178] In an example approach, the WTRU may perform resource reselection of the set of reserved resources for unicast / groupcast if the successful transmission ratio is less than a threshold. The Tx WTRU may consider the transmission successful if it receives a HARQ ACK feedback. The WTRU may consider the transmission unsuccessful if it receives a HARQ NACK or does not receive feedback from the Rx WTRU.

[0179] In another example approach, when the WTRU is operating in a network scheduled mode, the WTRU may report resource utilization to the network to support the network during scheduling. Additionally or alternatively, the WTRU may report a 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 trigger conditions. The trigger conditions may include, for example, when the utilization rate or transmission success rate of a set of reserved resources is less than a threshold value.

[0180] In some example situations, the WTRU may perform resource evaluation, re-evaluation, or both. According to an initial design of NR V2X, the WTRU may perform resource evaluation or re-evaluation for resources selected and / or reserved by the WTRU to determine whether it needs to reselect resources due to potential collisions with other WTRUs.

[0181] In one example, the WTRU may determine whether to trigger resource re-evaluation for a set of selected resources. In an example approach, the WTRU may determine whether resource re-evaluation needs to be triggered for a set of one or more selected resources based on one or any combination of the time between the slot when selecting resources and the slot of the first selected resource and / or the remaining delay budget of the TB.

[0182] In one example, the WTRU may determine whether to trigger resource re-evaluation based on the time between the slot of resource selection and the slot of the first selected resource. Specifically, in one example, the WTRU may trigger resource re-evaluation if the time between the slot of resource selection and the slot of the first selected resource is less than a threshold. Otherwise, the WTRU may not trigger resource re-evaluation. The threshold may be determined based on one or any combination of 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 with an interval threshold based on the CBR of the resource pool. Specifically, the WTRU may be configured or pre-configured with a long interval threshold when the CBR is low and a short interval threshold when the CBR is high. In one example related to fixed, configured, or pre-configured thresholds, the interval threshold may be a fixed value configured or pre-configured per resource pool. In one example related to the QoS of the TB, the interval threshold may be configured or pre-configured based on the priority of the TB. For example, the WTRU may be configured or pre-configured with a short interval threshold for high priority TBs and a long interval threshold for low priority TBs.

[0183] In another example, the WTRU may determine whether it needs to perform resource re-evaluation based on the remaining delay budget of the TB. Specifically, in one example, the WTRU may trigger resource re-evaluation if the remaining delay budget of the TB is greater than a threshold. Otherwise, the WTRU may not trigger resource re-evaluation. The delay budget threshold may be determined based on one or any combination of a fixed, configured, or pre-configured threshold, a CBR of the resource pool, and / or a resource reselection type of the TB. For example, the WTRU may be configured or pre-configured with a high delay budget threshold for HARQ-based retransmissions and a low delay budget threshold for blind retransmissions. With respect to the CBR of the resource pool, in one example, the WTRU may be configured or pre-configured with a delay budget threshold based on the CBR of the resource pool. For example, with a high delay budget threshold when the CBR is low and with a low delay budget threshold when the CBR is high. Furthermore, this approach may enable the WTRU to select sufficient available resources after resource re-evaluation. In one example relating to fixed, configured, or pre-configured thresholds, the delay budget threshold may be a fixed value that is configured or pre-configured per resource pool.

[0184] In an example approach, the WTRU may trigger resource re-evaluation in slots between the slot where the WTRU first selects a resource and the slot of use of the first selected resource. The WTRU may determine the resource re-evaluation trigger timing based on one or any combination of the TB QoS and / or the resource pool CBR. In an example with TB QoS, the WTRU may be configured or pre-configured with a maximum and / or minimum time interval between the first selected resource and the re-evaluation trigger based on the TB QoS, and the WTRU may then determine the resource re-evaluation timing to satisfy the configured or pre-configured time interval. Further, in an example with resource pool CBR, the time interval between the resource re-evaluation trigger and the first selected resource may be large when the resource pool CBR is low and low when the resource pool CBR is high.

[0185] The WTRU may determine a value for the time interval, in one example. In an exemplary example, the WTRU may be configured or pre-configured with the time interval. The time interval may be referred to as, for example, T3. In an exemplary example, the WTRU may be configured or pre-configured with a time interval T3 between the maximum resource re-evaluation timing and the first selected resource. The value of T3 may be determined based on the QoS of the TB and / or the CBR of the resource pool. In particular, T3 may be large for low priority TBs and small for high priority TBs.

[0186] In an example approach, the WTRU may change one or more resources from a previous iteration to one or more resources from a current iteration. After resource re-evaluation, the PHY layer of the WTRU may report a set of selectable resources, e.g., set A, to the MAC layer, which may then randomly select one resource set for the transmission of TB. The MAC layer of the WTRU may randomly reselect a set of resources for the retransmission. The MAC layer may perform resource selection if one or more of the previously selected resources are not in the set of selectable resources. If the MAC layer decides to perform resource selection, it may perform one or both of reselecting only at least one of the conflicting resources and / or reselecting the entire set of previously selected resources. The reselection may be performed based on association in one example. For example, the reselection may be performed based on association with the originally selected resources. Furthermore, the reselection may be performed based on association with the first resources.

[0187] The WTRU may decide whether to reselect only the collided resources or at least one of the entire set of previously selected resources based on one or any combination of the following: transmission type of TB and / or QoS of TB. In one example, for the transmission type of TB, the WTRU may decide to reselect the entire set of previously selected resources if the WTRU uses HARQ-based retransmission for TB. In a further example, the WTRU may decide to select the entire set of previously selected resources if the WTRU uses HARQ-based retransmission for TB, and reselect at least one of the collided resources only if blind retransmission is used for TB. Thereby, the WTRU may decide to reselect additional resources based on the HARQ status of the first resource. Furthermore, for the QoS of TB, the WTRU may decide to perform resource selection for at least one of the collided resources only if the priority of TB is higher than a threshold. Otherwise, the WTRU may perform resource selection for the entire set of previously selected resources.

[0188] In an example approach, the WTRU may determine to reselect at least one of only the collided resources. The WTRU may then randomly reselect one or more resources for transmission based on the number of collided 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, when the WTRU performs resource reselection of a first resource in the set of resources of a HARQ-based retransmission TB, the WTRU may exclude a set of selectable resources within the HARQ RTT from the second resource.

[0189] In an example example, when a WTRU needs to perform resource selection for unicast and / or groupcast traffic, the WTRU may select resources based on the availability of CSI reports. Specifically, if measured CSI is available in one set of subchannels, the WTRU may perform resource selection in the set of subchannels with associated CSI reports, in one example. Otherwise, if no CSI reports or wideband CSI reports are available, the WTRU may perform resource selection in the entire resource pool. In another example approach, the WTRU may apply different sets of RSRP thresholds between resources with CSI reports and resources without CSI reports.

[0190] In another example approach, the WTRU may determine when to stop the RSRP increments when performing resource evaluation or re-evaluation to determine the set of selectable resources. Specifically, the WTRU may be configured or pre-configured with a maximum RSRP threshold and / or a maximum number of RSRP increments during a resource re-evaluation procedure. The maximum RSRP threshold and / or the maximum number of RSRP increments may be determined based on one or any combination of the configured or pre-configured increments, the QoS of the TB, and / or the CBR of the resource pool.

[0191] In one example of configured or preconfigured increments, the WTRU may be configured or preconfigured with a certain number of RSRP increments, and the WTRU may stop incrementing the RSRP increments when the number of RSRP increments reaches a threshold.

[0192] In one example, the WTRU may be configured or pre-configured with respect to QoS of the TB. For example, the WTRU may be configured or pre-configured with a maximum number of RSRP increments based on the priority of the TB. Further, the WTRU may be configured or pre-configured with a high value of the maximum number of RSRP increments for high priority WTRUs and a low value of the maximum number of RSRP increments for low priority TBs.

[0193] With respect to the CBR of a resource pool, in one example, the WTRU may be (pre-)configured with a high value of the maximum number of RSRP increments if the CBR of the resource pool is high, and further, the WTRU may be configured or pre-configured with a low value of the maximum number of RSRP increments if the CBR of the resource is low.

[0194] In an example situation, the WTRU may perform resource selection for burst traffic. In an example approach, the WTRU may perform resource selection for burst traffic by performing resource contention for each TB in one subband. Specifically, the WTRU may divide the frequency domain of a resource pool into multiple subbands in one example. The bandwidth of each subband may depend on the size of each TB in the burst traffic. The WTRU may then independently perform the resource contention procedure for each TB in one subband.

[0195] In another example approach, the WTRU may occupy one or more subbands to perform clear channel assessment (CCA) and transmit one or more TBs. This approach may allow the WTRU to reduce CCA overhead because the WTRU may need to perform CCA once for one or more transmissions of one TB or multiple TBs.

[0196] The WTRU may determine a maximum channel occupancy time (MCOT) for each time it accesses the channel, or the WTRU may determine the MCOT over a period of time. The MCOT may be determined based on one or any combination of the number of TBs required for resource allocation, the QoS of each TB, the bandwidth of the occupied resources, and / or the CBR of the resource pool. For example, the WTRU may be configured for a higher MCOT if the CBR is low, and for a lower MCOT if the CBR is high. In an example regarding the QoS of each TB, the WTRU may determine the MCOT based on the number of transmissions for one TB, which may be determined based on the reliability of the TB. With regard to the bandwidth of the occupied resources, the WTRU may be configured for a smaller MCOT when using a higher bandwidth to balance between time and frequency resource usage, in one example.

[0197] In an example approach, the WTRU may combine backoff procedures for multiple TBs. For example, the WTRU may decide to perform resource allocation for bursty traffic by determining, for the bursty traffic, one or both of a backoff counter range and / or a backoff counter value.

[0198] The WTRU may then perform a backoff procedure for each TB sequentially. This approach may enable the WTRU to find an initial resource for transmission. The backoff counter range or backoff counter value may be determined based on one or more of the number of TBs required for resource allocation, the QoS of each TB, and / or the CBR of the resource pool.

[0199] For example, when the WTRU performs a resource selection procedure for one TB, it may be configured to randomly select a back-off value for the one TB in the range [0, N]. However, when the WTRU performs a resource selection procedure for two TBs in bursty traffic, the WTRU may sequentially select a back-off value for the first TB and the second TB in the range [0, N / 2].

[0200] In an example situation, the WTRU may perform resource selection to support congestion control. In an example approach, the WTRU may determine a set of non-selectable resources. Specifically, the WTRU may determine RSRP / RSRQ / RSSI thresholds in one example to determine whether a resource is selectable. The thresholds may be determined based on one or more of the QoS of the reserved resources, the QoS of the pending TB, and / or the CBR of the resource pool.

[0201] In an example approach, the WTRU may determine a set of non-selectable resources if the set satisfies the following: the set is reserved by one SCI and / or the measured RSRP / RSRQ / RSSI of the PSSCH / PSCCH used to reserve the resource set is greater than a threshold. In a further example, the threshold may be configured or pre-configured based on the relative priorities of the two TBs.

[0202] In another example approach, the WTRU may determine a set of non-selectable sources when reserved by one SCI, where the priority indicated in the SCI is one or more of below a threshold and / or below the priority of the pending TB minus Δ. Further, in one example, the value of Δ may be configured or pre-configured.

[0203] In an example situation, the WTRU may determine to perform congestion control by adjusting transmission parameters, dropping TBs, and / or preempting one or more resources when the number of selectable resources is less than a threshold or the number of non-selectable resources is greater than a threshold. In one example, adjusting the transmission may include one or more of changing the transmission power, e.g., reducing the transmission power, changing the number of subchannels selected per transmission, and / or changing the modulation and coding scheme (MCS). The threshold for performing congestion control may be fixed or determined based on the QoS of the TB and / or CBR of the resource pool.

[0204] In an example situation, the WTRU may perform one or more methods for preemption. In one approach, the WTRU may determine which resource pools are possible and what types of reserved resources are allowed for preemption. Based on a pool configuration, which may be configured or preconfigured in the WTRU or may be sent to the WTRU via a SIB or RRC, the WTRU may determine, for preemption in a resource pool, whether preemption is allowed, a priority range or another QoS parameter range of TBs for which the WTRU may perform preemption, a priority range or another QoS parameter range of reserved resources that may be preempted, a minimum priority difference or any QoS parameter difference between pending TBs and reserved resources allowed for preemption, a CBR threshold allowed for preemption, and / or any combination of a set of source ids and / or destination ids that may be associated with reserved resources that may be preempted.

[0205] In an example approach, the WTRU may be configured with different priority sets that are allowed to preempt reserved resources based on the CBR of the resource pool. Specifically, for one TB, the WTRU may determine whether to perform preemption based on the priority of the TB and the CBR of the resource pool, in one example.

[0206] In another example approach, the WTRU may determine whether preemption is allowed based on the CBR of the resource pool. Specifically, if the CBR is greater / less than a threshold, in one example, preemption may not be allowed. Otherwise, if the CBR is less / greater than a threshold, preemption may be allowed.

[0207] In an example situation, the WTRU may determine the set of resources it is allowed to preempt based on characteristics of its TB and characteristics of the reserved resources. Specifically, in one example, the characteristics of the pending TB may include one or more of the QoS of the TB, the cast type of the TB, and / or the size of the TB.

[0208] Additionally, the characteristics of the reserved resource may include any combination of: the QoS of the reserved resource, a cast type of the reserved resource, a size of the reserved resource, the reserved resource being a HARQ based initial transmission, the reserved resource being a HARQ based retransmission, the reserved resource being a blind retransmission, and / or the reserved resource being an initial blind transmission.

[0209] In an example approach, the WTRU may determine whether to preempt resources based on the QoS of its TB and the QoS of the reserved resources. The WTRU may be configured to preempt resources that have priority or other QoS information within a range or that have a priority differential or other QoS parameter differential that is greater than a configured or preconfigured threshold from the WTRU's pending TB. Additionally or alternatively, the WTRU may be configured to preempt one or more resources that have the lowest priority or the largest priority differential from its pending TB.

[0210] In another example approach, the WTRU may determine to preempt resources associated with one or more cast types based on the cast type of the pending TB. For example, if the pending TB is unicast, it may be possible to preempt only unicast traffic. Additionally or alternatively, if the pending TB is broadcast, it may be possible to preempt all cast types of the reserved resources.

[0211] In an example situation, the WTRU may determine which type of preemption based on the characteristics of the TB. One such preemption may be semi-persistent based preemption, where the WTRU may preempt reserved resources and use the preempted resources semi-persistently. Additionally or alternatively, the preemption may be dynamic based preemption, where the WTRU may preempt reserved resources and use the preempted resources for one-shot transmissions.

[0212] The WTRU may determine the type of preemption in the preemption indication message and may use one bit in the preemption indication message to indicate which type of preemption may be used. With respect to the duration of the preempted resources, the WTRU may decide to perform one of slot-based preemption and / or symbol-based preemption.

[0213] The duration of the preempted resources may be determined based on one or any combination of the QoS of the reserved TB, the size of the reserved TB, information communicated to the TB, and / or the frequency size of the reserved resources.

[0214] In one example approach, the WTRU may perform symbol-based preemption if the size of the TB is smaller than a threshold. Additionally or alternatively, the WTRU may perform symbol-based preemption for TBs that carry information such as CSI reports, PC5-RRC, etc. This approach may allow the WTRU to preempt fewer time resources for small TBs.

[0215] The WTRU, in one example, can indicate its preemption type in a preemption message to assist the receiver WTRU in sensing and resource selection procedures. Specifically, for example, the WTRU can implicitly / explicitly indicate whether the preemption type is semi-persistent or dynamic based. Furthermore, the WTRU, in one example, can further indicate whether the preemption is symbol-based or slot-based.

[0216] In one example, the WTRU may indicate the set of preempted WTRUs implicitly or explicitly by indicating the preempted resources. In an example approach, the WTRU may implicitly indicate the set of preempted WTRUs by indicating the preempted resources in the preemption message. After successfully decoding the preemption message, the receiver WTRU may identify whether it is preempted by identifying whether any of the reserved resources overlap with the preempted resources. In another example approach, the WTRU may explicitly indicate the preempted WTRUs and the set of preempted resources in the preemption message.

[0217] In an example situation, the WTRU may determine resources to transmit and monitor the preemption message. In an example approach, the WTRU may be configured to transmit the preemption message in a subchannel / slot / symbol dedicated to the PSCCH. In one example, the WTRU may determine the preemption message by a preemption-dedicated SCI format.

[0218] In another example approach, the WTRU may configure one or more resource pools to transmit the preemption message. Additionally or alternatively, the WTRU may configure a dedicated subchannel / slot to transmit the preemption message. The receiver WTRU may monitor the dedicated resource for a preemption indication to determine whether its reserved resources are to be preempted or to support a sensing and resource allocation procedure.

[0219] In another example approach, the WTRU may be configured with a rule for the time interval between a preemption indication transmission and a data transmission. The time interval between a preemption indication and a data transmission may be configured or preconfigured based on a resource pool. The configured or preconfigured value may be determined based on the time required for the WTRU to decode the preemption indication and cancel its transmission. Additionally or alternatively, this value may 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.

[0220] In an example approach, the WTRU may be configured with a time interval between a preemption indication and a data transmission based on the QoS of the preempted resource. Thus, the preempted WTRU may monitor for a preemption indication in a configured slot for preemption based on the QoS of its reserved resources.

[0221] In an example situation, the WTRU may decide to monitor a preemption indication based on its reserved resources and the configuration of a resource pool. In an example approach, the WTRU may decide to monitor a preemption indication if the reserved resources are allowed to be preempted. Specifically, the WTRU may decide to monitor preemption if one or more of the following apply: the reserved resources belong to a resource reservation type allowed to be preempted, the reserved resources belong to a configured or preconfigured resource set allowed to be preempted, the reserved resources for a TB with priority are allowed to be preempted, and / or the reserved resources belong to a cast type allowed to be preempted. In one example, one resource pool may allow preempt unicast or groupcast. In an example where the reserved resources belong to a resource reservation type allowed to be preempted, in one example, the resource pool may allow preempting semi-persistently reserved resources. In an example where the reserved resources belong to a configured or pre-configured resource set that is allowed to be preempted, in one example the resource set may be sub-channels and slots that are allowed to be preempted. With respect to the reserved resources of a TB that are allowed for preemption priority, the resources may be a low priority subset.

[0222] The WTRU may determine the number of preemption messages for transmission. The Tx WTRU may determine the number of preemption messages for a TB based on one or any combination of the QoS of the preempted resources, the QoS of the pending TBs, and / or the CBR of the resource pool.

[0223] In an example approach, the WTRU may be configured to transmit a fixed number of preemption messages for one TB. Additionally or alternatively, the WTRU may determine the number of preemption messages for one TB based on the CBR of the resource pool. This approach may be motivated to ensure reliability of the preemption messages.

[0224] In an example situation, the Tx WTRU may decide to trigger its TB based on one or any combination of the number of selectable resources in the resource selection procedure, the CBR of the resource pool, the QoS of the TB, and / or the backoff duration.

[0225] In an example approach, the WTRU may decide to perform preemption if the QoS of the TB exceeds a threshold, e.g., the priority of the TB is less than a threshold. Specifically, for example, the WTRU may perform preemption if the latency requirement of the TB is less than a threshold or if the priority of the TB is greater than a threshold.

[0226] In another example approach, the WTRU may perform resource selection for a pending TB. However, the WTRU may perform preemption if the set of selectable resources is smaller than a threshold or if the set of reserved or unavailable resources is larger than a threshold. The threshold may be fixed or determined, in one example, based on the QoS of the TB.

[0227] In another example approach, the WTRU may perform contention resolution, which may require the WTRU to perform CCA and / or backoff procedures to determine resources for transmission of the TB. In one example, the WTRU may decide to perform preemption if the number of CCAs is greater than a threshold or the backoff time is higher than a threshold. The threshold may be configured or preconfigured, or may be determined based on the QoS of the pending TB.

[0228] In an example situation, there may be certain Rx WTRU behaviors when the Rx WTRU detects a preemption indication. In an example approach, when the Rx WTRU successfully decodes a preemption indication that preempts resources that overlap with its reserved resources, the Rx WTRU may determine whether to perform collision avoidance, which may be performed by the WTRU to minimize resource collisions among multiple transmissions, based on one or any combination of 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 the preempted resource or resources.

[0229] In an example approach, the WTRU may perform collision avoidance if it successfully decodes the preemption indication. In another example approach, the WTRU may perform collision avoidance if it successfully decodes the preemption indication and the measured RSRP / RSSI from the preemption indication message is greater than a threshold. The threshold may be fixed, configured, or preconfigured based on the QoS of the preemption TB or the relative QoS of the preempted TB.

[0230] The receiving WTRU may perform collision avoidance by one or any combination of performing resource reselection, re-encoding the TBs, and / or dropping the pending TBs. In an example approach, the WTRU may perform collision avoidance by performing resource reselection. For example, the WTRU may perform collision avoidance by performing resource reselection for the sidelink process. The WTRU may also perform collision avoidance by performing resource reselection in other types of processes. In one example, the WTRU may perform resource reselection when the preempting WTRU preempts a resource and uses it semi-persistently. The WTRU may perform dynamic resource selection for the TBs that are expected to be transmitted in the preempted resources. Additionally or alternatively, in one example, the WTRU may perform resource reselection if the QoS of the reserved resources is greater than a threshold.

[0231] In another example approach, the receiving WTRU may decide to re-encode the TB and / or puncture / rate that matches the preempted resources if the percentage or amount of preempted resources is less than a threshold. The threshold may be determined to ensure that transmission of the TB in the remaining resources still meets the QoS requirements of the TB.

[0232] In an example situation, there may be other WTRUs that determine the availability of preempted semi-persistent resources. The WTRU may determine the availability of one reserved semi-persistent resource that is preempted based on the type of preemption. Specifically, the WTRU may determine that the reserved semi-persistent resource is still reserved if preemption is used for dynamic transmission. Additionally or alternatively, the WTRU may determine that the reserved semi-persistent resource is released and may be replaced by another semi-persistent resource if preemption is used for semi-persistent resource allocation.

[0233] FIG. 3A illustrates an example of resource selection and sensing. In the example illustrated in FIG. 3A, the WTRU may use resources over time shown on the x-axis and frequencies shown on the y-axis. The WTRU may reach a resource selection trigger at time n and select resources for future transmissions, such as resources 310A, 320A, and 330A. Furthermore, the WTRU may select resources, such as resources 310A, 320A, and 330A, that are located after time m in the time course and are within the packet delay budget (PDB). In one example, the selected resources may be considered pre-selected resources. The WTRU may further perform sensing. For example, the WTRU may perform sensing to decode the SCI of one or more other WTRUs. Furthermore, as a result of the sensing, in one example, the WTRU may determine the priority and RSRP / RSRQ / RSSI of reserved resources, such as resources 310A, 320A, and 330A. The sensing may be performed according to an example procedure described elsewhere herein. Additionally, the WTRU may perform resource re-evaluation based on the time interval between the selected resource and the remaining PDB, which may be determined according to examples provided elsewhere herein.

[0234] In one example, the WTRU may be a receiver WTRU. In a further example, the WTRU may be a V2X WTRU. In another example, the WTRU may be a SL WTRU.

[0235] FIG. 3B illustrates an example of resource re-evaluation including a resource re-evaluation trigger. In the example shown in FIG. 3B, the WTRU may decide to perform resource re-evaluation. Moreover, the procedure of FIG. 3B may occur after FIG. 3A. In an example, the WTRU may determine that a trigger may be met to perform resource re-evaluation. Furthermore, the WTRU may make the decision based on example procedures described elsewhere herein, such as one or any combination of sensing, QoS, latency requirements, or PDB. Furthermore, the WTRU makes the decision at time k as shown in FIG. 3B.

[0236] The WTRU may, in one example, decide to re-evaluate resources and decide not to make changes to the resources. In another example, the WTRU may decide to re-evaluate resources and decide to make changes to the resources. For example, the WTRU may determine that one or more preselected resources need to be removed from the resources used. Thus, one or more resources need to be reselected from the selectable resources to replace the one or more removed preselected resources. For example, the WTRU may determine that one or more preselected resources need to be removed due to a collision. For example, the WTRU may determine that one or more preselected resources are used by another WTRU, potentially causing a collision, as described in examples provided elsewhere herein. By performing resource re-evaluation, the WTRU may perform collision avoidance accordingly. Furthermore, the WTRU may complete the re-evaluation at time k+T1.

[0237] In the example shown in FIG. 3B, the WTRU may perform a re-evaluation and determine that resource 310B needs to be replaced due to a collision. The WTRU may also replace resource 310B with one or more of resources 320B, 330B, 340, 350, 360, 370, 380, 390. These resources may be located at a time between time m and time k+T2. Furthermore, these resources may be used for one or more TBs. In one example, the TBs may include one or more HARQ-enabled TBs, and in another example, the TBs may include one or more HARQ-disabled TBs, as further described below.

[0238] FIG. 4 illustrates an example of resource re-evaluation including a HARQ-enabled TB. In the example illustrated in FIG. 400, the WTRU performs resource re-evaluation and reselection resources to enable a TB or a HARQ process for one or more TBs. The WTRU needs to determine which resources to reselect in the example illustrated in FIG. 4 that are far enough apart in time that the HARQ process can function properly. For example, the WTRU may reselect resource 450 to replace resource 310B that must be replaced due to a collision, as described above. However, the WTRU may then not also reselect resource 420 because it is too close in time to resource 450 to allow the HARQ process to function properly. Instead, the WTRU may reselect resource 470, which is far enough away in time from resource 450 to allow the HARQ process to function properly. Furthermore, the WTRU may then not also reselect resource 430 because it is too close in time to resource 470 to allow the HARQ process to function properly. Thus, the WTRU may reselect resource 490 because it is far enough away in time from resource 470 to allow the HARQ process to function properly.

[0239] In this manner, the WTRU may reselect the first resource 310B and replace the first resource with the second resource 450. Additionally, the WTRU may reselect the third resource 470 based on the association with the second reselected resource 450. Also, resource 490 may be reselected. As a result, resources 470, 490 may also be reselected because the second resource is associated with a HARQ enablement process. Thus, resources are reselected based on the association.

[0240] In one example, resources 440, 460, 480 are generally selectable resources that are also potentially available for reselection. For example, the WTRU may reselect resource 440 instead of resource 450.

[0241] FIG. 5 is a diagram illustrating an example of resource re-evaluation including HARQ disabled TB. In the example illustrated in FIG. 500, the WTRU performs resource re-evaluation and reselection resources for a TB or one or more TBs that disable the HARQ process. Thus, the WTRU may determine which resources to reselect regardless of the interval time for the HARQ process function. For example, the WTRU may reselect resource 550 to replace resource 310B that must be replaced due to a collision, as described above. In one example, the WTRU may continue to use resource 520 despite its proximity to resource 550. For example, resource 520 may be reselected and the WTRU may decide to use resource 520 again. Similarly, the WTRU may continue to use resource 530 despite its proximity to resource 520.

[0242] In this manner, the WTRU may reselect the first resource 310B and replace the first resource with the second resource 550. Additionally, the WTRU may reselect the third resource 520 based on the association with the second reselected resource 550 and retain resource 520 as a used resource in this reselection. Also, the WTRU may reselect resource 530 and retain resource 530 as a used resource in this reselection. Thus, resources are reselected based on association.

[0243] In one example, resources 540, 560, 570, 580, 590 are generally selectable resources that are also potentially available for reselection. For example, the WTRU may reselect resource 440 instead of resource 550.

[0244] In one example, the WTRU may perform resource selection to determine a set of resources to be used for transmission, e.g., the resources may be used to transmit one or more TBs. Further, the set of resources used for transmission may be referred to as a previously selected set of resources.

[0245] Furthermore, the WTRU may dynamically decide to trigger resource re-evaluation. The WTRU may make this decision based on the feasibility of meeting the latency requirement. For example, one or more resources may be found to be capable of meeting the latency requirement. In another example, one or more resources may be found to be incapable of meeting the latency requirement. Thus, these one or more resources may need to be replaced with one or more other resources. Resource re-evaluation may include the determination of one or more potential collisions of one or more resources in the previously selected set of resources.

[0246] Additionally, the latency requirement may include the remaining PDB of the TB, and the latency requirement may include the time interval between the previously selected resource and the remaining PDB of the second TB.

[0247] In one example, the WTRU may determine a set of selectable resources by performing resource re-evaluation based on a previously selected set of resources and removing one or more resources from the previously selected set of resources. Furthermore, the WTRU may reselect at least one first resource from the previously selected set of resources. In one example, the at least one first resource may not be in the set of selectable resources. Furthermore, the WTRU may reselect the at least one first resource and replace the first resource with at least one second resource from the set of selectable resources. Furthermore, the WTRU may reselect at least one third resource from the set of selectable resources based on an association with the at least one second resource. The WTRU may then transmit the first TB using the at least one second resource.

[0248] In a further example, the WTRU may determine the set of selectable resources by performing resource re-evaluation based on the set of previously selected resources. Furthermore, the WTRU may select at least one first resource from the set of previously selected resources. In one example, the at least one first resource may not be in the set of selectable resources. Furthermore, the WTRU may replace the first resource with at least one second resource. In one example, the at least one second resource may be in the set of selectable resources. Furthermore, the WTRU may 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 may then transmit the first TB using the at least one second resource.

[0249] In an additional example, the WTRU may reselect at least one fourth resource based on the association with the at least one second resource. In yet another example, the WTRU may reselect at least one fifth resource based on the association with the at least one second resource. In additional embodiments, the WTRU may reselect additional resources based on the association with the at least one second resource.

[0250] In one example, one or more resources may be removed based on a collision, for example, a foreseeable and likely collision with a transmission of another WTRU, which in one example may be a V2X WTRU.

[0251] In one example, the association with the at least one second resource may be based on a HARQ state of the first TB. The HARQ state may be, in one example, an enabled HARQ state of the TB. Thus, the TB may be a HARQ enabled TB.

[0252] In a further example, the HARQ state may be, in one example, a disabled HARQ state for the TB. Thus, the TB may be a HARQ disabled TB. Further, the additional resources may include future HARQ transmissions associated with the first TB. For example, at least one third resource may be used for HARQ transmissions associated with the first TB.

[0253] In a further example, the association with the at least one second resource may be based on a grant. In one example, the grant may be a periodic reservation grant. Thus, the association with the at least one second resource may be based on a periodic reservation grant associated with the first TB. Furthermore, the additional resources may include resources associated with a periodic reservation grant. For example, the at least one third resource may be associated with a periodic reservation grant.

[0254] Furthermore, the preempted resources may also be periodically reserved resources. In one example, the periodically reserved resources may be used by the WTRU to transmit a periodically reserved transmission. Thus, the preempted resources may be used by the WTRU to transmit a periodically reserved transmission, in one example. In another example, the WTRU may intend to transmit a periodically reserved transmission using the preempted resources. Furthermore, the WTRU may not use the preempted resources for one or more future periodically reserved transmissions after selection or reselection, in one example. For example, after selection or reselection, the WTRU may not use at least one first resource for a current periodically reserved transmission and / or one or more future periodically reserved transmissions. Thus, the WTRU may assume that the preempted resources may be unavailable in a future time period. In one example, the preempted resources may be unavailable due to a collision.

[0255] In one example, the preempted resource may be one of the one or more deleted resources. For example, the preempted resource may be at least the first resource. Further, the periodically reserved transmission may be associated with a periodic reservation grant.

[0256] Example scenarios provided herein include a method of supporting reservation of an initial transmission. In an example scenario, the WTRU may determine a resource reservation type. For example, the WTRU may support reservation of the same TB feature, where a first PSCCH+PSSCH using a first frequency resource allocation reserves 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 smaller than, equal to, or larger than the size of the second frequency allocation. The WTRU may determine a 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 size of the frequency resource allocation of the second PSCCH+PSSCH, the size of the TB, the QoS of the TB, and / or the CBR of the resource pool.

[0257] In an example approach, the WTRU may determine a size difference between the first and second frequency resource allocations based on the size of the first PSCCH+PSSCH frequency resource allocation. Specifically, the WTRU may determine that the sizes of the first and second frequency resource allocations are equal if the size of the second PSCCH+PSSCH frequency resource allocation is smaller than a threshold. Additionally or alternatively, the WTRU may determine that the size of the first frequency resource allocation is smaller than the size of the second frequency allocation if the frequency size of the second PSCCH+PSSCH is greater than a threshold. For example, if the size of the first PSCCH+PSSCH frequency resource allocation is less than or equal to two subchannels, the WTRU may determine that the sizes of the first and second PSCCH+PSSCH frequency resource allocations are equal. However, if the size of the frequency resource allocation of the second PSCCH+PSSCH is greater than two subchannels, the WTRU may determine that the size of the frequency resource allocation of the second PSCCH+PSSCH is greater than the size of the frequency resource allocation of the first PSCCH+PSSCH. In one example, the size of the frequency resource allocation of the first PSCCH+PSSCH may be one subchannel.

[0258] In another example approach, the WTRU may determine a size difference between the first and second frequency resource allocations based on the size of the TB. Specifically, if the size of the TB is smaller than a threshold, in one example, the WTRU may determine that the first and second sizes of the frequency resource allocations are equal. Additionally or alternatively, if the size of the TB is larger than a threshold, the WTRU may determine that the size of the first PSCCH+PSSCH frequency resource allocation is smaller than the size of the second PSCCH+PSSCH frequency resource allocation.

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

[0260] In an example situation, the WTRU may select between reservation for the same TB and reservation for another TB feature. The WTRU may decide to use reservation for the same TB and / or reservation for another TB feature based on one or more of the size of one TB and / or the required frequency size of one TB, the QoS of one TB, and / or other information available to the WTRU. In an example regarding the size and / or the required frequency size of one TB, if the WTRU has two TBs in 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 reservation for another TB feature. In one example, the frequency may be one subchannel. In one example, regarding the QoS of one TB, the WTRU may decide to use reservation for another TB feature if the WTRU needs to transmit one low QoS TB. Regarding the WTRU has other information available that the WTRU may need to transmit, in one example, the WTRU may use reservation for another TB feature if it has CSI information to report / transmit.

[0261] The embodiments provided herein include a method for supporting network scheduling. For example, in NR V2X, there may be a modified method for supporting network scheduling. For example, there may be a method for supporting MCS table indication. In some circumstances, the WTRU may indicate its MCS table used for PSSCH transmission to the receiver WTRU. The WTRU may implicitly or explicitly indicate the used MCS table 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 with a mapping between a set of QoS parameters and MCS tables. The WTRU may then implicitly indicate the used MCS table by conveying the QoS parameters to the receiving WTRU.

[0262] In an example situation, there may be a way to support feedback-based HARQ retransmission. In an example situation, the WTRU may determine which TB to transmit in a grant scheduled by the gNB. The WTRU may have TBs in a MAC buffer and one or more TBs in a HARQ buffer. In an example approach, the WTRU may determine which TB to transmit in a grant scheduled by the gNB based on one or any combination of the QoS of each TB, the size of the scheduled grant, the buffer of the TB, whether UL HARQ of the TB is being transmitted, and / or the cast type of the TB.

[0263] In one example, the WTRU with respect to the QoS of each TB may prioritize the TB with the highest priority. With respect to the size of the scheduled grant, in one example, when the WTRU needs to determine which TBs in the HARQ buffer are to be transmitted, the WTRU may prioritize the TBs that require the smallest change in MCS compared to the previous transmission. Additionally or alternatively, the WTRU may prioritize TBs that have an MCS equal to or less than the MCS of the previous transmission.

[0264] With regard to the buffer of TBs, the WTRU may, in one example, prioritize the TBs in the HARQ buffer. With regard to whether UL HARQ of a TB has been transmitted, when the WTRU needs to decide which TB in the HARQ buffer to transmit, the WTRU may prioritize the TB for which the NACK status is conveyed to the gNB. With regard to the cast type of TBs, in one example, if two TBs have the same priority, the WTRU may prioritize the broadcast transmission.

[0265] In an example, the WTRU may determine a transmission type of the retransmission for unicast / groupcast. The WTRU may support the following retransmission types: blind retransmission and / or feedback-based retransmission.

[0266] For blind retransmission, the WTRU may perform blind retransmission by using the same or a different redundancy version (RV) as the initial transmission. Furthermore, the WTRU may indicate to the receiver WTRU that HARQ feedback should be disabled or that the WTRU is unable to monitor HARQ feedback of the initial transmission. For feedback-based retransmission, the WTRU may decide to perform a retransmission based on HARQ feedback from the receiving WTRU. Furthermore, the WTRU may hear HARQ feedback from the receiver WTRU and indicate to the receiver WTRU to enable HARQ feedback.

[0267] The WTRU may determine the retransmission type of the TB based on the timing of the initial transmission, the retransmission, and the timing of the UL HARQ feedback and the SL HARQ feedback. In an example approach, the WTRU may decide to perform a blind retransmission when it receives a DCI that schedules resources for both the initial transmission and the retransmission, and the timing of the UL HARQ feedback for the transmission is after the retransmission. In another example approach, the WTRU may decide to perform a HARQ-based retransmission if the WTRU receives a DCI that schedules the UL HARQ feedback between the initial transmission and the retransmission.

[0268] 6 shows an example of a WTRU determining the type of retransmission based on the timing of the initial transmission, the retransmission, and the UL HARQ feedback. In the example shown in FIG. 100 of option 1, the WTRU may perform a blind retransmission, and in option 2, the WTRU may perform a HARQ-based retransmission.

[0269] Thus, in option 1, the WTRU may receive DCI 610 scheduling resources for both the initial transmission 630 and the retransmission 650, with the timing of the UL HARQ feedback 670 for the transmission being after the retransmission 650. As a result, the WTRU may decide to perform a blind retransmission.

[0270] Further, in option 2, the WTRU may receive a DCI 620 that schedules the UL HARQ feedback 660 between the initial transmission 640 and the retransmission 680. As a result, the WTRU may decide to perform a HARQ-based retransmission.

[0271] In an example situation, the WTRU may receive a DCI that schedules UL HARQ feedback between the initial transmission and the retransmission timing resource. The WTRU may indicate to the gNB about the use of the retransmission resource. The UL HARQ feedback may indicate one or more of the following: the WTRU uses a grant for retransmission of the same TB, the WTRU uses a grant for transmission of another TB, and / or the WTRU releases a grant. In another example approach, the WTRU may decide to use the retransmission resource scheduled in one DCI for transmission of another TB if it receives an ACK from the receiver WTRU for the previous transmission.

[0272] In one example, the WTRU may determine a type of retransmission for a configured grant. In an example situation, the WTRU may be configured with one or more Type-1 and / or Type-2 configured grants. The WTRU may determine a retransmission type for the configured grant based on one or more of the following: availability of UL HARQ feedback for the configured grant, the number of resources for the transmission of one TB, and / or the time interval between two resources for the transmission of one TB. With respect to the availability of UL HARQ feedback for the configured grant, in an example unicast / groupcast scenario, the WTRU may determine to perform a blind retransmission if the configured grant does not include UL HARQ feedback. Furthermore, with respect to the number of transmission resources per TB, the WTRU may perform a blind transmission in one example if the number of retransmission resources per TB is greater than a threshold. In one example with respect to the time interval between two resources for the transmission of one TB, the WTRU may determine to perform a blind retransmission if the time interval between two consecutive resources for the transmission of a TB is less than a threshold. Additionally or alternatively, the WTRU may perform feedback-based HARQ retransmission if the time interval between two consecutive resources is greater than a threshold, which may be determined based on one or more of the QoS of the data and / or a resource pool configuration, such as a periodicity of the PSFCH slots and a resource pool bitmap, in one example.

[0273] In an example situation, there may be a way to support in-coverage and out-of-coverage communication. In an example situation, a Tx WTRU may transmit information about its Tx pool to an Rx WTRU. Specifically, the Tx WTRU may transmit information about its Tx pool to an Rx WTRU implicitly or explicitly. The information about the Tx pool may include one or more of information that a slot belongs to a resource pool, e.g., a bitmap of the resource pool, information about the periodicity of the PSFCH slots, information about the subchannel size, information about the number of subchannels in the resource, information about the first and last RB of the resource pool.

[0274] In an example approach, the WTRU may transmit resource pool information during a link establishment procedure for a unicast scenario. In another example approach, the Tx WTRU may transmit some information regarding the resource pool implicitly or explicitly in the SCI. Specifically, the WTRU may transmit information regarding the PSFCH periodicity in the SCI. Additionally or alternatively, the WTRU may be configured or pre-configured with a list of resource pools to indicate to the Rx WTRU, and the WTRU may indicate the index of the resource pool to the Rx WTRU. In another example approach, the Tx WTRU may indicate some information regarding the resource pool in the PSBCH. For example, the WTRU may indicate one or more of the following in the resource pool: PSFCH periodicity of the resource pool in the PSBCH, whether HARQ is enabled / disabled, and / or HARQ feedback option information.

[0275] In an example, the WTRU may use the resource pool information. In an example situation, the Rx WTRU may use the resource pool information transmitted by the Tx WTRU to determine the PSFCH resource to transmit sidelink HARQ feedback and / or perform sensing and resource selection.

[0276] In an example situation, there may be a way to support a feedback indication to the network. For example, a problem may arise when a WTRU may schedule a set of resources with an associated PUCCH and may expect the gNB to transmit a HARQ enable TB. However, in a logical channel prioritization (LCP) procedure, the WTRU may transmit a HARQ disable TB. Therefore, it may be necessary to address how the WTRU reports the HARQ ACK / NACK to the network.

[0277] The WTRU may be provided with a PUCCH resource in a dynamic or configured grant to report the HARQ status of its transmission on the associated grant, e.g., ACK / NACK. In the grant associated with the PUCCH resource, the WTRU may decide to transmit a TB with HARQ disabled. The WTRU may then decide to report either a HARQ ACK or a HARQ NACK based on one or any combination of parameters.

[0278] One such parameter for deciding to report a HARQ ACK or NACK may be the QoS of the TB. For example, the WTRU may report a HARQ ACK if the priority and / or reliability of the TB is greater than a threshold, and may report a HARQ NACK if the priority and / or reliability of the TB is less than a threshold. The threshold may be configured or pre-configured by the network.

[0279] One such parameter for deciding to report a HARQ ACK or NACK may be the logical channels multiplexed into the grant, for example, the WTRU may be configured with a set of logical channels that, when multiplexed in the TB, trigger a HARQ ACK / NACK indication.

[0280] One such parameter for deciding to report a HARQ ACK or NACK may be the amount of allocated resources. For example, the WTRU may decide to report a HARQ ACK or a HARQ NACK based on the amount of resources allocated to the WTRU. Specifically, if the amount of scheduled resources is greater than a threshold, the WTRU may report a HARQ ACK, and if the amount of scheduled resources is less than a threshold, the WTRU may report a HARQ NACK. The threshold may be fixed, (pre-)configured, and / or determined based on the QoS of the final TB transmitted in the scheduled resources.

[0281] One such parameter for deciding to report a HARQ ACK or NACK may be the number of transmitted resources for the final TB before reporting HARQ feedback.

[0282] One such parameter for deciding to report a HARQ ACK or NACK may be the type of assigned grant. In an example, the grant may be a configured grant or a dynamic grant. For example, the WTRU may always report a HARQ ACK for a dynamic grant and may decide to report either a HARQ ACK or a HARQ NACK for a configured grant.

[0283] One such parameter for deciding to report a HARQ ACK or NACK may be the cast type.

[0284] One such parameter for deciding to report a HARQ ACK or NACK may be the buffer status of the WTRU or any indicator of the amount of data the WTRU needs to transmit. For example, the WTRU may report a NACK if the buffer status of a logical channel group (LCG), which may potentially be related to the QoS of the transmitted TB, exceeds a threshold.

[0285] One such parameter for deciding to report a HARQ ACK or NACK may be the CBR, for example, the WTRU reports an ACK if the CBR exceeds a threshold and a NACK otherwise.

[0286] In an exemplary example, the WTRU may decide to report a HARQ ACK or HARQ NACK based on the number of transmissions made by the WTRU for the WTRU's last TB and the priority and / or reliability of the TB. Specifically, the WTRU may determine the number of expected transmissions of the TB based on its priority and / or reliability. The WTRU may then decide whether to transmit a HARQ ACK or NACK based on both the number of expected transmissions of the TB and the number of transmissions made for the TB. If the number of expected transmissions is greater than the number of transmissions made by the WTRU, the WTRU may report a HARQ NACK. Otherwise, the WTRU may report a HARQ ACK.

[0287] In another illustrative example, the WTRU may decide to report a HARQ ACK or a HARQ NACK based on the timing and / or amount of the future grant. Specifically, if the future timing of the future grant is less than the PDB of the TB, the WTRU may report a HARQ ACK. Otherwise, the WTRU may report a HARQ NACK. The future grant may belong to a configured grant set or a future resource set of a dynamic grant.

[0288] In another illustrative example, the WTRU may decide to report a HARQ ACK or HARQ NACK based on its buffer status and available resources in the future. Specifically, the WTRU may report a HARQ NACK if it still has data in its buffer, e.g., data may be stored in a MAC, radio link control (RLC) buffer, or HARQ buffer, and / or future resources cannot meet the QoS of the pending data in the buffer. Additionally or alternatively, the WTRU may report a HARQ NACK if it does not have data in its buffer.

[0289] The WTRU may report a HARQ ACK under example conditions. In another example example, the WTRU may report a HARQ ACK if the last TB transmitted on a resource with an associated PUCCH is a HARQ disabled TB.

[0290] In another illustrative example, the WTRU may decide to select between HARQ-enabled sidelink radio bearers (SLRBs) and HARQ-disabled SLRBs to multiplex in the TB. The WTRU may be configured or pre-configured with a priority gap between HARQ-enabled SLRBs and HARQ-disabled SLRBs to determine which type of SLRBs to multiplex in the TB for a resource with an associated PUCCH. Specifically, if the priority of the HARQ-enabled SLRBs is equal to or greater than the HARQ-disabled SLRBs plus the priority gap, the WTRU may prioritize the HARQ-enabled SLRBs over the HARQ-disabled SLRBs in one example. The priority gap may be configured or pre-configured or may be fixed. For example, if the priority gap is fixed to zero, the WTRU may prioritize the HARQ-enabled SLRBs over the HARQ-disabled SLRBs in a resource with an associated PUCCH if both SLRBs have the same priority.

[0291] In an example, the WTRU may decide to trigger a scheduling request (SR) and / or a buffer status report (BSR). In another example approach, the WTRU may be configured with an SR associated with transmission of a HARQ disablement TB on a resource having an associated PUCCH. The WTRU may trigger an SR and / or a BSR when the WTRU transmits a HARQ disablement TB on a final resource associated with a PUCCH. The WTRU may further trigger an SR and / or a BSR only when the WTRU reports a particular value of ACK or NACK based on any of the conditions discussed herein, e.g., a BSR is triggered when the WTRU reports a NACK. After the WTRU uses retransmission resources provided by the network after reporting a NACK, the WTRU may further calculate a BSR. The WTRU may be further configured or pre-configured with one or any combination of criteria / conditions to trigger an SR and / or a BSR.

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

[0293] One criterion / condition may be the number of transmissions made by the WTRU for the TB. For example, if the number of transmissions made by the WTRU for the final TB is less than a threshold, the WTRU may trigger an SR and / or a BSR. The threshold may be determined based on the QoS of the TB. Additionally or alternatively, the WTRU may trigger an SR and / or a BSR if it needs more resources to transmit the final TB.

[0294] One criterion / condition may be the buffer status of the WTRU, for example, the WTRU may trigger an SR and / or a BSR if it has data in its buffer.

[0295] One criterion / condition may be the amount of allocated resources. For example, if the amount of allocated resources is less than a threshold, the WTRU may trigger an SR and / or a BSR. The threshold may be determined based on the configured or preconfigured QoS of the TB.

[0296] One criterion / condition may be the type of allocated resource, e.g., if a HARQ disabled TB is transmitted in a configured grant, the WTRU may trigger an SR and / or a BSR, and if a HARQ disabled TB is transmitted in a dynamic grant, the WTRU may not trigger an SR.

[0297] One criterion / condition may be a cast type, for example, the WTRU may trigger an SR and / or a BSR based on the cast type.

[0298] In one example, the WTRU may cancel a pending BSR / SR transmission in case of reporting a NACK to a transmission without HARQ. Specifically, the WTRU may have a pending BSR transmission due to the arrival of new data for a potentially higher priority logical channel (LCH). The WTRU may decide to cancel such a BSR if it determines that it can perform a sidelink transmission for the new data in retransmission resources provided by the network. Specifically, the WTRU may decide to cancel a BSR if the amount of resources associated with the initial TB is large enough to transmit the new data in the buffer and / or the expected retransmission resource timing meets the latency requirement of the new data that triggered the BSR.

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

[0300] Although the features and elements are described above in certain combinations, one skilled in the art will understand that each feature or element may be used alone or in any combination with the other features and elements. Furthermore, the methods described herein may be implemented in a computer program, software, or firmware embodied 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 disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. 1. A method for use in a wireless transmit / receive unit (WTRU), comprising: receiving first data in a first physical sidelink shared channel (PSSCH) transmission; Transmitting second data on a second PSSCH transmission; and receiving third data in a third PSSCH transmission; determining a prioritization between transmitting a physical sidelink feedback channel (PSFCH) and receiving a 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; determining, subject to a determination of the prioritization to a determination of transmission of the PSFCH, to transmit a single PSFCH transmission or multiple PSFCH transmissions based on a power level of a first PSFCH transmission associated with the first data and a power level of a second PSFCH transmission associated with the third data; determining whether the single PSFCH transmission is the first PSFCH transmission or the second PSFCH transmission based on the first priority associated with the first data and the third priority associated with the third data, on a condition that transmission of the single PSFCH transmission is determined; transmitting the single PSFCH transmission, where, on a condition that the single PSFCH transmission is determined to be the first PSFCH transmission, a first Hybrid Automatic Repeat Request (HARQ) Response (ACK) / Negative ACK (NACK) feedback associated with the first data is transmitted in the first PSFCH transmission, and, on a condition that the single PSFCH transmission is determined to be the second PSFCH transmission, a second HARQ ACK / NACK feedback associated with the third data is transmitted in the second PSFCH transmission; A method comprising:

2. 2. The method of claim 1, further comprising receiving a first sidelink control information (SCI) associated with the first PSSCH transmission.

3. 2. The method of claim 1, further comprising transmitting a second SCI associated with the second PSSCH.

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 a 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 a 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 dropped based on the first priority and the third priority.

11. 2. The method of claim 1, further comprising: receiving a third PSFCH transmission associated with the second data, conditional on reception of the PSFCH being determined in the prioritization determination, wherein a third HARQ ACK / NACK feedback associated with the second data is received in the third PSFCH transmission.

12. 2. The method of claim 1, further comprising: transmitting the first PSFCH transmission and the second PSFCH transmission, conditional on a determination of transmission of the plurality of PSFCH transmissions, wherein the first PSFCH transmission transmits the first HARQ ACK / NACK feedback associated with the first data, and the second PSFCH transmission transmits the second HARQ ACK / NACK feedback associated with the third data.

13. 1. A wireless transmit / receive unit (WTRU), comprising: Transceiver and a processor operably coupled to the transceiver, the transceiver and the processor are configured to receive first data in a first physical sidelink shared channel (PSSCH) transmission; the transceiver and the processor are configured to transmit second data on a second PSSCH transmission; the transceiver and the processor are configured to receive third data in a third PSSCH transmission; the processor is configured to determine a prioritization between transmitting a physical sidelink feedback channel (PSFCH) and receiving a 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 determine, on condition that the transmission of the PSFCH is determined in the prioritization determination, to transmit a single PSFCH transmission or multiple PSFCH transmissions based on a power level of a first PSFCH transmission associated with the first data and a power level of a second PSFCH transmission associated with the third data; the transceiver and the processor are configured to determine, on a condition that a transmission of the single PSFCH transmission is determined, whether the single PSFCH transmission is the first PSFCH transmission or the second PSFCH transmission based on the first priority associated with the first data and the third priority associated with the third data; the transceiver and the processor are configured to transmit the single PSFCH transmission, and, conditional on the determination that the single PSFCH transmission is the first PSFCH transmission, a first hybrid automatic repeat request (HARQ) response (ACK) / negative ACK (NACK) feedback associated with the first data is transmitted in the first PSFCH transmission, and, conditional on the determination that the single PSFCH transmission is the second PSFCH transmission, a second HARQ ACK / NACK feedback associated with the third data is transmitted in the second PSFCH transmission.

14. 14. The WTRU of claim 13, wherein the transceiver and the processor are further configured to receive a first sidelink 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.

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 a 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 a 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 a 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 dropped based on the first priority and the third priority.

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

24. 14. The WTRU of claim 13, wherein the transceiver and the processor are further configured to transmit, conditional on a determination to transmit the plurality of PSFCH transmissions, the first PSFCH transmission and the second PSFCH transmission, wherein the first HARQ ACK / NACK feedback associated with the first data is transmitted in the first PSFCH transmission and the second HARQ ACK / NACK feedback associated with the third data is transmitted in the second PSFCH transmission.

Images