ST Triggering And Recovery For SL MODE-2

Abstract

A wireless transmit / receive unit (WTRU) may receive configuration information indicating that a transmission of a data radio bearer (DRB) associated with a sidelink (SL) transmission may be performed in a regular quality of service state (QoS) or in a limited time-to-live QoS state. The WTRU may start a time-to-live timer based on a determination that transmissions on the channel measurements and / or configured SL resources are discarded based on a channel occupancy rate (CR) above a threshold. The WTRU may transmit at least a first transport block (TB) based on a running time-to-live timer. The first TB includes data of the DRB in the SL in accordance with a transmission parameter corresponding to a restricted survival QoS state. The WTRU may transmit at least a second TB based on expiration of the time-to-live timer.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Provisional Patent Application No. 63 / 489,011, filed on March 8, 2023, the entire contents of which are incorporated herein by reference. Technical Field

[0002] The present disclosure relates to devices, methods, and systems for low-latency Quality of Service (QoS) on a sidelink. Summary of the Invention

[0003] Apparatus, methods, and / or systems for low-latency quality of service (QoS) on a sidelink (SL) are described herein. In one or more examples, a wireless transmit / receive unit (WTRU) may be configured to trigger increased reliability on a sidelink for low-latency services. In one or more embodiments, the WTRU may be configured for sidelink resource selection. In one or more embodiments, the WTRU may be configured for QoS attainment. In one or more embodiments, the WTRU may be configured for listen-before-talk (LBT). In one or more examples, the WTRU may be configured for SL preemption and / or prioritization.

[0004] Devices, methods, and systems are described herein for enabling time-to-live (ST) triggering and recovery for SL Mode-2. For example, a WTRU may be configured with one or more data radio bearers (DRBs) to which ST QoS requirements apply. Additionally, the WTRU may be configured with one or more resource pools for SL transmission Mode-2. The WTRU may trigger the ST state to obtain increased transmission reliability for transmitting the next transport block (TB). The WTRU may trigger the ST state to obtain increased transmission reliability for transmitting the next TB based on making channel measurements above a configured threshold and / or determining that a transmission on a configured SL resource was dropped due to a channel occupancy ratio (CR). The WTRU may determine that the channel measurement is above the configured threshold, for example, but not limited to, when the channel busy rate (CBR) and / or CR is measured above a threshold, the reference signal received power (RSRP) associated with SL control information (SCI) received from other WTRUs is measured above a threshold, and / or the CQI is measured below a threshold. The WTRU may trigger the ST state to obtain increased transmission reliability. Additionally, during the ST state, the WTRU may start an ST timer when the ST state is triggered. During the ST state, the WTRU may adjust the resource selection window so that the next new SL transmission expires within the remaining time of the ST timer. During the ST state, the WTRU may increase the TB priority of TB transmissions on SL resources in the resource selection procedure. During the ST state, for example, if a previous packet failed, the WTRU may bypass CBR and / or CR congestion control. During the ST state, for example, the WTRU may select a different SL resource (or resource pool) based on the measured CR and / or CBR. For example, if the WTRU is within coverage, the WTRU may report a transmission failure or a CBR / CR above a threshold to the gNB (e.g., in a Media Access Control Element (MAC CE), Scheduling Request (SR), and / or on the Physical Uplink Control Channel (PUCCH)). For example, the WTRU may report a negative acknowledgement (NACK).

[0005] A wireless transmit / receive unit (WTRU) may receive configuration information indicating that transmission of a data radio bearer (DRB) associated with a sidelink (SL) transmission may be performed in a normal quality of service (QoS) state and / or in a restricted time-to-live QoS state. The WTRU may start a time-to-live timer, for example, based on channel measurements and / or a determination that a transmission on configured SL resources was discarded due to a channel occupancy (CR) above a threshold. The WTRU may transmit at least a first transport block (TB) based on the running time-to-live timer. The first TB may include data for the DRB in the SL according to transmission parameters corresponding to the restricted time-to-live QoS. The WTRU may transmit at least a second TB based on expiration of the time-to-live timer. The second TB may include data for the DRB in the SL according to transmission parameters corresponding to the normal QoS state.

[0006] The channel measurement may correspond to one or more of: a channel busy rate (CBR) being higher than a threshold, a measured CR being higher than the threshold, a measured reference signal received power (RSRP) associated with received SL control information (SCI) being higher than a second threshold, and / or a measured channel quality indication (CQI) being lower than a third threshold.

[0007] The transmission parameters corresponding to the restricted lifetime QoS may include one or more of the following: an adjusted resource selection window so that the second SL transmission is within the remaining time of the lifetime timer; an increased TB priority; a determination to bypass one or more channel busy rate (CBR) congestion control constraints; a determination to bypass one or more channel occupancy rate (CR) congestion control constraints; and / or a reselected SL resource.

[0008] The WTRU may determine to transmit at least a first TB according to transmission parameters corresponding to a restricted survival QoS state based on a channel measurement being above a threshold and / or dropping transmissions on configured SL resources based on a CR being above a threshold. The at least a second TB may be transmitted in a different resource pool.

[0009] The WTRU may start a time-to-live timer based on a preemption determination. The WTRU may start a time-to-live timer based on a perception-based determination. While the time-to-live timer is running, the WTRU may temporarily disable congestion control and / or CR limiting.

[0010] The WTRU may stop the time-to-live timer based on receipt of an acknowledgement of the first TB and / or the second TB, receipt of an SCI, expiration of the time-to-live timer, receipt of an indication from the network, and / or one or more channel measurements.

[0011] For example, when the WTRU is within coverage, the WTRU may send a report to the network. The report may include an indication of a transmission failure, a CBR above a threshold, and / or a CR above a threshold. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] A more detailed understanding can be obtained from the following description given by way of example with reference to the accompanying drawings in which like reference numerals designate similar elements.

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

[0014] Figure 1B It is a diagram that can be Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use in the illustrated communication system.

[0015] Figure 1C It is a diagram that can be Figure 1A System diagram of an example Radio Access Network (RAN) and an example Core Network (CN) used in the illustrated communication system.

[0016] Figure 1D It is a diagram that can be Figure 1A System diagram of yet another example RAN and yet another example CN used in the illustrated communication system.

[0017] Figure 2 Depicted are example sidelink (SL) Mode 2 operations with time-to-live achievement. DETAILED DESCRIPTION

[0018] Figure 1A The present disclosure is a schematic diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. Communication system 100 may be a multi-access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. Communication system 100 may enable multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, communication system 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique word DFT spread OFDM (ZT UWDTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), and the like.

[0019] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, the RAN 104 / 113, the CN 106 / 115, the public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. However, it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical equipment and applications (e.g., remote surgery), industrial equipment and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated process chain environments), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a WTRU.

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

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

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

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

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

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

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

[0027] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology 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, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0028] For example, Figure 1AThe base station 114b in the example may be a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. Figure 1A As shown, base station 114b may be directly connected to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106 / 115.

[0029] The RAN 104 / 113 may be in communication with the CN 106 / 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 the WTRUs 102a, 102b, 102c, 102d. Data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform advanced security functions, such as user authentication. Although in Figure 1A Although not shown, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0030] The CN 106 / 115 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and / or the Internet Protocol (IP) from the TCP / IP Internet protocol suite. The networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 / 113 or a different RAT.

[0031] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). Figure 1A The WTRU 102c shown in FIG. 1 may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0032] Figure 1B is a system diagram illustrating an example WTRU 102. Figure 1B As shown, 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 appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment.

[0033] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors 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 the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it is understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

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

[0037] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from 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). The processor 118 may also output user data to the speaker / microphone 124, keypad 126, and / or display / touchpad 128. Furthermore, the processor 118 may access information from and store data in any suitable type of memory, such as non-removable memory 130 and / or removable memory 132. The non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from and store data in memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

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

[0039] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over 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 appreciated that the WTRU 102 may acquire location information by any suitable location-determination method while remaining consistent with the embodiments.

[0040] 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, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulation (FM) radio unit, a digital music player, a media player, an electronic game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors, which may include one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor, and the like.

