New Radio (NR) Vehicle-to-Everything (V2X) Method 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 on August 13, 2019; U.S. Provisional Patent Application No. 62 / 908,089, filed on September 30, 2019; and U.S. Provisional Patent Application No. 62 / 975,552, filed on February 12, 2020, the contents of which are incorporated herein by reference.

Background Art

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

[0003] New Radio (NR) V2X operations are being developed. V2X communication may include one or more of vehicle - to - vehicle (V2V) communication, vehicle - to - pedestrian (V2P) communication, vehicle - to - infrastructure (V2I) communication, and vehicle - to - network (V2N) communication. A V2X wireless transmit receive unit (WTRU) may be involved in V2X communication.

Summary of the Invention

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

[0005] Furthermore, WTRU may dynamically decide to trigger a resource reassessment. WTRU can make this decision based on the feasibility of meeting latency requirements. Additionally, latency requirements may include the remaining PDBs of the TB. Latency requirements may also include the time interval between the previously selected resource and the remaining PDBs of the second TB.

[0006] In one example, a WTRU may determine the set of selectable resources by performing a resource reassessment 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, 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, 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 its association with at least one second resource. The WTRU may then use at least one second resource to send the first TB.

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

[0008] In an additional example, association with at least one second resource may be based on a permission. In one example, the permission may be a periodic reservation permission. Thus, association with at least a second first resource may be based on a periodic reservation permission associated with the first TB. Furthermore, additional resources may include resources associated with periodic reservation permissions. For example, at least one third resource may be associated with a periodic reservation permission. Furthermore, a preempted resource may also be a periodically reserved resource. In another example, one or more resources may be deleted based on a conflict. [Brief explanation of the drawing]

[0009] A more detailed understanding can be obtained from the following explanation, which is given as an example in conjunction with the attached drawings, where similar reference numbers in the drawings indicate similar elements.

[0010] [Figure 1A] This is a system diagram showing an exemplary communication system in which one or more disclosed embodiments may be implemented.

[0011] [Figure 1B] This is a system diagram showing an exemplary wireless transmitter / receiver unit (WTRU) that may be used in the communication system shown in Figure 1A, according to one embodiment.

[0012] [Figure 1C] This is a system diagram showing an exemplary radio access network (RAN) and an exemplary core network (CN) that may be used in the communication system shown in Figure 1A according to one embodiment.

[0013] [Figure 1D] This is a system diagram showing further exemplary RAN and further exemplary CN that may be used in the communication system shown in Figure 1A according to one embodiment.

[0014] [Figure 2] FIG. is an example of a potentially reserved slot when the WTRU is not monitoring in one slot.

[0015] [Figure 3A] FIG. is an example showing resource selection and sensing.

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

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

[0018] [Figure 5] FIG. is an example of resource re - evaluation including a HARQ disabled TB.

[0019] [Figure 6] FIG. is an example of a WTRU that determines the type of re - transmission based on the timing of initial transmission, re - transmission, and uplink (UL) HARQ feedback. DETAILED DESCRIPTION OF THE INVENTION

[0020] FIG. 1A is a diagram showing an exemplary communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 can be a plurality of access systems that provide content such as voice, data, video, messaging, broadcast, etc. to a plurality of wireless users. The communication system 100 can enable a plurality of wireless users to access such content through sharing of system resources including wireless bandwidth. For example, the communication system 100 can 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 filter type OFDM, filter bank multicarrier (FBMC), etc.

[0021] As shown in Figure 1A, the communication system 100 may include radio 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, but it will be understood that the disclosed embodiments intend any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a radio environment. For example, WTRU102a, 102b, 102c, and 102d, all of which may be referred to as stations (STA), may be configured to transmit and / or receive radio signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscriber-based units, pagers, 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, and devices operating on commercial and / or industrial wireless networks. Any of WTRU102a, 102b, 102c, and 102d may interchangeably be referred to as UE.

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

[0023] Base station 114a may be part of 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). Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies which may be referred to as cells (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of radio services to a particular geographic area which may be relatively fixed or change over time. A cell may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one for each sector of the cell. In one embodiment, the base station 114a can use multiple-input multiple output (MIMO) technology and utilize multiple transceivers per cell sector. For example, beamforming can be used to transmit and / or receive signals in a desired spatial direction.

[0024] Base stations 114a and 114b may communicate with one or more WTRUs 102a, 102b, 102c, and 102d via an air interface 116, which may be any suitable radio 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 described above, the communication system 100 may be a multi-access system and may use one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base stations 114a of RAN 104 and WTRU 102a, 102b, 102c may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA) and can establish an air interface 116 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​Uplink (UL) Packet Access (HSUPA).

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

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

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

[0029] In other embodiments, base stations 114a and WTRUs 102a, 102b, and 102c may implement wireless technologies 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, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile communications (GSM), GSM Evolution (Enhanced Data rates for GSM Evolution, EDGE), and GSM EDGE (GERAN).

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

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

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

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

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

[0035] The processor 118 may be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), 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 functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120 which can be coupled to the transmit / receive element 122. Although Figure 1B shows the processor 118 and transceiver 120 as separate components, it will be understood that the processor 118 and 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) via the air interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF signals and optical signals. It will be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of radio signals.

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

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

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

[0040] The processor 118 may be configured to receive power from the power supply 134 and distribute and / or control power to other components in the WTRU 102. The power supply 134 may be any suitable device for supplying power to the WTRU 102. For example, the power supply 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), 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) about the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may determine its location by receiving location information from base stations (e.g., base stations 114a, 114b) via the air interface 116 and / or based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 may acquire location information by any preferred location determination method, while maintaining consistency with one embodiment.

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

[0043] WTRU102 may include a full-duplex radio in which the transmission and reception of some or all of a signal (for example, associated with specific subframes of both UL (for example, for transmission) and DL (for example, for reception) may occur simultaneously and / or together. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating 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, WTRU102 may include a half-duplex radio for the transmission and reception of some or all of a signal (for example, associated with specific subframes of either UL (for example, for transmission) or DL ​​(for example, for reception)).

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

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

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

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

[0048] The MME162 can be connected to each of the eNode-B162a, 162b, and 162c in RAN104 via the S1 interface and can function as a control node. For example, the MME162 may be responsible for authenticating WTRU102a, 102b, 102c users for bearer activation / deactivation and selecting a specific serving gateway during the initial attachment of WTRU102a, 102b, and 102c. The MME162 may provide control plane functionality for switching between RAN104 and other RANs (not shown) using other radio technologies such as GSM and / or WCDMA.

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

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

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

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

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

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

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

[0056] A high-throughput (HT) STA can, for example, form a 40MHz wide channel for communication by using a 40MHz wide channel via a combination of a primary 20MHz channel and adjacent or non-adjacent 20MHz channels.

[0057] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. 160 MHz channels can 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. In the 80+80 configuration, after channel coding, the data can pass through a segment parser that can split the data into two streams. Inverse Fast Fourier Transform (IFFT) and time-domain processing can be performed separately on each stream. The streams may be mapped to two 80 MHz channels, and the data can be transmitted by a transmitting STA. At the receiver of a receiving STA, the above operation for the 80+80 configuration can be reversed, and the combined data can be transmitted to Medium Access Control (MAC).

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

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

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

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

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

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

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

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

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

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

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

[0069] UPF184a and 184b may be connected via the N3 interface to one or more of gNB180a, 180b, and 180c in RAN104, which may provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices. UPF184 and 184b can perform other functions such as packet routing and forwarding, enforcement of user plane policies, support for multi-homed PDU sessions, processing of user plane QoS, buffering of DL packets, and mobility anchoring.

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

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

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

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

[0074] In LTE vehicle-to-everything (V2X) communication, there can be one or more traffic models for periodic and event-triggered (for example, aperiodic) traffic. In the case of periodic traffic, one 300-byte message may be followed by four 190-byte messages. Furthermore, the arrival interval between two packets may be a multiple of 100 ms. In the case of event-triggered traffic, six messages may be generated over 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 to or identical to 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 contain sidelink control information (SCI) which may contain information about the PSSCH transmission. By decoding the PSCCH, the received WTRU can decode the following information: the frequency and time of the forward-booked PSSCH, the priority of the PSSCH, and / or the frequency and time of the PSSCH retransmission.

[0077] Generally, an LTE V2X vehicle WTRU performs procedures for sensing and resource selection. First, the WTRU may perform sensing to decode the SCI of other WTRUs. From the decoding of the SCI, the WTRU may have information on forward-booking PSSCHs and their corresponding priority. The WTRU may consider a forward-booking PSSCH to be occupied and exclude it from resource selection if its reference signal received power (RSRP) PSSCH is greater than a threshold. Next, the WTRU ranks the remaining resources in ascending order of received strength signal indicator (RSSI) and selects a set of selectable resources S for the final resource selection. A You can select 20% of the total resources, which are represented as follows. Finally, S for transmission A One of the resources can be randomly selected.

[0078] NR V2X can apply traffic models. Similar to LTE V2X, New Radio (NR) V2X can support two types of traffic: periodic and aperiodic. However, NR V2X can support many different types of packet size, packet arrival speed, and latency requirements. Specifically, aperiodic traffic in Model 2 may have the following characteristics: a packet size range of 10,000 to 30,000 bytes, an average arrival speed of 20 ms, and / or latency requirements of 10 ms.

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

[0080] In the case of NR V2X, it may be necessary to address both long-term and short-term sensing. As mentioned above, NR V2X can support both periodic and aperiodic traffic. 3GPP RAN1 may support semi-persistent (SPS) resource reservations, which can be enabled / disabled. When SPS resource reservations are enabled, long-term sensing, which is utilized before resource selection is triggered, can be used to avoid collisions of periodic traffic. Short-term sensing of aperiodic traffic that occurs after resource selection is triggered can be supported in the exemplary solutions described herein. NR V2X sensing and resource selection may consider the interaction of both long-term and short-term sensing.

[0081] Furthermore, in the case of NR V2X, it may be necessary to address Hybrid Automatic Repeat Request (HARQ) transmissions in the resource pool. 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 preconfigured, occurring periodically every N slots (N=1, 2, 4). Resource reservation for HARQ-based retransmissions may be supported in NR V2X. Therefore, NR V2X sensing and resource selection may be considered for cast types and HARQ operation in the exemplary solutions described herein.

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

[0083] Furthermore, in the case of NR V2X, preemption techniques can be used. NR V2X supports TB with a low latency requirement of about 3ms. Resource selection within a 3ms resource selection window can result in a high probability of collision. Preemption can be used to ensure QoS for such stringent TB. In NR V2X sensing and resource selection, preemption can be addressed in the exemplary solutions described herein.

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

[0085] In some exemplary scenarios, methods for HARQ-based transmission may exist. Specifically, in some exemplary scenarios, methods for supporting HARQ feedback transmission may exist. For example, a WTRU can prioritize transmission and reception of physical sidelink feedback channels (PSFCH) in the same slot based on the HARQ status, the QoS of the data, and the number of PSSCH / PSCCH transmitted and received per TB.

[0086] In an exemplary scenario, the WTRU may prioritize PSFCH transmissions and receptions in the same slot based on at least one of the following: HARQ status, the associated PSSCH / PSCCH index for HARQ feedback, QoS of data associated with PSFCH transmission and reception, the associated PSSCH / PSCCH cast type, the feedback type group cast transmission, whether the PSSCH / PSCCH Tx or Rx is in the same slot, and / or the channel busy ratio (CBR).

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

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

[0089] Regarding the associated PSSCH / PSCCH cast types, several examples may apply. For instance, if a WTRU needs to receive a PSFCH for a group cast and send a PSFCH for a unicast, the WTRU can prioritize receiving the PSFCH regardless of other parameters.

[0090] Regarding feedback-type groupcast transmissions, several examples may apply. For example, a WTRU may be prioritized based on whether the feedback is NACK-based, which may be considered the first option or option 1. Furthermore, a WTRU may be prioritized based on whether the feedback is ACK / NACK-based, which may be considered 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] Regarding whether a PSSCH / PSCCH Tx or Rx is in the same slot, for example, if a WTRU transmits a Pssch / Pscch in the same slot where the WTRU may need to perform at least one of PSFCH-Tx and PSFCH-Rx, the WTRU may perform a PSFCH-Tx. Furthermore, if the WTRU receives a PSSCH / PSCCH in the same slot, the WTRU may perform a PSFCH-Rx. Also, if there is no PSSCH / PSCCH Tx or Rx in the slot, the WTRU may determine whether to perform a PSFCH-Tx or PSFCH-Rx based on other conditions described herein.

