Method and apparatus for inter-sidelink wireless transmitter / receiver unit (WTRU) communication.

Abstract

To provide methods, apparatuses, systems, architectures, and interfaces for a WTRU performing side link communications.SOLUTION: The present method may include any of: receiving SL transmission configuration information indicating (1) a dedicated resource allocation for assistance transmissions, and (2) triggering conditions for performing an assistance transmission; on condition that (i) a physical SL shared channel (PSSCH) transmission is received, by the WTRU from another WTRU, according to a semi-persistent reservation, and (ii) one or more of the triggering conditions for performing the assistance transmission has occurred, (a) performing sensing based on sensing parameters associated with the received PSSCH transmission, and (b) selecting a dedicated resource allocation according to a resource of the received PSSCH transmission; and transmitting, to any number of proximate WTRUs, an assistance transmission using the selected dedicated resource allocation, the assistance transmission including assistance information associated with the sensing performed by the WTRU.SELECTED DRAWING: Figure 2

Description

Background Art

[0001] The present invention relates to the field of communications, and more specifically, to methods, apparatuses, systems, architectures, and interfaces for communications in advanced or next-generation wireless communication systems, including new radio and / or new radio (NR) access technologies and communications performed using a communication system. The NR access technology and communication system can include, for example, vehicle-to-everything (V2X) for communication between any of automobiles on a roadway, infrastructure, pedestrians, and / or a network (e.g., can be used therefor), and wireless transmit / receive units (WTRUs) can communicate with each other (e.g., directly).

[0002] V2X scenarios include (1) an in-coverage scenario where a WTRU can receive assistance from a network to initiate transmission and reception of vehicle communication messages, and (2) an out-of-coverage scenario where a WTRU can initiate transmission and reception of vehicle communication messages using pre-configured parameters. V2X services include: (1) vehicle-to-vehicle (V2V): vehicle WTRUs can communicate directly with each other; (2) vehicle-to-infrastructure (V2I): a vehicle WTRU can communicate with either a roadside unit (RSU), or a base station (BS) such as evolved NodeBs (eNBs) or other access points; (3) vehicle-to-network (V2N): a vehicle WTRU can communicate with a core network, and (4) vehicle-to-pedestrian (V2P): a vehicle WTRU can communicate with a UE associated with a pedestrian under specific and / or special conditions, e.g., under low battery capacity. Further, V2X use cases can include evolved mobile broadband (eMBB), massive machine type communication (mMTC), and ultra-reliable low latency communication (URLLC). Different use cases may focus on different requirements such as higher data speeds, higher spectral efficiency, low power, and higher energy efficiency, shorter latency, and higher reliability.

Brief Description of the Drawings

[0003] A more detailed understanding can be obtained from the following description, which is given as an example in conjunction with the attached drawings, where similar reference numbers in the drawings indicate similar elements. [Figure 1A] This is a system diagram showing an exemplary communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] This is a system diagram showing an exemplary wireless transmit / receive unit (WTRU) that may be used in the communication system shown in Figure 1A, according to one embodiment. [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. [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. [Figure 2] This figure shows the transmission of support information triggered by an explicit request, according to the embodiment. [Figure 3] This figure shows an example of support information transmission triggered by a semi-persistent (SP) based resource reservation. [Figure 4] This figure shows an assist transmission triggered by either a HARQACK / NACK transmission or a HARQ retransmission, according to the embodiment. [Figure 5] This figure shows a support transmission that provides resource set information according to an embodiment. [Modes for carrying out the invention]

[0004] Exemplary network for implementing the embodiment Figure 1A shows an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, message transmission, and broadcast to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word DFT-Spread OFDM (ZT UW DTS-s OFDM), unique-word OFDM (UW-OFDM), resource block filtering OFDM, and filter bank multicarrier (FBMC).

[0005] As shown in Figure 1A, the communication system 100 may include radio transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, 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, 102d may be any type of device configured to operate and / or communicate in a radio environment. For example, WTRU102a, 102b, 102c, and 102d, any of which may be referred to as “station” and / or “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, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, radio 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 radio devices operating in an industrial and / or automated processing chain context), consumer electronics devices, and devices operating in commercial and / or industrial radio networks. Any of WTRU102a, 102b, 102c, and 102d may interchangeably be referred to as UE.

[0006] 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 / 115, the Internet 110, and / or other networks 112. As an example, base stations 114a and 114b may be base transceiver stations (BTS), node B, eNodeB, home node B, home eNodeB, gNB, NR nodeB, site controller, access point (AP), wireless router, etc. 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.

[0007] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), and relay nodes. 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 spectra, unlicensed spectra, or a combination of licensed and unlicensed spectra. Cells may provide coverage of radio services to a particular geographic area that may be relatively fixed or change over time. Cells 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 transceiver per sector of the cell. In one embodiment, the base station 114a may use multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

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

[0009] More specifically, as described above, the communication system 100 may be a multiple 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 and WTRUs 102a, 102b, 102c in RAN 104 / 113 may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish air interfaces 115 / 116 / 117 using wideband CDMA (WCDMA®). WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or Advanced HSPA (HSPA+). HSPA may include High-Speed ​​Downlink Packet Access (HSDPA) and / or High-Speed ​​UL Packet Access (HSUPA).

[0010] 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-A Pro).

[0011] In one embodiment, base stations 114a and WTRUs 102a, 102b, and 102c can implement radio technologies such as NR radio access, which can establish an air interface 116 using New Radio (NR).

[0012] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, base station 114a and WTRUs 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 WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions to and from multiple types of base stations (e.g., eNB and gNB).

[0013] 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 Interoperability for Microwave Access, WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), and GSM EDGE (GERAN).

[0014] The base station 114b in Figure 1A may be, for example, a wireless router, home node B, home eNode B, or access point, and may utilize any suitable RAT to facilitate wireless connectivity in local areas such as offices, homes, vehicles, campuses, industrial facilities, aerial corridors (for use by drones), roads, etc. In one embodiment, the base station 114b and WTRU 102c, 102d may 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 may 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 may 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 / 115.

[0015] RAN104 / 113 can communicate with CN106 / 115, 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 / 115 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 / 113 and / or CN106 / 115 may communicate directly or indirectly with other RANs employing the same or different RATs as RAN104 / 113. For example, in addition to being connected to RAN104 / 113 which may utilize NR radio technology, CN106 / 115 may also communicate with another RAN (not shown) employing GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0016] CN106 / 115 may also function as a gateway for WTRU102a, 102b, 102c, 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, where these networks and devices use common communication protocols such as the transmission control protocol (TCP), the user 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, which may employ the same RAT as RAN104 / 113 or a different RAT.

[0017] 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 may use cellular-based radio technology, and base station 114b, which may use IEEE 802 radio technology.

[0018] 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 partial combination of the aforementioned elements while maintaining consistency with one embodiment.

[0019] 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) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120 which may be coupled to a transmit / receive element 122. Figure 1B shows the processor 118 and transceiver 120 as separate components, but it will be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0020] The transmit / receive element 122 can 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 can be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmit / receive element 122 can 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 can be configured to transmit and / or receive both RF signals and optical signals. It will be understood that the transmit / receive element 122 can be configured to transmit and / or receive any combination of wireless signals.

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

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

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

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

[0025] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116 and / or determine its location 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.

[0026] 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. The peripheral device 138 may include one or more sensors, which may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, compass sensor, proximity sensor, temperature sensor, time sensor, geolocation sensor, altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor, and / or humidity sensor.

[0027] WTRU102 may include a full-duplex radio in which the transmission and reception of some or all of the signals (e.g., associated with specific subframes for both UL (e.g., transmission) and downlink (e.g., reception) may be in parallel and / or simultaneous. 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, WRTU102 may include a half-duplex radio for the transmission and reception of any of the signals (e.g., associated with specific subframes for either UL (e.g., transmission) or downlink (e.g., reception)).

[0028] Figure 1C is a system diagram illustrating 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.

[0029] 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 may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU102a.

[0030] 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 may communicate with each other via the X2 interface.

[0031] 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 (or PGW) 166. Although each of the aforementioned elements is 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.

[0032] The MME162 can be connected to each of the eNode-B160a, 160b, and 160c within RAN104 via the S1 interface and can function as a control node. For example, MME162 may perform roles such as authenticating users of WTRU102a, 102b, and 102c, activating / deactivating bearers, and selecting gateways for specific services during the initial attachment of WTRU102a, 102b, and 102c. MME162 may also provide control plane functionality for switching between RAN104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

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

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

[0035] CN106 can facilitate communication with other networks. For example, CN106 can 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 can 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.

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

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

[0038] A WLAN in Infrastructure 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 another type of wired / wireless network that carries traffic entering and / or leaving the Distribution System (DS) or BSS. Traffic originating outside the BSS and destined for the STAs may reach and be delivered to the STAs via the APs. Traffic originating from the STAs and destined for destinations outside the BSS may be sent to the APs and then delivered to their respective destinations. Traffic between STAs within the BSS may be transmitted, for example, via APs; a source STA may send traffic to the 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) via a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS 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 the “ad hoc” communication mode.

[0039] 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 width dynamically set via signaling. 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 some typical embodiments, for example in an 802.11 system, Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) may be implemented. 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 on a given BSS.

[0040] High-throughput (HT) STAs may use a 40 MHz wide channel for communication, which may be formed, for example, through a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels.

[0041] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. The 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels, or by combining two non-contiguous 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 for 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 operation described above for the 80+80 configuration may be reversed, and the combined data may be transmitted to Medium Access Control (MAC).

[0042] Sub-1GHz 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 5MHz, 10MHz, and 20MHz bandwidths in the TV White Space (TVWS) spectrum, while 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using the non-TVWS spectrum. According to a typical embodiment, 802.11ah may support meter-type control / machine-type communications, 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).

[0043] 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 due to an STA (which only supports 1MHz operating mode) transmitting to the AP, a large portion of the frequency band may remain idle and could be considered busy, even if it were available.

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

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

[0046] RAN113 may include gNB180a, 180b, and 180c, but it will be understood that RAN113 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 108b may use beamforming to transmit and / or receive signals to gNB180a, 180b, and 180c. Thus, gNB180a may, 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).

[0047] WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using transmissions associated with scalable 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 may communicate with gNB180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of varying or scalable lengths (e.g., containing varying numbers of OFDM symbols and / or having varying absolute time durations).

[0048] 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. In a non-standalone configuration, 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, while gNB180a, 180b, and 180c can provide additional coverage and / or throughput to service WTRU102a, 102b, and 102c.

[0049] 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 slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a and 182b, and so on. As shown in Figure 1D, the gNB180a, 180b, and 180c may communicate with each other via the Xn interface.

[0050] The CN115 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 each of the aforementioned elements is shown as part of the CN115, it will be understood that any of these elements may be owned and / or operated by entities other than the CN operator.

[0051] AMF182a and 182b can be connected to one or more gNB180a, 180b, and 180c in RAN113 via the N2 interface and can function as control nodes. For example, AMF182a and 182b can perform roles such as user authentication for WTRU102a, 102b, and 102c, support network slicing (e.g., handling different PDU sessions with different requirements), selection of specific SMF183a and 183b, management of registration areas, termination of 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 relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, and / or similar. The AMF162 may provide control plane functionality for switching between RAN113 and other RANs (not shown) employing other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0052] SMF183a and 183b can be connected to AMF182a and 182b in CN115 via the N11 interface. SMF183a and 183b can also be connected to UPF184a and 184b in CN115 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 WTRU IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0053] UPF184a and 184b may be connected via the N3 interface to one or more of gNB180a, 180b, and 180c in RAN113, 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 may perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

[0054] CN115 can facilitate communication with other networks. For example, CN115 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that functions as an interface between CN115 and PSTN108. Furthermore, CN115 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 data networks (DNs) 185a,185b through UPF184a,184b via an N3 interface to UPF184a,184b and an N6 interface between UPF184a,184b and DN185a,185b.

[0055] As can be seen from Figures 1A to 1D and their corresponding descriptions, one or more of the functions described herein relating to one or more of the WTRU102a to d, base stations 114a to b, eNode-B160a to c, MME162, SGW164, PGW166, gNB180a to c, AMF182a to b, UPF184a to b, SMF183a to b, DN185a to b, and / or any other devices described herein may be implemented 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 may be used to test other devices and / or simulate network and / or WTRU functions.

[0056] 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 / deployed as part of a wired and / or wireless network. Emulation devices may be directly coupled to another device for testing purposes and / or may perform testing using terrestrial radio communication.

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

[0058] (Detailed explanation) In the case of vehicle-to-vehicle (V2X) communication, various operating modes may exist, such as Release 14 (R14) modes 3 and 4, and Release 16 (R16) mode 2 (e.g., LTE). In mode 2 operation, the R16 V2X WTRU performs resource (re)selection based on sensing, for example, without any central scheduling or inter-WTRU coordination. In such cases, the sensing mechanism may cause (e.g., potential) collisions, for example, due to an increase in the RSRP threshold, when available resources are limited (e.g., especially in congested scenarios). Furthermore, in such cases, if (e.g., such) collisions occur against semi-persistent resource reservations, the collisions can become persistent, causing continuous packet loss. As a result, the R16 NR sidelink (SL) does not (e.g., cannot) ensure high reliability and low latency under conditions such as when the channel is busy (e.g., congested scenarios).

