Sidelink Discovery Associated with NR Relay

Abstract

For example, systems, methods, and means for sidelink discovery associated with a relay, e.g., an NR relay, are described herein. Discovery data may be transmitted, for example, to initialize communication between devices. The discovery data may be transmitted alone or multiplexed with other data (e.g., sidelink data). High priority discovery data may be transmitted alone. Low priority discovery data may be multiplexed with other data (e.g., other data received within a certain duration). Discovery data may be multiplexed with other data that share the same destination identity. Resource allocation may be performed, for example, based on whether the discovery data is transmitted alone or multiplexed with other data.

Description

Technical Field

[0001] (Cross - Reference to Related Applications) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 061,470, filed on August 5, 2020; U.S. Provisional Patent Application No. 63 / 089,096, filed on October 8, 2020; U.S. Provisional Patent Application No. 63 / 136,379, filed on January 12, 2021; and U.S. Provisional Patent Application No. 63 / 185,579, filed on May 7, 2021, the disclosures of which are hereby incorporated by reference in their entirety.

Background Art

[0002] Mobile communication using wireless communication has been continuously evolving. The fifth generation of mobile communication radio access technology (RAT) may be referred to as 5G new radio (NR). Previous (conventional) generations of mobile communication RAT may be, for example, the fourth generation (4G) long term evolution (LTE).

Summary of the Invention

[0003] For example, systems, methods, and means for sidelink discovery related to relays, for example, NR relays, are described herein. Discovery data may be transmitted, for example, to initialize communication between devices. Discovery data may be transmitted alone or multiplexed with other data (e.g., sidelink data). High - priority discovery data may be transmitted alone. Low - priority discovery data may be multiplexed with other data (e.g., other data received within a certain duration). Discovery data may be multiplexed with other data sharing the same destination identification information. Resource allocation may be performed, for example, based on whether discovery data is transmitted alone or multiplexed with other data.

[0004] A wireless transmit / receive unit (WTRU) may be used in the transmission of discovery data and / or other data. The WTRU may receive discovery data (e.g., discovery data may arrive at the WTRU). The discovery data may be associated with a priority value and a first destination identifier. The WTRU may determine whether the priority value exceeds a threshold. The WTRU may determine the transmission content based on the priority value (e.g., whether to multiplex the discovery data with sidelink communication data). The WTRU may determine the transmission content based on whether sidelink communication data is received during the duration, for example, if the priority value exceeds a threshold. The duration may be determined based on, for example, the priority value and / or the channel busy ratio (CBR). The WTRU may receive sidelink communication data during the duration (e.g., sidelink communication data may arrive at the WTRU). The sidelink communication data may be associated with a second destination identifier. The WTRU can determine, for example, that a transmission includes discovery data multiplexed with sidelink communication data if sidelink communication data is received during the duration and the first and second destination identifiers are the same. The WTRU can determine, for example, that a transmission includes discovery data (e.g., discovery data only) if sidelink communication data is not received during the duration or if the first and second destination identifiers are not the same.

[0005] The WTRU can perform resource allocation based, for example, on whether discovery data is transmitted alone or multiplexed with sidelink communication data. The WTRU can determine transmission parameters based on whether discovery data is multiplexed with sidelink communication data. Transmission parameters may include the number of subchannels, the number of retransmissions, the transmission power, and / or the modulation and coding scheme (MCS). [Brief explanation of the drawing]

[0006] [Figure 1A] This is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] This is a system diagram illustrating an exemplary wireless transmitter / receiver unit (WTRU) that may be used in a communication system illustrated in Figure 1A, according to one embodiment. [Figure 1C] This is a system diagram illustrating an exemplary radio access network (RAN) and an exemplary core network (CN) that may be used in a communication system illustrated in Figure 1A according to one embodiment. [Figure 1D] This is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used in the communication system illustrated in Figure 1A according to one embodiment. [Figure 2] This example shows a user-plane radio protocol stack for Layer 2 evolved WTRU inter-network relay. [Figure 3] This figure shows an example of a control plane radio protocol stack for Layer 2 evolved WTRU inter-network relay. [Figure 4] An example of a BSR associated with discovery data is shown. [Figure 5] This shows an exemplary resource allocation for discovery data using discovery resource allocation time. [Modes for carrying out the invention]

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

[0008] As shown in Figure 1A, the communication system 100 may include radio transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, but it will be understood that the disclosed embodiments intend any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a radio environment. For example, WTRU102a, 102b, 102c, and 102d, any of which may be referred to as “station” and / or “STA”, may be configured to transmit and / or receive radio signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscriber-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, radio sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other radio devices operating in an industrial and / or automated processing chain context), consumer electronics devices, and devices operating in commercial and / or industrial radio networks. Any of WTRU102a, 102b, 102c, and 102d may interchangeably be referred to as UE.

[0009] The communication system 100 may also include base stations 114a and / or base stations 114b. Each of the base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106 / 115, the Internet 110, and / or other networks 112. As an example, base stations 114a and 114b may be base transceiver stations (BTS), node B, eNodeB, home node B, home eNodeB, gNB, NR nodeB, site controller, access point (AP), wireless router, etc. Although base stations 114a and 114b are shown as single elements, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

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

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

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

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

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

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

[0016] In other embodiments, base stations 114a and WTRUs 102a, 102b, and 102c may implement wireless technologies such as IEEE 802.11 (i.e., Wireless Fidelity, WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access, WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), and GSM EDGE (GERAN).

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

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

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

[0020] Some or all of the WTRU102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (e.g., the WTRU102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). For example, the WTRU102c shown in FIG. 1A may be configured to communicate with a base station 114a that may use cellular-based wireless technology and a base station 114b that may use IEEE802 wireless technology.

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

[0022] The processor 118 may be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120 that may be coupled to a transmit / receive element 122. Figure 1B shows the processor 118 and the transceiver 120 as separate components, but it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

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

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

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

[0028] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 may acquire location information by any preferred location determination method while maintaining consistency with one embodiment.

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

[0030] WTRU102 may include a full-duplex radio in which the transmission and reception of some or all of the signals (e.g., associated with specific subframes for both UL (e.g., transmission) and downlink (e.g., reception) may be in parallel and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference via hardware (e.g., chokes) or signal processing via a processor (e.g., via a separate processor (not shown) or processor 118). In one embodiment, WRTU102 may include a half-duplex radio for the transmission and reception of any of the signals (e.g., associated with specific subframes for either UL (e.g., transmission) or downlink (e.g., reception)).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0056] UPF184a and 184b may be connected via the N3 interface to one or more gNB180a, 180b, and 180c in RAN113, thereby providing WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices. UPF184 and 184b may perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

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

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

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

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

[0061] For example, systems, methods, and means for sidelink discovery related to relays, such as NR relays, are described herein. Discovery data may be transmitted, for example, to initialize communication between devices. Discovery data may be transmitted alone or multiplexed with other data (e.g., sidelink data). High-priority discovery data may be transmitted alone. Low-priority discovery data may be multiplexed with other data (e.g., other data received within a certain duration). Discovery data may be multiplexed with other data that share the same destination identification information. Resource allocation may be performed, for example, based on whether the discovery data is transmitted alone or multiplexed with other data.

[0062] A wireless transmit / receive unit (WTRU) may be used in the transmission of discovery data and / or other data. The WTRU may receive discovery data (e.g., discovery data may arrive at the WTRU). The discovery data may be associated with a priority value and a first destination identifier. The WTRU may determine whether the priority value exceeds a threshold. The WTRU may determine the transmission content based on the priority value (e.g., whether to multiplex the discovery data with sidelink communication data). The WTRU may determine the transmission content based on whether the sidelink communication data is received during the duration, for example, if the priority value exceeds a threshold. The duration may be determined based on, for example, the priority value and / or the Chanel busy ratio (CBR). The WTRU may receive sidelink communication data during the duration (e.g., sidelink communication data may arrive at the WTRU). The sidelink communication data may be associated with a second destination identifier. The WTRU can determine, for example, that a transmission includes discovery data multiplexed with sidelink communication data if sidelink communication data is received during the duration and the first and second destination identifiers are the same. The WTRU can determine, for example, that a transmission includes discovery data (e.g., discovery data only) if sidelink communication data is not received during the duration or if the first and second destination identifiers are not the same.

[0063] The WTRU can perform resource allocation based, for example, on whether discovery data is transmitted alone or multiplexed with sidelink communication data. The WTRU can determine transmission parameters based on whether discovery data is multiplexed with sidelink communication data. Transmission parameters may include the number of subchannels, the number of retransmissions, the transmit power, and / or the modulation and coding scheme (MCS).

[0064] A radio transmit / receive unit (WTRU) can notify the gNB of the availability of discovery data, for example, using scheduling requests (SRs), buffer status reports (BSRs), and / or radio resource control (RRC) messages. The WTRU can prioritize discovery transmits / receives between other sidelinks and / or uplink transmits / receives, for example, based on the quality of service (QoS) of the data and / or other conditions. The WTRU can determine the transmission behavior of a message based on one or more of the following: the type of data multiplexed in a transport block (TB), the arrival time of discovery data within the discovery period, the QoS of the message (e.g., discovery message), the channel busy ratio (CBR) of the resource pool and / or the channel occupancy ratio (CR) of the WTRU, and the WTRU's past transmit activity. A WTRU can multiplex discovery messages with data transmissions having the same destination identifier (ID) based, for example, on discovery message priority and delay requirements (e.g., decide to multiplex them). A WTRU can prioritize transmissions between different resource pools based, for example, on message QoS and resource pool (pre-configured) priority.

[0065] In the example, the WTRU may multiplex discovery messages with data transmissions having the same destination ID (e.g., decide to multiplex them) based, for example, discovery message priority and delay requirements. The WTRU may have one or more destinations configured for data transmissions. The WTRU may send discovery messages by performing sensing and / or resource selection when the priority of the discovery data is below a threshold. Otherwise, the WTRU may track the discovery resource selection time (e.g., start a discovery resource selection timer). The duration (e.g., timer) may be determined based, for example, on the priority of the resource pool and / or the discovery period. The WTRU may, for example, stop tracking the duration (e.g., via the timer) when communication data associated with one of the configured destinations arrives, multiplex the discovery data with the communication data, and perform sensing and / or resource allocation for MAC PDUs having the discovery data. The WTRU can, for example, sense and / or allocate resources and send a standalone discovery message when the discovery resource selection time expires (e.g., via a discovery resource selection timer). The WTRU can perform resource selection for transmissions with discovery data. The WTRU can determine transmission parameters (e.g., the number of subchannels used for each transmission, the number of retransmissions, parameters associated with transmit power, MCS, etc.) based on whether the discovery data is multiplexed with the data. The WTRU can apply time and / or frequency limits between selected resources (e.g., the frequency gap and / or time gap between two selected resources may be greater than one threshold and less than another).

[0066] In the example, the WTRU can prioritize data transmissions and discovery transmissions based, for example, on the (pre-configured) priorities of the discovery resource pool and data resource pool, as well as the priority of data transmissions. The WTRU can configure multiple (e.g., two) transmission resource pools, for example, one for discovery transmissions and another for data transmissions, and the transmission resource pools can overlap in time and / or frequency. The WTRU can configure one priority threshold for the data resource pool and another priority threshold for the discovery resource pool. The WTRU can prioritize data resources and discovery resources in the resource selection procedure. The WTRU can perform resource selection for data TBs. The WTRU can exclude times / frequencies that overlap with the discovery resource pool if, for example, the priority of the data TB is greater than a configured priority threshold. The WTRU can perform resource selection for discovery TBs. The WTRU can exclude times / frequencies that overlap with the data resource pool if, for example, the priority of the discovery TB is greater than another configured threshold.

[0067] This specification describes systems, methods, and means related to discovery. A WTRU can determine, for example, whether to send a discovery message based on one or more parameters. A WTRU can trigger and / or stop monitoring a discovery resource pool based on one or more parameters. A WTRU can determine which resource pool to monitor based on its power saving status. A WTRU can include an ID associated with a group in the discovery message. A relay WTRU can determine whether to forward a discovery message.

[0068] A WTRU can determine the values ​​of one or more fields (e.g., each) in the SL BSR associated with the discovery data. A WTRU can determine the order of destinations to report to. A WTRU can use a MAC subheader to indicate the availability of the discovery data. A WTRU can use the MAC header to send the discovery message. A WTRU can indicate the L2 ID to the upper layer, for example, by reading the MAC header of the discovery message. A WTRU can (pre-configure) multiple discovery types. A WTRU can select a discovery type. A WTRU can select one or more resource pools for discovery transmission.

[0069] A WTRU can determine whether to transmit sidelink data based on discovery transmit / receive. A WTRU can perform congestion control for discovery data. A WTRU can determine which resource pool transmits discovery data. A WTRU can switch discovery transmits to a different resource pool. A WTRU can indicate the transmit power of discovery messages. A WTRU can perform RSRP measurements based on transmit power instructions from a TxWTRU. A WTRU can determine RSRP thresholds and perform relay (re)selection. A WTRU can decide whether to select an L2 or L3 relay. A WTRU can determine the steps to obtain the configuration related to relay services. A WTRU can determine whether to act as an L2 relay or an L3 relay based on instructions from a gNB. A WTRU can determine whether to select an L2 relay or an L3 relay based on instructions from a gNB. A WTRU can send RLF instructions to a remote WTRU. WTRU can determine whether to perform cell (re)selection first or relay (re)selection. WTRU can determine the threshold for cell (re)selection.

[0070] NR Sidelink relays can support WTRU-to-network relays and inter-WTRU relays. NR Sidelink can support vehicle-to-everything (V2X) related road safety services. Support can be provided for broadcast, groupcast, and unicast communications in out-of-coverage and in-network coverage scenarios. Sidelink-based relay functionality can support, for example, sidelink / network coverage extension and power efficiency improvements for a wide range of applications and services.

[0071] Coverage extensions may be provided for sidelink-based communications. Coverage extensions from WTRUs to the network may be provided. Uu coverage reachability may enable a WTRU to reach a server within a packet data network (PDN) or a corresponding WTRU outside the immediate vicinity area. WTRU-to-network relay coverage extensions may utilize evolved universal terrestrial radio access (EUTRA) based technologies, which may not be applicable to NR-based systems for NG-RAN and NR-based sidelink communications, for example. Coverage extensions from WTRU to WTRU may be provided. Proximity reachability may be applied to single-hop sidelink links (e.g., via EUTRA-based or NR-based sidelinks), which may not be applicable, for example, if Uu coverage is not present. Sidelink connectivity may be extended (e.g., further extended) within the NR framework to support enhanced quality of service (QoS), for example.

[0072] Single-hop NR sidelink relays may support sidelink-based WTRU inter-network and inter-WTRU relays based on, for example, the use of relay selection (e.g., reselection), relay / remote WTRU authorization, QoS for relaying operations, continuity of service, security of relayed connections (e.g., security after SA3 provides its conclusion), and / or user plane protocol stacks and control plane procedures (e.g., connection management of relayed connections). Higher layer operations for sidelink relays (e.g., discovery models / procedures) may be supported (e.g., without new physical layer channels / signals). Inter-network and inter-WTRU relays may use the same sidelink relay. Relays from WTRUs to networks may implement end-to-end packet data convergence protocol (PDCP) and hop-by-hop radio link control (RLC).

[0073] WTRU inter-network relays can be implemented. Relays can be implemented, for example, via proximity service (ProSe) WTRU inter-network relays to extend network coverage to out-of-coverage WTRUs, for example, by using PC5 (e.g., device-to-device, D2D) communication between out-of-coverage WTRUs and WTRU inter-network relays.

[0074] The ProSe WTRU inter-network relay can provide L3 forwarding capabilities (e.g., general-purpose L3 forwarding capabilities) that can relay Internet Protocol (IP) traffic (any type of IP traffic) between a remote WTRU and the network. One-to-one and one-to-many sidelink communication can be used between the remote WTRU and the ProSe WTRU inter-network relay. For example, single-carrier operation (e.g., only one) (e.g., public safety ProSe carrier) may be supported for the remote WTRU and the relay WTRU (e.g., Uu and PC5 may be the same carrier for the relay / remote WTRU). The remote WTRU may be permitted by higher layers. The remote WTRU may be within the coverage of the public safety ProSe carrier or outside the coverage of any supported carrier (e.g., including the public safety ProSe carrier) for WTRU inter-network relay discovery, (re)selection, and communication. ProSe WTRU inter-network relays may be within the coverage of the EUTRA network (EUTRAN) (e.g., always within coverage). ProSe WTRU inter-network relays and remote WTRUs may perform sidelink communication and sidelink discovery.

[0075] Relay selection can be performed for WTRU network (network, NW) inter-relay. ProSe relay selection / re-selection for WTRU network inter-relay can be performed, for example, based on a combination of access stratum (AS) layer quality measurements (e.g., reference signal received power, RSRP) and higher layer criteria.

