Autonomous low latency communications

Abstract

A relay wireless transmit / receive unit (WTRU) may receive a data transmission from a target WTRU. The data transmission from the target WTRU may be or may include an implicit indication that the target WTRU cannot listen to messages directed to the target WTRU. The message directed to the target WTRU may be a broadcast preemption message (BPM) and may be transmitted from a source WTRU. Based on receiving the data transmission from the target WTRU, the relay WTRU may determine that the target WTRU cannot listen to the BPM. Based on this determination, the relay WTRU may monitor the BPM. The relay WTRU may receive and decode the BPM. The relay WTRU may determine whether to relay the BPM in a message, such as a broadcast relay message (BRM). The relay WTRU may transmit the BRM to the target WTRU.

Description

[0001] Cross-references

[0002] This application claims the benefit of U.S. Provisional Application No. 62 / 741,862 filed on October 5, 2018, U.S. Provisional Application No. 62 / 790,167 filed on January 9, 2019, and U.S. Provisional Application No. 62 / 886,567 filed on August 14, 2019, the contents of which are incorporated herein by reference. Background Art

[0003] Wireless communication systems can facilitate the transmission and reception of data between devices and / or network components. The transmission and reception of data can be associated with various wireless applications, such as voice communication, multimedia distribution, machine type communication (MTC), public safety communication, and vehicle communication. Therefore, wireless communication systems can adopt technologies designed to facilitate the wireless exchange of data according to one or more applications. For example, wireless communication systems can adopt technologies designed to reduce battery consumption of wireless devices, which may be useful for MTC applications. Wireless applications can use other technologies, such as those used to support ultra-reliable low latency communication (URLLC). Summary of the invention

[0004] Systems, methods and means are described herein for a WTRU, such as a relay wireless transmit / receive unit (WTRU), to receive data transmissions from other WTRUs, such as a target WTRU. The data transmission from the target WTRU may be or may include an implicit indication that the target WTRU cannot listen for messages directed to the target WTRU. The message directed to the target WTRU may be or may include a broadcast preemption message (BPM). For example, a BPM directed to the target WTRU may stop the target WTRU from transmitting on a resource. The BPM may be transmitted from a WTRU, such as a source WTRU.

[0005] Based on receiving the data transmission from the target WTRU, the relay WTRU may determine that the target WTRU is unable to listen to messages directed to the target WTRU.

[0006] The relay WTRU may monitor messages directed to a target WTRU (eg, BPM) based on determining that the target WTRU is unable to listen to messages directed to the target WTRU.

[0007] A relay WTRU may receive messages (eg, BPMs) directed to a target WTRU.

[0008] The relay WTRU may decode a message (e.g., a BPM) directed to a target WTRU and may determine whether the message directed to the target WTRU is relayed in a message (e.g., a broadcast relay message (BRM)). For example, the relay WTRU may decode a message (e.g., a BPM) and determine the number of times the message (e.g., a BPM) has been relayed, a timestamp indicating when the message (e.g., a BPM) has been transmitted from a third WTRU, a distance between the third WTRU and the first WTRU, and / or the like.

[0009] In an example, based on the determination, the relay WTRU may transmit a message, such as a BRM, in a message directed to the target WTRU. The relay message may be or may include information about the number of times the message (e.g., BPM) has been relayed, a timestamp associated with when the message (e.g., BPM) has been transmitted from a third WTRU, and / or a distance between the third WTRU and the first WTRU, etc.

[0010] In an example, based on the determination, the relay WTRU may stop transmitting messages, such as BRMs, to the target WTRU. For example, the relay WTRU may stop transmitting BRMs to the target WTRU if the relay WTRU determines that the number of times a message directed to the target WTRU has been relayed exceeds a preconfigured counter threshold, the timestamp indicating when a message directed to the target WTRU has been transmitted from a WTRU (e.g., a source WTRU) exceeds a preconfigured time threshold, the distance between the source WTRU and the relay WTRU exceeds a preconfigured distance threshold, and / or the like.

[0011] If the relay WTRU determines to relay a message directed to a target WTRU (eg, a BPM), the relay WTRU may transmit the message (eg, a BRM) to the target WTRU.

[0012] If no message directed to the target WTRU is received, the relay WTRU may decode the data transmission from the target WTRU.

[0013] Systems, methods, and means for facilitating ultra-reliable low latency communications (URLLC) may be provided. A WTRU may be configured for a grant-free (GF) transmission that may utilize resources shared with other WTRUs. A GF transmission may include one or more attributes that may be determined and / or adjusted by the WTRU. A WTRU may be configured to preempt the transmission of one or more other WTRUs based on certain criteria, such as priority and / or latency requirements. Preemption may be indicated by a preemption indicator (PRI). Preemption may be single-level or multi-level. A WTRU may preempt other WTRUs by signaling the priority and / or latency requirements of its transmission(s), and / or by transmitting an interrupt signal. The ability of a WTRU to preempt other WTRUs on shared resources may depend on the priority of its transmission(s). A WTRU may transmit control information related to its transmission(s) and employ mechanisms for avoiding conflicts with other WTRUs on shared resources.

[0014] The target WTRU may delegate the action of listening to one or more preemption messages (e.g., preemption message(s) from the network or source WTRU) to the relay WTRU. For example, the target WTRU may delegate listening to the preemption messages when the target WTRU is not able to listen. The target WTRU may explicitly or implicitly delegate listening to the preemption messages to the relay WTRU. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0016] Figure 1B is a diagram showing that according to an embodiment, Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within a communication system is shown.

[0017] Figure 1C is a diagram showing that according to an embodiment, Figure 1A System diagram of an example radio access network (RAN) and an example core network (CN) used within a communication system is shown.

[0018] Figure 1D is a diagram showing that according to an embodiment, Figure 1A A system diagram of another example RAN and another example CN used within a communication system is shown.

[0019] Figure 2 An example relationship between control channels and shared channels in time and frequency is shown.

[0020] Figure 3An example transmission sequence is shown where a WTRU may use indications in a control channel to preempt other WTRU (eg, lower priority) transmissions.

[0021] Figure 4 An exemplary preemption indicator (PRI) transmission is shown.

[0022] Figure 5 Example PRI detection timing is shown.

[0023] Figure 6 An example of a PRI transmission opportunity within a transport block is shown.

[0024] Figure 7 An example transmission sequence is shown in which a WTRU may send (eg, interrupt) a signal to preempt other WTRUs' (eg, lower priority) transmissions.

[0025] Fig. 8A An exemplary parity-type preemption priority scheme is shown.

[0026] Figure 8B An exemplary staggered preemption priority scheme is shown.

[0027] Fig. 9 An example of a receiving WTRU alerting a transmitting WTRU of a preemption signal is shown.

[0028] Fig.10 One or more example actions associated with preemption are shown.

[0029] Fig.11 One or more example actions associated with relay preemption are shown. DETAILED DESCRIPTION

[0030] A detailed description of illustrative embodiments will now be described with reference to the accompanying drawings. Although this specification provides detailed examples of possible implementations, it should be noted that these details are intended to be exemplary and in no way limit the scope of the present application.

[0031] Wireless communication systems such as 3GPP New Radio (NR) can support a variety of use cases. Example use cases include, but are not limited to, ultra-reliable low latency communications (URLLC), massive machine type communications (mMTC), and / or enhanced mobile broadband (eMBB) communications. mMTC can support communications between low-cost, large numbers of, and / or battery-powered devices. mMTC can involve applications such as smart metering, logistics, and / or field and body sensors. URLLC can enable devices and machines to communicate with ultra-reliability, low latency, and high availability, which can facilitate vehicular communications, industrial control, factory automation, remote surgery, smart grids, public safety applications, and the like. eMBB can include improvements to other technologies, such as MBB in Long Term Evolution (LTE) and / or Advanced LTE (LTE-A).

[0032] In an example use case, a central node (e.g., Node B (NB), eNB, gNB, etc.) may serve one or more wireless devices or wireless transmit / receive units (WTRUs). The ability of a WTRU to transmit one or more transport blocks (TBs) may be managed by the central node. The central node may schedule individual WTRU transmissions by, for example, assigning and / or granting separate time-frequency resources to each WTRU. This arrangement for data transmission may be referred to as authorization-based transmission. Communication between two nodes (e.g., between two WTRUs) may occur outside of a scheduled authorization. In this case, the WTRU may transmit or receive data (e.g., one or more TBs) with limited or no involvement of the central node, such as when the WTRU is outside the wireless coverage of the central node. Direct data exchange between two WTRUs may have low latency properties.

[0033] Low latency communications may be used to facilitate various wireless applications, such as public safety communications, vehicular communications, etc. Low latency communications may or may not be managed by a central node such as a gNB. Autonomous low latency (ALL) communications may support use cases where inter-WTRU communications are managed by limited central nodes or do not involve a central node. For example, ALL may be used to facilitate vehicular communications when the vehicle is out of coverage of a central node and / or when information exchange between vehicles can occur with minimal latency.

[0034] To facilitate low latency communications, the WTRU may be configured for grant-free (GF) or configured grant (CG) uplink (UL) transmissions. A central node such as a gNB may assign time-frequency resources to one or more WTRUs, which may transmit one or more corresponding TBs via the assigned resources. The GF transmission may include one or more attributes that may or may not be managed by the central node. The attributes may include a K-repetition feature, where a TB may be sent by repetition on K GF resources before a response (e.g., an acknowledgement (ACK) or a negative acknowledgement (NACK)) is received or expected to be received from the central node.

[0035] The central node may manage the attribute(s) of the GF transmission by any appropriate mechanism, such as by radio resource control (RRC) configuration or by downlink control information (DCI). In the ALL communication use case, one or more attributes of the GF transmission may not be managed by the central node. Thus, a WTRU attempting to transmit or receive data may employ (e.g., additional) mechanisms to determine the need for attributes and / or attribute adjustments. The WTRU may adjust the attribute(s) and / or notify other WTRUs of the attribute(s) and / or attribute adjustments.

[0036] GF transmissions utilizing K repetitions may achieve higher reliability because repeated transmission of information may increase the likelihood of successfully receiving the information. This may be useful in various applications, such as in vehicular communications. As more WTRUs attempt to utilize GF transmissions and / or the K repetition feature, the likelihood of data collisions may increase, which may negatively impact reliability. For example, if vehicular traffic is slow and / or there are multiple vehicles in close proximity to each other, the transmission load for each vehicle may be high. Thus, a vehicle's GF transmission may not be successfully received due to collisions with GF transmissions from one or more other nearby vehicles.

[0037] Preemption techniques have been used to facilitate low latency communications. Such techniques may be managed by a central node. In situations where a central node is not involved in managing UL resources, such as in situations where a vehicle employs ALL communications, preemption may be managed by one or more WTRUs (e.g., vehicles) communicating with each other.

[0038] Control content related to the transmission of a TB may be transmitted to the WTRU that is the intended recipient of the TB. In ALL communications, some or all of the control content may or may not be known in advance, depending on whether the transmission is broadcast or unicast. Certain portions of the control content may need to be known before other portions of the control content. Some portions of the control content may appear in the DCI or UCI. Other portions may be configured by the RRC entity.

[0039] In autonomous communications, there is a possibility of collisions during transmissions of more than one WTRU. The impact of collisions may be more pronounced in low latency transmissions.

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

[0041] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, Internet 110, and other networks 112, although it should be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network components. Each WTRU 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, any of the WTRUs 102a, 102b, 102c, 102d may be referred to as a “station” and / or “STA”, which may be configured to transmit and / or receive wireless signals, and may include a 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 smart phone, 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 devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices working in an industrial and / or automated process chain environment), consumer electronic devices, and devices working on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, 102d may be interchangeably referred to as a UE.

[0042] The communication system 100 may also include a base station 114a and / or a base station 114b. Each base station 114a and / or base station 114b may be any type of device configured to facilitate access to one or more communication networks (e.g., CN 106 / 115, Internet 110, and / or other networks 112) by wirelessly interfacing with at least one of the WTRUs 102a, 102b, 102c, 102d. For example, the base stations 114a, 114b may be base transceiver stations (BTS), Node Bs, eNode Bs, Home Node Bs, Home eNode Bs, gNBs, NR Node Bs, site controllers, access points (APs), wireless routers, and the like. Although each base station 114a, 114b is depicted as a single component, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network components.

[0043] The base station 114a may be part of the RAN 104 / 113, and the RAN may also include other base stations and / or network components (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, and the like. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies called cells (not shown). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage for a specific geographic area that is relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, a cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., each transceiver corresponds to a sector of the cell. In an embodiment, the base station 114a may use multiple-input multiple-output (MIMO) technology, and may use multiple transceivers for each sector of the cell. For example, by using beamforming, signals may be transmitted and / or received in a desired spatial direction.

[0044] 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, millimeter wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0045] More specifically, as described above, the communication system 100 may be a multiple access system and may use one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA, among others. 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 use Wideband CDMA (WCDMA) to establish the air interface 115 / 116 / 117. 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).

[0046] In an 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 Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro).

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

[0048] In an 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 sent to / from multiple types of base stations (e.g., eNBs and gNBs).