[0041] The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., signals associated with particular subframes used for UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit 139 to reduce and or substantially eliminate self-interference via hardware (e.g., a choke) or via signal processing by a processor (e.g., a separate processor (not shown) or via the processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all signals (e.g., signals associated with particular subframes used for UL (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

[0042] Figure 1C 1 is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As described above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

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

[0044] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, etc. Figure 1C As shown, eNode-Bs 160a, 160b, 160c may communicate with each other over an X2 interface.

[0045] Figure 1C The CN 106 shown in FIG may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements is depicted as part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

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

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

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

[0050] Even though the WTRU Figures 1A-1D Although described as a wireless terminal, it is contemplated that in certain representative embodiments such a terminal may employ (eg, temporarily or permanently) a wired communication interface with a communication network.

[0051] In a representative embodiment, the other network 112 may be a WLAN.

[0052] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may access or interface with a distribution system (DS) or another type of wired / wireless network that transmits traffic to and / or from the BSS. Traffic originating from outside the BSS and destined for a STA can reach through the AP and be delivered to the STA. Traffic originating from a STA to a destination outside the BSS can be sent to the AP for delivery to the corresponding destination. For example, traffic between STAs within a BSS can be sent through the AP, where a source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be transmitted between (e.g., directly between) source and destination STAs using direct link setup (DLS). In certain representative embodiments, DLS may utilize 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using independent BSS (IBSS) mode may not have an AP, and STAs (eg, all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode is sometimes referred to herein as an "ad hoc" communication mode.

[0053] When using 802.11ac infrastructure mode or a similar mode of operation, the AP may transmit beacons on a fixed channel, such as the primary channel. The primary channel may have a fixed width (e.g., a wide 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 STAs to establish connections with the AP. In certain representative embodiments, such as in 802.11 systems, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented. With CSMA / CA, STAs (e.g., each STA), including the AP, may sense the primary channel. If a particular STA senses / detects and / or determines that the primary channel is busy, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0054] High throughput (HT) STAs may communicate using 40 MHz wide channels, for example, via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0055] Very High Throughput (VHT) STAs can support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. 40 MHz and / or 80 MHz channels can be formed by combining contiguous 20 MHz channels. A 160 MHz channel can be formed by combining eight contiguous 20 MHz channels or by combining two non-contiguous 80 MHz channels, which is referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data passes through a segment parser, which separates the data into two streams. Each stream is then subjected to an inverse fast Fourier transform (IFFT) and time-domain processing. These streams are mapped onto two 80 MHz channels, and the data is transmitted by the transmitting STA. At the receiving STA's receiver, the 80+80 configuration operations are reversed, and the combined data is sent to the media access control (MAC).

[0056] 802.11af and 802.11ah support sub-1 GHz operation modes. The channel operating bandwidth and carrier frequencies used in 802.11af and 802.11ah are reduced relative to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to representative embodiments, 802.11ah can support metered-type control / machine-type communications, such as MTC devices in macro coverage areas. MTC devices can have certain capabilities, such as limited capabilities, including support for (e.g., only) certain and / or limited bandwidths. MTC devices can include batteries with battery life exceeding a threshold (e.g., to maintain very long battery life).

[0057] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that can be designated as a primary channel. The bandwidth of the primary channel can be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by one of the STAs operating in the BSS that supports the minimum bandwidth operating mode. In the example of 802.11ah, for a STA that supports (e.g., only) 1 MHz mode (e.g., an MTC-type device), the primary channel can be 1 MHz wide, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (that only supports 1 MHz operating mode) transmitting to the AP, all available frequency bands may be considered busy, even if most of the available frequency bands remain idle and available.

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

[0059] Figure 1D 1 is a system diagram illustrating the RAN 113 and the CN 115 according to one embodiment. As described above, the RAN 113 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.

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

[0061] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may be different for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of varying or scalable lengths (e.g., containing a variable number of OFDM symbols and / or lasting a variable length of absolute time).

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

[0063] Each of the gNBs 180a, 180b, 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, network slicing support, dual connectivity, interworking between NR and E-UTRA, routing user plane data to a user plane function (UPF) 184a, 184b, routing control plane information to an access and mobility management function (AMF) 182a, 182b, etc. Figure 1D As shown, gNBs 180a, 180b, and 180c can communicate with each other on the Xn interface.

[0064] Figure 1DThe illustrated CN 115 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While each of the aforementioned elements is depicted as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0065] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting a specific SMF 183a, 183b, managing registration areas, terminating NAS signaling, mobility management, and the like. The AMF 182a, 182b may use network slicing to customize CN support for the WTRU 102a, 102b, 102c based on the type of service being used by the WTRU 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine-type communication (MTC) access, and / or the like. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0066] The SMF 183a, 183b may connect to the AMF 182a, 182b in the CN 115 via the N11 interface. The SMF 183a, 183b may also connect to the UPF 184a, 184b in the CN 115 via the N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating WTRU IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0067] The UPF 184a, 184b may be connected to one or more gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 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, providing mobility anchoring, etc.

[0068] The CN 115 may facilitate communications with other networks. For example, the CN 115 may include, or may communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 115 and the PSTN 108. Furthermore, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to the local data network (DN) 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and the N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0069] Given that Figures 1A-1D as well as Figures 1A-1D

[0045] As described herein, one or more or all of the functionality described herein with respect to one or more of the following may be performed by one or more emulated devices (not shown): the WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MMEs 162, SGWs 164, PGWs 166, gNBs 180a-c, AMFs 182a-ab, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other device(s) described herein. An emulated device may be one or more devices configured to emulate one or more or all of the functionality described herein. For example, an emulated device may be used to test other devices and / or simulate network and / or WTRU functionality.

[0070] Emulated devices can be designed to implement one or more tests of other devices in a laboratory environment and / or in a carrier network environment. For example, one or more emulated devices can perform one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network. One or more emulated devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulated device can be directly coupled to another device for testing purposes and / or can perform tests using over-the-air wireless communications.

[0071] One or more emulated devices can perform one or more functions, including all functions, without being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulated devices can be used in test labs and / or test scenarios in non-deployed (e.g., testing) wired and / or wireless communication networks to enable testing of one or more components. The one or more emulated devices can be test devices. The emulated devices can transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which can include one or more antennas).

[0072] The following abbreviations and acronyms are used herein, among others: Acknowledgement (ACK); Block Error Rate (BLER); Bandwidth Part (BWP); Channel Access Priority (CAP); Channel Access Priority Class (CAPC); Clear Channel Assessment (CCA); Control Channel Element (CCE); Control Element (CE); Configured Grant or Cell Group (CG); Cyclic Prefix (CP); Conventional OFDM (cyclic prefix dependent) (CP-OFDM); Channel Quality Indicator (CQI); Cyclic Redundancy Check (CRC); Channel State Information (CSI); Contention Window (CW); Contention Window Size (CWS); Channel Occupancy (CO); Downlink Assignment Index (DAI); Downlink Control Information (DCI); Downlink Feedback Information (DFI); Dynamic Grant (DG); Downlink (DL); Demodulation Reference Signal (DM-RS); Data Radio Bearer (DRB); Enhanced Grant Assisted Access (eLAA); Further Enhanced Grant Assisted Access (FeLAA); Hybrid Automatic Repeat Request (HARQ); Grant Assisted Access (LAA); Listen Before Talk (LBT); Long Term Evolution (e.g., from 3GPP LTE) R8 and above) (LTE); Negative ACK (NACK); Modulation and Coding Scheme (MCS); Multiple Input Multiple Output (MIMO); New Radio (NR); Orthogonal Frequency Division Multiplexing (OFDM); Physical Layer (PHY); Process ID (PID); Paging Occasion (PO); Physical Random Access Channel (PRACH); Primary Synchronization Signal (PSS); Random Access (or Procedure) (RA); Random Access Channel (RACH); Random Access Response (RAR); Radio Access Network Central Unit (RCU); Radio Front End (RF); Radio Link Failure (RLF); Radio Link Monitoring (RLM); Radio Network Identifier (RNTI); RACH Occasion (RO); Radio Resource Control ( RRC); Radio Resource Management (RRM); Reference Signal (RS); Reference Signal Received Power (RSRP); Received Signal Strength Indicator (RSSI); Service Data Unit (SDU); Sounding Reference Signal (SRS); Synchronization Signal (SS); Secondary Synchronization Signal (SSS); Switching Gap (in self-contained subframe) (SWG); Semi-Persistent Scheduling (SPS); Supplementary Uplink (SUL); Transport Block (TB); Transport Block Size (TBS); Transmit-Receive Point (TRP); Time-Sensitive Communication (TSC); Time-Sensitive Networking (TSN); Uplink (UL); Ultra-Reliable and Low Latency Communication (URLLC); Wide Bandwidth Part (WBWP); Wireless Local Area Networks and Related Technologies (IEEE 802.xx domain) (WLAN).

[0073] In an example, NR may support one or more services with different quality of service (QoS) requirements, e.g., services including one or more (e.g., varying) latency and / or reliability requirements.

[0074] In an NR system, data packets originate from the application layer. The non-access stratum (NAS) layer assigns QoS requirements and / or mapping rules. The NAS maps the data / IP flows carrying the data packets to QoS flows and configures a QoS flow ID (QFI) for one or more (e.g., each) QoS flows. One or more (e.g., all) data packets within the same QoS flow may have the same QFI. The access stratum (AS) layer may map the QoS flow to radio layer resources, where the Service Data Adaptation Protocol (SDAP) entity within the WTRU maps the QoS flow to a data radio bearer (DRB). One or more (e.g., all) data packets mapped to the same DRB may receive the same transmission treatment within the AS (e.g., from a radio interface perspective). The SDAP QoS flow to DRB mapping rules may be semi-statically configured in the radio resource control (RRC). The WTRU-SDAP may map SDUs to DRBs according to the configured rules and / or map SDUs to a default DRB (e.g., if no rules are configured). The RRC may configure one or more (e.g., each) DRB with one or more logical channels (LCHs). The Logical Channel Prioritization (LCP) function in the WTRU-MAC may allocate uplink radio resources among LCHs with buffered data in the WTRU, for example, based on configured QoS-related LCP parameters. The QoS-related LCP parameters may include, for example, the priority of the LCH, the prioritized bit rate (PBR) of the LCH, the bucket size duration (BSD) of the LCH, and / or LCP mapping constraints configured per LCH for the LCH.

[0075] NR can support time-sensitive communications and / or networks, including deterministic and / or non-deterministic time-sensitive networking (TSN) and / or time-sensitive communication (TSC) traffic patterns and / or flows. TSN and / or TSC traffic patterns and / or flows may be prevalent in factory automation settings using licensed and / or unlicensed spectrum.

[0076] TSN / TSC may include parameters signaled to the RAN in TSC Assistance Information (TSCAI). This may include a time-to-live (e.g., the amount of time an application can handle a failed transmission before the entire application fails). TSCAI may define service availability, reliability, and / or burst spread (e.g., the spread that may exist per burst due to jitter-like behavior) for periodic bursts. One or more (e.g., each) burst may represent an application message that may be delivered via a single Packet Data Convergence Protocol (PDCP) SDU (and / or via one or more (e.g., multiple) SDUs).

[0077] Time to Live (ST) can be a way to guarantee communication service availability (CSA) and / or communication service reliability (CSR). The CSA can be the percentage of time a service is available, and the CSR can be the average time between allowed failures. ST can be used for one or more (e.g., any) transmissions of an application. ST does not indicate the reliability of the packet itself, as one or more (e.g., any) packets may (e.g., may need to) be successfully transmitted for the time to live to be acceptable. For example, if there is a transmission associated with each time slot and the time to live is two time slots, the system can handle one failed transmission. For example, if the first transmission fails, the second transmission may be successful. The second transmission may not be a retransmission of the first. Instead, the second transmission may (e.g., may need to) be part of the application / service. When the time to live is about to expire (and in some cases, it can be on the order of 0.5 ms), the transmitter can increase the robustness of its transmission to ensure that at least one packet is successfully delivered. Relevant ST requirements to consider may include one or more requirements associated with periodic, deterministic communication services. For example, in R17, upon determining a NACK for a given message transmitted on the Physical Uplink Shared Channel (PUSCH), the WTRU may activate PDCP duplication for the next TB to prevent failure of subsequent messages. It is assumed that such traffic is periodic and that a successful transmission (tx) of one or more (e.g., any) subsequent TBs with duplication will satisfy the ST requirement. One or more (e.g., all) radio link control (RLC) entities configured for DRBs with ST data may be activated by the WTRU for duplication.