[0076] The eNB can control whether a WTRU can function as a ProSe WTRU inter-network relay. ProSe WTRU inter-network relay operation may be supported in a cell, for example, if the eNB broadcasts any information that can be associated with ProSe WTRU inter-network relay operation.

[0077] The eNB may provide transmit resources for ProSe WTRU inter-network relay discovery, for example, by using signaling for the Radio Resource Control (RRC) idle state (RRC_IDLE state) (e.g., broadcast signaling) and signaling for the RRC_CONNECTED state (e.g., dedicated signaling). The eNB may provide receive resources for ProSe WTRU inter-network relay discovery, for example, by using broadcast signaling. The eNB may broadcast minimum and / or maximum Uu link quality (e.g., RSRP) thresholds that the ProSe WTRU inter-network relay can comply with before initiating the WTRU inter-network relay discovery procedure. The WTRU may use the thresholds (e.g., in RRC_IDLE, if the eNB broadcasts the transmit resource pool) to start or stop the WTRU inter-network relay discovery procedure (e.g., autonomously). A WTRU may use a threshold (for example, in RRC_CONNECTED) to determine whether it can indicate to the eNB that, for example, the WTRU is a relay WTRU and wants to initiate ProSe WTRU inter-network relay discovery. A WTRU may initiate a request for ProSe-WTRU inter-network relay discovery resources (for example, by dedicated signaling, taking into account broadcasted thresholds) if the eNB does not broadcast a transmit resource pool for ProSe-WTRU inter-network relay discovery.

[0078] ProSe-WTRU inter-network relays may perform ProSe-WTRU inter-network relay discovery, for example, when the ProSe-WTRU inter-network relay is initiated by broadcast signaling (e.g., in RRC_IDLE). ProSe-WTRU inter-network relays may perform relay discovery, for example, when the ProSe-WTRU inter-network relay is initiated by dedicated signaling (e.g., in RRC_CONNECTED).

[0079] A ProSe WTRU inter-network relay that can (e.g., is performing) sidelink communication for ProSe WTRU inter-network relay operation may be in RRC_CONNECTED. A ProSe WTRU inter-network relay may receive Layer 2 link establishment requests or temporary mobile group identity (TMGI) monitoring requests (e.g., upper layer messages) from a remote WTRU. A ProSe WTRU inter-network relay may indicate to the eNB that it is a ProSe WTRU inter-network relay and is intended to perform ProSe WTRU inter-network relay sidelink communication. The eNB may provide resources for ProSe WTRU inter-network relay communication.

[0080] A remote WTRU may decide to begin monitoring for ProSe WTRU inter-network relay discovery (e.g., when to begin). Depending on the configuration of resources for ProSe WTRU inter-network relay discovery, a remote WTRU may send a ProSe WTRU inter-network relay discovery request message, for example, while in RRC_IDLE or RRC_CONNECTED. The eNB may broadcast a threshold that can be used by the remote WTRU to determine, for example, whether the remote WTRU can connect or communicate with, for example, a ProSe WTRU inter-network relay WTRU by sending a ProSe WTRU inter-network relay discovery request message. An RRC_CONNECTED remote WTRU may use the broadcasted threshold to determine, for example, whether it can indicate to the eNB that the RRC_CONNECTED remote WTRU is a remote WTRU and wishes to participate in ProSe WTRU inter-network relay discovery and / or communication. The eNB may provide transmit resources (e.g., using broadcast or dedicated signaling) and receive resources (e.g., using broadcast signaling) for ProSe WTRU inter-network relay operation. A remote WTRU may stop using ProSe WTRU inter-network relay discovery and communication resources, for example, if the RSRP exceeds a broadcast threshold. The time for traffic switching from Uu to PC5, or vice versa, may be determined, for example, by the higher layer.

[0081] A remote WTRU may perform radio measurements (e.g., on the PC5 interface) and use these measurements (e.g., based on upper-layer criteria) for ProSe WTRU inter-network relay selection and reselection. A ProSe WTRU inter-network relay may be considered suitable (e.g., with respect to radio criteria) if, for example, its PC5 link quality exceeds a configured threshold (e.g., a pre-configured or provided by the eNB). A remote WTRU may select a ProSe WTRU inter-network relay that meets the upper-layer criteria and provides the best PC5 link quality among (e.g., all) suitable ProSe WTRU inter-network relays. A remote WTRU may trigger ProSe WTRU inter-network relay reselection if, for example, the PC5 signal strength of the current ProSe WTRU inter-network relay falls below a configured signal strength threshold, AND / or) the remote WTRU receives a Layer 2 link release message (e.g., an upper-layer message) from the ProSe WTRU inter-network relay.

[0082] WTRU inter-network relays can be provided for wearables. WTRU inter-network relays can support wearable and IoT devices within a RAN. ProSe WTRU inter-network relays can use L3 (e.g., IP layer) relays. WTRU inter-network relays for wearables can use, for example, L2 relays.

[0083] Figure 2 shows an example of a user-plane radio protocol stack for relaying from a Layer 2 evolved WTRU to a network (for example, using a PC5 interface).

[0084] Figure 3 shows an example of a control plane radio protocol stack for Layer 2 evolved WTRU inter-network relay (for example, using a PC5 interface).

[0085] Connection establishment may be provided via a unicast link in NR V2X. The use of relays (e.g., for LTE) may be based on a one-to-one communication link established at a higher layer (e.g., ProSe layer) between multiple (e.g., two) WTRUs (e.g., a remote WTRU and a WTRU network relay). The connection may be transparent to the AS layer. Connection management signaling and procedures performed at the higher layer may be carried by the AS layer data channel. The AS layer may not be aware of the one-to-one connection.

[0086] The AS layer may support unicast links between multiple (e.g., two) WTRUs (e.g., in NR V2X). Unicast links may be initiated by higher layers (e.g., as in a ProSe one-to-one connection). The AS layer may be notified of the existence of unicast links and any data that may be transmitted unicast-wise between peer WTRUs. The AS layer may support hybrid automatic repeat request (HARQ) feedback, channel quality indicator (CQI) feedback, and power control schemes (e.g., which may be specific to unicast) (e.g., using this knowledge).

[0087] Unicast links at the AS layer may be supported, for example, via PC5-RRC connections. A PC5-RRC connection may be, for example, a logical connection between a source Layer 2 ID pair and a destination Layer 2 ID within the AS. For example, one PC5-RRC connection may correspond to one PC5 unicast link. PC5-RRC signaling may be initiated, for example, after the establishment of the corresponding PC5 unicast link. The PC5-RRC connection, as well as the corresponding sidelink signaling radio bearer (SRB) and sidelink data radio bearer (DRB), may be released, for example, when the PC5 unicast link is released (as may be indicated by a higher layer).

[0088] For example, in the case of a unicast (e.g., each) PC5-RRC connection, a (e.g., one) sidelink SRB may (e.g., be used to) send PC5-S messages, for example, before PC5-S security is established. A (e.g., one) sidelink SRB may (e.g., be used to) send PC5-S messages to establish PC5-S security. A (e.g., one) sidelink SRB may (e.g., be used to) send PC5-S messages, for example, after PC5-S security has been established. PC5-S messages may be protected. A (e.g., one) sidelink SRB may (e.g., be used to) send PC5-RRC signaling, which may be protected and sent only after PC5-S security has been established.

[0089] PC5-RRC signaling may include, for example, a sidelink configuration message (e.g., RRCReconfigurationSidelink), where, for example, a WTRU may configure the receiving (RX) relation parameters of (e.g., each) SLRB in the peer WTRU. Reconfiguration messages may configure parameters of (e.g., each) protocol in the L2 stack (e.g., service data adaptation layer (SDAP), packet data convergence protocol (PDCP), etc.). The receiving WTRU may, for example, confirm or reject the configuration depending on whether the receiving WTRU can support the configuration proposed by the peer WTRU.

[0090] The discovery function can enable the WTRU to send discovery messages. Discovery messages may have a fixed size (e.g., 232 bits). Discovery messages may be sent in a dedicated discovery resource pool, for example, using a physical downlink shared channel (PDSCH). (E.g., each) PDSCH resource may occupy two physical resource blocks (PRBs) spanning (e.g., one) subframe. Multiple (e.g., two) resource allocation types may exist for the discovery procedure, e.g., WTRU autonomous resource selection (Type 1) and network scheduling (Type 2).

[0091] Discovery procedures (for example, for Type 1 and Type 2 allocations) may support consecutive transmissions (e.g., one to four consecutive transmissions) using, for example, inter-subframe frequency hopping for each discovery message. Discovery procedures (for example, for Type 2 allocations) may support allocating discovery resources for each discovery message (e.g., Type 2A). Discovery procedures (for example, for Type 2 allocations) may support (e.g., semi-persistent) allocation of discovery resources for discovery transmissions with discovery periods (e.g., Type 2B) ranging from 40ms to 10240ms. Discovery procedures (for example, for Type 1 allocations) may support configuring a WTRU using one or more discovery resource pools, where each resource pool may support a discovery period (e.g., from 40ms to 10240ms). The discovery procedure (for example, for type 1 assignment) may support randomly selecting the time and frequency of the initial transmission during each discovery period (for example, for each discovery message).

[0092] NR V2X can be configured to carry physical sidelink (SL) control channel (PSCCH) transmissions and physical SL shared channel (PSSCH) transmissions. PSCCH and PSSCH transmissions can be time- and frequency-multiplexed. (For example, each) V2X sidelink transmission may include PSCCH and PSSCH transmissions occupying one or more subchannels across a slot (e.g., one slot). The subchannel size in NR V2X (e.g., minimum subchannel size) may be, for example, 10 PRBs. WTRU autonomous sensing and resource selection (e.g., mode 2) for PSCCH / PSSCH transmissions can be supported, and for example, the resource selection window can be a function of TB priority (e.g., within 100ms).

[0093] Discovery procedures for sidelink relays (e.g., WTRU-to-network relays and WTRU-to-WTRU relays) can use one or more physical layer (PHY) channels. Sidelink discovery can be performed, for example, using the V2X PHY channel of an NR.

[0094] When referred to herein, the term "discovery message" can refer to any message sent from a WTRU to initialize direct communication (e.g., side-link communication) with one or more other WTRUs. A discovery message may be sent, for example, via a direct link and / or via one or more relays (e.g., one or more relay WTRUs). A discovery message may be sent from a source WTRU, a destination WTRU, and / or a relay WTRU.

[0095] Messages transmitted by a WTRU (e.g., discovery messages) may include one (e.g., at least one) or a combination of the following information: source ID, destination ID (e.g., information about the service provided and / or the corresponding QoS), target user information, relay relationship information (e.g., whether the service allows relaying and / or the number of hops involved in the relay (e.g., the maximum number), or relay ID), and / or authentication information (e.g., information that can be used to support security).

[0096] In the example, discovery messages as described herein may be used in conjunction with (for example, to perform similar functions to) one or more of the following NAS messages, namely D2D or sidelink discovery messages, or direct communication request messages (for example, for NR V2X).

[0097] In the example, a discovery message may include a combination of a higher-layer message (e.g., a NAS message) and an AS layer message. For example, a discovery message may include a higher-layer message encapsulated within an AS layer message (e.g., a PC5-RRC message with a higher-layer container).

[0098] Sidelink discovery may be network-assisted. Sidelink discovery may be supported by a resource pool configuration procedure. The WTRU can determine resources for discovery data transmission. In the example, the WTRU may be configured (pre-configured) with one or more (e.g., multiple) dedicated resource pools for discovery transmission. In the example, the WTRU may be configured (pre-configured) with one or more resource pools. The WTRU may be configured (pre-configured) with a set of time / frequency resources (e.g., within each resource pool) for (e.g., possible) transmission of discovery data. The WTRU may be configured (pre-configured) with one or more resource pools for transmission of discovery data and / or other data.

[0099] Discovery information can be multiplexed with data (e.g., sidelink communication data). The WTRU can notify the gNB of the availability of discovery data. The WTRU can notify the gNB of the availability of discovery data to support the gNB scheduling decision, for example. Discovery data information can be sent, for example, via scheduling requests (SRs), media access control (MAC) control elements (CEs), and / or RRC messages.

[0100] A WTRU can send an SR to indicate the availability of discovery data. A WTRU can trigger an SR to indicate the availability of discovery data. In the example, a WTRU can (pre-configure) one or more (e.g., dedicated) SR resources to report the availability of discovery data. The arrival of discovery data may trigger an SR, for example, but not the transmission of a MAC CE (e.g., an SL Buffer Status Report (BSR)). In the example, a WTRU can (pre-configure) SR resources to indicate the availability of discovery data and other data. A WTRU can trigger the transmission of SRs and MAC CEs (e.g., SL BSRs). In the example, a WTRU can configure multiple SR resources / configurations for different characteristics of discovery data. A WTRU can select an SR based, for example, on the characteristics of the discovery data being sent.The characteristics of discovery data include, for example, the type of discovery (e.g., discovery for relay selection, discovery for relay re-selection, non-relay discovery, discovery for WTRU-to-WTRU relay, discovery for WTRU-to-NW relay, etc.), the priority / latency associated with the discovery, the period configured for discovery transmission, the WTRU type (e.g., relay WTRU, remote WTRU), the status of the relay WTRU / remote WTRU (e.g., connected for relay), and / or the number of remote WTRUs connected for relay, the size of the discovery message, the RRC status of the WTRU transmitting the discovery data, the relative time between the receipt of the discovery data and the end of the discovery period, the SL radio link failure (RLF) status in the WTRU at the time of discovery transmission (e.g., whether an SL RLF was triggered and / or whether recovery is in progress), the value of counters such as HARQ discontinuous transmission (DTX), or the SL causing the trigger. It may be one or more of the following: parameters associated with the RLF, the Uu RLF status of the WTRU (e.g., relay WTRU) at the time of sending the discovery message, or it may include one or more of these.

[0101] A WTRU can send a MAC CE to indicate the availability of discovery data. A WTRU can report the availability of discovery data by triggering the transmission of a discovery MAC CE (e.g., an SL BSR). In the example, a WTRU can report a discovery MAC CE, for example, as part of an SL BSR. A WTRU can (pre-configure) a dedicated destination ID and / or destination index, for example, to report the availability of discovery data. A WTRU can (pre-configure) one or more destinations, for example, to report the availability of discovery data. A WTRU can (pre-configure) one or more logical channels (LCHs) and logical channel groups (LCGs), for example, for each configured destination, to report buffer status. In the example, a WTRU can report the availability of discovery data by sending (e.g., an explicit) instruction in an SL BSR. A WTRU may use one or more fields within the MAC CE to indicate the QoS associated with the discovery data (e.g., latency, priority, and / or data volume), and / or any other characteristics associated with the discovery (e.g., characteristics as described herein). For example, a WTRU may send a MAC CE that can be used solely to indicate the presence of a discovery transmission. The MAC CE may be sent to the network (e.g., via a UL MAC CE) or to another WTRU (e.g., via an SL MAC CE).

[0102] A WTRU can determine the values ​​of one or more fields (e.g., each) within an SL BSR (e.g., an SL BSR associated with discovery data). A WTRU can report the availability of discovery data for transmission in the BSR (e.g., a WTRU can use a separate buffer status report for discovery data). In the example, a WTRU can determine the values ​​of one or more of the following fields within the SL BSR associated with discovery data: destination index, LCG, or buffer size.

[0103] A WTRU may (pre-configure) one or more destination indexes (e.g., dedicated destination indexes) to report the availability of discovery data. Discovery data (e.g., all discovery data) may be reported in the BSR along with a destination index (e.g., a single destination index). A WTRU may (pre-configure) each destination index to report discovery data associated with one or more destination IDs (e.g., L2 destination IDs). A WTRU may (pre-configure) indicate the availability of discovery data using one or more bits in the destination index field and / or another field (e.g., the LCG field or buffer size field).

[0104] A WTRU can be pre-configured with an LCG ID (e.g., a dedicated LCG ID). A WTRU can be pre-configured to represent an LCG ID using several bits. A WTRU can be pre-configured with LCG priority, for example, to determine the order of buffer status for discovery data. A WTRU can be configured not to include the destination index in the buffer status report. A WTRU can use the destination index to report other information, or to report a destination index associated with an L2 destination ID that may be associated with the discovery message. A WTRU can be pre-configured not to include LCG information in the buffer status report. Bits in the LCG field (e.g., all or a subset of bits in the LCG field) can be used to indicate other information, such as the buffer size.

[0105] A WTRU can be (pre-configured) to indicate the buffer size of the WTRU using several bits. The buffer size value can indicate the number of discovery messages (for example, if the size of discovery messages is fixed).

[0106] Figure 4 shows an example of bit allocation for SL or V2X BSR, where Oct may represent an octet. The x-axis can represent bits, as shown in Figure 4. In the first example, the WTRU may use 1 bit to indicate the LCG and 2 bits to indicate the buffer size. In the second example, the WTRU may use 3 bits to indicate the buffer size and no bits to indicate the LCG ID. The WTRU may use 5 bits to indicate the (pre-configured) destination index, for example, in the first and / or second example. In the third example, the WTRU may use 6 bits to indicate the destination index, 2 bits to indicate the buffer size, and no bits to indicate the LCG ID. The WTRU may use other bit allocation schemes to indicate the fields described herein. Buffer status associated with a discovery message may have a different size (e.g., a different number of bits) than buffer status associated with normal data (e.g., buffer status that does not include discovery message information), for example, as shown herein.