[0049] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (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), and GSM EDGE (GERAN), among others.

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

[0051] 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 WTRUs 102a, 102b, 102c, 102d. The 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 calls, Internet connectivity, video distribution, etc., and / or may 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 or a different RAT as the RAN 104 / 113. For example, in addition to being connected to the RAN 104 / 113 employing NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) employing GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0052] The CN 106 / 115 may also act 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 network devices that use common communication protocols, such as TCP, User Datagram Protocol (UDP), and / or IP in the Transmission Control Protocol / Internet Protocol (TCP / IP) Internet protocol suite. The networks 112 may include wired 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, where the one or more RANs may use the same RAT or a different RAT as the RAN 104 / 113.

[0053] 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 over different wireless links). Figure 1A The illustrated WTRU 102c 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.

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

[0055] 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, and the like. 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, however it should be appreciated that the processor 118 and the transceiver 120 may also be integrated into one electronic component or chip.

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

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

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

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

[0060] The processor 118 may receive power from the power source 134, and may be configured to distribute and / or control power for use by 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 (Ni-Cd), nickel-zinc (Ni-Zn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0061] 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) related to the current location of the WTRU 102. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) via the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be appreciated that the WTRU 102 may acquire location information via any suitable positioning method while remaining consistent with an embodiment.

[0062] 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 videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, module, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game console module, an Internet browser, a virtual reality and / or augmented reality (VR / AR) device, and an activity tracker, etc. The peripheral device 138 may include one or more sensors, which may be one or more of the following: 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.

[0063] The WTRU 102 may include a full-duplex radio in which the reception or transmission of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous for the radio. A full-duplex radio may include an interference management unit that reduces and / or substantially eliminates self-interference by means of hardware (e.g., chokes) or by signal processing by a processor (e.g., a separate processor (not shown) or by the processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio that transmits or receives some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) or downlink (e.g., for reception)).

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

[0065] The RAN 104 may include eNode-Bs 160a, 160b, 160c, however it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. Each of the eNode-Bs 160a, 160b, 160c may 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.

[0066] Each eNodeB 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, the eNode-Bs 160a, 160b, 160c may communicate with each other via an X2 interface.

[0067] Figure 1C The illustrated CN 106 may include a mobility management gateway (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. Although each of the foregoing components is described as being part of the CN 106, it should be appreciated that any of these components may be owned and / or operated by an entity other than the CN operator.

[0068] 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, performing bearer activation / deactivation processing, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, etc. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that use other radio technologies, such as GSM or WCDMA.

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

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

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

[0072] Although in Figures 1A-1D Although the WTRU is described as a wireless terminal, it should be appreciated that in certain typical embodiments, such a terminal may use a (eg, temporary or permanent) wired communication interface with a communication network.

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

[0074] A WLAN using an 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 be connected to a distributed system (DS) or other types of wired / wireless networks that send services into and / or out of the BSS. Services originating from outside the BSS and destined for the STA may be reached by the AP and delivered to the STA. Services originating from the STA and destined for a destination outside the BSS may be sent to the AP for delivery to the corresponding destination. Services between STAs within the BSS may be sent by the AP, for example, when the source STA may send services to the AP and the AP may deliver services to the destination STA. Services between STAs within the BSS may be considered and / or referred to as point-to-point services. The point-to-point services may be sent using a direct link establishment (DLS) between the source and destination STAs (e.g., directly therebetween). In certain typical embodiments, the DLS may use 802.11eDLS or 802.11z tunneled DLS (TDLS)). A WLAN using an independent BSS (IBSS) mode does not have an AP, and STAs (eg, all STAs) within or using the IBSS can communicate directly with each other. Here, the IBSS communication mode may sometimes be referred to as an "ad-hoc" communication mode.

[0075] When using the 802.11ac infrastructure mode of operation or a similar mode of operation, the AP may transmit a beacon on a fixed channel (e.g., a primary channel). The primary channel may have a fixed width (e.g., a bandwidth of 20 MHz) or a width that is dynamically set with the aid of signaling. The primary channel may be an operating channel of the BSS and may be used by STAs to establish a connection with the AP. In certain typical embodiments, carrier sense multiple access with collision avoidance (CSMA / CA) (e.g., in an 802.11 system) may be implemented. For 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. In a given BSS, there is one STA (e.g., only one station) transmitting at any given time.

[0076] A high throughput (HT) STA may communicate using a 40 MHz wide channel, for example, by combining a 20 MHz wide primary channel with a 20 MHz wide adjacent or non-adjacent channel to form the 40 MHz wide channel.

[0077] Very high throughput (VHT) STA can support channels with widths of 20MHz, 40MHz, 80MHz and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining continuous 20MHz channels. 160MHz channels can be formed by combining 8 continuous 20MHz channels or by combining two discontinuous 80MHz channels (this combination can be referred to as 80+80 configuration). For the 80+80 configuration, after channel coding, the data can be transmitted and passed through a segment parser, which can divide the data into two streams. Inverse fast Fourier transform (IFFT) processing and time domain processing can be performed separately on each stream. The stream can be mapped on two 80MHz channels, and the data can be transmitted by the STA performing the transmission. At the receiver of the STA performing the reception, the above operations for the 80+80 configuration can be opposite, and the combined data can be sent to the media access control (MAC).

[0078] 802.11af and 802.11ah support working modes below 1 GHz. Compared with 802.11n and 802.11ac, the channel working bandwidth and carrier used in 802.11af and 802.11ah are reduced. 802.11af supports 5MHz, 10MHz and 20MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz and 16MHz bandwidths using non-TVWS spectrum. According to a typical embodiment, 802.11ah can support instrument type control / machine type communication (such as MTC devices in macro coverage areas). MTC devices can have certain capabilities, such as limited capabilities including support (for example, only support) certain and / or limited bandwidths. MTC devices can include a battery, and the battery life of the battery is higher than a threshold (for example, for maintaining a very long battery life).

[0079] For WLAN systems that can support multiple channels and channel bandwidths (e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah), these systems include channels that can be designated as primary channels. 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 a certain STA, wherein the STA originates from all STAs operating in the BSS and supports the minimum bandwidth operating mode. In the example of 802.11ah, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes, for STAs (e.g., MTC-type devices) that support (e.g., only support) 1MHz mode, the width of the primary channel can be 1MHz. Carrier sensing and / or network allocation vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy (e.g., because a STA (which only supports the 1MHz operating mode) transmits to the AP), then even if most of the frequency band remains idle and available for use, the entire available frequency band can be considered busy.

[0080] In the United States, the available frequency band for 802.11ah is 902MHz to 928MHz. In South Korea, the available frequency band is 917.5MHz to 923.5MHz. In Japan, the available frequency band is 916.5MHz to 927.5MHz. Depending on the country code, the total bandwidth available for 802.11ah is 6MHz to 26MHz.

[0081] Figure 1D 1 is a system diagram showing the RAN 113 and the CN 115 according to an 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.

[0082] The RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. Each of the gNBs 180a, 180b, 180c may include one or more transceivers to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 180b, 180c may use beamforming processing to transmit and / or receive signals to and / or from the gNBs 180a, 180b, 180c. Thus, for example, the gNB 180a may use multiple antennas to transmit wireless signals to the WTRU 102a, and receive wireless signals from the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation techniques. 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 an unlicensed spectrum, while the remaining component carriers may be on a licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) techniques. For example, the WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0083] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with the scalable parameter configurations. 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 radio transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of different or scalable lengths (e.g., containing different numbers of OFDM symbols and / or lasting different absolute time lengths).

[0084] 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., the eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use 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 band. In a non-standalone configuration, the WTRU 102a, 102b, 102c may communicate / connect to the gNB 180a, 180b, 180c while communicating / connecting to another RAN (e.g., the eNode-B 160a, 160b, 160c). For example, the WTRU 102a, 102b, 102c may communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c in a substantially simultaneous manner by implementing the DC principle. In a non-standalone configuration, the eNode-B 160a, 160b, 160c may act as a mobility anchor for the WTRU 102a, 102b, 102c, and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput to serve the WTRU 102a, 102b, 102c.

[0085] Each gNB 180a, 180b, 180c 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, support network slicing, implement dual connectivity, implement interworking between NR and E-UTRA, route user plane data to user plane functions (UPFs) 184a, 184b, and route control plane information to access and mobility management functions (AMFs) 182a, 182b, and the like. Figure 1D As shown, gNBs 180a, 180b, and 180c can communicate with each other through the Xn interface.

[0086] Figure 1DThe CN 115 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and may include a data network (DN) 185a, 185b. Although each of the aforementioned components is described as part of the CN 115, it should be understood that any of these components may be owned and / or operated by entities other than the CN operator.

[0087] The AMF 182a, 182b may be connected to one or more 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, and mobility management, etc. The AMF 182a, 182b may use network slicing processing to customize the CN support provided to the WTRU 102a, 102b, 102c based on the type of service used by the WTRU 102a, 102b, 102c. As an 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, and / or services for machine type communication (MTC) access, etc. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) using other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0088] The SMF 183a, 183b may be connected to the AMF 182a, 182b in the CN 115 via the N11 interface. The SMF 183a, 183b may also be connected 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 may configure service routing through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy implementation and QoS, and providing downlink data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0089] The UPF 184a, 184b may be connected to one or more gNBs 180a, 180b, 180c in the RAN 113 via the N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks (e.g., 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, and providing mobility anchoring processing, etc.

[0090] 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. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired 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 via an N3 interface connected to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b and through the UPF 184a, 184b.

[0091] In view of Figures 1A-1D and about Figures 1A-1D , one or more or all of the functions described herein with respect to one or more of the following may be performed by one or more emulation devices (not shown): WTRU 102a-d, base station 114a-b, eNodeB 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or one or more of any other devices described herein. An emulation device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0092] The simulation device can be designed to implement one or more tests about other devices in a laboratory environment and / or an operator network environment. For example, the one or more simulation devices can perform one or more or all functions while being implemented and / or deployed as a part of a wired and / or wireless communication network in whole or in part to test other devices inside the communication network. The one or more simulation devices can perform one or more or all functions while being temporarily implemented or deployed as a part of a wired and / or wireless communication network. The simulation device can be directly coupled to other devices to perform the test, and / or can use over-the-air wireless communication to perform the test.

[0093] One or more simulation devices can perform one or more functions, including all functions, while not being implemented or deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test lab and / or a test scenario of a wired and / or wireless communication network that is not deployed (e.g., testing) to implement tests on one or more components. The one or more simulation devices can be test devices. The simulation device can transmit and / or receive data using direct RF coupling and / or wireless communication with the aid of RF circuits (as an example, the circuits can include one or more antennas).

[0094] A WTRU may be configured with one or more types of grant-free (GF) uplink (UL) transmissions having one or more attributes. In an exemplary type I GF UL transmission, the WTRU may be configured to access GF resources via RRC configuration. In an exemplary type II GF UL transmission, the WTRU may be configured to access GF resources via RRC configuration and / or DCI signaling. Access to GF resources may be activated, deactivated, or reactivated via RRC configuration and / or DCI signaling.

[0095] GF UL transmissions may be configured for slot-based and / or mini-slot-based transmissions. Acknowledgements, hybrid automatic repeat request (HARQ) feedback, and retransmissions may be provided, such as grant-based TB retransmissions after a GF transmission failure and / or GF transmissions of TBs with up to K repetitions (e.g., K=8) on (e.g., consecutive) GF resources. GF ​​transmissions may be terminated before the K repetitions are completed when the WTRU receives an acknowledgment indication (e.g., an implicit acknowledgment indication).

[0096] The GF UL transmission may include HARQ attributes (e.g., implicit HARQ attributes), such as no explicit HARQ-ACK feedback. The feedback may be implicit using the New Data Indicator (NDI) field in the DCI format, which may explicitly indicate the UL HARQ process identification (ID). The HARQ ID may be derived from the selected resources. For example, the HARQ process ID may be derived as follows: HARQ process ID = round down (X / UL-TWG-periodicity) mod UL-TWG-numbHARQproc.

[0097] X may include the symbol index of the start of the repetition bundle. X may be derived as follows: X = (SFN * SlotPerFrame * SymbolPerSlot + Slot_index_In_SF * SymbolPerSlot + Symbol_Index_In_Slot)).

[0098] The HARQ redundancy version (RV) sequence may be obtained from a configuration, which may include RV cycles and / or RV0 repetitions.

[0099] GF UL transmissions may be periodic with one or more repeated transmission opportunities in each period. The transmission opportunities may have (e.g., be bound to) an RV sequence, such as {0, 2, 3, 1}, {0, 3, 0, 3}, and / or {0, 0, 0, 0}. The initial repeated transmission may start with RV0. The timing of repeated transmissions may be flexible.