[0078] For example, if a message transmission fails, the message may (e.g., must) be successfully delivered before the Time-to-Live requirement has elapsed; otherwise, the ST may be violated. As described herein, the second transmission may not (e.g., need not be) a retransmission of the first transmission. Instead, the second transmission may (e.g., may need to) be part of the application / service. For example, when the Time-to-Live is about to expire and / or when the Time-to-Live state is triggered, the transmitter may increase the robustness of its transmission to ensure that at least one packet is successfully delivered before the Time-to-Live has elapsed. For non-strict communication services, the gNB may have sufficient time to safely react to the ST and reconfigure transmission to serve the service before the ST deadline. For more stringent scenarios, relying solely on the gNB may not be sufficient to meet the requirements. For example, in SL, the gNB may not (e.g., always) ensure that the Time-to-Live QoS requirement is met. For example, in Mode 2, if the WTRU is out of coverage, the gNB may not be involved. For example, in Mode 1, gNB involvement may not be timely because the gNB is considered a third party not involved in the application. For cases where ST is more relaxed, the gNB scheduler may help to react before the time to live has elapsed (e.g., may allow a reaction).

[0079] Embodiments described herein may include a WTRU configured for ST triggering and recovery for two SL modes. The WTRU may be configured with one or more DRBs to which a time-to-live QoS requirement applies. The WTRU may determine that a transmission on SL resources has failed. For example, the WTRU may determine that a transmission on SL resources has failed based on one or more of the following: receiving a physical sidelink feedback channel (PSFCH) and / or SCI indicating a failure from a peer WTRU; the TB being dropped due to an overlapping Uu transmission; and / or the TB being dropped due to being preempted by another SL transmission. The WTRU may trigger a time-to-live state to provide increased transmission reliability. For example, upon triggering the ST state, the WTRU may start an ST timer. For example, upon expiration of the ST timer and / or upon receipt of an acknowledgment (ACK) from the peer WTRU, the WTRU may deactivate the ST state. During the ST state, the WTRU may perform one or more of the following: During the ST state, the WTRU may increase the transmit power level associated with one or more other (e.g., new) SL transmissions. During the ST state, the WTRU may increase the TB priority of one or more other (e.g., new) TB transmissions on the SL resources. During the ST state, the WTRU may activate autonomous blind retransmission and / or repeat. During the ST state, the WTRU may override the discard rules so that SL transmissions with DRBs configured with ST are (eg, always) prioritized over other SL and / or Uu transmissions.

[0080] Embodiments are described herein regarding a WTRU configured for ST triggering and resumption for SL Mode 2. The WTRU may be configured with one or more DRBs to which ST QoS requirements apply. For example, the WTRU may receive configuration information indicating that transmission of DRBs associated with SL transmissions may be performed in a normal QoS state and / or in a restricted time-to-live QoS state. The WTRU may be configured with one or more resource pools for S1 transmission Mode-2. The WTRU may trigger a time-to-live state to obtain increased transmission reliability for transmitting the next TB. The WTRU may trigger the time-to-live state to obtain increased transmission reliability for transmitting the next TB based on making channel measurements above a configured threshold and / or determining that a transmission on a configured SL resource was dropped due to a CR. For example, the WTRU may trigger the time-to-live state to obtain increased transmission reliability based on a measured CBR and / or CR above a threshold, an RSRP associated with an SCI received from another WTRU above a threshold, and / or a CQI below a threshold. The WTRU may trigger the ST state to obtain increased transmission reliability. The WTRU may start an ST timer upon triggering the ST state. For example, the WTRU may start an ST timer based on a channel measurement and / or a determination that a transmission on a configured SL resource is discarded based on a CR being above a threshold. For example, the WTRU may start a time-to-live timer based on a preemption determination. For example, the WTRU may start a time-to-live timer based on a perception-based determination. For example, while the time-to-live timer is running, the WTRU may temporarily disable congestion control and / or CR limiting. The channel measurement may correspond to one or more of: a measured CBR being above a threshold, a measured CR being above a threshold, a measured RSRP associated with an SCI being above a threshold, and / or a measured CQI being below a threshold. The WTRU may (e.g., determine) transmit at least a first TB based on the running time-to-live timer. The first TB may include data for a DRB in the SL based on transmission parameters corresponding to a restricted survival QoS state. The WTRU may determine to transmit at least the first TB based on transmission parameters corresponding to a restricted survival QoS state based on a channel measurement being above a threshold and / or discarding a transmission on a configured SL resource based on a CR being above a threshold. The transmission parameters corresponding to the restricted survival QoS state may include one or more of the following: an adjusted resource selection window such that the second SL transmission is within the remaining time of the survival timer; an increased TB priority; a determination to bypass one or more CBR congestion control constraints; a determination to bypass one or more CR congestion control constraints; and / or a reselected SL resource. For example, if the WTRU is within coverage, the WTRU may report a transmission failure and / or a CBR / CR above a threshold to the gNB (e.g., an indication of a transmission failure and / or a CBR / CR above a threshold).For example, the WTRU may report a transmission failure and / or a CBR / CR exceeding a threshold (e.g., an indication of transmission failure and / or CBR / CR exceeding a threshold) to the gNB in ​​a MAC CE, a Scheduling Request (SR), and / or on a Physical Uplink Control Channel (PUCCH) (e.g., a NACK). The WTRU may transmit at least a second TB based on the expiration of the Time to Live timer. The second TB may include data for a DRB in a SL according to transmission parameters corresponding to a normal QoS state. The second TB may be transmitted in a different resource pool. While the WTRU is in the ST Time to Live state, the WTRU may perform one or more of the following. During the Time to Live state, the WTRU may adjust the resource selection window. For example, the WTRU may adjust the resource selection window so that the next (e.g., new) SL transmission expires within the remaining time of the ST timer. During the Time to Live state, the WTRU may increase the TB priority for TB transmissions on SL resources in the resource selection procedure. During the Time to Live state, the WTRU may bypass CBR / CR congestion control, for example, if a previous packet failed. During the Time to Live state, the WTRU may select a different SL resource (or resource pool) based on the measured CB / CBR. The WTRU may stop the time-to-live timer based on receipt of an acknowledgement of the first TB and / or the second TB, receipt of an SCI, expiration of the time-to-live timer, receipt of an indication from the network, and / or one or more channel measurements.

[0081] Figure 2 An example of SL Mode 2 operation with a time to live of 200 is depicted.

[0082] At 202, the WTRU may receive configuration for one or more DRBs with time-to-live QoS requirement(s). For example, the WTRU may receive configuration information indicating that transmission of DRBs associated with SL transmission may be performed in a normal QoS state and / or in a restricted time-to-live QoS state.

[0083] At 204, the WTRU may perform one or more measurements. For example, the WTRU may measure the CBR and / or CR to determine if the CBR and / or CR is above a threshold. For example, the WTRU may measure the RSRP (e.g., the SCI of one or more other WTRUs) to determine if the measured RSRP is above a threshold. For example, the WTRU may measure the CQI to determine if the measured CQI is below a threshold. Additionally or alternatively, the WTRU may discard the TB, for example, due to the CR.

[0084] At 206, the WTRU may trigger a time-to-live state and / or may start a time-to-live timer (e.g., as described herein). For example, the WTRU may start the time-to-live timer based on a channel measurement and / or based on a determination that a transmission on the configured SL resources was dropped based on a CR being above a threshold.

[0085] At 208, for the next SL TB transmitted during this time, the WTRU may perform one or more of the following: The WTRU may adjust the resource selection window so that the next (e.g., new) SL transmission expires within the time-to-live timer. The WTRU may increase the TB priority. The WTRU may bypass CBR and / or CR congestion control. The WTRU may select a different SL resource (or resource pool).

[0086] The embodiments described herein may relate to a WTRU configured for ST triggering and recovery for SL-U scenarios. The WTRU may be configured with one or more DRBs as required by ST QoS. The WTRU may be configured with multiple SL resources on different resource block (RB) sets with independent LBT channel acquisition procedures. The WTRU may detect an LBT failure for transmission on SL resources on a given RB set. The WTRU may trigger the ST state to obtain increased transmission reliability for transmitting the next TB. During the Time to Live state, the WTRU may perform one or more of the following. During the Time to Live state, the WTRU may transmit and / or retransmit a TB on different RB sets. During the Time to Live state, the WTRU may attempt to transmit a TB duplicate on multiple RB sets. During the Time to Live state, the WTRU may transmit a transport block with short LBT and / or no LBT configuration.

[0087] Embodiments of a WTRU configured for ST recovery and reporting for SL Mode-1 are described herein. The WTRU may be configured with one or more DRBs to which ST QoS requirements apply. The WTRU may be configured with an SR configuration for reporting SL transmission failure for DRBs configured with ST requirements. The WTRU may determine that a TB transmission has failed on SL resources. The WTRU may trigger an ST state for increased transmission reliability. The WTRU may trigger a new SR for reporting the SL transmission failure and / or may transmit an SR on PUCCH resources of the associated SR configuration. During the ST state, the WTRU may perform one or more of the following. During the Time to Live state, among multiple available grants, the WTRU may select a grant for transmission of a new transmission as: a grant with the highest reliability MCS and / or a grant preconfigured to be used (e.g., conditionally used) in the ST state. During the ST state, the WTRU may replicate the TB transmission on one or more (e.g., multiple) configured grants (CGs).