[0092] With respect to CBR, for example, if the CBR is higher than a threshold, the WTRU may perform PSFCH-Rx and skip the transmission of PSFCH in the slot. Otherwise, the WTRU may determine PSFCH-Tx or PSFCH-Rx based on other conditions described herein.

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

[0094] In another exemplary approach, the WTRU can prioritize PSFCH transmissions or receptions based on the order of HARQ retransmissions. Specifically, the WTRU can prioritize PSFCH transmissions or receptions with a higher index of the associated PSSCH / PSCCH.

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

[0096] In an exemplary approach, the WTRU may determine the maximum power level per PSFCH when transmitting multiple PSFCHs simultaneously, based on the frequency distance between two PSFCHs. Specifically, the WTRU may consist of a set of maximum power backoffs for a single PSFCH transmission, based on the frequency distance between two PSFCH resources. Based on the configured maximum power backoff values, the WTRU may determine the maximum power level per PSFCH when determining whether multiple PSFCHs can be transmitted simultaneously. Furthermore, the WTRU may determine the 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 receive 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 decide that it can transmit multiple PSFCHs simultaneously. Conversely, if the maximum power level of each PSFCH resource is less than or equal to its minimum required power level, the WTRU may decide that it cannot transmit multiple PSFCHs simultaneously.

[0098] In another exemplary approach, the WTRU may decide 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 decide 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 exemplary approach, a WTRU may determine whether two or more PSFCHs can be transmitted in the same slot based on the number of symbols configured in the slot containing the PSFCH resource. If an Ns symbol is configured for a PSFCH resource, the WTRU may transmit an NsPSFCH in the same slot, and the location of the symbol may be determined based on one or more of the following: the source ID (and / or destination ID) of the WTRU receiving the PSFCH, the associated subchannel index of the received PSSCH / PSCCH (e.g., the first or last subchannel), and / or the associated slot index of the received PSSCH / PSCCH.

[0100] In an exemplary scenario, a WTRU may prioritize multiple PSFCH transmissions based on at least one of the following: HARQ status, data QoS, and / or the PSSCH / PSCCH index for each TB. A WTRU may have multiple PSFCH-Tx in a slot when it receives multiple PSSCH / PSCCH transmissions associated with that slot. In this case, the WTRU may need to prioritize the PSFCH-Tx and drop / skip lower-priority PSFCH-Tx.

[0101] In one exemplary approach, a WTRU can perform PSFCH transmit prioritization by dropping one or more PSFCHs or reducing the power of non-priority PSFCHs. A WTRU can perform prioritization among multiple PSFCH transmits by applying similar rules for PSFCH transmit / receive prioritization. Specifically, WTRU prioritization may be determined based on one or more of the following: HARQ status, the index of the associated PSSCH / PSCCH for HARQ feedback, the QoS of the data associated with the PSFCH transmit / receive, the cast type of the associated PSSCH / PSCCH, the group cast transmission of the feedback type, and / or the time and place of the associated receive PSSCH / PSCCH. In one example, the HARQ status may include whether the WTRU needs to send an ACK or NACK, and the number of bits of the WTRU may indicate the status of one or more TBs by sending HARQ feedback.

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

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

[0104] In some exemplary scenarios, methods for management and resource selection for HARQ-based transmissions may exist. In exemplary scenarios, a WTRU may decide whether to reserve resources for unicast / groupcast TB retransmissions. A WTRU may decide to make resource reservations for one or more retransmissions based on one or any combination of the data state in the MAC buffer, the QoS of the data, and / or the CBR of the resource pool.

[0105] In an exemplary approach, a WTRU might 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 can help improve the spectral efficiency of the system because the resources reserved for HARQ-based retransmission can be used for transmission of another TB, and it may allow the WTRU to use the reserved resources when an HARQ ACK is received.

[0106] In another exemplary approach, the WTRU may decide to reserve one or more resources for HARQ-based retransmission and / or blind retransmission of unicast / groupcast TBs based on the TB's QoS. 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 intermediate QoS requirements, the WTRU may decide to reserve resources for HARQ-based retransmission only. Furthermore, if the TB has low QoS requirements, the WTRU may decide not to reserve any resources for retransmission.

[0107] A WTRU may determine the number of resources reserved for a single TB transmission based on the resource pool's CBR. Specifically, a WTRU may consist of the maximum and minimum number of resources reserved per CBR range based on the data's QoS. The WTRU can then determine the exact number of resources reserved per TB based on its QoS and the resource pool's CBR. If the CBR is greater than the threshold, the WTRU may decide not to reserve resources for HARQ-based retransmissions.

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

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

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

[0111] Such information, for example, priority and RSRP / RSRQ / RSSI, can be used to determine resource availability during the resource allocation procedure. The WTRU may determine the priority and RSRP / RSSI / RSRQ of a reserved HARQ-based retransmission resource based on 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 status associated with the TB's previous transmission, and / or one or any combination of the TB's cast type and the HARQ feedback options used for the TB.

[0112] With respect to transmissions used to reserve HARQ-based retransmission resources, the WTRU may determine whether the transmissions used to reserve HARQ-based retransmission resources originate from the same TB or different TBs. Resource reselection may also be used as an example.

[0113] With respect to the HARQ feedback state associated with a previous TB transmission, the WTRU may determine the state associated with the previous TB transmission, such as the WTRU receiving HARQ ACK feedback, the WTRU receiving HARQ NACK feedback, or the WTRU not receiving HARQ information. If the WTRU does not receive HARQ information, this state may be determined by the WTRU not decoding the HARQ feedback, the WTRU being unable to decode the HARQ feedback, or the WTRU performing sensing and resource allocation before the HARQ feedback time.

[0114] Regarding cast types, the WTRU may determine whether a reserved HARQ-based retransmission resource is for unicast or groupcast. Furthermore, if the resource is for groupcast transmission, the WTRU may further determine which HARQ feedback options will be used for the transmission, and such information may be implicitly or explicitly communicated in the SCI.

[0115] In an exemplary scenario, a WTRU may determine the priority and RSRP / RSRQ / RSSI of a reserved HARQ-based retransmission resource based on the resource reservation feature used to reserve the resource. Initially, the WTRU can 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 a 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 the initial or retransmission of one TB to reserve a 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 pre-configured, configured, or explicitly indicated in the SCI. This exemplary approach could support retransmission adjustments based on HARQ feedback.

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