[0100] There may be a relative time-frequency relationship between the control channel and the shared channel, which may be used to transmit control information and user data, respectively. Figure 2 An example relationship between the control channel and the shared channel in time and frequency is shown. For example, Figure 2 A pattern showing the relative positions of a control channel (e.g., a physical sidelink control channel (PSCCH)) and an associated shared channel (e.g., a physical sidelink shared channel (PSSCH)). The control and shared channels may be part of a wireless network employing NR technology, for example. Figure 2 As shown in Mode 1A, the control channel may appear (e.g., appear immediately) before the shared channel. The control and shared channels may each span one or more OFDM symbols. The shared channel may span a greater number of symbols than the control channel. The control and shared channels may span the same number of frequencies or resource blocks.

[0101] exist Figure 2In the illustrated mode 1B, the control channel may appear (eg, appear immediately) before the shared channel. The frequency span of the control channel may include a subset of the frequency span of the shared channel.

[0102] exist Figure 2 In the illustrated mode 2, the control channel may appear during the same OFDM symbol as the shared channel. The frequency span of the control channel may be different from the frequency span of the shared channel. For example, the control channel may appear at the edge of the shared channel.

[0103] exist Figure 2 In mode 3 shown, the control channel can be within the shared channel.

[0104] Autonomous low latency (ALL) communications can be implemented in one or more use cases, such as vehicle communications. ALL communications of vehicles can be used when the vehicle is outside the wireless coverage of a central node (e.g., a gNB). A platoon can be part of a collaborative driving use case where vehicles can move in the same direction in the same lane (or different lanes). Vehicles can maintain a (e.g., small) relatively constant inter-vehicle distance, which can help vehicles reduce fuel consumption and / or achieve safe and efficient transportation. Vehicles can include one or more sensors and can exchange one or more sensor outputs with each other (e.g., using an ALL communication framework). For example, a vehicle can notify other vehicles about an unexpected event in the road, which can enable other vehicles to plan actions (e.g., separate actions). As a platoon, vehicles can plan synchronized actions.

[0105] A GF transmission may include one or more adaptive attributes. A central node (e.g., a gNB) may manage the attribute(s) of a GF transmission, for example, by configuring the attribute(s) via RRC or adjusting the attribute(s) via DCI. In the event that the attribute(s) are not managed by the central node, for example, during ALL communications, the WTRU may undergo additional mechanisms to adjust the attribute(s) of the GF communication.

[0106] For example, if the WTRU is out of the wireless coverage of the central node, the WTRU may determine the attribute(s) of the GF transmission. The WTRU may be in a vehicle-to-everything (V2X) mode (e.g., V2X Mode 2). The WTRU may determine a value for K repetitions, such as a default value. The value of K may indicate the number of repetitions (e.g., a large number). If the WTRU attempts to transmit in a lower density area with fast-moving WTRUs (e.g., vehicles), a large number of repetitions may help achieve high (e.g., higher) reliability. In dense environments where vehicles move slowly, and / or when the WTRU has a large amount of data to transmit, a large number of repetitions may have a negative impact on transmission reliability. A large number of repetitions may result in more data collisions, which may reduce reliability.

[0107] The WTRU may start with a value for K repetitions, such as an intermediate value. In a particular case, whether the value of K is considered to be medium, high, or low may depend on one or more factors, such as transmission priority and / or reliability level. The WTRU may monitor one or more indicators at a given instance and / or over a period of time. The indicator may include one or more of the following: success rate of unicast transmissions; channel utilization; and / or the number of different WTRUs utilizing a channel over a (e.g., past) time unit or time interval. For example, the success rate of unicast transmissions may include the number of ACKs averaged over a unit of time, etc. For example, channel utilization may include the number of time-frequency resources occupied by other WTRUs, averaged over a unit of time, and / or the like. The WTRU may compare one or more of the aforementioned indicators with corresponding thresholds. Based on the result of the comparison, the WTRU may determine to reduce the value of K repetitions, increase the value of K repetitions, and / or keep the value of K repetitions unchanged.

[0108] In an example, if the number of confirmed unicast TBs sent by the WTRU is below a threshold, the WTRU may increase the K repetition value. If the number of confirmed unicast TBs sent by the WTRU is above a threshold, the WTRU may decrease the K repetition value. If the number of confirmed unicast TBs sent by the WTRU is approximately equal to (e.g., equal to) the threshold, the WTRU may not change the K repetition value. The WTRU may continue to monitor the number of received ACKs to determine whether to further adjust the K repetition value.

[0109] In an example, the WTRU may measure the (e.g., overall) utilization of the channel to determine the ratio of the WTRU's own transmission to the overall channel utilization. A ratio above a threshold may indicate that the WTRU may use a higher proportion of GF resources (e.g., higher than what may be considered a fair proportion of GF resources). The WTRU may reduce the K repetition value to reduce the ratio.

[0110] Additionally and / or alternatively, the WTRU may take into account the number of WTRUs (e.g., different WTRUs) that are using the channel. For example, the number of different WTRUs that are utilizing the channel may indicate the extent to which the WTRUs are competing for GF resources. The WTRU may use the number of WTRUs utilizing the channel to determine whether to adjust the K repetition value. For example, if the number of WTRUs utilizing the channel is below a threshold, the WTRU may adjust the K repetition value higher. If the number of WTRUs utilizing the channel is above a threshold, the WTRU may adjust the K repetition value lower. If the number of WTRUs utilizing the channel is approximately equal to the threshold, the WTRU may not change the K repetition value. The WTRU may keep monitoring the number of WTRUs utilizing the channel. The WTRU may re-evaluate / adjust the K repetition value, for example based on its estimation.

[0111] To obtain the number of WTRUs (e.g., different WTRUs) utilizing the channel, the WTRU may track one or more attributes of the received signal / channel. The one or more attributes may be averaged over a (e.g., sliding) unit time interval. For example, the WTRU may track: the number of WTRU ID(s) detected in a received sidelink channel (e.g., unique WTRU ID(s)); the number of DMRS sequences detected in a received sidelink channel (e.g., unique DMRS sequences); the number of attempts made by a WTRU (e.g., unique WTRU) for sidelink synchronization; and / or the number of discovery signals received (e.g., unique received discovery signals).

[0112] Reducing the number of K repetitions (e.g., the K repetition value) may or may not reduce the reliability of the WTRU transmission. If the reduction in K repetitions reduces the transmission reliability, the WTRU may adjust one or more other parameters, for example, to compensate (e.g., increase transmission reliability).

[0113] For example, the WTRU may reduce the modulation and coding scheme (MCS), for example by reducing the modulation and / or increasing the coding rate of the information being transmitted. Reducing the MCS may result in additional resources being required for each transmission. If the amount of resources remains the same, the amount of data that can be sent may be reduced and / or limited. The WTRU may limit transmissions to high priority information, for example to ensure that the WTRU can increase the coding rate and / or reduce the MCS.

[0114] A first WTRU may receive discovery channel transmission(s) of at least one other WTRU. The first WTRU may perform measurements to evaluate the quality of a link between the first WTRU and the transmitting WTRU(s). If the first WTRU intends to initiate a transmission with one of the identified WTRU(s), the first WTRU may select and / or use an initial repetition value based on the measurements performed. The repetition value may be adapted (e.g., after selecting and / or using an initial repetition value) using the techniques(s) described herein and / or using channel state information (CSI) feedback or measurements.

[0115] The WTRU may adjust power control (eg, loop ID, P0-PUSCH alpha, etc.) It should be appreciated that the WTRU may adjust other parameters of the GF transmission, such as MCS and / or power control, in a manner similar to the adjustment mechanism of the K repetition value.

[0116] GF transmissions between WTRUs, such as those occurring as part of ALL communications, may include the exchange of autonomous feedback information (AFI) (or sidelink feedback information). The AFI may be transmitted within the PSCCH.

[0117] The receiving WTRU may participate in ALL communications with an initiating (e.g., transmitting) WTRU and may send a control channel transmission to the initiating WTRU to suggest alternative attributes of communications (e.g., upcoming communications) between the WTRUs. For example, the initiating WTRU may have started one or more GF transmissions with a K repetition value (e.g., a maximum K repetition value). The receiving WTRU may suggest an alternative K repetition value (e.g., a lower K repetition value) to the initiating WTRU, for example, via a control channel.

[0118] As described above, WTRUs (e.g., vehicles) may be moving in the same lane (or different lanes) in the same direction, which may be referred to as a queue. QoS for WTRU transmissions may be maintained across layers. In the physical layer, at least some aspects of QoS may be maintained through ACK and / or HARQ mechanisms (one or more).

[0119] For example, the initiating or transmitting WTRU may assign a HARQ ID to the TB. One or more of the receiving WTRU(s) may: receive the TB; receive the TB without error; receive the TB in error; and / or receive some code blocks in error. In this way, the transmitting WTRU may keep the transport block in its buffer for a preconfigured duration. The transmitting WTRU may retransmit the code blocks, TBs, and / or portions of the TBs that were identified as not correctly received in the (e.g., separate) HARQ feedback from the receiving WTRU(s) (e.g., during a preconfigured duration). After the preconfigured duration expires, the WTRU may discard the TB.

[0120] ALL communications may be preempted. Communications between WTRUs, such as vehicular communications, may involve transmissions with different priorities and / or latency service requirements. A WTRU may have data or information to transmit that is considered to be of high priority (e.g., relative to data or information from other WTRUs) and / or may have latency requirements (e.g., strict latency requirements). If there is no central node (e.g., a gNB) managing high priority and / or low latency transmissions, the WTRU may signal other WTRUs that the WTRU has high priority and / or low latency data for transmission. The WTRU may monitor a GF resource (e.g., a channel) and if one or more other WTRUs have priority data (e.g., higher priority data than the WTRU) and / or low latency requirements (e.g., more stringent low latency requirements than the WTRU), the WTRU vacates the resource.

[0121] One or more WTRUs may use dedicated resources or channels in the sidelink (e.g., PSCCH) to handle high priority and / or low latency requirements. The WTRU may use a group common PSCCH (GC-PSCCH) and may be configured with or aware of a default location of the GC-PSCCH. A WTRU with high priority and / or low latency data may send a GC-PSCCH with one or more attributes (e.g., priority value, whether the transmission is unicast / multicast or broadcast, expected WTRU ID in the case where the transmission is unicast, expected group ID in the case where the transmission is multicast, etc.). The WTRU may indicate the resource ID, time reference, and / or duration of the channel that the WTRU intends to use to transmit high priority and / or low latency data. As Figure 3 As shown, the WTRU may send the GC-PSCCH more than once in the configured / default search space for the GC-PSCCH, which may facilitate other WTRUs to detect the GC-PSCCH. The WTRU may repeat the GC-PSCCH in the configured / default search space. The WTRU may repeat the GC-PSCCH when the WTRU transmits high priority and / or low latency data over the PSSCH. When sending one or more GC-PSCCHs, the WTRU may adjust the time attribute in the GC-PSCCH that indicates the duration of the high priority and / or low latency data in the PSSCH transmission.

[0122] If a WTRU has a lower priority and / or less stringent latency requirement (e.g., relative to other WTRUs), the WTRU may yield to one or more other WTRUs (e.g., WTRUs with higher priority and / or more stringent latency requirements). Before transmitting in a timeslot (e.g., each timeslot), the WTRU may monitor one or more OFDM symbols (e.g., the first few OFDM symbols) within a timeslot corresponding to a search space for the GC-PSCCH. If the GC-PSCCH includes an indication of high priority and / or low latency data traffic, the WTRU may detect the indication and abandon data transmission in the timeslot. The WTRU may refrain from transmitting data in the next timeslot and / or multiple subsequent timeslots based on one or more attributes of the high priority data identified in the GC-PSCCH.

[0123] Figure 3An example is shown in which a WTRU (e.g., comprising a user equipment (UE)) may refrain from transmitting data based on an indication in a GC-PSCCH regarding high priority and / or low latency data. WTRU1 and WTRU2 may have resource allocations from an allocation mechanism and may participate in data transmission. In each time slot, WTRU1 and WTRU2 may perform a GC-PSCCH search. If WTRU1 and WTRU2 do not detect a GC-PSCCH indicating high priority and / or low latency data, WTRU1 and WTRU2 may transmit (e.g., continue to transmit) their respective data, e.g., during time slots n and n+1, such as Figure 3 If one or both WTRUs detect a GC-PSCCH indicating high priority and / or low latency data, the WTRUs may abandon their respective transmissions. Figure 3 As shown, WTRU1 and WTRU2 may detect a GC-PSCCH during timeslot n+2 indicating high priority and / or low latency data from WTRU3. Depending on the capabilities and / or configurations of WTRU1 and WTRU2, WTRU1 and WTRU2 may stop their transmissions in the same timeslot (e.g., timeslot n+2) in which the GC-PSCCH is detected and / or in one or more subsequent timeslots (e.g., timeslot n+3, timeslot n+4, etc.). WTRU3 may start transmitting in timeslot n+2 or n+3.

[0124] Multiple WTRUs may have high priority and / or low latency data transmissions. The WTRUs may send GC-PSCCH during the same time slot, which may increase the likelihood of collisions. Thus, multiple search spaces may be assigned / configured for transmission of GC-PSCCH. A WTRU (e.g., each WTRU) may select (e.g., randomly select) one of the configured / default locations to transmit a GC-PSCCH indicating high priority traffic.