[0088] The CSI may include one or more of the following: a channel quality indicator (CQI), a rank indicator (RI), a precoding matrix indicator (PMI), an L1 channel measurement (e.g., RSRP, such as L1-RSRP, or signal-to-interference-plus-noise ratio (SINR)), a CSI-RS resource indicator (CRI), an SS / physical broadcast channel (PBCH) block resource indicator (SSBRI), a layer indicator (LI), and / or one or more (e.g., any) other measurement quantities measured by the WTRU from the configured CSI-RS and / or SS / PBCH blocks.

[0089] The channel condition may include one or more (e.g., any) conditions related to the state of the radio / channel. The WTRU may determine the state of the radio / channel from one or more of: WTRU measurements (e.g., L1 / SINR / RSRP, CQI / MCS, channel occupancy, RSSI, power headroom, exposure headroom, and / or the like), L3 / mobility based measurements (e.g., RSRP, Reference Signal Received Quality (RSRQ), and / or the like), RLM status, channel availability in unlicensed spectrum (e.g., whether the channel is occupied based on a determination of an LBT procedure or whether the channel is considered to have experienced a persistent LBT failure), and / or measurements associated with the SL channel (e.g., CR, CBR, SCI-RSRP, SL-CQI, and / or the like).

[0090] Attributes of the scheduling information (e.g., an uplink grant or a downlink assignment) may include one or more of: a frequency allocation; an aspect of a time allocation, such as a duration; a priority; a modulation and coding scheme; a transport block size; one or more (e.g., some) spatial layers; one or more (e.g., some) transport blocks to be carried; a transmission configuration indicator (TCI) state and / or a scheduling request indicator (SRI); one or more (e.g., some) repetitions; and / or whether the grant is a configured grant type 1, type 2, or a dynamic grant.

[0091] The indication and / or indication of the DCI may include one or more of the following: an explicit indication through a DCI field and / or through an RNTI used to mask the CRC of the physical downlink control channel (PDCCH); an implicit indication through an attribute (e.g., DCI format, DCI size, CORESET or search space, aggregation level, identification of the first control channel resource used for the DCI (e.g., index of the first CCE), where the mapping between attributes and values ​​may be signaled by RRC and / or MAC and / or the like); and / or an explicit indication through a DL MAC CE.

[0092] One or more (e.g., some) of the embodiments and / or methods described herein may be exemplified based on the transmission and / or delivery of URLLC and / or extended reality (XR) services. The embodiments and / or methods described herein may not be limited to such scenarios, systems, and / or services; the embodiments and / or methods described herein may be applicable to one or more (e.g., any) types of transmission and / or services, including but not limited to cloud gaming, IoT / MTC, industrial use cases, vehicles to everything (V2X), multicast broadcast multimedia services (MBMS), and / or the like.

[0093] In an example, triggering of a live state may be observed (e.g., generally) to improve QoS and / or reliability. The live state may be triggered by one or more (e.g., any) of the QoS triggers as discussed herein. The embodiments described herein for improving reliability and / or QoS requirement achievement on a side link may be applied to one or more (e.g., various) types of traffic, services, and / or DRBs. For example, the embodiments for improving reliability and / or QoS requirement achievement on a side link may be applied to one or more (e.g., various) types of traffic, services, and / or DRBs even if the underlying application is not configured with a time-to-live requirement and / or if the DRB is not configured with a time-to-live requirement.

[0094] In an example, a WTRU may be configured with aspects and conditions for ST triggering. The WTRU may determine to apply a method for ST state triggering and recovery (e.g., as described herein) based on the configuration of each WTRU and / or each DRB. For example, the WTRU may be configured with one or more DRBs to which a time-to-live QoS requirement or a different latency-critical QoS requirement applies. For example, the WTRU may activate one or more (e.g., any) of the increased reliability embodiments and / or methods described herein upon triggering and / or entering a time-to-live state. For example, the WTRU may deactivate one or more (e.g., any) of the increased reliability embodiments and / or methods described herein upon exiting a time-to-live state. The WTRU may apply ST triggering and recovery to a TB that includes data from at least one DRB configured with such a low latency QoS requirement. The WTRU may apply ST triggering and recovery if the WTRU is RRC configured with a given low latency and / or high reliability QoS requirement, at least one DRB is configured with such a QoS requirement, and / or if the WTRU has a certain WTRU capability. The WTRU may apply ST triggering and recovery depending on the peer WTRU type, peer WTRU capabilities, and / or whether the peer WTRU supports receiving such data with low latency and / or high reliability QoS requirements. The WTRU may apply ST triggering and recovery to TBs that include replicated data from at least one DRB configuration. The reliability embodiments described herein may be dependent on and / or applicable (e.g., only) to specific triggers (e.g., drop due to CR, measured high CBR level, drop due to overlapping Uu transmissions, and / or the like).

[0095] In an example, the WTRU may be configured to trigger the ST state during an SL transmission. The trigger may be common for both SL Mode 1 and SL Mode 2. One trigger may occur due to a TB drop. The WTRU may trigger the ST state due to a dropped SL transmission. Dropping the SL transmission may occur as a result of a prioritization decision. Dropping the SL transmission may occur as a result of a preemption decision. For example, as a result of prioritizing Uu transmission over SL transmission, the WTRU may drop and / or delay the SL transmission. For example, if the WTRU prioritizes Uu transmission over SL transmission when SL is granted, the WTRU may trigger the ST state if the WTRU cannot transmit both Uu and SL together. In an example, as a result of prioritizing a higher priority transmission and / or reception (e.g., transmission / reception of PSFCH), the WTRU may drop and / or delay the SL transmission. For example, if the WTRU prioritizes reception of PSFCH and does not perform a transmission when SL is granted, the WTRU may trigger the ST state.

[0096] The trigger may occur due to a determination of LBT failure. The WTRU may trigger the ST state when it fails to transmit on SL resources and / or fails to reserve SL resources. For example, the WTRU may trigger the ST state when it fails to transmit on SL resources and / or fails to reserve SL resources due to a determination of LBT failure. The WTRU may determine that LBT has failed based on receiving an indication from the physical layer indicating that the SL transmission has failed LBT. The WTRU may determine that LBT has failed (e.g., only) after an LBT reference time point has passed and / or an LBT / CCA stop condition is met. The reference time point may be based on the stop condition. For example, the stop condition may occur at the end of a CCA period. The stop condition may (e.g., additionally or alternatively) be based on receiving an indication of LBT failure from the PHY layer. In an example, if the failure indication provides more information about the SL resource on which the failure occurred, the stop condition may be based on receiving an indication of LBT failure from the PHY layer. For example, if the indication provides that the LBT failure occurred on a set of RBs matching the reserved SL resources, the WTRU may trigger the ST state and / or may determine that an LBT failure has occurred. The WTRU may trigger the ST state when it fails to access the channel before the reserved SL resources and / or within the period for transmission. For example, the LBT stop condition may include a resource selection window whose end is based on the packet delay budget (PDB) of the TB.

[0097] The trigger may occur due to a failure to transmit a message, a NACK, and / or a failure to receive HARQ feedback. The WTRU may determine that a time-to-live state is triggered and / or activate one or more (e.g., any) of the increased reliability embodiments described herein upon determining that one or more transmissions on S1 have failed and / or control information related to a TB with ST and / or low latency QoS requirements (e.g., failure to transmit HARQ feedback and / or SCI). The failed transmission may include a SL data transmission including at least one DRB configured with low latency and / or time-to-live QoS requirements. The WTRU may determine failure based on one or more of the following: receiving a HARQ-ACK value and / or determining a HARQ-ACK value as a NACK for the transmission; not receiving expected HARQ feedback for the transmission at the expected time; not receiving control information (e.g., SCI or PSFCH) from the peer WTRU to which the data was transmitted; and / or receiving control information and / or SCI indicating that the transport block was not successfully decoded.

[0098] The WTRU may trigger a time-to-live state, apply one or more of the increased reliability embodiments and / or methods described herein, and / or determine that a transmission has failed if at least one or more of the following is true: one or more (e.g., all) PDCP PDU portions of the same higher layer application SDU have failed; at least one PDCP PDU portion of the same SDU has failed; an anchor PDU from a PDU set has failed; one or more (e.g., some) x consecutive transport blocks, PDCH SDUs, and / or PDCP PDUs have failed consecutively or have failed while a timer is running; the transmission includes at least one DRB configured with a time-to-live and / or low latency QoS requirement; control information, data, and / or expected period TB and / or SCI are not received from the peer WTRU to which it is transmitting data; signaling and / or indications (e.g., via DCI and / or MAC) are received from the gNB. CE); expiration of a timer from the transmission of a transport block initiated by a freely transmitting WTRU; failure to transmit HARQ feedback and / or SCI for a TB received from a peer WTRU, where the TB may include data with low latency and / or time-to-live requirements; and discarding HARQ feedback and / or SCI for a TB received from a peer WTRU. For scenarios where one or more (e.g., some) x consecutive transport blocks, PDCH SDUs, and / or PDCP PDUs have failed consecutively or have failed while the timer is running, x may be configured by the RRC. For example, if one HARQ NACK is configured to trigger ST, the WTRU may trigger ST if HARQ feedback / PSFCH reception is discarded. In an example, if more than one NACK / failure is configured to trigger ST, after receiving x consecutive discarded PUSCHs and / or NACKs, the WTRU may wait for another PFSCH opportunity and / or trigger ST. For the case where HARQ feedback and / or SCI for a TB received from a peer WTRU is discarded, the TB may include data with low latency and / or time-to-live requirements, where the discarding may be based on: prioritization within the WTRU, deprioritization / preemption by another Uu transmission, deprioritization / preemption by another SL transmission, and / or LBT failure.

[0099] The WTRU may trigger a time-to-live state, apply one or more of the increased reliability embodiments and / or methods as described herein, and / or determine that a transmission has failed if the WTRU fails to receive HARQ feedback from a peer WTRU. For example, the WTRU may determine that a transmission has failed if no HARQ PSFCH is received and / or the delay from the TB transmission exceeds a configured and / or predetermined period (e.g., no feedback is received within the ST-related timer, the shared channel occupancy time (COT), the maximum COT duration, and / or the expected feedback (FB) arrival time).