[0117] In a further exemplary scenario, the WTRU may divide the set of selectable resources into two sets and select resources for sending one TB in one of the two sets. For example, one set may contain resources in slots with PSFCH, and the other set may contain slots without PSFCH resources. The WTRU may select one set to select resources for sending one TB. The WTRU may decide which set to select resources in based on one or more of the following: resource pool configuration, TB size, TB QoS, number of selectable resources in each set, resource pool CBR, and / or TB cast type.

[0118] In one example, a resource pool configuration may include periodicity of slots having 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 the example regarding QoS for TB, if the resource pool's QoS 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 the example regarding CBR, if the resource pool's CBR is less than a threshold, the WTRU may select a set of resources without PSFCH resources.

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

[0120] In some exemplary cases, a receiving WTRU may decide not to send HARQ feedback when its location is unknown. In further examples, a receiving WTRU may decide whether to send HARQ feedback based on its past location information. In some exemplary cases, a receiving WTRU may decide to send HARQ NACK feedback based on location information obtained from the last location information. In an exemplary scenario, an Rx WTRU may decide to use the last location information to calculate the Tx-Rx distance associated with the received TB when the period between the Rx WTRU's last location information and the TB transmission does not exceed a threshold. The threshold may be pre-configured, configured, or determined by the Rx WTRU based on at least one of the WTRU speed, channel state, and / or QoS requirements. In one example, the QoS requirement may include reliability.

[0121] In some further exemplary cases, a receiving WTRU may decide not to send HARQ feedback if its location is unknown and the time elapsed since the last time location information was received is greater than a threshold. In further examples, a receiving WTRU may decide to send HARQ feedback if its location is unknown but the time elapsed since the last time location information was received is less than or equal to a threshold.

[0122] In some exemplary scenarios, a WTRU may perform one or more steps for resource reservation. In exemplary scenarios, a WTRU may determine whether a feature reservation for another TB is permitted. Generally, a WTRU can support a feature reservation for another TB, thereby allowing a WTRU to reserve resources in another TB using the transmission of one TB. This feature may include one or any combination of semi-persistent resource reservations and / or dynamic resource reservations. In one example, a semi-persistent resource reservation may include a procedure in which an SCI associated with one TB in a periodic traffic reserves resources in another TB in the same periodic traffic. In a further example, a dynamic resource reservation may include a procedure in which an SCI associated with one TB reserves resources in any other TB. In an exemplary approach, a WTRU may indicate in an SCI which type of resource reservation is used to support other WTRUs in the sensing and resource allocation procedure.

[0123] A WTRU may be configured to determine whether another TB feature reservation is permitted based on one or any combination of the following: resource pool configuration, resource pool CBR, TB QoS, and / or minimum communication range (MCR). Examples involving MCR include whether the WTRU is an internal MCR or an external MCR. In one example, the WTRU may be an incoming WTRU. Also, an internal MCR may be referred to as in-MCR in one example. In further examples, an external MCR may be referred to as out-MCR. If the WTRU is in-MCR, in one example, another TB reservation may be permitted. Otherwise, another TB reservation may not be permitted.

[0124] The WTRU can be composed of resource pools 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 reservations 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 can 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 can include in-coverage or out-of-coverage. In a further example, the MCR can include in-MCR or out-MCR.

[0126] In another approach, the WTRU can be configured to activate / deactivate each feature based on the CBR of the resource pool. For example, the WTRU can be configured to activate both SPS and dynamic resource reservations when CBR <= CRB1, activate SPS resource reservation when CBR1 < CBR <= CBR2, activate dynamic resource reservation when CBR2 < CBR <= CBR3, and not activate reservation when CBR > CBR3.

[0127] In another exemplary approach, the WTRU can be configured to use a type of resource reservation for another TB feature. For example, the WTRU can 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 can 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 exemplary scenario, a WTRU might determine the number of resources to report from the physical (PHY) layer to the MAC layer based on whether another TB feature reservation is enabled or disabled. For example, a WTRU might determine the number of first resources to report from the PHY layer to the MAC layer based on the enable feature reservation of another TB. In a further example, a WTRU might determine the number of second resources to report from the PHY layer to the MAC layer based on the disable feature reservation of another TB.

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

[0130] For example, 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 different TB feature reservations are enabled and disabled, respectively. This approach allows WTRU to strike a balance between collision probability and the quality of the selected resources.

[0131] In an exemplary scenario, the WTRU may determine the number of reserved resources for an attainable TB by using a different TB feature reservation based on one or more of the CBR, QoS, and / or cast type. The WTRU may consist of a range of the number of reserved resources for each TB based on the resource pool's CBR, TB's QoS, and / or cast type.

[0132] In an exemplary approach, a WTRU might decide to reserve resources for all transmissions of a given TB by using a feature reservation for another TB if the resource pool's CBR is above or below a threshold. However, a WTRU might reserve one resource for either the initial transmission or retransmission of a TB by using a SCI associated with another TB if the resource pool's CBR is above or below a threshold.

[0133] In another exemplary approach, a WTRU may decide to reserve one or more resources for all transmissions of a single TB by using a separate TB feature reservation for TBs with high QoS requirements. In this embodiment, high QoS requirements may include one or more TBs having high priority, high reliability, or low latency. Additionally or alternatively, a WTRU may decide to reserve one resource for either the initial transmission or retransmission of a TB with low QoS requirements by using a separate TB feature reservation. This approach may allow a WTRU to reduce TB collisions with high QoS requirements because all transmission resources for the TB are pre-reserved.

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

[0135] In an exemplary scenario, a WTRU may determine a sensing window based on which reservation features of another TB feature are supported in the resource pool. A WTRU may determine a sensing window in a single resource pool based on whether SPS and / or dynamic resource reservations are supported / enabled in the resource pool. Specifically, a WTRU may consist of multiple resource pools, each of which may be configured within a sensing window, depending on which resource reservation features are supported in the resource pool.

[0136] In some exemplary scenarios, a WTRU may perform one or more steps for resource selection and / or re-selection. In exemplary scenarios, one or more steps for resource exclusion may exist. During the resource allocation procedure, a WTRU may decide whether to exclude a resource in a slot and must monitor reserved targeted PSSCH / PSCCH transmissions. Reserved targeted PSSCH / PSCCH transmissions may belong to the service on which the WTRU operates. The decision may be based on one or more of the following: QoS of the TB, QoS of the reserved targeted PSSCH / PSCCH, 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 resource pool's CBR.

[0137] In one example involving TB QoS, the WTRU may decide not to exclude slots with reserved target PSSCH / PSCCH if the TB's QoS priority is higher / lower than a threshold, and may decide to exclude all reserved PSSCH / PSCCG if the TB's priority is lower / higher than a threshold. In a further example involving reserved target PSSCH / PSCCH QoS, the WTRU may exclude slots with reserved target PSSCH / PSCCH transmits that have an associated TB QoS 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 transmits from the highest priority to the lowest priority until the set of selectable resources exceeds a threshold.

[0138] In an exemplary scenario, a Tx WTRU may semi-permanently reserve a resource for either aperiodic or periodic traffic. The WTRU may determine one or more parameters for the reserved resource, such as the resource's lifetime, minimum and maximum lifetimes, and / or the probability of retaining the reserved resource. For example, after each lifetime, the WTRU may randomly select a value. If this value is less than the probability of retaining the reserved resource, the WTRU can continue to use the reserved resource. Otherwise, the WTRU may perform a resource reselection.

[0139] These parameters of a reserved resource may be determined based on one or more of the following: resource pool configuration, data QoS, and / or resource pool congestion level or WTRU channel occupancy. Regarding data QoS, for example, WTRU may be pre-configured or configured as a mapping between lifespan or the probability of retaining a resource and TB priority. This approach may be motivated to allow high-priority data to retain resources for longer periods to avoid collisions with other / lower-priority data.

[0140] In an exemplary scenario, a WTRU may divide resources reserved by other WTRUs into multiple groups and gradually remove or add each resource to the set of selectable resources. Similar to LTE V2X, during the resource allocation procedure, a WTRU may consider all resources within the 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 a set of selectable resources by selecting a certain percentage of the candidate resources in the set of non-excluded resources, for example, 20%. The WTRU may then randomly select one or more resources from the set of selectable resources for its transmission.

[0141] In a possible example applicable to NR V2X, a 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 the set of selectable resources. Additionally or alternatively, a WTRU may gradually add each resource in each group to the set of excluded resources. The addition or removal 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 reserved resources into different groups may be determined based on one or more of the following: the QoS of the reserved resources, the timing of potential collisions, and / or the type of reserved resources. Regarding the QoS of reserved resources, WTRUs can divide reserved resources into high-QoS and low-QoS resources. Regarding the type of reserved resources, for example, WTRUs can divide a set of reserved resources into one of the following groups: dynamically reserved resources, semi-persistent reserved resources, and / or feedback-based HARQ retransmission resources. For example, a group of dynamically reserved resources might be used for one transmission of one TB. A group of semi-persistent reserved resources might be used semi-statically for multiple transmissions. Furthermore, a group of feedback-based HARQ retransmission resources might be used for feedback-based HARQ retransmissions.

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

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

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

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

[0147] Specifically, regarding the congestion level of a resource pool, the WTRU can be composed of different thresholds based on the resource pool's CBR range. For example, the WTRU may be composed of a threshold for a first CBR range, and the threshold for a second CBR range may be determined by an offset to the threshold for the first CBR range.

[0148] Regarding the types of reserved resources, for example, WTRU may consist of one threshold for each of the following reserved resources: reserved resources for blind retransmissions, reserved resources for feedback-based blind retransmissions, and / or reserved resources for initial transmissions.

[0149] Further illustrative situations provide methods for considering slots. In the embodiment, methods for considering unsupervised slots may be considered.

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

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