[0125] Preemption may be indicated using a preemption indicator (PRI). One or more of the following may apply.

[0126] The PSCCH may include at least two levels (e.g., PSCCH-I and PSCCH-II), e.g. Figure 4 shown. Figure 4An example PRI transmission is shown. The first level (PSCCH-I) may carry control channel information (e.g., limited control channel information). For example, the PSCCH-I may include one or more of the following: the location of the second level control channel (PSCCH-II), information associated with a reserved resource pool, traffic type, etc. The PSCCH-I, or PSCCH-I together with PSCCH-II, may serve as a reservation signal, for example, a WTRU decoding a PSCCH-I transmission from a first WTRU will be able to receive information about which resources and / or how long those resources are reserved by the first WTRU. The PSCCH-I and / or PSCCH-II may be sent in a configured CORESET set within the accessed resource pool.

[0127] In an example, the preemption indication signal (PRI) may include at least one level (eg, one level) and may be sent before the PSCCH, e.g., as Figure 4 As shown. Figure 4 In the embodiment, PRI may include two levels, for example, PRI-I and PRI-II. Figure 4 are example representations of possible slot formats and / or PRIs, PSCCHs, and / or PSSCHs that may not be transmitted by the same WTRU. A PRI may be transmitted by a WTRU that intends to preempt a resource pool with another WTRU (e.g., another WTRU that has already gained access to the resource pool). Without loss of generality and for purposes of example, a WTRU that intends to preempt a resource pool with another WTRU may be referred to as a "URLLC-WTRU" and a WTRU whose transmission is preempted may be referred to as a "non-URLLC-WTRU".

[0128] The PRI may be a level and one or more of the following may apply. If detected by a non-URLLC-WTRU, the PRI may indicate that the resource pool in which the PRI is transmitted is reserved for the URLLC-WTRU, for example, the non-URLLC-WTRU may not perform transmissions within the resource pool. The resource pool may be slot-based or non-slot-based. If detected by a non-URLLC-WTRU, the PRI may indicate that a set of preconfigured resources in the resource pool is reserved for the URLLC-WTRU, in which the PRI is transmitted, for example, the non-URLLC-WTRU may not perform transmissions in these resources. More than one resource set within a resource pool may be pre-occupied. Each respective resource set may be associated with a respective PRI. The detection of a PRI may indicate the preemption of associated resources. Different PRIs may be distinguished by at least one of the following: an index of the CORESET on which the PRI is transmitted; a physical layer attribute, such as a frequency position of the PRI; an associated sequence index; an associated cyclic shift index; and the like. The PRI may include information associated with the resources preempted by the URLLC-WTRU within the resource pool.

[0129] The PRI may include at least two levels. Hereinafter, for the purpose of explanation, it may be assumed that the PRI includes two levels, such as PRI-I and PRI-II. These techniques may be similarly applicable to situations where the PRI includes more than two levels. PRI-I may indicate that the URLLC-WTRU will preempt the planned / ongoing transmission of the non-URLLC-WTRU. PRI-I may indicate the location of the PRI-II. PRI-II may contain information related to the location (one or more) of the resources intended to be used by the URLLC-WTRU, the transmission attributes of the URLLC-WTRU, and the like.

[0130] The following may be applied to the technique(s) applicable to a WTRU (e.g., a non-URLLC-WTRU) whose transmissions are preempted. A resource pool may be configured with the attribute "preemptible". When a non-URLLC-WTRU gains access to a resource pool with this attribute, the non-URLLC-WTRU may assume that its transmissions in the resource pool may be preempted by another WTRU (e.g., a URLLC-WTRU). The non-URLLC-WTRU may be configured to detect possible PRI transmissions of the URLLC-WTRU, for example for preemption information. In TDD mode, the WTRU may not be able to transmit and receive simultaneously. Figure 5 Example PRI detection timing is shown. A non-URLLC WTRU may have to switch to receive mode during OFDM symbols where PRI transmissions may occur. Figure 5As shown, PRI detection may take several OFDM symbols. A portion of the OFDM symbol or at least one OFDM symbol may be allocated for possible Tx / Rx transition time and automatic generation control (AGC) stabilization; one or more OFDM symbols may be allocated for actual PRI reception. Depending on the content of the PRI and / or whether the PRI is detected, the non-URLLC-WTRU may spend some time for the Rx / Tx transition, and the non-URLLC-WTRU may start transmission of the PSCCH and PSSCH, for example, if possible.

[0131] A non-URLLC-WTRU that has gained access to a resource pool may attempt to detect a PRI and decode its contents, such as the contents of a PRI-I and possibly a PRI-II (if detected, for example).

[0132] In the example, the resource pool is preemptible, but the URLLC-WTRU does not transmit a PRI. Figure 6 An example of a PRI transmission opportunity within a transport block is shown. Figure 6 An example of possible PRI transmission opportunities for a URLLC-WTRU is shown, and how these opportunities conflict with the time / frequency resources reserved for the transmission of a transport block (TB) by a non-URLLC-WTRU. If no PRI is expected, the non-URLLC-WTRU may start and complete the transmission of the TB. If a PRI transmission is possible, the non-URLLC-WTRU may stop its transmission and switch to receive mode, for example when there is a possibility of a PRI, such as Figure 6 As shown in the example in, and the transmission of the TB can be interrupted. The size of the TB can be constructed so that it allows for resource loss for possible PRI detection interruption (for example, the TB is prepared to accommodate not including resources that can be used for PRI detection). When mapping the TB to the resources, the resources allocated for PRI detection can be skipped. The size of the TB can be such that it does not take into account resource loss for possible PRI detection interruption. When mapping the TB to the resources, the bits that can be mapped to the resources allocated for PRI detection can be punctured. When the PRI includes two levels, the TB can be prepared according to one of the above; the TB can take into account PRI-I, for example, only PRI-I. Similar techniques can be applied if the preempted resources are non-slot-based or slot-based.

[0133] In the example, the resource pool is preemptible and the PRI is transmitted by the URLLC-WTRU. The size of the TB can be constructed so that it takes into account the loss of resources that may be interrupted by the PRI detection (for example, the TB can be prepared to accommodate the resources that cannot be used for PRI detection). When the TB is mapped to the resources, the resources allocated for PRI detection can be skipped. If the PRI is detected and encoded, puncturing (for example, further puncturing) can be performed, for example, based on the content of the PRI. The size of the TB can be such that it does not take into account the loss of resources that may be interrupted by the PRI detection. When the TB is mapped to the resources, the bits that can be mapped to the resources allocated for PRI detection can be punctured. If the PRI is detected and encoded, puncturing (for example, further puncturing) can be performed based on the content of the PRI. When the PRI includes two levels, the TB can be prepared according to one of the above; the TB can take into account PRI-I, for example, only PRI-I. If PRI-II is detected and encoded, puncturing (for example, further puncturing) can be performed, for example, based on the content of PRI-II.

[0134] The WTRU may decode the discovery channel information of a neighboring WTRU. The discovery channel may have an attribute indicating whether the WTRU is a URLLC-WTRU or a non-URLLC-WTRU. If the first non-URLLC WTRU cannot detect a URLLC-WTRU from the coded discovery channel, but the resource pool to which it has gained access is preemptible, the first WTRU may be able to disable preemption so that the first WTRU may not monitor possible PRI transmissions. In this case, the first WTRU will be able to transmit its TBs on one or more (e.g., all) available resources. In an alternative or in addition, the first WTRU may still transmit its own TBs on one or more (e.g., all) resources, but with reduced power and possibly a reduced MCS.

[0135] If the non-URLLC-WTRU requires feedback control information, such as an ACK / NACK for a previous transmission, and the location of the feedback channel is known, the URLLC-WTRU may not preempt the feedback transmission. The URLCC-WTRU may obtain the location information of the feedback transmission by one or more of the following. The timeslot format may be known by the URLLC-WTRU, for example, through configuration and / or signaling. The sensing / reservation signal transmitted by the non-URLLC-WTRU may carry the location information of the feedback transmission. The location of the feedback channel may be configured, for example, separately for each resource pool.

[0136] For example, Figure 7 As shown, preemption may be signaled by the WTRU via an SOS signal or a request for interrupt (RFI) signal. Figure 7is an example transmission sequence in which a WTRU may transmit a signal, such as an interrupt signal, to preempt the transmission of other WTRUs (e.g., of lower priority). For example, when the WTRU has high priority and / or low latency data to transmit (e.g., during ALL communications), the WTRU may send an SOS or RFI signal. This signal may cause the WTRU to interrupt other communications on the resources (e.g., designated resources) and make those resources available for its communications (e.g., emergency communications). The resources may become available in the next time slot or mini-time slot, such as Figure 7 As shown, the content of the signal may include an indication. The indication may be or may include a one-bit flag indicating RFI, or may include multiple bits defining other / additional parameters, such as the type of SOS or RFI, a subset of outage resources, and / or a WTRU ID.

[0137] The WTRU may perform an interruption mechanism after receiving an SOS or RFI signal. A set of resources in a time slot (e.g., each time slot or each consecutive k time slots) may be assigned or specified. If the WTRU receives an SOS or RFI signal in a time slot (e.g., the last time slot) or one of the last k time slots, the WTRU may refrain from transmitting on these resources, where k may be predefined or may be configured by a central node (e.g., a gNB). The interruption may be complete or partial based on predefined criteria and / or the configuration of the central node (e.g., a semi-static configuration). When a complete interruption is implemented, the WTRU may stop one or more (e.g., all) PSCCH and PSSCH transmissions whose associated resources overlap with the specified interruption resources. When a partial interruption is implemented, the WTRU may partially interrupt PSSCH transmissions to avoid the specified interruption resources. PSSCH transmissions may be rate matched around the interrupted resources.

[0138] The SOS or RFI signal may be WTRU-specific or non-WTRU-specific / anonymous, which may be based on predefined criteria and / or configuration of the central node (eg, semi-static configuration).

[0139] In the case of non-WTRU specific / anonymous signals, the SOS or RFI signal may not indicate the identity of the WTRU that has requested an interruption. The WTRU identity may be indicated in an assistance message that may be sent by the WTRU on one or more designated interruption resources. The indication of the WTRU ID in the assistance message may be done by the header, or by a cyclic redundancy check (CRC), which may be masked by the radio network temporary identifier (RNTI) of the WTRU. Non-WTRU specific / anonymous signals may be useful when the interruption probability and / or the interruption collision probability (e.g., two different WTRUs requesting an interruption at the same time) is low or acceptable. The non-WTRU specific / anonymous signal may be a specific resource designated for the SOS or RFI signal. The non-WTRU specific / anonymous signal may be transmitted on resources used for other purposes, such as the PSCCH and / or PSSCH. The transmission may be performed so that the SOS or RFI signal may be separated from other transmissions. The separation may be accomplished by power division (eg, boosting the power of the SOS or RFI signal) and / or code division (eg, spreading the SOS or RFI signal so that it can be separated from other signals and detected by a decorrelator receiver).

[0140] In the case of a WTRU-specific signal, the identity of the WTRU requesting the interruption may be identified based on the SOS or RFI signal transmitted by the WTRU. The ID may be included in the content of the SOS or RFI message. The ID may be derived from a CRC that is masked by the RNTI of the WTRU. The ID may be derived from properties of the SOS or RFI signal, such as a sequence associated with the signal. For example, each WTRU may be assigned one or more sequences from an orthogonal or semi-orthogonal sequence set, such as a Zadoff-Chu or other CAZAC sequence set. In this way, the WTRU may determine the identity of the WTRU transmitting the SOS or RFI signal based on the detected sequence(s).

[0141] Preemption may include a prioritization scheme. The priority of data may be identified by a parameter. If the data belongs to a number associated with the highest priority level and / or a higher priority level (e.g., the first two priority levels), the WTRU may preempt other WTRUs and transmit their data. It should be understood that a WTRU with data belonging to the second highest priority level may yield to a WTRU with data belonging to the first highest priority level. A WTRU with data belonging to the third highest priority level may yield to a WTRU with data belonging to the first and second highest priority levels, and so on. This may be referred to as prioritized preemption.

[0142] Fig. 8AAn exemplary parity-type preemption priority scheme is shown. The GC-PSCCH may be used to assign the highest priority data level to one or more time slots (e.g., even time slots). The GC-PSCCH may be used to assign the second highest priority data level to one or more other time slots (e.g., odd time slots). A WTRU with data belonging to the second highest priority data level may monitor odd time slots (e.g., the nearest odd time slot). If the WTRU does not detect a GC-PSCCH indicating the first highest priority level, the WTRU may attempt to transmit its own GC-PSCCH indicating the second highest priority level in an upcoming time slot (e.g., an even time slot). If the WTRU detects a GC-PSCCH indicating the first highest priority level, the WTRU may refrain from transmitting its GC-PSCCH and may continue to monitor odd time slots. When a GC-PSCCH indicating the first highest priority level is no longer detected, the WTRU may initiate its own GC-PSCCH transmission.