[0100] The WTRU may trigger a time-to-live state, apply one or more of the increased reliability embodiments and / or methods as described herein, and / or determine that a transmission has failed if the WTRU determines that a HARQ PSFCH reception was dropped due to overlap with another UL transmission and / or SL transmission (e.g., an LTE SL transmission and / or another SL transmission with a higher priority at a peer WTRU). This may cause the WTRU to (e.g., either) trigger a ST and / or enter a preemption action to obtain increased reliability (e.g., before deterministically determining the failed transmission).

[0101] The preemption trigger may be based on a measurement of channel conditions. The WTRU may determine that a time-to-live state is triggered and / or activate one or more (e.g., any) of the increased reliability embodiments described herein when a certain channel condition is measured above or below a configured threshold. The measurement may be related to a shared channel / SL resource and / or to a certain channel condition between the tx and a peer WTRU.

[0102] The WTRU may determine that the Time to Live state is triggered after performing an RSRP measurement on a given SL resource (e.g., a Mode 2 resource pool) that is above a threshold. RSRP may be correlated with the SCI of other WTRUs measuring from the shared resource. The WTRU may trigger the Time to Live state when performing measurements on a shared channel (e.g., a sidelink channel operating on an unlicensed spectrum) that is above a threshold. For example, the WTRU may trigger the ST state when it measures RSSI and / or channel occupancy (CO) above a configured threshold.

[0103] The WTRU may trigger the ST state after measuring a link quality metric and / or channel condition below or above a configured threshold. The link may be between a tx WTRU and a peer WTRU to which it transmits a TB with ST and / or low latency QoS data. For example, if the measured CQI of the link between the WTRUs is below a certain configured threshold, the WTRU may trigger the ST state. If the measured L1-RSRP, BLER, or L1-SINR of the link between the WTRUs is below a certain configured threshold, the WTRU may trigger the ST state. The threshold may be configured by RRC configuration or reconfiguration signaling.

[0104] The WTRU may trigger the ST state based on measurements of a side link between the WTRU and a peer WTRU. The WTRU may receive RSRP measurements from the peer WTRU and determine the corresponding path loss. The WTRU may trigger the ST state when the determined path loss may be below a configured and / or preconfigured threshold. In an example, the WTRU may determine the transmit power based on the determined path loss. The WTRU may trigger the ST state when the determined SL transmit power may exceed a preconfigured and / or configured maximum power.

[0105] The WTRU may trigger the ST state based on resource selection information (e.g., inter-WTRU coordination (IUC) information) received from a peer WTRU. For example, the WTRU may be configured to receive a non-preferred resource set from a peer WTRU and trigger (e.g., determine) the ST state based on the received non-preferred resource set. The non-preferred resource set may include resources from which the peer WTRU may not receive SL transmissions from the WTRU. The WTRU may trigger the ST state when the number of received non-preferred resources exceeds a pre-configured and / or configured threshold. The pre-configured and / or configured threshold may be indicated as a ratio of the number of non-preferred resources to the total resources to be selected in the resource selection window. In an example, the WTRU may receive one or more conflict indications in the PSFCH dedicated to the resources reserved by the WTRU. The conflict indication may indicate that the reserved resources overlap with resources reserved by other WTRUs. When the WTRU receives one or more conflict indications, the WTRU may trigger the ST state. As the WTRU enters the ST state, the WTRU may perform resource reselection.

[0106] A WTRU may be configured with a low latency QoS requirement and other triggers caused by QoS requirements other than ST. Other QoS conditions that may cause a WTRU to trigger the ST state are described herein (e.g., triggers related to PDBs, triggers due to failure to transmit a PDU from a PDU set, triggers due to out-of-sequence SDU sequence numbers (SNs)). The WTRU may trigger the Time to Live state, applying one or more of the increased reliability embodiments and / or methods as described herein, when one or more (e.g., any) of the following QoS conditions are met: arrival of data of a particular priority; PDB remaining time; time since data arrival; missing PDUs from a PDU set; receipt of an acknowledgment of received out-of-sequence PDCP SN from a peer WTRU; intra-WTRU prioritization between PDUs of different priorities; triggering of a BSR or SR due to arrival of data from a DRB configured with low latency QoS or ST requirements; configuration of at least one SL DRB with a Time to Live or low latency QoS parameter or priority; and / or receipt of DL data from a DL DRB of a particular priority or from an associated SL DRB. With respect to the arrival of data of a certain priority, the WTRU may be configured with a priority index for each LCH or DRB. Upon the arrival of data with a high priority index or a certain priority index, the WTRU may trigger ST. With respect to the PDB remaining time, the WTRU may trigger ST if the remaining time in the PDB of the packet is less than a certain threshold, expires, or is about to expire. With respect to the time since the arrival of the data, the WTRU may be configured to trigger ST if the time since the arrival of the data in the WTRU buffer is less than or greater than a configured and / or predefined threshold (e.g., related to the ST value). With respect to missing PDUs from a PDU set, the WTRU may trigger the ST state upon determining that a certain PDU from the PDU set (e.g., an anchor PDU) was not successfully transmitted, was not acknowledged by a peer WTRU, and / or was not received from a higher layer. The WTRU may be configured or predefined to determine which PDUs within a PDU set are anchor DDUs (e.g., PDUs associated with certain frames of a video stream). With respect to receiving confirmation of receipt of out-of-order PDCP SNs from a peer WTRU, for example, if the WTRU receives successful confirmation of receipt of PDCP SN 1, SN 2, and then SN 4, the WTRU may trigger the ST state because SN 3 was not confirmed. In the example, if SN 3 is not received from higher layers within the WTRU, the WTRU may trigger the ST state. With respect to intra-WTRU prioritization between PDUs of different priorities, the WTRU may trigger the ST state when a PDU is discarded due to intra-WTRU prioritization of a HARQ-ACK with a higher priority and / or a higher priority SL PDU. One or more of the conditions described herein may be used to characterize low latency QoS requirements.

[0107] One or more triggers may be associated with an S1 Mode 2 transmission. The WTRU may be configured with a CBR-based trigger. When operating in Mode 2, the WTRU may trigger the ST state after a transmission based on a condition related to the measured CBR. When operating in Mode 2, the WTRU may trigger the ST state based on a condition related to the CBR measured at the time of transmission. For example, the WTRU may trigger the ST state if the measured CBR is above a configured threshold. In an example, the WTRU may trigger the ST state if the measured CBR changes (e.g., increases) by a configured amount. In an example, the WTRU may trigger the ST state if the transmission results in a triggering of congestion control (such as, but not limited to, reducing transmit power, reducing the number of resources, changing the MCR, QoS parameters of minimum communication range, and / or the like compared to the previous transmission). Additionally or alternatively, the WTRU may trigger the ST state if the measured CBR meets the condition for a period of time. For example, if the measured CBR remains above a threshold for a period of time, the WTRU may trigger the ST state after the period of time. The WTRU may remain in the ST state for a preconfigured period of time, for a single or a predefined / preconfigured number of transmissions, and / or until additional conditions related to the CBR are met (eg, the CBR falls below a threshold).

[0108] One or more triggers may be associated with a CR-based trigger. The WTRU may be configured with a CR-based trigger. The WTRU may trigger the ST state after a transmission based on a condition related to the measured CR. The WTRU may trigger the ST state based on a condition related to the CR measured at the time of the transmission. For example, if the measured CR is above a threshold, the WTRU may trigger the ST state. For example, if the CR reaches a CR limit and the WTRU therefore chooses to drop the transmission, the WTRU may trigger the ST state. For example, after each dropped transmission due to reaching the CR limit, the WTRU may trigger the ST state for one or more (e.g., each) transmissions. For example, the WTRU may remain in the ST state as long as the CR is above the threshold. For example, the WTRU may remain in the ST state as long as the condition related to the CR that initiated the ST state is met.

[0109] One or more triggers may be based on preemption. The WTRU may be configured with a trigger based on preemption. The WTRU may trigger the ST state after a preemption decision. For example, if the WTRU preempts a selected resource due to a sensing result, the WTRU may trigger the ST state. The sensing result may be a sensing result of the WTRU and / or based on sensing information provided by another WTRU. For example, if the WTRU has reserved resources for transmission and performs a reselection due to preemption, the WTRU may trigger the ST state. Additionally or alternatively, the WTRU may trigger the ST state after a trigger used to perform a reassessment. For example, the WTRU may trigger a reassessment after an initial resource selection and / or the WTRU may trigger the ST state after deciding to perform a reassessment. The WTRU may trigger the ST state after preemption and / or a reassessment based on one or more (e.g., additional) conditions related to the reselected resource. For example, the WTRU may trigger the ST state after preemption and / or reassessment (e.g., only) if the reselected resource occurs later in time than the originally selected resource. For example, the WTRU may trigger the ST state after preemption and / or re-evaluation (eg, only) when the reselected resource occurs one or more (eg, some) time slots later in time.

[0110] One or more triggers may be perception based. The WTRU may be configured with a perception based trigger. The WTRU may trigger the ST state following a condition associated with a perception result, a perception mechanism, and / or the like. In an example, the ST state may be triggered by a condition related to the number of times the RSRP threshold is increased by 3dB to achieve the required available resources. For example, if the WTRU performs resource selection, the WTRU may trigger the ST state and obtain the selected resource after the threshold RSRP is required to be increased by 3dB to achieve x% of the available resources. In an example, the ST state may be triggered by a condition related to the number of available resources from which the WTRU performs a random selection. For example, if the WTRU performs a resource selection and obtains the selected resource after the number of available resources is less than y% when performing the random selection, the WTRU may trigger the ST state. In an example, the ST state may be triggered by a condition related to the SCI RSRP observed in the resource pool and / or many resources with high SCI RSRP. For example, if a WTRU performs resource selection and the selected resources are obtained such that at least z% of the available resources in the available resource pool have an SCI RSRP from another WTRU that is above a preconfigured threshold, then the WTRU may trigger the ST state. In an example, the ST state may be based on the type of sensing performed. For example, for a WTRU that uses random selection in a resource pool and / or uses partial sensing in a resource pool, the ST state may be used in one or more (e.g., all) cases.