[0107] The WTRU can indicate, for example, the amount of discovery data (e.g., in bytes) to be sent in the BSR if one or more discovery transmissions are available in the WTRU. The WTRU can encode the buffer size field associated with the discovery transmission into, for example, a sequence of values ​​(e.g., each value can be associated with a size range of the discovery message). For example, the WTRU may be configured to send the buffer size of the discovery data using two bits. The WTRU may send a bit value "01" for small discovery data (e.g., x may be configured if the buffer size is 0 to x bytes), a bit value "10" for medium discovery data (e.g., if the buffer size is x to y bytes), and a bit value "11" for large discovery data (e.g., if the buffer size is y to z bytes), where x <y<zである。

[0108] A WTRU can determine the order in which destinations are reported (e.g., the order in which BSRs for those destinations are sent). A WTRU can determine the order of BSRs for discovery data based on the (pre-configured) priority of the LCG associated with the discovery-related BSRs. A WTRU can (pre-configure) priority levels for discovery-related BSRs. A WTRU can include (e.g., send) BSRs for discovery data and / or other data according to the respective priority of the LCG associated with those BSRs (e.g., the configured priority). A WTRU can, for example, prioritize BSRs for discovery data over other SL BSRs and / or UL BSRs.

[0109] A WTRU can use a MAC subheader to indicate the availability of discovery data. A WTRU can use one or more bits in the MAC subheader to indicate the availability of discovery data. For example, a WTRU can use one or more bits in the V field of the SL-SCH MAC subheader (e.g., the field indicating the SL-SCH version) and / or one or more bits in the R field of the SL-SCH MAC subheader (e.g., the reserved field) to indicate, for example, the availability of discovery data and / or the amount of discovery data. A WTRU can use two bits in the V field to indicate the buffer status of discovery data, where the two bits (e.g., each) can indicate the number of discovery data messages. A WTRU can use, for example, "01", "10", and "11" to indicate one, two, and three discovery messages being sent, respectively. A WTRU can indicate data availability, for example, if it sends an SL-SCH MAC subheader.

[0110] A WTRU can be configured with LCP restrictions for LCHs containing discovery data. For example, a WTRU can configure one or more destination IDs for discovery transmissions (e.g., pre-configured). A WTRU can be configured with LCP restrictions for discovery transmissions associated with data. For example, a WTRU may not be allowed to multiplex data and discovery within the same PDU. For example, a WTRU may, based on the selection of LCHs associated with data, not select LCHs associated with discovery to include in the same PDU. Based on the selection of LCHs associated with discovery, a WTRU may, not select LCHs associated with data to include in the same PDU.

[0111] A WTRU can have conditions associated with the application of restrictions. For example, whether or not such conditions apply may depend on the resource pool's CBR, the allowable transmit power or conditions associated with transmit power for PDUs, the size of the SL grant, and / or the data priority in the discovery LCH or data LCH, or the relative data priority in the discovery LCH and data LCH.

[0112] A WTRU can, for example, configure limit enforcement conditions that depend on the resource pool's CBR. For instance, a WTRU could enforce such a limit when the shared resource pool's CBR exceeds a threshold.

[0113] The WTRU can have limiting conditions configured, for example, depending on the allowable transmit power for the PDU, or conditions associated with the transmit power. For example, the WTRU can apply an LCP limit if the transmit power is limited by some factor (e.g., based on open-loop calculations or based on Uu RSRP).

[0114] A WTRU can have limitations applied based on, for example, the size of the SL grant. The size of the SL grant may be relative to the amount of data transmitted from either or both of the discovery LCH and the data LCH. For example, if the grant size is below a threshold, the WTRU may apply such a limitation. For example, if the difference between the grant size and the data in either the discovery LCH or the data LCH is below a threshold, the WTRU may apply such a limitation.

[0115] A WTRU can have its restriction application conditions configured according to, for example, the priority of either the discovery LCH or the data LCH, or the relative priority of the data in the discovery LCH and the data LCH. For example, if the priority of the discovery or data LCH is above (for example, above or below) a threshold, the WTRU can apply such a restriction. For example, if the difference in priority between discovery and data is greater than a threshold, the WTRU can apply such a restriction.

[0116] The WTRU can receive instructions from a network node (e.g., gNB) indicating whether a scheduled sidelink grant is for discovery data. In the example, the WTRU can determine whether discovery can be transmitted on the grant. The WTRU can perform LCP restrictions based on the grant instructions from the network, for example. If the network indicates that the grant can be used for discovery transmissions, the WTRU can avoid restricting multiple discovery on the TB for possible transmissions on the grant. If the network indicates that the grant may not be used for discovery transmissions, the WTRU can perform LCP restrictions to avoid including discovery LCHs in the grant. In the example, the WTRU can determine whether the grant is for discovery (e.g., for discovery only). If the grant is for discovery, the WTRU can use the grant for discovery transmissions (e.g., use the grant only for discovery transmissions). If the grant can be used for transmissions other than discovery (for example, if the grant is not solely for discovery), the WTRU may use the grant for other sidelink data transmissions.

[0117] A WTRU may be scheduled, for example, for Uu HARQ feedback, using sidelink grants and PUCCH resources. A WTRU may use scheduled sidelink grants, for example, for discovery transmissions. A WTRU may have a configured (e.g., pre-configured) number of transmissions for discovery TBs (e.g., a maximum and / or minimum number of transmissions). The minimum and maximum number of transmissions for discovery TBs may be equal. A WTRU may decide to request more resources for discovery transmissions based, for example, the number of transmissions it has performed for a single discovery TB transmission. If the number of transmissions is within the configured (e.g., pre-configured) range, the WTRU may not request more resources for discovery transmissions. Otherwise, the WTRU may request more resources for discovery transmissions. A WTRU may send an ACK in a PUCCH transmission to indicate that it does not want to request more resources, or it may send a NACK to indicate that it wants to request more resources.

[0118] A WTRU may perform LCP limiting, for example, to determine whether to multiplex discovery in the TB for transmission on a sidelink grant. A WTRU may perform LCP limiting on an LCH for discovery transmission, for example, based on one or any combination of the following characteristics of a sidelink resource: the size of the sidelink grant, the number of (re)transmission resources in the grant, and / or the frequency diversity of the grant.

[0119] The WTRU can implement LCP limits based, for example, on the size of the grant. If the grant size is greater than the threshold, the WTRU may choose not to multiplex the discovery LCH for the transmission of the discovery TB at the grant. If the grant size is less than or equal to the threshold, the WTRU may multiplex the discovery at the TB for potential discovery transmissions at the sidelink grant. The sidelink grant size threshold may be fixed (e.g., one subchannel) or configured (e.g., preconfigured). For example, the WTRU may be configured (e.g., preconfigured) to use a subchannel (e.g., at most one subchannel) for discovery transmissions. The WTRU can determine, based on the grant size, whether to multiplex the discovery at the TB for transmissions at the sidelink grant. If the grant size is one subchannel, the WTRU may multiplex the discovery at the TB. If the grant size is greater than one subchannel, the WTRU may choose not to multiplex the discovery at the TB for transmissions at the grant. In the example, a WTRU can configure (e.g., pre-configure) sidelink sizes (e.g., one or more sidelink sizes) for sending discoveries in an grant. Each size may be associated with a single resource pool, discovery service, etc. Based on the grant size, the WTRU can determine whether to multiplex discoveries in the TB for discovery transmission. If the grant size belongs to one of the configured (e.g., pre-configured) sizes, the WTRU can multiplex discoveries in the TB for transmission in the grant. Otherwise, the WTRU may choose not to multiplex discoveries in the TB.

[0120] A WTRU can implement LCP limits, for example, based on the number of (re)transmit resources in an grant. For example, a WTRU can configure (e.g., pre-configure) the number of transmit resources in an grant for discovery transmissions (e.g., the minimum and / or maximum number of transmit resources). A WTRU can determine whether to multiplex discovery in the TB for possible transmissions in a sidelink grant based on the number of (re)transmit resources associated with the grant. If the number of (re)transmit resources associated with the grant is within the configured (e.g., pre-configured) number of transmit resources, the WTRU can multiplex discovery data in the TB for discovery transmissions. Otherwise, the WTRU may choose not to multiplex discovery data in the TB.

[0121] The WTRU can implement LCP limitations based, for example, on the frequency diversity of the grant. For example, the WTRU can configure (e.g., pre-configure) one or any combination of the following frequency diversity rules for the transmission resources of a discovery TB: namely, the frequency gap between transmission resources (e.g., two transmission resources) or consecutive transmission resources (e.g., two consecutive transmission resources) is greater than a threshold, and / or the frequency range of transmission resources (e.g., two, three or more, or all transmission resources) is greater than a threshold. The WTRU can determine whether to multiplex discovery data in a sidelink grant based on whether the sidelink grant satisfies one or any combination of the frequency diversity rules (e.g., as described herein). If the sidelink grant satisfies the frequency diversity rules, the WTRU can multiplex discovery data in the TB; otherwise, the WTRU may choose not to multiplex discovery data in the TB.

[0122] A WTRU may send RRC messages (e.g., WTRU / UE assistance information (UAI)) to indicate changes in discovery data traffic. A WTRU may be scheduled using one or more configured grants (CGs) to send discovery messages. A WTRU may send RRC messages (e.g., WTRU / UEAssistantInformation or UAI) to indicate changes in discovery data traffic (e.g., based on changes in discovery data traffic). A WTRU may send RRC messages based on at least one of the following triggers, for example, the availability of discovery data, changes in the period and / or offset of discovery data, changes in the QoS of discovery data, changes in the size of discovery data, or changes in the characteristics of discovery data (e.g., as described herein). A WTRU may implicitly or explicitly include one or more (e.g., any combination) of the expected period of discovery data, expected offset of discovery resources, etc., in an RRC message associated with discovery data.

[0123] A WTRU can determine which data can be multiplexed with discovery data. In the example, a WTRU can (pre-configure) one or more destinations for discovery data. The WTRU can multiplex discovery data with other data based, for example, on the receipt of other data that has destinations belonging to a set of (pre-configured) data. In the example, a WTRU can receive configuration information (e.g., LCH configuration information) indicating whether a particular LCH allows data from the LCH to be multiplexed with discovery data. A WTRU performing logical channel prioritization (LCP) can multiplex data from permitted LCHs (e.g., only data from permitted LCHs) with discovery data. Permitted LCHs may be indicated in the LCH configuration information (e.g., whether they are permitted or not to be multiplexed with discovery data).

[0124] A WTRU can receive dedicated / preferred grants for discovery transmissions. For example, a WTRU can receive a grant dedicated to transmitting discovery data, and a WTRU can transmit discovery data (e.g., discovery data only) in the grant. For example, a WTRU can receive a permission that discovery data may be preferred. A WTRU can multiplex discovery data (e.g., using LCP) in the grant, which has a higher priority than non-discovery data. A WTRU can determine the priority of discovery data in LCP, for example, depending on whether the grant is preferred over discovery data. A WTRU can receive prioritization instructions, for example, in the DCI associated with an SL grant, or in the RRC configuration information of a configured sidelink grant.

[0125] The WTRU can determine the priority of discovery data in LCP. The WTRU can determine the priority of discovery data for transmission (e.g., in the LCP procedure) based, for example, on one or more of the following characteristics of the discovery data (as described herein), namely, LCH (e.g., and associated configuration information associated with the discovery data), sidelink channel measurements at transmission (e.g., CBR, CR, and / or sensing results), the presence of additional SL appendages at transmission (e.g., configured appendages), the time gap between the arrival time of the discovery data and the timing of the selected resource for transmission, the remaining PDB of the message, or the discovery model.

[0126] A WTRU can determine the priority of discovery data for transmission based on the time gap between the arrival time of the discovery data and the timing of the resource selected for transmission. The WTRU can determine the priority of a discovery message as a function of the time gap between the arrival time of the discovery message and the selected resource. In the example, a WTRU can assign a higher priority if the time gap is large. In the example, a WTRU can assign a lower priority if the time gap is small.

[0127] A WTRU can determine the priority of discovery data for transmission based on the remaining packet delay budget (PDB) of the message. A WTRU can assign higher priority to TBs with lower remaining PDBs, or lower priority to TBs with higher remaining PDBs. The remaining PDB can be determined as the time gap between the selected resource and the immediately preceding slot in which the WTRU can transmit the TB.

[0128] A WTRU can determine the priority of discovery data for transmission based on one or more discovery models. A WTRU can receive configuration information about multiple priority levels (e.g., two or more priority levels) associated with a discovery message. A first priority level may be associated with a first discovery message model (e.g., a Model A discovery message). A second priority level may be associated with a second discovery message model (e.g., a Model B discovery message). A WTRU can determine the priority of a discovery message based on which discovery model is used.

[0129] For example, a WTRU can assign a higher priority to discovery data within an LCP if the discovery data is associated with the WTRU that triggered the SL RLF and / or the WTRU in which recovery is in progress. A WTRU can be assigned a first priority associated with the discovery (for example, based on configuration information), and the WTRU can be changed to a second priority associated with the discovery if the discovery is associated with one or more (pre-configured) or predefined characteristics.

[0130] The WTRU can determine the QoS of the discovery data. The WTRU can (pre-configure) one or more LCHs for the discovery data. (For example, each) LCH may be associated with one or more of the following parameters: priority range, latency, reliability, minimum communication range, and / or discovery period. The WTRU may receive one or more of these parameters (for example, any combination) from a higher layer (for example, the WTRU receives parameter instructions). The minimum communication range may be indicated, for example, via transmit power, minimum transmit power, and / or maximum transmit power.

[0131] A WTRU can determine the QoS of a discovery message. For example, a WTRU can determine one or more (e.g., any combination) of the following QoS parameters that can be associated with a discovery message: message priority, message latency, message reliability, message minimum range, and the discovery period associated with the message. A WTRU can determine (e.g., each) parameter based on the type of data multiplexed in the message. QoS parameters can be determined, for example, as the minimum, maximum, or average values ​​of (e.g., each) type of data multiplexed in the message.

[0132] A WTRU can select a resource pool for sending discovery data. For example, a WTRU can select a resource pool for sending discovery data based on one or more of the following (e.g., any combination): the QoS of the discovery data, the supported period of the resource pool, the resource selection type of the resource pool, the CBR of the resource pool, and / or the CR of the WTRU. For example, a WTRU can select a resource pool with the lowest CR (e.g., in combination with other criteria).

[0133] In the example, the WTRU can be configured (in advance) with a dedicated resource pool for sending discovery messages. A discovery message may belong to one or more of the following messages: a discovery message containing discovery data (e.g., discovery data only), and / or a discovery message containing discovery data and other data.

[0134] In the example, the WTRU can select resource pools that meet the QoS requirements for the discovery data. The WTRU can determine the latency, priority, reliability, minimum communication range, period, and / or other parameters associated with the discovery data. The WTRU can select one or more resource pools that satisfy one or more combinations of parameters (e.g., any decidable, selectable, configurable, or shown). For example, the WTRU can select resource pools with a discovery period smaller than the data latency and / or discovery period. The WTRU can select resource pools with the lowest supported period.

[0135] In the example, the WTRU can select a resource pool that supports random resource selection or sensing-based resource selection based, for example, on the QoS of the discovery data. For example, the WTRU can select a resource pool using random resource selection if the priority value of the discovery data is greater than a threshold. The WTRU can select a resource using sensing-based resource selection for discovery data with a priority value less than a threshold. The threshold can be configured (in advance), for example, per service or per resource pool. The WTRU can select the resource pool with the lowest CBR.

[0136] The WTRU can perform prioritization between discovery transmits / receives and other sidelink and / or uplink transmits / receives. The WTRU can perform prioritization between discovery transmits / receives and other sidelink and / or uplink transmits / receives based on one or more of the following (e.g., any combination): the priority of discovery transmits / receives and / or the priority of other data transmits / receives, sidelink conditions, the WTRU's coverage status, relay availability, and the characteristics of the discovered data (e.g., as described herein).

[0137] A WTRU can perform prioritization, for example, based on the priority of discovery transmission / reception and / or the priority of other data transmission / reception. A WTRU can determine, for example, which data to perform resource selection / transmission / reception on first, based on the priority of the relevant data. A WTRU may (for example) be configured to determine whether to prioritize discovery data over data with the same priority. A WTRU may prioritize discovery data if its priority value is below a threshold (e.g., less than or equal to the threshold). A WTRU may prioritize other data if its priority value is above a threshold (e.g., greater than or equal to the threshold).

