Method and apparatus for link management and recovery for sidelink relays - Patents.com

Abstract

Described herein are methods and apparatus for link management and recovery for sidelink relays. The method may include transmitting a packet to a network via a first relay and using a sidelink radio bearer (SLRB) configuration, where the transmitted packet includes an identifier associated with the first relay; receiving a message identifying an alternative relay; and detecting a radio link failure. The method may also include obtaining signal quality measurements of reference signals associated with the alternative relays; selecting a second relay from the alternative relays having the highest signal quality; and transmitting a reconfiguration message to the selected second relay indicating use of the same or equivalent SLRB configuration. If the response indicates successful reconfiguration of the second relay, the packet may be transmitted via the second relay using the same or equivalent SLRB configuration. The packet may include an identifier associated with the second relay.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 061,532, filed August 5, 2020, and U.S. Provisional Patent Application No. 63 / 185,801, filed May 7, 2021, the contents of which are incorporated herein by reference. Summary of the Invention

[0002] Described herein are methods and apparatus for link management and recovery for sidelink relays. The method may include transmitting a packet to a network via a first relay and using a sidelink radio bearer (SLRB) configuration, where the transmitted packet includes an identifier associated with the first relay; receiving a message identifying an alternative relay; and detecting a radio link failure. The method may also include obtaining signal quality measurements of reference signals associated with the alternative relays; selecting a second relay from the alternative relays having the highest signal quality; and transmitting a reconfiguration message to the selected second relay indicating use of the same or equivalent SLRB configuration. If the response indicates successful reconfiguration of the second relay, the packet may be transmitted via the second relay using the same or equivalent SLRB configuration. The packet may include an identifier associated with the second relay. [Brief explanation of the drawings]

[0003] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, in which like reference numerals indicate similar elements and in which: [Figure 1A] FIG. 1 is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B]1B is a system diagram illustrating an exemplary wireless transmit / receive unit (WTRU) that may be used within the communications system shown in FIG. 1A, according to one embodiment. [Figure 1C] 1B is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system shown in FIG. 1A, according to one embodiment. [Figure 1D] 1B is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communication system shown in FIG. 1A, according to one embodiment. [Figure 2] FIG. 1 illustrates an example user plane radio protocol stack for Layer 2 evolved WTRU inter-network relay. [Figure 3] FIG. 1 illustrates an example control plane radio protocol stack for Layer 2 evolved WTRU inter-network relay. [Figure 4] FIG. 10 illustrates an example of inter-WTRU relaying. [Figure 5] FIG. 1 illustrates an example of a WTRU inter-network relay. [Figure 6] 1 is a flow diagram of an exemplary re-establishment or recovery procedure. DETAILED DESCRIPTION OF THE INVENTION

[0004] 1A illustrates an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. Communication system 100 may be a multiple-access system that provides content, such as voice, data, video, messaging, broadcasts, etc., to multiple wireless users. Communication system 100 may enable multiple wireless users to access such content through sharing of system resources, including wireless bandwidth. For example, the communication system 100 may use one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word discrete Fourier transform spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multicarrier (FBMC), etc.

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

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

[0007] The base station 114a may be part of the RAN 104, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The 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 a cell (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage for a particular geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers per sector of the cell, for example, using beamforming to transmit and / or receive signals in desired spatial directions.

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

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

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

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

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

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

[0014] 1A may be, for example, a wireless router, a Home Node B, a Home eNode B, or an access point and may utilize any suitable RAT to facilitate wireless connectivity in a local area such as a location such as a business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may establish a picocell or a femtocell using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 through the CN 106.

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

[0016] The CN 106 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a public switched telephone network providing plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), the user datagram protocol (UDP), and / or the internet protocol (IP) of the TCP / IP Internet protocol suite. The networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the network 112 may include another CN connected to one or more RANs, which may use the same RAT as the RAN 104 or a different RAT.

[0017] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links.) For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with a base station 114a that may use a cellular-based wireless technology and a base station 114b that may use an IEEE 802 wireless technology.

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

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

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

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

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

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

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

[0025] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or instead of information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 116 and / or determine its location based on the timing of signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may obtain location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0026] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or 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, etc. The peripherals 138 may include one or more sensors. The sensor may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor, and the like.

[0027] The WTRU 102 may include a full-duplex radio for transmitting and receiving some or all of the signals (e.g., associated with a particular subframe on both the UL (e.g., for transmission) and DL (e.g., for reception)) simultaneously and / or together. The full-duplex radio may include an interference management unit for reducing and or substantially eliminating self-interference through hardware (e.g., chokes) or signal processing via a processor (e.g., via a separate processor (not shown) or processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio for transmitting and receiving some or all of the signals (e.g., associated with a particular subframe on either the UL (e.g., for transmission) or DL ​​(e.g., for reception)).

[0028] 1C is a system diagram illustrating the RAN 104 and the CN 106 according to one embodiment. As mentioned above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using E-UTRA radio technology. The RAN 104 may also communicate with the CN 106.

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

[0030] Each of the eNodeBs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling, etc. in the UL and / or DL. As shown in FIG. 1C, the eNodeBs 160a, 160b, 160c may communicate with one another via an X2 interface.

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

[0032] The MME 162 may be connected to each of the eNodeBs 162a, 162b, 162c in the RAN 104 via an S1 interface and may function as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, activating / deactivating bearers, selecting a particular serving gateway during initial attach of the WTRUs 102a, 102b, 102c, etc. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies such as GSM and / or WCDMA.

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

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

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

[0036] Although the WTRU is depicted in FIGS. 1A-1D as a wireless terminal, it is contemplated that in certain representative embodiments, such a terminal may use a wired communication interface (e.g., temporarily or permanently) with the communication network.

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

[0038] A WLAN in infrastructure Basic Service Set (BSS) mode may have an access point (AP) of the BSS and one or more stations (STAs) associated with the AP. The AP may have access to or interface with a distribution system (DS) or another type of wired / wireless network that carries traffic within and / or outside the BSS. Traffic originating from outside the BSS to a STA may arrive through the AP and be delivered to the STA. Traffic originating from a STA to a destination outside the BSS may be sent to the AP and transmitted to the respective destination. Traffic between STAs within the BSS may be transmitted, for example, through the AP; the source STA may transmit traffic to the AP, which may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be transmitted between a source STA and a destination STA (e.g., directly between them) in 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 an Independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (e.g., all of the STAs) may communicate directly with each other. The IBSS mode of communication may be referred to herein as an "ad hoc" communication mode.

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

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

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

[0042] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidths and carriers 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 non-TVWS spectrum. According to representative embodiments, 802.11ah may support meter-type control / machine-type communications (MTC), such as MTC devices in macro coverage areas. MTC devices may have specific capabilities, including, for example, support for (e.g., only support for) specific and / or limited bandwidths. MTC devices may include batteries with above-threshold battery life (e.g., to maintain very long battery life).

[0043] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that can be designated as a primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be configured and / or limited by the STAs among all STAs operating in the BSS that support the minimum bandwidth operating mode. In an 802.11ah example, the primary channel can be 1 MHz wide for STAs (e.g., MTC-type devices) that support (e.g., only) the 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) configuration can depend on the condition of the primary channel. For example, if the primary channel is busy, a STA (that only supports 1 MHz mode of operation) transmitting to the AP may cause all of the available frequency bands to be considered busy, even if most of the available frequency bands are idle.

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

[0045] 1D is a system diagram illustrating the RAN 104 and the CN 106 according to one embodiment. As mentioned above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using NR radio technology. The RAN 104 may also communicate with the CN 106.

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

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

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

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

[0050] 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While the foregoing elements are shown as part of the CN 106, it will be understood that any of these elements may also be owned and / or operated by an entity other than the CN operator.

[0051] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N2 interface and may function as a control node. For example, the AMF 182a, 182b may be responsible for user authentication of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selection of the SMF 183a, 183b for registration, management of registration areas, termination of non-access stratum (NAS) signaling, mobility management, etc. The network slicing may be used by the AMF 182a, 182b to customize the CN support of the WTRUs 102a, 102b, 102c based on the type of service utilizing the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, etc. The AMFs 182a, 182b may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0052] The SMFs 183a, 183b may be connected to the AMFs 182a, 182b in the CN 106 via an N11 interface. The SMFs 183a, 183b may also be connected to the UPFs 184a, 184b in the CN 106 via an N4 interface. The SMFs 183a, 183b may select and control the UPFs 184a, 184b and configure the routing of traffic through the UPFs 184a, 184b. The SMFs 183a, 183b may perform other functions, such as managing and allocating WTRU IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0053] The UPFs 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks such as the Internet 110 to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPFs 184, 184b may perform other functions such as packet routing and forwarding, user plane policy enforcement, support for multi-homed PDU sessions, handling user plane QoS, DL packet buffering, mobility anchoring, etc.

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

[0055] 1A-1D and the corresponding description thereof, one or more or all of the functions described herein with respect to one or more of the WTRUs 102a-d, base stations 114a-b, eNodeBs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other devices described herein may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation devices may be used to test other devices and / or simulate network and / or WTRU functions.

[0056] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and / or an 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 communication network to test other devices in the communication 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 communication network. The emulation devices may be directly coupled to another device for testing and / or conducting tests using over-the-air wireless communication.

[0057] One or more emulation devices may perform one or more functions, inclusive, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in test scenarios in a test lab and / or in an undeployed (e.g., test) wired and / or wireless communication network 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 (which may include, e.g., one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0058] New Radio (NR) Release 17 may consider the use of both WTRU-to-network relaying and WTRU-to-WTRU relaying based on the PC5 interface (e.g., sidelink). For example, an initial version of the NR sidelink procedure was developed for NR Release 16, which may support V2X-related road safety services. This design may provide support for broadcast, groupcast, and unicast communications in both out-of-coverage and in-network coverage scenarios. However, it may be desirable to improve coverage extension and power efficiency, and consider a wider range of applications and services than those considered in Release 16, for example, to support enhanced quality of service (QoS) requirements.

[0059] For example, it may be desirable to consider WTRU inter-network coverage extension and / or WTRU-to-WTRU coverage extension. Regarding WTRU inter-network coverage extension, air interface (i.e., Uu) coverage reachability may be necessary for a WTRU to reach a server in the PDN network or a corresponding WTRU outside the proximity area. The various options discussed in Release 13 regarding WTRU inter-network relaying may be limited to EUTRA-based technologies and therefore may not apply to NR-based systems for both NG-RAN and NR-based sidelink communications. Regarding WTRU-to-WTRU coverage extension, current proximity reachability may be limited to a single-hop sidelink link via either EUTRA-based or NR-based sidelink technologies. However, this may not be sufficient in scenarios where Uu coverage does not exist, given the limited single-hop sidelink coverage.

[0060] Some considerations may include a mechanism with minimal impact to the specifications for single-hop NR sidelink relaying that supports scheduling assignment (SA) requirements for sidelink-based WTRU inter-network relaying and WTRU-to-WTRU relaying, emphasizing, for example, one or more aspects related to Layer 3 relaying and Layer 2 relaying. Such aspects may include relay (re)selection criteria and procedures, relay / remote WTRU authorization, QoS for relay functionality, service continuity, security of relayed connections after SA3 has concluded, and impact on user plane protocol stacks and control plane procedures (e.g., connection management of relayed connections). Other considerations may include, for example, support for higher layer operation of discovery models and / or procedures for sidelink relaying, assuming no new physical layer channels / signals.

[0061] Release 13 introduced relaying via proximity services (ProSe) WTRU inter-network relays to extend network coverage to out-of-coverage WTRUs by using a PC5 interface (e.g., D2D) between the out-of-coverage WTRU and the WTRU inter-network relay. The ProSe WTRU inter-network relay can provide a general L3 forwarding function capable of relaying any type of IP traffic between the remote WTRU and the network. One-to-one and one-to-many sidelink communications may be used between the remote WTRU and the ProSe WTRU inter-network relay. Only one single-carrier (e.g., public safety ProSe carrier) operation may be supported for both the remote WTRU and the relay WTRU (e.g., Uu and PC5 may be the same carrier for both the relay WTRU and the remote WTRU). The remote WTRU may be authorized by higher layers, for example, to be in coverage of a Public Safety ProSe carrier or out of coverage on any supported carrier including the Public Safety ProSe carrier for WTRU inter-network relay discovery, selection or reselection, and communication.

[0062] Relay selection or reselection for a ProSe WTRU inter-network relay may be performed based on one or a combination of access stratum (AS) layer quality measurements (e.g., reference signal received power (RSRP)) and higher layer criteria. The eNB may control whether a WTRU can operate as a ProSe WTRU inter-network relay. ProSe WTRU inter-network relay operation may be supported in a cell if the eNB broadcasts information associated with ProSe WTRU inter-network relay operation. The eNB may provide one or more of transmission resources for ProSe WTRU inter-network relay discovery using broadcast signaling for the RRC_IDLE state and dedicated signaling for the RRC_CONNECTED state, and reception resources for ProSe WTRU inter-network relay discovery using broadcast signaling.

[0063] The eNB may, for example, broadcast one or more minimum and / or maximum Uu link quality (e.g., RSRP) thresholds that a ProSe WTRU inter-network relay may need to meet (or "adhere to") before being able to initiate a WTRU inter-network relay discovery procedure. In some cases, such as when operating in RRC_IDLE mode and the eNB broadcasts a transmission resource pool, the WTRU may use the thresholds to autonomously start or stop a WTRU inter-network relay discovery procedure. In some cases, such as when operating in RRC_CONNECTED mode, the WTRU may use the thresholds to determine whether it can indicate to the eNB that it is a relay WTRU and wishes to initiate ProSe WTRU inter-network relay discovery. If the eNB does not broadcast a transmission resource pool for ProSe-WTRU inter-network relay discovery, the WTRU may initiate a request for ProSe-WTRU inter-network relay discovery resources by dedicated signaling while meeting (or "adhering to") one or more broadcasted thresholds.