[0059] Release 17 (R17) supports ultra-high reliability low-latency communication (URLLC) type SL use cases in (e.g., advanced) operating scenarios. Considering R16, which provides limited support for specific transmits (e.g., as described above), inter-WTRU cooperation in mode 2 operation is considered for R17, for example. That is, for R17, inter-UE cooperation is considered to improve the reliability and latency of SL transmits. One form of such cooperation is a WTRU providing support information to another WTRU. The support information can be a set of resources determined by the WTRU. For example, inter-WTRU cooperation includes a first WTRU that determines a set of resources in mode 2 and sends them to a second WTRU, so that the second WTRU can take this into consideration in its resource selection for its own transmit.

[0060] However, in Mode 2 (for example, conventionally in the relevant technical field, such as R17), there is a lack of coordination between WTRUs (e.g., no coordination at all), where, for example, one WTRU does not know, for example, whether or when another WTRU has traffic for transmission, and furthermore, one WTRU does not know what type of resources another WTRU is using. Such a lack of coordination can result in an excessive number of required transmissions. Therefore, it is necessary to enable inter-WTRU coordination features while avoiding an excessive number of required transmissions. Taking into account at least the aforementioned issues (e.g., lack of inter-WTRU communication), it is necessary to provide solutions (e.g., address, resolve, etc.) to one of the following issues / questions: (1) Does a WTRU(s) provide support information? (2) Which WTRU(s) request and / or receive support information? (3) What are the trigger conditions for such communication? (4) How does a WTRU(s) obtain support information that is useful, for example, for another WTRU(s) resource selection? (5) What does the support information include? (6) How is the support information transmitted? (7) How does another WTRU(s) use the support information in its resource selection?

[0061] According to embodiments, a WTRU may transmit support information to, for example, another WTRU, or any other similar and / or appropriate network node (e.g., it may perform a support transmission). According to embodiments, a WTRU may perform a support transmission to, for example, assist in the selection of SL resources for transmission by another WTRU. According to embodiments, a support transmission may carry information including a set of SL resources (e.g., support). According to embodiments, a WTRU may be a supporting WTRU (e.g., a supporting WTRU). That is, a WTRU may be referred to as a supporting WTRU when it performs a support transmission, for example, as discussed and / or referred to herein. According to embodiments, a WTRU may either trigger or receive a support transmission. According to embodiments, a WTRU that triggers and / or receives a support transmission may be referred to as a supported WTRU. According to embodiments, in this specification, supporting WTRUs and supported WTRUs may be referred to as such with respect to (e.g., specific) support information transmissions.

[0062] Determining the WTRU trigger for support transmission According to the embodiment, a WTRU may determine whether to perform an assisting transmission and / or become a assisting WTRU. According to the embodiment, a WTRU may determine to perform an assisting transmission and / or become a assisting WTRU according to (for example, based on) any number of conditions (e.g., triggers). According to the embodiment, such triggers and / or conditions (used to determine whether to perform an assisting transmission and / or become a assisting WTRU) may include: (1) the WTRU receives an explicit request for an assisting transmission from, for example, a supported WTRU; (2) the WTRU receives a semi-persistent resource reservation from the supported WTRU; (3) the WTRU receives a CSI request from the supported WTRU; (4) the WTRU detects (e.g., several) collisions applicable to a semi-persistent resource reservation by / with the supported WTRU; (5) the WTRU is unable to decode some PSSCH from the supported WTRU, for example, the corresponding HARQ (6) The WTRU sends a NACK transmission; (7) The WTRU is unable to decode some PSSCHs corresponding to resource reservations from the assisted WTRU; (8) The WTRU is located below (e.g., extending above) a threshold (as referred herein, the terms configured, pre-configured, and (pre-configured) are used interchangeably); (9) The WTRU measures (e.g., detect, determine, etc.) a congestion metric (e.g., channel busy ratio (CBR)) that is higher than a (pre-configured) threshold; (10) The WTRU receives a configuration for assistance transmissions during (e.g., between) SL link establishment (e.g., procedure) signaling applicable to the assisted WTRU; (11) The WTRU is of a type (e.g., vehicle WTRU, pedestrian user, vulnerable road user (VRU), first responder, etc.) (e.g., vehicle WTRU, pedestrian user, vulnerable road user (VRU), first responder, etc.). According to the embodiment, the WTRU may trigger a supported transmission (for example, it may determine to perform, execute, transmit, etc.) if the data associated with the supported WTRU is available (for example, for transmission).According to the embodiment, the WTRU may be configured (for example, in advance) to perform periodic support transmissions for any of the following: a V2X application, a data group, a WTRU group, an application group, etc.

[0063] Figure 2 shows an example of a support information transmission triggered by an explicit request.

[0064] According to the embodiment, the transmission of support information (e.g., a WTRU support transmission) may be triggered by a request (e.g., explicit, signaled, determined, etc.). According to the embodiment, the transmission of a request for support transmission (e.g., a support transmission request) may be performed (e.g., triggered, determined, etc.) according to (e.g., specific) conditions. According to the embodiment, a WTRU may determine whether to transmit an explicit support transmission request or become a supported WTRU, for example, when resource (re)selection of a transmission block (TB) is triggered by a higher layer.