[0138] A WTRU can perform prioritization based on sidelink conditions, for example. A WTRU can prioritize discovery transmissions / receptions based on sidelink conditions between itself and another WTRU (e.g., a relay WTRU, a source WTRU, or a destination WTRU). A WTRU can prioritize data transmissions if the sidelink between it and another WTRU is in good condition (e.g., RSRP is greater than the threshold, no RLFs have been detected, the distance between the two WTRUs is less than the threshold). A WTRU can prioritize discovery data transmissions / receptions if the sidelink transmission between it and another WTRU is in poor condition based on one or more unfavorable conditions (e.g., RSRP is less than the threshold, an RLF has been detected, the distance between the two WTRUs is greater than the threshold).

[0139] WTRUs can perform prioritization based, for example, on their coverage status. For example, a WTRU can prioritize discovery transmissions if it is within network coverage. For example, a WTRU can prioritize discovery receptions if it is outside network coverage.

[0140] A WTRU can perform prioritization based, for example, on relay availability. For example, if a WTRU does not have an existing relay, it can prioritize discovery data transmission / reception. For example, if a WTRU has a connection to a relay, it can prioritize other data transmission / reception.

[0141] A WTRU can perform prioritization based, for example, on the characteristics of the discovery data (as described herein). For example, a WTRU may prioritize discovery transmissions over data transmissions if the latency associated with the discovery data for the end of the discovery period is above / below a threshold. For example, a WTRU may prioritize discovery transmissions / receptions over data transmissions if it has pending SL-RLFs or is performing recovery.

[0142] A WTRU may perform autonomous procedures. A WTRU may (e.g., autonomously) determine the discovery transmission content and / or parameters (e.g., transmission behavior). A WTRU may determine the transmission content and / or parameters of a message. The transmission content and / or parameters of a TB (e.g., a discovery message) may include, for example, one or more (e.g., any combination) of the following: the probability of transmitting the (e.g., discovery) message (e.g., the probability that a WTRU will transmit a pending discovery message for a given period or resource), the message sensing and / or resource selection time, the number of retransmissions, the number of subchannels (e.g., used for transmitting the TB), the modulation and coding scheme (MCS), the transmission power, the DMRS pattern of the PSSCH, the sensing window and / or resource selection window, the resource pool used for transmitting the message, etc.

[0143] The WTRU may determine the TB's transmitted content and / or parameters based on one or more of the following (e.g., any combination): the type of data multiplexed in the TB, the QoS of the arrival time messages of the discovery data within the discovery period (e.g., discovery messages), the resource pool's CBR and / or the WTRU's CR (e.g., the WTRU can determine that the transmission behavior of the discovery data, such as transmission parameters, is not a function of the CBR and / or CR), the WTRU's past transmission activity, and the characteristics of the discovery data (e.g., as described herein).

[0144] A WTRU can determine the type of data to be multiplexed in a TB. For example, a WTRU can determine the transmission content and / or parameters of a message (e.g., a discovery message) based on the type of data multiplexed in the message. A WTRU can (pre-configure) one or more transmission contents and / or parameters. (For example, each) transmission content and / or parameter may be associated with (e.g., one) type of TB. A WTRU can determine the transmission content and / or parameters based on the type of TB. For example, a WTRU can (pre-configure) three transmission behaviors (e.g., content and / or behavior) for three types of TBs. A WTRU can perform a first transmission behavior for a TB without discovery data. A WTRU can perform a second transmission behavior for a TB with discovery data and other data (e.g., normal data). A WTRU can perform a third transmission behavior for a TB with only discovery data.

[0145] A WTRU can determine which resource pool to use to send a message (for example, which resource pools can use resources to send a message). A WTRU can determine which resource pool to use to send a message based, for example, on the type of data multiplexed within the message. For example, a WTRU may have two sets of resource pools. One resource pool may be dedicated to discovery messages, and the other may be dedicated to data messages. A WTRU may, for example, send a message in the first resource pool if the message contains discovery data. A WTRU may, for example, send a message in the second resource pool if the message does not contain discovery data.

[0146] A WTRU can determine the probability of sending a discovery message. A WTRU can perform the following steps to send a message with a certain probability. For example, a WTRU can (for example, initially) randomly generate a value between 0 and 1. A WTRU can send a message if, for example, the generated value is less than a (pre-configured) probability. A WTRU can drop a message if, for example, the generated value is greater than or equal to a (pre-configured) probability.

[0147] A WTRU can determine the transmission probability of a message (e.g., a discovery message) based on the relevant QoS (e.g., priority, latency, minimum range, and / or discovery period) of the discovery message. For example, a WTRU can (pre-configure) the priority and transmission probability of each discovery message. A WTRU can determine the priority and associated transmission probability of discovery data based on the discovery data (e.g., based on the arrival of the discovery data) (e.g., based on signaling from higher layers). A WTRU can then perform the transmission of the discovery message according to the associated probability. A WTRU may choose not to apply the transmission probability if the discovery message contains both discovery data and other data.

[0148] A WTRU can determine the transmit power of a discovery message. A WTRU can (pre-configure) parameters (e.g., multiple sets of parameters) for determining the transmit power of a message in a resource pool. Each set of parameters may be associated with a data type. Each set of parameters may include one or more of the following (e.g., any combination): power offset and alpha value, maximum transmit power, etc.

[0149] A WTRU can determine the transmit power for a message based on the type of data multiplexed within the message. For example, a WTRU can (pre-configure) multiple (e.g., two) sets of parameters for determining the transmit power of a message in a resource pool. The first set may be associated with discovery data, and the second set may be associated with other data. A WTRU can determine the transmit power of a message based on the type of data multiplexed within the message. For example, if a message has discovery data, a WTRU can use the first set of parameters to determine the transmit data. A WTRU can combine the two sets of parameters to determine the transmit power, or, for example, if a message (e.g., a discovery message) contains discovery data and other data, a second set of parameters can be used.

[0150] A WTRU can determine the transmitted content and / or parameters based on the arrival time of discovery data. A WTRU can determine the transmitted content and / or parameters of a message (e.g., a discovery message) based on the arrival time of the message. A WTRU may determine whether to perform resource selection for discovery messages in a discovery period (e.g., for discovery data arriving in a discovery period, where the discovery period may be the current discovery period as used herein), or for discovery messages in a subsequent period (e.g., a consecutive discovery period or a subsequent discovery period occurring after the discovery period), or for discovery messages in both periods, based on one or more of the following (e.g., any combination) of the time gap between the arrival time of discovery data and the end of the discovery period, the QoS of the discovery period, etc.

[0151] The WTRU can determine, for example, whether to perform resource selection for discovery messages in the discovery period and / or the next period based on the time gap between the arrival time of discovery data and the end of the discovery period. For example, if the time gap between the arrival time and the end of the discovery period is less than a threshold, the WTRU can perform resource selection in the next period. For example, if the time gap between the arrival time and the end of the discovery period is greater than or equal to a threshold, the WTRU can perform resource selection in the discovery period and / or in both the discovery period and the next discovery period.

[0152] The WTRU can, for example, determine whether to perform resource selection for discovery messages during the discovery period and / or the next period based on the QoS of the discovery period. For example, if the discovery latency is below a threshold, the WTRU can perform resource selection for sending discovery messages during the discovery period and / or both the discovery period and the next discovery period. For example, if the discovery latency is above a threshold, the WTRU can perform resource selection for sending discovery data during the next discovery period.

[0153] A WTRU can determine the transmission content and / or parameters based on the message's QoS. For example, a WTRU can determine the transmission content and / or parameters of a message (e.g., a discovery message) based on the QoS of the data (e.g., priority and / or latency) and / or the QoS of the discovery data. For example, a WTRU may not perform (e.g., may not be allowed to perform) the transmission of discovery data that is not multiplexed with other data if the priority of the discovery data is greater than a threshold. For example, a WTRU may not be allowed to trigger the sensing and / or resource selection of discovery data if the priority of the data is greater than a threshold. Thresholds can be configured (in advance), for example, per resource pool or per service. A WTRU can determine the probability of transmitting discovery data according to the priority of the discovery data.

[0154] A WTRU can determine the transmission content and / or parameters based on the resource pool's CBR and / or the WTRU's CR. For example, a WTRU can determine the transmission content and / or parameters of a message (e.g., a discovery message) based on the resource pool's CBR and / or the WTRU's CR. For example, a WTRU can (pre-configure) one or more transmission behaviors (e.g., content and / or parameters) for a discovery message. Each (e.g.) behavior may be associated with a CBR range (e.g., one CBR range) and / or a CR range (e.g., one CR range). A WTRU may, for example, not perform (e.g., not be allowed to perform) the transmission of a discovery message that does not multiplex with data if the CBR and / or CR are greater than a threshold. A WTRU can, for example, determine the transmission probability of a discovery message based on the resource pool's CBR and / or the WTRU's CR. A WTRU can (pre-configure) the transmission probability of a discovery message for each (e.g.) CBR range.

[0155] A WTRU can determine the transmission content and / or parameters based on its past transmission content and / or parameters. A WTRU can determine the transmission content and / or parameters of a discovery message (e.g., the current discovery message) based on its past transmission content and / or parameters (e.g., transmission content and / or parameters associated with discovery data). A WTRU can modify the probability of sending discovery data during a given period based on its transmission activity of discovery data during the previous period. A WTRU can increase the probability of sending discovery data during a given period if it did not send discovery data during the previous discovery period or during several previous discovery periods (e.g., the WTRU has a 1% chance of sending discovery data). This or similar method based on transmission content and / or parameter history can support the transmission of at least one discovery message within a given time period.

[0156] A WTRU can determine the transmission content and / or parameters of a message (e.g., a discovery message) based on one or more characteristics of the message. For example, as defined herein, a WTRU can determine the transmission content and / or parameters of a message (e.g., a discovery message) based on one or more characteristics of the message. For example, if a discovery message is received with a pending RLF, the WTRU can perform resource selection using a first resource selection window, and for example, if a discovery message is received without a pending RLF, the WTRU can perform resource selection using a second resource selection window.

[0157] Resource allocation can be time-based resource allocation (e.g., timer-based resource allocation). Figure 5 shows an exemplary resource allocation for discovery data using discovery resource allocation time. The WTRU can determine the timing of message sensing and / or resource selection. The WTRU can perform sensing and / or resource selection based on the arrival of a message (e.g., a discovery message), for example, as shown in Figure 5. The WTRU can track duration (e.g., via a timer that the WTRU can start) to determine the timing of message sensing and / or resource selection. The WTRU can trigger message sensing and / or resource selection (e.g., based on the expiration of the duration and / or timer). A WTRU may determine whether to track discovery resource selection time (for example, via a discovery resource selection timer that the WTRU can start) based on one or more of the following (e.g., any combination): the QoS of the discovery data (e.g., priority and / or latency of the discovery data), the discovery period and / or arrival time of the discovery data, the resource pool's CBR, the WTRU's buffer status and / or WTRU's CR, the availability of the sensing result, the availability of reserved resources, and the characteristics of the discovery message (e.g., as defined herein).

[0158] A WTRU can determine whether to track discovery resource selection time (e.g., via a discovery resource selection timer) based on the QoS of the discovery data (e.g., the priority and / or latency of the discovery data). A WTRU can track discovery resource selection time (e.g., via a timer) if the priority of the discovery timer is greater than a threshold (e.g., as shown in Figure 5). A WTRU can skip tracking discovery resource selection time (e.g., via a timer) if the priority of the discovery timer is below a threshold (e.g., as shown in Figure 5). Priority thresholds can be configured (pre-configured), for example, per resource pool or per service.

[0159] The WTRU can determine whether to track the discovery resource selection time (e.g., via a discovery resource selection timer) based, for example, on the discovery period and / or the arrival time of the discovery data. The WTRU can track the discovery resource selection time (e.g., via a discovery resource allocation timer) if, for example, the discovery period is greater than a threshold. The WTRU discovery period can be derived from the LCH of the discovery data. The WTRU can track the discovery resource selection time (e.g., via a discovery resource selection timer) if, for example, the discovery period is greater than a threshold and / or the time gap between the arrival time of the discovery data and the slot immediately preceding the discovery period is greater than a threshold. The discovery period can be configured (in advance) for each resource pool.

[0160] A WTRU can determine whether to track discovery resource selection time (e.g., via a discovery resource selection timer) based on the resource pool's CBR. A WTRU can track discovery resource selection time (e.g., via a discovery resource allocation timer) if the resource pool's CBR is greater than a threshold. Thresholds can be configured (pre-configured), for example, per resource pool or per service. A WTRU can (pre-configured) a CBR threshold as a function of the discovery data's QoS (e.g., priority and / or latency). A WTRU can (pre-configured) multiple CBR thresholds to track discovery resource selection time (e.g., via a discovery resource selection timer). Each threshold can be associated with the discovery data's priority (e.g., one priority) and / or latency range (e.g., one latency range).

[0161] A WTRU can determine whether to track discovery resource selection time (e.g., via a discovery resource selection timer) based, for example, the WTRU's buffer status and / or the WTRU's CR. A WTRU can track a second time (e.g., via a second timer) if, for example, there is no data associated with a (pre-configured) set of available destinations in the buffer. A WTRU can track discovery resource selection time (e.g., via a discovery resource selection timer) if, for example, data associated with a (pre-configured) destination is available in the buffer. A WTRU can track discovery resource selection time (e.g., via a discovery resource selection timer) if, for example, the WTRU has data associated with a particular LCH that may have a higher priority than the discovery data. A WTRU can track discovery resource selection time (e.g., via a discovery resource selection timer) if, for example, the WTRU's CR is above a threshold.

[0162] The WTRU can determine whether to track the discovery resource selection time (e.g., via a discovery resource selection timer) based on the availability of sensing results, for example. For example, the WTRU can (pre-configure) several sensing slots (e.g., a minimum number of sensing slots) before performing resource selection. The WTRU can track the discovery resource selection time (e.g., via a discovery resource selection timer) if the number of sensing slots is less than a threshold.

[0163] The WTRU can determine whether to track discovery resource selection time (e.g., via a discovery resource selection timer) based on the availability of reserved resources, for example. The WTRU can send a discovery message using reserved resources if the reserved resources satisfy one or more of the following conditions (e.g., any combination): the timing of the reserved resources satisfies the latency requirements for the discovery data; the number of reserved resources satisfies the reliability requirements for the discovery message (e.g., the number of reserved resources is greater than a threshold); and / or the number of reserved subchannels is greater than a first threshold and / or less than a second threshold. For example, the WTRU may be configured to send a discovery message using a subchannel resource (e.g., one). The WTRU may choose not to track discovery resource selection time (e.g., via a discovery resource selection timer) if a subchannel resource (e.g., one) has been previously reserved.

[0164] The WTRU can determine the initial value of the discovery resource selection time (for example, as shown in Figure 5). The initial value of the time can be determined as a function of one or more (e.g., any combination) of the following parameters: QoS of discovery data (e.g., priority as shown in Figure 5, and / or latency of discovery data), discovery period and / or arrival time of discovery data, CBR of the resource pool and / or CR of the WTRU (e.g., as shown in Figure 5), and characteristics of discovery messages (e.g., as defined herein). The WTRU can have minimum and / or maximum values ​​for discovery resource allocation time. The minimum and / or maximum limits can be (pre)configured based on one or more (e.g., any combination) of the parameters. The WTRU can determine the initial value of sensing and / or resource selection by, for example, randomly selecting values ​​within the minimum and maximum (pre)configured values.

[0165] A WTRU can determine which data to multiplex with discovery data. A WTRU can multiplex discovery data with other data (e.g., decide / determine multiplexing) based on one or more of the following (e.g., any combination): the destination of other data, the QoS of the other data, the QoS of the discovery data, etc. A WTRU can (pre-configure) one or more destinations for multiplexing discovery data, for example, it can configure data that has destinations belonging to a set of (pre-configured) destinations.

[0166] The WTRU can perform sensing and / or resource selection, for example, as shown in Figure 5, when the discovery resource selection time expires (for example, via a discovery resource selection timer). The WTRU can perform sensing and / or resource selection for a discovery message based on the expiration of the discovery resource selection time (for example, via a discovery resource selection timer). The WTRU can construct a MAC PDU using the discovery data, for example, as shown in Figure 5, only if there is no available data in the buffer belonging to a (pre-configured) set of destinations. The WTRU can multiplex the discovery data with other data, for example, as shown in Figure 5, if there is available data in the buffer belonging to a (pre-configured) set of destinations.

[0167] The WTRU can apply time and / or frequency limits between selected resources for discovery messages. For example, the WTRU can select resources for each (e.g.) transmission of a TB such that the time and / or frequency gap between two selected resources is greater than a first threshold and / or less than a second threshold. Time / frequency thresholds can be configured (pre-configured), for example, per resource pool and / or per service. The WTRU can apply time and / or frequency limits during the resource selection procedure. For example, the WTRU can exclude (e.g., all) resources in a set of selectable resources (before selecting the next resource) if the time and / or frequency gap between previously selected resources is less than a first threshold and / or greater than a second threshold. The WTRU can select resources such that the time and / or frequency gap between two consecutive resources is fixed.