[0143] Figure 8B An exemplary staggered preemption priority scheme is shown. The GC-PSSCH may be used to assign multiple resources (e.g., a higher number of resources), such as all, to a priority level (e.g., the highest priority level). A WTRU with data belonging to the second highest priority service may be assigned a subset of time slots or mini-slots that are assigned to higher priority data. For example, a WTRU with data belonging to the second highest priority service may be assigned one or more (e.g., all) even time slots. A WTRU with lower priority data may be assigned another subset of time slots / mini-slots that are assigned to a WTRU with the second higher priority data, and so on. In mini-slot based monitoring, a modified GC-PSSCH scheduled on a mini-slot granularity may be used.

[0144] Preemption indication (e.g., via an SOS or RFI signal) can be used to prioritize preemption. A subset of the sequence can be assigned to indicate preemption of the highest priority data. Another subset of the sequence can be assigned to indicate preemption of the second highest priority data, and so on. A resource location (e.g., an even time slot) can be assigned for an SOS or RFI signal for the highest priority traffic, and another resource location (e.g., an odd time slot) can be assigned for an SOS or RFI signal for the second highest priority traffic, and so on.

[0145] Fig. 9An example is shown of a receiving WTRU alerting a transmitting WTRU of a preemption signal, such as an SOS or RFI signal. The transmitting WTRU cannot switch from transmission to reception and back to transmission without an interstitial period to listen for the GC-PSSCH and / or the SOS or RFI signal. In this way, the WTRU may refrain from transmitting within the resources reserved for the GC-PSSCH of the receiving WTRU. The receiving WTRU may decode the information in the reserved resources (e.g., the information in the GC-PSSCH), for example, in addition to other information. The decoding may be done by the same receiver in the receiving WTRU, or by a separate partner receiver (e.g., a separate low-complexity partner receiver) that may be dedicated for this purpose. The signal decoding may be based on a low-complexity receiver. The signal decoding may be performed based on correlation (e.g., simple correlation) or by energy detection. If the receiving WTRU receives an SOS or RFI signal in the reserved resources, the receiving WTRU may modify its behavior and / or perform other mechanisms (e.g., move to a predetermined action or expect additional information in a specific reserved future resource).

[0146] The receiving WTRU may decode the preemption and / or SOS / RFI signals. If the SOS information is in the same resource or the SOS action is immediate, for example, the WTRU may stop decoding the data from the transmitting WTRU and may start SOS actions, such as decoding the SOS signal and / or performing an SOS request. The receiving WRTU may send an SOS received signal to the transmitting WRTU for further actions. For example, if the SOS information is in a different resource (e.g., a later resource) or the SOS action is not immediate, the receiving WRTU may continue decoding the data from the transmitting WRTU. The receiving WRTU may send an ACK / NAK and the associated SOS signal to the transmitting WRTU for further actions and perform the SOS action. The transmitting WRTU may perform the SOS action upon receiving the SOS signal (with or without ACK / NAK).

[0147] If the transmitting WTRU cannot decode the SOS or RFI signal (e.g., due to its inability to quickly switch between transmitting and receiving), the receiving WTRU may transmit or relay the SOS or RFI signal to the transmitting WTRU during the transmitting WTRU's reserved ACK period or an additional period (e.g., of the transmitting WTRU) reserved for receiving SOS or RFI signals. The receiving WTRU may transmit the SOS or RFI signal with (e.g., additionally) and / or without an ACK.

[0148] A WTRU that has received a broadcast preemption message for the network (e.g., the entire network) may rebroadcast / relay the preemption message on the same or different resources to enable propagation of the preemption message through the network. Rebroadcasting / relaying the preemption message may reduce or minimize any delay associated with delivering a number (e.g., a large number) of preemption messages to a WTRU that may be part of a group or queue. If the same resources are used, the same packet may be sent to allow for message combination at the receiving WTRU. If different resources are used, the information may be encoded differently.

[0149] The relay WTRU may send preemption information received from a source (e.g., the network or source WTRU) to a target WTRU (e.g., by performing Fig.10 One or more features shown in ).

[0150] The target WTRU may delegate (e.g., explicitly or implicitly) the action of listening / listening for preemption messages from the network or source WTRU to the relay WTRU. For example, when the target WTRU is unable to listen to the preemption message(s), the target WTRU may delegate the listening to the preemption message(s) to the relay WTRU. The target WTRU may determine that the target WTRU is unable to listen to the BPM message, for example, due to half-duplex constraints or capabilities. The target WTRU may determine that the target WTRU is far (e.g., too far) from a possible BPM transmitter to reliably receive the transmission. For example, the target WTRU may be located at the edge of a convoy, away from a queue conductor. Upon receiving a message (e.g., a BPM) intended for the target WTRU, the relay WTRU may, for example, send the message (e.g., a BPM in a BRM, information associated with the BPM, etc.) to the target WTRU at an appropriate time. For example, the relay WTRU may send a preemption message to the target WTRU at the end of the transmission, at a preconfigured time (e.g., in a TDD system, during a symbol where the direction switches from outside to inside or from inside to outside), or send preemption information in the BRM (e.g., the WTRU may expect / receive a new set of instructions at a future time (t); and / or the WTRU may perform a set of actions at a future time (t)).

[0151] A WTRU (eg, a source WTRU) may send a message, such as a Broadcast Preemption Message (BPM).

[0152] A BPM may be a message sent by a source WTRU to a target WTRU to interrupt and / or modify the current or future actions / behaviors of the target WTRU.

[0153] The BPM may be directed to a target WTRU or set of target WTRUs. The BPM may, for example, modify the behavior(s) of the target WTRU(s) at a target time (t). For example, the BPM may configure the target WTRU(s) to perform one or more of the following: stop current transmissions; and / or stop actions and / or response actions taken by the target WTRU(s) at time (t).

[0154] The BPM may be directed to a target WTRU or target group of WTRUs to stop a transmission (eg, a current transmission as an example).

[0155] In an example, the target WTRU or target WTRU group may stop the current transmission, which may allow a transmission from another WTRU. For example, the transmission from the other WTRU may be a higher priority traffic.

[0156] In an example, a target WTRU or a target WTRU group may stop a current transmission due to resource preemption from another WTRU. The other WTRU may acquire resources from the current WTRU.

[0157] In an example, the target WTRU or target WTRU group may stop the current transmission for the transmission from the same WTRU(s). For example, the transmission from the same WTRU(s) may be or may include traffic from a logical channel (LCH) with a higher priority.

[0158] The BPM may be directed to a target WTRU or a target group of WTRUs (eg, a subset of WTRUs in a network). The BPM may indicate actions that may be taken by the target WTRU(s) at a specific time (t) and / or response actions.

[0159] In an example, the target WTRU(s) may respond to a vehicle emergency maneuver, such as a braking procedure or an avoidance maneuver.

[0160] In an example, the target WTRU(s) may respond to the action and monitor the Standalone Dedicated Channel (SDCCH) for future messages.

[0161] The target WTRU may be or may include WTRU1 or WTRUSet1 and may be used interchangeably.

[0162] The source WTRU sending the BPM (eg, the original BPM) may be or may include WTRU3. The source WTRU (eg, WTRU3) may be the WTRU requesting the preemption or action. The source WTRU may be or may include WTRU3 and may be used interchangeably.

[0163] A WTRU (eg, a relay WTRU and / or a source WTRU) may send a message, such as a broadcast relay message (BRM) or a relay message, to a target WTRU.

[0164] The BRM may be a message sent by a relay WTRU to a target WTRU. For example, a BRM may relay a message such as a BPM from a source WTRU to a target WTRU. For example, as described herein, a message from a source WTRU may be or may include an indication to interrupt a current action of a target WTRU.

[0165] The BRM may be directed to a target WTRU or set of target WTRUs to modify the behavior(s) of the target WTRU(s), for example, at a target time (t).

[0166] The BRM may be a relay (eg, a direct relay) of the BPM (eg, without modification).

[0167] A BRM may be a message including information derived from a BPM.

[0168] A relay WTRU or a relay WTRU set may be or may include WTRU2 or WTRU set 2, respectively, and may be used interchangeably.

[0169] The BRM may include one or more of: preemption information indicating that the WTRU (e.g., the target WTRU) may stop transmitting, such as stopping transmission on a specific resource or set of resources to allow another WTRU to transmit; preemption information indicating that the WTRU (e.g., the target WTRU) may stop transmitting and / or expect a new set of instructions or a specific set of actions; and / or signaling to enable relay message stop criteria, such as preventing relaying (e.g., of BRM / BPM) exceeding a threshold. If the BRM includes preemption information, the BRM may include information about where the relay WTRU may retransmit the information (e.g., part or all of the information) (e.g., rescheduling), for example, if the information fails to transmit during the stop period.

[0170] The BRM may include preemption information to indicate that the WTRU (e.g., the target WTRU) may stop transmitting and / or expect a new set of instructions or a specific set of actions. The preemption information may indicate one or more of the following: the WTRU (e.g., the target WTRU) may expect a new set of instructions, for example, at a future time (t); and / or the WTRU (e.g., the target WTRU) may perform a set of actions, for example, at a future time (t).

[0171] The BRM may include signaling to enable relay message stop criteria and prevent relaying (e.g., of a BRM / BPM) beyond a threshold. A WTRU (e.g., a relay WTRU) may stop relaying messages (e.g., BPMs and / or BRMs) directed to a target WTRU based on one or more of the following: based on how many times a BRM has been relayed; based on when a BRM was sent; based on the space and / or range between the source (e.g., the source WTRU) and the destination (e.g., the target WTRU); and / or based on the priority of the received BPM / BRM. A relay WTRU may use the relay message stop criteria described herein to determine whether to relay a BPM (e.g., or stop relaying a BPM to prevent the relaying of a BPM from exceeding a threshold). For example, a relay WTRU may determine whether the relaying of a BPM exceeds a preconfigured relay counter threshold that the BPM has been relayed, whether the relaying of a BPM exceeds a preconfigured time threshold when the BPM was first sent from the source WTRU, and / or whether the range between the source and the destination exceeds a preconfigured distance threshold. If the relay WTRU determines that the relay message stop criteria have been exceeded (e.g., a preconfigured relay counter threshold, a preconfigured time threshold, and / or a preconfigured distance threshold), the relay WTRU may stop relaying the BPM and prevent relaying the BPM that exceeds the threshold.

[0172] A source WTRU may transmit a BPM to a target WTRU. A relay WTRU may relay the BPM to a target WTRU in a BRM or as part of a BRM. In an example where there are multiple relay WTRUs, the BPM may be transmitted from a source WTRU and received by a first relay WTRU. The BPM may be relayed in a BRM sent by a first relay WTRU or as part of that BRM. The BRM may be received by a second relay WTRU, which may relay the BRM to a target WTRU. Stop criteria associated with a BRM may be used, for example, to prevent relaying exceeding a threshold (e.g., relaying a BRM that includes a BPM). For example, a counter associated with the BRM may be incremented accordingly (e.g., indicating the number of times the BPM has been relayed). The target WTRU may receive a BRM from the second relay WTRU and / or the first relay WTRU.

[0173] A relay WTRU may stop relaying a BRM based on the number of times the BRM has been relayed and whether the number of times the BRM has been relayed exceeds a preconfigured relay counter threshold. In an example, the BRM may include a counter that may be used to determine whether the BRM may be relayed or may be stopped. The counter may be updated when the BRM is relayed (e.g., each time). If the counter reaches or exceeds a preconfigured relay counter threshold (e.g., which is a fixed or configurable relay counter threshold), WTRU2 may stop relaying. For example, the counter may indicate a BRM relay process. The WTRU may identify the appropriate BRM relay process, for example, based on an explicit BRM identifier (e.g., included in the BRM) or based on the (e.g., complete) content of the BRM.

[0174] The relaying of a BRM may be stopped based on when the BRM was sent. In an example, the BRM may include a timestamp (e.g., or a field derived from the timestamp or indicating the timestamp). The timestamp may indicate timing (e.g., absolute or relative timing), such as indicating the time when the BRM was first sent from the source WTRU and / or the time when the BRM was first relayed. In an example, the timestamp may indicate an expiration time after which the BRM may not be relayed. In an example, the timestamp may indicate the actual time (one or more) at which the BRM was relayed in the past. The current relay WTRU may use this information to decide whether the BRM may be further relayed. In an example, the timestamp (one or more) may be updated when the BPM / BRM is relayed (e.g., each time the BPM / BRM is relayed). In an example, the timestamp may not be updated each time the BPM / BRM is relayed. For example, if the timestamp is not updated, the relay WTRU may stop relaying based on the difference between the current time and the timestamp (e.g., the time it was transmitted) being greater than a threshold (e.g., a preconfigured time threshold).

[0175] The relaying of a BRM may be stopped based on the space and / or distance between the source and the destination. In an example, the space and / or distance between the source and the destination may be based on a received SNR value. In an example, the space and / or range between the source and the destination may be based on location information (e.g., explicitly sent). In an example, the space and / or range between the source and the destination may be based on location information estimated by a relay WTRU. In an example, a BRM message may carry the location of the source. The relay WTRU may determine whether to relay a BRM based on the calculated space and / or range between the source and the destination WTRU and a threshold (e.g., using the source location in the BRM message). The threshold may be or may include a preconfigured distance threshold.