[0064] If ProSe WTRU inter-network relay operation is initiated by broadcast signaling, the WTRU inter-network relay may perform ProSe WTRU inter-network relay discovery when in RRC_IDLE mode. If ProSe WTRU inter-network relay operation is initiated by dedicated signaling, it may perform relay discovery when in RRC_CONNECTED mode. A ProSe WTRU inter-network relay performing sidelink communication for ProSe WTRU inter-network relay operation may need to operate in RRC_CONNECTED mode. After receiving a Layer 2 link establishment request or a temporary mobile group identity (TMGI) monitoring request (e.g., a higher layer message), or any other logically equivalent message from a remote WTRU, the ProSe WTRU inter-network relay may indicate to the eNB that it is a ProSe WTRU inter-network relay and intends to perform ProSe WTRU inter-network relay sidelink communication. The eNB may provide resources for ProSe WTRU inter-network relay communication.

[0065] The remote WTRU may decide when to start monitoring for ProSe WTRU inter-network relay discovery. The remote WTRU may send a ProSe WTRU inter-network relay discovery request message while in RRC_IDLE or RRC_CONNECTED, depending on the configuration of resources for ProSe WTRU inter-network relay discovery. The eNB may broadcast a threshold value, which may be used by the remote WTRU to determine whether it can send a ProSe WTRU inter-network relay discovery request message to connect or communicate with the ProSe WTRU inter-network relay WTRU. An RRC_CONNECTED remote WTRU may use the broadcasted threshold value to determine whether it can indicate to the eNB that it is a remote WTRU and wishes to participate in ProSe WTRU inter-network relay discovery and / or communication. The eNB may provide transmission resources using broadcast or dedicated signaling, and provide reception resources using broadcast signaling, for ProSe WTRU inter-network relay operation. The remote WTRU may stop using discovery and communication resources of the ProSe WTRU inter-network relay if the RSRP exceeds the broadcasted threshold. The exact time for traffic switching from Uu to PC5 or vice versa may be determined or signaled by a higher layer function, entity, or their logical equivalent.

[0066] The remote WTRU may perform radio measurements on the PC5 interface and use these measurements, along with higher layer criteria, for ProSe WTRU inter-network relay selection and reselection. A ProSe WTRU inter-network relay may be deemed suitable (e.g., with respect to radio criteria) if, for example, the PC5 link quality exceeds a configured threshold (e.g., pre-configured or provided by the eNB). In some cases, the remote WTRU may select a ProSe WTRU inter-network relay that meets one or more criteria (e.g., provided by higher layer signaling, a higher layer function or entity, or their logical equivalents) and has the best PC5 link quality among all suitable ProSe WTRU inter-network relays.

[0067] The remote WTRU may trigger reselection of the ProSe WTRU inter-network relay under one or more circumstances. For example, the remote WTRU may trigger reselection of the ProSe WTRU inter-network relay if the PC5 signal strength of the current ProSe WTRU inter-network relay falls below a configured signal strength threshold and / or if the remote WTRU receives a Layer 2 link release message (e.g., a higher layer message or any logical equivalent) from the ProSe WTRU inter-network relay.

[0068] In Release 14, research was conducted in the RAN on WTRU inter-network relays for commercial use cases tailored to wearables and IoT devices. While such research did not result in any specifications, technical reports (TRs) provided some preferred solutions for such relays. In contrast to ProSe WTRU inter-network relays, which can use Layer 3 (IP layer) relaying approaches, the WTRU inter-network relay for wearables is expected to be a Layer 2 relay based on the protocol stacks shown in Figures 2 and 3, which are substantially introduced and described in the following paragraphs. Relay solutions in previous releases of the LTE specification were based on a one-to-one communication link established at higher layers (e.g., the ProSe layer) between two WTRUs (e.g., a remote WTRU and a WTRU inter-network relay). Such a connection was transparent to the AS layer, and connection management signaling and procedures performed at higher layers were carried by the AS layer data channel. The AS layer was sometimes unaware of such a one-to-one connection.

[0069] Figure 2 illustrates an example user plane radio protocol stack for Layer 2 evolved WTRU inter-network relay. As shown in Figure 2, a remote WTRU 201 may interface with a Layer 2 relay WTRU 202 over a sidelink (i.e., the remote WTRU 201 and relay WTRU 202 may communicate over a PC5 interface). The Layer 2 relay WTRU 202 and an eNB 203 may have a lower layer link established with the eNB over the air interface (Uu).

[0070] PDCP and IP links may be established between the remote WTRU 201 and the eNB 203, while RLC, MAC, and PHY and non-3GPP transport layer links may be established between the remote WTRU 201 and the Layer 2 relay WTRU 202 over PC5 and between the evolved Layer 2 relay WTRU 202 and the eNB 203 over Uu. Relaying of user plane data from the remote WTRU 201 to the core network (CN) 204 via the Layer 2 evolved WTRU inter-network relay, and vice versa, may be performed above the RLC layer (e.g., at the PDCP and IP layers).

[0071] 3 illustrates an example control plane radio protocol stack for a Layer 2 evolved WTRU inter-network relay. Similar to that described above with respect to elements 201, 202, 203, and 204 for FIG. 2, the remote WTRU 301 may interface with the Layer 2 relay WTRU 302 via a sidelink (i.e., the remote WTRU 201 and relay WTRU 202 may communicate via a PC5 interface). PDCP and RRC links may be established between the remote WTRU 301 and the eNB 303, while RLC, MAC, and PHY, as well as non-3GPP transport layers, may be established between the remote WTRU 301 and the Layer 2 relay WTRU 302 via PC5, and between the evolved Layer 2 relay WTRU 302 and the eNB 303 via Uu. Relaying of control plane data from the remote WTRU 201 to the core network (CN) 204 via the Layer 2 evolved WTRU inter-network relay, and vice versa, may be performed above the RLC layer (e.g., at the PDCP and IP layers).

[0072] In a system operating according to the NR V2X framework (e.g., as described in Release 16), the AS layer can support unicast links between two WTRUs. The unicast link may be initiated by higher layers (e.g., as in a ProSe one-to-one connection). However, the AS layer can be informed of the existence of such a unicast link and of any data transmitted in a unicast manner between peer WTRUs. With such knowledge, the AS layer can support hybrid automatic repeat request (HARQ) feedback, channel quality indicator (CQI) feedback, and unicast-specific power control schemes.

[0073] Unicast links at the AS layer can be supported via PC5-radio resource configuration (RRC) connections. A PC5-RRC connection can be a logical connection between a pair of source Layer 2 ID and destination Layer 2 ID within an AS. One PC5-RRC connection can correspond to one PC5 unicast link. PC5-RRC signaling can be initiated after the corresponding PC5 unicast link is established. A PC5-RRC connection and corresponding sidelink signaling radio bearers (SRBs) and sidelink dedicated radio bearers (DRBs) can be released when the PC5 unicast link is released as indicated by higher layers.

[0074] For each PC5-RRC unicast connection, a sidelink SRB may be used to transmit PC5-S messages (e.g., messages used to establish, maintain, or release a secure PC5 link between two WTRUs). Such messages may be transmitted before PC5-S security is established. One sidelink SRB may be used to transmit PC5-S messages to establish PC5-S security. One sidelink SRB may be used to transmit PC5-S messages after PC5-S security is established, and the PC5-S messages may be protected. One sidelink SRB may be used to transmit PC5-RRC signaling, which is protected and sent only after PC5-S security is established.

[0075] The PC5-RRC signaling may include one or more sidelink configuration messages (e.g., an RRCReconfigurationSidelink message, or a logically equivalent message) that allow the WTRU to configure RX-related parameters of each sidelink radio bearer (SLRB) at the peer WTRU. Such reconfiguration messages may configure parameters for each protocol in the L2 stack (e.g., service data adaptation protocol (SDAP), packet data convergence protocol (PDCP), etc.). The receiving WTRU may confirm or reject such configuration depending on whether it can support the configuration proposed by the peer WTRU.

[0076] Integrated access and backhaul (IAB) in Release 16 can support backhaul radio link failure (RLF) indication. When a backhaul RLF recovery failure is detected at an IAB mobile termination (MT), for each egress link associated with an IAB distributed unit (DU), the transmitter of the backhaul adaptation protocol (BAP) entity in the IAB-DU can construct a BAP control protocol data unit (PDU) for the backhaul RLF indication. If an egress backhaul (BH) radio link control (RLC) channel for the BAP control PDU is configured, the BAP entity in the IAB-DU can submit the BAP control PDU to the configured egress BH RLC channel of the egress link. In some cases, such as when an egress BH RLC channel for the BAP control PDU is not configured, the BAP control PDU may be submitted to any egress BH RLC channel of the egress link. Upon receiving a BAP control PDU for a backhaul RLF indication from a lower layer (e.g., an ingress BH RLC channel), the receiving portion of the BAP entity may indicate to upper layers that a backhaul RLF indication has been received for the ingress link on which the BAP control PDU is received.

[0077] The Integrated Access and Backhaul (IAB) framework described in Release 16 can support flow control feedback as follows: For a link, the transmitter of the BAP entity in the IAB-MT can construct a BAP control PDU for flow control feedback when flow control feedback is triggered when buffer load exceeds a certain level or when a BAP control PDU for flow control polling is received at the receiver. If an egress BH RLC channel for the BAP control PDU is configured, the egress BH RLC channel may submit the BAP control PDU to the configured egress BH RLC channel of the egress link. If an egress BH RLC channel for the BAP control PDU is not configured, the BAP control PDU can be submitted to any egress BH RLC channel of the egress link.

[0078] The various problems for which solutions are proposed herein can be understood as follows.

[0079] Link management may be performed for an RRC_CONNECTED WTRU via a Uu RLM / RLF procedure, which may use the quality of reference signals (RS) transmitted by the network to determine when the link is no longer reliable. For a sidelink connection, a similar PC5-RRC connection between two WTRUs may exist, such that link management is performed via a SL RLF procedure, which may include monitoring the number of consecutive HARQ discontinuous transmissions (DTX) observed by the transmitting WTRU and / or the number of consecutive RLC retransmissions performed.

[0080] In the case of relayed links involving sidelinks (e.g., WTRU-to-network (NW) relay or WTRU-to-WTRU relay), individual link management procedures may not be sufficient because link management on one link is not necessarily visible to another link. Therefore, a mechanism to make a failure on one link visible to another link may be desirable. For example, in a WTRU-to-network relay scenario, the relay WTRU may trigger a TX-based RLF over the relayed link. However, such an RLF may be invisible to the remote WTRU if the remote WTRU does not have its own periodic transmission to trigger a similar RLF or if the SL channel is not reciprocal. In such cases, recovery may be delayed and it may be difficult to achieve service continuity. Specifically, while the network may be able to transmit data over Uu (in the case of an SL failure), it cannot know whether the WTRU is reachable after a failure, given the premise that it should not require a WTRU connected via a WTRU-to-network relay to perform all necessary Uu procedures (e.g., for power saving purposes).

[0081] Furthermore, recovery on Uu can be achieved via a re-establishment procedure, but another assumption may be that the SL RRC connection exists between a single pair of WTRUs, so no such procedure exists on SL. For relayed links, recovery can be achieved by selecting a new relay. However, a solution for selecting such a relay is desirable so that the relay can achieve the same QoS as the failed link.

[0082] Methods for link management and recovery for sidelink relay are described herein. Link management mechanisms applicable to both WTRU-to-WTRU and WTRU-to-network relay are discussed in detail herein.

[0083] FIG. 4 illustrates an example architecture for link management and recovery in the context of inter-WTRU relay. A relay WTRU 402 can be used as an inter-WTRU relay, as shown in FIG. 4. The first link illustrated in FIG. 4 may correspond to the link between the source WTRU 401 and the relay WTRU 402. The second link may also refer to the link between the relay WTRU 402 and either the destination or next-hop WTRU 403 in an inter-WTRU or inter-WTRU-network multi-hop link. Generally speaking, the destination may be a WTRU or a network node, depending, for example, on whether the relay is an inter-WTRU relay or an inter-WTRU-network relay. In the case illustrated in FIG. 4, the destination is the former destination WTRU 404. Without loss of generality, the term source WTRU may also refer to a relay WTRU served by another relay along the link to the destination.

[0084] 5 illustrates another example architecture for link management and recovery, particularly in the context of a WTRU inter-network relay. A relay WTRU may be used as a WTRU inter-network relay, as shown in FIG. 5. The first link shown in FIG. 4 may correspond to the link between the source WTRU 501 and the relay WTRU 502. The second link may also refer to the link between the relay WTRU 502 and either the destination or next-hop WTRU 503 in an inter-WTRU or inter-WTRU multi-hop link. In the case shown in FIG. 5, the destination is Node B 504. Without loss of generality, the term source WTRU described with respect to FIG. 5 may also refer to a relay WTRU that is served by another relay along the link to the destination.

[0085] In some embodiments, a WTRU configured as an SL relay (e.g., a WTRU-to-network relay or a WTRU-to-WTRU relay) may send a link problem indication over the sidelink to one or more other WTRUs. Such an indication may be sent, for example, to the source WTRU of a relayed connection or to another WTRU involved in the relay connection, in accordance with the architecture described herein and shown in the figures. Such an indication may be sent upon detection of a link problem detected between the relay WTRU and the NW (in the case of a WTRU-to-network relay), or between the relay WTRU and another WTRU (which may be, for example, a destination WTRU or another relay WTRU, in accordance with the architecture described herein and shown in the accompanying figures).

[0086] The link problem indication (LPI) may be an L2 protocol message transmitted via any or a combination of a PC5-RRC message, a SL MAC control element (CE), or an L2 control PDU, such as an RLC control PDU, an adaptation layer (or relay adaptation layer) control PDU, a PDCP PDU, or any other logical equivalent. For example, the WTRU may transmit the LPI as a PC5-RRC message and include with the message a SL medium access control (MAC) CE and / or adaptation control PDU that contains some of the information described herein and associated with the LPI. Alternatively or additionally, the LPI may be sent via a sidelink control information (SCI) message.

[0087] The LPI may be broadcast / groupcast to all source WTRUs served by a particular relay WTRU. For example, the relay WTRU may be configured with an L2 source / destination ID (or a logically equivalent source / destination ID) for transmission of an LPI or similar status message targeted to each or a subset of the source WTRUs served by the relay WTRU. The relay WTRU (and corresponding source WTRU) may determine such an L2 ID based on any combination of one or more indications received from higher layers, derive the L2 ID from the RAN ID, or determine the L2 ID based on the relay WTRU's own configured L2 ID and / or based on an L2 address exchange procedure in a PC5-RRC configuration with each source WTRU. When the relay WTRU determines the L2 ID, e.g., based at least on higher layers, the relay WTRU and corresponding WTRU may receive the L2 ID explicitly from higher layers and / or from the network, e.g., when operating as / configured to use a relay WTRU. When the relay WTRU determines the L2 ID by deriving the L2 ID from at least the RAN ID, the relay WTRU may use any feature of the RAN ID, such as, for example, a cell radio network temporary identifier (C-RNTI), an inactive RNTI (I-RNTI), or an international mobile subscriber identity (IMSI).