[0111] One or more triggers may be associated with SL Mode 1 transmission. The trigger may be based on the receipt of a DL indication over Uu. The WTRU may be configured with a trigger based on the receipt of a DL indication over Uu. When an indication is received from the network over Uu indicating that the WTRU should enter the ST state, the WTRU may trigger the time-to-live state, applying one or more of the increased reliability embodiments and / or methods as described herein. The WTRU may be configured to trigger the ST state (e.g., implicitly) starting from the receipt of such an indication. The WTRU may be configured to trigger the ST state (e.g., implicitly) starting from the receipt of such an indication, even if the indication does not provide an explicit indication to enter the ST state. The network (NW) may be aware of a problem with a peer WTRU, for example, because the peer WTRU has provided a report to the NW. The indication may be in the form of one or more of: an indication in a DCI as described herein; an indication determined by the WTRU based on attributes from the schedule as described herein; reception of a PDCCH; reception of a DCI; reception of a dynamic grant; activation of a given CG or SPS resource; reception of a grant; reception of a DL MAC CE indicating ST entry; and / or reception of an RRC message and / or RRC reconfiguration for SL resources. With respect to the indication provided in the reception of a PDCCH, the indication may be provided on a certain core set and / or search space associated with a higher priority transmission and / or schedule. With respect to the indication provided in the reception of a DCI, the indication may be provided with an indicated high priority index. With respect to the indication provided in the reception of a dynamic grant (e.g., a SL DG), the indication may be provided if the dynamic grant is from a certain subset of HARQ processes. For example, the WTRU may trigger the ST state upon receiving a dynamic grant for a retransmission of a TB multiplexed with ST and / or low latency QoS data. In an example, the WTRU may be configured with a processed HARQ pool associated with a higher priority transmission or a certain priority index. With respect to the indication provided in the activation of a given CG or SPS resource, the WTRU may trigger the ST state upon receiving signaling to activate a Type-2 CG associated with a high priority index. In an example, the WTRU may trigger the ST state upon receiving signaling to activate a Type-2 CG that is configured to be used (e.g., conditionally used) in (e.g., only in) the ST state. With respect to the indication provided in the reception of a grant (e.g., SL DG and / or CG), the indication may be provided if the dynamic grant is signaled and / or configured with a certain priority index (e.g., high priority, priority index 1 or 0). With respect to the indication provided in the reception of a certain RRC message and / or RRC reconfiguration for SL resources, for example, the WTRU may receive an RRC reconfiguration outlining a change in LCH and / or DRB priority configured with ST and / or low latency QoS requirements.

[0112] Methods for increasing reliability after ST triggering are described herein. A WTRU may be configured to increase reliability after ST triggering. For example, a WTRU may be configured to increase reliability for both SL Mode 1 and SL Mode 2.

[0113] The WTRU may be configured for adjustment of TB priority. For example, the WTRU may achieve the ST state by adjusting transmission priority and / or the like. In an example, the WTRU may temporarily increase the priority of the TB when performing SL transmission. For example, during transmission in the SCI, the WTRU may use a higher priority (or use priority 1). Additionally or alternatively, when performing operations at the MAC layer (e.g., LCP, LBT, sensing and / or the like), the WTRU may determine (e.g., assume) a higher logical channel priority than configured (e.g., use priority 1). In an example, the WTRU may change one or more rules for UL / SL prioritization. For example, the WTRU may change one or more rules for UL / SL prioritization over a period of time. For example, even when Uu transmission is prioritized, the WTRU may perform SL transmission instead of Uu transmission.

[0114] The WTRU may be configured to adjust transmission parameters and / or resources after an LBT failure. Upon triggering the ST state and / or during the ST state, the WTRU may perform one or more of the following: transmit and / or retransmit TBs on different RB sets; attempt LBT on multiple RB sets to transmit TB copies on multiple RB sets; attempt TLB on multiple RB sets to a single TB on an RB set where LBT succeeded; and / or transmit and / or retransmit TBs with short LBT and / or no LBT configuration. The WTRU may use one or more (e.g., any) of the methods described herein to determine whether LBT succeeded or failed. Upon triggering the ST state and / or during the ST state, the WTRU may perform one or more (e.g., any) of the procedures described herein based on the condition that the WTRU has an ST state triggered by an LBT failure.

[0115] The WTRU may be configured for adjustments to PHY transmission parameters. Upon triggering the ST state and / or during the ST state, the WTRU may perform one or more of the following: changing and / or increasing transmit power; MCS / coding rate; and / or a diversity configuration using more antenna ports. Regarding changing or increasing transmit power, the WTRU may be configured with (one or more) alternative transmit power values ​​for use in the ST state. The WTRU may be configured with a tx power offset, wherein the WTRU may increase the tx power by an increment during the ST state and / or after each retransmission. Regarding MCS / coding rate, the WTRU may be configured with (one or more) alternative MCS values ​​for use in the ST state. The WTRU may be configured with an MCS offset, wherein the WTRU increases MCS reliability during the ST state and / or after each retransmission. Regarding a diversity configuration using more antenna ports, the WTRU may be configured with (one or more) alternative values ​​for the number of antenna ports and / or elements for use in the ST state. Upon entering the ST state and / or after each retransmission, the WTRU may use more antenna ports / elements and / or an alternative configuration for beamforming.

[0116] The WTRU may be configured for adjustments to repetition and duplication. The WTRU may activate autonomous blind retransmission / repetition upon triggering the ST state and / or during the ST state, and / or increase the number of autonomous repetitions. Upon triggering the ST state and / or during the ST state, the WTRU may duplicate a TB transmission on one or more (e.g., multiple) SL resources (e.g., a CG or resource pool).

[0117] One or more stop conditions may be associated with the added reliability. The WTRU may be configured with one or more stop conditions for the added reliability. The WTRU may be predefined and / or configured with one or more criteria to exit the ST state and / or stop using the added reliability embodiments and / or methods as described herein, including one or more of: receipt of an ACK for the same or next TB; receipt of an SCI; expiration of a timer; based on channel measurements; and / or receipt of an indication from the network to exit the ST state.

[0118] Regarding the reception of an ACK for the same or next TB, the WTRU may exit the ST state upon receiving a HARQ ACK (e.g., on the PSFCH), upon receiving a configured or predefined number of HARQ ACKs consecutively (e.g., for TBs / PDUs within a sequence), and / or upon implicitly determining an ACK from the expiration of a timer. The WTRU may exit the ST state (e.g., only) if the ST state was triggered by the reception and / or determination of a NACK.

[0119] Regarding the reception of an SCI, the WTRU may exit the ST state upon receiving an SCI from a peer WTRU. Receipt of an SCI from a peer WTRU may indicate reception of a transmitted PDU. The WTRU may exit the ST state (e.g., only) if the ST state was triggered by a NACK reception or confirmation.

[0120] With respect to the expiration of timers (e.g., time-to-live related timers), the WTRU may start a timer upon entering the ST state, and upon expiration of such a timer, the WTRU may exit the ST state and cease using the reliability embodiments and / or methods as described herein. Such a timer may be stopped when the time-to-live limit set by higher layers has expired or elapsed.

[0121] With respect to exiting the ST state based on channel measurements, the WTRU may exit the ST state when the channel measurement drops below or rises above a configured threshold. (For example, only) if the ST state is triggered by channel measurements and / or by a preemption trigger for added reliability in the absence of NACK certainty, the WTRU may exit the ST state when the channel measurement drops below or rises above a configured threshold. For example, the WTRU may exit the ST state if: the CR drops below a threshold; the CBR drops below a threshold; the link quality between peers drops above a threshold (for example, based on CSI reports and / or CQI); and / or the RSRP is less than or greater than a threshold.

[0122] Regarding receipt of an indication from the network to exit the ST state, one or more (e.g., any) of the example indications described herein may be applicable to exiting the ST state. Exiting the ST state upon receiving an indication from the network may be applicable (e.g., only) if the ST state was triggered by a gNB indication. For example, the WTRU may exit the ST state upon CG deactivation and / or reconfiguration of SL resources.

[0123] The WTRU may be configured with increased reliability for Mode 2. The WTRU may be configured for adjustment of TB priority. The WTRU may be configured in the ST state by adjusting transmission priority, and / or similarly configured in the ST state in the case of Mode 2 transmission. In an example, the WTRU may temporarily increase the priority of a TB when performing resource selection. For example, the WTRU may use a higher priority (or use priority 1) during the determination of available resources. In an example, the WTRU may temporarily disable congestion control and / or CR limiting during the ST state. For example, the WTRU may not reduce transmission parameters based on CBR, and / or may determine (e.g., assume) a minimum CBR range when selecting transmission parameters. The WTRU may not limit CR, and / or may determine (e.g., assume) a higher CR limit during the ST state. In an example, the WTRU may trigger resource selection and / or reselection upon entering the ST state, and / or may change the criteria associated with resource selection to obtain resources with less interference from other WTRUs. For example, an SCI RSRP used to determine that available resources may be below or less than x% of the available resources may be accepted to perform random selection among better quality resources. For example, better quality resources may mean less interference (e.g., this may be measured by having SCI RSRP × dB less than a typical threshold outside of the ST state and / or the percentage of available resources without interference being x percent higher than outside of the ST state). "x" may be a configured threshold that may be configured by RRC configuration signaling and / or reconfiguration signaling. In an example, the WTRU may transmit in different resource pools during the ST state. For example, the WTRU may use a special resource pool. For example, if the ST state is triggered when the WTRU performs a random selection among the pools, the WTRU may use a resource pool that allows for full awareness.

[0124] The WTRU may be configured for adjustment of transmission resource selection. In the ST state, the WTRU may adjust the resource selection window for mode 2 sidelink resources. The WTRU may start the selection window after triggering the ST state and / or upon receiving a HARQ NACK for a TB transmitted with ST and / or low latency QoS requirements. The WTRU may adjust the maximum window size so that the remaining delay budget for the next transmitted TB falls within the expiration of the ST timer or the remaining PDB. The WTRU may adjust the maximum window size so that the resource selection window (RSW) and the transmission time end before the expiration of the delay budget. The delay budget may be determined from the remaining time in the ST timer, the remaining time in the PDB, and / or the remaining time in the higher layer application lifetime.