[0152] In an exemplary approach, a WTRU may determine the availability of any potentially reserved slot during resource allocation when the WTRU is not monitoring a slot. For example, a WTRU may not monitor a slot when it needs to transmit in that slot. The availability of a potentially reserved slot may be determined based on one or more of the following: the resource pool's CBR, the TB's QoS, and / or the TB's traffic type.

[0153] Regarding the CBR of a resource pool, for example, a WTRU might determine one potentially reserved slot as unavailable when the CBR of one of the resource pools is greater than a threshold. Conversely, a WTRU might determine a potentially reserved slot as available when the resource pool's CBR is less than a threshold. When a WTRU considers a slot to be potentially reserved as available, it may include resources in those slots in the set of selectable resources. Conversely, when a WTRU considers these slots as unavailable, it may exclude resources in those slots from the set of selectable resources.

[0154] In one example, with respect to TB QoS, WTRU may determine one potentially reserved slot as either available or unavailable if it exceeds the TB priority / latency threshold. In a further example, only the priority threshold may be used. In another example, only the threshold example may be used.

[0155] With respect to TB traffic types, this basis for determination may be appropriate when a WTRU determines one potentially reserved slot as available / unavailable based on dynamic or semi-persistent resource selection. Specifically, when a WTRU performs dynamic resource selection, it may determine a potentially reserved slot as available, and when a WTRU performs resource selection for semi-persistent use, it may determine a potentially reserved slot as unavailable.

[0156] In exemplary circumstances, a WTRU may perform one or more steps for resource ranking as provided herein. In an exemplary approach, a WTRU may divide a set of resources in a resource selection window into several groups, each of which may be associated with a single resource group rank. The WTRU may then perform ranking of resources within each group. Specifically, a WTRU may divide a set of resources in a 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] For example, WTRU is f(QoS) * Resource ranking within a group of resources reserved by other WTRUs can be performed based on an increase or decrease in g(RSRP / RSRQ / RSSI). An exemplary approach would be to rank resources within a group of resources reserved by other WTRUs based on an increase or decrease in f(QoS, RSRP, or RSRQ). For example, a WTRU may...

number

number

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

[0159] In exemplary circumstances, a WTRU may perform one or more steps to determine a resource selection window. In an exemplary approach, a WTRU may determine the resource selection window for the next resource of a TB based on the time resources of a previously selected resource and the maximum reservation signaling between the two resources. Specifically, similar to LTE V2X, for the first selected resource of a TB, a WTRU may determine the resource selection window as [n+T1, n+T2], where the value of T1 may be determined based on WTRU capabilities and the value of T2 may be determined based on the latency and reliability of the TB. The earliest or most recent time of the WTRU among the previously selected resources may be assumed to be 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. A WTRU may determine the resource selection window for the following resources as [min(n+Tmin-N, n+T1), max(n+Tmax+N, n+T2)].

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

[0161] In an exemplary scenario, the WTRU may determine which type of resource selection to perform for unicast / groupcast TB. 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 HARQ-based retransmissions only, resources for the next TB transmission may occur before the HARQ feedback time for the previous transmission. For a combination of blind and HARQ-based retransmissions, the next TB transmission may occur before or after the HARQ feedback time for the previous transmission.

[0163] The WTRU may decide to perform one type of resource selection based on one or more of the following: 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 of 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 exemplary scenarios, the WTRU may determine a selection window for the next resource based on the results of a previously selected resource for only the resource allocation type of HARQ-based retransmission. The WTRU may determine a resource selection window for a resource as [n+T1, n+T2], where the value of T2 may be determined based on the TB latency and the number of transmissions required for the TB. The WTRU may assume that it selects a first resource in slot n+k, associated with a PSFCH in subframe n+k+a. The WTRU may determine a 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 exemplary scenario, the WTRU may determine the selection windows for initial transmit resources and HARQ-based retransmit resources. In an exemplary approach, the WTRU may determine the resource selection windows for initial transmit and HARQ-based retransmit 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 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 of 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 within [n+T1, n+T3]. Additionally or alternatively, the value of T3 may be determined such that the number of selectable resources within a window [n+T1, n+T3] is greater than X% of the total number of selectable resources within the window [n+T1, +T2]. The value of X may be fixed or determined based on one or more of the TB's QoS and / or the resource pool's CBR.

[0167] In another exemplary approach, the WTRU may determine that the first and second resource selection windows are [n+T1, n+T3] and [n+k+a+Δ, n+T2], respectively, where n+k and n+k+a are the slots for the initial transmission and its associated PSFCH. 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 exemplary scenario, the WTRU may decide to switch from a 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, if, during the selection procedure for the HARQ-based retransmission-only resource allocation type, 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 ensure QoS for TB.

[0169] In an exemplary scenario, a WTRU may determine, based on the timing of the PSFCH resources, which PSFCH resource will feed back the state of multiple PSSCH / PSCCH transmissions for one or more TB transmissions. For example, a 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 resources will feed back the HARQ state for these PSSCH / PSCCH transmissions. Based on the timing of the PSFCH resources, the WTRU may determine which PSFCH resource will feed back the state of multiple PSSCH / PSCCH transmissions. Specifically, in one approach, the WTRU may select a PSFCH resource associated with a first PSSCH / PSCCH transmission if it has enough time to decode both PSSCH / PSCCH transmissions and prepare the HARQ feedback. Otherwise, the WTRU may select a PSFCH associated with a second PSSCH / PSCCH transmission. Alternatively, the WTRU may use a PSFCH associated with a second PSSCH / PSCCH.

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

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

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

[0173] In an exemplary scenario, the WTRU may perform a resource contention procedure for the initial transmission in the first resource selection window and use the SCI of the initial transmission to reserve resources for one or more retransmissions in the 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 zero or less. The backoff value may decrease when it is determined that one or more resources in the slot are available for their transmission.

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

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

[0177] In the examples provided herein, a WTRU may perform resource reselection. In an exemplary scenario, a 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, a WTRU may consist of a resource utilization threshold for one set of reserved resources corresponding to one sidelink process. The utilization threshold may be configured based on resource pool data and / or CBR QoS. A WTRU may determine the resource utilization of a set of reserved resources as the ratio of used resources to unused resources during a given period.

[0178] In an exemplary approach, a WTRU may perform resource reselection of a set of reserved resources for unicast / groupcast if the successful transmission ratio is below a threshold. A Tx WTRU may consider a transmission successful if it receives HARQ ACK feedback. A WTRU may consider a transmission failed if it receives HARQ NACK or no feedback from an Rx WTRU.

[0179] In another exemplary approach, if a WTRU is operating in network-scheduled mode, the WTRU may support the network during scheduling by reporting resource utilization to the network. Additionally or alternatively, the WTRU may report the transmit success rate to the network based on HARQ feedback from receiver WTRUs. Reporting in both approaches may be configured periodically or based on trigger conditions. Trigger conditions may include, for example, when the utilization rate or transmit success rate of a set of reserved resources falls below a threshold.

[0180] In some exemplary scenarios, a WTRU may perform resource evaluation, re-evaluation, or both. According to the initial design of NR V2X, a WTRU may perform resource evaluation or re-evaluation for resources selected and / or reserved by the WTRU to determine whether the resources need to be re-selected due to potential conflicts with other WTRUs.

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

[0182] In one example, WTRU may determine whether to trigger a resource reassessment based on the time between the slot in which a resource is selected and the slot of the first selected resource. Specifically, in one example, WTRU may trigger a resource reassessment if the time between the slot in which a resource is selected and the slot of the first selected resource is less than a threshold. Otherwise, WTRU may not trigger a resource reassessment. The threshold may be determined based on one or any combination of a fixed, configured, or pre-configured threshold, TB QoS, and / or resource pool CBR. For example, WTRU may be configured or pre-configured with a time interval threshold based on the resource pool CBR. Specifically, WTRU may be configured or pre-configured with a long time interval threshold if the CBR is low, and with a short time interval threshold if the CBR is high. In one example related to fixed, configured, or pre-configured thresholds, the time interval threshold may be a fixed value configured or pre-configured for each resource pool. In one example related to TB QoS, the time interval threshold may be configured or pre-configured based on TB priority. For example, WTRU may be configured or pre-configured with a short time interval threshold for high-priority TBs and a long time interval threshold for low-priority TBs.

[0183] In another example, the WTRU may determine whether a resource reassessment is necessary based on the remaining delay budget of the TB. Specifically, in one example, the WTRU may trigger a resource reassessment if the remaining delay budget of the TB is greater than a threshold. Otherwise, the WTRU may not trigger a resource reassessment. The delay budget threshold may be determined based on one or any combination of fixed, configured, or pre-configured thresholds, the resource pool's CBR, and / or the TB's resource reselection type. 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. Regarding the resource pool's CBR, in one example, the WTRU may be configured or pre-configured with a delay budget threshold based on the resource pool's CBR. For example, if the CBR is low, it may be configured or pre-configured with a high delay budget threshold, and if the CBR is high, it may be configured or pre-configured with a low delay budget threshold. Furthermore, this approach may allow the WTRU to select sufficient available resources after the resource reassessment. In one example relating to fixed, configured, or pre-configured thresholds, the delay budget threshold may be a fixed value configured or pre-configured for each resource pool.