[0088] For example, when a relay WTRU determines an L2 ID based at least on its own configured L2 ID, it may reuse one of its own L2 source / destination IDs, potentially along with some other information, to construct the source / destination ID for transmission of the LPI. For example, the relay WTRU may use a subset of the bits of one of its source / destination IDs and append a special combination of bits to the subset to create a groupcast source / destination ID. For example, the relay WTRU may use a subset of the bits of the higher layer provided source / destination ID and append a WTRU-specific identifier, which may be randomly selected, assigned by the network, or derived from some other RAN ID (e.g., C-RNTI or IMSI).

[0089] For example, the relay WTRU may be configured (e.g., by higher layers) with L2 source / destination IDs to use for transmitting LPI messages when determining the L2 IDs based at least on the L2 address exchange procedure in PC5-RRC configuration with each source WTRU, and may send the L2 source / destination IDs to each source WTRU during the PC5-RRC configuration procedure for link establishment. For example, the relay WTRU may determine the source / destination addresses using any of the means described in the examples above (e.g., derived from the RAN ID) and provide the IDs to each of the source WTRUs in the PC5-RRC configuration procedure.

[0090] Once the source WTRU knows the L2 source / destination ID associated with the transmission of the LPI message, it may monitor the source / destination ID for receipt of groupcast LPI messages sent by the relay WTRU.

[0091] In some embodiments, the LPI may be transmitted in a dedicated message on the PSCCH or PSSCH identified with a special SCI or SCI format (e.g., an SCI without a source / destination ID). For example, a new SCI format may be created (e.g., using reserved bits in the SCI) that includes an identifier for transmissions other than the L1 source / destination ID. For example, this SCI may indicate a new transmission type (e.g., a relay-specific broadcast transmission to the source WTRU). The SCI may further include an identifier or parameter that identifies the relay WTRU, such as a RAN-specific identity for the relay WTRU (e.g., as described herein), an identifier for the relay WTRU exchanged via PC5-RRC (e.g., as described herein), and / or an identifier provided by higher layers (e.g., as described herein).

[0092] In some embodiments, if the content of the LPI is restricted (e.g., includes only an indication of RLF), the LPI may be transmitted on a dedicated PHY channel, such as the physical sidelink control channel (PSCCH), the physical sidelink shared channel (PSSCH), or the physical sidelink feedback channel (PSFCH). Several dedicated resources may be configured for transmission of the LPI on any of the dedicated PHY channels. In particular, the WTRU-to-WTRU relay may be configured with PSFCH resources (e.g., occurring periodically) for transmitting the LPI. For example, the relay WTRU may send an indication (e.g., a HARQ acknowledgment (ACK) or a HARQ negative acknowledgment (NACK)) on the PSFCH resources when it is to transmit the LPI. The relay WTRU may be configured (e.g., by the NW) with one such PSFCH resource per destination WTRU or relay WTRU for the second link and / or information to be sent (e.g., according to the contents of the LPI).

[0093] The source WTRU may receive dedicated configurations / resources associated with the PHY channel associated with the LPI (e.g., in PC5-RRC signaling with the relay WTRU during link establishment), and may monitor such resources to determine reception of the LPI associated with the relayed link.

[0094] A relay WTRU may transmit a Link Problem Recovery Indication (LPRI). Such an LPRI may be associated with the event that triggered the LPI. A WTRU transmitting an LPI may begin monitoring for transmission of the LPRI. The WTRU may transmit an LPRI whenever the condition that triggered the associated LPI is alleviated. Any of the conditions mentioned herein for an LPI may be considered for LPRI when the LPI condition is alleviated. For example, a WTRU may transmit an LPI associated with a buffer status above a CR / resource pool dependent threshold, and then transmit an LPRI when such buffer status falls below another (possibly related) threshold.

[0095] A source WTRU receiving an LPRI may cancel any actions related to relaying, relay reselection / reconfiguration, etc. that may have been initiated as a result of receiving the LPI.

[0096] In some examples, the LPI may initiate (possibly more frequent) discovery for relay selection and / or change the priority / parameters of discovery message transmission. The WTRU may stop such discovery upon receipt of an LPRI indicating that the condition has mitigated. If the condition indicated in the LPI persists (e.g., upon receipt of an LPRI indicating that a second condition has been met, or upon timer expiration without receipt of a second LPI or LPRI), the WTRU may trigger cell reselection and / or reconfiguration of the relayed link.

[0097] In some examples, the WTRU may initiate part of the relay reselection procedure upon receipt of an LPI and then complete the reselection / reconfiguration if the WTRU does not receive an LPRI indicating mitigation of the condition, or if a timer expires without receipt of such an LPRI.

[0098] The relay WTRU may send information in the link problem indication in a periodic manner. The period may depend on the values ​​of one or more parameters described further below. In some cases, the relay WTRU may send the LPI in response to one or a combination of the following conditions: RLF on the second link associated with the destination, failure to perform recovery, relay selection or reselection (which may be associated for (or within) the duration for which recovery or selection or reselection is to occur), and / or receipt of a link problem indication from another WTRU. In some cases, the relay WTRU may determine whether to use the relay WTRU based on: the degree of CBR / CR; based on a relay-specific CR; based on the number of consecutive HARQ feedback failures; based on counter and / or timer values ​​for the second link (which may be the link to the WTRU or the link to the network); based on buffer load at the relay; based on CQI / RSRP measurements received / transmitted by the relay WTRU; based on the QoS of the configured bearers and / or data in the relay buffer (e.g., observed latency or remaining PDB); based on configuration by the peer (source) WTRU (which may be implicit or explicit); based on resource pool configuration; based on Uu quality / conditions; based on Uu mobility events; based on Uu failures; based on whether the current link configuration / status allows for detection of RLF / link issues at the source WTRU; based on the absence of a feedback response; and / or based on whether a mechanism for determining RLF is configured on the first link; specifically, in the context of WTRU-to-WTRU relay, the relay WTRU may determine whether HARQ feedback enabled over a past time window is configured or pre-configured for some SCIs and / or the relay WTRU may determine whether the RLC The LPI may be sent based on any or a combination of the following: the AM has configured at least one SLRB (potentially not counting SL SRBs);

[0099] With respect to an RLF on a second link associated with a destination, for example, a relay WTRU may transmit an LPI when it triggers an RLF related to a second link to a destination WTRU of an inter-WTRU relay connection. Specifically, a WTRU may transmit an LPI to a source WTRU when an RLF occurs for a destination to which the source WTRU is connected via a relay. For example, a relay WTRU may transmit an LPI when it triggers a Uu RLF associated with a second link of an inter-WTRU network relay.

[0100] For example, the relay WTRU may start a timer or start measuring the duration following an RLF on the second link for a failure to perform recovery. The relay WTRU may initiate relay selection or reselection. If the reselection is not completed before the timer expires or when it is determined that the duration has elapsed, the relay WTRU may send an LPI message.

[0101] Upon receiving a link problem indication from another WTRU, for example, the relay WTRU may receive an LPI from another WTRU (e.g., a next-hop relay WTRU) on a second link and may transmit the LPI and / or forward the received LPI to the source WTRU.

[0102] With respect to the CBR / CR measure, for example, the WTRU may transmit an LPI when the measured CBR / CR meets some configured or preconfigured condition. Such a condition may further depend on the QoS of the data transmitted by the relay and / or the SLRB / relay configuration at the relay. Such a condition may depend on other conditions mentioned herein for transmitting an LPI. Such a condition may consist of the CBR / CR reaching some configured or preconfigured value, possibly for a certain period of time. For example, the WTRU may transmit an LPI when the measured channel busy ratio (CBR) exceeds a configured or preconfigured threshold, possibly for a certain period of time. For example, the WTRU may transmit an LPI when the channel occupancy ratio (CR) exceeds a configured or preconfigured threshold.

[0103] With respect to the relay-specific CR, the WTRU may determine the relay-specific CR. In particular, the relay WTRU may measure the amount of resources reserved / utilized for transmission of relayed traffic and / or the ratio of the CR applicable to the relayed traffic. The WTRU may determine such ratio by determining the ratio of traffic in the WTRU's buffer for relay traffic versus non-relay traffic and multiply such ratio by the measured CR. The WTRU may determine the relay-specific CR by determining the amount of resources relative to the total number of resources in a resource pool associated with the relayed link or used for transmitting to a destination ID including data from an LCH associated with the relayed link.

[0104] Regarding the number of consecutive HARQ feedback failures, the relay WTRU may send an LPI to the source WTRU when the number of consecutive DTX receptions for HARQ-based transmissions for a destination reaches some value. Such a destination may correspond to a destination with which the source WTRU is communicating via a WTRU-to-WTRU relay. For example, the relay WTRU may trigger an LPI or LPRI when an RLF is triggered following transmission of an LPI for consecutive DTX or when the number of consecutive DTX is reset.

[0105] With respect to the value of the counter and / or timer and / or duration related to the second link, for example, the WTRU inter-network relay WTRU may send an LPI to the source WTRU, e.g., when timer T310 is started, when T310 expires, when T310 reaches some configured or pre-configured value, or when the number of consecutive OOS reaches some pre-configured value. In other words, the WTRU inter-network relay WTRU may send an LPI to the source WTRU, e.g., when the duration begins, when the duration elapses, for some configured or pre-configured duration of the duration, or when the number of consecutive OOS reaches some pre-configured value. For example, the WTRU-to-WTRU relay may send an LPI to the source WTRU when the number of consecutive RLC retransmissions reaches a configured or pre-configured value.

[0106] With regard to buffer load at the relay, for example, the WTRU may send an LPI when the buffer load exceeds a threshold. Such a threshold may further depend on the QoS, SLRB configuration, number of relayed source WTRUs / LCHs, etc. For example, the buffer load that triggers the LPI may be the load of a single LCH, or the overall load of all LCHs or relayed LCHs at the relay WTRU.

[0107] With respect to CQI / RSRP measurements received / transmitted by a relay WTRU, for example, the WTRU may transmit an LPI when the CQI measurement (e.g., of the second link) received by the WTRU's relay is above / below a threshold.

[0108] For example, with respect to QoS of configured bearers and / or data in the relay buffer, the WTRU may transmit an LPI based on any condition (possibly in combination with other conditions) associated with the latency of the SLRB and / or the latency of the data currently buffered in the relay WTRU buffer (possibly for the relay connection). For example, the WTRU may transmit an LPI when the amount of data buffered for any relayed LCH with latency below a threshold (or an expected remaining PDB below a threshold) is above a threshold.

[0109] With respect to configuration by the peer WTRU, the relay WTRU may be configured by the peer WTRU (e.g., in PC5-RRC signaling) with respect to whether or not to transmit an LPI upon the occurrence of a particular trigger. For example, the relay WTRU may be configured to perform one or both of the following two behaviors upon detecting an RLF on the second link: upon detecting an RLF on the second link, the relay WTRU immediately releases the PC5-RRC connection associated with the second link and does not transmit an LPI, or sends an LPI (e.g., potentially including an RLF indication) to the source WTRU and waits for confirmation before releasing the PC5-RRC connection. The relay WTRU may further suspend any transmissions performed on the second link associated with the link that is in RLF. Such configuration may be provided as part of the SLRB configuration. For example, the relay WTRU may receive such configuration parameters for each SLRB and may select a behavior based on at least one of the SLRBs for which the associated behavior is configured.

[0110] The implicit configuration of whether to transmit an LPI may be defined with respect to the activation / deactivation status of the link itself, the WTRU location, the WTRU RRC state, and / or the WTRU coverage status. With respect to the activation / deactivation status of the link itself, for example, the relayed link may be activated / deactivated by the source WTRU and / or the NW and / or higher layers. The WTRU may transmit the LPI only when the link is activated, and may drop or buffer the LPI when the link is deactivated (e.g., to transmit upon activation). For example, the WTRU may broadcast the LPI to all source WTRUs as long as at least one link to the source WTRU is activated. With respect to the WTRU location, for example, the WTRU may be configured with a zone or rule regarding the WTRU's relative location with another WTRU or a Node B (e.g., a gNB) for whether to transmit an LPI. With respect to the WTRU RRC state, for example, the WTRU may determine whether to transmit an LPI if another trigger is met based on the current RRC state of the relay WTRU. With respect to WTRU coverage status, for example, the WTRU may determine whether to send an LPI if another trigger is met based on whether the WTRU is in coverage of a Uu.

[0111] With respect to the resource pool configuration, for example, any conditions described herein for sending an LPI may further depend on the transmission resource pool configuration. For example, the WTRU may send an LPI if the amount of data in the buffer exceeds some value that depends on the density of slots / subchannels available for transmission by the relay and / or the CR / CBR measured at the relay WTRU. For example, the relay WTRU may send an LPI (e.g., for flow control purposes) when the amount of relayed data in the buffer exceeds a TX pool-specific threshold. In another example, the relay WTRU may send an LPI (e.g., for flow control purposes) when the amount of relayed data in the buffer exceeds a function of the CBR / CR and / or the number of subchannels for TX in the resource pool and / or the average latency / remaining PDB of the data currently buffered at the relay WTRU.

[0112] With regard to Uu quality / conditions, the relay WTRU may send an LPI as a result of either the Uu cell RSRP / RSRQ (eg, below a threshold) and / or the measured CQI (eg, below a threshold).

[0113] With respect to Uu mobility events, for example, the relay WTRU may send an LPI as a result of either a handover / reconfiguration / conditional handover / PSCell change being received / triggered at the relay WTRU, a cell reselection event being triggered at the relay WTRU, and / or the relay WTRU changing tracking area, RAN paging area, etc., or moving out of the coverage of a configured or pre-configured set of cells.

[0114] For Uu failure, for example, the relay WTRU may send an LPI as a result of either an RLF, a failed re-establishment, or a failed reconfiguration / handover / PSCell change.