[0125] In the ST state, the WTRU may select a resource even if the congestion level is above a (e.g., typical) threshold (e.g., in a legacy configuration). The WTRU may select a resource conditional on receiving one or more (e.g., some) NACKs. In an example, the WTRU may be configured with an additional second RSRP threshold and / or offset, where the WTRU may (e.g., still) select a SL resource. The WTRU may select a SL resource even if the RSRP is above the legacy first threshold and the RSRP is below a second additional threshold. The second threshold may be determined based on adding an offset to the first threshold. After consecutively receiving and / or determining each NACK, and / or while the ST timer is running, the WTRU may increase the value of the second threshold and / or add an offset to the threshold. If the ST state is triggered and / or deemed to have a higher priority than the traffic priority in the measured resources, the WTRU may ignore the traffic priority in the measured resources and transmit regardless of such priority.

[0126] A WTRU may be configured with multiple Mode 2 resource pools. Each resource pool may be configured with a priority index, an MCS, a transmit power, whether such resource pool may be used during and / or outside of the ST state (e.g., a determination of whether such resource pool may be used during and / or outside of the ST state), and / or alternative CR and / or CBR thresholds. During the ST state, among multiple available grants, the WTRU may select a resource pool for transmission and / or retransmission that is: the pool with the most reliable MCS; the pool configured with the highest transmit power; the pool with the lowest measured CBR, CR, and / or RSRP associated with other WTRUs / traffic on such resources; the pool preconfigured for use in a time-to-live state (e.g., conditionally used); and / or the pool with the highest configured priority index and / or reliability level. For example, the pool with the most reliable MCS may be the pool with the lowest spectral efficiency, which may accommodate SDUs without segmentation.

[0127] Upon triggering and / or during the ST state, the WTRU may use a subset of the available resource pools. For example, the WTRU may transmit data (e.g., only) on resource pools that are configured for conditional use during the ST state. For example, upon receiving and / or determining a HARQ NACK, the WTRU may switch to using a different resource pool and / or a different set of RBs that are configured for use during the ST state. The WTRU may replicate a TB transmission on one or more (e.g., multiple) resource pools during the ST state. For example, the WTRU may replicate a TB transmission on one or more (e.g., multiple) resource pools during the ST state, where the copies may be transmitted on a subset of the resource pools (e.g., those resources that are configured to be used (e.g., conditionally used) during the ST state).

[0128] The WTRU may be configured with increased reliability based on measurements and / or preemption prior to the ST state being triggered. If the measurement of the channel condition is above or below the configured threshold(s), the WTRU may exclude SL resources (e.g., a Mode 2 resource pool or a pool on a given RB set) from selection for TB transmissions that include data associated with ST and / or low latency QoS requirements. For example, the WTRU may exclude resources where the measured CR, CBR, and / or SCI-RSRP is above the configured thresholds. The threshold(s) may be determined based on adding a positive or negative offset to an existing threshold for resource selection (e.g., an existing threshold for RSRP associated with SCI transmissions from other WTRUs sharing the resource).

[0129] If a preemption and / or deprioritization event occurs on SL resources, the WTRU may exclude such resources (e.g., a Mode 2 resource pool or a pool on a given RB set) from selection for TB transmissions that include data associated with ST and / or low latency QoS requirements. The WTRU may exclude SL resources from selection based on the condition that the deprioritization event involves data from the same priority level and / or data configured with ST and / or low latency QoS requirements. When an ST-related transmission is dropped due to preemption or prioritization by a different Uu and / or SL transmission, the WTRU may exclude such resources from transmission and / or retransmission of the dropped transmission.

[0130] The WTRU may rank the remaining available resources based on the measured quality metric of each available resource. After the above resource exclusion in Mode 2 resource selection, the WTRU may rank the remaining available resources based on the measured quality metric of each available resource to further improve reliability. In an example, the WTRU may rank the available resources in order of measured RSRP and / or RSSI and determine the set of resources with the highest RSRP and / or RSSI measurements to use for resource selection.

[0131] A WTRU may request a peer WTRU to provide inter-WTRU coordination (IUC) information for resource selection. In an example, the WTRU may request a peer WTRU to provide a preferred resource set that includes resources that the peer WTRU may prefer to receive from the WTRU's transmission. The WTRU may perform resource selection for transmissions to the peer WTRU within the received preferred resources.

[0132] The WTRU may be configured for added reliability for Mode 1. The WTRU may be configured to perform adjustments to transmission resource selection. The WTRU may be configured with multiple configured grants for SL Mode 1 transmission. Each configured grant may be configured with one or more of: a priority index, an MCS, a transmit power, and / or a determination of whether such grant may be used during and / or outside of the ST state. During the ST state, among multiple available grants, the WTRU may select the grant for transmission of another (e.g., new) transmission as: a grant with the highest reliability MCS (e.g., the lowest spectral efficiency that can accommodate an SDU without fragmentation); a grant configured with the highest transmit power; a grant preconfigured to be used in a Time to Live state (e.g., conditionally used); and / or a grant with the highest configured priority index and / or reliability level. The WTRU may ignore one of multiple available CG opportunities. For example, the WTRU may skip, drop, and / or not transmit on a CG opportunity. The time constraint may be related to the remaining time in the Time to Live timer. The WTRU may be configured to ignore a CG opportunity among multiple available CG opportunities if such an opportunity is not sufficiently reliable and / or may not satisfy the remaining lifetime timer and / or transmission duration constraints of the PDB. That is, the WTRU may use a CG opportunity that satisfies the reliability constraints and / or time constraints. The WTRU may be configured to ignore a CG opportunity even if it is the first occurrence of a CG opportunity.

[0133] Upon triggering and / or during the ST state, the WTRU may use a subset of the available configured grants. For example, the WTRU may transmit data (e.g., only) on configured grants that are configured to be used (e.g., only) conditionally during the ST state. For example, upon receiving and / or determining a HARQ NACK, the WTRU may switch to using a different CG configuration that is configured to be used during the ST state. The WTRU may duplicate a TB transmission on one or more (e.g., multiple) CGs during the ST state. For example, the WTRU may duplicate a TB transmission on one or more (e.g., multiple) CGs during the ST state, in which the duplicate TB transmission may be transmitted on a subset of CGs (e.g., those CGs that are configured to be used (e.g., conditionally used) during the ST state).

[0134] Upon receipt of a dynamic grant, a dynamic grant that triggers ST state entry (e.g., as described herein), and / or triggering of ST state, the WTRU may prioritize multiplexed data from DRBs / LCHs configured with ST and / or low latency requirements on such DGs. If another LCH has a higher LCP priority and such LCH is not configured with ST requirements, the WTRU may prioritize multiplexed data from DRBs / LCHs configured with ST and / or low latency requirements on such DGs. Upon activation of a CG that is configured to be conditionally used during ST state and / or activation of a CG that triggers ST state entry, the WTRU may prioritize transmission of transport blocks including data from LCHs / DRBs configured with ST and / or low latency QoS requirements. Upon activation of a CG that is configured to be used conditionally during the ST state and / or activation of a CG that triggers entry into the ST state, the WTRU may prioritize the retransmission of a TB including data from an LCH / DRB configured with ST and / or low latency QoS requirements over another (e.g., new) transmission without such data / QoS requirements and / or another retransmission without such data / QoS requirements.

[0135] The WTRU may be configured to report ST state triggers and / or related measurements. The WTRU may be configured to proactively report channel conditions to the network. The WTRU may report the cause and / or trigger that led to ST state entry and / or ST state triggering to the gNB. The WTRU may report channel condition measurements that increase reliability of ST state entry and / or preemption to the gNB. For example, the WTRU may report one or more of dropped transmissions due to overlap with another Uu and / or SL transmission, dropped transmissions due to CR, failure to transmit HARQ feedback and / or SCI to a peer WTRU related to ST and / or low latency QoS, and / or failure to transmit on SL resources. The WTRU may report quantities (e.g., measurements) associated with ST state triggering. In an example, the WTRU may report channel access failures (e.g., Type 1 channel access) in an RB set / subband / channel to the gNB. When the WTRU may fail to access a channel within a resource selection window, the WTRU may report channel access failures in an RB set / subband / channel to the gNB. The WTRU may include RSSI values ​​and / or CO measured in LBT sensing using the resource selection window. In an example, when the WTRU fails channel access in Mode 1, the WTRU may be triggered to perform measurements of CO / RSSI / RSRP / CBR for one or more (e.g., all) configured and / or pre-configured RB sets / subbands / channels, and / or report the results to the gNB to assist in resource allocation by the gNB in ​​Mode 1.

[0136] The WTRU may report such events or measurements upon the arrival and / or transmission of data from a DRB configured for ST and / or low latency QoS (e.g., conditionally). The WTRU may preempt reporting channel measurements (e.g., CR, CBR, RSSI, and / or CO). For example, the WTRU may report channel measurements if the measurement value is below or above a configured threshold for reporting. In an example, the WTRU may initiate reporting channel condition measurements upon the arrival of data from an LCH and / or DRB configured with a certain ST and / or low latency QoS requirement. The WTRU may initiate reporting channel condition measurements based on a configured periodicity. As described herein, the WTRU may initiate (e.g., periodically) reporting such events and / or measurements upon initiating evaluation of at least one trigger.

[0137] The WTRU may be configured to report SL transmission failures to the network. For example, if the WTRU is within coverage, the WTRU may report ST state entry to the gNB. The WTRU may (e.g., also) report ST state exit. Along with the ST state report, the WTRU may report the cause of the ST entry (e.g., the cause of the ST entry may be, for example, one of the triggers as described herein). The WTRU may report a transmission failure. For example, if the transmission includes data from a DRB configured with ST and / or low latency QoS, and / or if the transmission is governed by low latency QoS, the WTRU may report a transmission failure. For example, when a NACK is determined and / or received on the PSFCH, the WTRU may report a HARQ NACK on the PUCCH and / or PUSCH to the gNB. In an example, the WTRU may report a HARQ NACK on the PUCCH and / or PUSCH to the gNB when no feedback is received from a peer WTRU. The WTRU may report the ST state entry to the gNB portion of the PUSCH payload and / or multiplexed MAC CE. The WTRU may indicate that the ST state is enabled and / or use the added reliability embodiments as described herein.The WTRU may indicate a peer WTRU to which the transmission is intended.