[0168] In the example, a WTRU can perform resource selection for the transmission of, for example, one or more TBs. A WTRU can select transmission resources such that the frequency range between two selected resources within a single window is greater than a first frequency range threshold and / or less than a second frequency range threshold. A WTRU can select transmission resources such that the time gap between two selected resources (e.g., the time gap between consecutively selected resources, the time gap between any two selected resources for a TB, etc.) is greater than a first time gap threshold and / or less than a second time gap threshold. Time gap thresholds and / or frequency range thresholds may be configured (e.g., pre-configured) for a resource pool. A WTRU may have multiple time gap thresholds and / or frequency range thresholds configured (e.g., pre-configured). Each threshold may be associated with one or any combination of the TB's QoS, the resource pool's CBR, the TB's HARQ type, and / or the TB's traffic type.

[0169] Thresholds can be determined based on the TB's QoS. For example, a WTRU may have one threshold per priority (e.g., a time gap threshold and / or frequency range threshold). The WTRU can then decide which threshold to use, for example, based on the TB's priority.

[0170] Thresholds can be associated with the resource pool's CBR. WTRUs can have thresholds configured for each CBR range. WTRUs can, for example, determine which threshold to use based on the resource pool's measured CBR.

[0171] Thresholds can be associated with the HARQ type of a TB. For example, a WTRU may have two sets of thresholds (e.g., a time gap threshold and / or a frequency range threshold). One set of thresholds may be associated with HARQ-enabled TBs, and the other set of thresholds may be associated with HARQ-disabled TBs. The WTRU can then decide which set of thresholds to use, for example, based on the HARQ type of the TB.

[0172] Thresholds can be associated with the traffic type of the TB (e.g., unicast, groupcast and / or broadcast, periodic traffic and / or aperiodic traffic). For example, a WTRU may have two sets of thresholds (e.g., a time gap threshold and / or frequency range threshold), the first set of which may be used for periodic traffic and the other set of which may be used for aperiodic traffic. The WTRU can then determine, for example, which threshold to use based on the traffic type of the TB.

[0173] The WTRU can determine the number of retransmissions for discovery messages. The WTRU can (pre-configure) the number of retransmissions for discovery messages (e.g., a minimum and / or maximum number of retransmissions). The WTRU can (for example, randomly) select the number of retransmissions for discovery messages within the (pre-configured) minimum and maximum number of retransmissions.

[0174] A WTRU can perform resource selection in a shared resource pool between discovery data and other data. A WTRU can perform resource selection for discovery transmissions in a shared resource pool between discovery and data. A WTRU can select the transmission of one or more (e.g., all) discovery messages in a time / frequency resource configured for discovery transmissions. A WTRU can select (e.g., the first) several resources within a time / frequency resource configured for discovery transmissions. A WTRU can make a selection (e.g., restrict selection) in the first transmission in a time / frequency resource configured for discovery transmissions. This technique can support the decoding of discovery messages by other WTRUs, for example, if other WTRUs are not aware of the entire data resource pool.

[0175] A WTRU can indicate power control and discovery decoding. A WTRU can indicate its transmit power in discovery messages. A WTRU can implicitly / explicitly indicate its transmit power information in discovery messages. Transmit power information can be used, for example, to derive the WTRU's transmit power. Transmit power information may be one or more of the following (e.g., any combination): path loss (e.g., downlink path loss and / or sidelink path loss), resource pool CBR, transmit power, etc.

[0176] A WTRU can explicitly or implicitly send instructions for the transmit power for discovery data. A WTRU can indicate transmit power using one or more of the following (e.g., any combination): destination ID, TB QoS, dedicated fields in the message, transmit resources, and WTRU location.

[0177] A WTRU can indicate its transmit power, for example, using a destination ID. For example, a WTRU can (pre-configure) multiple destinations. For example, each destination may be associated with a transmit power value. A WTRU can (implicitly) indicate its transmit power, for example, via a destination ID.

[0178] A WTRU can indicate transmit power, for example, using the TB's QoS. A WTRU can (implicitly) indicate transmit power, for example, via the TB's QoS (e.g., priority and / or minimum communication range). A WTRU can (pre-configure) transmit power, for example, as a function of transmit priority. A transmitting WTRU (Tx WTRU) can determine the transmit power of a discovery TB, for example, based on the TB's priority. A receiving WTRU (Rx WTRU) can determine the transmit power of the Tx WTRU, for example, based on the priority field indicated in the TB's sidelink control information (SCI). A WTRU can (pre-configure) transmit power, for example, as a function of communication range (e.g., minimum communication range). A WTRU can determine transmit power based on the WTRU's communication range (e.g., minimum communication range). An Rx WTRU can determine the transmit power of the Tx WTRU, for example, based on the communication range (e.g., minimum communication range) value indicated in the SCI.

[0179] A WTRU can indicate transmit power, for example, using a dedicated field within the message. A WTRU can indicate transmit power, for example, using one or more transmit resources (e.g., the number of time / frequency resources and / or subchannels used for transmitting discovery data). A WTRU can (pre-configure) the transmit resources for discovery data, for example, depending on one or more transmit power information (e.g., any combination). A WTRU can select transmit resources, for example, based on the CBR of the resource pool. A WTRU can (pre-configure) transmit power, for example, as a function of the number of subchannels used for transmitting discovery messages. An Rx WTRU can determine the transmit power of a Tx WTRU, for example, by the number of subchannels used for discovery transmission.

[0180] A WTRU can indicate the transmit power using, for example, the WTRU's location. A WTRU can indicate the transmit power using the WTRU's zone ID (e.g., absolute zone or relative zone). A relative zone may be a zone that uses the location of a point (e.g., gNB) as coordinates in zone calculations.

[0181] A WTRU can implicitly or explicitly transmit its transmit power information using one or more of the following (e.g., any combination): a first SCI, a second SCI, an SL MAC CE, an SL RRC message, or a higher layer message. A WTRU can also transmit its discovery transmit power (e.g., in an SL RRC message) if it changes the power of its discovery message transmission (e.g., as a result of one or more triggers as described herein).

[0182] A WTRU can indicate the presence of a discovery message. A WTRU can indicate the transmission of a discovery message, for example, in an SCI. A WTRU can indicate the presence of a discovery message in data carried in the associated PSSCH, for example, using one or more bit fields in the SCI (e.g., a first one). A WTRU can (pre-configure) one or more code points. (e.g., each) code point may be associated with (e.g., one) type of discovery. A WTRU can indicate a code point associated with the discovery type of the WTRU. A WTRU can (pre-configure) a bit field (e.g., one of two bit fields) to indicate the presence of a discovery message. For example, code point 01 can be used to indicate discovery for relay services, code 10 can be used to indicate direct sidelink discovery, and code 00 can be used to indicate non-discovered data. A WTRU can indicate the presence of discovery data based on the discovery type, for example, by indicating code point 01 or 10. An Rx WTRU can determine whether to decode a message (for example, further) based on the (pre-configured) discovery type of the WTRU being monitored. A WTRU not configured to decode a discovery message may not decode the message further if, for example, the discovery bit field is decoded to be 01 or 10. For example, a WTRU configured to monitor a discovery service (for example, a relay service associated with code 01) may not decode the message if, for example, the discovery bit field is not 01.

[0183] A WTRU can use an SCI format (e.g., a second SCI format) to indicate the presence of discovery data. A WTRU can use a second SCI to indicate the discovery type. An Rx WTRU can determine whether to decode the second SCI (e.g., further) based on the indication of the second SCI format for discovery. A WTRU (e.g., an RX WTRU) can decode (e.g., continue decoding) the second SCI format if, for example, the first SCI indicates the presence of the second SCI format for discovery. A WTRU can refrain from continuing to decode the message if, for example, the first SCI does not indicate the presence of the second SCI format for discovery.

[0184] A WTRU can indicate the presence of a discovery message, for example, by using a different scrambling sequence (e.g., a different initialization) compared to the normal scrambling sequence for the first SCI. A WTRU that monitors discovery messages (e.g., monitors only discovery messages) can decode discovery messages using a scrambling sequence specifically for discovery messages.

[0185] A WTRU may include, for example, other information associated with the discovery message in a transmission indicating the discovery message and / or another message (for example, an SL RRC message that can provide information for subsequent discovery transmissions, e.g., all discovery transmissions). A WTRU may include (e.g., together with the discovery message) one or more elements associated with the characteristics of the discovery message (e.g., as defined herein).

[0186] A WTRU may use a MAC header to send discovery messages. A WTRU may (pre-configure) a dedicated ID for discovery transmission (e.g., a destination L1 ID). For example, the dedicated destination ID for discovery may be a specified value or a (pre-configured) value (e.g., a field with all zeros). In response to receiving discovery data and / or associated IDs (e.g., L2 IDs) (e.g., from the network or a higher layer), a WTRU may send a discovery message by performing one or a combination of the following: The WTRU may indicate the dedicated ID (e.g., a destination L1 ID) in the SCI. The WTRU may transmit the L2 destination ID (e.g., the entire L2 destination ID) at the MAC layer by constructing a MAC header or MAC PDU that includes at least the associated ID (e.g., the entire L2 ID) of the discovery message provided by the network or a higher layer. A WTRU may transmit an L2 destination ID (e.g., the entire L2 destination ID) at the MAC layer by including a MAC CE containing the L2 ID (e.g., the complete L2 ID) (e.g., in a PDU transmission containing a discovery message). A WTRU may transmit an L2 destination ID (e.g., the entire L2 destination ID) at the MAC layer by transmitting a discovery message using an SL MAC CE (e.g., a discovery MAC CE), such a MAC CE may contain the complete L2 ID and / or discovery data. A WTRU may transmit a discovery message based on performing one or more of the operations described herein.

[0187] A WTRU can, for example, indicate an L2 ID to a higher layer by reading the MAC header of a discovery message. A WTRU can be (pre-configured) with a dedicated ID (e.g., a destination L1 ID) for discovery reception. A WTRU can read an ID (e.g., a destination L2 ID) (for example, based on the discovery of a discovery message), which can be shown in the MAC header of the message, in the MAC CE, or within the MAC PDU. A WTRU can indicate the acquired ID and / or associated measurements to a higher layer.

[0188] WTRUs can prioritize between discovery and data transmission. WTRUs can prioritize transmissions across different resource pools. WTRUs can (pre-configure) priority thresholds for each resource pool. WTRUs can (pre-configure) a set of associated resource pools (for each resource pool) to determine, for example, which time / frequency resources in a transmission resource pool overlap with those in the associated resource pool.

[0189] WTRU can prioritize transmissions among different resource pools during the resource selection procedure. WTRU can determine, for example, whether to exclude overlapping time / frequency resources from other resource pools based on transmission priority and / or the (pre-configured) priority of the resource pool. For example, if TB's priority is greater than / less than the (pre-configured) priority of the resource pool, WTRU can exclude (e.g., all) overlapping time / frequency resources from other resource pools during the resource selection procedure. Conversely, if TB's priority is less than / greater than a threshold, WTRU can choose not to exclude overlapping resources during the resource selection procedure.

[0190] A WTRU can (pre-configure) multiple (e.g., two) resource pools. One resource pool may be used for data transmission, and the other for discovery transmission. A WTRU can configure one priority threshold for the data resource pool and another priority threshold for the discovery resource pool. A WTRU can perform resource selection for (e.g., one) TB in the data resource pool. A WTRU can exclude (e.g., all) time / frequency resources that overlap with the discovery resource pool if, for example, the priority of a TB is greater than / less than the (pre-configured) priority of the discovery resource pool. A WTRU can perform resource selection for discovery messages in the discovery resource pool. A WTRU can exclude all time / frequency resources that overlap with the data resource pool if, for example, the priority of a discovery message is greater than / less than the (pre-configured) priority of the discovery resource pool.

[0191] WTRUs can use a dedicated resource pool for sending discovery messages.

[0192] WTRUs can calculate the Comprehensive Reference Rate (CR) in a shared resource pool between discovery data and other data. For example, WTRUs can apply one or more of the following to the CR calculation: excluding discovery transmissions from the CR calculation, excluding discovery transmissions containing only discovery data from the CR calculation, etc. This technique can support prioritizing discovery transmissions in the resource pool.

[0193] WTRU can use the remaining PRB in the resource pool for discovery transmission. WTRU has N size N for resource pools with subchannel sizes PRB This can be configured (in advance). The WTRU uses the remaining PRB in the resource pool for sending discovery messages.

[0194]

number

[0195] WTRU can perform resource selection in the discovery resource pool. WTRU can perform resource selection in the discovery resource pool using one or more of the following methods (e.g., any combination): sensing-based resource allocation, random resource selection, etc.

[0196] A WTRU can perform resource reselection. For example, a WTRU can perform random resource selection based on its WTRU ID. A WTRU can determine the subchannel index and / or slot index of a discovery transmission, for example, as a function of its WTRU ID.

[0197] WTRUs can perform sensing-based resource selection. WTRUs can perform sensing-based resource selection in the discovery resource pool. WTRUs can determine the availability threshold for discovery transmissions using (for example, one) RSRP thresholds.

[0198] Features that may be associated with sending and / or receiving discovery messages (e.g., power-efficient discovery sending / receiving) are described herein. A WTRU can determine whether to send a discovery message. A WTRU can determine whether to send a message (e.g., a discovery message) based on one or more of the following: whether the WTRU (e.g., a remote WTRU, a source WTRU, or a destination WTRU) is connected to a relay, the load on the WTRU, the CR of the WTRU, the CBR of the resource pool (e.g., the CBR of the discovery resource pool and / or the CBR of the data resource pool), the priority of the discovery service and / or the priority of the TB with discovery data, the channel quality and / or status of an existing side link (e.g., the side link to which the WTRU is connected), the synchronization status of the WTRU, or the reception of a message from another node. Based on the decision, the WTRU can send a message (e.g., a discovery message).

[0199] A WTRU can determine whether to send a message (e.g., a discovery message) based on whether or not it is connected to a relay. A WTRU (e.g., a remote WTRU or a relay WTRU) can, for example, refrain from sending a discovery message (e.g., not send it) if the WTRU is already connected to a relay. For example, a WTRU may not be allowed to send a discovery message if it is already connected to a relay. In this example, this could be associated with restricting unnecessary discovery transmissions.

[0200] A WTRU can determine whether to send a message (e.g., a discovery message) based on its load. A WTRU (e.g., a relay WTRU) can be prevented from sending discovery messages (e.g., not allowed) based on its load. A WTRU may be allowed to send discovery messages if its load is below a threshold. If the load is above the threshold, the WTRU may be prevented from sending discovery messages (e.g., not allowed). The WTRU load threshold can be configured (in advance) with one or more other parameters (e.g., resource pool CBR, service QoS, etc.). The WTRU load can be determined based on one or any combination of the following: the WTRU's buffer status, such as the number of connected WTRUs, the number of links, and / or the number of established radio bearers; or the WTRU's CR, the amount of data being sent / received, and / or the amount of data expected to be sent / received.

[0201] The load on a WTRU can be determined based at least on the WTRU's buffer status. A WTRU may be prevented from sending discovery messages (e.g., not allowed to send them) if the total amount of data in its buffer is greater than a threshold, and may be allowed to send discovery messages (e.g., may send them) if the total amount of data in its buffer is less than a threshold. A WTRU may be prevented from sending discovery messages (e.g., not allowed to send them) if the amount of data in a set of LCGs / LCHs is greater than a threshold, and may be allowed to send discovery messages (e.g., may send them) if the amount of data in a set of LCGs / LCHs is less than a threshold. A set of LCGs / LCHs may be determined as a set of LCGs / LCHs with a higher priority than the priority of the discovery data.

[0202] A WTRU can determine whether to send a message (e.g., a discovery message) based on its CR (Critical Record). If the WTRU's CR is greater than a threshold, it may be prevented from sending a discovery message (e.g., not allowed to send it), and if the WTRU's CR is greater than a threshold, it may be allowed to send a discovery message (e.g., it may send it). The CR may be determined based on the WTRU's sending activity in, for example, a data resource pool and / or a discovery resource pool. In the example, this may be associated with managing discovery transmissions of WTRUs in a discovery resource pool. A WTRU may have a CR threshold configured in, for example, a data communication resource pool, to determine whether it can send a discovery message in the discovery resource pool. If the WTRU's CR in the data communication resource pool is less than a threshold, it may be allowed to send a discovery message. If the CR is greater than a threshold, the WTRU may be prevented from sending a discovery message in the discovery resource pool (e.g., not allowed to send it).

[0203] A WTRU can determine whether to send a message (e.g., a discovery message) based on its CR (Critical Record). A WTRU can, for example, stop sending discovery messages for a period of time and / or increase / decrease the frequency of discovery messages if it fails to find one or more WTRUs to connect to during the period for sending discovery messages. For example, a remote WTRU can send discovery messages (e.g., request messages) using, for example, Model B. A WTRU can periodically send discovery messages using a first transmission period (e.g., initially). A WTRU can increase the frequency of discovery message transmissions (e.g., after a certain duration threshold). The duration thresholds and / or transmission frequencies (e.g., first and / or second maximum / minimum transmission frequencies) for discovery messages can be configured, for example, per resource pool and / or per service. In an example, this could be associated with reducing power consumption due to discovery monitoring.