[0115] With respect to whether the current link configuration / status allows for detection of an RLF / link problem at the source WTRU based on a lack of feedback / response, for example, the relay WTRU may select one of the following two behaviors in the RLF of the second link: immediately release the PC5-RRC connection associated with the second link and do not send an LPI, and / or send an LPI (e.g., potentially including an RLF indication) to the source WTRU and wait for confirmation before releasing the PC5-RRC connection. The WTRU relay WTRU may further pause any transmissions performed on the second link associated with the link that is in RLF.

[0116] The relay WTRU may include, in the LPI to the source WTRU, an indication of the failure, an indication of a triggered relay selection / reselection initiated by the relay, or an indication of a triggered Uu re-establishment triggered by the relay, a quantity associated with any of the conditions described herein for sending the LPI, an L2 source / destination ID of the next hop (for which the LPI is applicable in some cases (e.g., the link that triggered the RLF)), one or more RLF-related parameters associated with the second link, one or more LCHs for which other LPI content applies, a cell ID of the cell in which the relay WTRU experienced an RLF / re-establishment failure or any conditions related to RLF, a new cell ID applicable to the WTRU inter-network relay connection (assumed after receipt of the LPI or completion of the reselection procedure), one or more relay reselection candidates (e.g., relay source / destination L2 IDs and / or cell IDs) and any associated measurement / selection metrics (SL / Uu RSRP measurements, etc.), and / or an identifier to be used by the WTRU after receipt of the LPI (e.g., to continue communications after receipt of the LPI and / or successful reselection).

[0117] Regarding the indication of failure, for example, the LPI may include an identifier that further identifies the reason for the failure or the resources for transmission of the LPI, whereby any of the triggers described herein may be for different reasons. Regarding the indication of triggered relay selection / reselection, for example, the relay WTRU may decide to trigger relay selection or relay reselection depending on some conditions associated with the transmission of the LPI. The relay WTRU may include such information in the LPI. Regarding the quantities associated with the conditions described herein for transmitting an LPI, these may include, for example, relay buffer load, CBR, CR, or RSRP. For example, the LPI may include the status (e.g., RLC status / number) of the last packet successfully transmitted over the second link, possibly for each relayed RLC channel associated with the source WTRU on which the LPI is being transmitted.

[0118] With respect to one or more RLF-related parameters associated with the second link, these may include, for example, the number of consecutive DTX-to-HARQ transmissions experienced by the relay WTRU, the number of consecutive RLC retransmissions experienced by the relay WTRU, the number of OOS, or some value of a counter / timer related to RLF of the second link. For example, the relay WTRU may transmit a set of transmissions / retransmissions for which the relay WTRU failed and / or did not send HARQ feedback. The relay WTRU may determine the missed transmissions / retransmissions based on receiving a DAI (or the like) on the sidelink. The source WTRU may consider such lost transmissions in its RLF determination algorithm (e.g., subtract the number of DTX-to-HARQ). In another example, the relay WTRU may transmit the number of consecutive IS / OOS, the value of any counter, timer (e.g., T310), or the value of a measured duration to the source WTRU or the WTRU inter-network relay link. For example, the relay WTRU may transmit the value of T310 or the duration to be measured, may transmit an indication that the value of T310 has reached a threshold, or may transmit an indication that the duration has elapsed. With regard to identifiers used by the WTRU following reception of the LPIE, such identifiers may include, for example, source / destination L2 IDs, C-RNTI, A-RNTI, or any similar Uu or SL identifier.

[0119] The relay WTRU may create an SLRB for transmission to the source WTRU in response to link initiation by the source WTRU. For example, the relay WTRU may create an SLRB toward the source WTRU upon receiving a PC5-RRC message from the source WTRU. Alternatively or additionally, the relay WTRU may create an SLRB toward the source WTRU in response to an indication from higher layers that it will act as a relay WTRU for a particular source / destination L2 ID and / or receiving a source / destination routing table from higher layers. For example, such an SLRB may be used for transmitting an LPI in a secure manner.

[0120] In some embodiments, the WTRU may modify its link management decisions / actions as a function of receiving the LPI / LPRI and / or the contents (or a function of the contents) of the LPI / LPRI. For example, the WTRU may perform any or a combination of the following: trigger an RLF for the relayed link on which the LPI is received; pause, start, or resume HARQ feedback monitoring for the RLF; initiate a relay reselection procedure; modify / reset any counters associated with the HARQ feedback it monitors for the RLF associated with the relayed link; modify / change / select the conditions for triggering an RLF associated with the relayed link (e.g., change the number of consecutive HARQ DTX for an RLF); change the transmission path from one relay link (the link on which the LPI is received) to a different relay link, possibly determined after relay selection; or notify higher layers.

[0121] In some embodiments, the source WTRU may trigger an SL RLF following receipt of an LPI indicating an SL RLF. The source WTRU may delete all context associated with the PC5-RRC connection with the relay WTRU that sent the LPI and may notify upper layers of the SL RLF. In some embodiments, the source WTRU may initiate relay reselection following receipt of an LPI indicating an SL RLF on the second link. The source WTRU may possibly suspend transmissions to the relay WTRU that sent the LPI while the reselection is being performed. If the reselection is successful, the source WTRU may notify upper layers that the reselection was successful and / or may change the source / destination IDs of any SLRBs sent via the original relay WTRU to new source / destination IDs provided by upper layers, possibly following the reselection. If the reselection is unsuccessful, the source WTRU may instead trigger an SL RLF.

[0122] The source WTRU may determine / modify any aspect of its RLF determination mechanism based on the information in the LPI. In some embodiments, the WTRU may determine the maximum number of consecutive DTXs in response to an RLF-triggering HARQ-based transmission based on any or a combination of the following parameters reported in the LPI: The WTRU may, upon receipt of the LPI / LPRI, in response to the HARQ-based transmission that triggers the RLF, further change the maximum number of consecutive DTXs from a first value to a second value, and the following parameters are changed compared to the previous LPI / LPRI: the CR measured by the relay WTRU, the CBR measured by the relay WTRU, the amount of data in the relay WTRU buffer or the relay WTRU buffer occupancy (possibly associated with a single link or all relayed links), the degree of latency associated with the data in the buffer (potentially associated with the relaying of the data), the TX resource pool configuration of the relay WTRU (which may be the same as or different from the TX resource pool configuration of the source WTRU), the CQI on the second link received by the relay WTRU from its peer WTRU and further reported by the relay WTRU to the source WTRU, any degree of channel capacity / efficiency of the second link measured by the relay WTRU, and / or whether the transmission is to a relay WTRU or directly to a peer WTRU, and the number of hops associated with the relayed path. With respect to the degree of latency associated with the data in the buffer, for example, the WTRU may calculate an average latency metric for the data in that buffer by assigning a latency value to each packet (e.g., based on the LCH associated with that packet).

[0123] In some embodiments, the WTRU may set the number of consecutive DTXs to a first value if the CR measured by the relay WTRU is below a threshold, and may set the number of consecutive DTXs to a second value if the CR is above the threshold. In some embodiments, the WTRU may suspend counting HARQ-based DTXs for RLF determination upon reception of an LPI, possibly for a period of time, where such LPI includes values ​​of the parameters mentioned in the examples above that meet some configured or pre-configured criteria. In some embodiments, the WTRU may reset the number of HARQ-based DTXs counted upon reception of an LPI / LPRI (possibly if such LPI / LPRI includes values ​​of the parameters mentioned in the examples above that meet some configured or pre-configured criteria).

[0124] In some embodiments, the WTRU may declare RLF based on the number of HARQ-based DTXs counted over a configurable window. The WTRU may perform RLF in this manner only if the contents of the LPI satisfy some condition. For example, the WTRU may perform RLF in this manner only when the CR and / or buffer status reported by the relay WTRU is above a threshold. The WTRU may further determine the number of HARQ-based DTXs that trigger RLF and / or the window size based on such parameters in the LPI.

[0125] In some embodiments, the WTRU may ignore certain HARQ-based DTXs when counting consecutive DTXs according to some predefined algorithm or pattern, for example, the WTRU may skip counting every N DTXs when counting the number of consecutive DTXs, where N may further depend on parameters in the LPI.

[0126] In some embodiments, the WTRU may decide to deactivate a link (e.g., maintain the link for later activation and for receiving measurements, LPRI / LPI messages) or release the link based on one or more of the following: another active link to the same destination via a different relay, the QoS associated with the active bearer on the relayed link, and / or the presence of any information (e.g., CBR / CR / CQI) received in the LPI message itself.

[0127] For example, the WTRU may activate a second link to the same destination (e.g., via another relay WTRU) and / or deactivate a first link following receipt of the LPI message, potentially using information that meets any criteria similar to those described herein (e.g., for triggering an LPI message). For example, a WTRU receiving an RLF indication from a relay WTRU may respond to the relay WTRU with a deactivation message. The source WTRU may then perform relay reselection and / or activation of a different link to the same destination (via another relay). In another example, the WTRU may release a link if the QoS does not require multiple active links to the same destination and the WTRU successfully reselects another link to the destination and / or has another link to the same destination active at the time of receipt of the LPI.

[0128] In some embodiments, a WTRU (e.g., a source WTRU or a relay WTRU) may decide whether to perform relay reselection at the source WTRU or at the relay WTRU (e.g., following receipt of an LPI or a similar trigger for transmitting an LPI as described herein). For example, relay selection at the relay WTRU may involve introducing a larger number of hops in the overall end-to-end link. For example, relay selection at the source WTRU may have the advantage that it may not require an increased number of hops. The decision of which WTRU to perform relay reselection may be made by the source WTRU or the relay WTRU. The relay WTRU may itself be considered a source WTRU in a multi-hop environment.

[0129] In some embodiments, the decision may be made by the source WTRU based on information provided by the relay WTRU. In other embodiments, the decision may be made by the relay WTRU based on information provided by the source WTRU. The WTRU (source or relay) may make such a decision based on any or a combination of the following information (each such information may be provided by or related to other WTRUs, and / or may be determined independently by the WTRU or related to the WTRU itself): QoS or SLRB configuration; coverage requirements of the source WTRU and / or relay WTRU; synchronization sources of the source WTRU and / or relay WTRU (potentially synchronization sources that refer to the destination WTRU); location of the source and / or relay (potentially relative to each other or relative to another entity such as a Node B (e.g., a gNB) or the destination WTRU); CBR / CR / CQI / RSRP or similar measurements; the number of potential relay WTRUs determined based on a relay discovery procedure; a measured quality metric (e.g., RSRP measurement) or any function thereof (possibly compared to current relay quality) of one or several potential relay WTRUs determined based on a relay discovery procedure; the number of relay hops; and / or Uu RSRP measurement of the link between the last hop relay and the NW (in the case of a WTRU-network relay).

[0130] Regarding the QoS and / or SLRB configuration, for example, the SLRB configuration of any configured bearer may or may not allow the relay WTRU to perform reselection only under certain conditions. Regarding the range requirements at the source WTRU and / or relay WTRU, for example, reselection may not be allowed by the relay WTRU based on the range requirements and possibly the location of the relay WTRU. Regarding the synchronization source of the WTRU and / or relay WTRU, for example, reselection may be performed by the WTRU (remote or relay WTRU), thereby maintaining the current synchronization source or prioritizing synchronization to a WTRU having the same synchronization source as the relay WTRU or destination WTRU. Regarding the location of the source and / or relay, for example, the location may be determined based on a configured zone. Regarding the measurement quality criterion, the measurement quality criterion may include, for example, the maximum RSRP of any potential relay WTRU, an average value of the RSRP of some / all potential relay WTRUs, the RSRP of a potential relay WTRU being better than a first threshold while the RSRP of the current relay is worse than a second threshold, and / or the RSRP of a potential relay is somewhat better than the current relay WTRU.

[0131] In some embodiments, the relay WTRU may be configured or pre-configured with one or a set of conditions based on the above information (e.g., as measured at the relay WTRU) to determine whether to initiate resource reselection or notify the source WTRU to perform relay selection. For example, if the number of hops resulting from a reselection / reconfiguration to a reconfigured relay path to the destination falls below a QoS / SLRB-dependent threshold, the relay WTRU may perform relay reselection and / or reconfiguration of the second path following any trigger similar to the trigger for sending an LPI message. Otherwise, the relay WTRU may potentially send an LPI message to the source WTRU indicating that relay reselection needs to be performed at the source WTRU. Upon receiving the LPI message, the source WTRU may perform relay reselection.

[0132] In another example, the relay WTRU may perform relay reselection and / or reconfiguration of the second path following any trigger similar to the trigger for sending an LPI message if the RSRP of the selected relay exceeds a configured or pre-configured threshold. The relay WTRU in this example, or any reselection procedure, may further perform one of the following procedures. For example, the relay WTRU may notify the source WTRU (e.g., via an LPI or similar message) that the relay WTRU is performing relay reselection. For example, the source WTRU may buffer any traffic to the relay WTRU while the relay reselection is being performed. The relay WTRU may notify the source WTRU of the success or failure of the reselection performed by the relay WTRU. For example, the WTRU may provide the source WTRU with updated configuration and / or QoS information for the updated link to the destination, such as a new cell ID of the new cell to which the final hop relay WTRU is connected, a new number of hops to the destination, expected latency or other expected QoS over the new link to the destination, new bearer configuration or bearer mapping configuration or capability information associated with subsequent nodes (e.g., relays in the NW) along the new path, e.g., support for multi-carrier or support for full-duplex operation.

[0133] In another example embodiment, the relay WTRU / source WTRU may provide relay selection candidates to the source WTRU / relay WTRU in transmitting an LPI or in response to an LPI. The source WTRU / relay WTRU may determine whether to perform relay selection and / or instruct the relay WTRU / source WTRU to perform relay selection based on a comparison of measured quality metrics of its own candidate and other WTRU candidates. For example, the WTRU may determine that it should perform reselection if the candidate has a higher RSRP than other WTRU candidates. For example, the WTRU may decide to perform reselection if the candidate's RSRP is a better offset than other WTRU candidates, and such offset may depend on which WTRU (e.g., the source WTRU or the relay WTRU) makes the decision and / or any other factors mentioned in the information exchanged / used herein and / or in the LPI.