[0184] In an exemplary approach, the WTRU may trigger a resource reevaluation in a slot between the slot in which it first selects a resource and the slot in which it uses the first selected resource. The WTRU may determine the resource reevaluation trigger timing based on one or any combination of the TB's QoS and / or the resource pool's CBR. In the example with respect to the TB's QoS, the WTRU may be configured or preconfigured based on the TB's QoS with the maximum and / or minimum time interval between the first selected resource and the reevaluation trigger, and then the WTRU may determine the resource reevaluation timing to satisfy the configured or preconfigured time interval. Furthermore, in the example with respect to the resource pool's CBR, the time interval between the resource reevaluation trigger and the first selected resource may be large when the resource pool's CBR is low and small when the resource pool's CBR is high.

[0185] WTRU can, in one example, determine the value of the interval. In an exemplary example, WTRU may be configured or preconfigured with an interval, which may be referred to as T3. In an exemplary example, WTRU may be configured or preconfigured with an interval T3 between the maximum resource reassessment 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. Specifically, T3 may be larger for lower-priority TBs and smaller for higher-priority TBs.

[0186] In an exemplary approach, the WTRU may replace one or more resources from a previous iteration with one or more resources from the current iteration. After resource reevaluation, 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 set of resources for TB transmission. The MAC layer of the WTRU may randomly re-select a set of resources for 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 re-select only at least one of the conflicting resources, and / or re-select the entire set of previously selected resources. Re-selection may, in one example, be based on association. For example, re-selection may be based on association with the originally selected resources. Furthermore, re-selection may be based on association with a first resource.

[0187] The WTRU may decide whether to reselect only the conflicted resources or at least one of the entire set of previously selected resources based on one or any combination of the following TB transmission type and / or TB QoS. For example, with respect to the TB transmission type, the WTRU may decide to reselect the entire set of previously selected resources if the WTRU uses HARQ-based retransmission for the 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 the TB, and to reselect at least one of the conflicted resources only if blind retransmission is used for the TB. This allows the WTRU to decide to reselect additional resources based on the HARQ state of the first resource. Furthermore, with respect to the TB QoS, the WTRU may decide to perform resource selection for at least one of the conflicted resources only if the TB priority is higher than a threshold. Otherwise, the WTRU may perform resource selection for the entire set of previously selected resources.

[0188] In an exemplary approach, the WTRU may decide to reselect at least one of the conflicted resources. The WTRU may then randomly reselect one or more resources for transmission based on the number of conflicted resources. The WTRU may then determine a window for reselecting one or more resources based on the timing of the remaining resources and the HARQ round trip time (RTT). For example, if the WTRU performs resource reselection of a first resource in a set of resources for 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 exemplary example, if 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 CSIs are available for one set of subchannels, the WTRU may, in one example, perform resource selection for the set of subchannels that have the relevant CSI reports. Otherwise, if CSI reports or broadband CSI reports are not available, the WTRU may perform resource selection across the entire resource pool. In another exemplary approach, the WTRU may apply different sets of RSRP thresholds between resources with and without CSI reports.

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

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

[0192] For example, with respect to TB QoS, WTRUs can be configured or preconfigured. For instance, WTRUs can be configured or preconfigured with the maximum number of RSRP increments based on the TB priority. Furthermore, WTRUs can be configured or preconfigured with a higher maximum number of RSRP increments for high-priority WTRUs and a lower maximum number of RSRP increments for low-priority TBs.

[0193] Regarding the resource pool's CBR, for example, if the resource pool's CBR is high, the WTRU may be (pre-configured) with a high value for the maximum number of RSRP increments. Furthermore, if the resource's CBR is low, the WTRU may be configured or pre-configured with a low value for the maximum number of RSRP increments.

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

[0195] In another exemplary approach, the WTRU could perform a Clear Channel Assessment (CCA) and occupy one or more subbands to transmit one or more TBs. This approach could allow the WTRU to reduce CCA overhead, as it might only need to perform a CCA once for the transmission of one or more TBs.

[0196] A WTRU can determine the maximum channel occupancy time (MCOT) for each time a channel is accessed, or it can determine the MCOT over a period of time. The MCOT can 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 resource, and / or the CBR of the resource pool. For example, a WTRU may be configured for a higher MCOT if the CBR is low, or for a lower MCOT if the CBR is high. In the example with respect to the QoS of each TB, the WTRU may determine the MCOT based on the number of transmissions per TB, which can be determined based on the reliability of the TB. With respect to the bandwidth of the occupied resource, the WTRU may be configured for a smaller MCOT, for example, if higher bandwidth is used to balance time and frequency resource usage.

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

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

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

[0200] In an exemplary scenario, a WTRU may perform resource selection to support congestion control. In an exemplary approach, a WTRU may determine a set of resources that are unavailable for selection. Specifically, in one example, a WTRU may determine RSRP / RSRQ / RSSI thresholds to determine whether a resource is available for selection. The thresholds may be determined based on one or more of the following: the QoS of reserved resources, the QoS of pending TBs, and / or the CBR of the resource pool.

[0201] In an exemplary approach, WTRU can determine a set of resources that are unavailable if the set satisfies the following conditions: 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 preconfigured based on the relative priority of two TBs.

[0202] In another exemplary approach, if WTRU is reserved by one SCI, a set of unselectable sources may be determined, where the priority indicated in the SCI is one or more of the following: lower than a threshold and / or lower than the priority of the pending TB minus Δ. Furthermore, in one example, the value of Δ may be configured or preconfigured.

[0203] In exemplary scenarios, a WTRU may decide to perform congestion control by adjusting transmit parameters, dropping TB, and / or preempting one or more resources if the number of selectable resources is less than a threshold or the number of unselectable resources is greater than a threshold. In one example, adjusting transmits may include, for example, changing transmit power, such as reducing transmit power, changing the number of subchannels selected per transmit, 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 resource pool's TB and / or CBR.

[0204] In exemplary scenarios, a WTRU may perform one or more methods for preemption. In one approach, the WTRU may determine which resource pools are available and which types of reserved resources are permitted for preemption. Based on pool configurations that can be configured or preconfigured in the WTRU, or that can be sent to the WTRU via the SIB or RRC, the WTRU may determine, for preemption in resource pools, whether preemption is permitted, the priority range or another QoS parameter range of TBs on which the WTRU can perform preemption, the priority range or another QoS parameter range of reserved resources that can be preempted, the minimum priority difference or any QoS parameter difference between pending TBs and reserved resources permitted for preemption, the CBR threshold permitted for preemption, and / or any combination of source IDs and / or destination IDs that may be associated with reserved resources that can be preempted.

[0205] In an exemplary approach, a WTRU might consist of different priority sets that are permitted to preempt reserved resources based on the resource pool's CBR. Specifically, for a single TB, the WTRU might, in one example, determine whether preemption can be performed based on the TB's priority and the resource pool's CBR.

[0206] In another exemplary approach, the WTRU could determine whether preemption is permitted based on the resource pool's CBR. Specifically, if the CBR is greater than / less than a threshold, preemption might not be permitted, for example. Otherwise, if the CBR is less than / greater than a threshold, preemption might be permitted.

[0207] In an exemplary scenario, a WTRU may decide, based on the characteristics of its TB and the characteristics of the reserved resources, whether a set of resources is permitted to be preempted. Specifically, in one example, the characteristics of a pending TB may include one or more of the TB's QoS, the TB's cast type, and / or the TB's size.

[0208] Furthermore, the characteristics of a reserved resource may include any combination of the QoS of the reserved resource, the cast type of the reserved resource, the size of the reserved resource, whether the reserved resource is an HARQ-based initial transmit, whether the reserved resource is an HARQ-based retransmit, whether the reserved resource is a blind retransmit, and / or whether the reserved resource is an initial blind transmit.

[0209] In an exemplary approach, a WTRU may determine whether a resource is preempted based on the QoS of its TB and the QoS of the reserved resource. A WTRU may be configured to preempt resources that have a priority or other QoS information within a range, or that have a priority difference or other QoS parameter difference that is greater than the configured or pre-configured threshold of the WTRU's pending TB. Additionally or alternatively, a WTRU may be configured to preempt one or more resources that have the lowest priority or the largest priority difference with its pending TB.

[0210] In another exemplary approach, the WTRU may decide to preempt one or more cast types and associated resources 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 exemplary scenario, a WTRU may determine the type of preemption based on the characteristics of the TB. One such preemption could be semi-persistent preemption, in which the WTRU preempts reserved resources and can semi-persistently use the preempted resources. Additionally or alternatively, preemption could be dynamic preemption, in which the WTRU preempts reserved resources and can use the preempted resources for one-shot transmissions.

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

[0213] The duration of a preempted resource may be determined based on one or any combination of the following: the QoS of the pending TB, the size of the pending TB, the information transmitted to the TB, and / or the frequency size of the reserved resource.

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

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

[0216] In one example, a WTRU can implicitly or explicitly indicate a set of preempted WTRUs by indicating the preempted resources. In an exemplary approach, a WTRU can implicitly represent a set of preempted WTRUs by indicating the preempted resources in the preemption message. After successfully decoding the preemption message, a receiver WTRU can determine if a reserved resource is preempted by identifying whether any of the reserved resources overlap with the preempted resources. In another exemplary approach, a WTRU can explicitly indicate a set of preempted WTRUs and preempted resources in the preemption message.

[0217] In an exemplary scenario, a WTRU can determine, send, and monitor resources for preemption messages. In an exemplary approach, a WTRU may be configured to send preemption messages to a subchannel / slot / symbol dedicated to the PSCCH. In one example, a WTRU may determine preemption messages using a preemption-specific SCI format.

[0218] In another exemplary approach, a WTRU may configure one or more resource pools to send preemption messages. Additionally or alternatively, a WTRU may configure a dedicated subchannel / slot to send preemption messages. A receiver WTRU may monitor a dedicated resource for preemption instructions to determine whether the reserved resource is preempted, or to support sensing and resource allocation procedures.