[0204] A WTRU can determine whether to send a message (e.g., a discovery message) based on the resource pool's CBR. For example, if the CBR of a resource pool (e.g., a data communication resource pool or a discovery message resource pool) is greater than a threshold, the WTRU may prevent the discovery message from being sent in the discovery resource pool or the data communication resource pool (e.g., it may not be allowed to send it) (and vice versa). Thresholds may be configured for each resource pool. In the example, this may be related to controlling congestion in the data or discovery resource pool. A WTRU can configure two resource pools: one for data transmission and the other for discovery transmission. The WTRU can configure a CBR threshold in the data resource pool such that if the CBR of the resource pool is greater than a threshold, the WTRU may prevent the discovery message from being sent in the discovery resource pool (e.g., it may not be allowed to send it) (and vice versa).

[0205] A WTRU can determine whether to send a message (e.g., a discovery message) based on the priority of the discovery TB. A WTRU can determine whether to send a discovery TB in a resource pool based on the priority of the TB. Discovery of a TB may be sent in a resource pool based on its priority, for example, if its priority is greater than / less than a threshold. Otherwise, the WTRU may prevent it from being sent in the resource pool (e.g., it may not be allowed to send it). Priority thresholds may be configured, for example, per CBR range and / or per resource pool.

[0206] The channel quality and / or status of a sidelink (e.g., an existing sidelink) may be used in relation to the TB. A WTRU can determine whether to send a discovery TB in the resource pool based on the channel quality and / or status of the current sidelink (e.g., the sidelink to which the WTRU is connected). If the channel quality of the current sidelink is below a threshold, the WTRU may decide to send a discovery message. Otherwise, the WTRU may be prevented from sending a discovery message (e.g., not allowed to send one). A remote WTRU may be allowed to send a discovery message to search for another relay if, for example, the measured RSRP on the sidelink with the current relay (e.g., the relay to which the WTRU is connected) is below a threshold (e.g., and vice versa). Thresholds may be configured (pre-configured) per resource pool and / or per relay service.

[0207] A WTRU can determine whether to send a message (e.g., a discovery message) based on its synchronization status. A WTRU can also determine whether to send a discovery TB based on its synchronization status. The WTRU's synchronization status may be determined based on one or both of the following: the availability of a synchronization source, the priority of a synchronization source, or whether the WTRU has sent a synchronization signal.

[0208] A remote WTRU may decide to find an inter-WTRU relay by sending a discovery message (e.g., one). A remote WTRU may be prevented from sending a discovery message (e.g., not permitted to send a discovery message) if it is not synchronized with the gNB and / or if the WTRU is directly synchronized with the gNB.

[0209] A WTRU can find inter-WTRU relays by sending discovery messages. A WTRU can choose not to send messages (e.g., not be allowed to send them) if it is not synchronized with any synchronization source (e.g., or vice versa). A WTRU can choose not to send discovery messages (e.g., not be allowed to send them) if the priority of the synchronization source is below a threshold (e.g., or vice versa).

[0210] A WTRU (e.g., a relay WTRU) may decide to send a discovery message if it has a synchronization source or has sent a synchronization message. In this example, this may be associated with enabling a remote WTRU to properly connect to the relay WTRU in synchronization with it.

[0211] A WTRU can determine whether to send a message (e.g., a discovery message) based on the reception of a message from another node. A WTRU can also determine whether to send a discovery message based on the reception of another message from another node (e.g., a discovery message from another WTRU). For example, in an inter-WTRU scenario, a relay WTRU can decide to send a discovery message if it receives a discovery message (e.g., a solicitation message) from a remote WTRU. In this example, this can be associated with reducing the discovery transmission overhead of the relay WTRU.

[0212] A WTRU can trigger and / or stop monitoring the discovery resource pool. A WTRU can trigger and / or stop monitoring the resource pool (e.g., the discovery resource pool) based on one or more of the following: whether the WTRU (e.g., remote WTRU, source WTRU, or destination WTRU) is connected to a relay, the load on the WTRU, the CR of the WTRU, the CBR of the resource pool (e.g., the CBR of the discovery resource pool and / or the CBR of the data resource pool), the priority of the discovery service and / or the priority of the TB with discovery data, the channel quality / status of the side links and / or Uu links, or the synchronization status of the WTRU. Monitoring the discovery resource pool may include one or more of the following: decoding the SCI to look for discovery messages about the WTRU itself and determine reserved resources, or measuring RSRP, RSSI, CBR, etc.

[0213] A WTRU can trigger and / or stop monitoring the discovery resource pool based on whether or not the WTRU is connected to a relay. A WTRU (e.g., a remote WTRU) can trigger or stop monitoring the discovery resource pool based on its sidelink connection status (e.g., current sidelink connection status). A WTRU can stop monitoring the discovery resource pool if, for example, it already has a connection to one relay. A WTRU can trigger monitoring the discovery resource pool if, for example, it does not have any connected relays.

[0214] A WTRU can trigger and / or stop monitoring a discovery resource pool based on its load. A WTRU (e.g., a relay WTRU) can trigger or stop monitoring a discovery resource pool based on its load. A WTRU can, for example, trigger monitoring a discovery resource pool if its load is below a threshold. A WTRU can, for example, stop monitoring a resource pool if its load is above another threshold. Other parameters (e.g., resource pool CBR, service QoS, etc.) can be (pre-configured) for the WTRU load threshold.

[0215] A WTRU can trigger and / or stop monitoring a discovery resource pool based on the resource pool's CBR. A WTRU can also trigger monitoring of discovery messages based on the resource pool's CBR. The CBR used to trigger monitoring of a discovery resource pool may be measured in the discovery resource pool (e.g., the current discovery resource pool) and / or associated data resource pools. A WTRU can, for example, trigger monitoring of a discovery resource pool if the CBR of the associated data communication resource pool is less than / greater than a threshold. Thresholds may be configured (pre-configured), for example, for each priority of resource pools and / or relay services.

[0216] WTRU may decide to stop monitoring a discovery resource pool based on the resource pool's CBR. The CBR used to stop monitoring a discovery resource pool may be measured in the discovery resource pool and / or associated data resource pools. For example, WTRU may stop monitoring a discovery resource pool if the CBR of the associated data communication resource pool is greater than a threshold. The threshold may be configured (in advance) for each priority of resource pools and / or relay services.

[0217] A WTRU can trigger and / or deactivate monitoring of the discovery resource pool based on the channel quality / status of an existing sidelink (e.g., the sidelink to which the WTRU is connected). A WTRU can trigger monitoring of discovery messages based on the channel quality / status of an existing sidelink and / or Uu link. A WTRU can trigger monitoring of the discovery resource pool, for example, if the channel quality / status of an existing sidelink meets predefined trigger conditions for the existing sidelink and / or Uu link. The trigger conditions may be one or more of the following: the RSRP of the existing sidelink and / or the RSRP of the Uu is below a threshold; the WTRU receives an instruction from a peer WTRU to terminate an ongoing connection; or the WTRU decides to terminate a sidelink connection (e.g., the current sidelink connection). In the example, this may be associated with reduced power consumption resulting from the monitoring of the discovery resource pool.

[0218] A WTRU can trigger and / or stop monitoring the discovery resource pool based on its synchronization status. For example, a WTRU can trigger monitoring the discovery resource pool if it synchronizes with a synchronization source. For example, a WTRU can stop monitoring the discovery resource pool if it loses synchronization. A WTRU can stop monitoring the discovery resource pool if one or more of the following occur: the WTRU is not synchronized with a global navigation satellite system (GNSS), the WTRU is not synchronized with a base station (e.g., a gNB), the WTRU does not detect a sidelink synchronization signal (SLSS) for a period of time, or the WTRU does not transmit an SLSS.

[0219] A WTRU can determine which resource pool to monitor based on its power saving state. A WTRU can be configured with one or more resource pools (in advance). Each resource pool can be associated with one or more power saving states. A WTRU can determine which resource pool to monitor based on its power saving state. A WTRU can switch the monitored resource pool when switching power saving states.

[0220] A WTRU can switch its power-saving state based on its receiving activity. For example, if a WTRU is not found for a certain period of time, such as if a relay and / or remote WTRU is not found, it may switch from a first power-saving state (e.g., a high-power consumption state) to a second power-saving state (e.g., a lower-power consumption state).

[0221] A WTRU can use resource pool monitoring time (e.g., via a timer) to determine, for example, the power saving state of resource pool monitoring. When a WTRU is monitoring a resource pool, it can track the duration (e.g., start a timer). When the duration expires (e.g., the timer expires), the WTRU can change the monitored resource pool. A WTRU can stop tracking the duration (e.g., stop the timer) if it finds a relay and / or remote WTRU. In an example, this could be associated with the WTRU helping to reduce power consumption resulting from resource pool monitoring.

[0222] Features related to platoon-based discovery may be disclosed herein. For example, users (e.g., users A and B) may belong to a platoon and may wish to communicate with each other, for example, via the platoon's relays.

[0223] A WTRU can include IDs associated with a group in its discovery message. A WTRU (e.g., source WTRU, destination WTRU) can include one or more of the following IDs in its discovery message to facilitate discovery: IDs associated with a platoon, IDs of target WTRUs (e.g., target member IDs in a platoon), IDs of source WTRUs (e.g., source member IDs in a platoon), or a set of possible relay WTRU IDs.

[0224] A WTRU can include its source and / or destination ID in its discovery message. The WTRU ID can be obtained, for example, from one or more messages sent from the source and / or destination WTRU (e.g., discovery messages). A WTRU can include its WTRU ID in its discovery message, for example, if it decides to act as a relay for another WTRU.

[0225] A WTRU may include sidelink measurements associated with a WTRU ID. A WTRU (e.g., a relay WTRU) may include one or more sidelink measurements (e.g., SL RSRP), each of which may be associated with one source / destination WTRU included in the discovery message. A WTRU may include a source / destination ID based on the SL RSRP of the corresponding sidelink (e.g., a WTRU may include a WTRU ID in the discovery message if the SL RSRP of the corresponding sidelink is greater than a threshold, which may be configured (in advance), for example, per relay service and / or per resource pool), or based on one or more of the QoS of the requested relay service.

[0226] A relay WTRU can determine whether to forward a discovery message. A relay WTRU can determine whether to forward a discovery message based on the sidelink quality between itself and the target WTRU. Sidelink quality can be determined based on the RSRP of data communication between itself and the target WTRU. A relay WTRU can also determine whether to forward a discovery message based on a set of IDs included in the discovery message. For example, if the WTRU ID belongs to the set of IDs included in the discovery message, the WTRU can forward the discovery message. Otherwise, the WTRU may choose not to forward the discovery message.

[0227] A WTRU can select discovery types and / or resource pools. A WTRU can be configured with one or more discovery types (pre-configured). One or more of these discovery types (e.g., each discovery type) may be associated with one or a combination of the following parameters / configurations: discovery packet size, multiplexing behavior, resource transmission type (e.g., aperiodic, semi-persistent, or periodic transmission), bandwidth (e.g., the number of subchannels used for discovery transmission), MCS, transmission power (e.g., whether power boosting is used and / or which power level is used), priority level, discovery model (e.g., discovery model A, discovery model B, etc.), or LCH for use for discovery messages.

[0228] Regarding discovery packet size, a WTRU can (pre)configure multiple discovery message sizes, and one or more of these message sizes (e.g., each message size) can be associated with each discovery type. Regarding multiplexing behavior, the first discovery type may allow multiplexing with other data, while the second discovery type may not. Regarding transmit power, the first discovery type (e.g., discovery message type) may use low transmit power, while the second discovery type may use high transmit power. Regarding priority levels, (e.g., each) discovery message type may be assigned different priority levels for Tx and Rx. In an example (e.g., for LCP, UL / SL prioritization, transmission in SCI, or other functions), priority may be assigned to transmission.

[0229] A WTRU can select a discovery type (e.g., discovery message type). The WTRU can select a discovery message type based on one or more of the following: the resource pool used or determined for discovery transmission; the QoS requirements of the relay service (e.g., related to the discovery message or data transmitted via the relay); coverage information and / or Uu measurements of cells within the coverage of the WTRU; scheduling mode (e.g., mode 1 or mode 2); WTRU type (e.g., including specific characteristics of the WTRU or WTRU capability); the need to find a relay (e.g., a new relay) (e.g., urgency or importance); whether the WTRU is already connected to the relay (e.g., whether the discovery is for selection or re-selection); whether the discovery message can include additional AS information (e.g., system information); or whether the discovery message can be based on the type of AS layer information that may be included with the discovery message.

[0230] With regard to selecting discovery message types based on resource pools, a WTRU can (pre-configure) one or more resource pools. Each configured resource pool can be associated with one or more discovery types. The WTRU can determine which discovery types to send based on the resource pool used or determined for discovery transmission / reception. For example, a WTRU may (pre-configure) two resource pools and two message types. A first resource pool may be associated with a first discovery type that may allow multiplexing with data. A second resource pool may be associated with a second discovery type that may not allow multiplexing with data.

[0231] Regarding the selection of discovery message types based on the QoS requirements of a relay service, a WTRU may use a first discovery type for high-QoS requirement services (e.g., with high transmit power and / or high transmit / receive priority). A WTRU may use a second discovery type for low-QoS requirement services (e.g., with low transmit power and / or low transmit / receive priority). A WTRU can configure a specific discovery type to be used for a given L2 destination ID associated with a discovery message (e.g., a given L2 destination ID can be associated with type 1 and / or type 2). QoS requirements may be determined based on the bearer configuration and / or the priority of the relayed bearer or channel. For example, a WTRU may select a discovery type if the LCH of the relayed WTRU has a priority above a threshold (e.g., a configured threshold) or if the configuration for the LCH specifies the use of a particular discovery type.

[0232] Regarding the selection of a discovery message type by a WTRU based on coverage information or Uu measurement values ​​of cells within its coverage, the WTRU may use a first discovery type if it is within network coverage, and a second discovery type if it is outside network coverage.

[0233] With regard to selecting the discovery message type based on the scheduling mode (e.g., mode 1 or mode 2), a WTRU (which may be, for example, a relay WTRU) may use a first discovery type if the discovery resource transmission is scheduled by the network, or a second discovery type if the discovery resource transmission is selected by the WTRU.

[0234] With regard to selecting discovery message types based on WTRU type (e.g., including specific characteristics or capabilities of the WTRU), WTRU types can include relay WTRU, remote WTRU, WTRU-to-network (U2N) relay / remote WTRU, WTRU-to-WTRU (U2U) relay / remote WTRU, pedestrian WTRU or VUE, low-power WTRU, or non-low-power WTRU. WTRU capabilities can include whether the WTRU can transmit discovery type 1 or discovery type 2. In the example, a WTRU configured as a relay WTRU can transmit type 1 discovery, and a WTRU configured as a remote WTRU can transmit type 2 discovery. In the example, a WTRU configured to be type 2 compliant can transmit type 2 discovery.

[0235] Regarding the selection of discovery message types based on the need to find the relay (e.g., urgency or importance), a remote WTRU may use a discovery type if it triggers a discovery transmission as a result of being unable to communicate with its connected relay (e.g., if SL RSRP is below a pre-configured threshold, or if SL RLF is triggered).

[0236] A WTRU can select one or more resource pools for discovery transmissions. A WTRU can (pre-configure) one or more resource pools for discovery transmissions. A WTRU can (pre-configure) one or more shared resource pools for data transmissions and / or one or more dedicated resource pools for discovery transmissions (e.g., for discovery transmissions only). A WTRU can determine which resource pool to use for sending discovery messages based on one or any combination of the following:

[0237] A WTRU can determine which resource pool to use for discovery transmissions based on the CBR associated with the resource pool. For example, a WTRU may be pre-configured to use a resource pool for discovery transmissions (e.g., always) if the CBR associated with the resource pool is below a threshold (e.g., which may be configured). If the CBR associated with a resource pool is greater than the threshold, the WTRU may do one or more of the following: The WTRU may switch to a different resource pool. The WTRU may report the CBR associated with the resource pool to the network and / or implicitly / explicitly request a different resource pool configuration for discovery transmissions. The WTRU may trigger an SR and / or SL-BSR to report the availability of discovery transmissions.

[0238] A WTRU may, for example, use a dedicated resource pool for discovery transmissions if the CBR associated with the resource pool is below a threshold. A WTRU may switch to a dedicated resource pool if the CBR associated with the dedicated resource pool is above a threshold. A WTRU may use a dedicated resource pool for discovery transmissions if the CBR associated with the resource pool is below a threshold. A WTRU may, for example, trigger an SR and / or BSR to report the availability of discovery transmissions if the CBR associated with the dedicated resource pool is above a threshold. One or more of the thresholds described herein may be established (e.g., by the network or a higher layer, such as via RRC signaling).