[0176] The relaying of the BRM may be stopped based on the priority of the received BPM / BRM.

[0177] A WTRU (eg, a target WTRU) may perform broadcast preemption actions based on the BPM and / or the BRM.

[0178] A broadcast preemption action may be an action taken by a target WTRU (e.g., or a group of target WTRUs) in response to receipt of a BPM or BRM. For example, a broadcast preemption action may include stopping a current transmission, e.g., in response to a transmission from another WTRU. The target WTRU(s) may stop a current action, e.g., in response to another action performed by the WTRU as described herein (e.g., an action indicated by a source WTRU).

[0179] A relay WTRU may be configured. A relay WTRU (e.g., WTRU2) or a set of relay WTRUs (e.g., WTRU set 2) may be configured based on implicit configuration and / or explicit configuration. The implicit and / or explicit configuration may be or may include implicit and / or explicit indications from a target WTRU (e.g., WTRU1) or a central node.

[0180] A relay WTRU (e.g., WTRU2) or a set of relay WTRUs (e.g., WTRU set 2) may be configured as a relay WTRU for a target WTRU (e.g., WTRU1) based on an implicit configuration (e.g., receiving a data transmission from WTRU1). For example, WTRU2 or WTRU set 2 may be configured (e.g., implicitly configured) as a relay WTRU for WTRU1, for example, based on an implicit configuration.