[0219] In another exemplary approach, the WTRU may consist of rules regarding the time interval between sending a preemption instruction and sending data. The time interval between the preemption instruction and sending data may be configured or preconfigured based on the resource pool. The configured or preconfigured value may be determined based on the time required for the WTRU to decode the preemption instruction 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 exemplary approach, a WTRU may consist of a time interval between a preemption instruction and data transmission, based on the QoS of the preempted resource. Thus, a preempted WTRU can monitor preemption instructions in the configured slot for preemption, based on the QoS of its reserved resource.

[0221] In exemplary scenarios, a WTRU may decide to monitor preemption directives based on the configuration of its reserved resources and resource pools. In an exemplary approach, a WTRU may decide to monitor preemption directives if reserved resources are permitted to be preempted. Specifically, a WTRU may decide to monitor preemption if one or more of the following apply: the reserved resource belongs to a resource reservation type that is permitted to be preempted; the reserved resource belongs to a configuration or pre-configured set of resources that is permitted to be preempted; the reserved resource for a priority TB is permitted to be preempted; and / or the reserved resource belongs to a cast type that is permitted to be preempted. In one example, a resource pool may allow preemption unicasts or groupcasts. In an example where the reserved resource belongs to a resource reservation type that is permitted to be preempted, a resource pool may allow preemption of semi-persistent reserved resources. In an example, reserved resources belong to a configured or pre-configured set of resources that are permitted to be preempted. In one example, the resource set may consist of subchannels and slots that can be preempted. With respect to reserved resources of TB with priority permitted for preemption, 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 one TB 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.

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

[0224] In an exemplary scenario, 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 resource pool's CBR, the TB's QoS, and / or the backoff duration.

[0225] In an exemplary approach, the WTRU might decide to perform preemption if the TB's QoS exceeds a threshold. For example, the TB's priority is less than the threshold. Specifically, for example, the WTRU might perform preemption if the TB's latency requirement is less than the threshold or if the TB's priority is greater than the threshold.

[0226] In another exemplary approach, the WTRU may perform resource selection for pending TBs. 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, for example, based on the QoS of the TB.

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

[0228] In exemplary scenarios, certain Rx WTRU behaviors may exist when an Rx WTRU detects a preemption instruction. In an exemplary approach, once an Rx WTRU successfully decodes a preemption instruction that preempts a resource that overlaps with its reserved resource, the Rx WTRU may determine whether it is necessary to perform collision avoidance, which can be performed by the WTRU to minimize resource collisions between multiple transmissions, based on one or any combination of the RSRP / RSSI of the preemption instruction, the QoS of preempting the TB, the QoS of the preempted TB, and / or the QoS associated with one or more preempted resources.

[0229] In an exemplary approach, the WTRU may perform collision avoidance if it successfully decodes the preemption instruction. In another exemplary approach, the WTRU may perform collision avoidance if it successfully decodes the preemption instruction and the RSRP / RSSI measured from the emptiness instruction 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] A receiving WTRU may perform collision avoidance by performing one or any combination of the following: performing resource reselection, re-encoding TBs, and / or dropping pending TBs. In an exemplary approach, a WTRU may perform collision avoidance by performing resource reselection. For example, a WTRU may perform collision avoidance by performing resource reselection for a sidelink process. A WTRU may also perform collision avoidance by performing resource reselection for other types of processes. In one example, a preempting WTRU may perform resource reselection if it preempts a resource and uses it semi-permanently. A WTRU may perform dynamic resource selection for TBs expected to be transmitted on the preempted resource. Additionally or alternatively, in one example, a WTRU may perform resource reselection if the QoS of a reserved resource is greater than a threshold.

[0231] In another exemplary approach, the incoming WTRU may decide to reencode the TB and / or puncture / rate to match the preempted resources if the percentage or amount of preempted resources is less than a threshold. The threshold may be determined to ensure that the transmission of TB on the remaining resources still meets the TB QoS requirements.

[0232] In exemplary scenarios, there may be other WTRUs that determine the availability of a preempted semi-persistent resource. A WTRU may determine the availability of a preempted reserved semi-persistent resource based on the type of preemption. Specifically, a WTRU may determine that a reserved semi-persistent resource is still reserved if the preemption is used for dynamic transmission. Additionally or alternatively, a WTRU may determine that a reserved semi-persistent resource has been released and, if the preemption is used for semi-persistent resource allocation, may be replaced by another semi-persistent resource.

[0233] Figure 3A is a diagram illustrating an example of resource selection and sensing. In the example shown in Figure 3A, the WTRU may use resources over time, shown on the x-axis, and frequency, 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, over time, the WTRU may select resources such as resources 310A, 320A, and 330A that are located after time m and are within the packet delay budget (PDB). In one example, selected resources may be considered pre-selected resources. The WTRU may perform further sensing. For example, the WTRU may perform sensing to decode the SCI of one or more other WTRUs. Furthermore, as a result of sensing, in one example, the WTRU may determine the priority and RSRP / RSRQ / RSSI of reserved resources such as resources 310A, 320A, and 330A. Sensing may be performed according to exemplary procedures described elsewhere in this specification. Furthermore, WTRU may perform resource reassessment based on the time interval between the selected resources and the remaining PDBs. The time interval may be determined according to the examples provided elsewhere in this specification.

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

[0235] Figure 3B shows an example of resource reassessment including a resource reassessment trigger. In the example shown in Figure 3B, the WTRU may decide to perform a resource reassessment. Furthermore, the procedure in Figure 3B may occur after Figure 3A. In one example, the WTRU may decide that a trigger can be met to perform a resource reassessment. Furthermore, the WTRU may make a decision based on exemplary procedures described elsewhere in this specification, such as sensing, QoS, latency requirements, or one or any combination of PDBs. Furthermore, the WTRU makes a decision at time k, as shown in Figure 3B.

[0236] In one example, a WTRU may decide to re-evaluate a resource and decide not to make any changes to it. In another example, a WTRU may decide to re-evaluate a resource and decide to make changes to it. For example, a WTRU may decide that one or more pre-selected resources need to be removed from a resource that uses them. Thus, one or more resources need to be re-selected from the selectable resources and replaced with one or more removed pre-selected resources. For example, a WTRU may decide that one or more pre-selected resources need to be removed due to a conflict. For example, a WTRU may decide that one or more pre-selected resources are being used by another WTRU and potentially cause a conflict, as described in the embodiments provided elsewhere in this specification. By performing a resource re-evaluation, a WTRU may perform conflict avoidance accordingly. Furthermore, a WTRU may complete the re-evaluation at time k+T1.

[0237] In the example shown in Figure 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, and 390. These resources may be located between time m and time k+T2. Furthermore, these resources may be used for one or more TBs. In one example, a TB may contain one or more HARQ-enabled TBs, and in another example, a TB may contain one or more HARQ-deactivating TBs. Further explanation follows.

[0238] Figure 4 shows an example of resource reevaluation including HARQ activation TB. In the example shown in Figure 400, the WTRU performs resource reevaluation and reselection of resources to activate the HARQ process for TB or one or more TBs. In the example shown in Figure 4, the WTRU needs to determine which resources to reselect because they are sufficiently spaced out in time for the HARQ process to function properly. For example, the WTRU may reselect resource 450 to replace resource 310B, which must be replaced due to a collision, as described above. However, the WTRU may then not 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 because it is far enough away from resource 450 in time to allow the HARQ process to function properly. Furthermore, the WTRU may then not reselect resource 430 because it is too close in time to resource 470 to allow the HARQ process to function properly. Therefore, WTRU can re-select resource 490 because enough time has passed since resource 470 that the HARQ process can function properly.

[0239] In this way, the WTRU can re-select the first resource 310B and replace the first resource with the second resource 450. Furthermore, the WTRU may re-select the third resource 470 based on its association with the second re-selected resource 450. Resource 490 may also be re-selected. As a result, resources 470 and 490 may also be re-selected because the second resource is associated with the HARQ activation process. Thus, resources are re-selected based on their associations.

[0240] For example, resources 440, 460, and 480 are generally selectable resources and are also potentially available for re-selection. For instance, WTRU could re-select resource 440 instead of resource 450.

[0241] Figure 5 shows an example of resource reevaluation including a HARQ disablement TB. In the example shown in Figure 500, the WTRU performs resource reevaluation and reselection of resources for a TB that disables the HARQ process or for one or more TBs. Thus, the WTRU can decide 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, which 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 way, the WTRU can re-select the first resource 310B and replace the first resource with the second resource 550. Furthermore, based on its association with the second re-selected resource 550, the WTRU can re-select the third resource 520 and, in this re-selection, retain resource 520 as a resource to be used. The WTRU can also re-select resource 530 and, in this re-selection, retain resource 530 as a resource to be used. Thus, resources are re-selected based on their associations.

[0243] For example, resources 540, 560, 570, 580, and 590 are generally selectable resources and are also potentially available for re-selection. For instance, WTRU could re-select resource 440 instead of resource 550.

[0244] For example, a WTRU might perform resource selection and determine the set of resources to be used for transmission. For instance, resources might be used to transmit one or more TBs. Furthermore, the set of resources used for transmission might be referred to as the previously selected set of resources.

[0245] Furthermore, WTRU can dynamically decide whether to trigger a resource reevaluation. WTRU can make this decision based on the feasibility of meeting latency requirements. For example, it might be found that one or more resources can meet the latency requirements. In another example, it might be found that one or more resources cannot meet the latency requirements. Therefore, these one or more resources may need to be replaced by one or more other resources. Resource reevaluation may involve determining one or more potential conflicts between one or more resources in a previously selected set of resources.