[0134] In some embodiments, the WTRU may determine the RLF based on a combination of several consecutive HARQ-based DTXs and receptions from a peer WTRU, where such receptions may be reception of an LPI or another transmission by the peer / relay WTRU. The source WTRU may determine that the transmission received by the peer WTRU is associated with the same source / destination ID as the source WTRU's own transmission, but with the source and destination IDs reversed. Alternatively or additionally, the source WTRU may determine that the reception by the peer WTRU is any reception received over a reverse control channel, as described in more detail herein.

[0135] In an example, the WTRU may reset the number of consecutive DTXs in the RLF determination upon receipt from a relay / peer WTRU. Such receipt may be an RLC buffer status, a flow control indication, a measurement indication, an LPI / LPRI, an RS transmission, a measurement report, or any data / control transmission. In another example, the WTRU may trigger RLF based on a combination of several consecutive HARQ-based DTXs and a time period reached without a reception from the relay WTRU. Such a time difference may further depend on the SLRB configuration and / or QoS.

[0136] In any of the examples described herein, successful reselection as a result of transmitting / receiving an RLF and / or LPI message may depend on performing all actions within a configured time or timer. The WTRU may start a timer, whereby the reselection procedure may fail if the timer expires before the associated action is completed, or the WTRU may determine that the reselection procedure may fail if a time period elapses after the associated action is completed. Such timers or durations may further depend on any one or a combination of QoS / SLRB configurations of one or more established services over relay and / or CBR. With regard to QoS / SLRB configuration, for example, the source / relay WTRU may be configured with a reselection timer or reselection duration associated with each SLRB. Upon triggering reselection, the WTRU may set the timer to the minimum value of the timers for each established SLRB, or may consider the duration to be the minimum value of the timers for each established SLRB. With regard to CBR, for example, the source / relay WTRU may be configured with a reselection timer or reselection duration associated with a range of CBR. Upon triggering reselection, the WTRU may set a timer to a value associated with the CBR measured at the time of the reselection trigger.

[0137] In any of the examples described herein, successful reselection may depend on the new relay supporting the SLRB configuration configured for the existing / old relay or a similar or equivalent configuration. Specifically, in some cases, a WTRU that triggers a relay reselection procedure to find a relay may select such a relay only if the relay supports the SLRB configuration (possibly for the SLRB configured for communication with the relay WTRU) configured prior to the reselection or an equivalent configuration.

[0138] In some embodiments, a WTRU triggering a relay reselection may perform the events (potentially in sequence) described in the following paragraphs.

[0139] The WTRU may initiate a relay selection procedure, which may include transmitting / receiving discovery and / or link establishment messages from higher layers. Alternatively or additionally, the WTRU may rely on existing discovery message transmissions for relay selection.

[0140] The WTRU may select the relay with the best RSRP measurement value as the potential relay WTRU. The WTRU may also use higher layer criteria (e.g., supported services) for relay selection (e.g., the higher layer service supports the relay with the best supported RSRP measurement value). The WTRU may determine whether to initiate a PC5-RRC configuration procedure with a peer WTRU (e.g., the selected potential relay WTRU). The WTRU may reuse the configuration of the bearer / PC5-RRC connection with the existing relay (e.g., the SLRB configuration for the relay) for the configuration included in the PC5-RRC connection with the potential selected relay and / or for the TX-related parameters of the SLRB configuration. The WTRU may send a PC5-RRC reconfiguration message using the L2 source / destination IDs provided by the higher layers (associated with the potential new relay WTRU sending the discovery message) and receive a response. Alternatively or additionally, the WTRU may use a default L2 source / destination ID pair for relay reselection transmissions, possibly also provided by the higher layers. Alternatively or additionally, the WTRU may use the L2 source / destination ID provided with the discovery message transmission / reception to the new potential relay for sending the PC5-RRC configuration message.Using the same / similar configuration may include using the same number of SLRBs, using the same configuration of one or more of the SLRBs or a subset of the parameters of the SLRBs, which may include TX-related parameters of the SLRBs and / or parameters of the SLRBs sent to the relay WTRU in a PC5-RRC reconfiguration message, using an equivalent configuration whereby such configuration is derived from the original configuration to take into account changes in any of the following characteristics of the new selected relay / path (such information may be provided, e.g., in a discovery message, prior to relay selection, or may be stored, e.g., from a previous session with that relay): differences in the number of hops between the old and new links, differences in the capabilities of the new relay (e.g., number of supported carriers), and / or differences in measurements reported by or by the new relay. An equivalent configuration may be configured or pre-configured for each configuration from the network.

[0141] If the PC5-RRC configuration procedure with the selected potential relay is successful, the WTRU may indicate a successful relay selection or reselection procedure to higher layers. The WTRU may further perform any one or a combination of the following subsequent actions: The WTRU may release the PC5-RRC context associated with the current relay WTRU. The WTRU may indicate to higher layers that the reselection to the relay WTRU was successful and indicate a source / destination ID identifying the relay WTRU. The WTRU may create a new PC5-RRC connection associated with the new relay WTRU, and / or the WTRU may replace the source / destination ID associated with the current relay with a new source / destination ID associated with the relay WTRU in the PC5-RRC context of the current relay.

[0142] The WTRU may perform any of the following actions, or any combination of the following subsequent actions, upon receiving a failure in the PC5-RRC configuration response message: The WTRU may restart the PC5-RRC reconfiguration procedure with another potential relay (e.g., potentially a relay WTRU with a suboptimal RSRP). For example, the WTRU may repeat the PC5-RRC configuration procedure with multiple potential selected relays, starting with the best RSRP measurement, until the PC5-RRC reconfiguration procedure is successful. In another example, the WTRU may repeat the PC5-RRC configuration procedure with any (e.g., randomly selected) potential relay WTRU whose RSRP measurement meets some criterion (e.g., above a threshold) until the PC5-RRC reconfiguration procedure is successful. In another example, the WTRU may repeat the PC5-RRC configuration procedure with different potential relays until all potential relays with measured RSRP above a threshold have been tried or until the PC5-RRC reconfiguration procedure is successful. In another example, the WTRU may repeat the PC5-RRC reconfiguration procedure with different potential relays until it determines that a timer of a given duration has expired, as described herein. Any combination of the conditions in the above examples is possible for the WTRU behavior when determining whether to restart the PC5-RRC reconfiguration procedure with another potential relay. The WTRU may indicate a reselection failure to higher layers upon exceeding a maximum number or maximum time associated with reselection and / or possibly after PC5-RRC reconfiguration with all potential relay WTRUs with RSRP above a threshold has failed.

[0143] FIG. 6 is a flow diagram of an example re-establishment or recovery procedure. As shown in 601 of FIG. 6, a remote WTRU may connect to a network via a sidelink interface with a WTRU-to-network relay. The remote WTRU may be configured with a set of alternative relays, as shown in 602, e.g., according to one or more other procedures described herein. If the remote WTRU determines that a SL RLF has occurred (e.g., according to one or more procedures described herein) while connected to a relay, as shown in 603, the remote WTRU may select a suitable relay, as shown in 604. As shown in FIG. 6, such a suitable relay may be the relay with the highest RSRP. Alternatively, or additionally, any suitable relay with a SL RSRP above a threshold may be selected. A suitable relay may be a relay provided by the network in a configured list. A suitable relay may be a relay with a measured SL RSRP higher than a threshold, satisfy some upper layer criteria associated with the discovery message, and have an acceptable PLMN. It should be appreciated that solutions according to embodiments not shown may involve selecting one or more suitable relays according to procedures described herein. As shown in 605, if all relays in the set of alternate relays configured for the remote WTRU are exhausted, e.g., if reconfiguration fails for all alternate relays or if a suitable alternate relay cannot be found, the remote WTRU may determine that recovery has failed. If a suitable alternate relay can be found and selected, the remote WTRU may send an SL reconfiguration message to the selected relay to configure one or more of the SLRBs at 606. The remote WTRU may use the same SLRB configuration (e.g., an SL RLC channel for transmitting SLRB1, such as all SL RLC channels) previously configured at the remote WTRU with the previous relay. At 607, the remote WTRU may determine whether the reconfiguration was successful, e.g., based on a response received from the selected alternate relay.For example, if the relay responds with a failure or if the remote WTRU does not receive a response, the remote WTRU may retry reconfiguration with a different suitable relay. The remote WTRU may retry such a procedure until the list of suitable relays is exhausted, or until a timer associated with relay reselection expires, or until a determined duration has elapsed. For example, if the reconfiguration for the newly selected relay is determined to be successful based on a response received from the newly selected relay, the remote WTRU may update its current relay with the new L2 ID of the newly selected relay at 608 and transmit a Uu Re-establishment Request message at 609 using its existing SL RLC channel for SRB1 transmission, except that the L2 ID may be changed for the new L2 ID. Specifically, the remote WTRU may maintain the same configuration of the SL RLC channel for transmission, replacing the L2 ID with the old relay as the new relay.

[0144] 6, provided recovery fails, the remote WTRU may delete its context, move to RRC_IDLE, trigger a relay reselection procedure, and / or trigger a cell reselection procedure. In an embodiment, relay reselection may result in a new or different set of suitable relays compared to the set of relays provided by the NW.

[0145] In some embodiments, a WTRU may perform relay selection or reselection and / or recovery (e.g., after an RLF) to a relay from a set of configured relay WTRUs provided by the network. Specifically, the WTRU may determine a relay WTRU to select, reselect, or recover from by selecting a WTRU in a list of WTRUs provided by the network. Such a list may be provided directly over Uu (e.g., while the WTRU is in coverage). Alternatively or additionally, such a list may be provided by RRC signaling sent via a currently connected relay WTRU. Upon detecting any condition defined herein (e.g., a SL RLF by a relay WTRU), the remote WTRU may select one of the relays in the list of relays provided by the network based on any or a combination of relay measurements at the time of reselection or recovery, ordering and / or priority associated with each relay, and / or the remote WTRU's current location. For example, the remote WTRU may select the relay WTRU on the list with the highest RSRP for the relay measurements or reselection or recovery at that time. In another example, the remote WTRU may select any relay WTRU with an acceptable RSRP (e.g., RSRP above a threshold). With regard to the ordering and / or priority associated with each relay, for example, the remote WTRU may receive a preference and / or priority associated with each relay and may perform reselection / recovery to the relay WTRU associated with the highest priority. In another example, the remote WTRU may further combine other factors described herein (e.g., relay RSRP measurements) with such priority to determine a relay. With regard to the remote WTRU's current location, for example, the network may provide a set of allowed locations (e.g., zone IDs) for each relay WTRU, and the remote WTRU may select the relay associated with its current WTRU location (e.g., its current zone ID).

[0146] The WTRU may further receive from the network an SL configuration (PC5-RRC) to be used with each such relay WTRU upon recovery / reselection. Specifically, the remote WTRU may receive, via another relay WTRU, a PC5-RRC configuration applicable to recovery of the RRC CONNECTION. Such PC5-RRC configuration may be used to communicate with the reselected relay upon the occurrence of any trigger / event (e.g., SL-RLF) described herein.

[0147] The WTRU may initiate recovery for a relay WTRU for which the WTRU has a stored PC5-RRC configuration by sending an initial activation message over the SL, whereby such activation message may include one or more of a dedicated activation PC5-RRC message, an SL MAC CE, or an SCI addressed to the L2 destination ID of the new relay, transmission of any UL or SL data that allows the WTRU to change the L2 destination ID to that of the new relay, and / or a dedicated activation or normal UL or SL transmission to the recovery L2 destination ID or a special L2 destination ID configured in the remote WTRU for recovery. Upon receiving such a message, the relay WTRU may activate its similarly stored configuration for reception / transmission to the remote WTRU.

[0148] A WTRU may be considered to be connected to the network via a WTRU inter-network relay if it has a PC5-RRC connection to the WTRU inter-network relay (e.g., the WTRU is a relay or has a PC5-RRC context that is determined to be specific to a relay). Specifically, the WTRU may stop performing a subset of procedures to the network and be considered to be connected via a relay in response to one or more of an indication from higher layers that a PC5-link with the relay WTRU has been initiated and / or receiving a PC5-RRC message indicating a connection for a relay. For example, the WTRU may receive a PC5-RRC reconfiguration message that includes an indication that a configuration is associated with a WTRU connection to an inter-network relay. In another example, the WTRU may receive a PC5-RRC reconfiguration message that implicitly indicates a reconfiguration of the PC5-RRC connection for the relay due to the content of the message. The PC5-RRC configuration message from the relay WTRU may include any of the following: configuration for the adaptation layer, configuration for mapping Uu QoS flows / bearers to SL protocol (e.g., RLC) entities / bearers, mapping of Uu QoS entities to SL QoS entities, configuration for the Uu protocol layer (e.g., PDCP / SDAP), configuration / conditions for returning to Uu, and / or configuration for monitoring Uu while connected to the WTRU inter-network relay (including PDCCH configuration, Uu RLF configuration, and / or CQI reporting configuration). For example, the WTRU may receive a PC5-RRC message with an embedded Uu RRC reconfiguration message that configures certain aspects of the Uu connection, as described herein.

[0149] Upon connecting to an inter-network relay, such a WTRU may stop performing some procedures to the Uu. For example, the WTRU may stop monitoring the RLF (legacy RLF) over the Uu and initiate a relay-based link monitoring procedure with the relay WTRU. The WTRU may also perform a new or limited RLF procedure with the network (over the Uu) as described herein. In another example, the WTRU may stop receiving system information from the network and receive system information from a relay WTRU. In another example, the WTRU may stop monitoring paging and receive paging from a peer WTRU. In another example, the WTRU may stop monitoring the PDCCH from the network for DL ​​assignments and UL grants. Alternatively or additionally, the WTRU may perform some limited PDCCH monitoring as described herein. In another example, the WTRU may suspend all DRBs. In another example, the WTRU may replace some or all DRBs with corresponding relayed DRBs. In another example, the WTRU may create relayed DRBs corresponding to Uu DRBs, which may be suspended.

[0150] A WTRU connected via a WTRU inter-network relay may trigger a relay RLF procedure upon detection of an RLF associated with the WTRU inter-network relay. Such detection may be as a result of any of the triggers described herein.