[0138] In one or more cases, a WTRU may be configured with an SR configuration. The SR configuration may be used to report ST state entry and / or transmission failure associated with ST and / or low latency QoS requirements, and / or to obtain SL resources suitable for transmitting and / or retransmitting data associated with ST and / or low latency QoS requirements. The WTRU may trigger another (e.g., new) SR upon triggering the ST state, upon failing to make a transmission associated with the ST and / or low latency QoS requirements, and / or if available resources are unsuitable (e.g., as described herein) for transmitting and / or retransmitting data payload associated with the ST and / or low latency requirements (e.g., before the expiration of an ST timer). For example, unsuitable resources may include one or more available resources that do not meet one or more QoS requirements (e.g., the duration and / or end time of the transmission exceeds the remaining time in the ST timer, is associated with high interference that does not meet the LCP constraint(s) for the data to be transmitted (e.g., based on an SCI RSRP greater than a threshold), etc.). For such a newly triggered SR, the WTRU may use the SR configuration configured for the ST state reporting (e.g., the associated PUCCH resources) for transmission of such an SR. In an example, if the available resources are not reliable enough to complete the transmission and / or retransmission of data associated with ST and / or low latency QoS, the WTRU may trigger another (e.g., a new) SR. The WTRU may determine whether the available resources are reliable enough to complete the transmission and / or retransmission of the data based on: a priority index associated with the available SL resources, a determination of whether the available SL resources are large enough to accommodate the arrival of the entire SDU, a determination of whether the SL resources have caused a failure and / or ST state triggering, and / or a measured CR and / or CBR on the available SL resources is above a configured threshold. For example, the determination of whether the available resources are large enough to accommodate the arrival of the entire SDU may include determining whether the entire SDU can fit into the resource without segmentation (e.g., the number of data bits in the resource is greater than or equal to the number of bits of the SDU plus applicable sub-headers inserted in the transmission and control elements added in the transmission).

[0139] Based on a failed transmission and / or failure to receive a HARQ FB, the WTRU may be configured for ST recovery. The WTRU may be configured with one or more DRBs to which a Time-to-Live QoS requirement applies. The WTRU may determine that a transmission on SL resources has failed and / or a Time-to-Live state has been triggered for increased transmission reliability. The WTRU may determine that a transmission on SL resources has failed and / or a Time-to-Live state has been triggered based on one or more of the following: receiving a PSFCH and / or SCI indicating a failure from a peer WTRU; not receiving expected HARQ feedback for the transmission at the expected time; determining that the transmission includes at least one DRB configured with a Time-to-Live and / or Low Latency QoS requirement; discarding HARQ feedback and / or SCI for a TB received from a peer WTRU; and / or receiving a DL indication from the gNB to enter the ST state.

[0140] The WTRU may start a time-to-live timer when the time-to-live state is triggered. The WTRU may deactivate the time-to-live state when the ST timer expires. The WTRU may stop the time-to-live timer upon one or more of: receiving an ACK and / or SCI for the TB associated with the ST requirement from a peer WTRU; receiving a DL indication to exit the ST state from the gNB; and / or performing (e.g., taking) channel condition measurements below a threshold. For example, if the WTRU is within coverage, the WTRU may report the state entry to the gNB. Along with the ST state report, the WTRU may report the cause of the ST entry and / or the associated channel condition measurements.

[0141] During the Time to Live state, the WTRU may perform one or more of the following reliability-increasing procedures (e.g., methods). During the Time to Live state, the WTRU may increase the transmit power level associated with one or more other (e.g., new) SL transmissions. During the Time to Live state, the WTRU may select different SL resources (or resource pools) based on the measured CR / CBR. During the Time to Live state, the WTRU may change one or more resources used (e.g., switch to a different resource pool). During the Time to Live state, the WTRU may adjust the RSW so that the SL transmission complies with the ST remaining time. During the Time to Live state, the WTRU may activate autonomous blind retransmission / repeat. During the Time to Live state, the WTRU may prioritize the transmission of TBs with ST requirements among one or more (e.g., multiple) TBs and / or other (e.g., new) transmissions and / or retransmissions.

[0142] Although features and elements are described above in specific combinations, one skilled in the art will appreciate that each feature or element can be used alone or in combination with other features and elements. Furthermore, the methods described herein may be implemented in a computer program, software, or firmware incorporated into a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor storage devices, magnetic media (such as internal hard drives and removable disks), magneto-optical media, and optical media (such as CD-ROMs and digital versatile disks (DVDs)). A processor associated with the software may be used to implement a radio frequency transceiver for use in a WTRU, a WTRU, a terminal, a base station, an RNC, or any host computer.

Claims

1. A wireless transmit / receive unit (WTRU), comprising: A processor configured to: receiving configuration information indicating that transmission of a data radio bearer (DRB) associated with a sidelink (SL) transmission can be performed in a normal quality of service state (QoS) or in a restricted time-to-live QoS state; Starting a time-to-live timer based on channel measurements or a determination that a transmission on a configured SL resource is discarded based on a channel occupancy ratio (CR) being above a threshold; transmitting at least a first transport block (TB) based on the time-to-live timer being running, wherein the first TB includes data of a DRB in the SL according to transmission parameters corresponding to the restricted time-to-live QoS state; and Based on expiration of the time-to-live timer, at least a second TB is transmitted, wherein the second TB includes data of the DRB in the SL according to transmission parameters corresponding to the normal QoS state.

2. The WTRU of claim 1 , wherein: The channel measurement corresponds to one or more of the following: a measured channel busy rate (CBR) is higher than a threshold, a measured CR is higher than the threshold, a measured reference signal received power (RSRP) associated with received SL control information (SCI) is higher than a second threshold, or a measured channel quality indication (CQI) is less than a third threshold.

3. The WTRU of claim 1 , wherein: The transmission parameters corresponding to the restricted lifetime QoS state include one or more of the following: an adjusted resource selection window so that the second SL is transmitted within the remaining time of the lifetime timer; an increased TB priority; a determination to bypass one or more channel busy rate (CBR) congestion control constraints; a determination to bypass one or more channel occupancy rate (CR) congestion control constraints; or a reselected SL resource.

4. The WTRU of claim 1 , wherein: The processor is configured to discard transmission on the configured SL resources based on the channel measurement being above the threshold or based on the CR being above the threshold, determine to transmit the at least first TB according to transmission parameters corresponding to the restricted survival QoS state.

5. The WTRU of claim 1 , wherein: The processor is configured to start the time-to-live timer based on a preemption determination.

6. The WTRU of claim 1 , wherein: The processor is configured to start the time-to-live timer based on a perception-based determination.

7. The WTRU of claim 1 , wherein: While the time-to-live timer is running, the processor is configured to temporarily disable congestion control or CR limiting.

8. The WTRU of claim 1 , wherein: The at least a second TB is transmitted in a different resource pool.

9. The WTRU of claim 1 , wherein: The processor is further configured to stop the time-to-live timer based on receipt of an acknowledgement of the first TB or the second TB, receipt of SL control information (SCI), expiration of the time-to-live timer, receipt of an indication from a network, or one or more channel measurements.

10. The WTRU of claim 1 , wherein: When the WTRU is within coverage, the processor is further configured to send a report to a network, wherein the report includes an indication of a transmission failure, a channel busy rate (CBR) above a threshold, or the CR above the threshold.

11. A method comprising: receiving configuration information indicating that transmission of a data radio bearer (DRB) associated with a sidelink (SL) transmission can be performed in a normal quality of service state (QoS) or in a restricted time-to-live QoS state; Starting a time-to-live timer based on channel measurements or a determination that a transmission on a configured SL resource is discarded based on a channel occupancy ratio (CR) being above a threshold; transmitting at least a first transport block (TB) based on the time-to-live timer being running, wherein the first TB includes data of a DRB in the SL according to transmission parameters corresponding to the restricted time-to-live QoS state; and Based on expiration of the time-to-live timer, at least a second TB is transmitted, wherein the second TB includes data of the DRB in the SL according to transmission parameters corresponding to the normal QoS state.

12. The method according to claim 11, wherein The channel measurement corresponds to one or more of the following: a measured channel busy rate (CBR) is higher than a threshold, a measured CR is higher than the threshold, a measured reference signal received power (RSRP) associated with received SL control information (SCI) is higher than a second threshold, or a measured channel quality indication (CQI) is less than a third threshold.

13. The method according to claim 11, wherein The transmission parameters corresponding to the restricted lifetime QoS state include one or more of the following: an adjusted resource selection window so that the second SL is transmitted within the remaining time of the lifetime timer; an increased TB priority; a determination to bypass one or more channel busy rate (CBR) congestion control constraints; a determination to bypass one or more channel occupancy rate (CR) congestion control constraints; or a reselected SL resource.

14. The method according to claim 11, wherein The method further includes discarding transmission on the configured SL resources based on the channel measurement being above the threshold or based on the CR being above the threshold, determining to transmit the at least the first TB according to transmission parameters corresponding to the restricted survival QoS state.

15. The method according to claim 11, wherein The method further includes starting the time-to-live timer based on a preemption determination.

16. The method according to claim 11, wherein The method further includes starting the time-to-live timer based on the perception-based determination.

17. The method according to claim 11, wherein While the time-to-live timer is running, the method further includes temporarily disabling congestion control or CR limiting.

18. The method according to claim 11, wherein The at least a second TB is transmitted in a different resource pool.

19. The method according to claim 11, wherein The method further includes stopping the time-to-live timer based on receipt of an acknowledgement of the first TB or the second TB, receipt of SL control information (SCI), expiration of the time-to-live timer, receipt of an indication from a network, or one or more channel measurements.

20. The method according to claim 11, wherein When the WTRU is in coverage, the method further includes sending a report to a network, wherein the report includes an indication of a transmission failure, a channel busy rate (CBR) above a threshold, or the CR above the threshold.

Images