[0181] For example, a relay WTRU (e.g., WTRU2) or a set of relay WTRUs (e.g., WTRU set 2) may receive information (e.g., a data transmission) from another WTRU (e.g., a target WTRU or WTRU1). If WTRU2 or WTRU set 2 receives information (e.g., a data transmission) from WTRU1, WTRU2 or WTRU set 2 may be configured (e.g., implicitly configured) as a relay WTRU for WTRU1. As a relay WTRU for WTRU1, WTRU2 or WTRU set 2 may monitor BPM transmission resources (e.g., such as Fig. 9 For example, WTRU2 or WTRU set 2 may monitor the BPM transmission resources on behalf of WTRU1 based on receiving implicit and / or explicit configuration (eg, indication) from the target WTRU or WTRU1.

[0182] A relay WTRU (e.g., WTRU2) or a set of relay WTRUs (e.g., WTRU set 2) may be configured based on an explicit configuration (e.g., an explicit indication). For example, WTRU2 or WTRU set 2 may be configured (e.g., explicitly configured) by the network or by a target WTRU (e.g., WTRU1).

[0183] In an example, a relay WTRU (e.g., WTRU2) or a set of relay WTRUs (e.g., WTRU set 2) may be configured by the network to act as a relay WTRU to other WTRUs in the network (e.g., the entire network). The configuration may be static, semi-static, or dynamic. Static or semi-static configuration may use RRC configuration or MAC-CE signaling. Dynamic configuration may use L1 signaling.

[0184] In an example, a relay WTRU (e.g., WTRU2) or a set of relay WTRUs (e.g., WTRU set 2) may be configured (e.g., explicitly configured) by a target WTRU (e.g., WTRU1) or a set of target WTRUs (e.g., WTRU set 1) to function as a relay WTRU for the target set. The configuration may be static, semi-static, or dynamic.

[0185] The target WTRU (eg, WTRU1) may send an explicit indication, such as a preemption delegation message, to the relay WTRU (eg, WTRU2).The target WTRU may delegate the monitoring of the BPM to the relay WTRU by sending an explicit indication, such as a preemption delegation message.

[0186] The preemption delegation message may be or may include a message from a target WTRU (e.g., WTRU1) to a relay WTRU (e.g., WTRU2). The preemption delegation message may configure (e.g., designate) WTRU2 as a relay WTRU for WTRU1. By sending the preemption delegation message, WTRU1 may delegate the responsibility of listening / monitoring BPM(s) to the relay WTRU (e.g., WTRU2). The relay WTRU (e.g., WTRU2) may send a BRM (e.g., a BPM included in the BRM described herein) from a source WTRU (e.g., WTRU3) to a target WTRU (e.g., WTRU1). For example, the relay WTRU may receive a message from the source WTRU. The message from the source WTRU may be directed to the target WTRU. For example, the message from the source WTRU may be or may include a preemption message to the target WTRU. If the relay WTRU determines that the message from the source WTRU is directed to the WTRU, the relay WTRU may relay the message from the source WTRU in a relay message, such as a BRM. The relay message from the relay WTRU may be directly relayed to the target WTRU. A relay message from a relay WTRU may be relayed via one or more other relay WTRUs and relayed to a target WTRU, for example if the relay criteria described herein have been met. A target WTRU (e.g., WTRU1) may transmit a preemption delegation message to a relay WTRU (e.g., WTRU2) or a set of relay WTRUs (e.g., relay WTRU set 2). At a predetermined monitoring time, WTRU1 may listen for a BPM from a source WTRU (e.g., WTRU3) or a BRM from a relay WTRU (e.g., WTRU2). Upon receiving a BPM / BRM, WTRU1 may modify behavior, for example to take into account the received message. For example, WTRU1 may stop the current transmission or take a preemption action based on the BPM / BRM.

[0187] The preemption delegation message may indicate, for example, a set of resources (e.g., time and / or frequency) at which the target WTRU (e.g., WTRU1) may not be able to receive the broadcast preemption message. The preemption delegation message may indicate a set of resources at which the target WTRU (e.g., WTRU1) is expected to receive BPM / BRM. The relay WTRU (e.g., WTRU2) may use the indication from the preemption delegation message (e.g., the set of resources at which the target WTRU may not be able to receive BPM / BRM or may be able to receive BPM / BRM) to monitor the BPM intended for the target WTRU (e.g., WTRU1).

[0188] Delegate message signaling may be implicit. For example, if WTRU1 is transmitting (e.g., a data transmission or a control information transmission) to WTRU2, WTRU2 may know (e.g., implicitly know) what set of resources WTRU1 is using to transmit. For example, based on receiving a data transmission from WTRU1, WTRU2 may determine that WTRU1 cannot monitor / receive messages from the source WTRU, such as BPM. WTRU2 may be configured to monitor the WTRU1 control channel and may determine a set of resources where WTRU1 is transmitting and may not be able to receive BPM / BRM.

[0189] The delegation message signaling may be explicit. For example, if WTRU1 does not transmit information to WTRU2 or WTRU2 cannot determine when WTRU1 cannot receive BPM / BRM, WTRU1 may transmit an explicit preemption delegation message to WTRU2. WTRU2 may relay the BPM to WTRU1 using a relay message, such as BRM.

[0190] The preemption delegation message may include one or more of: a duration parameter; a period and / or duration of semi-persistent or periodic transmissions by the target WTRU; and / or a set of preemption timing parameters.

[0191] The preemption delegation message may include a duration parameter. The duration parameter may indicate the length of time that the preemption delegation is valid. The relay WTRU may listen to the BPM(s) for the indicated duration and relay the BPM(s), for example via a BRM as described herein.

[0192] The preemption delegation message may indicate (eg, or define) the period and / or duration of semi-persistent or periodic transmissions by the target WTRU (eg, WTRU 1).

[0193] The preemption delegation message may include a preemption timing parameter set. The preemption timing parameter set may indicate when the relay WTRU (e.g., WTRU2) may transmit a message to the target WTRU (e.g., WTRU1). The relay WTRU (e.g., WTRU2) may determine the timing / resources for transmitting, for example, the BRM(s) to the target WTRU (e.g., WTRU1), for example, based on the received timing parameters.

[0194] The preemption delegation message may be transmitted to the WTRU / set of WTRUs via dynamic signaling, such as a WTRU-specific or group-side link control channel.

[0195] The preemption delegation message may use MAC-CE or RRC signaling.

[0196] A relay WTRU (eg, WTRU2) may transmit a BRM, such as relaying a BPM or information associated with a BPM to a target WTRU (eg, WTRU1).

[0197] A relay WTRU (e.g., WTRU2) may transmit a BRM to a target WTRU in one or more of the following situations: if the relay WTRU receives a BPM intended for the target WTRU; if the target WTRU instructs the relay WTRU to monitor messages directed to the target WTRU, such as BPM; and / or by detecting (e.g., autonomously detecting) the need for the target WTRU to receive a BPM, such as based on target WTRU control signaling.

[0198] The relay WTRU may detect the need for the target WTRU to receive the BPM based on receiving a transmission from WTRU1 (e.g., the data transmission serves as an implicit preemption delegation message). The transmission from WTRU1 may include an indication of the duration (e.g., length) of the transmission from WTRU1 to WTRU1. WTRU2 may know (e.g., automatically know) that WTRU1 is unavailable (e.g., cannot be used for the duration) and may monitor for messages (e.g., BPM) directed to WTRU1.

[0199] The relay WTRU may detect the need for the target WTRU to receive the BPM based on monitoring of the PDCCH from the central node (e.g., gNB). WTRU2 may recognize, for example, based on the PDCCH, that WTRU1 is scheduled to transmit for a duration. WTRU2 may know (e.g., automatically know) that WTRU1 is unavailable (e.g., cannot be used for this duration) and may monitor messages directed to WTRU1 (e.g., BPM). The WTRU (e.g., the target WTRU) may need to send a C-RNTI (e.g., or ID) to the relay WTRU, and the relay WTRU may monitor the PDCCH, for example, based on the C-RNTI (e.g., or ID).

[0200] The relay WTRU (e.g., WTRU2) may transmit a BRM to the target WTRU (e.g., WTRU 1) if the relay WTRU receives a BPM (e.g., every time the relay WTRU receives a BPM). If the relay WTRU sends a BRM every time the relay WTRU receives a BPM, the probability that the target WTRU (e.g., WTRU1) receives the message may increase.

[0201] In an example, the timing of the BRM (e.g., the precise timing) may be fixed or may be configured based on WTRU2's knowledge of the state of WTRU1. For example, WTRU2 may know that WTRU1 may have switched from transmit mode to receive mode (e.g., sending a BRM when WTRU1 is in receive mode).

[0202] In an example, if WTRU1 is transmitting, WTRU2 may monitor the channel, for example, to identify when WTRU1 stops transmitting.

[0203] In an example, WTRU1 may indicate the length / duration of the transmission. WTRU2 may transmit a message to WTRU1, such as a BRM or BPM directed to WTRU1, at the end of the transmission.

[0204] In an example, WTRU1 may indicate a preemption listening period to WTRU2. The listening period may be indicated statically or dynamically. WTRU2 may transmit a BRM to WTRU1, for example, during the indicated preemption listening period (eg, during any indicated period).

[0205] Based on the target WTRU (e.g., WTRU1) instructing the relay WTRU (e.g., WTRU2) to monitor messages directed to the target WTRU, such as BPM messages sent to the target WTRU, the relay WTRU (e.g., WTRU2) may transmit a BRM to the target WTRU (e.g., WTRU1). For example, when the target WTRU (e.g., WTRU1) is transmitting or when the target WTRU is busy, the target WTRU may instruct the relay WTRU to monitor messages directed to the target WTRU, such as BPM. If the target WTRU instructs to monitor messages sent to the relay WTRU (e.g., WTRU2), such as BPM, WTRU1 may delegate WTRU2 to monitor the BPM, for example using a preemption delegation message as described herein. The target WTRU (e.g., WTRU1) may include information to the relay WTRU (e.g., in an indication) as to when to transmit the BRM (e.g., as described herein). Fig.11 For example, the target WTRU may indicate when a BRM may be received from the relay WTRU.

[0206] A relay WTRU (e.g., WTRU2) may transmit a message directed to a target WTRU (e.g., WTRU1) via BRM, for example, by detecting (e.g., autonomously detecting) the need for WTRU1 to receive BPM information. A relay WTRU may detect (e.g., autonomously detecting) the need for WTRU1 to receive BPM information based on WTRU1 control signaling.

[0207] The target WTRU (eg, WTRU1) may transmit a preemption delegation message to the relay WTRU based on a configuration (eg, a timing configuration).

[0208] The target WTRU (eg, WTRU1) may be configured to transmit a preemption delegation message based on one or more of: the ability to listen to BPM messages; and / or the distance of the target WTRU to the BPM transmitter.

[0209] The target WTRU may determine that the target WTRU may not be able to listen to the BPM message due to, for example, half-duplex constraints or capabilities.

[0210] The target WTRU may determine that the target WTRU is far away (eg, too far) from a possible BPM transmitter to reliably receive the transmission, such as BPM. For example, the target WTRU may be located at the edge of a convoy, away from the convoy conductor.

[0211] Fig.10 The action(s) associated with preemption are shown. For example, Fig.10 As shown, a relay WTRU (e.g., WTRU2) may alert a target WTRU (e.g., WTRU1) based on receiving a BPM (e.g., a BPM received from a source WTRU, e.g., WTRU3). For example, a relay WTRU may alert a target WTRU by, for example, relaying a BPM directed to the target WTRU via a BRM, such as Fig.10 . A relay WTRU (e.g., WTRU2) may receive a data transmission (e.g., as an implicit preemption delegation message) from a target WTRU (e.g., WTRU1) and may transmit a BRM to the target WTRU (e.g., WTRU1) if, for example, a BPM was received from a source WTRU (e.g., WTRU3) during that time. For example, the BPM may be directed / intended for WTRU1. The preemption delegation message may be implicit, for example, based on WTRU2 receiving data from WTRU1 during the time when WTRU1 was transmitting, for example, as Fig.10 as shown in .

[0212] The target WTRU (e.g., WTRU1) may transmit data and may not be able to receive messages directed to the target WTRU, such as BPM. Fig.10 As shown, a target WTRU (e.g., WTRU1) may transmit data to a relay WTRU (e.g., WTRU2). WTRU1 may indicate a delegation configuration, such as BPM delegation, to WTRU2 and may delegate listening for BPM to WTRU2 (e.g., on behalf of WTRU1). If resources for data transmission and preemption messages overlap, WTRU1 may rate match around the preempted resources or puncture the data in the preempted resources.

[0213] WTRU1 may monitor and preempt resources for information from WTRU2. Fig.10 and 11 As shown, WTRU1 monitoring the preempted resource for information from WTRU2 may be indicated as preempted resource 1 (PR1).

[0214] If there is no information in PR1 (eg, WTRU1 does not receive a BRM), WTRU1 may receive an ACK / NAK and may terminate the transmit / receive mechanism, such as Fig.10 shown.

[0215] If PR1 is received after a transmission (eg, a data transmission from WTRU1 to WTRU2), WTRU2 may send and WTRU1 may receive an ACK / NAK and a BRM, such as Fig.10 shown.

[0216] If the BPM is received by WTRU2 sometime after the set time (eg, near the end of the transmission), WTRU2 may send and WTRU1 may receive an ACK / NAK and a BRM, such as Fig.10 The BRM may be or may include a BMP directed to WTRU1.

[0217] If the BPM notification received in WTRU2 is not an immediate action, WTRU2 may send and WTRU1 may receive an ACK / NAK and a BRM, such as Fig.10 The BRM may be or may include a BPM directed to WTRU1.

[0218] If one or more preemption resources are available in PR1 during a transmission, and a BPM is received in WTRU2 before the configured time (e.g., near the end of the transmission), WTRU2 may send and WTRU1 may receive a BRM (e.g., without an ACK / NAK). WTRU1 may respond with a BRM action. WTRU1 may truncate the transmission data.

[0219] A preemption feature for a relay WTRU (eg, WTRU2) may be described herein. One or more of the following may apply.

[0220] like Fig.10 As shown, WTRU1 and WTRU2 may be aware of the configuration (eg, PR1 and / or PR2). PR1 may indicate the resources that WTRU1 may receive the BRM. PR2 may indicate the resources that WTRU2 may use to receive the BPM for WTRU1.

[0221] WTRU2 may need to know PR2, for example, to monitor, such as when to monitor BPM. WTRU2 may need to know PR1, for example, to transmit, such as when to transmit to WTRU1. WTRU1 may need to know PR1, for example, to delegate, such as when to delegate monitoring of BPM to WTRU2. WTRU may need to know PR2, for example, to receive, such as when to receive BPM from WTRU2. The configuration may be sent to WTRU1 and WTRU2 separately. The configuration may be sent simultaneously (e.g., in GC-PSSCH).

[0222] like Fig.10 As shown, WTRU2 may receive a BRM configuration from WTRU1. PR1 may indicate resources in which WTRU1 may receive a BRM. PR2 may indicate resources that WTRU2 may use to receive a BPM for WTRU1. For example, the BPM for WTRU1 may include network preemption signaling and / or WTRU1-specific preemption signaling. In an embodiment, PR1 may be the same as PR2. For example, a relay WTRU may have the same resources to receive a BPM and transmit a BRM. In an example, PR1 may be different from PR2. For example, a relay WTRU may use different resources to receive a BPM and transmit a BRM (e.g., and not miss any messages).

[0223] WTRU2 may receive the data transmission (eg, as an implicit preemption indication).

[0224] like Fig.10 As shown, WTRU2 may receive data from WTRU1, which may be an implicit preemption delegation from WTRU1 to WTRU2. As described herein, WTRU1's implicit preemption delegation may be or may include a transmission of data from WTRU1 to WTRU2.

[0225] WTRU2 may monitor PR2. For example, WTRU2 may monitor whether a BPM exists in PR2.

[0226] If there is no BPM in PR2 (eg, not received), WTRU2 may decode the data from WTRU1 and may send an ACK / NAK to WTRU1.

[0227] If a BPM is present (eg, received) in PR2, WTRU2 may decode the BPM and may create a BRM.

[0228] If PR1 is received after a transmission (e.g., a transmission from WTRU1), WTRU2 may decode the data (e.g., a data transmission from WTRU1) and may send an ACK / NAK and a BRM to WTRU1. For example, WTRU2 may wait for the data transmission from WTRU1 to complete, e.g., before sending a BRM.

[0229] If the BPM in PR2 is received at a time after the configured time (e.g., near the end of the transmission), and if PR1 is received after the transmission, WTRU2 may decode the data (e.g., data transmission from WTRU1) and may send an ACK / NAK along with the BRM (e.g., SOS message) to WTRU1. For example, if the BPM in PR2 is received at a time after the configured time (e.g., near the end of the transmission), and if PR1 is received after the transmission, WTRU2 may skip sending the BPM in the BRM to WTRU1 (e.g., and / or preempt).

[0230] If the BPM hint in PR2 is not an immediate action, WTRU2 may decode the data (eg, a data transmission from WTRU1) and may send an ACK / NAK and a BRM (eg, an SOS message) to WTRU1.

[0231] If PR1 provides WTRU2 with an opportunity to transmit a relay message to WTRU1 (e.g., before the end of the message), and receives a BPM before the configured time (e.g., near the end of the transmission), WTRU2 may transmit a BRM to WTRU1. WTRU2 may stop decoding signals received from WTRU1 (e.g., data transmissions).

[0232] Fig.11 An example relay preemption mechanism is shown. Fig.11 As shown, a receiver WTRU (e.g., WTRU4) may receive data from a target WTRU (e.g., WTRU1). A relay WTRU (e.g., WTRU2) may be a dedicated relay WTRU and may transmit a BRM to a target WTRU (e.g., WTRU1) if a BPM is received from a source WTRU (e.g., WTRU3).

[0233] A target WTRU (eg, WTRU1) may delegate monitoring and / or receiving messages, such as BPM, from a source WTRU to other WTRUs (eg, a relay WTRU (eg, WTRU2)).

[0234] like Fig.11 As shown, WTRU1 may indicate the BRM configuration to WTRU2 (eg, via relay preemption configuration), and may delegate the listening of the BPM from WTRU3 to WTRU2 (eg, via relay preemption delegation).

[0235] Preemption Resource 1 (PR1) may indicate resources that WTRU1 may use to receive the BRM.

[0236] Preemption resources 2 (PR2) may indicate resources that WTRU2 may use to receive the BPM for WTRU 1. For example, the BPM for WTRU 1 may include network preemption signaling and / or WTRU-specific preemption signaling.

[0237] In an embodiment, PR1 may be the same as PR2. In an example, PR1 may be different from PR2.

[0238] The BRM configuration from WTRU1 to WTRU2 may include the duration of the delegation to WTRU1.

[0239] WTRU1 may transmit information, such as data, to WTRU4.

[0240] WTRU1 may monitor the preempted resources for information from WTRU2. For TDD transmissions, WTRU1 may stop transmitting to WTRU4 during the monitoring period. For FDD transmissions, WTRU1 may continue transmitting (e.g., to WTRU4) during the monitoring period. WTRU1 may stop transmitting to WTRU4 if a BRM is received in PR1.

[0241] WTRU1 may perform preemption actions (eg, according to BRM).

[0242] A preemption mechanism for a relay WTRU (eg, WTRU2) may be described herein.

[0243] WTRU2 may receive the BRM configuration from WTRU1 and may accept listening to the BPM from WTRU3, for example, on behalf of WTRU2.

[0244] PR1 may indicate resources on which WTRU1 may receive BRM.

[0245] PR2 may indicate resources (eg, general network preemption signaling and / or WTRU1-specific preemption signaling) that WTRU2 may use to receive BPM for WTRU1.

[0246] In an embodiment, PR1 may be the same as PR2. In an example, PR1 may be different from PR2.

[0247] The BRM configuration from WTRU1 may include the duration of the delegation to WTRU1.

[0248] WTRU2 may monitor the preemption resource for general signaling (e.g., or general network preemption signaling) to WTRU1. Such a resource may be PR2. If WTRU2 receives a BPM from WTRU3, WTRU2 may wait for the next PR1 resource and may relay the information to WTRU1.

[0249] Hierarchical control information may be provided. A portion of control information common to a group of WTRUs and / or a group of intended receiving WTRUs may be separated and sent as sidelink control information (SCI), which may reduce signaling overhead (e.g., for unicast control information). In this way, the WTRU may transmit one or more types of SCI, such as a broadcast SCI, a unicast SCI, and / or a multicast SCI. The WTRU may transmit a broadcast SCI to schedule a broadcast sidelink data transmission from the WTRU and / or to transmit a portion of control information that is common between one or more (e.g., all) unicast transmissions from the WTRU.

[0250] Other WTRUs (e.g., unintended WTRUs) may detect the presence of the broadcast SCI and decode the content. Depending on the type of information in the broadcast SCI, the other WTRUs may infer one or more of the following: attributes (one or more) of the unicast or multicast data transmission, such as the MCS, priority and / or latency identifier of the data, etc.; capabilities or configurations of the transmitting WTRU, such as the MCS table, the number of HARQ processes that the transmitting WTRU is capable of executing, etc.; and / or detect the presence of the PSCCH (and associated PSSCH) by performing detection of a demodulation reference signal (DMRS), which may not be a WTRU-specific DMRS due to the nature of the broadcast SCI.

[0251] The content of the broadcast SCI may include one or more of the following: service identification / priority, which may indicate urgency, waiting time, reliability, etc.; number of HARQ processes; MCS table; K repetition value; frequency hopping identifier; SRS resource indicator; and / or the duration of an upcoming PSSCH or the duration of a set of PSSCH resources expected to be allocated by the same service identifier.

[0252] One or more attributes in the broadcast SCI, such as the K repetition value or the traffic / latency identifier, may help other WTRUs plan (e.g., better plan) resource allocations. For example, by identifying the broadcast SCI and its associated PSCCH with a latency identifier (which may be associated with a traffic priority), the transmitting WTRU may be able to avoid collisions on the PSSCH and / or help other WTRUs find other resources. The transmitting WTRU may attempt to check back after the identified duration.

[0253] The contents of the unicast SCI may include one or more of the following: HARQ process ID; MCS; K repetition value; frequency hopping identifier; power control (e.g., loop ID, P0-PUSCH alpha, etc.); and / or an indication of a transformed (e.g., expected) precoder for the PSSCH.

[0254] A sidelink group common SCI (SL-GC-SCI) may be used to transmit a portion of control information that is common in one or more (e.g., all) unicast transmissions from a WTRU to a group of (e.g., intended) receiving WTRUs (e.g., a group of WTRUs or roadside units, or a combination thereof). The SL-GC-SCI may be sent on a GC-PSCCH, which may have a similar or different structure than a unicast PSCCH. In the GC-PSCCH, a CRC masked by the RNTI of the receiving group may be used for group identification. The identification of the transmitting WTRU for the GC-PSCCH may be indicated via associated configuration resources, via a header (SL-GC-SCI) in its content, and / or via a CRC masked by the RNTI of the transmitting WTRU (e.g., an additional CRC). The SL-GC-SCI transmitted by the GC-PSCCH may include information or parameters for one or more (e.g., all) unicast transmissions from the transmitting WTRU to the intended receiving group. The parameters may include one or more of: the number of HARQ processes; the MCS table and / or the MCS; the K repetition value; and / or a preemption indication for data transmitted by the transmitting WTRU to the intended reception group.

[0255] The resources used for the broadcast and unicast portions of the SCI may be adjacent and may have the same or similar attributes.

[0256] The hierarchical attributes (e.g., resource allocation and / or transmission attributes) of the broadcast and unicast portions of the SCI may be different. For example, the resources used for the broadcast SCI may be selected from a set of resources designated for broadcast resources. The transmission attributes of the broadcast SCI may be selected from a selection set (e.g., a default set) and / or from a smaller selection set, which may allow blind detection (e.g., short and fast blind detection) at the receiving WTRU. The broadcast SCI may include some transmission attributes of the associated unicast SCI, such as MCS, unicast SCI resource location, etc. The unicast SCI may come from the same resources as the data / shared channel.

[0257] For example, collision avoidance in ALL communications may be provided. When a resource is accessed by more than one WTRU, collisions may result. The impact of collisions may be more pronounced in situations where low latency is expected. PSSCH transmissions may be longer than PSCCH transmissions. Thus, the impact of collisions on the PSSCH may be more pronounced than collisions on the PSCCH, although collisions on the PSCCH may result in the associated PSSCH being lost. The PSCCH may be sent with a lower MCS, more redundant coding, and / or in duplicate (e.g., due to its smaller size). This may increase the likelihood of detection, even in the event of a collision.

[0258] PSCCH can be sent before PSSCH. Figure 2 As described in the description of , the PSCCH may be sent on the same frequency resources of the PSSCH and / or on a subset of the frequency resources of the PSSCH. In this way, a conflict avoidance scheme may be implemented by monitoring the PSCCH. For example, when attempting to use a given PSSCH resource, the WTRU may monitor the associated PSCCH to assess whether the PSSCH is idle.

[0259] The PSCCH may be monitored via one or more of: received signal strength indicator (RSSI) measurements on the PSCCH; reference signal received power (RSRP) measurements (e.g., if non-WTRU-specific DMRS is used for PSCCH transmission); RSRP measurements of the broadcast portion of the PSCCH transmission; and / or RSRP measurements of the broadcast portion of the PSCCH and RSSI measurements of the unicast portion of the PSCCH.

[0260] When monitoring the PSCCH, the WTRU may compare one or more of the aforementioned measurements to a threshold (e.g., a corresponding threshold). If the measurement is greater than the threshold, the WTRU may skip transmission on one or more PSSCH resources (e.g., subsequent PSSCH resources). If the measurement is less than the threshold, the WTRU may transmit on one or more associated PSSCH resources (e.g., upcoming associated PSSCH resources). The threshold may be data-related and / or priority-related. The threshold may be calculated based on a reference threshold and adjusted by the bandwidth of the PSCCH. If the WTRU fails to access the PSSCH resource after multiple attempts (e.g., consecutive attempts), the threshold may be adjusted (e.g., increased).

[0261] In the case where a WTRU is part of a queue, one or more WTRUs (e.g., vehicles) that may be ahead (e.g., have a higher priority) in the queue may be more likely to transmit TBs to other WTRUs in the queue. As a result, the one or more WTRUs may participate in more periodic transmissions than other WTRUs. This situation may be exploited during resource allocation to reduce the chance of conflicts within the queue.

[0262] A resource set may be divided into multiple sets (eg, two or more sets). One set may be assigned to a periodic transmission mode. Another set may be assigned to an aperiodic transmission mode.

[0263] A partition (e.g., each partition) may have a contiguous set of resource blocks or a set of non-contiguous resource blocks. Dividing resources (e.g., bandwidth) into two or more sets may facilitate different reservation mechanisms. For example, if longer channel sensing is performed, periodic transmissions may be more reliable. Thus, dividing resources for periodic transmissions may avoid the presence of non-periodic transmissions. For non-periodic transmissions, the reservation mechanism may be faster by performing fast channel sensing. Thus, when resources are divided for non-periodic transmissions, the non-periodic transmissions may be more reliable. The division may reduce (e.g., overall) conflicts between WTRUs with periodic transmissions and WTRUs with non-periodic transmissions.

[0264] Resources may be divided for periodic and aperiodic transmissions. It should be understood that each PSSCH may have an associated PSCCH. A PSCCH may be adjacent to a corresponding PSSCH. PSCCHs may be adjacent in time (e.g., Figure 2 1A and 1B in FIG. 1 ) and / or adjacent in frequency (e.g., as shown in FIG. Figure 2 2 in Figure 1).

[0265] Resource allocation for a partition may follow a different approach than another partition. For example, resource allocation for periodic transmissions may be based on a sensing interval (e.g., a longer sensing interval), which may be different in resource allocation for non-periodic transmissions. A WTRU that selects resources for periodic transmissions from the partition may share information with other WTRUs about the periodicity of their respective transmissions, which may be the periodicity of transmissions in the PSSCH on the corresponding resources. This information may be carried in the PSCCH or in the broadcast portion of the associated PSCCH. This information may facilitate sharing of resources allocated for periodic transmissions. For example, two or more WTRUs may alternate using resources (e.g., a WTRU with periodic transmissions may not use resources in every timeslot).

[0266] A WTRU that intends to send a periodic transmission may use resources from a previous set of resources. The selection of resources from this set of resources may include one or more of the mechanisms described above and / or mechanisms that may use a long sensing period. WTRUs with periodic transmissions may collide with each other, although the likelihood of such collisions may be reduced because the number of WTRUs with periodic transmissions may be less than the total number of WTRUs in the queue.

[0267] To facilitate stable resource allocation during the duration (e.g., lifetime) of the periodic transmission, the WTRU may select a resource (e.g., for the periodic transmission) from a first set of resources and continue to use the resource (e.g., the same resource) for the duration (e.g., lifetime) of the periodic traffic unless the WTRU identifies a conflict. If the WTRU identifies a conflict, the WTRU may select another resource (e.g., a different resource) from the first set of resources.

[0268] A WTRU that intends to send an aperiodic transmission may use resources from a second set of resources (e.g., resources allocated for aperiodic transmissions). Selecting resources from the set of resources may include one or more of the mechanisms described above. WTRUs with aperiodic transmissions may collide with each other, although the likelihood of such collisions may be reduced because the number of WTRUs with aperiodic transmissions may be less than the total number of WTRUs in the queue.

[0269] In case the WTRU with aperiodic transmission determines that its transmission pattern matches the transmission pattern of the periodic transmission, the WTRU may select resources from the first set of resources.

[0270] The partitioning between the first set of resources (e.g., for periodic transmissions) and the second set of resources (e.g., for aperiodic transmissions) may be set as a default and / or may be preconfigured by a central node (e.g., a gNB), such as when the WTRU is within the radio coverage of the central node. One or more WTRUs may notify other WTRUs, such as those in a queue, of the partitioning. A WTRU leading in a queue and participating in periodic traffic transmission may select a partitioning scheme (e.g., from a selection set) and may notify other WTRUs (e.g., those in a queue) of the selection.

[0271] Although the features and elements are described above in specific combinations, it will be understood by those skilled in the art that each feature or element can be used alone or in any combination with other features and elements. In addition, the methods described herein can be implemented in a computer program, software, or firmware, which is incorporated into a computer-readable medium to be executed 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 memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor associated with the software can be used to implement a radio frequency transceiver used in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A first wireless transmit / receive unit (WTRU), comprising: A processor configured to: determining, based on reception by the first WTRU of a data transmission from a second WTRU, that the second WTRU is unable to listen for a first message directed to the second WTRU; based on the determination, monitoring the first message directed to the second WTRU; receiving the first message directed to the second WTRU; determining whether to relay the first message to the second WTRU in a second message; as well as if the first WTRU determines to relay the first message to the second WTRU, transmitting the second message to the second WTRU; wherein the first message comprises a broadcast preemption message to the second WTRU, wherein the broadcast preemption message indicates to skip transmission on a resource, and wherein to decode the first message to determine whether to relay the first message to the second WTRU, the processor is configured to: decoding the first message, wherein the first message is transmitted from a source WTRU; determining one or more of: a number of times the first message has been relayed, a timestamp indicating when the first message has been transmitted from a third WTRU, or a distance between the third WTRU and the first WTRU; as well as Based on the determination, the first message is transmitted to the second WTRU in the second message, and the second message includes information about one or more of the following: the number of times the first message has been relayed, the timestamp associated with when the first message has been transmitted from the third WTRU, or the distance between the third WTRU and the first WTRU.

2. The first WTRU of claim 1 , wherein the data transmission from the second WTRU includes an implicit indication that the second WTRU cannot listen to the first message directed to the second WTRU, and the processor is configured to: Based on monitoring a control channel associated with the second WTRU, determining when the second WTRU is transmitting and unable to listen to the first message.

3. The first WTRU of claim 1, wherein the first message comprises a discovery message to the second WTRU.

4. The first WTRU of claim 1 , wherein if the first message is not received, the processor is configured to: decode the data transmission from the second WTRU.

5. The first WTRU of claim 1, wherein the first WTRU is a relay WTRU and the second WTRU is a target WTRU, and wherein the second message is a broadcast relay message.

6. A method performed by a first wireless transmit / receive unit (WTRU), comprising: determining, based on reception by the first WTRU of a data transmission from a second WTRU, that the second WTRU is unable to listen for a first message directed to the second WTRU; based on the determination, monitoring the first message directed to the second WTRU; receiving the first message directed to the second WTRU; determining whether to relay the first message to the second WTRU in a second message; as well as if the first WTRU determines to relay the first message to the second WTRU, transmitting the second message to the second WTRU; wherein the first message comprises a broadcast preemption message to the second WTRU, wherein the broadcast preemption message indicates to skip transmission on a resource, and wherein to decode the first message to determine whether to relay the first message to the second WTRU, the method comprises: decoding the first message, wherein the first message is transmitted from a source WTRU; determining one or more of: a number of times the first message has been relayed, a timestamp indicating when the first message was transmitted from a third WTRU, or a distance between the third WTRU and the first WTRU; and Based on the determination, the first message is transmitted to the second WTRU in the second message, and the second message includes information about one or more of the following: the number of times the first message has been relayed, the timestamp associated with when the first message has been transmitted from the third WTRU, or the distance between the third WTRU and the first WTRU.

7. The method of claim 6, wherein the data transmission from the second WTRU includes an implicit indication that the second WTRU cannot listen to the first message directed to the second WTRU, and the method comprises: Based on monitoring a control channel associated with the second WTRU, determining when the second WTRU is transmitting and unable to listen to the first message.

8. The method of claim 6, wherein the first message comprises a discovery message to the second WTRU.

9. The method according to claim 6, wherein the method comprises: If the first message is not received, the data transmission from the second WTRU is decoded.

10. The method of claim 6, wherein the first WTRU is a relay WTRU and the second WTRU is a target WTRU, and wherein the second message is a broadcast relay message.

11. A first wireless transmit / receive unit (WTRU), comprising: A processor configured to: determining, based on the first WTRU receiving a data transmission from a second WTRU, that the second WTRU is unable to listen for a first message directed to the second WTRU to obtain a first determination; monitoring the first message directed to the second WTRU based on the first determination; receiving the first message directed to the second WTRU; determining whether to relay the first message to the second WTRU in a second message; as well as if the first WTRU determines to relay the first message to the second WTRU, transmitting the second message to the second WTRU, Wherein, to determine whether to relay the first message to the second WTRU in the second message, the processor is configured to: decoding the first message, wherein the first message includes a broadcast preemption message to the second WTRU to skip transmission; determining one or more of the following to obtain a second determination result: whether the number of times the first message has been relayed exceeds a preconfigured relay counter threshold, whether a timestamp indicating when the first message has been transmitted from a third WTRU exceeds a preconfigured time threshold, or whether a distance between the third WTRU and the first WTRU exceeds a preconfigured distance threshold; as well as Based on the second determination, transmitting the second message to the second WTRU is skipped.

12. The first WTRU of claim 11, wherein the data transmission from the second WTRU includes an implicit indication that the second WTRU cannot listen to the first message directed to the second WTRU, and the processor is configured to: Based on monitoring a control channel associated with the second WTRU, determining when the second WTRU is transmitting and unable to listen to the first message.

13. The first WTRU of claim 11, wherein the first message comprises a discovery message to the second WTRU.

14. The first WTRU of claim 11, wherein if the first message is not received, the processor is configured to: decode the data transmission from the second WTRU.

15. The first WTRU of claim 11, wherein the first WTRU is a relay WTRU and the second WTRU is a target WTRU, and wherein the second message is a broadcast relay message.

16. A method performed by a first wireless transmit / receive unit (WTRU), comprising: determining, based on reception by the first WTRU of a data transmission from a second WTRU, that the second WTRU is unable to listen for a first message directed to the second WTRU; based on the determination, monitoring the first message directed to the second WTRU; receiving the first message directed to the second WTRU; as well as determining whether to relay the first message to the second WTRU in a second message; as well as if the first WTRU determines to relay the first message to the second WTRU, transmitting the second message to the second WTRU, Wherein determining whether to relay the first message to the second WTRU in the second message comprises: decoding the first message, wherein the first message comprises a broadcast preemption message to the second WTRU to skip transmission on a resource; determining one or more of: whether a number of times the first message has been relayed exceeds a preconfigured relay counter threshold, whether a timestamp indicating when the first message has been transmitted from a third WTRU exceeds a preconfigured time threshold, or whether a distance between the third WTRU and the first WTRU exceeds a preconfigured distance threshold; and Based on the determination, transmitting the second message to the second WTRU is skipped.

17. The method of claim 16, wherein the data transmission from the second WTRU includes an implicit indication that the second WTRU cannot listen to the first message directed to the second WTRU, and the method comprises: Based on monitoring a control channel associated with the second WTRU, determining when the second WTRU is transmitting and unable to listen to the first message.

18. The method of claim 16, wherein the first message comprises a discovery message to the second WTRU.

19. The method according to claim 16, wherein the method comprises: If the first message is not received, the data transmission from the second WTRU is decoded.

20. The method of claim 16, wherein the first WTRU is a relay WTRU and the second WTRU is a target WTRU, and wherein the second message is a broadcast relay message.

Images