[0239] The WTRU can determine which resource pool to use for discovery transmissions based on the type of discovery transmission (e.g., the discovery types described herein) and / or the frequency of discovery traffic. For example, the WTRU may select a first resource pool for semi-persistent discovery transmissions and a second resource pool for dynamic and / or semi-persistent discovery transmissions. The UE may select a dedicated resource pool for semi-persistent transmissions and a shared resource pool for dynamic discovery transmissions, or vice versa.

[0240] A WTRU may, for example, allow the reservation of one or more periodic resources in a resource pool (e.g., a dedicated resource pool) if the resource's period is greater than a threshold (e.g., a pre-configured threshold). The WTRU may then decide whether to perform resource selection in the dedicated resource pool (e.g., based on the arrival of discovery data) or to wait for the reserved resources in the dedicated resource pool.

[0241] A WTRU can determine which resource pool to use for discovery transmission based on the availability of relays at remote WTRUs. For example, a WTRU may select a dedicated resource pool for relay selection and a shared resource pool for relay re-selection. A WTRU can send discovery messages in a dedicated resource pool if, for example, it does not have relays. A WTRU can send discovery messages in a shared resource pool if, for example, it is connected to relays.

[0242] A WTRU can determine which resource pool to use for discovery transmission based on the QoS of the relay service and / or the QoS of the discovery message. For example, a WTRU transmitting and / or relaying data through an LCH with a specific priority may choose a dedicated resource pool rather than a shared resource pool.

[0243] A WTRU can determine which resource pool to use for discovery transmission based on its Critical Risk (CR). For example, a WTRU can (pre-configure) one or more CR thresholds to determine whether it should send discovery messages in dedicated and / or shared resource pools. The CR thresholds may be a function of the priority of the discovery message. The CR thresholds may (pre-configure) for one or more resource pools (e.g., per resource pool). For example, if the CR measured in the WTRU's dedicated resource pool is greater than the CR threshold, the WTRU can send discovery messages in a different resource pool (e.g., a shared resource pool). If the CR measured in the WTRU's dedicated resource pool is less than or equal to the CR threshold, the WTRU can send discovery messages in the dedicated resource pool. If the CR measured in the shared resource pool is less than the CR threshold, the WTRU can send discovery messages in the shared resource pool. If the CR measured in the shared resource pool is greater than or equal to the CR threshold, the WTRU can send discovery messages in the dedicated resource pool.

[0244] A WTRU can determine which resource pool to use for discovery transmissions based on its load (e.g., data load). For example, a WTRU can send discovery messages in a dedicated resource pool, or it can request resources for discovery transmissions if its load is above a threshold. The WTRU load can be associated with the amount of pending data being relayed. The WTRU load can be determined as the amount of data (e.g., being relayed) with a priority higher than a priority threshold. The priority threshold can be a function of the priority of the discovery messages.

[0245] A WTRU can determine which resource pool to use for discovery transmission based on the subchannel size of the resource pool. A WTRU can (pre-configure) resource pools (e.g., multiple resource pools) for sending discovery messages. For example, a WTRU can determine which resource pool will send the discovery message based on the subchannel size of the resource pool. A WTRU can select a resource pool (e.g., the one with the smallest subchannel size) from a set of resource pools (pre-configured) for discovery transmission. For example, a WTRU can select a resource pool if its subchannel size is smaller than a threshold.

[0246] The WTRU can determine which resource pool to use for discovery transmissions based on whether a physical sidelink feedback channel (PSFCH) is (pre-configured) in the resource pool. The WTRU can prioritize resource pools (for example, if PSFCH transmissions are not configured). If PSFCH transmissions are configured in all resource pools, the WTRU can prioritize the resource pool with the best PSFCH transmission duration.

[0247] The WTRU can determine which resource pool to use for discovery transmissions based on the carriers (pre-configured) for sidelink data transmissions and carriers (pre-configured) for discovery transmissions. The WTRU may prioritize resource pools within the same carrier as the resource pools (pre-configured) for sidelink data transmissions.

[0248] A WTRU can determine which resource pool to use for discovery transmissions based on the configuration information it receives. For example, if a WTRU receives configuration information (e.g., via RRC signaling), it can preferentially use that resource pool for discovery transmissions. If a WTRU receives configuration information from an SIB, or if a resource pool is (pre-configured), the WTRU can choose not to prioritize such a resource pool (e.g., not to prioritize it). A WTRU can also determine which resource pool to use for discovery transmissions using other criteria (e.g., based on the resource pool's CBR).

[0249] WTRU can determine which resource pool to use for discovery transmission based on whether semi-persistent reservations are disabled / enabled in the resource pool. In the example, WTRU can prioritize resource pools where semi-persistent reservations are enabled.

[0250] A WTRU can perform discovery transmissions across multiple resource pools (e.g., both shared and dedicated resource pools). A WTRU may be pre-configured to prioritize one resource pool (e.g., a dedicated resource pool) if the resource pool's CBR is below a threshold. The WTRU can then transmit the discovery across another resource pool if the preferred resource pool's CBR is above a pre-configured threshold. This technique can increase the probability that discovery messages reach their intended receivers in congested scenarios.

[0251] Discovery extension, relay reselection, and / or cell reselection may be performed. The WTRU may, for example, determine whether to transmit sidelink data based on discovery transmit / receive. In the example, the WTRU may be configured (e.g., pre-configured) to prioritize discovery transmit / receive. In the example, the WTRU may be configured (e.g., pre-configured) to stop transmitting priority and / or service data (e.g., Uu and / or SL) if discovery transmit / receive takes priority. For example, the WTRU may be configured (e.g., pre-configured) to have priority thresholds. If the WTRU needs to transmit / receive discovery data, the WTRU may refrain from transmitting data whose priority is lower than the priority threshold. In the example, the WTRU may, for example, reduce the number of (re)transmissions for sidelink TB if the WTRU decides to prioritize discovery transmit / receive. In the example, the WTRU may prioritize sidelink discovery transmits over Uu transmits. The WTRU may be configured with LCH to determine whether to prioritize UL transmits over SL discovery transmits. For example, a WTRU may apply such thresholds if it determines that it needs to perform discovery transmit / receive. A WTRU may determine whether to perform discovery transmit / receive based on one or any combination of the following events: the WTRU receiving an RLF instruction from a relay WTRU, the WTRU triggering an RLF (e.g., SL RLF and / or Uu RLF), and / or the WTRU receiving an instruction from the network (e.g., in dedicated RRC signaling).

[0252] WTRU can perform congestion control for discovery data. For example, WTRU can be configured (e.g., pre-configured) with two or more sets of congestion control parameters, which may include one or any combination of the following parameters: transmit power (e.g., maximum transmit power), MCS (e.g., maximum and minimum MCS), number of retransmissions for TB (e.g., maximum number), and / or number of subchannels used for a single transmission (e.g., maximum number).

[0253] A WTRU may have one set of parameters configured (e.g., pre-configured) for data transmissions (e.g., normal data transmissions), and another set of parameters may be used for discovery transmissions. A WTRU may have a set of parameters configured (e.g., pre-configured) for each range of CBRs and / or CRs in the resource pool. A WTRU can determine which set of parameters to use based on whether the transmission is associated with a data transmission or a discovery transmission. If the transmission contains data from logical channels associated only with data (e.g., not LCHs associated with discovery), for example, Tx WTRU can use the first set of congestion control parameters associated with data. If the transmission contains data from logical channels associated only with discovery (e.g., not LCHs associated with data), for example, Tx WTRU can use the second set of congestion control parameters associated with discovery. Tx WTRU can use the first set of parameters, or, for example, the second set of parameters if the transmission contains both discovery and data.

[0254] A WTRU can determine which resource pool to send discovery data to. A WTRU can be configured with multiple resource pools to which it can send discovery data. For example, a WTRU can be configured with a resource pool dedicated to sending discovery data, and another resource pool that can enable both data transmission and discovery transmission. A WTRU can establish rules (e.g., specific rules) regarding which pool should be used. A WTRU can determine which pool or pool type may be used to send discovery based on, for example, the resource pool's CBR, the WTRU's CR within the resource pool, the TB's QoS, the WTRU's load, and / or the expected transmit power of the discovery message.

[0255] A WTRU can determine, for example, which pool or pool type may be used to send a discovery based on the resource pool's CBR. For example, a WTRU can be configured (e.g., pre-configured) with a CBR threshold that enables discovery transmission within a pool. If the CBR is less than the threshold, the WTRU can send a discovery in the resource pool. Otherwise, the WTRU may choose not to send a discovery in the resource pool. In this case, the WTRU can send a discovery in a dedicated discovery resource pool or in a pool where no such CBR threshold is configured.

[0256] A WTRU can determine, for example, which pool or pool type may be used to send a discovery based on the CR of the WTRU in the resource pool. For example, a WTRU can have a CR threshold configured (e.g., pre-configured) and associate the CR threshold with the CR of the WTRU in that resource pool. If the CR is less than the threshold, the WTRU can send a discovery in the resource pool. Otherwise, the WTRU may choose not to send a discovery in the resource pool. In this case, the WTRU can send a discovery in a dedicated resource pool or a pool where such a CR threshold is not configured.

[0257] A WTRU can determine, for example, which pool or pool type may be used to send a discovery based on the QoS of the TB. For example, a WTRU can be configured with priority thresholds (e.g., pre-configured). A WTRU may be allowed to send a discovery in a resource pool if, for example, the priority of the TB or discovery message is greater than the threshold. Otherwise, the WTRU may choose not to send the discovery in the resource pool and instead send it in a dedicated pool (e.g., where it needs to be sent).

[0258] A WTRU can determine, for example, which pool or pool type may be used to send a discovery based on the WTRU's load. For example, a WTRU can configure (e.g., pre-configure) load thresholds in resource pools. A WTRU can determine, for example, whether to send a discovery in a resource pool based on the WTRU's load. A WTRU can send a discovery in a resource pool if, for example, the load is below the threshold. Otherwise, the WTRU may choose not to send a discovery in the resource pool. A WTRU can measure its load based, for example, the amount of data in the WTRU's buffer, the average / expected data rates in transmit / receive / relay, the number of unicast links and / or remote WTRUs being served, or similar criteria associated with measuring the load in the WTRU.

[0259] The WTRU can determine, for example, which pool or pool type may be used to transmit the discovery based on the expected transmit power of the discovery message. The WTRU can configure (e.g., pre-configure) the transmit power thresholds for the discovery, such as the maximum and / or minimum transmit power thresholds for the discovery. The WTRU can further determine the maximum / minimum power based, for example, on open-loop or closed-loop power control formulas. The WTRU can determine the expected / required transmit power associated with the discovery transmission. For example, if the transmit power of the discovery is less than the maximum power threshold and / or greater than the minimum transmit power threshold, the WTRU can transmit the discovery in the resource pool. Otherwise, the WTRU may choose not to transmit the discovery in the resource pool.

[0260] A WTRU can switch discovery transmissions to a different resource pool. For example, a WTRU can be configured (e.g., pre-configured) to send discoveries to two or more resource pools (e.g., a normal resource pool and an exceptional resource pool). A WTRU can be configured (e.g., pre-configured) to send discoveries to a default resource pool (e.g., a normal resource pool). A WTRU can send discoveries to the default resource pool if, for example, the discovery transmission meets configured (e.g., pre-configured) conditions. A WTRU can switch to a different resource pool (e.g., an exceptional resource pool) if, for example, one or more configured conditions are not met, and / or in the event of a specific event. The conditions configured for sending discovery in the default resource pool may be one or any combination of the following: the default resource pool's CBR and / or WTRU's CR is less than a threshold; the TB's QoS is within range (e.g., the TB's priority is less than a threshold); the TB's transmission is within power range (e.g., the TB's transmission power is less than a threshold and / or greater than another threshold); and / or the WTRU's load is less than a threshold.

[0261] A WTRU may send a discovery in a resource pool (e.g., an exception resource pool) based on the occurrence of one or more events. One or more events may include, for example, the WTRU discovering an RLF (e.g., Uu RLF and / or SL RLF), the WTRU having a discovery message available for transmission with a certain priority (e.g., a priority above a threshold), the WTRU triggering a cell reselection, and / or a determination that a duration has expired (e.g., timer expiration). A duration (e.g., timer) may be initiated based on the occurrence of any of the other events referred to herein.

[0262] A WTRU can send a discovery in a resource pool (e.g., an exceptional resource pool) based on triggering a cell reselection. A WTRU can be configured with conditions that can trigger the sending of a discovery on other pools based on, for example, a cell reselection, the state of the WTRU (e.g., the WTRU is RRC_CONNECTED / RRC_INACTIVE), the priority of pending transmissions (e.g., the WTRU is configured with an LCH that has a priority above a threshold), and / or the failure of a mobility event (e.g., a direct-to-indirect or reverse HO or NW control switch).

[0263] A WTRU can indicate the transmit power of a discovery message. A WTRU can indicate one or any combination of the following information regarding the transmit power of a discovery message: absolute transmit power, information about resource pool path loss (e.g., DL path loss) or CBR, power level (e.g., low, medium, or high transmit power), and / or power reduction level (e.g., low, medium, or high transmit reduction due to CBR and / or DL ​​path loss). For example, a Tx WTRU may include an indication in its transmission when its transmit power is reduced due to congestion control. A Tx WTRU may include an indication of the amount of power reduction associated with congestion control. Transmit power information may be indicated, for example, using signaling by SCI or MAC CE.

[0264] A WTRU can perform RSRP measurements based on, for example, a transmit power indication from a Tx WTRU. A WTRU (e.g., a remote WTRU) can determine the sidelink quality associated with discovery transmissions based on, for example, the measured sidelink discovery (SD)-RSRP and the transmit power indication from a Tx WTRU. Sidelink quality can be a function of SD-RSRP and transmit power indication parameters. For example, if low transmit power is indicated, sidelink quality can be determined by subtracting a delta (e.g., some (pre-configured) quantity) from the measured SD-RSRP (e.g., sidelink quality = SD-RSRP - delta). The delta can be determined by, for example, additional information in the transmit power indication by the Tx WTRU. For example, the Tx WTRU can send a coefficient that can be used by the Rx WTRU to determine a multiplier to increase the value of delta. Whether high transmit power is transmitted can be determined by, for example, adding the delta to the measured SD-RSRP (e.g., sidelink quality = SD-RSRP - delta). Sidelink quality can be determined, for example, as the measured SD-RSRP when medium transmit power is transmitted. The delta value can be configured (e.g., pre-configured) in the resource pool.

[0265] A WTRU can determine RSRP thresholds and perform relay (re)selection. A WTRU can use RSRP thresholds (e.g., SD-RSRP threshold, SL-RSRP threshold, or Uu RSRP threshold) to perform relay (re)selection procedures, for example. For instance, a WTRU can trigger relay (re)selection if the current relay's SD-RSRP and / or SL-RSRP are below a threshold. A WTRU can use RSRP thresholds to trigger discovery transmit / receive procedures, for example. For instance, a WTRU can trigger discovery transmit / receive based on whether Uu RSRP is above and / or below a (pre-configured) threshold. A WTRU can use RSRP thresholds to trigger relay (re)selection procedures and discovery transmit / receive procedures in combination, for example.

[0266] Any of the above RSRP thresholds (e.g., SD-RSRP threshold, SL-RSRP threshold, Uu RSRP threshold) may be determined based on one or any combination of the following: whether a transmit power instruction in the discovery message, resource pool CBR, relay service QoS, RLF is triggered, or whether duration related to RLF or similar failures is being tracked (e.g., a timer is running), whether a WTRU is tracking duration (e.g., whether a timer is running in the WTRU, whether a specific timer is running in the WTRU), and / or the Uu state of a remote WTRU.

[0267] The RSRP threshold can be determined based on the transmit power indication in the discovery message. In the example, a WTRU may have one RSRP threshold configured (e.g., pre-configured). The WTRU can then determine the RSRP threshold (e.g., the actual RSRP threshold) for performing relay (re)selection based on, for example, the indicated transmit power in the message. For example, the WTRU may decrease the RSRP threshold if the indicated transmit power is low. The WTRU may increase the RSRP threshold if the indicated transmit power in the message is high. The WTRU may retain the configured (e.g., pre-configured) RSRP threshold (e.g., the initially configured (e.g., pre-configured) RSRP threshold) if the indicated transmit power is moderate. In the example, a WTRU may have multiple RSRP thresholds configured (e.g., pre-configured), and each threshold can be associated with one or more transmit power or transmit power indication types by the Tx WTRU. The WTRU can determine which RSRP threshold to use based on, for example, the indicated transmit power in the message.