[0065] According to the embodiment, a WTRU determines whether to send an explicit assisted transmit request (in addition to and / or instead of resource (re)selection of TB triggered by a higher layer) and become a assisted WTRU, according to any of the following conditions (e.g., trigger): (1) the (e.g., remaining) packet delay budget exceeds a (pre-) configured threshold (e.g., the remaining packet delay budget allows for round-trip propagation and WTRU processing time associated with (e.g., generated by) the assisted transmit request and the assisted transmit; (2) reliability However, (1) the (pre-configured) threshold is exceeded (e.g., the support transmission is triggered by the transmission of a high-reliability TB such as BLER at 1E-5); (2) the priority exceeds the (pre-configured) threshold (e.g., the inter-WTRU support procedure may be triggered by the transmission of a high-priority TB); (3) the size of the transport packet exceeds the (pre-configured) threshold (e.g., the support transmission may be triggered by the transmission of a large TB requiring many subchannels); (4) the distance to the WTRU to which the support transmission request is sent (e.g., the intended) WTRU is below the (pre-configured) threshold.

[0066] According to the embodiment, the content of a support transmission request may represent various information. According to the embodiment, the supported WTRU may, for example, include any of the following (e.g., resource (re)selection) information in a support transmission request: (1) for example, the resource pool from which PSSCH resources can be reported; (2) for example, the L1 priority of the TB used for transmission by the supported WTRU; (3) for example, the remaining packet delay budget (PDB) (i.e., within slots) of the TB used for transmission by the supported WTRU; (4) T1_TB, for example, the start of the transmission window from which the TB can be transmitted; (5) T2_TB, for example, the end of the transmission window; (6) for example, the number of subchannels to be used for PSSCH transmission of the TB; and (7) the number of resources required (requested) in the resource set, such as (i) the number of resources requested in the resource set and (ii) the ratio of the total number of candidate resources in the transmission window.

[0067] According to the embodiment, the (e.g., supported) WTRU may determine, for example, the (e.g., remaining) PDBs to be included in the supported transmission request, according to (e.g., based on) either the remaining PDBs of the TB used for transmission or the time resources reserved for the supported transmission request. According to the embodiment, the WTRU may calculate the remaining PDBs to be included in the supported transmission request as shown in the following equation [1]:

[0068]

number

[0069] According to the embodiment, for example, if the WTRU receives a resource selection trigger in slot n associated with TB and determines that the WTRU will send an assistance transmission request in slot m, it may calculate the remaining PDB using equation [1]. According to the embodiment, (for example, in another case) the assisted WTRU may determine T2_TB based on a (pre-configured) T2_min. For example, according to the embodiment, T2_min ≤ T2_TB ≤ PDB TB In this case, the supported WTRU may select T2_TB according to the WTRU implementation (e.g., designed, selected, etc.). Also, according to the embodiment, T2_min > PDB TB In this case, T2_DB is a PDB. TB It may also be equal to this.

[0070] According to the embodiment, the supported WTRU may determine T1_TB according to (for example, based on) the QoS requirements of the TB. That is, according to the embodiment, the supported WTRU may determine the initial T1_TB of a large transmit window to allow more resources for resource selection of a TB that has either high reliability and / or priority requirements. According to the embodiment, either T1_TB or T2_TB may be an absolute frame, a subframe, or a slot number. According to the embodiment, either T1_TB or T2_TB may be an offset (i.e., number of slots) to the timing (slot) of the support transmit request.

[0071] According to the embodiment, a support transmission request may be transmitted using any of the following resources, signaling, messaging, channels, etc. According to the embodiment, a support transmission request may be transmitted using PSCCH and PHY signaling (e.g., carried). According to the embodiment, a support transmission request may be transmitted using a standalone PSCCH (e.g., carried). According to the embodiment, a support transmission request may be transmitted using PSCCH transmission and either MAC CE or RRC signaling (e.g., carried).

[0072] According to the embodiment, the supported WTRU may transmit a support transmission request according to one of a plurality of configurations. For example, according to the embodiment, the supported WTRU may transmit a support transmission request according to a configuration having a PSSCH / PSCCH using one subchannel, for example, if the supported WTRU transmits a PSSCH containing only a support transmission request (for example, it may transmit one). As another example, according to the embodiment, the supported WTRU may transmit a support transmission request according to a configuration having a PSSCH / PSCCH using multiple subchannels, for example, if the supported WTRU transmits a PSSCH containing both a support transmission request and data TB.

[0073] According to the embodiment, the supported WTRU may perform sensing for resource selection for a supported transmission request, for example. According to the embodiment, the WTRU may apply any of several sensing patterns, for example, as discussed below. According to the embodiment, the sensing parameter may be, for example, a resource pool from which resources are reported. That is, according to the embodiment, the supported WTRU may select a resource from a resource pool dedicated to / for a supported transmission request. According to the embodiment, the sensing parameter may be an L1 priority. That is, according to the embodiment, the L1 priority of a supported transmission request may be configured (in advance) so that, for example, the L1 priority is set to the highest / lowest priority. According to the embodiment, the L1 priority of a supported transmission request may be the same as that of a TB carried in the same transmission (for example, it may be set as ). According to the embodiment, the sensing parameter may be a remaining PDB. That is, according to the embodiment, the remaining PDB of a supported transmission request may be configured (in advance). For example, either a fixed value or a small value may be configured (in advance). According to the embodiment, the remaining PDB of a supported transmission request may be the same as that of a TB carried in the same transmission (for example, it may be set as ). According to one embodiment, the sensing parameter may be, for example, the number of subchannels used for support transmission requests.

[0074] According to the embodiment, the supported WTRU may determine either the T1_request or the T2_request of the support transmission request. According to the embodiment, the T1_request may be determined according to (e.g., based on) WTRU processing. According to the embodiment, the T2_request may be determined according to (e.g., based on) (pre-)configuration. For example, according to the embodiment, a fixed T2_request may be (pre-)configured for the support transmission request. According to the embodiment, the T2_request may be determined according to (e.g., based on) the remaining PDB of the TB. That is, according to the embodiment, the supported WTRU may select the T2_request to ensure that any of the following steps can be completed within the remaining PDB: the step of sending / transmitting the support transmission request; the step of receiving the support transmission; the step of processing support information and selecting resources for the transmission of the TB; and the step of sending / transmitting the TB.

[0075] According to the embodiment, the support request transmission may be a new (e.g., different from the above-described) SL physical signal and / or physical channel (e.g., transmitted, sent, etc., via, using, or included in the WTRU). That is, according to the embodiment, the WTRU may transmit a support request (e.g., transmission) on a new SL PHY signal and / or PHY channel. According to the embodiment, the WTRU may consist of (e.g., pre-configured) resource allocation for either (e.g., dedicated to, only for, etc.) support requests and support information transmissions. According to the embodiment, the resource allocation may be (1) a resource pool and (2) a set of time and frequency resources allocated within the resource pool, for example.

[0076] According to the embodiment, such resources may be configured (e.g., pre-configured) for either support request transmissions and support information transmissions (e.g., as described above). According to the embodiment, such resources may not be used by / for other SL transmissions (e.g., V2X data transmissions). According to the embodiment, such time and frequency resources (e.g., sets) may include any of the following: sets of SL slots, sets of SL symbols, sets of subchannels, sets of PRBs, and sets of subcarriers (e.g., consisting of them, comprising them, etc.). According to the embodiment, such time and frequency resources (e.g., sets) may be configured (e.g., pre-configured) for / in a resource pool for SL data transmissions.

[0077] According to the embodiment, the WTRU may determine resources for sending an assistance request. According to the embodiment, the WTRU may determine resources such as time resources and frequency resources for either the PHY assistance request channel and the ZC sequence index according to one of the following (e.g., selectable, pre-configured): (1) the source ID and / or destination ID of the SL link to which the assistance request applies; (2) the link ID of the SL link to which the assistance request applies; (3) the total number of time and frequency resources configured (e.g., pre-configured) for sending the assistance request; (4) the total number of ZC sequences configured (e.g., pre-configured) for sending the assistance request; and (5) the index / number of slots for the request transmission. According to the embodiment, the WTRU may trigger an assistance request transmission according to (e.g., based on) the trigger conditions (e.g., described above). According to the embodiment, in such a case, the WTRU may select the earliest (e.g., immediately following) SL slot after the trigger, such as an SL slot with pre-configured resources for sending the assistance request. According to one embodiment, the resources available for sending support requests (e.g., available resources) may be indexed according to the total number of configured (e.g., pre-configured) ZC sequences and frequency resources (e.g., PRBs). According to one embodiment, each resource may be either a ZC sequence or a frequency resource (e.g., PRB).

[0078] According to the embodiment, the index of request transmission resources may be incremented after a configured (e.g., pre-configured) ZC sequence set up in a PRB, and further incremented (e.g., for each, etc., after) a configured (e.g., pre-configured) PRB. According to the embodiment, for example, if there are six configured (e.g., pre-configured) ZC sequences, the resources for assistance request transmission may be indexed from 0 to 5 in the first configured (e.g., pre-configured) PRB and from 6 to 11 in the second PRB. That is, for example, the index may be incremented by 6 in each PRB up to the last configured (e.g., pre-configured) PRB. According to the embodiment, such indexing may provide, for example, an index of each available resource that a WTRU selects for assistance request transmission. According to the embodiment, a WTRU may determine any number of such resources according to (e.g., based on) any of the WTRUID and / or link ID, the SL slot index, and the total number of resources. For example, a WTRU can select an index according to a modular function, using the source ID (e.g., in decimal format) and the total number of indexed resources.

[0079] Figure 3 shows an example of a support information transmission triggered by a semi-persistent (SP)-based resource reservation.

[0080] According to the embodiment, a WTRU may perform an assisting transmission triggered by a received SP resource reservation. According to the embodiment, a WTRU may determine, for example, whether to perform an assisting transmission or become an assisting WTRU when it receives a data transmission along with an SP resource reservation. According to the embodiment, a WTRU may determine that data (e.g., a received data transmission) is self-targetable and may continue to receive data according to (e.g., based on) one of the identifiers (IDs) such as a destination ID, source ID, and group member ID. According to the embodiment, the destination ID may be carried in a second SCI and may indicate a broadcast link that the WTRU may subscribe to. According to the embodiment, either the source ID or the destination ID may be carried in a second SCI and may indicate a unicast link that the WTRU may have established. According to the embodiment, in the case of a group member ID, the destination ID carried in a second SCI may indicate a groupcast link that the WTRU may subscribe to.

[0081] According to the embodiment, the supporting WTRU may trigger a supported transmission in any (e.g., each) reserved period. According to the embodiment, the supporting WTRU does not have to trigger a supported transmission after slot n. According to the embodiment, the supporting WTRU does not have to trigger a supported transmission after slot n based on any of the following: the start of the transmission window associated with the reserved transmission TxWindow_start; T2 of the supported transmission; and the (pre-configured) offset between the start of the transmission window and T2 of the supported transmission Toffset. For example, slot n may not be the slot corresponding to the timing TxWindow_start-Toffset-T2. According to the embodiment, the result in such a case (e.g., objective) may be that the supported WTRU receives the supported transmission and has enough time to process the received set of resources and select resources for the reserved transmission.

[0082] According to the embodiment, a WTRU support transmission can be triggered by a received CSI request transmission. That is, according to the embodiment, when a WTRU receives a CSI request transmission, it can perform a support transmission and determine, for example, to become a support WTRU. According to the embodiment, the WTRU can provide support information and a CSI report in a single transmission (e.g., transmission).

[0083] According to the embodiment, WTRU support transmission may be triggered by the detection of a collision in a received SP resource reservation. According to the embodiment, a WTRU may perform a support transmission and determine to become a supporting WTRU if, for example, the WTRU detects a set of collisions for a received SP resource reservation. According to the embodiment, a WTRU may detect collisions specific to a resource reservation already received from another WTRU, which may be referred to as a standing reservation. That is, according to the embodiment, a WTRU may detect a collision specific to a received resource reservation if the WTRU identifies a duplicate resource reservation from a different WTRU(s) with a higher L1 priority. According to the embodiment, a WTRU may detect a collision specific to a resource reservation if the WTRU measures the RSRP associated with any resource reservation from another WTRU that is greater than the corresponding RSRP threshold. According to the embodiment, the WTRU may determine the corresponding RSRP threshold according to any of the following: (1) RSRP(s) values ​​in transmissions received within the resource received during the (previous) reservation period, such as the RSRP value of the most recently received transmission, the averaged RSRP value across several recently received transmissions, and the maximum RSRP value across several recently received transmissions; (2) a (pre-configured) offset of XdB (e.g., 0dB or 3dB); (3) L1 priority of standing reservations (P1); (4) L1 priority of overlapping reservations (P2).

[0084] According to one embodiment, the corresponding RSRP threshold may be the sum of the RSRP value and the offset. According to another embodiment, the corresponding RSRP threshold may be, for example, a weighted RSRP value based on the RSRP value. According to another embodiment, the weighting coefficient may be, for example, based on the L1 priority of both overlapping resource reservations (for example, using a (pre-configured) function (P1, P2)).

[0085] According to the embodiment, a WTRU may determine to become a support WTRU and perform a support transmission if the detected collision exceeds a (pre-configured) threshold (e.g., 1, 5, 10, etc.). According to the embodiment, a WTRU may maintain a counter for consecutive collisions within a (pre-configured) period and / or up to a threshold. According to the embodiment, consecutive collisions may indicate that collision events may be occurring during a consecutive period of standing resource reservations. According to the embodiment, if a collision is detected, the result (e.g., objective) may be to identify a persistent collision event and (e.g., subsequently) transmit a support resource set to initiate resource reselection, for example, to avoid future collisions.

[0086] According to the embodiment, a WTRU may be able to decode either the first state SCI or the second stage SCI of a PSSCH transmission in, for example, a transmission instance(s) of a received SP-based resource reservation(s). According to the embodiment, in such a case, the WTRU may determine a collision according to (based on) any of (1) the resource reserved in the first stage SCI, (2) the representation of the WTRU type in the first stage SCI, and (3) the source ID and / or destination (e.g., destination ID) of the second stage SCI. According to the embodiment, a WTRU may determine a collision if any (e.g., a number) of the decoded information listed above is not equal to the corresponding parameter of the received SP-based reservation of the resource.

[0087] Figure 4 shows an example of an assist transmission triggered by either a HARQ ACK / NACK transmission or a HARQ retransmission.

[0088] According to the embodiment, a WTRU-assisted transmission may be triggered by a HARQ NACK transmission, for example, as shown in Figure 4. According to the embodiment, a WTRU may determine to perform an assisted transmission and become a assisted WTRUE if the number of HARQ NACK transmissions corresponding to resource reservations exceeds a (pre-configured) threshold. According to the embodiment, a WTRU may determine to perform an assisted transmission and become a assisted WTRU if the number of HARQ retransmission events reaches a (pre-configured) maximum number and / or exceeds a (pre-configured) threshold. According to the embodiment, a WTRU may select a threshold from, for example, any number of (pre-configured) thresholds.

[0089] According to the embodiment, the WTRU may select a threshold according to a fixed value (e.g., a (pre-configured) value specific to the resource pool). According to the embodiment, the value may be equal to the (pre-configured) maximum number of HARQ retransmissions per resource pool. According to the embodiment, the WTRU may select a threshold according to QoS (e.g., based on QoS) (e.g., a low threshold corresponding to high reliability and / or low latency). According to the embodiment, the WTRU may select a threshold according to CBR (e.g., based on QoS) (e.g., a low threshold if the CBR is high). According to the embodiment, the WTRU may select a threshold according to the RSRP of the received PSCCH transmission (e.g., based on QoS) (e.g., a low threshold if the PSCCH RSRP is below a (pre-configured) threshold). According to the embodiment, the WTRU may select a threshold according to the CSI of the received PSSCH transmission (e.g., based on QoS) (e.g., a low threshold if the CQI applicable to the subchannel(s) of the received PSSCH transmission is below a (pre-configured) threshold). According to the embodiment, the WTRU may select a threshold according to (for example, based on) the WTRU velocity (e.g., the state of motion) (e.g., a low threshold when the WTRU velocity is high and the channel is changing rapidly).

[0090] According to the embodiment, dynamic threshold selection may allow the WTRU to perform support transmissions more frequently, for example, when the channel condition deteriorates. According to the embodiment, the WTRU may count HARQ NACK transmissions for all initial and retransmissions. According to the embodiment, in such a case, there may be multiple HARQ NACK transmissions for each reservation interval. According to the embodiment, the WTRU may count one HARQ NACK for each reservation period (e.g., a NACK corresponding to the final HARQ retransmission). According to the embodiment, if the WTRU determines that the number of HARQ retransmissions has reached or exceeded a (pre-configured) maximum number, the WTRU may include events occurring over a continuous period of resource reservation.

[0091] According to the embodiment, a WTRU support transmission may be triggered in accordance with (for example, based on) the failure to receive any number of TBs. According to the embodiment, a WTRU may perform a support transmission and determine to become a support WTRU if the number of TBs that the WTRU is unable to receive exceeds a (pre-configured) threshold. According to the embodiment, for example, if HARQ is disabled, a WTRU may be determined according to the number of TBs that the WTRU is unable to receive over a continuous period of resource reservation compared to (for example, a (pre-configured) threshold. According to the embodiment, the WTRU threshold can be selected according to any of the following: (1) a fixed value (e.g., a (pre-configured) value specific to the resource pool); (2) QoS (e.g., a low threshold corresponding to high reliability and / or low latency); (3) CBR (e.g., a low threshold if the CBR is high); (4) RSRP of the received PSCCH transmission (e.g., a low threshold if the PSCCH RSRP is below a (pre-configured) threshold); (5) CSI of the received PSSCH transmission (e.g., a low threshold if the CQI applicable to the subchannel of the received PSSCH transmission is below a (pre-configured) threshold); (6) WTRU speed (mobility, movement state, etc.) (e.g., a low threshold if the WTRU speed is high and the channel is changing rapidly).

[0092] According to the embodiment, WTRU support transmissions may be triggered according to a range (e.g., distance, value, location, etc.). According to the embodiment, a WTRU may perform a support transmission and determine to become a supporting WTRU if it is located within a (pre-configured) range, for example, between itself and the supported WTRU. According to the embodiment, a WTRU may perform a support transmission and determine to become a supporting WTRU if it receives a semi-persistent resource reservation from the supported WTRU. According to the embodiment, the range may be determined according to either a minimum communication range requirement or a (pre-configured) threshold. For example, a WTRU may perform a support transmission and determine to become a supporting WTRU if it is moving within the range of the MCR-X meter (where X may be a (pre-configured) threshold).

[0093] According to the embodiment, a WTRU support transmission can be triggered by a CBR. According to the embodiment, a WTRU may perform a support transmission and determine to become a supporting WTRU if either (1) the WTRU measures a CBR higher than a (pre-configured) threshold, or (2) the WTRU receives a semi-persistent resource reservation from the supported WTRU.

[0094] According to the embodiment, a WTRU-assisted transmission may be performed (e.g., triggered) according to the configuration (e.g., based on). According to the embodiment, a WTRU may determine to perform an assisted transmission and become an assisting WTRU when the WTRU receives a configuration for an assisted transmission. According to the embodiment, for example, a WTRU may receive a configuration for an assisted transmission during link establishment of a unicast link. According to the embodiment, the assisted transmission configuration may include information (e.g., used, indicated, etc.) for determining the opportunity for / to perform an assisted transmission (e.g., transmission frequency and / or traffic / transmission patterns of the associated service).

[0095] According to the embodiment, WTRU support transmissions may be performed (e.g., triggered) according to the WTRU type. According to the embodiment, a WTRU may perform a support transmission and determine to be a supporting WTRU if: (1) the WTRU is of a (e.g., unique, specific, (pre-configured) type of WTRU (e.g., pedestrian or VRU type); or (2) the WTRU receives an SP resource reservation from a supported WTRU. According to the embodiment, a WTRU may have a (pre-configured) setup for support transmissions.

[0096] According to the embodiment, a WTRU may be determined to perform an assisting transmission and become an assisting WTRU if any / all of the following conditions apply: (1) the WTRU is of a (pre-configured) type (e.g., a vehicle WTRU, i.e., a V2X device installed in a vehicle); (2) the WTRU may be configured by a higher layer to perform periodic assisting transmissions; or (3) the measured CBR exceeds a (pre-configured) threshold.

[0097] According to the embodiment, a WTRU support transmission may be performed in accordance with (e.g., triggered, based on, etc.) an indication of a change in resource reservation. According to the embodiment, a WTRU may perform a support transmission and determine to become a supporting WTRU if it receives an indication from a supported WTRU of a change (e.g., implicit, explicit, etc.) in the resource reservation of one or any number of SL processes (or more) (e.g., one, any number, etc.). According to the embodiment, a supported WTRU may perform (e.g., be required to perform) a resource (re)selection of one or any number of SL processes (or more) (e.g., one, any number, etc.) in accordance with either (1) the resource (re)selection counter of the sidelink process reaching zero, or (2) the WTRU's traffic pattern changing, including a change in periodicity, offset, TB size, and packet size. For example, a supported WTRU may have one set of resources semi-permanently reserved for one sidelink process. According to the embodiment, in such a case, the supporting WTRU may trigger a supporting transmission when transmissions (e.g., any number) within the reserved resource do not indicate further semi-persistent reservations for the resource set. According to the embodiment, such indications (e.g., information contained in transmissions within the reserved resource) may be communicated using either SCI, MAC CE, or RRC.

[0098] According to one embodiment, a WTRU support transmission may be performed (e.g., triggered) if data associated with the supported WTRU is available. According to another embodiment, a supporting WTRU may trigger a support transmission to one supported WTRU, for example, only if data associated with the supported WTRU is available. In such a case, the WTRU does not need to construct a TB containing only support information.

[0099] According to the embodiment, for example, a periodic support transmission transmitted by a WTRU may be configured for (e.g., associated with) any of the following: an application (e.g., a group of applications, a V2X application, etc.), a WTRU group, and a data group. According to the embodiment, a WTRU may be (pre-configured) to perform a periodic support transmission. According to the embodiment, a periodic support transmission may be either (1) a semi-persistent broadcast transmission, or (2) a group cast transmission for any of the associated V2X applications, V2X data groups, V2XWTRU groups, etc. According to the embodiment, a vehicle WTRU (VWTRU) may be (pre-configured) by a higher layer to perform a periodic support transmission (e.g., transmit, transmit, etc.) that provides, for example, available resource information (e.g., by including information indicating ). According to the embodiment, a periodic support transmission may be transmitted (e.g., provide, transmit, guide, etc.) by the VWTRU to any number of V2X WTRUs adjacent to (e.g., the VWTRU). According to embodiments, a WTRU adjacent to (e.g., VWTRU) (e.g., V2X) may be and / or include any of the WTRUs discussed below. However, this disclosure is not limited thereto, and any type of WTRU suitable for the operation and features described herein may be a WTRU adjacent to a VWTRU.

[0100] According to the embodiment, a nearby WTRU may be either a PWTRU or a VRU that transitions from an inactive / sleep state to an active / awake state, for example, to initiate SL transmission. If such a PWTRU / VRU does not need to perform sensing during the inactive / sleep period, it may not have the information necessary for resource selection for SL transmission under the active / awake state (e.g., used, requested, etc.). According to the embodiment, for example, in such a case, either the PWTRU or VRU may perform resource selection according to (e.g., based on) received support resource information, i.e., until sensing information becomes available.

[0101] According to the embodiment, a nearby WTRU may be either a PWTRU and a VRU (e.g., a device) having (e.g., associated with) battery constraints (e.g., low available battery amount, high battery energy consumption rate). According to the embodiment, either the PWTRU and the VRU device may be (pre-configured) not to perform sensing if the battery level falls below a (pre-configured) threshold. According to the embodiment, in such a case, either the PWTRU or the VRU may perform resource selection for SL transmission (e.g., based on (e.g., received) support resource information). According to the embodiment, a nearby WTRU may be a group of any number of WTRUs in a group transmission (e.g., a group of V2X WTRUs) configured (pre-configured) to share either sensing information and resource selection information among group members (e.g., WTRUs). For example, according to the embodiment, (e.g., one) group member WTRU may perform sensing and resource selection and transmit (e.g., resulting and / or other) support resource information to other member WTRUs.

[0102] According to the embodiment, the WTRU may be (pre-configured) with any number of periods for support transmissions, for example, according to any number of resource pools (each, for each, etc.). For example, according to the embodiment, the periods for support transmissions may follow (for example, can be determined, can be configured, etc.) a per-slot bitmap, e.g., a length (pre-configured) for each SL resource pool, (for example, can be determined, can be configured, etc.). According to the embodiment, the WTRU may be (pre-configured) with a set of support transmission windows, e.g., a set of consecutive support transmission windows in a resource pool. According to the embodiment, the support-side WTRU may perform support transmissions in any (e.g., each) configured period and / or within any (e.g., each) support transmission window.

[0103] According to the embodiment, the support WTRU may randomly select timing instances for support transmissions within a support transmission period and / or window. According to the embodiment, the support WTRU may perform support transmissions according to an offset, such as an offset (e.g., slot, window, frame, time, etc.) from the start of a support transmission period and / or window. For example, the offset may be a zero slot, which is the start of a support transmission period and / or window. According to the embodiment, the offset may be configured (in advance) according to a resource pool (e.g., based on, per, etc.).

[0104] According to the embodiment, the period of support transmissions may be associated with any of the following: V2X data groups, WTRU groups, QoS requirements associated with support resource information, and CBR. According to the embodiment, for example, a small period may be applied when there are low latency requirements for V2X data transmissions. According to the embodiment, a supporting WTRU may reduce the period of support transmissions (e.g., increase the number of support transmissions) when the CBR (e.g., measured, determined, etc.) falls below a (pre-configured) threshold. According to the embodiment, in such a case, for example, more support information (e.g., more available) may be available for the supported WTRU without increasing channel congestion.

[0105] According to the embodiment, the supporting WTRU may indicate the period of the supporting transmission. For example, according to the embodiment, the supporting WTRU may transmit information indicating the period of the supporting transmission in the reserved period indicator bit field within the SCI of the supporting transmission. According to the embodiment, the supported WTRU may, for example, determine, based on the reserved period indicator bit field, any of the V2X application(s), V2X data group(s), and QoS requirements associated with the supporting resource set information carried in the supporting transmission. According to the embodiment, in such a case, the supported WTRU may, according to the reserved period indicator bit field (for example, based on, as shown, etc.), select resources from the supporting resource set for the SL transmission for any of the V2X application(s), V2X data group(s), and its SL TB QoS requirements.

[0106] Figure 5 shows a support transmission that provides resource set information according to an embodiment.

[0107] According to the embodiment, for example, referring to Figure 5, a support transmission (e.g., transmitted by a WTRU) may provide resource set information to (e.g., other) WTRUs in proximity (e.g., a specific one). According to the embodiment, a support WTRU may perform sensing to select candidate resources to be included in the support resource set. According to the embodiment, candidate support resources in the support resource set may be single-slot support resources spanning (e.g., a reference) number of subchannels. According to the embodiment, a support WTRU may determine any of the following sensing parameters: (1) resource pool; (2) sensing window 501 length; (3) reference transmission window 502 length; (4) reference number of subchannels; (5) reference RSRP threshold; and (6) minimum number of resources (e.g., required, requested, etc.) for the resource set.

[0108] According to the embodiment, for example, if the resource pool is a sensing parameter, the resource pool of the support resource set may be the same as the one used for support transmission. According to the embodiment, the resource pool for support resource information (e.g., used, associated, etc.) may be configured (in advance) for any of the following: V2X application, data group, WTRU group, etc. According to the embodiment, for example, the resource pool used for either a V2X WTRU during a DRX transition period or a WTRU with battery constraints may be dedicated to such a WTRU group (e.g., V2X WTRU during a DRX transition period and WTRU with battery constraints) or configured (in advance). According to the embodiment, for example, in the case of the sensing window 501 length (e.g., sensing window 501 length as a sensing parameter), the sensing window length may be any value (e.g., indicated by any value), such as a time value (e.g., 100ms, 1000ms, etc.). According to the embodiment, for example, in the case of the length of the reference transmit window 502 (e.g., the length of the reference transmit window 502 as a sensing parameter), the reference transmit window length can be any value, such as a time value (e.g., 10ms, 20ms, 100ms, etc.) (e.g., indicated by any value). According to the embodiment, such a length (e.g., a parameter of the reference transmit window, a value, etc.) can be associated with (e.g., depend on) any of the V2X data group, WTRU group, and QoS requirements supported by the support resource information. For example, a low-latency V2X data group may use a small transmit window.

[0109] According to the embodiment, for example, in the case of a criterion number of subchannels as a sensing parameter, the criterion number of subchannels may be a (pre-configured) value including, for example, 1, 2, 4, etc. According to the embodiment, the WTRU may select a criterion number of subchannels according to, for example, a V2X data group, a WTRU group, and QoS requirements of the support resource information. For example, the WTRU may select a small criterion number of subchannels for either a V2X data group or a WTRU group using a periodic small packet size. According to the embodiment, for example, in the case of a criterion RSRP threshold as a sensing parameter, it may be, for example, a measured RSRP value used to determine whether a resource can be included in a support resource set. According to the embodiment, the criterion RSRP threshold may be based on a measured RSRP, the L1 priority decoded within the resource, and the criterion TX priority.

[0110] According to the embodiment, the reference TX priority may be configured (in advance) and associated with any of the V2X data groups, WTRU groups, and QoS needs (e.g., requirements) of the support resource information. According to the embodiment, for example, the sensing parameter may be the minimum number of resources needed (e.g., used, requested, requested, etc.) in the resource set. According to the embodiment, the minimum number of resources may be given (e.g., named) as X%, where X is the ratio (e.g., 20%, 35%, 50%, etc.) of (1) the number of resources requested in the support resource set and (2) the total number of candidate resources in the reference transmit window, determined (e.g., based on any of the V2X data groups, WTRU groups, and QoS requirements associated with the support resource set information. For example, according to one embodiment, the WTRU may include more candidate resources (e.g., 50% of the support resource set) for either, for example, high-reliability V2X data transmission and / or VRU.

[0111] According to the embodiment, the support WTRU determines (e.g., selects) a set of candidate resources selected according to the sensing result (e.g., obtained from the sensing result), and may include such a set in, for example, the support transmission 504. According to the embodiment, the support WTRU may include any number of sensing parameters in the support information, such as any of the sensing parameters described above. According to the embodiment, the support WTRU may indicate an index of a reference sensing configuration applied to the candidate resource set (e.g., it may send a message indicating the index). For example, according to the embodiment, the reference sensing configuration may be configured (in advance) for either the support WTRU or the supported WTRU. According to the embodiment, the support WTRU may include an indication of the SCI (e.g., transmit, transmit, etc.) to indicate that the data carried by the PSSCH may be support information, for example, a set of support resources and associated parameters.

[0112] According to the embodiment, the supported WTRU may determine a reference sensing parameter according to (for example, based on) either a sensing configuration indication and a set of sensing parameters included in the support transmission. According to the embodiment, the reference transmit window associated with the support resource set information may be the slot from which the support transmission is received. According to the embodiment, the start of the reference transmit window may be configured (in advance) using an offset which may be, for example, the number of slots (for example, with respect to) from the slot from which the support transmission is received. According to the embodiment, the supported WTRU may calculate the transmit window associated with the received support resource set and determine a subset of the received support resources (for example, of the set) that may be used for (for example, its) SL transmission, based, for example, the purple window of the actual transmit window 503 of the WTRU shown in Figure 4. According to the embodiment, the actual transmit window 503 may be determined according to (for example, based on) the packet delay budget (PDB) of the transmitted TB.

[0113] According to the embodiment, the supporting WTRU may include a priority value associated with each supporting resource in the supporting resource set information. According to the embodiment, the supported WTRU may calculate a relative RSRP threshold for each supporting resource according to, for example, the receiving priority associated with each resource and the priority associated with the supported WTRU's actual SL transmitter 505. According to the embodiment, the supported WTRU may determine a subset of supporting resources that have an RSRP value lower than the (e.g., calculated) relative RSRP threshold. According to the embodiment, the supported WTRU may, for example, select a resource (e.g., randomly) from the determined subset of supporting resources for the (e.g., actual) SL transmitter 505. According to the embodiment, the supported WTRU may, for example, perform sensing regarding / for received supporting resources for resource selection by the (e.g., actual) SL transmitter 505.

[0114] According to the embodiment, the supported WTRU may receive and / or apply a support resource set transmission for a first SL transmission, for example, when the supported WTRU transitions to an active / wake state or begins performing sensing. According to the embodiment, the supported WTRU may stop receiving support transmissions(s) if, for example, sensing information is available for resource selection (e.g., becomes available), i.e., when the supported WTRU can accumulate sensing data within or for a complete sensing window.

[0115] According to the embodiment, a WTRU may determine not to perform an assist transmission in the event of a trigger (e.g., triggering) condition (e.g., occurrence). According to the embodiment, a WTRU may determine not to perform a triggered assist transmission in any of the following cases: (1) the WTRUTX-RX distance is greater than the threshold configured for the resource pool for inter-WTRU assist; (2) the WTRU battery level is less than the threshold configured for WTRU assist; (3) the measured CBR is higher than the threshold configured for WTRU assist; or (4) the WTRU receives such a triggered assist transmission from another WTRU.

[0116] UE determination of information within and / or for support transmission According to the embodiment, the WTRU may determine the content contained in the support information (e.g., of a support transmission). According to the embodiment, the support WTRU may provide a set of resources in the support transmission (e.g., information indicating ). According to the embodiment, the support WTRU may include an indication (e.g., information indicating ) for any number of trigger conditions in the support transmission. According to the embodiment, such an indication (e.g., information indicating ) may be any of a collision detection indication, a high CBR indication, a range indication, and a consecutive TB decoding failure indication. According to the embodiment, for X trigger conditions, the number of bits used (e.g., required for ) in this indication may be [log2X].

[0117] According to the embodiment, the support WTRU may transmit any of the following (e.g., information) in the support transmission (e.g., together with): (1) congestion control information; (2) resource pool display; (3) CSI associated with the support resource; (4) signal measurement associated with the support resource; (5) interference measurement associated with the support resource; (6) grant-free resource display; and (7) speed and / or location of the support WTRU. According to the embodiment, when providing congestion control information (e.g., CBR information), the WTRU may include a CBR measurement in the support transmission (e.g., based on either zone ID information and CBR value). For example, according to the embodiment, the WTRU may transmit CBR information if either a zone ID change or a measured CBR value exceeds a (pre-configured) threshold.

[0118] According to the embodiment, in the case of a resource pool display, the WTRU may include an index of the resource pool(s) that may be used (e.g., used) by the supported WTRU in the support transmission. According to the embodiment, in the case of a CSI associated with a provided support resource (e.g., a subchannel-based CSI report), the WTRU may include a CSI report associated with a support resource provided to another WTRU. According to the embodiment, in the case of a signal measurement of a support resource, it may be an RSRP value for any or each support resource. According to the embodiment, in the case of an interference measurement of a support resource, it may be an RSSI value for any or each support resource. According to the embodiment, when indicating grant-free resources, the WTRU may indicate the type of support resource set provided. For example, according to the embodiment, the WTRU may indicate that the support resource can be used in a grant-free manner (e.g., without resource reservation).

[0119] According to the embodiment, the support information may include a representation of resource reservations associated with the support transmission (e.g., resource reservations that may be reselected according to the support information of the supported WTRU and / or by the supported WTRU). According to the embodiment, for example, such a representation may include any of the following: L1 destination ID and / or L1 source ID, L2 destination and / or L2 source ID, and link ID.

[0120] According to the embodiment, for example, as described above, the supporting WTRU may include information (e.g., associated) about a transmission window associated with a resource set carried in a supporting transmission, for example, such information may include either T1 or T2. According to the embodiment, either the T1 or T2 value (e.g., in a slot) may be for a supporting transmission. According to the embodiment, such T1 and / or T2 values ​​can provide a reference timing to the supported WTRU, for example, to interpret the resource set (e.g., correctly).

[0121] According to the embodiment, any number of support transmission types may exist. According to the embodiment, the support-side WTRU may perform support transmissions according to (e.g., based on) either an SL channel and / or signaling. For example, according to the embodiment, the support-side WTRU may perform support transmissions according to (e.g., based on) any of the following SL channels and / or signalings (e.g., via channels): PSCCH (e.g., standalone PSCCH); PSFCH; physical SL collision indicator channel; PSSCH (e.g., MAC CE signaling, RRC signaling, etc.), and physical SL support indicator channel.

[0122] According to the embodiment, support information transmission may be performed via (e.g., a new) physical SL support display channel (e.g., using, over, through, within, etc.). According to the embodiment, the WTRU may transmit support information within a new SL PHY channel, such as a physical SL support display channel. According to the embodiment, such (e.g., a new) channel may have any number (e.g., types) of (e.g., different) displays (e.g., support displays) (e.g., consisting of, equipped with, utilized, associated with, etc.). According to the embodiment, such displays(plural) may be determined according to either (1) support request transmission and configuration (e.g., pre-configuration) of each resource pool (e.g., per). According to the embodiment, the support displays may be any of (1) collision displays, (2) half-duplex displays, (3) PSFCH transmission displays, and (4) UL transmission displays (e.g., and / or may include them).

[0123] According to the embodiment, a collision indicator may indicate the detection of a collision with an SP-based resource reservation (e.g., a detected collision) detected by a WTRU to which the support information is directed. For example, according to the embodiment, the indicator may be 1 bit and may be transmitted within the resource associated with the reserved resource between the collision detection and the next transmission instance of the resource reservation. According to the embodiment, a supported WTRU receiving such information (e.g., a collision indicator) may trigger either preemption or resource reselection. According to the embodiment, a half-duplex indicator may indicate an incoming SL transmission, for example, an unreceived slot(s). According to the embodiment, a half-duplex indicator may include a bit field for conveying the index of the slot(s) of the unreceived slot(s). According to the embodiment, upon receiving a half-duplex indicator, a supported WTRU may avoid an SL transmission in the slot(s) associated with the half-duplex indicator (e.g., within / indicated by the indicator).

[0124] According to the embodiment, a PSFCH transmission indicator may indicate an incoming PSFCH transmission. According to the embodiment, a PSFCH transmission indicator may include a bit field to indicate, for example, whether the PSFCH transmission is reserved in the nearest PSFCH slot in the resource pool. According to the embodiment, a PSFCH indicator may include the PSFCH slot index for all reserved PSFCH transmissions. According to the embodiment, upon receiving such a PSFCH transmission indicator, the supported WTRU may avoid transmitting a PSSCH in any slot (e.g., any slot) that could result in a PSFCH transmission in the indicated slot(s). In such a case, according to the embodiment, the supporting WTRU may avoid a PSFCH loss caused, for example, by multiple PSFCH transmissions in one slot. According to the embodiment, a UL transmission indicator may indicate an incoming UL transmission. According to the embodiment, a UL transmission indicator may include a bit field to indicate, for example, the slot in which the UL transmission is scheduled. According to the embodiment, upon receiving a UL transmission indicator, the supported WTRU may avoid transmitting a PSSCH in any indicated slot(s). In such cases, according to the embodiment, the supporting WTRU can avoid interference within the WTRU, for example, interference from UL transmission to SL reception (affecting, etc.).

[0125] According to the embodiment, the WTRU may determine (e.g., select) resources for (e.g., associated with) an assisting transmission. According to the embodiment, the WTRU may consist of (e.g., be pre-configured) resource allocations for (e.g., dedicated, only, in particular, etc.) an assisting information transmission that may occur (e.g., transmitted) on either the PSSCH or a new PHY display channel (e.g., via, using, etc.). According to the embodiment, (e.g., such) resource allocations may be either a resource pool and a set of time and frequency resources allocated within the resource pool. According to the embodiment, such resources may not be used for, or by, any other V2X data transmissions. According to the embodiment, such time and / or frequency resources (e.g., a set) may be any of a set of SL slots, a set of SL symbols, a set of subchannels, a set of PRBs, and a set of subcarriers (e.g., consisting of, comprising, including, having, etc.). According to the embodiment, such time and / or frequency resources may be configured as a separate area within / of a resource pool (e.g., pre-configured) configured for SL transmissions.

[0126] According to the embodiment, a WTRU may determine (e.g., select) resources for an assisting transmission according to a PSSCH transmission associated with the supported WTRU. For example, according to the embodiment, a WTRU may determine (e.g., select) resources for an initial assisting display transmission according to resources used for a PSSCH transmission associated with display information (e.g., the display information described above). According to the embodiment, for example, a display channel having a collision display (e.g., equipped with, including, etc.) may use resources associated with the resources of a PSSCH transmission in which a collision is detected. According to the embodiment, resources for a PSSCH transmission may be reserved via a semi-persistent reservation (e.g., using, within, by, etc.). According to the embodiment, such association of resources (e.g., such related resources) may be determined according to any of the following: (1) the starting subchannel and / or PRB index of the PSSCH transmission; (2) the index of the slot of the PSSCH transmission; (3) the WTRU source ID and / or destination ID of the supported WTRU; (4) the SLID of the SL link to which the support information is subject; and (5) the total resources configured (e.g., pre-configured) for the support transmission.

[0127] According to the embodiment, the support WTRU may determine the frequency resources for the initial support display transmission within either the subchannel and PRB used for the PSSCH transmission. For example, according to the embodiment, the display channel may use either the subchannel and the lowest index PRB of the PSSCH transmission. According to the embodiment, either the subchannel or PRB may be selected according to a module function of either the WTRU ID (e.g., in decimal format), the SL ID, and the total number of subchannels and / or PRBs used for the PSSCH transmission (e.g., performed with / above). According to the embodiment, the mapping of PSSCH subchannels and / or PRBs (e.g., between, etc.) may consist of dedicated frequency resources for the support display channel. According to the embodiment, the WTRU may determine the set of subchannels and / or PRBs according to either the slot index and the starting subchannel and PRB index of the PSSCH transmission. According to the embodiment, the WTRU may select either the subchannel and / or PRB from the set of subchannels and / or PRBs according to either the WTRU source / destination ID and the SL ID. According to one embodiment, the WTRU can determine a PSFCH resource in accordance with a PSSCH transmission (for example, as specified in accordance with the 3GPP standard) and transmit an initial support display channel within the determined PSFCH resource.

[0128] According to the embodiment, a WTRU may determine resources for an assistance transmission according to associations between resources used for assistance requests and corresponding information transmissions. According to the embodiment, a WTRU may perform an assistance transmission (e.g., carry, indicate, etc.) containing the requested information when the WTRU receives an assistance request transmission. According to the embodiment, a WTRU may determine resources used for an assistance information transmission according to configured associations (e.g., using) of resources in the received corresponding assistance request. According to the embodiment, such configured (e.g., pre-configured) associations may be indicated, for example, explicitly or implicitly (e.g., as discussed below).

[0129] According to the embodiment, there may be an explicit association between the resources for support requests and information transmissions. According to the embodiment, the WTRU may explicitly indicate an SL resource allocation reserved for support information transmission within an SL PHY control channel, such as an SL PHY support request channel. According to the embodiment, SL control information (SCI) may be carried in the support request channel and may include any of the following information: (1) support request indication; (2) time and / or frequency resources allocated for the corresponding support information transmission; and (3) either the source ID or destination ID of the SL link to which the support request applies.

[0130] According to the embodiment, the support request indicator may indicate (for example, communicate) either the type of support information requested or the content of the support information requested. For example, according to the embodiment, the WTRU may request support information including any of the following: collision indicator, CSI, sensing result, intermediate sensing result, etc. According to the embodiment, each code point in the SCI bit field may correspond to either the configured type of the requested support information or the content of the support information requested.

[0131] According to the embodiment, in the case of time and / or frequency resources allocated to the corresponding support information transmission, the allocation (e.g., time and / or frequency resources) may include multiple resources for either initial transmission and retransmission. For example, according to the embodiment, the time gap (e.g., with respect to) of the slot may be applied to indicate the time resources associated with the slot on which the requested channel is transmitted (e.g., by reference to, for, etc.). According to the embodiment, an index of either the subchannel or PRB may be indicated for the frequency resource allocation. According to the embodiment, in the case of support information parameters, the WTRU may provide sensing parameters (e.g., as described above). According to the embodiment, the WTRU may indicate either the buffer status and packet size to which the support information pertains.

[0132] According to the embodiment, there may be an implicit association between the resources for the support request and the support information transmission. According to the embodiment, the WTRU may perform a support request transmission, including (e.g., without) a resource allocation for the corresponding support information transmission. According to the embodiment, the WTRU may transmit a support request via the SL PHY support request channel (e.g., using, within, on, etc.) according to a PHY signal (e.g., a ZC-based sequence). According to the embodiment, the WTRU may transmit a support request within the SL PHY support request channel, including a set of bit fields (e.g., as described above), without (e.g., without) a resource allocation for the corresponding support information transmission.

[0133] According to the embodiment, the support-side WTRU may determine the SL slots for initial support information transmission according to a timing offset (e.g., the number of slots) between the support request and the corresponding information transmission. According to the embodiment, the timing offset may be configured for each type and / or content of the support information (e.g., it may be pre-configured). For example, a collision indication may consist of a time gap smaller than the available resource set. According to the embodiment, the timing offset (e.g., the time gap) may be configured as a fixed value, such as the number of slots that allow the support-side WTRU sufficient time to generate the support information. According to the embodiment, the support-side WTRU may determine the frequency resources for initial support information transmission according to any of the following parameters: (1) the index of either the subchannel and PRB on which the support request is received; (2) the type of support information indicated in the support request transmission; (3) either the source ID and destination ID of the SL link to which the support information applies; (4) the link ID of the SL link to which the support information applies; and (5) the total resources configured for the support transmission.

[0134] According to the embodiment, the support WTRU may select one of the subchannels and PRBs for the support transmission according to a configured (e.g., pre-configured) association between (1) one of the subchannels and PRBs used for the request transmission and (2) the corresponding support transmission. According to the embodiment, such association (e.g., between (1) and (2)) may be a one-to-one mapping between the subchannels and / or PRBs used for both transmissions. For example, according to the embodiment, the WTRU may select one of the same subchannels and the same PRBs used for the support request transmission of the corresponding information transmission. According to the embodiment, the WTRU may select (e.g., determine) a subchannel that may contain the PRB used for the associated request transmission. According to the embodiment, the support WTRU may perform retransmission of support information according to a configured (e.g., pre-configured) pattern. According to the embodiment, such a pattern may be a sequence of time and / or frequency resources (e.g., include, consist of, have, equip, etc.) with reference to the determined resources of the initial transmission.

[0135] According to the embodiment, the WTRU may determine the assistance information. According to the embodiment, the assistance WTRU may determine the set of resources of the assistance information (e.g., included in, shown in, etc.) according to one of sensing and resource selection, CSI measurement, and collision detection. According to the embodiment, the assistance WTRU may perform sensing and resource selection (e.g., two, any number, etc.). According to the embodiment, the two sensing and resource selections may include sensing and resource selection for determining the resources used for assistance transmission, and sensing and resource selection for determining the set of resources for reporting in assistance transmission.

[0136] According to the embodiment, sensing and resource selection may be for determining the resources to be used for support transmission (for example, they may be used by a WTRU). According to the embodiment, a support-side WTRU may perform resource selection for support transmission according to sensing. According to the embodiment, a support-side WTRU may apply sensing parameters. According to the embodiment, the sensing parameters of a support-side WTRU (for example, applied by a WTRU) may be a resource pool from which resources are reported. For example, a support-side WTRU may select resources from a resource pool dedicated to support transmission.

[0137] According to the embodiment, the sensing parameter of the support WTRU (e.g., applied by it) may be the L1 priority. According to the embodiment, the L1 priority of the support transmission may be configured (in advance). For example, the L1 priority may be set to the highest priority. According to the embodiment, the L1 priority of the support transmission may be the same as the L1 priority of the TB carried in the same transmission. According to the embodiment, the sensing parameter of the support WTRU (e.g., applied by it) may be the remaining PDB. According to the embodiment, the remaining PDB of the support transmission may be configured (in advance). For example, either a fixed value or a small value may be configured (in advance). According to the embodiment, the support WTRU may determine the waiting time for the support transmission based on the remaining PDB. According to the embodiment, the remaining PDB of the support transmission request may be the same as that of the TB carried in the same transmission. According to the embodiment, the sensing parameter of the support WTRU (e.g., applied by it) may be the number of subchannels used (e.g., to be used) for the support transmission.

[0138] According to the embodiment, the supporting WTRU may determine either T1_assist or T2_assist for an assist transmission request. According to the embodiment, T1_assist may be determined according to (e.g., based on) WTRU processing. According to the embodiment, T2_assist may be determined according to (pre)configuration. That is, according to the embodiment, a fixed value (e.g., a) T2_assist may be (pre)configured for an assist transmission request. According to the embodiment, T2_assist may be determined by the remaining PDB of TB. According to the embodiment, T2_assist may be determined according to the duration of the associated resource reservation. According to the embodiment, the supporting WTRU may select T2_assist such that, for example, the supported WTRU has enough time to receive the assist transmission and reselect resources based on the received assist resource set. According to the embodiment, for example, as shown in Figure 4, when T1_TB is applied to the sensing of a resource set, the supporting WTRU may set T2_assist before T1_TB-Toffset.

[0139] According to the embodiment, sensing and resource selection may be performed to determine, for example, the set of resources to report in the support transmission. According to the embodiment, the supporting WTRU may determine any number of sensing parameters. According to the embodiment, the supporting WTRU may determine the sensing parameters according to any of the following: (1) the (previous) configuration (e.g., specific to) the resource pool; (2) the L1 priority indicated in the (e.g., previous) transmission received from the supported WTRU; (3) the number of subchannels in the (e.g., previous) transmission received from the supported WTRU; (4) the (e.g., received, used) RRC configuration during link establishment from the supported WTRU; and (5) the parameters included in the support request received from the supported WTRU. According to the embodiment, the supporting WTRU may determine the sensing parameters according to the content of the received support transmission request, for example, as described above.

[0140] According to one embodiment, the supporting WTRU may determine sensing parameters according to a transmission (e.g., a previous one) received from the supported WTRU. For example, according to one embodiment, the supporting WTRU may apply either the number of subchannels and the L1 priority of the previous transmission.

[0141] According to the embodiment, the support resources of the support resource set (e.g., resources used / indicated by them) may be determined, for example, by the WTRU. According to the embodiment, the support resources may include a set of available resources that may be determined, for example, by a sensing procedure. For example, according to the embodiment, the support WTRU may provide a set of support resources according to (e.g., from, based on, etc.) set A which is determined (e.g., as a result of) the sensing procedure. According to the embodiment, in such a case, each support resource may be a candidate resource designated for the sensing procedure. According to the embodiment, the support resource (e.g., a candidate resource) may be a time / frequency resource occupying a single slot and any set of (e.g., specific, several) consecutive subchannels used for sensing contained in the corresponding resource pool and the associated transmit window (e.g., for that purpose).

[0142] According to the embodiment, the support resources may include a set of resources unavailable for transmission. For example, according to the embodiment, a peer WTRU in either unicast or groupcast may indicate a set of slots unavailable to the supported WTRU (e.g., a set of slots that the peer WTRU could use, request, need, reserve, and perform a transmission on). According to the embodiment, the supported WTRU may avoid (e.g., not select) a transmission resource included in the set of slots indicated by supporting the WTRU.

[0143] According to the embodiment, a WTRU may determine the transmit window associated with a support resource set. According to the embodiment, resources within a support resource set may be indexed according to, for example, candidate resources within the associated transmit window (e.g., total, quantity). According to the embodiment, (for example, when a support resource set is indexed), both the supporting WTRU and the supported WTRU may have the same interpretation of time and frequency resources based on the index of resources within the support resource set (e.g., require, request, etc.). According to the embodiment, for example, in order to have such the same interpretation (e.g., achieve), both the supporting WTRU and the supported WTRU may have the same understanding of the start and end of a transmit window (e.g., should have, shall have, must have, etc.).

[0144] According to the embodiment, the supporting WTRU may receive an explicit indication in the supporting transmission request that includes, for example, either T1_TB or T2_TB. According to the embodiment, either T1_TB or T2_TB may be an absolute frame, a subframe, or a slot number. According to the embodiment, the indicated value may be an offset (e.g., within a slot) to the timing of the supporting transmission request. According to the embodiment, such timing (e.g., such time) may be common to both the supporting WTRU and the supported WTRU and may not (e.g., cannot, do not) create ambiguity when interpreting window start, window end, and resource indexing. According to the embodiment, the supporting WTRU may determine T2_TB from the remaining PDBs included in the supporting transmission request.

[0145] According to the embodiment, the assisting WTRU may determine T1_TB according to any of the following: T2_assistTX (e.g., T2 of the assist transmission); an offset (e.g., a slot) configured (in advance) between T2_assistTX and T1_TB; the timing of the assist transmission; and the timing of the assist transmission request. For example, according to the embodiment, the assisting WTRU may determine T1_TB = T2_assistTX + offset, thereby determining a transmission window of [n + T1_TB, n + T2_TB] (where n may refer to the timing of the assist transmission request (e.g., a slot)). According to the embodiment, the (e.g., (in advance) configured) offset may allow sufficient time for the supported WTRU to receive the assist transmission and perform WTRU processing to perform resource selection based on the received assist transmission (e.g., it shall allow, must allow, should allow, etc.).

[0146] According to the embodiment, a support WTRU may determine a transmit window according to either a reserved transmit timing or a predefined transmit window. For example, according to the embodiment, a support WTRU may perform a support transmit (e.g., including information) that provides a set of resources for the next transmit by a support WTRU in a slot, such as slot X. According to the embodiment, a support WTRU may determine a transmit window according to either a reserved time resource (e.g., slot X), or a (pre-configured) transmit window for a reserved time resource, such as a transmit window that starts from slot X with a (pre-configured) duration (e.g., slot). According to the embodiment, a transmit window may end in slot X with a (pre-configured) duration (e.g., slot).

[0147] According to the embodiment, the above determination and / or (e.g., associated) parameters (e.g., any of the above) may be common to both the supporting WTRU and the supported WTRU so that both WTRUs may have the same understanding of the start and end of the transmit window. According to the embodiment, for example, as a result of having such the same understanding, the supported WTRU may (e.g., correctly) interpret the resources in the resource set provided according to the indexing. According to the embodiment, the supporting WTRU may determine the percentage of resources among the (e.g., total) candidate resources of the transmit (e.g., in the set of resources reported to the supported WTRU). According to the embodiment, the supporting WTRU may determine the percentage of resources among the total candidate resources in the transmit window according to any of the following: (1) (pre) configuration (e.g., the percentage may be fixed at X%, where X may be equal to 20); (2) QoS requirements (e.g., the percentage may be X%, where X is based on L1 priority); (3) indication in the received support transmit request.

[0148] According to the embodiment, a set of (e.g., any) number of support resources may be configured (in advance) to be associated with (e.g., a specific) resource pool. According to the embodiment, such a number (e.g., of a set of support resources) may be included in the RRC configuration (e.g., signaled) during link establishment. According to the embodiment, such a number may be indicated in the support request from the supported WTRU.

[0149] According to the embodiment, a WTRU may determine support information when triggered by a CSI report. According to the embodiment, a support-side WTRU may include CSI information (e.g., either CQI or RI) along with the resource set in a support transmission, for example. According to the embodiment, a support-side WTRU may determine a set of support resources according to the CSI measurement of the resources. According to the embodiment, a support-side WTRU may include support resources whose measured CSI value (e.g., CQI) exceeds a threshold (e.g., a (pre-configured) CQI, etc.). According to the embodiment, a support-side WTRU may receive a CQI threshold in a support request from a supported-side WTRU. According to the embodiment, (e.g., in addition to the above features) a set of resources whose measured CQI exceeds, for example, the average CQI value or the median CQI value obtained across all measured resources in the determined transmission window. According to the embodiment, if the size of the support resource set is fixed, a support-side WTRU may include, for example, the specific support resource with the highest measured CQI value.

[0150] According to the embodiment, the WTRU may determine support information in either the case of collision detection or HARQ NACK. According to the embodiment, the WTRU may include collision information in the PSFCH transmission when HARQ is enabled for the transmission(s) corresponding to the resource reservation in which a collision is detected. According to the embodiment, for example, the PSFCH format may include a bit field indicating a collision detected in the PSFCH resource associated with the HARQ ACK / NACK carried in the PSFCH. According to the embodiment, in such a case, the WTRU may transmit either or both of the HARQ ACK / NACK information and the associated collision detection indication to the PSFCH.

[0151] According to the embodiment, the WTRU may transmit a collision indication to an SL PHY channel (e.g., a physical SL collision indication channel) so that the physical SL collision indication channel can carry 1-bit information (e.g., a collision indication). According to the embodiment, the channel may be sequence-based, following (e.g., a (pre-defined) sequence indicating either collision detection and / or non-collision detection. According to the embodiment, such a sequence may follow (e.g., based on) a ZC sequence having two (pre-defined) periodic shifts. According to the embodiment, the resources of the physical SL collision indication channel may (e.g., implicitly) be associated with a PSSCH resource, for example, a PSSCH resource where the indicated collision is detected. According to the embodiment, if the collision indication is based on consecutive collision detections (e.g., as described above), the resources may (e.g., implicitly) be associated with the last PSSCH resource. According to the embodiment, the support WTRU may include a collision detection indication with a resource set in its support transmission, following (e.g., based on) either MAC CE signaling and RRC signaling. According to the embodiment, the WTRU may periodically transmit physical SL collision indication channels. According to the embodiment, the WTRU may transmit physical SL collision indication channels triggered by collision detection (for example, as described above).

[0152] According to the embodiment, there may be an indication of a collision with a VRU transmission (e.g., about the collision). According to the embodiment, the WTRU may identify (e.g., detect, determine, sense, etc.) a collision with a VRU transmission according to a WTRU type indication (e.g., included, carried, notified, indicated, etc.) in the SCI. For example, according to the embodiment, a WTRU type indication in the SCI may include a value corresponding to a VRU transmission (e.g., information indicating a VRU transmission). According to the embodiment, if the WTRU detects a collision with a VRU transmission, the WTRU may transmit a collision indication that indicates information (e.g., transmitted, notified, included, etc.). According to the embodiment, the collision indication may be included in the PHY control channel, the collision indication may consist of a set of values, at least one of which may indicate a collision with a VRU transmission (e.g., corresponding to and / or associated with the collision indication).

[0153] According to the embodiment, when a supported WTRU receives a collision indication (e.g., such as such), the supported WTRU may decide to perform either preemption or resource reselection, without considering the priority of the colliding transmission. According to the embodiment, performing either preemption or resource reselection may, for example, allow VRU transmissions to be prioritized (e.g., enable VRU prioritization) because, for example, a particular VRU may have hardware (e.g., software, physical, etc.) constraints (e.g., the VRU may not have a receiver) and the VRU may be unable to detect the collision (e.g., cannot) (e.g., as a result of the constraints). According to the embodiment, when a supported WTRU receives a collision indication value (e.g., corresponding, indicating, etc.) associated with a collision with another VRU, the supported WTRU may decide to perform either preemption or resource reselection, for example, according to (e.g., based on) the transmission priority value.

[0154] According to the embodiment, a WTRU may perform operations and / or features when it receives an assistance transmission. According to the embodiment, the assisted WTRU may, for example, select (e.g., determine) any number of assistance messages of any type to be used (e.g., process, etc.) in association with (e.g., any number of) assistance transmissions (e.g., any number of).

[0155] According to the embodiment, a supported WTRU may receive any number of support messages from any number of (e.g., different) WTRUs. According to the embodiment, a supported WTRU may decide to use any number of received support messages (e.g., process them, select resources accordingly). According to the embodiment, a supported WTRU may decide which received support messages to use (e.g., select any number of support messages) according to the source ID of the support message, the destination ID of the support message, and the destination ID of the TB. That is, according to the embodiment, in the case of a single unicast link, a supported WTRU may select support messages from a peer WTRU for unicast transmission with a peer WTRU. According to the embodiment, in the case of group cast transmission, a supported WTRU may select support messages from WTRUs within that group. According to the embodiment, a supported WTRU may decide (e.g., select) which (e.g., any number) received support messages to use according to the timing of the support messages. For example, according to one embodiment, the supported WTRU may use the support message if the time gap between the support message and the arrival of the TB is smaller than a threshold that can be determined, for example, by the TB's PDB.

[0156] According to the embodiment, the supported WTRU may perform resource selection (e.g., select support resources). According to the embodiment, the supported WTRU may select (e.g., support) resources from a set of support resources according to either random selection or a CSI report.

[0157] According to one embodiment, the supported WTRU may receive, for example, information indicating / identifying a set of available resources from the supporting WTRU. According to one embodiment, upon receiving a set of available resources from the supporting WTRU, the supported WTRU may perform sensing to determine the set of available resources (for example, during / after the sensing procedure). According to one embodiment, the supported WTRU may determine the set of available resources according to a combination of the available resources from the sensing procedure and the set of available resources determined according to the support information (e.g., transmitted by signal, indicated, received, etc.). According to one embodiment, the supported WTRU may determine the set of available resources according to the intersection of the set of available resources determined according to its sensing and the set of available resources determined according to the support information.

[0158] According to the embodiment, the supported WTRU may receive, for example, a set of unavailable resources from the supporting WTRU. According to the embodiment, when the supported WTRU receives, for example, a set of unavailable resources, it may exclude all (e.g., indicated, received, etc.) unavailable resources during either the sensing procedure or the resource (re)selection procedure. According to the embodiment, the set of unavailable resources may be determined as a set of transmit slots associated with the supporting WTRU (e.g., used by, etc.). According to the embodiment, the supported WTRU may determine to exclude any of the unavailable resources from the transmission of TBs associated with the supporting WTRU.

[0159] According to the embodiment, the supported WTRU may receive a collision indication from the supporting WTRU. According to the embodiment, a resource collision indication (e.g., received from the supporting WTRU) may indicate a (e.g., potential) collision of any number of (e.g., reserved) resources. According to the embodiment, for example, upon receiving a resource collision indication, the (e.g., supported) WTRU may determine to trigger resource selection / re-selection.

[0160] According to the embodiment, a supported WTRU can receive support information from any number of supporting WTRUs (e.g., multiple, two or more, etc.). According to the embodiment, a WTRU can process the received support information and the WTRU's (e.g., independently) sensing results simultaneously (e.g., together, in parallel) and determine a superset of combined support information. According to the embodiment, a superset of resources (e.g., associated with a superset of combined support information) may be the value of all resources in the transmission window determined by the configured processing time of the SL TB and the PDB (e.g., a specific percentage, X, X%, etc.). According to the embodiment, such a value (e.g., a specific percentage, X) may be configured (e.g., pre-configured) according to each QoS (e.g., each priority, each resource pool, etc.).

[0161] According to the embodiment, the WTRU may determine candidate resource sets according to (e.g., based on) a superset of either available resources or preferred resources. According to the embodiment, such a superset (e.g., of available and / or preferred resources) may be determined according to (e.g., based on) either (1) the number of resource sets containing the support resources, and (2) the average RSRP and L1 priority of the candidate resources included in the support information.

[0162] According to the embodiment, in the case of a superset determined according to the number of resource sets containing support resources, such resource sets may include either the received support resource sets or the resource sets determined by sensing (e.g., set A). According to the embodiment, (e.g., each) support resource set may include, for example, any available resources and preferred resources determined by any (e.g., each) supporting WTRU. According to the embodiment, the supported WTRU may count the number of resource sets containing candidate resources. According to the embodiment, the supported WTRU may rank all resources in descending order according to the count (e.g., based on), and may include a first percentage (e.g., X%) of resources in the superset of candidate resources for TB transmission. According to the embodiment, the superset may include resources that the majority of WTRUs identify as available and / or preferred (e.g., accordingly).

[0163] According to the embodiment, in the case of a superset determined according to either the average RSRP and L1 priority of candidate resources included in the support information, the supported WTRU may process all of the available and preferred resources in all supported resource sets received together with its own perception (e.g., simultaneously). For example, according to the embodiment, the supported WTRU may calculate the average RSRP of candidate resources according to the RSRP reported for the same resource (e.g., based on) and exclude resources that have an average RSRP higher than a certain value (e.g., configured / pre-configured threshold). According to the embodiment, such a value (e.g., threshold) may be configured for each L1 priority pair, so that, for example, the priority of TB is transmitted by the supported UE and the decoded priority is associated with the candidate resource (e.g., the decoded priority in). According to the embodiment, the WTRU may determine (e.g., select, notify, etc.) a candidate resource set according to (e.g., based on) a superset of unavailable resources included in the received supported resource set (e.g., indicated by) and the WTRU's own perception results, such as set A. According to the embodiment, the supported WTRU may exclude any or all of the unavailable resources received from set A.

[0164] According to the embodiment, the supported WTRU may determine whether to perform a resource (re)evaluation (e.g., whether to perform it, whether it is necessary, whether it has requirements, etc.). According to the embodiment, the supported WTRU may determine whether it is necessary to perform a resource (re)evaluation (e.g., or) depending on any of the following: According to the embodiment, the supported WTRU may determine whether to perform a resource (re)evaluation (e.g., whether to perform it, whether it is necessary, whether it has requirements, etc.) depending on either the timing of the support information message or the remaining PDBs of the TB. According to the embodiment, for example, the WTRU may determine not to perform a resource (re)evaluation if, after receiving the support information message, the remaining PDBs of the TB are less than a threshold. According to the embodiment, if the remaining TBs of the PDBs do not exceed a threshold, the supported WTRU may perform a resource (re)evaluation.

[0165] According to the embodiment, the supported WTRU may determine whether to perform a resource (re)evaluation (e.g., whether to perform it, whether it is necessary, whether it has requirements, etc.) based on either the amount of support resources (e.g., the total number of either transmission resources or slots) or the support resource window. For example, according to the embodiment, the supported WTRU may determine not to perform a resource (re)evaluation if either the number of support resources or the support resource window size is smaller than (e.g., their respective) thresholds. According to the embodiment, if such thresholds are not exceeded, the supported WTRU may perform a resource (re)evaluation. According to the embodiment, such an approach for resource (re)evaluation allows the WTRU to have (e.g., sufficient) resources for selection. According to the embodiment, the supported WTRU may determine whether to perform a resource (re)evaluation (e.g., whether to perform it, whether it is necessary, whether it has requirements, etc.) based on either the QoS of the TB or the CBR of the resource pool. For example, according to one embodiment, the supported WTRU may determine that it will perform a resource (re)evaluation of either a high-priority TB or a high-measurement CBR, or it may determine that it will not perform a resource (re)evaluation of either a low-priority TB or a low-measurement CBR.

[0166] According to the embodiment, the supported WTRU may determine, for example, whether to use support information from the supporting WTRU (e.g., whether to use it or not). According to the embodiment, the supported WRTU may determine whether to use support information (e.g., a set of available resources transmitted from the supported WTRU) according to the distance between the supporting WTRU and the supported WTRU. According to the embodiment, the supported WRTU may determine whether to use support information (e.g., a set of available resources transmitted from the supporting WTRU) according to, for example, the received signal strength from the supporting WTRU. According to the embodiment, the supported WRTU may determine whether to use support information (e.g., a set of available resources transmitted from the supporting WTRU) according to the CBR of the resource pool. According to the embodiment, for example, the WTRU may not have to determine whether to use or decode the support information if, for example, the CBR is less than a threshold. According to the embodiment, such a supported WRTU may determine to use support information if the CBR is greater than a threshold. According to the embodiment, the supported WRTU may determine whether to use support information (e.g., a set of available resources sent from the supporting WTRU) according to the TB's QoS. For example, according to the embodiment, the WTRU may determine to use and / or decode the support information if the TB's priority is greater than a threshold, and otherwise determine not to use the support information. According to the embodiment, the supporting WRTU may determine whether to use support information (e.g., a set of available resources sent from the supporting WTRU) according to the timing of receiving the support information.

[0167] According to the embodiment, the supported WTRU may determine either the distance between itself and the supporting WTRU, or the signal strength received from the supporting WTRU. According to the embodiment, the supported WTRU may determine whether to use the support information transmitted from the supporting WTRU, according to the distance between it and the supporting WTRU. For example, according to the embodiment, if the distance between the supporting WTRU and the supported WTRU is less than a threshold (e.g., distance), the supported WTRU may use the support information received from the supporting WTRU; otherwise, the supported WTRU may not use the support information.

[0168] According to the embodiment, the (e.g., distance) threshold may be determined according to any of a variety of method parameters and / or features, such as one or any combination of the following, as discussed below. According to the embodiment, the (e.g., distance) threshold may be determined according to the Minimum Communication Range (MCR) indicated in the support message. For example, according to the embodiment, the support WTRU may indicate the MCR to be used in its support information. According to the embodiment, the supported WTRU may determine the distance threshold (e.g., as) according to the MCR indicated by the support WTRU. According to the embodiment, the (e.g., distance) threshold may be determined by the QoS of the TB. For example, according to the embodiment, the WTRU may consist of a mapping between the TB's (e.g., any number) distance thresholds and (e.g., any number) priorities. According to the embodiment, such a WTRU may then determine the distance threshold (e.g., matching) of the TB's QoS (e.g., any of the TB's priority, delay, and / or reliability). According to the embodiment, the (e.g., distance) threshold may be determined according to the CBR of the resource pool. For example, according to one embodiment, the WTRU may consist of a mapping between (e.g., any, each) CBR range and (e.g., one, any, each) distance thresholds. According to one embodiment, such a WTRU may then determine the distance thresholds according to the measured CBR of the resource pool.

[0169] According to the embodiment, a WTRU may determine, for example, the received signal strength of a signal received from a supporting WTRU. According to the embodiment, a supported WTRU may determine (for example, whether to use) the support information according to the received signal strength (for example, either RSSI or RSRP) of a message (for example, a signal) associated with the support information. For example, according to the embodiment, if the received signal strength is less than a threshold, the supported WTRU may use the support information (for example, from the supporting WTRU). Otherwise, if the received signal strength does not exceed a threshold, the supported WTRU does not have to use such support information.

[0170] According to the embodiment, the received signal strength threshold may be determined according to either the transmit power and the minimum received signal strength threshold indicated by the support WTRU. According to the embodiment, the received signal strength threshold may be determined by the QoS of the TB. For example, according to the embodiment, the WTRU may be (pre-configured) with a mapping between the minimum received signal strength threshold (e.g., one, each, arbitrary, etc.) and the priority and reliability values ​​of the TB (e.g., one, each, arbitrary, etc.). According to the embodiment, such a WTRU may (for example, then) determine whether to use the support information (e.g., whether to use it) according to either the transmit TB and its measured received signal strength. According to the embodiment, the received signal strength threshold may be determined according to the CBR of the resource pool. For example, according to the embodiment, the WTRU may consist of a mapping between each CBR range and the received signal strength threshold. According to the embodiment, such a WTRU may (for example, then) determine the received signal strength threshold according to the measured CBR of the resource pool.

[0171] According to one embodiment, the WTRU may determine the transmission time of the support information (for example, for a specific purpose). According to another embodiment, the supported WTRU may determine, for example, whether to decode and / or use the support information according to the transmission time of the support information. For example, according to one embodiment, the supported WTRU may determine whether to decode and not use the support information for a time T (e.g., a period, T-slot, etc.) before transmitting the resource. According to one embodiment, the value of T may be determined according to one of the following: the resource pool (e.g., its (pre)configured) capacity, the WTRU capacity, the QoS of TB, and / or the CBR of the resource pool.

[0172] conclusion While 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 non-temporary 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 software can be used to implement a radio frequency transceiver for use in a UE, WTRU, terminal, base station, RNC, or any host computer.

[0173] Furthermore, the embodiments described above include processing platforms, computing systems, controllers, and other devices including constrained servers and processors. These devices may include at least one central processing unit ("CPU") and memory. According to the convention of those skilled in the art in the field of computer programming, references to operations and symbolic representations of arithmetic or instructions may be performed by various CPUs and memories. Such operations and arithmetic or instructions may be referred to as "execution," "computer execution," or "CPU execution."

[0174] Those with ordinary art in the art will understand that operations and symbolically represented arithmetic or instructions involve the manipulation of electrical signals by the CPU. The electrical system represents data bits that can cause a resulting transformation or reduction of electrical signals, and maintains these data bits in memory locations of the memory system, thereby reconfiguring or otherwise modifying the CPU's operations and processing of other signals. The memory locations where the data bits are maintained are physical locations having specific electrical, magnetic, optical, or organic properties that correspond to or represent the data bits. It should be understood that exemplary embodiments are not limited to the platforms or CPUs described above, and other platforms and CPUs may support the methods provided.

[0175] Data bits may also be maintained on computer-readable media, including magnetic disks, optical disks, and any other volatile (e.g., Random Access Memory ("RAM")) or CPU-readable non-volatile (e.g., Read-Only Memory ("ROM")) mass storage systems. The computer-readable media may include cooperative or interconnected computer-readable media distributed among multiple interconnected processing systems, which may reside exclusively on a processing system or be local or remote to the processing system. Typical embodiments are not limited to the memory described above, and it is understood that other platforms and memories may support the methods described.

[0176] In exemplary embodiments, any of the operations, processes, etc., described herein may be implemented as computer-readable instructions stored on a computer-readable medium. These computer-readable instructions may be executed by processors in mobile devices, network elements, and / or any other computing devices.

[0177] There is little distinction between hardware and software implementations of a system configuration. The use of hardware or software is generally (though not always, in certain situations the choice between hardware and software can be significant) a design choice involving a cost-effectiveness trade-off. Various vehicles (e.g., hardware, software, and / or firmware) may exist in which the processes and / or systems and / or other technologies described herein may be effective, and the preferred vehicle may vary depending on the context in which the processes and / or systems and / or other technologies are deployed. For example, if the implementer determines that speed and accuracy are paramount, the implementer may choose primarily hardware and / or firmware vehicles. If flexibility is paramount, the implementer may choose primarily software implementations. Alternatively, the implementer may choose any combination of hardware, software, and / or firmware.

[0178] The detailed description above illustrates various embodiments of devices and / or processes through the use of block diagrams, flowcharts, and / or examples. Those skilled in the art will understand that, insofar as such block diagrams, flowcharts, and / or examples include one or more functions and / or operations, each function and / or operation in such block diagrams, flowcharts, or examples may be implemented individually and / or collectively by a wide range of hardware, software, firmware, or substantially any combination thereof. Suitable processors include, by example, general-purpose processors, dedicated processors, conventional processors, digital signal processors (DSPs), multiple microprocessors, one or more microprocessors associated with a DSP core, controllers, microcontrollers, application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), field-programmable gate array (FPGA) circuits, any other type of integrated circuit (IC), and / or state machines.

[0179] While the features and elements are provided above in specific combinations, it will be understood by those with ordinary art in the art that each feature or element can be used individually or in any combination with other features and elements. This disclosure is not limited in terms of the specific embodiments described in this application, which are intended to be illustrative of various aspects. As will be apparent to those skilled in the art, many modifications and variations can be made without departing from the spirit and scope of the invention. Any elements, actions, or instructions used in the description of this application should not be construed as important or essential to the invention unless expressly presented as such. In addition to those enumerated herein, functionally equivalent methods and apparatus within the scope of this disclosure will be apparent to those skilled in the art from the above description. Such modifications and variations are intended to fall within the scope of the appended claims. This disclosure is limited only by the terms of the appended claims, and together with the full scope of the equivalents to which such claims are entitled. It should be understood that this disclosure is not limited to any particular method or system.

[0180] Furthermore, it should be understood that the terms used herein are intended to describe specific embodiments (e.g., only) and are not intended to limit the invention. Where used herein, “User Equipment” and its abbreviation “UE” may mean (1) a wireless transmit and / or receive unit (WTRU) such as the infrastructure described herein, (2) any of several embodiments of a WTRU such as the infrastructure described herein, (3) a wireless and / or wired (e.g., tetherable) device configured to have some or all of the structure and functions of an exemplary WTRU (e.g., the infrastructure described herein), (4) a wireless and / or wired device configured to have less than all of the structure and functions of a described WTRU (e.g., the infrastructure described herein), or (5) the same. Details of exemplary WTRUs that may represent any WTRU listed herein.

[0181] In certain representative embodiments, some parts of the subject matter described herein may be implemented via application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integrated formats. However, it will be recognized by those skilled in the art that some aspects of the embodiments disclosed herein can be equivalently implemented in an integrated circuit as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or substantially any combination thereof, and that designing circuits and / or writing software and / or firmware code is within the scope of the art of those skilled in the art in light of this disclosure. Furthermore, it will be understood by those skilled in the art that mechanisms of the subject matter described herein may be distributed as various forms of program products, and that exemplary embodiments of the subject matter described herein are applicable regardless of the specific type of signal-carrying medium used to actually carry out the distribution. Examples of signal-carrying media include, but are not limited to, recordable media such as floppy disks, hard disk drives, CDs, DVDs, digital tapes, and computer memory, as well as transmission media such as digital and / or analog communication media (e.g., optical fiber cables, waveguides, wired communication links, wireless communication links, etc.).

[0182] The subject matter described herein may, in some cases, depict different components that are contained within or connected to other different components. Such illustrated architectures are merely examples, and it should be understood that in practice, many other architectures can be implemented to achieve the same function. Conceptually, any arrangement of components to achieve the same function is effectively “associated” in such a way that the desired function can be achieved. Therefore, any two components combined herein to achieve a particular function, regardless of architecture or intermediate components, can be seen as “associated” with each other in such a way that the desired function can be achieved. Similarly, any two components thus associated can be considered “operably connected” or “operably coupled” with each other to achieve the desired function, and any two components that can be associated in such a way can be considered “operably coupled” with each other to achieve the desired function. Specific examples of operably coupled components include, but are not limited to, physically matable and / or physically interacting components, and / or wirelessly interactable and / or wirelessly interacting components, and / or logically interacting and / or logically interactable components.

[0183] With regard to the use of substantially any plural and / or singular terms herein, those skilled in the art can convert from plural to singular and / or singular to plural as appropriate to the context and / or use. For clarity purposes, various singular / plural rearrangements may be explicitly described herein.

[0184] In general, it will be understood by those skilled in the art that the terms used herein, and in particular in the appended claims (e.g., in the body of the appended claims), are generally intended to be “non-limiting” terms (for example, the term “contains” should be interpreted as “contains but not limited to,” the term “has” should be interpreted as “has at least,” and the term “contains” should be interpreted as “contains but not limited to.”). Furthermore, it will be understood by those skilled in the art that if a particular number of claims introduced are intended to be described, such intent is explicitly stated in the claim, and if such statement is not present, such intent does not exist. For example, if only one item is intended, the term “single” or similar word may be used. To aid understanding, the following appended claims and / or descriptions herein may include the use of the introductory phrases “at least one” and “one or more” to introduce the description of a claim. However, the use of such phrases should not be interpreted as meaning that the introduction of a claim description by the indefinite article "a" or "an" limits any particular claim containing such introduced description to embodiments containing only one such description, even if the same claim contains the introductory phrase "one or more" or "at least one" and an indefinite article such as "a" or "an" (for example, "a" and / or "an" should be interpreted as meaning "at least one" or "one or more"). The same applies to the use of the definite article used to introduce a claim description. Furthermore, even if a particular number of descriptions in an introduced claim are explicitly stated, it will be recognized by those skilled in the art that such a statement should be interpreted as meaning at least the number stated (for example, the simple statement "two descriptions" without other modifiers means at least two descriptions or two or more descriptions).Furthermore, when a notation similar to "at least one of A, B, and C" is used, such a structure is generally intended to mean what a person skilled in the art would understand (for example, "a system having at least one of A, B, and C" includes, but is not limited to, systems having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together). When a notation similar to "at least one of A, B, or C" is used, such a structure is generally intended to mean what a person skilled in the art would understand (for example, "a system having at least one of A, B, or C" includes, but is not limited to, systems having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together). It will be further understood by those skilled in the art that any substantially separate word and / or phrase presenting two or more alternative terms in any description, claim, or drawing should be understood as construing the possibility of including one of the terms, either of the terms, or both of the terms. For example, the phrase “A or B” should be understood as including the possibility of “A” or “B” or “A and B.” Furthermore, as used herein, the term “any of” followed by a list of multiple items and / or a list of categories of multiple items is intended to include “any of,” “any combination of,” “any number of,” and / or “any number of combinations of,” of the items and / or categories of items, individually or in combination with other items and / or categories of other items. Furthermore, as used herein, the term “set / group” is intended to include any number of items, including zero. Furthermore, as used herein, the term “number” is intended to include any number, including zero.

[0185] Furthermore, if any feature or aspect of this disclosure is described from the perspective of the Markush group, a person skilled in the art will recognize that this disclosure is also described from the perspective of any individual member or subgroup of a member of the Markush group.

[0186] For all purposes, including providing written explanations, as will be understood by those skilled in the art, all scopes disclosed herein also encompass any possible sub-scopes and combinations of sub-scopes. Any enumerated scope can be readily recognized as sufficiently explainable and enable that the same scope can be broken down into at least equal 1 / 2, 1 / 3, 1 / 4, 1 / 5, 1 / 10, etc. As a non-limiting example, each scope described herein can readily be broken down into the lower third, the middle third, the upper third, etc. Also, as will be understood by those skilled in the art, all words such as “up to,” “at least,” “greater than,” and “less than” include the number mentioned and mean a scope that can be further broken down into sub-scopes as described above. Finally, as will be understood by those skilled in the art, a scope includes individual elements. Thus, for example, a group having 1 to 3 cells refers to a group having 1, 2, or 3 cells. Similarly, a group having 1 to 5 cells refers to a group having 1, 2, 3, 4, or 5 cells, and so on.

[0187] Furthermore, unless otherwise specifically stated, the claims should not be read as being limited to the order or elements provided. Moreover, in any claim, the use of the term “means for” is intended to appeal to Section 112, paragraph 6 of the U.S. Patent Act, or the means-plus-function claim format, and no claim without the term “means for” is intended to appeal in that way.

[0188] A software-related processor may be used to implement a radio frequency transceiver for use in a radio transceiver unit (WTRU), user equipment (UE), terminal, base station, mobility management entity (MME), or evolved packet core (EPC), or any host computer. The WTRU may be used in conjunction with hardware and / or software-implemented modules such as software-defined radio (SDR), and may also be implemented in other components such as cameras, video camera modules, video phones, speakerphones, vibration devices, speakers, microphones, television transceivers, hands-free headsets, keyboards, Bluetooth® modules, frequency modulation (FM) radio units, near-field communication (NFC) modules, LCD display units, organic light-emitting diode (OLED) display units, digital music players, media players, video game player modules, internet browsers, and / or wireless local area network (WLAN) or ultra-wideband (UWB) modules.

[0189] Although the present invention has been described in relation to a communication system, it is intended that the system may be implemented in software on a microprocessor / general-purpose computer (not shown). In certain embodiments, one or more functions of various components may be implemented in software that controls the general-purpose computer.

[0190] Furthermore, while the present invention is illustrated and described herein with reference to specific embodiments, it is not intended to be limited to the details shown. Rather, various modifications can be made in detail within the scope of the claims and their equivalents without departing from the present invention.

Claims

1. A first wireless transceiver unit (WTRU) comprising a processor and memory, The aforementioned processor and memory are Receiving a resource information request from a second WTRU, wherein the resource information request includes an indication of priority associated with a transmission performed by the second WTRU, an indication of the start and end of a time window associated with the transmission performed by the second WTRU, and an indication of the number of subchannels associated with the transmission performed by the second WTRU. Determining one or more sets of resources based on the indicated priority, the start and end times of the time window, and the number of subchannels, wherein the set of one or more resources includes one or more resources that the first WTRU has determined to be available to the second WTRU for the transmission performed by the second WTRU, Determining a support information resource for transmitting support information to the second WTRU, wherein the support information includes an indication of one or more sets of resources. Using the aforementioned support information resources, transmit media access control (MAC) control element (CE) or side link control information (SCI) containing the support information to the second WTRU, Configured to perform, The first WTRU.

2. The support information includes resource type indication, the first WTRU of claim 1.

3. The first WTRU of claim 2, wherein the resource type indicates that one or more resources of the set of one or more resources are preferred resources.

4. The first WTRU according to claim 1, wherein the processor and memory are further configured to determine that one or more resources of the set of one or more resources are available to the second WTRU based on sensing a set of candidate resources.

5. The first WTRU of claim 4, wherein the sensing includes determining an RSRP (reference signal received power) measurement for one or more candidate resources of the set of candidate resources.

6. The sensing includes comparing the RSRP measurement with a threshold, the first WTRU of claim 5.

7. The first WTRU of claim 6, wherein the processor and memory are configured to determine the threshold based on the priority indication included in the resource information request.

8. The priority indication included in the resource information request indicates the Layer 1 (L1) priority associated with the transmission performed by the second WTRU, The aforementioned L1 priority is set to the highest priority. The aforementioned processor and memory are The weighting coefficient is determined based on the L1 priority, Applying the aforementioned weighting coefficient to the RSRP value, Determining the threshold based on the weighting coefficient, The first WTRU of claim 7, configured to further perform the following.

9. A method performed by a first wireless transceiver unit (WTRU), Receiving a resource information request from a second WTRU, wherein the resource information request includes an indication of priority associated with a transmission performed by the second WTRU, an indication of the start and end of a time window associated with the transmission performed by the second WTRU, and an indication of the number of subchannels associated with the transmission performed by the second WTRU. Determining one or more sets of resources based on the indicated priority, the start and end times of the time window, and the number of subchannels, wherein the set of one or more resources includes one or more resources that the first WTRU has determined to be available to the second WTRU for the transmission performed by the second WTRU, Determining a support information resource for transmitting support information to the second WTRU, wherein the support information includes an indication of one or more sets of resources. Using the aforementioned support information resources, transmit media access control (MAC) control element (CE) or side link control information (SCI) containing the support information to the second WTRU, A method that includes this.

10. The method of claim 9, wherein the support information includes resource type indication.

11. The method of claim 10, wherein the resource type indicates that one or more resources of the set of one or more resources are preferred resources.

12. The method of claim 9, further comprising determining that one or more resources of the set of one or more resources are available to the second WTRU based on sensing a set of candidate resources.

13. The method of claim 12, wherein the sensing includes determining an RSRP (reference signal received power) measurement for one or more candidate resources of the set of candidate resources.

14. The method of claim 13, wherein the sensing includes comparing the RSRP measurement with a threshold.

15. The method of claim 14, further comprising determining the threshold based on the priority indication included in the resource information request.

16. The priority indication included in the resource information request indicates the Layer 1 (L1) priority associated with the transmission performed by the second WTRU, The aforementioned L1 priority is set to the highest priority. The aforementioned method, The weighting coefficient is determined based on the L1 priority, Applying the aforementioned weighting coefficient to the RSRP value, Determining the threshold based on the weighting coefficient, The method of claim 15, further comprising the following:

Images