[0151] When the WTRU triggers an RLF associated with a WTRU inter-network relay, it may perform any one or any combination of the following actions: For example, the WTRU may release the PC5-RRC context associated with the WTRU inter-network relay. The WTRU may release protocol entities (e.g., adaptation layers) for routing between SL and Uu. The WTRU may release SL bearers (e.g., signaling and / or data SL bearers). If the WTRU is in network coverage or has not triggered an RLF with respect to the network, the WTRU may restore its Uu context, including any suspended Uu bearers. If the WTRU is in network coverage or has not triggered an RLF with respect to the network, the WTRU may release the routing of the Uu bearers over the SL bearers / channels and resume transmission of the WTRU's Uu QoS flows or transmit data from the WTRU's Uu QoS flows over the Uu bearers. If the WTRU is in network coverage, the SDAP and / or PDCP layer of the WTRU may reroute QoS flows / bearers from SL to Uu. The WTRU may initiate WTRU inter-network relay reselection. If the WTRU is in network coverage or has not triggered RLF with respect to the network, the WTRU may resume normal Uu procedures that were interrupted when the WTRU connected to the inter-network relay. If the WTRU is in network coverage or has not triggered RLF with respect to the network, the WTRU may perform network access procedures as described herein. If the WTRU is in network coverage or has not triggered RLF with respect to the network, the WTRU may start decoding PDSCH for transmission by the network. If the WTRU is in network coverage or has not triggered RLF with respect to the network, the WTRU may resume any interrupted Uu radio bearers.

[0152] In some embodiments, a WTRU connected to a WTRU inter-network relay may initiate a link monitoring procedure based on receiving a discovery from a connected relay WTRU. The WTRU may further determine which reception to use for link monitoring based on an indication in the SCI (e.g., if the SCI includes an indication that the associated data includes a discovery transmission) or based on an indication in the MAC header (e.g., if the MAC header indicates data for a logical channel associated with discovery). Specifically, the remote WTRU may perform RSRP measurements on the discovery transmission by the relay WTRU and determine whether to declare RLF based on the measured RSRP and / or perform a BLER calculation based on the RS received in the discovery transmission and possibly further. With respect to performing RSRP measurements, for example, the WTRU may declare RLF for the relayed connection if the RSRP of the relay discovery transmission falls below a threshold, possibly for a period of time. In another example, the WTRU may declare RLF for the relayed connection if the RSRP of the relay discovery transmission changes by at least a threshold and possibly remains unchanged for a period of time. Regarding performing the BLER calculation, for example, the WTRU may determine the PSCCH BLER from the RS received in an SCI associated with / containing the discovery message (e.g., an SCI indicating a discovery transmission). The WTRU may count the number of consecutive OOS (e.g., BLER below a threshold) events and start an RLF timer when the number of OOS reaches a certain value, or in other words, the WTRU may determine whether the duration associated with the RLF has elapsed. If the timer expires without some recovery event (e.g., BLER above a threshold) or if the duration has elapsed, the WTRU may trigger an RLF.The WTRU may further determine the periodicity of IS / OOS determinations and / or indications to higher layers based on the configured discovery transmission period of the WTRU or relay (e.g., obtained via PC5-RRC).

[0153] In some embodiments, the WTRU may perform monitoring of the PDCCH while connected to the relay WTRU. Such monitoring may be periodic and / or sparse. This may minimize power consumption associated with PDCCH monitoring. For example, the WTRU may perform some DRX-like monitoring of the PDCCH while connected to the relay WTRU. For example, the WTRU may monitor the PDCCH on one or more slots with a configured or preconfigured periodicity.

[0154] In some embodiments, the WTRU may be configured to enable / start DRX with the NW when a connection with the WTRU inter-network relay is initiated. The WTRU may receive such a configuration for DRX from the network prior to connecting with the WTRU inter-network relay (e.g., via SIB or dedicated RRC signaling). Alternatively or additionally, the WTRU may enable DRX upon receiving a DRX configuration via the relay WTRU (e.g., over PC5-RRC) following establishment of a PC5-RRC connection with the relay WTRU.

[0155] The WTRU may be configured to receive a wakeup signal (WUS) that can control monitoring of the PDCCH versus the PSCCH. For example, the WUS may determine whether to monitor the PDCCH instead of the PSCCH (or vice versa) for a certain period of time (e.g., a DRX cycle). For example, the WTRU may monitor the WUS over Uu at a configured or preconfigured time. If a WUS is detected, the WTRU may monitor the PDCCH for a DRX cycle. Otherwise, as in some embodiments, it may skip the DRX cycle and continue to monitor only the SL.

[0156] The WTRU may determine the intensity of PDCCH monitoring while connected to the WTRU inter-network relay based on measurements / criteria associated with the PC5-RRC connection with the relay WTRU. For example, the intensity of PDCCH monitoring may include any of the periodicity of PDCCH monitoring, the bandwidth or PDCCH monitored, the number of consecutive slots monitored per period, and / or the search space associated with the monitored PDCCH.

[0157] The WTRU may determine the intensity of PDCCH monitoring based on either the measured and / or reported RSRP on the SL to the relay WTRU and / or the value of any parameter, the counter of a timer related to the SL RLF, or the expiration of a duration related to the SL RLF. For example, with respect to the measured and / or reported RSRP on the SL to the relay WTRU, the WTRU may be configured or pre-configured with a mapping between the measured / reported RSRP range and the periodicity of PDCCH monitoring. The remote WTRU may be configured to report SL RSRP measurements to the relay WTRU. The relay WTRU may then forward such RSRP measurements to the network. Alternatively or additionally, the relay WTRU may send RSRP measurements (or an indication of the level of such measurements) only when such measurements change from a first level to a second level corresponding to a change in the intensity of the remote WTRU's PDCCH monitoring. With respect to any parameter, counter, timer, or duration value associated with the SL RLF, for example, the WTRU may be configured with a PDCCH decoding strength for when a timer such as T310 associated with SL link monitoring is running or the duration associated with SL link monitoring has not expired, and another PDCCH decoding strength for when a timer such as T310 is not running or the duration associated with SL link monitoring has expired. For example, the WTRU may be configured with a PDCCH decoding strength for when the number of HARQ-DTX (either continuous or within a window) is below a threshold and when the number of HARQ-DTX (either continuous or within a window) is above a threshold.