[0246] Furthermore, latency requirements may include the remaining PDBs of the TB. Latency requirements may also include the time interval between the previously selected resource and the remaining PDBs of the second TB.

[0247] In one example, the WTRU may determine the set of selectable resources by performing a resource reassessment based on a previously selected set of resources and removing one or more resources from the previously selected set. Furthermore, the WTRU may re-select at least one first resource from the previously selected set of resources. In one example, at least one first resource may not be in the set of selectable resources. Furthermore, the WTRU may re-select 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 re-select at least one third resource from the set of selectable resources based on its association with at least one second resource. The WTRU may then send the first TB using at least one second resource.

[0248] In a further example, a WTRU may determine the set of selectable resources by performing a resource reassessment 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, 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, 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 its association with at least one second resource. The WTRU may then use at least one second resource to send the first TB.

[0249] In an additional example, the WTRU may re-select at least one fourth resource based on its association with at least one second resource. In yet another example, the WTRU may re-select at least one fifth resource based on its association with at least one second resource. In an additional embodiment, an additional resource may be re-selected based on its association with at least one second resource.

[0250] In one example, one or more resources can be deleted based on a collision. For instance, the collision might be a predictable and likely collision with the transmission of another WTRU. In one example, the other WTRU might be a V2X WTRU.

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

[0252] In a further example, the HARQ state could be, in one instance, an invalid HARQ state of a TB. Thus, a TB could be an invalid HARQ TB. Furthermore, 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, association with at least one second resource may be based on a permission. In one example, the permission may be a periodic reservation permission. Thus, association with at least one second resource may be based on a periodic reservation permission associated with the first TB. Furthermore, additional resources may include resources associated with periodic reservation permissions. For example, at least one third resource may be associated with a periodic reservation permission.

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

[0255] For example, a preempted resource may be one of more deleted resources. For instance, a preempted resource may be at least one first resource. Furthermore, a periodically scheduled transmission may be associated with a periodically scheduled permission.

[0256] The exemplary scenarios provided herein include methods for supporting initial transmission reservations. In the exemplary scenarios, the WTRU may determine the resource reservation type. For example, the WTRU may transmit the same TB with a first PSCCH+PSSCH using a first frequency resource allocation supporting the reservation of the same TB feature for a second PSCCH+PSSC using a second frequency resource allocation. The size of the first frequency resource allocation may be less than, equal to, or greater than the size of the second frequency allocation. The WTRU may determine the difference between the size of the first frequency resource allocation and the size of the second frequency resource allocation based on one or more of the 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 exemplary approach, the WTRU may determine the size difference between the first and second frequency resource allocations based on the size of the first PSCCH+PSSCH's 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's frequency resource allocation is less 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's frequency resource allocation is two subchannels or less, the WTRU may determine that the sizes of the first and second PSCCH+PSSCH's frequency resource allocations are equal. However, if the size of the frequency resource allocation for the second PSCCH+PSSCH is larger than two subchannels, the WTRU may determine that the size of the frequency resource allocation for the second PSCCH+PSSCH is larger than the size of the frequency resource allocation for the first PSCCH+PSSCH. In one example, the size of the frequency resource allocation for the first PSCCH+PSSCH may be one subchannel.

[0258] In another exemplary approach, the WTRU may determine the size difference between a first and second frequency resource allocation based on the size of the TB. Specifically, if the size of the TB is less than a threshold, in one example, the WTRU may determine that the sizes of the first and second frequency resource allocations are equal. Additionally or alternatively, if the size of the TB is greater 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 exemplary approach, the WTRU may determine the size difference between a first frequency resource allocation and a second frequency resource allocation based on the TB QoS. For example, the WTRU may determine that the frequency sizes of the first and second PSCCH+PSSCH are equal if, in one example, the TB latency is less than a threshold.

[0260] In exemplary scenarios, a WTRU may choose between a reservation for the same TB and a reservation for a different TB feature. A WTRU may decide to use a reservation for the same TB and / or a reservation for a different TB feature based on one or more of the following: 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. Regarding the size of one TB and / or the required frequency size, if a WTRU has two TBs in its 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 can use a reservation for a different TB feature. In one example, the frequency could be one subchannel. Regarding the QoS of one TB, in one example, a WTRU may decide to use a reservation for a different TB feature if the WTRU needs to transmit a low-QoS TB. Regarding the availability of other information that the WTRU may need to transmit, in one example, a WTRU can use a reservation for a different TB feature if it has CSI information for reporting / transmitting.

[0261] The embodiments provided herein include methods for supporting network scheduling. For example, in NR V2X, modified methods for supporting network scheduling may exist. For example, methods for supporting MCS table indication may exist. In certain circumstances, a WTRU may indicate its MCS table to be used for PSSCH transmission to a receiver WTRU. A WTRU may implicitly or explicitly indicate the MCS table used to the receiving WTRU. A WTRU may explicitly indicate the MCS table by using one or more bit fields in the SCI. Additionally or alternatively, a WTRU may consist of or pre-configured mappings between sets of QoS parameters and MCS tables. The WTRU may then implicitly indicate the MCS table to be used by transmitting the QoS parameters to the receiving WTRU.

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

[0263] For example, a WTRU can prioritize TBs with the highest priority based on the QoS of each TB. Regarding the size of the scheduled allow, for example, if a WTRU needs to decide which TBs in the HARQ buffer should be sent, the WTRU can prioritize TBs that require the smallest change in MCS compared to the previous transmission. Additionally or alternatively, the WTRU can prioritize TBs with an MCS less than or equal to the MCS of the previous transmission.

[0264] Regarding TB buffers, a WTRU can, for example, prioritize TBs in the HARQ buffer. Regarding whether a TB UL HARQ has been sent, a WTRU can prioritize TBs whose NACK state is propagated to the gNB when it needs to decide which TB in the HARQ buffer to send. Regarding TB cast types, a WTRU can prioritize broadcast transmissions if two TBs have the same priority.

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

[0266] In the case of blind retransmission, the WTRU may perform a blind retransmission by using the same or a different redundant version (RV) as the initial transmission. Furthermore, the WTRU may indicate to the receiver WTRU whether HARQ feedback should be disabled or if the WTRU is unable to monitor the HARQ feedback of the initial transmission. In the case of feedback-based retransmission, the WTRU may decide to perform a retransmission based on HARQ feedback from the receiver WTRU. Furthermore, the WTRU may listen for HARQ feedback from the receiver WTRU and indicate to the receiver WTRU to enable HARQ feedback.

[0267] A WTRU may determine the type of TB retransmission based on the timing of the initial transmission, retransmission, and UL HARQ feedback and SL HARQ feedback. In an exemplary approach, a WTRU may decide to perform a blind retransmission when it receives a DCI scheduling resources for both the initial transmission and retransmission, with the timing of UL HARQ feedback for transmission occurring after the retransmission. In another exemplary approach, a WTRU may decide to perform a HARQ-based retransmission when it receives a DCI scheduling UL HARQ feedback between the initial transmission and retransmission.

[0268] Figure 6 shows an example of a WTRU that determines the type of retransmission based on the timing of initial transmission, retransmission, and UL HARQ feedback. In the example shown in Figure 100 for Option 1, the WTRU may perform blind retransmission, while in Option 2, the WTRU may perform HARQ-based retransmission.

[0269] Therefore, in Option 1, the WTRU can receive a DCI 610 scheduling resources for both the initial transmit 630 and the retransmit 650, and the timing of the UL HARQ feedback 670 for the transmit is after the retransmit 650. As a result, the WTRU may decide to perform a blind retransmit.

[0270] Furthermore, in Option 2, the WTRU can receive DCI620 scheduling UL HARQ feedback 660 between the initial transmit 640 and the retransmit 680. As a result, the WTRU may decide to perform HARQ-based retransmission.

[0271] In an exemplary scenario, a WTRU may receive a DCI that schedules UL HARQ feedback between initial transmit and retransmit timing resources. The WTRU may indicate to the gNB about the use of the retransmit resource. The UL HARQ feedback may indicate one or more of the following: the WTRU uses permission for retransmitting the same TB, the WTRU uses permission for transmitting a different TB, and / or the WTRU releases permission. In another exemplary approach, if the WTRU receives an ACK from a receiver WTRU for a previous transmit, it may decide to use a retransmit resource scheduled in one DCI for transmitting a different TB.

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

[0273] In exemplary scenarios, methods may exist to support in-coverage and out-of-coverage communication. In exemplary scenarios, a Tx WTRU may transmit information about its Tx pool to an Rx WTRU. Specifically, a Tx WTRU may implicitly or explicitly transmit information about its Tx pool to an Rx WTRU. The information about the Tx pool may include one or more of the following: information that the slot belongs to a resource pool, e.g., a bitmap of the resource pool; information about the periodicity of the PSFCH slot; information about the subchannel size; information about the number of subchannels in the resource; and information about the first and last RBs of the resource pool.

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

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

[0276] In exemplary scenarios, there may be ways to support feedback instructions to the network. For example, a problem may arise when a WTRU can schedule a set of resources with associated PUCCHs and expect a gNB to send HARQ enable TBs. However, in logical channel prioritization (LCP) procedures, the WTRU may send HARQ disable TBs. Therefore, it may be necessary to address how the WTRU reports HARQ ACKs / NACKs to the network.