[0268] RSRP thresholds can be determined based on the resource pool's CBR. In the example, a WTRU can have multiple RSRP thresholds configured (e.g., pre-configured). For example, thresholds can be associated with a CBR range. A WTRU can determine which RSRP threshold to use based on the resource pool's CBR. The resource pool's CBR can be measured by a WTRU or indicated by another WTRU. In the example, a WTRU can have RSRP thresholds configured (e.g., pre-configured). A WTRU can determine the RSRP threshold (e.g., the actual RSRP threshold) for performing relay (re)selection based on the resource pool's CBR. If the resource pool's CBR is high, a WTRU can increase the RSRP threshold. If the resource pool's CBR is low, the actual RSRP threshold may be the same as the configured (e.g., pre-configured) RSRP threshold, or the actual RSRP threshold may be determined by decreasing the configured (e.g., pre-configured) RSRP threshold.

[0269] RSRP thresholds can be determined based on the QoS of the relay service. For example, a WTRU can determine an RSRP threshold based on the LCH priority for the relay service (e.g., maximum expected priority). A WTRU can configure (e.g., pre-configure) multiple RSRP thresholds. RSRP thresholds can be associated with the relay service priority (e.g., maximum expected priority). A WTRU can determine which RSRP threshold to use based, for example, the minimum expected priority of the relay service that the WTRU expects.

[0270] RSRP thresholds can be determined based on whether an RLF is triggered or whether the duration associated with an RLF or similar fault is being tracked (e.g., a timer is running). A WTRU can determine the RSRP threshold for sending relay (re)selection and / or discovery messages based, for example, on whether an RLF is triggered for the current relay. In the example, a WTRU can configure (e.g., pre-configure) two RSRP thresholds, one to use when an RLF is not triggered and the other to use when an RLF is triggered. The WTRU can then determine which RSRP threshold to use based, for example, whether an RLF is triggered.

[0271] The RSRP threshold may be determined based on whether the WTRU is tracking duration (e.g., whether a timer is running in the WTRU, or whether a specific timer is running in the WTRU). Duration may be associated with a Uu connection. For example, if the duration is not tracked (e.g., no timer is running), the WTRU may send a discovery message based on a first RSRP threshold (e.g., if the Uu RSRP exceeds the threshold, the WTRU is allowed to send a discovery), and if the duration is tracked (e.g., a timer is running), it may send a discovery message based on a second RSRP threshold. Duration may be related to RLF, re-establishment, or similar fault handling (e.g., timers related to RLF, re-establishment, or similar fault handling, such as T310, T311, T301, etc.).

[0272] RSRP thresholds can be determined based on the Uu state of the remote WTRU. For example, a WTRU can use a first threshold for RRC_CONNECTED, a second threshold for RRC_INACTIVE, and a third threshold for RRC_IDLE.

[0273] A WTRU may decide to (re)select (e.g., select or re-select) an L2 or L3 relay. For example, a WTRU may determine whether to (re)select an L2 or an L3 relay based on, for example, the availability of an L2 or L3 relay, the WTRU's current relay (e.g., the relay to which the WTRU is connected), the WTRU's RRC status, and / or one or any combination of the QoS of the service.

[0274] The WTRU can determine whether to (re)select an L2 or an L3 relay based, for example, on the availability of an L2 or L3 relay. For example, the WTRU may be configured (e.g., pre-configured) to preferentially select one type of relay (e.g., either an L2 or L3 relay). The WTRU may select (e.g., always select) a configured (e.g., pre-configured) preferred relay type if, for example, at least one relay belonging to the relay type is available and at least one relay satisfies other relay (re)selection criteria (e.g., sidelink RSRP is greater than a threshold, relay load is less than a threshold, etc.). If there are no available relays for the configured (e.g., pre-configured) relay type, the WTRU may select a different relay type. For example, the WTRU may be configured (e.g., pre-configured) to select an L2 relay. The WTRU may select an L2 relay if, for example, an L2 relay is available and the L2 relay satisfies the relay (re)selection criteria. If no L2 relay that meets the relay (re)selection criteria exists, the WTRU may select an L3 relay.

[0275] The WTRU can determine, for example, whether to (re)select an L2 or an L3 relay based on the WTRU's current relay (e.g., the relay to which the WTRU is connected). For example, the WTRU can determine which relay type (e.g., L2 or L3 relay) to select based on the current relay to which the WTRU is connected. For example, if the WTRU is connected to an L2 relay, the WTRU may prioritize (re)selecting a different L2 relay. If the WTRU is connected to an L3 relay, the WTRU may prioritize (re)selecting a different L3 relay.

[0276] A WTRU can determine, for example, whether to (re)select an L2 or an L3 relay based on its RRC status. A WTRU can also determine which relay type to re-select based on its own RRC status. For example, if a WTRU is in an RRC connected state, it can select the same relay type as the current relay. A WTRU can prioritize (re)selecting an L2 relay if it is in an RRC idle / inactive state.

[0277] A WTRU can determine, for example, whether to (re)select an L2 or L3 relay based on the QoS of the service. A WTRU can determine, for example, which relay type to select based on the QoS of the service. For example, a WTRU can prioritize L2 relays for services with high QoS requirements (e.g., services with high-priority data). A WTRU can prioritize L3 relays, or, for example, a WTRU can choose not to prioritize a relay type if the QoS requirements of the service are low.

[0278] A WTRU can determine the procedure for receiving configuration information about a relay service. A WTRU (e.g., a relay) can decide to receive configuration information related to a relay service, for example, based on whether the WTRU is an L2 relay or an L3 relay. The configuration information may include one or any combination of resource pools for discovery, SLRB configurations, Uu RSRP thresholds, and / or SL RSRP thresholds for relay (re)selection.

[0279] For example, a WTRU operating as an L2 relay can receive configuration information via signaling (e.g., dedicated RRC signaling) if the WTRU is in RRC connection mode. A WTRU operating as an L3 relay can receive configuration information from a System Information Block (SIB) or (pre-)configuration, for example, even if the WTRU is in RRC connection mode.

[0280] A WTRU can determine whether to operate as an L2 relay or an L3 relay based on instructions from network nodes such as a gNB. For example, a WTRU can determine whether to operate as an L2 relay or an L3 relay based on a gNB response or instruction, for example, in response to a request from a relay WTRU. For example, a WTRU can request a gNB to operate as a relay or request relay resources from a gNB. A WTRU can determine whether to operate as an L2 or an L3 relay based on instructions from the network.

[0281] A WTRU can determine whether to select an L2 relay or an L3 relay based on instructions from a network node such as a gNB. For example, a WTRU can determine whether to select an L2 relay or an L3 relay based on instructions for discovery resources from the network (e.g., a gNB). For example, a WTRU can send a request for discovery resources. A WTRU can determine whether to select an L2 relay or an L3 relay based on instructions from the network.

[0282] A WTRU can send an RLF instruction to a remote WTRU. A WTRU (e.g., a relay WTRU) may decide to send an RLF instruction (for example, to indicate an RLF or to indicate PC5 link release) based on one or any combination of the following events: namely, the WTRU detecting an RLF (Uu RLF or sidelink RLF) in the relay WTRU, and / or the WTRU deciding to release a connection with one or more remote WTRUs.

[0283] To send an RLF instruction, the WTRU may use one or any combination of the following messages: Non-Access Layer (NAS) message instructions (e.g., PC5-S message instructions) or AS message instructions (e.g., PC5 RRC message, MAC CE signaling, SCI).

[0284] A WTRU can determine whether to send NAS message instructions and / or AS message instructions based on either the QoS of the relay service or whether there is a connected remote WTRU, or any combination thereof.

[0285] A WTRU can determine whether to send NAS message instructions and / or AS message instructions based on the QoS of the relay service. For example, a WTRU can send an AS message instruction for high-QoS requirement relay services. A WTRU can send a NAS message instruction for low-QoS requirement relay services.

[0286] A WTRU can determine whether to send NAS message instructions and / or AS message instructions based on whether there is a connected remote WTRU. For example, if there is a connected remote WTRU, the WTRU can send an AS message instruction. Otherwise, the WTRU can send a NAS message instruction (for example, if there is no connected remote WTRU).

[0287] A WTRU can determine whether to perform cell (re)selection first or relay (re)selection first. A WTRU can be configured to perform cell (re)selection and / or relay (re)selection. A WTRU can have rules configured, for example, regarding whether to perform cell (re)selection. A WTRU can have rules configured, for example, regarding whether to perform relay (re)selection. If a WTRU is configured to perform both cell and relay (re)selection, the WTRU can have criteria configured regarding which to perform first. A WTRU can determine whether to perform cell (re)selection and / or relay (re)selection, and / or which to perform first, based on one or any combination of the following: (pre)configuration, the WTRU's coverage status with respect to the current relay WTRU's network (e.g., gNB), measured Uu RSRP and / or SD-RSRP, events that trigger cell (re)selection and / or relay (re)selection, connectivity of remote WTRUs, and / or the RRC status of remote WTRUs.

[0288] The WTRU can determine whether to perform cell (re)selection and / or relay (re)selection based on a (pre)configuration. The WTRU can determine the order in which to perform cell (re)selection and relay (re)selection based on a (pre)configuration. For example, the WTRU can be configured (e.g., preconfigured) to perform cell (re)selection first (e.g., always perform cell (re)selection first). For example, the WTRU can be configured (e.g., preconfigured) to perform relay (re)selection first (e.g., always perform relay (re)selection first).

[0289] The WTRU can determine whether to perform cell (re)selection, relay (re)selection, and / or which to perform first based on the coverage status of the WTRU with respect to the network of the current relay WTRU (e.g., gNB). For example, if the WTRU is outside the coverage of the serving cell of the current relay WTRU (e.g., the relay WTRU to which the WTRU is connected), the WTRU can perform relay (re)selection first. The WTRU can, for example, (re)select a relay WTRU having the same cell ID as the current relay (e.g., the relay to which the WTRU is connected). If the WTRU is within the coverage of the serving cell of the current relay WTRU, the WTRU can perform cell (re)selection first. Then, the WTRU can switch to the Uu link with the same cell ID. In this case, the WTRU may be permitted to camp on the same cell.

[0290] The WTRU can first determine whether to perform relay (re)selection or cell (re)selection based on the measured Uu RSRP and / or the measured SD-RSRP. In an example, the WTRU can first perform relay (re)selection, for example, if the measured SD-RSRP of the relay is greater than a threshold value. The threshold value can be (pre-)configured. In an example, the WTRU can first perform cell (re)selection if the Uu RSRP of the measured cell is greater than a configured (e.g., pre-configured) threshold value. If the SD-RSRP is greater than a configured (e.g., pre-configured) threshold value and the Uu RSRP is greater than another configured (e.g., pre-configured) threshold value, the WTRU can first perform relay (re)selection.

[0291] The WTRU can determine whether to perform cell (re)selection, relay (re)selection, and / or which one to perform first based on events that trigger cell (re)selection and / or relay (re)selection. For example, the WTRU can first perform relay (re)selection when relay (re)selection is triggered due to a sidelink RLF event with the current relay (e.g., the relay to which the WTRU is connected). The WTRU can first trigger cell (re)selection, for example, when the relay WTRU releases the link due to a congestion control event.

[0292] The WTRU can determine whether to perform cell (re)selection, relay (re)selection, and / or which one to perform first based on the connection of the remote WTRU. For example, the WTRU can first perform relay reselection if it is connected via a relay WTRU, and can first perform cell reselection if it is directly connected via Uu.

[0293] The WTRU can determine whether to perform cell (re)selection, relay (re)selection, and / or which to perform first, based on the RRC status of the remote UE. For example, if it is RRC_CONNECTED, the WTRU can perform cell reselection first; otherwise, it can perform relay reselection first.

[0294] The above combinations can be used to determine whether to perform cell (re)selection or relay (re)selection, and / or which to perform first. For example, WTRU may perform relay reselection first if multiple conditions are met, or if any of a set of conditions are met. For example, WTRU may use one condition to determine whether to perform a certain type of reselection, and a second condition to determine which reselection to perform first.

[0295] WTRU can determine thresholds for cell (re)selection. In the example, WTRU can determine thresholds for cell (re)selection and / or relay (re)selection, which may include one or more of the following: the Uu RSRP threshold for the current cell to perform cell (re)selection, the Uu RSRP threshold for candidate cells to perform cell (re)selection, the SL-RSRP of the current relay to trigger relay (re)selection, and / or the acceptable SD-RSRP of a relay (e.g., a relay suitable for selection) for relay (re)selection.

[0296] The threshold may be determined based on one or any combination of the following: the connection status with the current relay, the type of the current relay (e.g., L2 or L3 relay), and / or whether the current cell is the serving cell for the current WTRU.

[0297] The threshold can be determined based on the current connection status with the relay. If the SL-RSRP and / or SD-RSRP with the current relay is greater than the threshold (e.g., the WTRU has a good connection with the current relay), the WTRU can reduce the Uu RSRP threshold for performing cell (re)selection. For example, if the WTRU already has a good connection with the relay, unnecessary cell (re)selection events can be reduced.

[0298] The threshold may be determined based on whether the current cell is the serving cell of the current relay WTRU. A WTRU can be configured (e.g., pre-configured) with two Uu RSRP thresholds for performing cell (re)selection. For example, one threshold can be used if the current cell is the serving cell of the relay WTRU, and the other threshold can be used if the current cell is not the serving cell of the relay WTRU. The WTRU may determine which threshold to use based, for example, whether the current camping gNB is serving the WTRU's current relay.

[0299] The WTRU may decide not to perform congestion control for discovery transmissions. The WTRU may determine that the transmit power of the discovery message is not limited by the resource pool's CBR. The transmit power may be a function of downlink path loss. The WTRU may, for example, allow the message to reach a relay WTRU in the event of congestion in the resource pool.

[0300] Although the features and elements described above are described in specific combinations, each feature or element may be used alone without other features and elements of the preferred embodiment, or in various combinations with or without other features and elements.

[0301] While the implementations described herein may take into account 3GPP-specific protocols, it is understood that the implementations described herein are not limited to this scenario and may be applicable to other wireless systems. For example, while the solutions described herein take into account LTE, LTE-A, New Radio (NR), or 5G-specific protocols, it is understood that the solutions described herein are not limited to this scenario and may be further applicable to other wireless systems.

[0302] The processes described above can be implemented in computer programs, software, and / or firmware embedded in computer-readable media for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via wired and / or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, internal hard disks, and removable disks, as well as magnetic media, magneto-optical media, and / or optical media such as compact disc (CD)-ROM discs and / or digital versatile disks (DVDs). A processor associated with software can be used to implement radio frequency transceivers for use in WTRUs, terminals, base stations, RNCs, and / or any host computer.

Claims

1. A wireless transmit receive unit (WTRU), comprising:

1. A processor, comprising: receiving configuration information including an indication of a resource pool, the configuration information indicating whether the resource pool is dedicated to transmitting discovery information; receiving a grant associated with a sidelink transmission, the grant indicating use of the resource pool; and sending the sidelink transmission using the discovery information, the sidelink transmission including the discovery information, provided that the resource pool is dedicated to transmitting discovery information. Processor configured to A WTRU comprising:

2. 2. The WTRU of claim 1, wherein if the configuration information indicates that the resource pool is dedicated to transmitting discovery information, the sidelink transmission is limited to transmitting discovery information.

3. 2. The WTRU of claim 1, wherein if the configuration information indicates that the resource pool is not dedicated to transmitting discovery information, then the sidelink transmissions are not limited to transmitting discovery information.

4. The condition is a first condition, The processor: determining that a second condition is satisfied; and 2. The WTRU of claim 1, further configured to: apply a Link Control Protocol (LCP) restriction based on the determination that the second condition is met; and wherein the sidelink transmission is further determined based on the applied LCP restriction.

5. 5. The WTRU of claim 4, wherein the second condition is associated with one or more of a channel busy ratio associated with the resource pool, an allowable transmit power, a size of a grant associated with the sidelink transmission, or a priority associated with the sidelink transmission.

6. The WTRU of claim 1 , wherein the sidelink transmission includes at least one of discovery information or data information.

7. A method implemented by a wireless transmit receive unit (WTRU), comprising: receiving configuration information including an indication of a resource pool, the configuration information indicating whether the resource pool is dedicated to transmitting discovery information; receiving a grant associated with a sidelink transmission, the grant indicating use of the resource pool; sending the sidelink transmission using the resource pool, provided that the resource pool is dedicated to transmitting discovery information, the sidelink transmission including discovery information; A method comprising:

8. 8. The method of claim 7, wherein if the configuration information indicates that the resource pool is dedicated to transmitting discovery information, the sidelink transmission is limited to transmitting discovery information.

9. 8. The method of claim 7, wherein if the configuration information indicates that the resource pool is not dedicated to transmission of discovery information, the sidelink transmission is not limited to transmission of discovery information.

10. The condition is a first condition, determining that a second condition is met; applying a Link Control Protocol (LCP) restriction based on the determination that the second condition is met, wherein the sidelink transmission is further determined based on the applied LCP restriction; and The method of claim 7 further comprising:

11. 11. The method of claim 10, wherein the second condition is associated with one or more of a channel busy ratio associated with the resource pool, an allowable transmission power, a size of a grant associated with the sidelink transmission, or a priority associated with the sidelink transmission.

12. 8. The method of claim 7, wherein the sidelink transmission comprises at least one of discovery information or data information.

Images