[0158] The WTRU may trigger the relay RLF procedure on any of the following conditions relayed to be received over Uu: reception of scheduling on the PDCCH (e.g., a DCI scheduled using the WTRU's C-RTNI or a new RNTI indicating resumption of NW-based scheduling), which may be for UL and / or DL ​​data transmission over Uu; reception of an RRC message resuming Uu-based (e.g., non-relay) operation, which may be received directly over the Uu link; reception for a MAC CE over Uu; reception by the WTRU at a configured Uu monitoring occasion; and / or an explicit indication from the network in any of the above signaling mechanisms (e.g., an RRC message with an explicit indication to trigger an SL RLF or a WUS with an explicit indication to trigger an SL RLF). Regarding reception of an RRC message resuming Uu-based operation, for example, the WTRU may suspend all Uu DRBs and maintain SRBs when connected to the WTRU inter-network relay. The WTRU may trigger the relay RLF and resume the DRB when it receives an RRC message from the network over the SRB via Uu.

[0159] The WTRU may perform RLF-like operations on Uu and SL simultaneously. The WTRU may notify the network of an RLF on one of the links via the other link. For example, upon detecting an SL RLF with the relay WTRU, the remote WTRU may perform an access procedure, which may include either performing a RACH procedure (potentially if the TAT has expired) and / or transmitting an RRC message such as SLUEInformation, RRCResume, or UEAssistanceInformation, or another logically equivalent message. The WTRU may further indicate the occurrence of an SL RLF in such a message. Upon detecting a Uu RLF, the WTRU may notify the network of such an RLF via transmitting a Uu RRC message via the relay WTRU (e.g., encapsulated in PC5-RRC).

[0160] The WTRU may trigger a re-establishment procedure following an RLF while connected to a WTRU inter-network relay. In such a procedure, the WTRU may indicate the relay WTRU (e.g., L2 source / destination ID) in a re-establishment request message. If the WTRU detects a Uu RLF and / or failed re-establishment, the WTRU may operate as if it were out of coverage.

[0161] In some embodiments, the WTRU may release the PC5-RRC connection (e.g., release all context associated with the PC5-RRC connection with the relay and notify higher layers) upon either reselection to a cell where the existing relay is not supported, receipt of a re-establishment response, and / or a Uu RLF resulting in any re-establishment procedure. For a Uu RLF resulting in reselection to a cell where the existing relay is not supported, for example, the WTRU may be configured or pre-configured with a set of relays that can be used on the cell, and the WTRU may trigger a PC5-RRC release if the selected cell does not support the current relay WTRU. For receipt of a re-establishment response, for example, the WTRU may receive an instruction to release the PC5-RRC connection in the re-establishment response message. For any re-establishment procedure, for example, the WTRU may be configured to release the PC5-RRC connection upon triggering a Uu re-establishment procedure.

[0162] In some embodiments, a remote WTRU may be connected to a relay WTRU and configured to perform Uu CSI measurements when within coverage of the network. The remote WTRU may transmit the CSI measurements to the relay WTRU. In addition, the relay WTRU may be configured to forward the received CSI measurements to the network.

[0163] The remote WTRU may be configured to measure CSI over Uu by RRC signaling (e.g., directly over Uu or via RRC encapsulated in PC5-RRC). Alternatively or additionally, the remote WTRU may be configured with conditions for measuring / transmitting CSI measurements based on any or a combination of the relay WTRU's measured quality, the quality measured over Uu, the presence of another relay, the remote WTRU and / or relay WTRU's location, and / or QoS and / or other bearer configurations. With respect to the relay WTRU's measured quality, for example, the remote WTRU may perform / transmit Uu CSI measurements when the relay RSRP is below a threshold. In another example, the remote WTRU may perform / transmit Uu CSI measurements when the relay RSRP is between a first threshold and a second threshold. In another example, the remote WTRU may perform / transmit Uu CSI measurements when the relay RSRP changes by a certain amount. With respect to the quality measured over Uu, for example, the remote WTRU may perform / transmit Uu CSI measurements when the Uu RSRP is above a threshold. In another example, the remote WTRU may perform / transmit Uu CSI measurements when the Uu RSRP is between a first threshold and a second threshold. Regarding the presence of another relay, for example, the remote WTRU may perform / transmit Uu CSI measurements when there are no other detected potential relays whose measured RSRP is above a threshold. Regarding the location of the remote WTRU and / or relay WTRU, for example, the remote WTRU may be configured with a set of zones for which it should report CSI measurements. For example, the remote WTRU may report CSI measurements based on the relay WTRU's reported zones, possibly in combination with the remote WTRU's own location (e.g., if the distance exceeds some configured or pre-configured value or some function of a QoS parameter (e.g., a range parameter)).With respect to QoS and / or bearer configuration, for example, the remote WTRU may decide to report CSI measurements based on the QoS of the data being transmitted or based on some configuration aspect related to the currently configured / established bearer.

[0164] The remote WTRU may send the network CSI measurements to the relay WTRU via a MAC CE or a logically equivalent message. Alternatively or additionally, the remote WTRU may send the network CSI measurements to the relay via a PC5-RRC message. Alternatively or additionally, the remote WTRU may send the network CSI measurements in a Uu RRC message encapsulated within a PC5-RRC message, or any logically equivalent message.

[0165] In some embodiments, the remote WTRU may send CSI measurements to the relay WTRU via a MAC CE. The remote WTRU may determine the time requirement for the CSI measurement based on one or a combination of being configured by the network, the speed of the remote WTRU, the CBR / CR measured at the remote WTRU and / or indicated by the relay WTRU, and / or flow control indication / information provided by the relay WTRU. The remote WTRU may drop the CSI measurement if the time from the trigger of the CSI measurement exceeds a threshold.

[0166] The remote WTRU may include in the CSI measurement report / CQI report the CQI, the trigger type (e.g., periodic vs. event-based CQI reporting), a priority indication, and / or a timestamp corresponding to the time when the Uu CSI measurement was triggered. With regard to the priority indication, for example, the remote WTRU may set the priority indication based on the trigger that generated the CQI report (e.g., periodic vs. event-based CQI reporting). For example, the remote WTRU may set the priority indication based on the time between when the CSI measurement is triggered and when the CQI report is constructed / transmitted.

[0167] In some embodiments, the relay WTRU may transmit CSI measurements from one or more remote WTRUs to the network, e.g., the relay WTRU may transmit a MAC CE or RRC message (or another logically equivalent message) to the network that includes CQI measurements received from one or more remote WTRUs.

[0168] In some embodiments, the relay WTRU may send a MAC CE or logically equivalent message containing CSI reports from one or more remote WTRUs. Such a message may include the CQI and / or the destination ID of the remote WTRU to which the CQI belongs.

[0169] The relay WTRU may assign a fixed or pre-configured priority to the CQI MAC CE or equivalent CQI message. Alternatively or additionally, the relay WTRU may determine the priority of the CQI MAC CE based on one or more of a timestamp received from the remote WTRU for the associated CQI, a priority received from the remote WTRU associated with the CQI, and / or a trigger type for the SL CQI.

[0170] The relay WTRU may trigger the MAC CE to forward CSI measurements upon receipt of any Uu CQI report from any remote WTRU and / or upon expiration of a timer, which may be started upon receipt of a Uu CQI report from any remote WTRU. For example, the relay WTRU may set such a timer if it is not running upon receipt of a Uu CQI report from a remote WTRU. The relay WTRU may trigger transmission of the remote WTRU's CSI measurements along with any other CQI reports received (possibly from other WTRUs) while the timer is running. The relay WTRU may also transmit the CQI report immediately upon receipt (e.g., before expiration of a running timer or before its duration has elapsed) based on some condition associated with the received CQI report (e.g., upon receipt of a CQI report with particular values ​​for trigger type, priority indication, and / or timestamp).

[0171] In some embodiments, the WTRU may store a Uu configuration along with the cell to which the WTRU is connected upon establishment of a WTRU inter-network relay connection. The WTRU may reuse such a stored configuration as part of a recovery procedure triggered based on any condition described herein (e.g., when the relay link fails). Alternatively or additionally, the WTRU may have multiple stored candidate Uu cell configurations with different cells. The WTRU may receive such candidate cells via dedicated RRC signaling over Uu and / or via a relay WTRU. The WTRU may also reuse such stored configuration as part of a recovery procedure.

[0172] The stored candidate Uu cell configuration may be explicitly configured for recovery when the WTRU is connected to an inter-network relay. Additionally or alternatively, the candidate Uu cell configuration may be configured for the WTRU for other purposes while the WTRU is connected via Uu (e.g., a conditional handover (HO) candidate cell or a conditional PSCell change candidate cell).

[0173] The WTRU may determine the validity of the stored Uu candidate configuration based on any of the relay WTRUs to which the remote WTRU was connected before the recovery action and / or one or more identifiers broadcast by the relay WTRU or broadcast by the network but relayed by the relay WTRU. For a relay WTRU to which the remote WTRU was connected before the recovery action, for example, the remote WTRU may be configured with an association between the stored Uu candidate configuration and one or more relay WTRUs (e.g., identified by a WTRU ID such as a destination ID, C-RNTI, or similar / new ID). The remote WTRU may consider a stored Uu candidate configuration valid for recovery if the relay WTRU to which the WTRU was connected when recovery was triggered is associated with such a candidate configuration. For example, the remote WTRU may receive a list of valid stored candidate cells from the relay WTRU, and the WTRU may consider the stored configuration for each cell valid when recovery is triggered following connection to that relay WTRU. With respect to one or more identifiers broadcast by the relay WTRU or broadcast by the network but relayed by the relay WTRU, for example, the remote WTRU may receive the identifiers from the relay WTRU (either directly, such as via PC5-RRC, or indirectly by forwarding a Uu RRC message or IE from the network). The remote WTRU may further be configured with a set of valid cell configurations for a given identifier, or a set of identifiers that should be received in order for a cell configuration to be considered valid for recovery while connected to that relay. For example, such an identifier may correspond to a RAN area ID relayed by the relay WTRU in the system information.

[0174] The remote WTRU may delete stored Uu candidate configurations / cells upon reselection to a relay WTRU where such stored candidate configurations / cells are invalid. Alternatively or additionally, the WTRU may store all configured candidate configurations, but only consider one or more valid stored cell configurations as part of the recovery procedure.

[0175] The WTRU may perform a recovery procedure over Uu (e.g., a CHO procedure or the like) using the stored Uu configuration following any SL-related condition that triggers recovery, as described herein. The WTRU may further perform such a recovery procedure in response to any or a combination of the following conditions: the WTRU performs cell reselection to a cell with a valid stored Uu candidate configuration, the cell to which reselection is performed has a particular quality (e.g., RSRP above a threshold), and / or the WTRU detects a cell with a particular quality (e.g., RSRP above a threshold) that has a stored valid Uu candidate configuration.

[0176] In some embodiments, the WTRU may prioritize cells with stored valid candidate configurations when performing recovery. If any or all of the above conditions do not exist, the WTRU may skip any recovery procedures and perform normal re-establishment procedures.

[0177] The cell selection / relay selection procedure may depend on factors associated with the re-establishment trigger, such as Uu measurements at the time of re-establishment, such as Uu RSRP, SL measurements, such as CBR, whether one procedure is being triggered or was already triggered at the start of re-establishment, support for relaying by the cell for which re-establishment is being triggered (e.g., the cell originates from a relay-capable NodeB, e.g., a gNB), and the QoS associated with the currently active bearer or any configuration of the bearer / LCH.

[0178] A remote WTRU may trigger a cell selection or relay selection procedure when connected directly over Uu and / or when connected via a relay WTRU. Such a cell / relay reselection procedure may be associated with a trigger that typically triggers Uu re-establishment in Uu. For example, when a remote WTRU triggers a Uu RLF, it may initiate a re-establishment procedure taking into account a possible relay WTRU. Such a new re-establishment procedure may start with the initiation of a cell reselection and / or relay selection procedure. Either cell reselection or relay reselection or both may be initiated.

[0179] The remote WTRU may perform the cell selection, cell reselection, relay selection, and / or relay reselection procedures sequentially (e.g., perform one first, then the other). In such a case, the remote WTRU may determine the order of such procedures. Alternatively or additionally, the remote WTRU may perform the two procedures in parallel. For example, the remote WTRU may initiate re-establishment towards the relay WTRU or directly towards the cell, depending on whether the relay reselection procedure or the cell reselection procedure completed first (and provided a suitable cell / relay).

[0180] The WTRU may decide whether to perform neither cell selection nor relay selection, either cell selection and relay selection, or both cell selection and relay selection, and / or which to perform first, based on any or a combination of the following factors: whether the current cell supports relay configuration (e.g., whether the relay is capable of broadcasting relay-specific information that may be associated with the L2 relay, e.g., in the relay's SIB); whether the WTRU is PC5-RRC connected to a relay WTRU; whether the remote WTRU is connected via Uu or via a relay WTRU; whether the WTRU has already initiated a relay reselection procedure (e.g., due to another trigger such as Uu RSRP or as a result of some explicit / implicit instruction by the network to initiate such a reselection); current Uu RSRP measurements (e.g., with respect to thresholds); network configuration; and / or SL measurements.

[0181] Regarding whether the current cell supports relay configuration, for example, if the current cell supports relay configuration, the remote WTRU may initiate relay selection as part of the re-establishment procedure (e.g., before or after cell selection). Regarding whether the WTRU is PC5-RRC connected to a relay WTRU, for example, if the remote WTRU is PC5-RRC connected to a relay WTRU at the time of the trigger (e.g., Uu RLF), the remote WTRU may not perform either cell selection or relay selection. In another example, if the remote WTRU is not PC5-RRC connected to a relay WTRU at the time of the trigger (e.g., Uu RLF), the remote WTRU may initiate relay selection.

[0182] With regard to whether the remote WTRU is connected via Uu or via a relay WTRU, for example, when the remote WTRU triggers a re-establishment procedure while connected via a relay, it may perform cell reselection before relay reselection (or vice versa). In some cases, the remote WTRU may only perform relay selection (and not cell selection) when connected via a relay (or vice versa). With regard to whether the WTRU has already initiated a relay reselection procedure (e.g., due to another trigger such as Uu RSRP or as a result of some explicit / implicit instruction by the network to initiate such a reselection), if the remote WTRU has already initiated a relay reselection procedure, the remote WTRU may not trigger either a cell / relay reselection procedure or may only trigger a cell reselection procedure. Otherwise, as in some cases, the remote WTRU may trigger relay reselection or both procedures. For example, the remote WTRU may trigger relay reselection when Uu RSRP falls below a threshold and / or when the network sends an instruction to trigger reselection. Such one or more triggers may occur before the initiation of re-establishment. If a suitable relay is already found before the re-establishment trigger, the remote WTRU may not trigger cell reselection and / or relay reselection. If the remote WTRU has a PC5-RRC connection to a suitable relay, the remote WTRU may not trigger cell reselection and / or relay reselection.

[0183] With regard to determining whether to perform cell selection or relay selection, neither, either, or both, and / or which to perform first based on the current Uu RSRP measurement, for example, if the Uu RSRP measurement is below a threshold when the RLF is triggered, the remote WTRU may trigger relay selection before cell selection. Otherwise, the remote relay may trigger cell selection before relay selection. For example, if the Uu RSRP measurement is below a threshold when the RLF is triggered, the remote WTRU may trigger relay selection in addition to cell selection. Otherwise, the remote WTRU may trigger cell selection only.

[0184] For example, the remote WTRU may be configured with a cell selection / relay selection order, with respect to determining whether to perform neither cell selection nor relay selection, either one or both, and / or which one to perform first based on network configuration. Such configuration may be explicit (e.g., an indicator in the SIB or a dedicated RRC) or may be tied to another network configuration aspect based on some rule. For example, the WTRU may be configured with bearers / QoS flows for which it should initiate one or the other selection procedure, which may be in a particular order.

[0185] For example, with regard to determining whether to perform neither, either, or both cell selection or relay selection and / or which to perform first based on SL measurements, the remote WTRU may perform cell selection only or perform cell selection before relay selection if the measured CBR is above a threshold, otherwise the remote WTRU may perform both cell selection and relay selection or perform relay selection before cell selection.

[0186] The remote WTRU may use a single timer (e.g., similar to T311) for both cell selection and relay selection, or may determine whether a duration has elapsed. For example, the remote WTRU may start a timer (T3XX) upon re-establishment trigger and may move to RRC_IDLE if it fails to find either a suitable cell or a suitable relay before the duration has elapsed. The value of the T3xx timer or duration may depend on whether the WTRU is configured to perform both cell selection and / or relay selection. For example, the remote WTRU may use a first timer or duration when configured to perform cell selection only, a second timer or duration when configured to perform relay selection only, and a third timer or duration when configured to perform both cell selection and relay selection. Furthermore, the remote WTRU may use different timers or durations depending on whether cell selection and relay selection are performed in parallel or sequentially, based on the conditions described herein.

[0187] In some embodiments, the remote WTRU may be configured with separate timers or durations for cell selection and relay selection. For example, the remote WTRU may trigger relay selection upon expiration of T311 (e.g., a failed cell selection procedure) or when it determines that the duration has elapsed. Alternatively or additionally, the remote WTRU may trigger cell selection upon expiration of a relay selection-related timer (T3yy) or when it determines that the duration associated with relay selection has elapsed.

[0188] Once the remote WTRU selects a cell or a relay (depending on which is found first), it may stop a timer such as T311. Alternatively or additionally, the remote WTRU may continue a timer such as T311 until it selects / finds both a relay and a cell. For example, if the remote WTRU finds a cell when T311 starts and T311 has not expired, the remote WTRU may determine that the duration has not elapsed and the remote WTRU may initiate / continue relay selection until a suitable relay is also found. Alternatively or additionally, if a timer or duration such as T311 expires, the remote WTRU may initiate re-establishment to a suitable cell upon expiration of the timer or duration.

[0189] The remote WTRU may be associated with different parameters for cell / relay reselection depending on factors associated with the re-establishment trigger. For example, such parameters may include RSRP thresholds (e.g., Uu threshold for cell suitability or SL RSRP threshold for relay suitability). For example, the remote WTRU may use different thresholds or apply offsets to such thresholds depending on factors mentioned herein.

[0190] For example, the remote WTRU may determine such a threshold based on a current Uu RSRP measurement, e.g., the remote WTRU may set the SL RSRP threshold for determining whether relaying is appropriate to a higher value when the Uu RSRP is higher when the Uu RLF / re-establishment is triggered.

[0191] In some examples, the remote WTRU may perform re-establishment to a predetermined / selected relay. In response to one or more triggers for re-establishment (e.g., Uu RLF, SL-RLF), the remote WTRU may perform re-establishment to a predetermined or pre-defined relay WTRU. For example, the remote WTRU may immediately perform re-establishment to a relay WTRU without a relay selection procedure and / or a cell selection procedure. The relay WTRU may be determined based on network signaling / configuration, based on an existing PC5-RRC connection, based on measurements reported to the network, and / or based on a previous relay selection procedure.

[0192] With regard to determining a relay WTRU based on NW signaling / configuration, for example, the remote WTRU may be provided with one or more relay WTRUs in a Uu RRC message (or another logically equivalent message) and may perform re-establishment with any of the one or more provided relay WTRUs. With regard to determining a relay WTRU based on an existing PC5-RRC connection, for example, the remote WTRU may perform re-establishment with the relay WTRU if it is already PC5-RRC connected to the relay WTRU.

[0193] With regard to determining the relay WTRU based on measurements reported to the network, for example, the remote WTRU may be configured with RRM-like measurements of SL relays, and the remote WTRU may trigger re-establishment directly for relay WTRUs that are in the list of relays reported by the WTRU to the network in the reported measurements.

[0194] With regard to determining the relay WTRU based on a previous relay selection procedure, for example, if the remote WTRU has already selected a suitable relay, the remote WTRU may initiate re-establishment to the relay without performing cell / relay reselection.

[0195] The remote WTRU may perform re-establishment via a relay or directly via Uu. In one example, the WTRU may decide to perform re-establishment based on a first suitable entity (e.g., a cell or a relay) determined at the remote WTRU. For example, the remote WTRU may perform both cell selection and relay selection simultaneously and select a first suitable entity to initiate re-establishment. For example, the remote WTRU may be configured with an order for performing cell selection versus relay selection. For example, if the remote WTRU performing relay selection finds a suitable relay (e.g., SL RSRP is above a threshold, meets higher layer criteria, and the relay is connected to an allowed PLMN for the remote WTRU) before the remote WTRU performing cell selection finds a suitable cell (e.g., Uu RSRP is above a threshold and an allowed PLMN), the remote WTRU may initiate re-establishment via the relay.

[0196] In another example, if both a relay and a cell are determined to be suitable, the WTRU may be configured with a preference / priority for re-establishment via relay or direct. For example, if both a suitable relay and a suitable cell are selected, the remote WTRU may select one of them based on priority. If the remote WTRU is configured with direct as a higher priority than via relay (or vice versa), it may re-establish via direct. The remote WTRU may prioritize re-establishment via direct if it was previously connected via direct. The remote WTRU may prioritize re-establishment via relay if it was previously connected via relay. The remote WTRU may re-establish via direct if the selected cell is a conditional handover candidate configured in the WTRU. Otherwise, as in some embodiments, the remote WTRU may use other selection rules described herein. The remote WTRU may re-establish via relay if the relay WTRU is connected to a cell that is a conditional handover candidate for the remote WTRU.

[0197] The remote WTRU may be configured with different values ​​for the re-establishment timer or duration for re-establishment, and the remote WTRU may decide which timer or duration to use depending on factors associated with the re-establishment. For example, the remote WTRU may determine the value or duration of the re-establishment timer (T301) depending on the following factors: whether the re-establishment is performed via a relay or via direct (Uu), whether the re-establishment is triggered when an existing PC5-RRC connection with the relay exists or whether the remote WTRU needs to establish such a PC5-RRC connection before being able to send the re-establishment via the relay, whether the network previously provided one or more relays that could be used for the re-establishment, and / or whether the remote WTRU performs the re-establishment using a single hop or a multi-hop relay. For example, a relay WTRU may announce the number of hops in a discovery message, and the remote WTRU may select the value or duration of T301 based on the announced number of hops.

[0198] The remote WTRU may include in the re-establishment request message the identity of the relay WTRU to which the remote WTRU was previously connected, the identity of the relay WTRU to which the remote WTRU was previously connected, and / or an indication of whether re-establishment was triggered when the remote WTRU was connected via Uu or via a relay. For example, the remote WTRU may include an explicit indication of the previous connection interface. For example, the remote WTRU may use different re-establishment cause values ​​to indicate that the failure that triggered re-establishment occurred while directly connected via Uu or while connected via a relay.

[0199] The relay WTRU can determine the cause values ​​(establishment cause, resumption cause, re-establishment cause) to be included in its own connection establishment / resumption / re-establishment signaling with the network. The relay WTRU can use dedicated cause values ​​for relay WTRU connection establishment / resumption resulting from a remote WTRU attempting to access the network. Alternatively, the relay WTRU can reuse some of the existing cause values ​​currently defined for both its own access as well as access attempts initiated by a remote WTRU.

[0200] In an embodiment, the relay WTRU may determine a cause value for its own establishment / re-establishment / resume operation based on properties or characteristics of the remote WTRU's own transmissions. Such remote WTRU transmissions may be further associated with, for example, a transmission that initiated the connection by the relay WTRU. Such properties or characteristics may include any or a combination of the RLC channel on which data is received from the remote WTRU, a Uu RRC message / procedure triggered by the remote WTRU, a subset of resources (e.g., time or frequency) on which data is received from the remote WTRU, and / or explicit signaling from the remote WTRU.

[0201] With respect to the RLC channels over which data is received from the remote WTRU, for example, the relay WTRU may be configured, pre-configured, or pre-defined to use a first cause value for connection establishment / re-establishment / resumption triggered by receipt of data from a first RLC channel and a second cause value when triggered by receipt of data from a second RLC channel. For example, the particular cause value used by the relay WTRU may be pre-defined as part of the RLC channel configuration. For example, the remote WTRU may select particular SL-RLC channels for transmissions associated with different cause values ​​determined at the remote WTRU. For example, the remote WTRU may transmit Uu data relayed over the sidelink on the first SL RLC channel when the data is associated with one or more first cause values ​​(e.g., emergency access) and may use the second RLC channel when the data is associated with one or more second cause values ​​(e.g., other cause values).

[0202] With respect to a Uu RRC message / procedure triggered by the remote WTRU, for example, the relay WTRU may use a first cause value for a connection establishment procedure triggered by the remote WTRU, a second cause value for a connection re-establishment procedure, and a third cause value for a resumption procedure. The relay WTRU may determine the procedure being performed by the remote WTRU using information from the remote WTRU using other embodiments (e.g., an RLC channel, explicit signaling, etc.), which may indicate the procedure and / or knowledge of the RRC state of the remote WTRU. For example, the relay WTRU may determine that the procedure is a connection establishment procedure when it receives data on the SL-RLC channel associated with SRB0. For example, the relay WTRU may decide to resume the procedure when the SL-RLC channel for SRB1 is used and the remote WTRU is RRC_INACTIVE, and may determine that the procedure is a re-establishment procedure when data is received on the SL-RLC channel for SRB1 and the remote WTRU is RRC_CONNECTED. The relay WTRU may determine the RRC state of the remote WTRU from the remote WTRU or from the network. For example, the remote WTRU may indicate (e.g., explicitly or using other methods described herein) a particular procedure (e.g., resumption, connection establishment, or connection re-establishment) being initiated by the remote WTRU.

[0203] With respect to resources or subsets of resources on which data is received from a remote WTRU, for example, the remote WTRU may be configured or pre-configured with sets of time / frequency resources on which it may send transmissions associated with different access categories and / or cause values. For example, the remote WTRU may be configured or pre-configured to select a first cause value when receiving a transmission on the remote WTRU that may be associated with one or more pre-defined RLC channels on a particular configured or pre-configured set of resources, and may select a second cause value when receiving a transmission on a second set of resources.

[0204] With regard to explicit signaling from the remote WTRU, for example, the remote WTRU may send a cause value for its own connection establishment / re-establishment / resumption signaling to the relay WTRU over Uu. For example, the remote WTRU may send an SL MAC CE, an adaptation layer control message, an SL RRC message, a PHY signal (e.g., SCI), or other explicit signaling indicating the establishment cause. For example, the remote WTRU may send an explicit indication when its establishment cause is one or a subset of the values. The relay WTRU may select its own establishment cause from the establishment causes received from the remote WTRU. For example, the remote WTRU may send an indication over SL (e.g., in an SL MAC CE, SL RRC message, or SCI) when access by the remote WTRU is associated with a particular cause value (e.g., emergency access). In that case, the relay WTRU may use the first cause value (e.g., emergency access), and in other cases may use the second cause value (e.g., new cause value). For example, the remote WTRU may send a cause value for its own connection establishment / / re-establishment / resumption over Uu to the relay WTRU, and if the cause value is one of a subset of cause values, the relay WTRU may use the first cause value (e.g., emergency access); otherwise, the relay WTRU may use the second cause value (e.g., new cause value).

[0205] The relay WTRU may use a new or existing cause value for its own access depending on the cause value (or information thereof) received from the remote WTRU. For example, the relay WTRU may be configured or pre-configured with a mapping of remote WTRU cause values ​​to relay WTRU cause values ​​and may select its own cause value based on this mapping. Such a mapping may further depend, for example, on the RRC state of the remote / relay WTRU, the access category of the relay WTRU itself, the access categories of other remote WTRUs connected to the relay WTRU (which may be in certain RRC states), network preferences, sidelink configurations and / or measurements (e.g., CBR, CR, SL, RSRP and / or resource load at the relay).

[0206] With respect to the RRC state of the remote / relay WTRU, for example, the relay WTRU may be configured with different mappings depending on the RRC state of the remote WTRU or its own RRC state. With respect to the access category of the relay WTRU itself, for example, the relay WTRU may be configured with different mappings depending on the access category of the relay WTRU. For example, with respect to the access categories of other remote WTRUs connected to the relay WTRU, the relay WTRU may be configured with different mappings depending, for example, on the highest / lowest access category of such remote WTRUs that the other remote WTRUs may be in a particular RRC state. For example, the relay WTRU may determine the cause value based on a mapping of a received cause value (or cause value information) to a relay cause value, and such a mapping may be defined specific to the access category of one particular connected remote WTRU (e.g., having the highest / lowest access category).

[0207] With regard to network preference / configuration, for example, the network may change the mapping using SIB / RRC signaling. For example, the relay WTRU may receive an explicit mapping to be applied from the network. For example, the relay WTRU may receive a preference indication (e.g., in SIB or RRC signaling, or another logically equivalent message), which may indicate that the relay WTRU should use the first mapping over the second mapping.

[0208] With respect to sidelink measurements (e.g., CBR, CR, SL RSRP, and / or resource load at the relay), for example, the relay WTRU may change the mapping (or determine the mapping) based on sidelink channel measurements such as CBR measurements, CR measurements, or relay load measurements.

[0209] In some embodiments, the relay WTRU can determine the reason for restart of its own restart procedure based on the remote WTRU's access identity. The relay WTRU can receive the remote WTRU's access identity from the remote WTRU itself, for example, in PC5-RRC signaling, SL MAC CE, adaptation layer header or control PDU, or other logically equivalent SL signaling. Similarly, the relay WTRU can determine the access identity based on knowledge of whether the remote WTRU requests emergency services. Alternatively or additionally, the relay WTRU can receive the remote WTRU's access identity from the network (e.g., in dedicated RRC signaling). The remote WTRU can send the access identity to the connected relay WTRU upon establishment of a Uu connection via the relay. Alternatively or additionally, the remote WTRU can send the access identity following mobility (e.g., reselection and PC5-RRC connection to a new relay, or connected mode mobility from a direct (over Uu) link). The remote WTRU may trigger an SL transmission to the relay WTRU if the access identity changes while connected to the relay WTRU.

[0210] The relay WTRU may use the access identity of the remote WTRU when determining the establishment cause of the relay WTRU when the relay WTRU is in RRC_INACTIVE mode. Alternatively or additionally, the relay WTRU may use the access identity of the remote WTRU when determining the establishment cause of the relay WTRU when the remote WTRU is in RRC_INACTIVE mode. Alternatively or additionally, the relay WTRU may use the access identity of the remote WTRU when determining the establishment cause of the relay WTRU only when both the relay WTRU and the remote WTRU are in RRC_INACTIVE mode. The relay WTRU may use the access identity of the remote WTRU when determining the establishment cause of the relay WTRU when the relay WTRU receives a paging for the remote WTRU. Specifically, the relay WTRU may determine whether the remote WTRU's access identity is included in the remote WTRU's paging message to determine whether to use the remote WTRU's access identity. Specifically, the relay WTRU may make such a determination based on whether at least one of the paging records in the paging message received at the remote WTRU's PO includes the I-RNTI. For example, the relay WTRU may make such a determination based on whether the paging message includes an indication of the presence of an I-RNTI for the remote WTRU.

[0211] Following receipt of a paging message addressed to the remote WTRU, the relay WTRU may determine (e.g., based on configuration or pre-configuration) a period during which it should determine an establishment cause for the relay WTRU based on the access identity of the remote WTRU. Such behavior may be used when the relay WTRU initiates resumption / establishment upon receipt of a remote WTRU transmission in response to a paging. Alternatively, a relay WTRU in RRC_INACTIVE / RRC_IDLE may initiate connection establishment / resumption immediately upon receipt of a paging directed to the remote WTRU and may use the access identity of the remote WTRU to determine an establishment cause for such connection establishment / resumption.

[0212] In some embodiments, the relay WTRU may determine its own cause value by considering the cause values ​​of multiple remote WTRUs. Such a determination may be performed when the relay WTRU receives multiple simultaneous transmissions from remote WTRUs, each of which may trigger connection establishment / resumption by the relay WTRU. The relay WTRU may determine the worst-case establishment cause and, for example, use the highest priority establishment cause of all of the received establishment causes as its own establishment cause. In some embodiments, for example, the relay WTRU may use an emergency if at least one remote WTRU indicates an emergency. Otherwise, as in some embodiments, the remote WTRU may use a specific cause value (e.g., a new cause value). Alternatively or additionally, the relay WTRU may be configured / predefined with a table that maps cause values ​​from two or more remote WTRUs to a single relay cause value.

[0213] For example, a relay WTRU in RRC_IDLE mode may set the establishment cause to emergency if the remote WTRU has established emergency services and / or initiates a re-establishment procedure, to highPriorityAccess if the remote WTRU initiates a re-establishment procedure, and / or set a new cause value for relay access otherwise. A relay WTRU in RRC_INACTIVE mode may set the establishment cause to emergency if the remote WTRU has established emergency services and initiates a re-establishment procedure, to highPriorityAccess if the remote WTRU initiates a re-establishment procedure, to a value determined from the remote WTRU's access identity if the remote WTRU receives a paging message from the relay WTRU, and to a new cause value for relay access otherwise.

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

Claims

1. 1. A wireless transmit / receive unit (WTRU), comprising: a processor; a transceiver, The processor and the transceiver Detecting a sidelink radio link failure; initiating a first timer based on a first timer value in response to detecting the sidelink radio link failure, the first timer being associated with selecting a candidate node, the candidate node being one of a relay node or a network node; and selecting the candidate node for connection re-establishment, wherein the selected candidate node is the relay node; stopping the first timer upon selecting the candidate node; determining one of a second timer value or a third timer value to be used by a second timer, wherein the second timer is associated with the connection re-establishment, the second timer value is associated with the connection re-establishment via the network node, and the third timer value is associated with the connection re-establishment via the relay node, and the third timer value is different from the second timer value; starting the second timer using the determined timer value upon selecting the candidate node, the determined timer value being the third timer value; sending a re-establishment request message; configured to run The processor and the transceiver are further configured to enter an idle mode on the condition that the WTRU does not receive a response to the re-establishment request message before expiration of the second timer.

2. The WTRU of claim 1 , wherein the first timer is a T311 timer.

3. The WTRU of claim 1 , wherein the second timer is a T301 timer.

4. 2. The WTRU of claim 1, wherein the detecting the sidelink radio link failure includes one or more of determining a number of consecutive hybrid automatic repeat request (HARQ) discontinuous transmissions (DTXs) ​​performed or determining a number of consecutive retransmissions performed.

5. The WTRU of claim 1 , wherein the processor and the transceiver are configured to receive configuration information comprising a system information block (SIB).

6. The WTRU of claim 1 , wherein selecting the candidate node for connection re-establishment includes measuring a signal quality associated with the candidate node.

7. 10. The WTRU of claim 1, wherein selecting the candidate node for connection re-establishment includes determining a priority associated with the candidate node, measuring a signal quality associated with the candidate node, and determining a zone identifier associated with the candidate node.

8. A method performed by a wireless transmit / receive unit (WTRU), comprising: Detecting a sidelink radio link failure; initiating a first timer based on a first timer value in response to detecting the sidelink radio link failure, the first timer being associated with selecting a candidate node, the candidate node being one of a relay node or a network node; and selecting the candidate node for connection re-establishment, wherein the selected candidate node is the relay node; stopping the first timer upon selecting the candidate node; determining one of a second timer value or a third timer value to be used by a second timer, wherein the second timer is associated with the connection re-establishment, the second timer value is associated with the connection re-establishment via the network node, and the third timer value is associated with the connection re-establishment via the relay node, and the third timer value is different from the second timer value; starting the second timer using the determined timer value upon selecting the candidate node, the determined timer value being the third timer value; sending a re-establishment request message; entering an idle mode, provided that the WTRU does not receive a response to the re-establishment request message before expiration of the second timer; The method further comprises:

9. The method of claim 8, wherein the first timer is a T311 timer.

10. The method of claim 8, wherein the second timer is a T301 timer.

11. The method of claim 8, wherein detecting the sidelink radio link failure includes one or more of determining the number of consecutive hybrid automatic repeat request (HARQ) discontinuous transmissions (DTX) performed or determining the number of consecutive retransmissions performed.

12. The method of claim 8, further comprising receiving configuration information including a system information block (SIB).

13. The method of claim 8, wherein selecting the candidate node for connection re-establishment includes measuring a signal quality associated with the candidate node.

14. The method of claim 8, wherein selecting the candidate node for connection re-establishment includes determining a priority associated with the candidate node, measuring a signal quality associated with the candidate node, and determining a zone identifier associated with the candidate node.

Images