[0277] A WTRU may provide a PUCCH resource in a dynamic or configured authorization to report the HARQ status of its transmission for the associated authorization, e.g., ACK / NACK. For an authorization associated with a PUCCH resource, the WTRU may decide to send 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 that determines whether to report a HARQ ACK or NACK may be the QoS of the TB. For example, a WTRU may report a HARQ ACK if the TB's priority and / or reliability is greater than a threshold, and a HARQ NACK if the TB's priority and / or reliability is less than a threshold. The threshold may be configured or pre-configured by the network.

[0279] One such parameter for determining whether to report a HARQ ACK or NACK may be a logical channel multiplexed in the authorization. For example, a WTRU may consist of a set of logical channels that, when multiplexed in the TB, trigger a HARQ ACK / NACK instruction.

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

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

[0282] One such parameter for determining whether to report a HARQ ACK or NACK can be the type of grant. In the example, the grant can be a configured grant or a dynamic grant). For example, the WTRU can always report a HARQ ACK for a dynamic grant and can determine whether to report either a HARQ ACK or a HARQ NACK for a configured grant.

[0283] One such parameter for determining whether to report a HARQ ACK or NACK can be the cast type.

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

[0285] One such parameter for determining whether to report a HARQ ACK or NACK can 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 determine to report a HARQ ACK or a HARQ NACK based on the number of transmissions made by the WTRU for the last TB of the WTRU, as well as the priority and / or reliability of the TB. Specifically, the WTRU may determine the expected number of transmissions of the TB based on its priority and / or reliability. Then, the WTRU may determine whether to transmit a HARQ ACK or NACK based on both the expected number of transmissions of the TB and the number of transmissions made for the TB. If the expected number of 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 exemplary example, the WTRU may determine to report a HARQ ACK or a HARQ NACK based on the timing and / or amount of future grants. 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 set of grants or a future resource set of dynamic grants.

[0288] In another exemplary example, the WTRU may determine to report a HARQ ACK or a HARQ NACK based on its buffer state and the resources available in the future. Specifically, if the WTRU still has data in its buffer, the WTRU may report a HARQ NACK. For example, the data may be stored in a MAC, radio link control (RLC) buffer or a HARQ buffer, and / or the future resources may not be able to satisfy the QoS of the data pending in the buffer. Additionally or alternatively, the WTRU may report a HARQ NACK if it does not have data in its buffer.

[0289] A WTRU may report a HARQ ACK under exemplary conditions. In another exemplary case, a WTRU may report a HARQ ACK if the final TB sent in the resource with the associated PUCCH is a HARQ invalidation TB.

[0290] In another exemplary example, a WTRU may decide to select between HARQ-enabled sidelink radio bearers (SLRBs) and HARQ-disabled SLRBs for multiplexing in a TB. The WTRU may determine which type of SLRB is multiplexed in a TB for a resource having associated PUCCH, by configuring or preconfiguring a priority gap between the HARQ-enabled SLRBs and the HARQ-disabled SLRBs. Specifically, if the priority of the HARQ-enabled SLRB is greater than or equal to the priority gap of the HARQ-disabled SLRB, the WTRU may, in one example, prioritize the HARQ-enabled SLRB over the HARQ-disabled SLRB. The priority gap may be configured, preconfigured, or fixed. For example, if the priority gap is fixed at zero, the WTRU may prioritize the HARQ-enabled SLRB over the HARQ-disabled SLRB for a resource having associated PUCCH, provided both SLRBs have the same priority.

[0291] In an example, a WTRU may decide to trigger a scheduling request (SR) and / or a buffer status report (BSR). In another exemplary approach, a WTRU may consist of an SR associated with the transmission of a HARQ invalidation TB at a resource with an associated PUCCH. The WTRU may trigger an SR and / or a BSR when it transmits a HARQ invalidation TB at the final resource associated with the PUCCH. The WTRU may further trigger an SR and / or a BSR only when it reports a specific value of ACK or NACK based on any of the conditions considered herein, for example, a BSR is triggered when the WTRU reports a NACK. After the WTRU reports a NACK and has used the retransmission resources provided by the network, the WTRU may further calculate a BSR. The WTRU may be further configured or preconfigured with one or any combination of the criteria / conditions to trigger an SR and / or a BSR.

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

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

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

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

[0296] One criterion / condition could be the type of resource assigned. For example, if a TB with HARQ disabled is sent in an authorized configuration, the WTRU may trigger an SR and / or BSR, while if a TB with HARQ disabled is sent in a dynamic authorized configuration, the WTRU may not trigger an SR.

[0297] One criterion / state can be a cast type. For example, WTRU can trigger SR and / or BSR based on its cast type.

[0298] For example, a WTRU may cancel a pending BSR / SR transmission in a case where it reports a NACK to a transmission without a HARQ. Specifically, a 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 on the 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 satisfies the latency requirements for the new data that triggered the BSR.

[0299] In one or more embodiments disclosed herein, the WTRU may determine whether a slot should trigger a resource reassessment for one or more selected resources based on the time between the slot selecting a resource and the slot of the first selected resource and the remaining delay budget of TB. The WTRU may determine when to trigger a resource reassessment. 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 conflicted resources. The WTRU may perform resource selection based on the availability of CSI. The WTRU may determine when to stop RSRP increments in a resource assessment or reassessment 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 TB and its QoS. The WTRU may decide to report a HARQ ACK / NACK based on the timing and / or amount of future authorizations. A WTRU may decide to report a HARQ ACK or HARQ NACK based on its buffer state and future available resources. A WTRU may report a HARQ ACK. A WTRU may choose between a HARQ-enabled SLRB and a HARQ-disabled SLRB for multiplexing in TB. A WTRU may decide to trigger an SR and / or BSR.

[0300] While the features and elements are described above in specific combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. Furthermore, the methods described herein can be implemented in computer programs, software, or firmware embedded in computer-readable media for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via 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 associated with the software can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method for use in a wireless transceiver unit (WTRU), Receiving the first data via the first physical sidelink shared channel (PSSCH) transmission, The second PSSCH transmission transmits the second data, Receiving the third data in the third PSSCH transmission, Prioritization between transmission and reception of the physical sidelink feedback channel (PSFCH) is determined based on the first priority associated with the first data, the second priority associated with the second data, and the third priority associated with the third data. Conditional on the prioritization decision being made to transmit the PSFCH, a decision is made to transmit a single PSFCH transmission or multiple PSFCH transmissions based on the power level of the first PSFCH transmission associated with the first data and the power level of the second PSFCH transmission associated with the third data. On the condition that the transmission of the single PSFCH transmission is decided, it is determined whether the single PSFCH transmission is a first PSFCH transmission or a second PSFCH transmission based on the first priority associated with the first data and the third priority associated with the third data, The transmission of the single PSFCH transmission, wherein, on the condition that the single PSFCH transmission is determined to be the first PSFCH transmission, a first Hybrid Automatic Repeating Request (HARQ) Response (ACK) / Negative ACK (NACK) feedback associated with the first data is transmitted in the first PSFCH transmission, and on the 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, Methods that include...

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

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

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

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

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

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

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

9. The method according to claim 1, wherein the second priority is based on the second QoS.

10. The method according to claim 1, wherein either 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. The method according to claim 1, further comprising receiving a third PSFCH transmission associated with the second data, provided that the reception of the PSFCH is 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. The method according to claim 1, wherein, on the condition that the transmission of the plurality of PSFCH transmissions is decided, the first PSFCH transmission and the second PSFCH transmission are transmitted, further comprising the first PSFCH transmission transmitting the first HARQ ACK / NACK feedback associated with the first data and the second PSFCH transmission transmitting the second HARQ ACK / NACK feedback associated with the third data.

13. A wireless transceiver unit (WTRU), Transceiver and The transceiver comprises a processor operably coupled to the transceiver, The transceiver and the processor are configured to receive first data via a first physical sidelink shared channel (PSSCH) transmission. The transceiver and the processor are configured to transmit the second data in the second PSSCH transmission. The transceiver and the processor are configured to receive the third data in the third PSSCH transmission. The processor is configured to determine prioritization between transmission and reception of the physical sidelink feedback channel (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 whether to transmit a single PSFCH transmission or multiple PSFCH transmissions based on the power level of a first PSFCH transmission associated with the first data and the power level of a second PSFCH transmission associated with the third data, provided that the transmission of the PSFCH is determined in the prioritization determination. The transceiver and the processor are configured to determine whether the single PSFCH transmission is a first PSFCH transmission or a second PSFCH transmission, based on a first priority associated with the first data and a third priority associated with the third data, provided that the transmission of the single PSFCH transmission is determined. A WTRU wherein the transceiver and the processor are configured to transmit the single PSFCH transmission, and 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, provided that the single PSFCH transmission is determined to be the first PSFCH transmission, and a second HARQ ACK / NACK feedback associated with the third data is transmitted in the second PSFCH transmission, provided that the single PSFCH transmission is determined to be the second PSFCH transmission.

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

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

16. The WTRU according to claim 14, wherein the first priority is based on the first priority value.

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

18. The WTRU according to claim 16, wherein the second priority is based on the second priority value.

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

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

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

22. The WTRU according to claim 13, wherein either 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. The WTRU according to claim 13, wherein the transceiver and the processor are further configured to receive a third PSFCH transmission associated with the second data, provided that the reception of the PSFCH is determined in the prioritization determination, and a third HARQ ACK / NACK feedback associated with the second data is received in the third PSFCH transmission.

24. The WTRU according to claim 13, wherein the transceiver and the processor are further configured to transmit the first PSFCH transmission and the second PSFCH transmission, provided that the transmission of the plurality of PSFCH transmissions is determined, 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.

Images