Method and apparatus for link management and recovery for sidelink relays

Abstract

Methods and apparatus for link management and recovery for sidelink relays are described herein. A method may include transmitting a packet to a network via a first relay and using a sidelink radio bearer (SLRB) configuration, wherein the transmitted packet includes an identifier associated with the first relay; receiving a message identifying another selected relay; and detecting a radio link failure. The method may include obtaining a signal quality measurement of a reference signal associated with the additional selected relay; selecting a second relay with the highest signal quality from the other selected relays; and transmitting, to the selected second relay, a reconfiguration message indicating the use of the same SLRB configuration or the equivalent SLRB configuration. If the response indicates that reconfiguration of the second relay is successful, packets 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

[0001] This patent application is a divisional application of the following invention patent applications:

[0002] Application number: 202180054070.3

[0003] Application Date: August 5, 2021 Invention Title: Method and Apparatus for Link Management and Recovery of Sidelink Relay

[0004] CROSS-REFERENCE TO RELATED APPLICATIONS

[0005] This application claims the benefit of U.S. Provisional Application No. 63 / 061,532, filed August 5, 2020, and U.S. Provisional Application No. 63 / 185,801, filed May 7, 2021, the contents of which are incorporated herein by reference. Summary of the Invention

[0006] Methods and apparatus for link management and recovery of sidelink relays are described herein. The method may include transmitting a packet to a network via a first relay and using a sidelink radio bearer (SLRB) configuration, wherein 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 include obtaining a signal quality measurement of a reference signal associated with the alternative relay; selecting a second relay with the highest signal quality from the alternative relays; and transmitting a reconfiguration message to the selected second relay indicating use of the same SLRB configuration or an equivalent SLRB configuration. If the response indicates that reconfiguration of the second relay was successful, 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 DESCRIPTION OF THE DRAWINGS

[0007] A more detailed understanding may be obtained from the following description given by way of example with reference to the accompanying drawings in which like reference numerals indicate like elements and in which:

[0008] Figure 1A is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented;

[0009] Figure 1B It is shown that according to one embodiment, Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) for use within the illustrated communication system;

[0010] Figure 1C It is shown that according to one embodiment, Figure 1A a system diagram illustrating an exemplary radio access network (RAN) and an exemplary core network (CN) for use within the illustrated communication system;

[0011] Figure 1D It is shown that according to one embodiment, Figure 1A A system diagram of another exemplary RAN and another exemplary CN used within the illustrated communication system;

[0012] Figure 2 is a diagram illustrating an example of a user plane radio protocol stack for a Layer 2 evolved WTRU to network relay;

[0013] Figure 3 is a diagram illustrating an example of a control plane radio protocol stack for a Layer 2 evolved WTRU to network relay.

[0014] Figure 4 is a diagram illustrating an example of WTRU-to-WTRU relay;

[0015] Figure 5 is a diagram illustrating an example of WTRU to network relay; and

[0016] Figure 6 is a flow chart of an exemplary re-establishment or recovery process. DETAILED DESCRIPTION

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

[0018] like Figure 1AAs shown, the communication 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. However, it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a station (STA)) may be configured to transmit and / or receive wireless signals and may include user equipment (WTRUs), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspot or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated process chain environments), consumer electronic devices, devices operating on commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as WTRUs.

[0019] The communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106, 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 NodeB, an evolved NodeB (eNB), a Home NodeB, a Home evolved NodeB, a next generation NodeB such as a gNodeB (gNB), a New Radio (NR) NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0020] 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. Base station 114a and / or base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage to a specific 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 base station 114a may be divided into three sectors. Thus, in an embodiment, base station 114a may include three transceivers, one for each sector of the cell. In an embodiment, base station 114a may employ multiple-input, multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

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

[0022] More specifically, as noted above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 116. 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).

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

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

[0025] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement both LTE radio access and NR radio access, for example, 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 sent to / from multiple types of base stations (e.g., eNBs and gNBs).

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

[0027] Figure 1AThe base station 114b in the may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, and the like. In an 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 an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a microcell or a femtocell. As Figure 1A As shown, base station 114b may have a direct connection to the Internet 110. Thus, base station 114b may not need to access the Internet 110 via CN 106.

[0028] The RAN 104 may be in communication with the CN 106, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. Data may have different quality of service (QoS) requirements, such as different throughput requirements, delay requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform advanced security functions, such as user authentication. Although not described in detail in the text, the CN 106 may be configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. Figure 1A Although not shown in the figures, it will be appreciated that the RAN 104 and / or the CN 106 may be in direct or indirect communication with other RANs that employ 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 be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

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

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

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

[0032] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), 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 functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it is understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

[0034] Although the transmit / receive element 122 is Figure 1B Although depicted as a single element in FIG1 , the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in an 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.

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

[0036] The processor 118 of the WTRU 102 may be coupled to and may receive user input 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, and the like. In other embodiments, the processor 118 may access information from and store data in memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

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

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

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

[0040] The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) and DL (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference via hardware (e.g., a choke) or via signal processing performed by a processor (e.g., a separate processor (not shown) or via the processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) or DL (e.g., for reception)) may be concurrent and / or simultaneous.

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

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

[0043] 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, scheduling of users in UL and / or DL, etc. Figure 1C As shown, the eNode-Bs 160a, 160b, 160c may communicate with one another via an X2 interface.

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

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

[0046] 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 downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.

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

[0048] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may be in communication 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. In addition, 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.

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

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

[0051] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access to or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or out of the BSS. Traffic originating from outside the BSS and destined for a STA can reach the AP and be delivered to the STA. Traffic originating from a STA and destined for a destination outside the BSS can be sent to the AP for delivery to the destination. Traffic between STAs within a BSS can be sent through the AP, for example, where a source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within a BSS can be considered and / or referred to as point-to-point traffic. Point-to-point traffic can be sent between a source and destination STA (e.g., directly between them) using direct link setup (DLS). In certain representative embodiments, the DLS can 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 (eg, all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad-hoc" communication mode.

[0052] When using the 802.11ac infrastructure operating mode or a similar operating mode, the AP may transmit a beacon 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 set 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., each STA), including the AP, may sense the primary channel. If the primary channel is sensed / detected by a particular STA and / or determined to be busy, the particular STA may back off. One STA (e.g., only one station) may transmit in a given BSS at any given time.

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

[0054] Very high throughput (VHT) STAs can support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. 40 MHz and / or 80 MHz channels can be formed by combining contiguous 20 MHz channels. A 160 MHz channel can be formed by combining eight contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels (this may be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, the data can pass through a segment parser that can separate the data into two streams. Each stream can be individually processed using an inverse fast Fourier transform (IFFT) and time domain processing. These streams can be mapped to two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiving STA's receiver, the operations described above for the 80+80 configuration can be reversed, and the combined data can be sent to the medium access control (MAC).

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

[0056] WLAN systems that 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 may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA (that supports the minimum bandwidth operating mode) from among all STAs operating in the BSS. In the example of 802.11ah, for a STA (e.g., an MTC-type device) that supports (e.g., only supports) 1 MHz mode, the primary channel may be 1 MHz wide, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, because a STA (that only supports 1 MHz operating mode) is transmitting to the AP, the entire available frequency band may be considered busy even if most of the available frequency band remains idle.

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

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

[0059] The RAN 104 may include gNBs 180a, 180b, and 180c, though it will be appreciated 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 and 180b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, and 180c. Thus, the gNB 180a may, for example, use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a. In an embodiment, the gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In an embodiment, gNBs 180a, 180b, and 180c may implement coordinated multi-point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0060] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable parameter sets. For example, OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmit spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or Transmission Time Intervals (TTIs) of varying or scalable lengths (e.g., containing varying numbers of OFDM symbols and / or varying absolute time lengths).

[0061] 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 while not accessing other RANs (e.g., such as the eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate or connect with the gNBs 180a, 180b, 180c while also communicating or connecting with other RANs, such as the eNode-Bs 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNode-Bs 160a, 160b, 160c may serve as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0062] Each of the gNBs 180a, 180b, 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, support of network slicing, interworking between DC, NR, and E-UTRA, routing of user plane data towards a user plane function (UPF) 184a, 184b, routing of control plane information towards an access and mobility management function (AMF) 182a, 182b, etc. Figure 1D As shown, gNBs 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0063] Figure 1DThe illustrated CN 106 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 data networks (DNs) 185a, 185b. While the aforementioned elements are depicted as part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0064] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c via the N2 interface in the RAN 104 and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling of different protocol data unit (PDU) sessions with different requirements), selecting a specific SMF 183a, 183b, managing registration areas, terminating non-access stratum (NAS) signaling, mobility management, etc. The AMF 182a, 182b may use network slicing to customize CN support for the WTRUs 102a, 102b, 102c based on the type of services used by 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 Mobile Broadband (eMBB) access, services for MTC access, etc. The AMFs 182 a and 182 b 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.

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

[0066] The UPFs 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via the N3 interface. These gNBs 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 routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchoring, and the like.

[0067] The CN 106 may facilitate communications with other networks. For example, the CN 106 may include, or may 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. Additionally, 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 an embodiment, the WTRUs 102a, 102b, 102c may connect to the DNs 185a, 185b through the UPFs 184a, 184b via the N3 interface to the UPFs 184a, 184b and the N6 interface between the UPFs 184a, 184b and the local DNs 185a, 185b.

[0068] Given that Figures 1A to 1D as well as Figures 1A to 1D As described herein, one or more or all of the functions described herein with reference to one or more of the following may be performed by one or more emulated devices (not shown): the WTRUs 102a-d, base stations 114a-b, eNodeBs 160a-c, MMEs 162, SGWs 164, PGWs 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other devices described herein. An emulated device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, an emulated device may be used to test other devices and / or simulate network and / or WTRU functions.

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

[0070] The one or more emulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation device can be used in a test scenario in a test lab and / or in a non-deployed (e.g., testing) wired and / or wireless communication network to enable testing of one or more components. The one or more emulation devices can be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which can include one or more antennas) can be used by the emulation device to transmit and / or receive data.

[0071] New Radio (NR) Release 17 may consider the use of both WTRU-to-network relay and WTRU-to-WTRU relay over the PC5 interface (e.g., sidelink). For example, initial versions of NR sidelink procedures were developed for NR Release 16 to support V2X-related road safety services. The design can support broadcast, multicast, and unicast communications in both out-of-coverage and in-coverage scenarios. However, it may be desirable to improve coverage extension and power efficiency, and to consider a wider range of applications and services than those considered in Release 16, for example, to support enhanced Quality of Service (QoS) requirements.

[0072] For example, it may be desirable to consider WTRU to network coverage extension and / or WTRU to WTRU coverage extension. For WTRU to network coverage extension, air interface (i.e., Uu) coverage reachability may be necessary for the 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 to network relay may be limited to EUTRA-based technologies and therefore may not be applicable to NR-based systems for NG-RAN-based and NR-based sidelink communications. For WTRU to WTRU coverage extension, current proximity reachability may be limited to a single-hop sidelink via EUTRA-based or NR-based sidelink technologies. However, this may not be sufficient in scenarios where there is no Uu coverage, given the limited single-hop sidelink coverage.

[0073] For single-hop NR sidelink relay, some considerations may include mechanisms with minimal regulatory impact that support scheduling assignment (SA) requirements for sidelink-based WTRU-to-network and WTRU-to-WTRU relay, focusing on one or more aspects of, for example, layer 3 relay and layer 2 relay. These aspects may include relay selection and / or reselection criteria and procedures, relay / remote WTRU authorization, QoS for relay functions, service continuity, security of the relay connection after SA3 provides its conclusion, and impact on the user plane protocol stack and control plane procedures (e.g., connection management of the relay connection). Other considerations may include, for example, upper layer operations to support the discovery model and / or procedures for sidelink relay, assuming no new physical layer channels / signals.

[0074] Release 13 introduces WTRU-to-network relaying via Proximity Services (ProSe) to extend network coverage to out-of-coverage WTRUs using a PC5 interface (e.g., D2D) between the out-of-coverage WTRU and the WTRU-to-network relay. The ProSe WTRU-to-network relay can provide a generic L3 forwarding function that can relay any type of IP traffic between a remote WTRU and the network. One-to-one and one-to-many sidelink communications can be used between a remote WTRU or a WTRU and a ProSe WTRU-to-network relay. For both the remote WTRU and the relay WTRU, only one single carrier (e.g., a public safety ProSe carrier) operation may be supported (e.g., Uu and PC5 may be the same carrier for the relay / remote WTRU). The remote WTRU may be authorized by upper layers and may be within the coverage of a public safety ProSe carrier or out of coverage on any supported carrier, including the public safety ProSe carrier used for WTRU-to-network relay discovery, selection or reselection, and communication.

[0075] Relay selection or reselection of a ProSe WTRU to 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) measurements) and upper layer criteria. The eNB may control whether a WTRU may act as a ProSe WTRU to network relay. ProSe WTRU to network relay operation may be supported in a cell if the eNB broadcasts any information associated with the ProSe WTRU to network relay operation. The eNB may provide one or more of the following: transmission resources for ProSe WTRU to 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 to network relay discovery using broadcast signaling.

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

[0077] If the ProSe WTRU to network relay operation is initiated by broadcast signaling, the WTRU to network relay may perform ProSe WTRU to network relay discovery while in RRC_IDLE mode. If the ProSe WTRU to network relay operation is initiated by dedicated signaling, the ProSe WTRU to network relay may perform relay discovery while in RRC_CONNECTED mode. A ProSe WTRU to network relay that performs sidelink communication for ProSe WTRU to network relay operation may need to operate in RRC_CONNECTED mode. Upon receiving a Layer 2 Link Establishment Request or a Temporary Mobile Group Identity (TMGI) Monitoring Request (e.g., an upper layer message) or any other logically equivalent message from a remote WTRU, the ProSe WTRU to network relay may indicate to the eNB that it is a ProSe WTRU to network relay and intends to perform ProSe WTRU to network relay sidelink communication. The eNB may provide resources for ProSe WTRU to network relay communication.

[0078] The remote WTRU may decide when to start monitoring for ProSe WTRU to network relay discovery. Depending on the configuration of resources for ProSe WTRU to network relay discovery, the remote WTRU may transmit a ProSe WTRU to network relay discovery request message while in RRC_IDLE or in RRC_CONNECTED. The eNB may broadcast a threshold value that the remote WTRU may use to determine whether it may transmit a ProSe WTRU to network relay discovery request message in order to connect or communicate with a ProSe WTRU to network relay WTRU. An RRC_CONNECTED remote WTRU may use the broadcasted threshold value to determine whether it may indicate to the eNB that it is a remote WTRU and wishes to participate in ProSe WTRU to network relay discovery and / or communication. The eNB may use broadcast or dedicated signaling to provide transmission resources and broadcast signaling to provide reception resources for ProSe WTRU to network relay operation. When the RSRP exceeds the broadcast threshold value, the remote WTRU may stop using the ProSe WTRU to network relay discovery and communication resources. The exact time of traffic switching from Uu to PC5 or from PC5 to Uu may be determined or signaled by higher layer functions, entities or their logical equivalents.

[0079] The remote WTRU may perform radio measurements at the PC5 interface and use these radio measurements together with higher layer criteria for ProSe WTRU-to-network relay selection and reselection. A ProSe WTRU-to-network relay may be considered suitable in terms of radio criteria, for example, if the PC5 link quality exceeds a configured threshold (e.g., pre-configured or provided by the eNB). In some instances, the remote WTRU may select a ProSe WTRU-to-network relay that satisfies one or more criteria (provided by, for example, 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-to-network relays.

[0080] The remote WTRU may trigger ProSe WTRU-to-network relay reselection under one or more circumstances. For example, when the current PC5 signal strength of the ProSe WTRU-to-network relay falls below a configured signal strength threshold and / or when the remote WTRU receives a Layer 2 Link Release message (e.g., an upper layer message or any logical equivalent) from the ProSe WTRU-to-network relay, the remote WTRU may trigger ProSe WTRU-to-network relay reselection.

[0081] In Release 14, studies were conducted on WTRU-to-network relay in the RAN for business use cases tailored for wearables and IoT devices. Although no specifications were produced from such studies, a Technical Report (TR) provided some preferred solutions for such relays. Unlike ProSe WTRU-to-network relay, which can use Layer 3 (IP layer) relay methods, the ProSe WTRU-to-network relay based on Figure 2 and Figure 3 The protocol stack shown in Figure 1, the WTRU-to-network relay for wearable devices is expected to be a Layer 2 relay, which is introduced and described in detail in the following paragraphs. The relay solution in previous releases of the LTE specification was based on a one-to-one communication link established at the upper layers (e.g., ProSe layer) between two WTRUs (e.g., the remote WTRU and the WTRU-to-network relay). Such a connection is transparent to the AS layer, and the connection management signaling and procedures performed at the upper layers are carried by the AS layer data channel. Therefore, the AS layer is unaware of such a one-to-one connection.

[0082] Figure 2 is a diagram illustrating an example of a user plane radio protocol stack for Layer 2 evolved WTRU to network relay. Figure 2 As shown, the remote WTRU 201 may be connected to the layer 2 relay WTRU 202 via a side link (i.e., the remote WTRU 201 and the relay WTRU 202 may communicate via a PC5 interface). The layer 2 relay WTRU 202 and the eNB 203 may have a lower layer link established with the eNB via an air interface (Uu).

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

[0084] Figure 3 is a diagram illustrating an example of a control plane radio protocol stack for a layer 2 evolved WTRU to network relay. Figure 2As described with reference to elements 201, 202, 203, and 204 of the present invention, the remote WTRU 301 may be connected to the layer 2 relay WTRU 302 via a side link (i.e., the remote WTRU 201 and the 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, PHY, and 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 (and vice versa) via the layer 2 evolved WTRU-to-network relay may be performed above the RLC layer (e.g., at the PDCP and IP layers).

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

[0086] Unicast links at the AS layer can be supported via a PC5-Radio Resource Configuration (RRC) connection. A PC5-RRC connection can be a logical connection between a source layer-2ID and a destination layer-2ID pair in the AS. One PC5-RRC connection can correspond to one PC5 unicast link. PC5-RRC signaling can be initiated after its corresponding PC5 unicast link is established. When the PC5 unicast link is released as instructed by upper layers, the PC5-RRC connection and the corresponding sidelink signaling radio bearer (SRB) and sidelink dedicated radio bearer (DRB) can be released.

[0087] For each PC5-RRC unicast connection, a sidelink SRB may be used to transport 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 has been established. One sidelink SRB may be used to transport PC5-S messages to establish PC5-S security. One sidelink SRB may be used to transport PC5-S messages after PC5-S security has been established, and the messages may be protected. One sidelink SRB may be used to transport PC5-RRC signaling, which may be protected and sent only after PC5-S security has been established.

[0088] PC5-RRC signaling may include one or more sidelink configuration messages (e.g., RRCReconfigurationSidelink messages or logically equivalent messages) through which the WTRU may configure the RX-related parameters of each sidelink radio bearer (SLRB) in 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)). The receiving WTRU may confirm or reject such configuration, depending on whether it can support the configuration proposed by the peer WTRU.

[0089] The Integrated Access and Backhaul (IAB) in Release 16 may support backhaul radio link failure (RLF) indication. When a backhaul RLF recovery failure is detected at an IAB-Mobile Terminal (MT), for each egress link associated with the IAB-Distributed Unit (DU), the transport portion of the Backhaul Adaptation Protocol (BAP) entity at the IAB-DU may construct a BAP Control Protocol Unit (PDU) for backhaul RLF indication. If an egress Backhaul (BH) Radio Link Control (RLC) channel is configured for BAP Control PDUs, the BAP entity at the IAB-DU may submit the BAP Control PDU to the configured egress BH RLC channel of the egress link. In some cases, such as when no egress BH RLC channel is configured for BAP Control PDUs, the BAP entity may submit the BAP Control PDU to any egress BH RLC channel of the egress link. When a BAP control PDU for a backhaul RLF indication is received from lower layers (eg, 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 where the BAP control PDU was received.

[0090] The Integrated Access and Backhaul (IAB) framework as described in Release 16 can support flow control feedback as follows. For a link, the transmit part of the BAP entity at the IAB-MT can construct a BAP Control PDU for flow control feedback when flow control feedback is triggered when the buffer load exceeds a certain level, or when a BAP Control PDU for flow control polling is received at the receive part. If an egress BH RLC channel for BAP Control PDUs is configured, the BAP entity can submit the BAP Control PDU to the configured egress BH RLC channel of the egress link. If no egress BH RLC channel for BAP Control PDUs is configured, the BAP entity can submit the BAP Control PDU to any egress BH RLC channel of the egress link.

[0091] The various problems that the solutions proposed herein address can be understood as follows.

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

[0093] In the case of relay links involving side links (e.g., WTRU to network (NW) relay or WTRU to WTRU relay), separate link management procedures may not be sufficient because link management on one link is not necessarily visible to the other link. Therefore, a mechanism may be needed to make failures on one link visible to the other link. For example, in a WTRU to network relay scenario, the relay WTRU may trigger a TX-based RLF over the relay link. However, if the remote WTRU does not have its own regular transmission to trigger a similar RLF, or if the SL channel is not reciprocal, such RLF may not be visible to the remote WTRU. In such cases, recovery may be delayed and service continuity may be difficult to achieve. Specifically, the network may be able to send data via Uu (in the event of a SL failure), but it may not be known whether the WTRU is reachable after the failure, under the premise that the WTRU connected via the WTRU to network relay should not be required to perform all required Uu procedures (e.g., for power saving purposes).

[0094] Furthermore, recovery over the Uu can be achieved via a re-establishment procedure, whereas no such procedure exists over the SL, as another prerequisite may be the presence of a SL RRC connection between a single WTRU pair. For relay links, recovery can now be achieved by selecting a new relay. However, a solution for selecting one or more relays is desired so that the relays can achieve the same QoS as the failed link.

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

[0096] Figure 4 is a diagram illustrating an exemplary architecture for link management and recovery in the context of a WTRU to WTRU relay. Figure 4 As shown. Figure 4 The first link shown may correspond to the link between the source WTRU 401 and the relay WTRU 402. The second link may refer to the link between the relay WTRU 402 and any one of the destination or next-hop WTRU 403 in a multi-hop WTRU-to-WTRU or WTRU-to-network link. In general, the destination may be, for example, a WTRU or a network node, depending on whether the relay is a WTRU-to-WTRU relay or a WTRU-to-network relay. Figure 4 In the depicted case, the destination is the former, namely, destination WTRU 404. Without loss of generality, the term source WTRU may also refer to a relay WTRU that is served by another relay along the link to the destination.

[0097] Figure 5 is a diagram illustrating another exemplary architecture for link management and restoration, particularly in the context of WTRU to network relay. A relay WTRU may be used as a WTRU to network relay, such as Figure 5 As shown. Figure 4 The first link shown may correspond to the link between the source WTRU 501 and the relay WTRU 502. The second link may refer to the link between the relay WTRU 502 and any of the destination or next-hop WTRU 503 in a multi-hop WTRU-to-WTRU or WTRU-to-network link. Figure 5 In the depicted case, the destination is NodeB 504. Without loss of generality, as with respect to Figure 5 The term source WTRU described may also refer to a relay WTRU that is served by another relay along the link to the destination.

[0098] In some embodiments, a WTRU configured as a SL relay (e.g., a WTRU-to-network relay or a WTRU-to-WTRU relay) may send a link problem indication to one or more other WTRUs via a side link. Such an indication may be sent to the source WTRU of the relay connection or to another WTRU included in the relay connection, e.g., according to the architecture described herein and shown in the accompanying drawings. Such an indication may be sent upon detection of a link problem detected between the relay WTRU and the NW (for a WTRU-to-network relay) or between the relay WTRU and another WTRU (the other WTRU may be the destination WTRU or another relay WTRU, e.g., according to the architecture described herein and shown in the accompanying drawings).

[0099] A Link Problem Indication (LPI) may be an L2 protocol message sent via any one or 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 send the LPI as a PC5-RRC message and include, along with the message, a SL Medium Access Control (MAC) CE and / or Adaptation Control PDU containing 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.

[0100] The LPI may be broadcast / multicast to all source WTRUs served by a particular relay WTRU. For example, a relay WTRU may be configured with an L2 source / destination ID (or a logically equivalent source / destination ID) to transmit an LPI or similar status message intended for each source WTRU served by the relay WTRU, or a subset thereof. The relay WTRU (and the corresponding source WTRU) may determine such an L2 ID based on any combination of one or more indications received from upper layers, derive the L2 ID from the RAN ID, or determine the L2 ID based on its own configured L2 ID and / or based on the L2 address exchange procedure in the PC5-RRC configuration with each source WTRU. When the relay WTRU determines the L2 ID based on at least upper layers, for example, the relay WTRU and the corresponding WTRU may receive the L2 ID explicitly from the upper layers and / or from the network, such as when configured to act as / use a relay WTRU. For example, 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 functionality of the RAN ID, such as a cell radio network temporary identifier (C-RNTI), an inactive RNTI (I-RNTI), or an international mobile subscriber identity (IMSI).

[0101] When a relay WTRU determines the L2 ID based at least on its own configured L2 ID, for example, the relay WTRU may reuse one of its own L2 source / destination IDs (possibly along with some other information) to construct the source / destination ID for LPI transmission. For example, the relay WTRU may use a subset of the bits of one of its source / destination IDs and append a specific bit combination to it to create the multicast source / destination ID. For example, the relay WTRU may use a subset of the bits of the source / destination ID provided by upper layers 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).

[0102] When the relay WTRU determines the L2 ID based at least on the L2 address exchange procedure in the PC5-RRC configuration with each source WTRU, for example, the relay WTRU may be configured (e.g., by upper layers) with the L2 source / destination ID for transmission of the LPI message and may send it to each source WTRU during the PC5-RRC configuration procedure for link establishment. For example, the relay WTRU may determine the source / destination address using any of the means described in the above examples (e.g., derived from the RAN ID) and may provide one or more IDs to each source WTRU during the PC5-RRC configuration procedure.

[0103] Once the source WTRU knows the L2 source / destination ID associated with the transmission of the LPI message, the source WTRU may monitor the source / destination ID to receive the multicast LPI message transmitted by the relay WTRU.

[0104] In some embodiments, the LPI may be transmitted in a dedicated message on the PSCCH or PSSCH identified by 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 contains identifiers for transmissions in addition to the L1 source / destination ID. For example, the SCI may indicate a new transmission type (e.g., a relay-specific broadcast transmission to the source WTRU). The SCI may also contain identifiers or parameters that identify the relay WTRU, such as: a RAN-specific identity of the relay WTRU (e.g., as described herein), an identifier of the relay WTRU exchanged via PC5-RRC (e.g., as described herein), and / or an identifier provided by upper layers (e.g., as described herein).

[0105] In some embodiments, if the content of the LPI is limited (e.g., only contains 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). Some dedicated resources may be configured for transmitting the LPI on any of the dedicated PHY channels. Specifically, the WTRU to WTRU relay may be configured with a PSFCH source for transmitting the LPI (e.g., occurring periodically). For example, when transmitting the LPI, the relay WTRU may transmit an indication (e.g., a HARQ acknowledgement (ACK) or a HARQ negative acknowledgement (NACK)) on the PSFCH source. The relay WTRU may be configured with one such PSFCH resource and / or information to be sent (e.g., based on the content of the LPI) for each destination WTRU or relay WTRU of the second link (e.g., by the NW).

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

[0107] A relay WTRU may send a Link Problem Recovery Indication (LPRI). Such an LPRI may be associated with an event that triggered an LPI. The WTRU that sent the LPI may initiate monitoring for the transmission of the LPRI. The WTRU may transmit the LPRI whenever the condition that triggered the associated LPI is relieved. When the LPI condition is relieved, any of the conditions mentioned herein for the LPI may be considered for the LPRI. For example, the WTRU may send an LPI associated with a buffer status that is above a threshold that depends on the CR / resource pool, and then may send an LPRI when such buffer status drops below another (possibly related) threshold.

[0108] A source WTRU receiving an LPRI may cancel any operations related to relaying, relay reselection / reconfiguration, etc., which may have been started as a result of receiving the LPI.

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

[0110] In some examples, the WTRU may initiate part of the relay reselection process upon receiving the LPI, and then complete the reselection / reconfiguration if the WTRU does not receive an LPRI indicating that the condition is alleviated or if a timer expires without receiving such an LPRI.

[0111] The relay WTRU may send information in a link problem indication in a periodic manner. The period may depend on the values of one or more parameters, discussed further below. In some instances, the relay WTRU may send an LPI when one or a combination of the following conditions occurs: RLF on a second link associated with the destination, failure to perform recovery, relay selection or reselection (which may be associated with (or within) a duration for which recovery or selection or reselection should occur, and / or receiving a link problem indication from another WTRU. In some instances, the relay WTRU may send an LPI based on: based on CBR / CR measurements, based on relay-specific CRs, based on the number of consecutive HARQ feedback failures, based on the values of counters and / or timers associated with the second link (either to the WTRU or to the network), based on buffer load at the relay, based on CQI / RSRP measurements received / transmitted by the relay WTRU, based on relay buffer based on the QoS of the configured bearers and / or data in the relay (e.g., observed latency or remaining PDB), based on the configuration of the peer (source) WTRU (implicit or explicit), based on the resource pool configuration, based on Uu quality / conditions, based on Uu mobility events, based on Uu failures, based on whether the current link configuration / state allows detection of RLF / link problems at the source WTRU based on the absence of a feedback response, and / or based on whether the first link is configured with a mechanism for determining RLF, such as any one or a combination of the following, particularly in the context of WTRU to WTRU relay, the relay WTRU is configured or pre-configured with multiple SCIs for enabling HARQ feedback over a configured or pre-configured past time window; and / or the relay WTRU is configured with at least one SLRB configured with RLC AM (possibly excluding SL SRBs).

[0112] Regarding RLF on the second link associated with the destination, for example, the relay WTRU may send an LPI to the destination WTRU of the WTRU-to-WTRU relay connection when RLF associated with the second link is triggered. Specifically, when an RLF occurs for the destination to which the source WTRU is connected via the relay, the WTRU may transmit the LPI to the source WTRU. For example, the relay WTRU may send the LPI when a Uu RLF associated with the second link of the WTRU to the network relay is triggered.

[0113] Regarding failure to perform recovery, for example, the relay WTRU may start a timer or begin measuring the duration after RLF on the secondary link. The relay WTRU may initiate relay selection or reselection. If reselection is not completed before the timer expires, or upon determining that the duration has elapsed, the relay WTRU may send an LPI message.

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

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

[0116] Regarding the relay-specific CR, the WTRU may determine the relay-specific CR. Specifically, the relay WTRU may measure the amount of resources reserved / used for transmission of relay traffic and / or the ratio of the CR applicable to relay traffic. The WTRU may determine such a ratio by determining the ratio of the amount of traffic in its buffer used for relay traffic to non-relay traffic and multiplying such a ratio by the measured CR. The WTRU may determine the relay-specific CR by determining the amount of resources in the resource pool used to transmit to the destination ID associated with the relay link or containing data from the LCH associated with the relay link.

[0117] Regarding the number of consecutive HARQ feedback failures, when the number of consecutive DTX receptions for HARQ-based transmissions to a destination reaches a certain value, the relay WTRU may transmit an LPI to the source WTRU. Such a destination may correspond to a destination to which the source WTRU relays communications via a WTRU-to-WTRU relay. For example, after transmitting the LPI for consecutive DTXs, the relay WTRU may trigger an LPI or LPRI when an RLF is triggered or when the number of consecutive DTXs is reset.

[0118] Regarding the value of the counter and / or timer and / or the duration associated with the second link, for example, the WTRU-to-network relay WTRU may transmit the LPI to the source WTRU when, for example, timer T310 is started, when T310 has expired, when T310 reaches a certain configured or preconfigured value, or when the number of consecutive OOS reaches a certain preconfigured value. In other words, the WTRU-to-network relay WTRU may transmit the LPI to the source WTRU when, for example, the duration begins, when the duration has elapsed, when some configured or preconfigured duration, or when the number of consecutive OOS reaches some preconfigured value. For example, the WTRU-to-WTRU relay may transmit the LPI to the source WTRU when the number of consecutive RLC retransmissions reaches a configured or preconfigured value.

[0119] Regarding the buffer load at the relay, for example, the WTRU may send an LPI when the buffer load exceeds a threshold. Such a threshold may also depend on the QoS, SLRB configuration, the number of relay source WTRUs / LCHs, etc. For example, the buffer load that triggers the LPI may be the load of a single LCH, or it may be the total load of all LCHs at the relay WTRU or relay LCHs.

[0120] Regarding the CQI / RSRP measurements received / transmitted by the relay WTRU, for example, when the CQI measurement received by the WTRU's relay (eg, of the second link) is above / below a threshold, the WTRU may send an LPI.

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

[0122] With respect to configuration performed by the peer WTRU, the relay WTRU may be configured by the peer WTRU (e.g., in PC5-RRC signaling) as to whether to send an LPI when a particular trigger occurs. For example, when an RLF is detected on the second link, the relay WTRU may be configured with one or both of the following two behaviors: when an RLF is detected on the second link, the relay WTRU immediately releases the PC5-RRC connection associated with the second link and does not send an LPI or sends an LPI (e.g., which may contain an RLF indication) to the source WTRU and waits for an acknowledgement before releasing the PC5-RRC connection. The relay WTRU may also 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 per SLRB and may select a behavior based on at least one of the configured SLRBs having the configured associated behavior.

[0123] The implicit configuration of whether to send LPI may be defined based on the activation / deactivation state of the link itself, the WTRU location, the WTRU RRC state, and / or the WTRU coverage state. Regarding the activation / deactivation state of the link itself, for example, the relay link may be activated / deactivated by the source WTRU and / or the NW and / or upper layers. The WTRU may only send LPI when the link is activated and may discard or buffer LPI (e.g., sent upon activation) when the link is deactivated. For example, the WTRU may broadcast LPI to all source WTRUs as long as at least one link to the source WTRU is activated. Regarding the WTRU location, for example, the WTRU may be configured with zones or rules regarding whether it should send LPI based on its relative location to another WTRU or NodeB (e.g., gNB). Regarding the WTRU RRC state, for example, the WTRU may determine whether to send LPI based on another trigger based on the current RRC state of the relay WTRU. Regarding the WTRU coverage state, for example, the WTRU may determine whether to send LPI based on another trigger based on whether the WTRU is in coverage of the Uu.

[0124] With respect to resource pool configuration, for example, any of the conditions described herein for sending an LPI may further depend on the transmit resource pool configuration. For example, the WTRU may send an LPI if the amount of data in the buffer exceeds a certain value, the certain value depending on the density of time 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. For 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 used for TX in the resource pool and / or the average waiting time / remaining PDB of data currently buffered at the relay WTRU.

[0125] Regarding Uu quality / condition, 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).

[0126] With respect to Uu mobility events, for example, the relay WTRU may send an LPI as a result of receiving / triggering a handover / reconfiguration / conditional handover / PSCell change at the relay WTRU, triggering a cell reselection event at the relay WTRU, and / or the relay WTRU changing tracking area, RAN paging area or the like, or moving outside the coverage of a configured or pre-configured set of cells.

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

[0128] Regarding whether the current link configuration / state allows for the detection of an RLF / link problem at the source WTRU based on the absence of feedback / response, for example, the relay WTRU may choose between one of the following two actions upon RLF of the second link: immediately release the PC5-RRC connection associated with the second link without sending an LPI and / or send an LPI (e.g., which may include an RLF indication) to the source WTRU and wait for an acknowledgment before releasing the PC5-RRC connection. The relay WTRU may also suspend any transmissions performed on the second link associated with the link in RLF.

[0129] The relay WTRU may include in the LPI to the source WTRU an indication of a 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, quantities associated with any of the conditions for transmitting the LPI described herein, the L2 source / destination ID of the next hop for which the LPI may apply (e.g., the link that triggered the RLF), one or more RLF-related parameters associated with the second link, one or more LCHs to which the other LPI content applies, the cell ID of the cell in which the relay WTRU experienced the RLF / failed re-establishment, or any conditions related to the RLF, a new cell ID applicable for the WTRU-to-network relay connection (e.g., assumed after receiving the LPI or after completing the reselection procedure), one or more relay reselection candidates (e.g., the source / destination L2 ID and / or cell ID of the relay) and some associated measurements / selection metrics (such as SL / Uu RSRP measurements), and / or an identifier to be used by the WTRU after receiving the LPI (e.g., to continue communicating after the LPI and / or after a successful reselection).

[0130] Regarding indications of failure, for example, the LPI may include an identifier that further identifies the cause of the failure, or the resources used to transmit the LPI, whereby any of the triggers described herein may be triggered for different reasons. Regarding indications of triggered relay selection / reselection, for example, the relay WTRU may decide to trigger relay selection or relay reselection under some conditions associated with the transmission of the LPI. The relay WTRU may include such information in the LPI. Regarding quantities associated with the conditions for transmitting the LPI described herein, these quantities 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 on the second link, possibly for each relay RLC channel associated with the source WTRU to which the LPI is being sent.

[0131] With respect to one or more RLF-related parameters associated with the second link, these parameters 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 Out-of-Service (OOS), or a value of a counter / timer associated with RLF for the second link. For example, the relay WTRU may send a set of transmissions / retransmissions missed by the relay WTRU and / or may not send HARQ feedback. The relay WTRU may determine the missed transmissions / retransmissions based on the reception of a DAI (or similar) on the sidelink. The source WTRU may account for such missed transmissions in the RLF determination algorithm (e.g., by subtracting them from the number of DTX-to-HARQ). For another example, the relay WTRU may send the number of consecutive Out-of-Service (IOS) / OOS, the value of any counter, the value of a timer (e.g., T310), or the value of a duration to be measured to the source WTRU or the WTRU-to-network relay link. For example, the relay WTRU may send the value of T310 or the duration to be measured, may send an indication that the value of T310 has reached a threshold, or may send an indication that the duration has elapsed. Regarding the identifiers used by the WTRU after receiving the LPIE, these identifiers may include, for example, any of the source / destination L2 IDs, C-RNTI, A-RNTI, or similar Uu or SL identifiers.

[0132] When a link is initiated by a source WTRU, the relay WTRU may create an SLRB for transmission to the source WTRU. For example, the relay WTRU may create an SLRB towards the source WTRU upon receiving a PC5-RRC message from the source WTRU. Alternatively or in addition, the relay WTRU may create an SLRB towards the source WTRU upon an indication from upper layers that it will act as a relay WTRU for a particular source / destination L2 ID and / or upon receiving a source / destination routing table from upper layers. For example, such an SLRB may be used to transmit the LPI in a secure manner.

[0133] In some embodiments, the WTRU may modify its link management decisions / actions based on the receipt of an LPI / LPRI and / or the content (or functionality of the content) of the LPI / LPRI. For example, the WTRU may perform any one or a combination of the following: trigger RLF for the relay link on which the LPI was received; suspend, start, or restart HARQ feedback monitoring for RLF; initiate a relay reselection procedure; modify / reset any counters associated with HARQ feedback monitoring for RLF associated with the relay link; modify / change / select the conditions for triggering RLF associated with the relay link (e.g., changing the number of consecutive HARQ DTXs for RLF); change the transmission path from one relay link (the link on which the LPI was received) to a different relay link, which may be determined after relay selection; or notify upper layers.

[0134] In some embodiments, the source WTRU may trigger a SL RLF after receiving an LPI indicating a SL RLF. The source WTRU may delete all contexts associated with the PC5-RRC connection of the relay WTRU that transmitted the LPI and may notify the upper layers of the SL RLF. In some embodiments, the source WTRU may initiate a relay reselection after receiving an LPI indicating a SL RLF on the second link. The source WTRU may suspend transmission to the relay WTRU that sent the LPI, possibly while performing a reselection. Upon successful reselection, the source WTRU may notify the upper layers of the successful reselection and / or may change the source / destination IDs of any SLRBs transmitted via the original relay WTRU to new source / destination IDs provided by the upper layers (possibly after reselection). When the reselection fails, the source WTRU may instead trigger a SL RLF.

[0135] The source WTRU may determine / change 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 a HARQ-based transmission that triggers RLF based on any one or a combination of the following parameters reported in the LPI: In response to a HARQ-based transmission that triggers an RLF, the WTRU may also change the maximum number of consecutive DTXs from a first value to a second value upon receiving an LPI / LPRI, wherein the values of 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 (which may be associated with a single link or all relay links), a measurement of the latency associated with the data in the buffer (which may be associated with the relayed data), the TX resource pool configuration of the relay WTRU (which may be the same / 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, some measurement of the channel capacity / efficiency of the second link measured by the relay WTRU, and / or whether the transmission is to the relay WTRU or directly to the peer WTRU, and the number of hops associated with the relay path. With respect to measurement of latency associated with data in a buffer, for example, the WTRU may calculate an average latency metric for the data in its buffer by assigning a latency value to each packet (eg, based on the LCH associated with the packet).

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

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

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

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

[0140] For example, the WTRU may activate (e.g., via another relay WTRU) a second link to the same destination and / or deactivate the first link after receiving an LPI message, which may carry information that meets any criteria similar to those described herein (e.g., for triggering the LPI message). For example, a WTRU that receives an indication of RLF 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). For another example, if QoS does not require multiple active links to the same destination and the WTRU successfully reselects another link to the destination and / or another link to the same destination is active when the LPI is received, the WTRU may release the link.

[0141] 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 (e.g., after receiving an LPI or similar trigger for sending an LPI as described herein) or at the relay WTRU. 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 of not requiring an increase in the 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 itself may be considered a source WTRU in a multi-hop environment.

[0142] 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. A WTRU (source or relay) may make such a decision based on any one or a combination of the following information (each of which may be provided by or related to other WTRUs and / or determined by itself or related to itself): QoS or SLRB configuration, communication range requirements at the source WTRU and / or relay WTRU, synchronization source of the source WTRU and / or relay WTRU (possibly with reference to the destination WTRU), location of the source and / or relay (possibly with respect to each other or to another entity such as a NodeB (e.g., gNB) or the destination WTRU), CBR / CR / CQI / RSRP or similar measurements, number of possible relay WTRUs determined based on the relay discovery process, measurement quality criteria (e.g., RSRP measurements) of one or more possible relay WTRUs determined based on the relay discovery process or any function thereof (possibly compared to the current relay quality), number of relay hops, and / or Uu RSRP measurement of the link between the previous hop relay and the NW (in the case of a WTRU to network relay).

[0143] With respect to 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. With respect to communication range requirements at the source WTRU and / or relay WTRU, for example, based on the communication range requirements and possibly based on the location of the relay WTRU, the relay WTRU may not allow reselection. With respect to the synchronization source of the WTRU and / or relay WTRU, for example, reselection may be performed by the WTRU (remote or relay WTRU), which may result in maintaining the current synchronization source or supporting synchronization of a WTRU having the same synchronization source as, for example, the relay WTRU or the destination WTRU. With respect to the location of the source and / or relay, for example, the location may be determined based on the configured zone. With respect to measurement quality criteria, it may include, for example, the maximum RSRP of any possible relay WTRU, the average of the RSRPs of multiple / all possible relay WTRUs, the RSRP of a possible relay WTRU becoming better than a first threshold when the RSRP of the current relay becomes worse than a second threshold, and / or the RSRP of a possible relay becoming better than the current relay WTRU.

[0144] 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 due to reconfiguration of the reselected / reconfigured relay path to the destination is below a QoS / SLRB dependent threshold, the relay WTRU may perform relay reselection and / or reconfiguration of the second path after any trigger similar to the trigger for transmitting the LPI message. Otherwise, the relay WTRU may transmit an LPI message to the source WTRU, possibly indicating that relay reselection needs to be performed at the source WTRU. The source WTRU may perform relay reselection upon receipt of the LPI message.

[0145] For another example, if the RSRP of the selected relay is above a configured or pre-configured threshold, the relay WTRU may perform relay reselection and / or reconfiguration of the second path after any trigger similar to the trigger for transmission of the LPI message. The relay WTRU in such an example or any reselection process may further perform one of the following processes. 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 during the relay reselection. The relay WTRU may notify the source WTRU of any successful or failed reselection performed by the relay WTRU. For example, the WTRU may provide the source WTRU with updated configuration and / or QoS information of the updated link to the destination, such as the new cell ID of the new cell to which the previous hop relay WTRU is connected, the new number of hops to the destination, the 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 along the new path (e.g., relays of the NW), such as support for multi-carrier or support for full-duplex operation.

[0146] In another exemplary embodiment, the relay WTRU / source WTRU may provide a relay selection candidate to the source WTRU / relay WTRU in the transmission of the LPI or in response to the 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 the WTRU's own candidate with the measured quality metrics of the other WTRU candidates. For example, if the WTRU's candidate has a higher RSRP than the other WTRU candidates, the WTRU may determine that it will perform reselection. For example, if the RSRP of the WTRU's candidate is a better offset than the other WTRU candidates, the WTRU may determine that it will perform reselection, where 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 the information in the LPI.

[0147] In some embodiments, the WTRU may determine RLF based on a combination of a plurality of consecutive HARQ-based DTXs and receptions from a peer WTRU, where such receptions may be reception of an LPI or another transmission by a peer / relay WTRU. The source WTRU may determine a transmission received by a peer WTRU as being associated with the same source / destination ID as its own transmission, but with the source ID and destination ID swapped. Alternatively or in addition, the source WTRU may determine a reception by a peer WTRU as any reception received via a reverse control channel, as described in greater detail herein.

[0148] In one example, the WTRU may reset the number of consecutive DTXs in the RLF determination when receiving from a relay / peer WTRU. Such reception 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 an RLF based on a combination of the number of consecutive HARQ-based DTXs and the duration of the absence of reception from the relay WTRU. This time difference may further depend on the SLRB configuration and / or QoS.

[0149] In any of the examples described herein, successful reselection as a result of transmission / reception of an RLF and / or LPI message may be dependent on all actions being performed within a configured time or timer. The WTRU may start a timer, whereby expiration of the timer before the associated actions are completed may result in a failed reselection process, or the WTRU may determine that a period of time has elapsed before the associated actions are completed, which may result in a failed reselection process. Such a timer or duration may also depend on any one or a combination of QoS / SLRB configurations for one or more services established by relaying and / or CBR. With respect to QoS / SLRB configurations, 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 lowest value of the timer for each established SLRB, or consider the duration to be the lowest value of the timer for each established SLRB. With respect to CBR, for example, the source / relay WTRU may be configured with a reselection timer or reselection duration associated with a range of CBRs. Upon triggering reselection, the WTRU may set the timer to the value associated with the measured CBR at the time of the reselection trigger.

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

[0151] In some embodiments, a WTRU that triggers relay reselection may perform the events described in the following paragraphs (possibly in order).

[0152] The WTRU may initiate a relay selection process, which may involve transmitting / receiving discovery messages and / or link establishment messages from upper layers. Alternatively or in addition, the WTRU may rely on existing discovery message transmissions for relay selection.

[0153] The WTRU may select the relay with the best RSRP measurement as the possible relay WTRU. The WTRU may also use upper layer criteria (e.g., supported services) to select the relay (e.g., supporting the relay with the best RSRP measurement for which the upper layer service is supported). The WTRU may determine whether the WTRU can initiate a PC5-RRC configuration procedure with a peer WTRU (e.g., the selected possible relay WTRU). The WTRU may reuse the configuration of the bearer / PC5-RRC connection with the existing relay (e.g., SLRB configuration for the relay) for the configuration included in the PC5-RRC connection with the possible selected relay and / or the TX related parameters for the SLRB configuration. The WTRU may use the L2 source / destination ID provided by the upper layers (associated with the possible new relay WTRU that transmitted the discovery message) to transmit the PC5-RRC reconfiguration message and receive a response. Alternatively or in addition, the WTRU may use a default L2 source / destination ID pair for the relay reselection transmission, which may also be provided by the upper layers. Alternatively or in addition, the WTRU may transmit the PC5-RRC configuration message using the L2 source / destination ID provided to the new potential relay along with the discovery message transmission / reception. The use of the same / similar configuration may include any of the following: 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 the TX-related parameters of the SLRBs and / or the parameters of the SLRBs sent to the relay WTRU in the PC5-RRC reconfiguration message; using an equivalent configuration, whereby such configuration is derived from the original configuration to account for changes in any of the following characteristics of the newly selected relay / path (where such information may be provided prior to relay selection, e.g., in the discovery message, or stored, e.g., from a previous session with the relay); the difference in the number of hops between the old link and the new link; the difference in the capabilities of the new relay (e.g., the number of carriers supported); and / or the difference in measurements reported by or made by the new relay. An equivalent configuration may be configured or pre-configured for each configuration from the network.

[0154] If the PC5-RRC configuration procedure with the selected possible relay is successful, the WTRU may indicate to the upper layers the successful relay selection or reselection procedure. The WTRU may also perform any 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 the upper layers the successful reselection of the relay WTRU and indicate the source / destination IDs 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 IDs associated with the current relay with the new source / destination IDs associated with the relay WTRU in the PC5-RRC context of the current relay.

[0155] Upon receiving a failure in the PC5-RRC Configuration Response message, the WTRU may perform any of the following actions or any combination of the following subsequent actions. The WTRU may re-initiate the PC5-RRC reconfiguration procedure with another possible relay (e.g., which may be the relay WTRU with the next best RSRP). For example, the WTRU may repeat the PC5-RRC configuration procedure with multiple possible selected relays in order of best RSRP measurement until the PC5-RRC reconfiguration procedure is successful. For another example, the WTRU may repeat the PC5-RRC configuration procedure with any (e.g., randomly selected) possible relay WTRU whose RSRP measurement meets some criteria (e.g., above a threshold) until a successful PC5-RRC reconfiguration procedure. For another example, the WTRU may repeat the PC5-RRC configuration procedure with different possible relays until all possible relays with a measured RSRP above a threshold have been attempted or until a successful PC5-RRC reconfiguration procedure. For another example, the WTRU may repeat the PC5-RRC configuration procedure with different possible relays until a timer expires, as determined as described herein, and a given duration has elapsed. Any combination of the conditions in the above examples is possible for the WTRU behavior when determining whether to re-initiate the PC5-RRC reconfiguration procedure with another possible relay. The WTRU may indicate a reselection failure to upper layers upon at least one of the following two conditions: when a maximum number or time associated with reselection is exceeded and / or after failed PC5-RRC reconfiguration with all possible relay WTRUs that may have an RSRP above a threshold.

[0156] Figure 6 is a flow chart of an exemplary re-establishment or recovery process. Figure 6As shown, at 601, 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 at 602, e.g., in accordance with one or more other procedures described herein. As shown at 603, upon determining that a SL RLF has occurred (e.g., consistent with one or more procedures of this specification), the remote WTRU may then select an appropriate relay when connecting to a relay, as shown at 604. Figure 6 As shown, such a suitable relay may be the relay with the highest RSRP. Alternatively or in addition, any suitable relay with a SL RSRP above a threshold may be selected. Suitable relays may be those relays provided by the network in a configuration list. Suitable relays may be those relays whose measured SL RSRP is above a threshold, satisfy some upper layer criteria associated with the discovery message, and have an allowable PLMN. It should be understood that solutions according to embodiments not depicted may involve selecting one or more suitable relays according to the procedures described herein. As shown at 605, if all relays from the set of alternative relays configured for the remote WTRU are exhausted, for example, reconfiguration of all alternative relays has failed or otherwise no suitable alternative relay can be found, the remote WTRU may determine that recovery has failed. If a suitable alternative relay can be found and selected, then at 606, the remote WTRU may transmit a SL reconfiguration message to the selected relay to configure one or more of the SLRBs. The remote WTRU may use the same SLRB configuration as the SLRB configuration previously configured at the remote WTRU by the previous relay (e.g., SL RLC channels for transmitting SLRB1, such as all SL RLC channels). At 607, the remote WTRU may determine whether the reconfiguration was successful, for example, based on the response received from the selected alternative 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 the reconfiguration with a different suitable relay. The remote WTRU may retry such a process until the list of suitable relays has been exhausted or until a timer associated with relay reselection expires, or until a determined duration has elapsed. If the reconfiguration for the newly selected relay is determined to be successful, for example, based on the response received from the newly selected relay, then at 608 the remote WTRU may update its current relay with the new L2 ID of the newly selected relay and, at 609, transmit a Uu Re-establishment Request message using its existing SL RLC channel for SRB1 transmission, but the L2 ID may be changed to the new L2 ID. Specifically, the remote WTRU may maintain the same configuration of one or more SL RLC channels for transmission on the old relay as on the new relay, with the L2ID replaced.

[0157] exist Figure 6 In the example shown, in the case of a recovery failure, the remote WTRU may delete its context and move to RRC_IDLE, triggering a relay reselection procedure, and / or triggering a cell reselection procedure. In an embodiment, the relay reselection may result in a new or different set of suitable relays compared to the set of relays provided by the NW.

[0158] In some embodiments, the WTRU may perform relay selection or reselection and / or restoration (e.g., after RLF) of a relay from a set of configured relay WTRUs provided by the network. Specifically, the WTRU may determine the relay WTRU to be selected, reselected, or restored by selecting a WTRU from a list of WTRUs provided by the network. Such a list may be provided directly via Uu (e.g., when the WTRU is in coverage). Alternatively or in addition, such a list may be provided by RRC signaling sent via the currently connected relay WTRU. When any condition defined herein is detected (e.g., SL RLF with a relay WTRU), the remote WTRU may select one of the relays in the list of relays provided by the network based on any one or a combination of the following: measurements of the relays at the time of reselection or restoration, a ranking and / or priority associated with each relay, and / or the current location of the remote WTRU. With respect to measurements of the relays at the time of reselection or restoration, for example, the remote WTRU may select the relay WTRU with the highest RSRP on the list. For another example, the remote WTRU may select any relay WTRU with an acceptable RSRP (e.g., an RSRP above a threshold). With respect to the ranking 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 of the relay WTRU associated with the highest priority. For another example, the remote WTRU may also combine other factors described herein (e.g., RSRP measurements of the relays) with such priorities to determine the relays. With respect to the current location of the remote WTRU, for example, the network may provide each relay WTRU with a set of allowed locations (e.g., zone IDs), and the remote WTRU may select one or more relays associated with the current WTRU location (e.g., its current zone ID).

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

[0160] A WTRU may initiate recovery to a relay WTRU, which may have stored a PC5-RRC configuration to the relay WTRU, by sending an initial activation message over the SL, whereby such an activation message may include one or more of the following: a dedicated activation PC5-RRC message, SL MAC CE, or SCI addressed to the L2 destination ID of the new relay; a transmission of any UL or SL data whereby the WTRU may change the L2 destination ID to the L2 destination ID 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 at the remote WTRU for recovery. Upon receiving such a message, the relay WTRU may activate a similar stored configuration for reception / transmission to the remote WTRU.

[0161] If a WTRU has a PC5-RRC connection to a WTRU-to-network relay (e.g., it has a PC5-RRC context in which the WTRU is identified as or specific to a relay), then the WTRU may be considered to be connected to the network via a WTRU-to-network relay. Specifically, the WTRU may stop performing a subset of procedures to the network and be considered to be connected via the relay when an indication from upper layers that a PC5-link has been initiated with the relay WTRU and / or one or more of the PC5-RRC messages indicating a connection for the relay are received. For example, the WTRU may receive a PC5-RRC reconfiguration message that includes an indication to configure an indication associated with a connection to the WTRU-to-network relay. For 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 SLQoS entities, configuration for the Uu protocol layer (e.g., PDCP / SDAP), configuration / conditions for falling back to Uu, and / or configuration for monitoring Uu when connected to the WTRU to the network relay, including PDCCH configuration, Uu RLF configuration, and / or CQI reporting configuration. For example, a WTRU may receive a PC5-RRC message that contains an embedded Uu RRC reconfiguration message that configures certain aspects of the Uu connection, as described herein.

[0162] When connected to a WTRU to a network relay, such a WTRU may stop performing certain procedures to Uu. For example, the WTRU may stop monitoring for RLF on Uu (legacy RLF) and start a relay-based link monitoring procedure with the relay WTRU. The WTRU may also perform new or restricted RLF procedures with the network (on Uu), as described herein. As another example, the WTRU may stop receiving system information from the network and receive system information from the relay WTRU. As another example, the WTRU may stop monitoring for paging and receive paging from a peer WTRU. As another example, the WTRU may stop monitoring PDCCH for DL allocations and UL grants from the network. Alternatively or in addition, the WTRU may perform some restricted PDCCH monitoring, as described herein. As another example, the WTRU may suspend all DRBs. As another example, the WTRU may replace some or all DRBs with corresponding relay DRBs. As another example, the WTRU may create a relay DRB corresponding to a Uu DRB, which may be suspended.

[0163] A WTRU connected via a WTRU-to-network relay may trigger a relay RLF procedure when an RLF associated with the WTRU-to-network relay is detected. Such detection may be a result of any of the triggers described herein.

[0164] When an RLF associated with a WTRU to network relay is triggered, the WTRU may perform any or a combination of the following actions. For example, the WTRU may release the PC5-RRC context associated with the WTRU to network relay. The WTRU may release the protocol entities (e.g., adaptation layer) used 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 RLF has not been triggered with respect to the network, the WTRU may resume its Uu context, including any suspended Uu bearers. If the WTRU is in network coverage or RLF has not been triggered with respect to the network, the WTRU may release routing of the Uu bearers via the SL bearers / channels and resume transmission of its Uu QoS flows or transmission of data from its Uu QoS flows via the Uu bearers. If the WTRU is in network coverage, the SDAP and / or PDCP layer of the WTRU may reroute the QoS flows / bearers from SL to Uu. The WTRU may initiate WTRU to network relay reselection. If the WTRU is in network coverage or RLF has not been triggered with respect to the network, the WTRU may resume normal Uu procedures that were suspended while connected to the WTRU-to-network relay. If the WTRU is in network coverage or RLF has not been triggered with respect to the network, the WTRU may perform procedures for accessing the network as described herein. If the WTRU is in network coverage or RLF has not been triggered with respect to the network, the WTRU may initiate decoding of the PDSCH for transmission by the network. If the WTRU is in network coverage or RLF has not been triggered with respect to the network, the WTRU may resume any suspended Uu radio bearers.

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

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

[0167] In some embodiments, the WTRU may be configured to enable / start DRX with the NW when initiating a connection with the WTRU to the network relay. The WTRU may receive such a configuration for DRX from the network before the connection with the WTRU to the network relay (e.g., via SIB or dedicated RRC signaling). Alternatively or in addition, the WTRU may enable DRX when the DRX configuration is received via the relay WTRU (e.g., over PC5-RRC) after establishing a PC5-RRC connection with the relay WTRU.

[0168] The WTRU may be configured to receive a wake-up signal (WUS) that may control the monitoring of the PDCCH and PSCCH. For example, the WUS may determine whether to monitor the PDCCH instead of the PSCCH (or vice versa) for a period of time (e.g., a DRX cycle). For example, the WTRU may monitor the WUS over the Uu at a configured or pre-configured time. If a WUS is detected, the WTRU may monitor the PDCCH for the DRX cycle. Otherwise, as in some embodiments, the DRX cycle may be skipped and only monitoring of the SL may continue.

[0169] When connected to a WTRU-to-network relay, the WTRU may determine the intensity of PDCCH monitoring based on measurements / criteria associated with the PC5-RRC connection to 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 time slots monitored per period, and / or one or more search spaces associated with the monitored PDCCH.

[0170] The WTRU may determine the intensity of PDCCH monitoring based on any one of the RSRP and / or the value of any parameter measured on the SL and / or reported to the relay WTRU, the counter of the timer associated with the SLRLF, or the expiration of the duration associated with the SL RLF. With respect to the RSRP measured on the SL and / or reported to the relay WTRU, for example, the WTRU may be configured or pre-configured with a mapping between the RSRP range for measurement / reporting and the periodicity of PDCCH monitoring. The remote WTRU may be configured to report the SL RSRP measurements to the relay WTRU. The relay WTRU may then forward such RSRP measurements to the network. Alternatively or in addition, 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 the value of any parameter, counter, timer, or duration related to SL RLF, for example, for a case where a timer like T310 associated with SL link monitoring is running or a duration associated with SL link monitoring has not elapsed, the WTRU may be configured with a PDCCH decoding strength, and for a case where a timer like T310 is not running or a duration associated with SL link monitoring has elapsed, the WTRU may be configured with another PDCCH decoding strength. For example, when the number of HARQ-DTXs (continuous or within a window) is below a threshold and the number of HARQ-DTXs (continuous or within a window) is above a threshold, the WTRU may be configured with a PDCCH decoding strength.

[0171] The WTRU may trigger a relay RLF procedure upon any of the following conditions for reception on relay to Uu: reception of a schedule on the PDCCH (e.g., a DCI scheduled with the WTRU's C-RTNI or a new RNTI indicating resumption of network-based scheduling), where such schedule may be used for UL and / or DL data transmission on the Uu; reception of an RRC message to resume Uu-based (e.g., non-relay) operation, where such an RRC message may be received directly on the Uu link; reception of a MAC CE on the Uu; reception of the WTRU at a configured Uu monitoring opportunity; 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 SL RLF or a WUS with an explicit indication to trigger SL RLF). With respect to reception of an RRC message to resume Uu-based operation, for example, when the WTRU is connected to a WTRU-to-network relay, all Uu DRBs may be suspended and SRBs may be maintained. When the WTRU receives an RRC message from the network on SRBs via Uu, the WTRU may trigger a relay RLF and resume DRBs.

[0172] The WTRU may perform RLF-like operations on both Uu and SL simultaneously. The WTRU may notify the network of the RLF on one of the links via the other link. For example, upon detection of a SL RLF with a relay WTRU, the remote WTRU may perform an access procedure that may include any of the execution of a RACH procedure (which may be performed if the TAT has expired) and / or the transmission of an RRC message (such as SLUEInformation, RRCResume, or UEAssistanceInformation) or another logically equivalent message. The WTRU may also indicate the occurrence of a SL RLF in such a message. Upon detection of a Uu RLF, the WTRU may notify the network of such RLF via the transmission of a Uu RRC message via the relay WTRU (e.g., encapsulated in PC5-RRC).

[0173] When connected to a WTRU-to-network relay, the WTRU may trigger a re-establishment procedure after an RLF. In such a procedure, the WTRU may indicate the relay WTRU (e.g., L2 source / destination ID) in the re-establishment request message. Upon detecting a UuRLF and / or a failed re-establishment, the WTRU may operate as if it were out of coverage.

[0174] In some embodiments, the WTRU may release the PC5-RRC connection (e.g., releasing all context associated with the relayed PC5-RRC connection and notifying upper layers) upon the occurrence of a Uu RLF that results in reselection of a cell that does not support an existing relay, upon receipt of a reestablishment response, and / or upon any reestablishment procedure. With respect to a Uu RLF that results in reselection of a cell that does not support an existing relay, for example, the WTRU may be configured or pre-configured with a set of relays that may be used on that cell, and if the selected cell does not support the current relay WTRU, the WTRU may trigger a PC5-RRC release. With respect to receipt of a reestablishment response, for example, the WTRU may receive an indication in a reestablishment response message to release the PC5-RRC connection. With respect to any reestablishment procedure, for example, the WTRU may be configured to release the PC5-RRC connection upon triggering the Uu reestablishment procedure.

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

[0176] The remote WTRU may be configured to measure CSI on Uu via RRC signaling (e.g., directly on Uu or via RRC encapsulated within PC5-RRC). Alternatively or additionally, the remote WTRU may be configured with conditions for measuring / transmitting CSI measurements based on any one or a combination of the relay WTRU's measured quality, the measured quality on Uu, the presence of another relay, the location of the remote WTRU and / or the relay WTRU, and / or QoS and / or other bearer configurations. With respect to the relay WTRU's measured quality, for example, when the relay RSRP drops below a threshold, the remote WTRU may perform / transmit Uu CSI measurements. For another example, when the relay RSRP is between a first threshold and a second threshold, the remote WTRU may perform / transmit Uu CSI measurements. For another example, when the relay RSRP changes by a certain amount, the remote WTRU may perform / transmit Uu CSI measurements. With respect to the measured quality on Uu, for example, when the Uu RSRP is above a threshold, the remote WTRU may perform / transmit Uu CSI measurements. As another example, the remote WTRU may perform / transmit Uu CSI measurements when the Uu RSRP is between a first threshold and a second threshold. With respect to the presence of another relay, for example, when there are no other detected possible relays with a measured RSRP above a threshold, the remote WTRU may perform / transmit Uu CSI measurements. With respect to the location of the remote WTRU and / or the relay WTRU, for example, the remote WTRU may be configured with a set of zones in which it should report CSI measurements. For example, the remote WTRU may report CSI measurements based on the reported zone of the relay WTRU, possibly in combination with its own location (for example, 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 determine 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 bearers.

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

[0178] In some embodiments, the remote WTRU may transmit 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 a network configuration, its speed, the CBR / CR measured at the remote WTRU and / or indicated by the relay WTRU, and / or the flow control indication / information provided by the relay WTRU. If the time since the triggering of the CSI measurement exceeds a threshold, the remote WTRU may discard the CSI measurement.

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

[0180] In some embodiments, the relay WTRU may transmit CSI measurements from one or more remote WTRUs to the network. For example, the relay WTRU may transmit a MAC CE or RRC message (or another logically equivalent message) to the network containing CQI measurements received from one or more remote WTRUs.

[0181] In some embodiments, the relay WTRU may transmit a MAC CE or a logically equivalent message that includes a CSI report 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.

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

[0183] The relay WTRU may trigger a MAC CE for forwarding CSI measurements upon receipt of a Uu CQI report from any remote WTRU and / or upon expiration of a timer, wherein such a timer may be started upon receipt of a Uu CQI report from any remote WTRU. For example, the relay WTRU may set a timer upon receipt of a Uu CQI report from a remote WTRU (if such a timer is not running). While the timer is running, the relay WTRU may trigger the transmission of the CSI measurement for the remote WTRU along with any other CQI reports received (possibly from other WTRUs). The relay WTRU may also transmit a CQI report immediately upon receipt of the CQI report (e.g., before expiration of a running timer or before a duration has elapsed) based on certain conditions associated with the received CQI report (e.g., upon receipt of a CQI report with a specific value for the trigger type, priority indication, and / or timestamp).

[0184] In some embodiments, the WTRU may store the Uu configuration of the cell to which the WTRU is connected when establishing a WTRU-to-network relay connection. The WTRU may reuse such stored configuration as part of a recovery procedure triggered based on any of the conditions described herein (e.g., when a relay link fails). Alternatively or in addition, 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.

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

[0186] 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. With respect to the 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). If the relay WTRU to which the WTRU is connected when the recovery is triggered is associated with such a candidate configuration, the remote WTRU may consider the stored Uu candidate configuration to be valid for recovery. For example, the remote WTRU may receive a list of valid stored candidate cells from the relay WTRU, and when recovery is triggered after being connected to the relay WTRU, the WTRU may consider the stored configuration of each cell to be valid. 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 identifier from the relay WTRU (such as directly in 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 to be received to consider the cell configuration valid for recovery when connected to the relay. For example, such an identifier may correspond to a RAN area ID relayed by the relay WTRU in the system information.

[0187] The remote WTRU may delete the stored Uu candidate configurations / cells when reselection of the relay WTRU occurs for an invalid stored Uu candidate configuration / cell. Alternatively or in addition, the WTRU may store all configured candidate configurations but may only consider one or more valid stored cell configurations as part of the recovery process.

[0188] The WTRU may perform a recovery procedure (e.g., a CHO procedure or similar procedure) over Uu using the stored Uu configuration following any SL-related conditions that trigger recovery, as described herein. The WTRU may also perform such a recovery procedure under any or a combination of the following conditions: the WTRU performs cell reselection to a cell for which the WTRU has a valid stored Uu candidate configuration; the cell to which the reselection is performed has a certain quality (e.g., an RSRP above a threshold); and / or the WTRU detects a cell with a certain quality (e.g., an RSRP above a threshold) for which the WTRU has a valid stored Uu candidate configuration.

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

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

[0191] When directly connected via Uu and / or when connected via a relay WTRU, the remote WTRU may trigger a cell selection or relay selection procedure. Such a cell / relay reselection procedure may be associated with a trigger that would normally trigger a Uu re-establishment in Uu. For example, upon triggering a Uu RLF, the remote WTRU may initiate a re-establishment procedure considering possible relay WTRUs. Such a new re-establishment procedure may begin with the initiation of a cell reselection and / or relay selection procedure. Either or both of cell reselection and relay reselection may be initiated.

[0192] The remote WTRU may perform the cell selection, cell reselection, relay selection, and / or relay reselection procedures sequentially (e.g., one first and then the other). In this case, the remote WTRU may determine the order of such procedures. Alternatively or in addition, the remote WTRU may perform both procedures in parallel. For example, the remote WTRU may initiate reestablishment of the cell to the relay WTRU or directly to the cell, depending on which of the relay reselection or cell reselection procedures completes first (and provides a suitable cell / relay).

[0193] The WTRU may determine whether to perform neither cell selection nor relay selection, to perform either or both of cell selection and relay selection, and / or which of cell selection and relay selection to perform first based on any one 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 an L2 relay, for example, in its 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 initiated a relay reselection procedure (e.g., due to another trigger, such as Uu RSRP, or due to some explicit / implicit indication by the network to initiate such a reselection); based on the current Uu RSRP measurement (e.g., relative to a threshold); based on the network configuration; and / or based on the SL measurement.

[0194] Regarding whether the current cell supports relay configuration, for example, if the current cell supports relay configuration, the remote WTRU may initiate relay selection (e.g., before or after cell selection) as part of the re-establishment procedure. 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 when a trigger (e.g., Uu RLF) occurs, the remote WTRU may not perform either cell selection or relay selection. For another example, if the remote WTRU is not PC5-RRC connected to a relay WTRU when a trigger (e.g., Uu RLF) occurs, the remote WTRU may initiate relay selection.

[0195] With respect to whether the remote WTRU is connected via Uu or via a relay WTRU, for example, when the re-establishment procedure is triggered when connected via a relay, the remote WTRU may perform cell reselection before relay reselection (and vice versa). In some instances, when connected via a relay, the remote WTRU may only perform relay selection (and not cell selection) (and vice versa). With respect to whether the WTRU has already initiated a relay reselection procedure (e.g., due to another trigger, such as Uu RSRP, or due to some explicit / implicit indication 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 the cell / relay reselection procedure, or may only trigger the cell reselection procedure. Otherwise, as in some instances, the remote WTRU may trigger relay reselection or both procedures. For example, the remote WTRU may trigger relay reselection when the Uu RSRP is below a threshold and / or when the network sends an indication to trigger reselection. Such one or more triggers may occur before initiating re-establishment. If a suitable relay has been found before the re-establishment trigger, the remote WTRU may not trigger cell and / or relay reselection. If the remote WTRU has a PC5-RRC connection to a suitable relay, the remote WTRU may not trigger cell and / or relay reselection.

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

[0197] Regarding determining whether to not perform cell selection and relay selection, to perform either or both of them, and / or which one to perform first based on the network configuration, for example, the remote WTRU may be configured with an order for cell selection / relay selection. Such configuration may be explicit (e.g., an indicator in a 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 a bearer / QoS flow for which the WTRU should initiate one or another selection procedure, and the one or another selection procedure may be performed in a specific order.

[0198] Regarding determining whether to perform neither cell selection nor relay selection, to perform either or both of them, and / or which one to perform first based on the SL measurement, for example, if the measured CBR is above a threshold, the remote WTRU may perform only cell selection, or perform cell selection before relay selection. Otherwise, the remote WTRU may perform both cell selection and relay selection, or perform relay selection before cell selection.

[0199] For both cell selection and relay selection, the remote WTRU may use a single timer (e.g., similar to T311) or determine whether a duration has elapsed. For example, the remote WTRU may start a timer (T3xx) upon a re-establishment trigger and may move to RRC_IDLE upon failing to find 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 only cell selection, may use a second timer or duration when configured to perform only relay selection, and may use a third timer or duration when configured to perform both cell selection and relay selection. In addition, 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.

[0200] 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 process) or upon determining that a duration has elapsed. Alternatively or in addition, the remote WTRU may trigger cell selection upon expiration of a relay selection-related timer (T3yy) or upon determining that a duration associated with relay selection has elapsed.

[0201] The remote WTRU may stop a timer such as T311 when it selects a cell or a relay (depending on whichever is found first). Alternatively or in addition, the remote WTRU may continue a timer such as T311 until the remote WTRU selects / finds a relay and a cell. For example, if the remote WTRU finds a cell when starting T311, and T311 has not expired, the remote WTRU determines that the duration has not elapsed and the remote WTRU may start / continue relay selection until a suitable relay is also found. Alternatively or in addition, if a timer such as T311 or the duration expires, the remote WTRU may initiate re-establishment of a suitable cell upon expiration of the timer or the duration.

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

[0203] For example, the remote WTRU may determine such a threshold based on the current Uu RSRP measurement.For example, when the Uu RSRP when the UuRLF / re-establishment is triggered is high, the remote WTRU may set the SL RSRP threshold used to determine whether the relay is suitable to a higher value.

[0204] In some examples, the remote WTRU may perform re-establishment on a predetermined / selected relay. Upon one or more triggers associated with re-establishment (e.g., Uu RLF, SL-RLF), the remote WTRU may perform re-establishment on a predetermined or predefined relay WTRU. For example, the remote WTRU may immediately perform re-establishment on a relay WTRU without requiring 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.

[0205] With respect 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 one of the one or more provided relay WTRUs. With respect to determining a relay WTRU based on an existing PC5-RRC connection, for example, if the remote WTRU is already PC5-RRC connected to a relay WTRU, the remote WTRU may perform re-establishment with the relay WTRU.

[0206] Regarding determining a relay WTRU based on measurements reported to the network, for example, a remote WTRU may be configured with RRM-like measurements of a SL relay. The remote WTRU may trigger re-establishment directly to a relay WTRU that is in the relay list reported by the WTRU to the network in the reported measurements.

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

[0208] The remote WTRU may perform re-establishment via a relay or directly via Uu. In one example, the WTRU may determine this based on a first suitable entity (e.g., a cell or a relay) determined at the remote WTRU. For example, the remote WTRU may run cell selection and relay selection concurrently and may select the first entity that is appropriate to initiate re-establishment. For example, the remote WTRU may be configured with a sequential ordering to perform cell selection versus relay selection. For example, if the remote WTRU performing relay selection finds a suitable relay (e.g., SL RSRP above a threshold, higher layer criteria are met, 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 above a threshold and allowed PLMNs), the remote WTRU may initiate re-establishment via the relay.

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

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

[0211] The remote WTRU may include in the re-establishment request message an identification of the relay WTRU to which the remote WTRU was previously connected, an identification 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 previously connected interface. For example, the remote WTRU may use different re-establishment cause values to indicate whether the failure to trigger re-establishment occurred when the remote WTRU was connected directly via Uu or when the remote WTRU was connected via a relay.

[0212] The relay WTRU may determine the cause value (establishment cause, recovery cause, re-establishment cause) included in its own connection establishment / recovery / re-establishment signaling with the network. The relay WTRU may use a dedicated cause value for relay WTRU connection establishment / recovery due to a remote WTRU attempting to access the network. Alternatively, the relay WTRU may reuse some of the existing cause values currently defined for its own access as well as access attempts initiated by the remote WTRU.

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

[0214] With respect to the RLC channel on which data is received from the remote WTRU, for example, the relay WTRU may be configured, preconfigured or predefined to use a first cause value for connection establishment / reestablishment / recovery triggered by receiving data from the first RLC channel, and to use a second cause value when triggered by receiving data from the second RLC channel. For example, the specific cause value used by the relay WTRU may be predefined as part of the RLC channel configuration. For example, the remote WTRU may select a specific SL-RLC channel for transmission associated with different cause values determined at the remote WTRU. For example, the remote WTRU may transmit Uu data to be relayed on 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 the remote WTRU may use the second RLC channel when the data is associated with one or more second cause values (e.g., other cause values).

[0215] For example, with respect to Uu RRC messages / procedures triggered by the remote WTRU, the relay WTRU may use a first cause value for a connection establishment procedure, a second cause value for a connection re-establishment procedure, and a third cause value for a resumption procedure triggered by the remote WTRU. The relay WTRU may use information from the remote WTRU using other implementations (e.g., RLC channels, explicit signaling, etc.) to determine the procedure being performed by the remote WTRU, which may indicate the procedure and / or knowledge of the remote WTRU's RRC state. For example, when the relay WTRU receives data on the SL-RLC channel associated with SRB0, the relay WTRU may determine the procedure to be a connection establishment procedure. For example, when the SL-RLC channel for SRB1 is in use and the remote WTRU is in RRC_INACTIVE, the relay WTRU may determine the procedure to be resumed, and when data is received on the SL-RLC channel for SRB1 and the remote WTRU is in RRC_CONNECTED, the relay WTRU may determine the procedure to be re-established. The relay WTRU may determine the remote WTRU's RRC state from the remote WTRU or from the network. For example, the remote WTRU may indicate (eg, explicitly or using other methods described herein) a particular procedure (eg, resume, connection establishment, or connection re-establishment) that is initiated by the remote WTRU.

[0216] For example, with respect to resources or a subset of resources on which data is received from a remote WTRU, the remote WTRU may be configured or preconfigured with a set of time / frequency resources on which the remote WTRU may send transmissions associated with different access categories and / or cause values. For example, the remote WTRU may be configured or preconfigured to select a first cause value when it receives a transmission from the remote WTRU on a particular configured or preconfigured set of resources, and to select a second cause value when it receives a transmission on a second set of resources, wherein the remote WTRU may be associated with one or more predefined RLC channels.

[0217] Regarding 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 a SL MAC CE, an adaptation layer control message, a SL RRC message, a PHY signal (e.g., SCI), or other explicit signaling indicating the establishment cause. For example, when the remote WTRU's establishment cause is a value or a subset of values, the remote WTRU may send an explicit indication. The relay WTRU may select its own establishment cause from the establishment causes received from the remote WTRU. For example, when the remote WTRU's access is associated with a specific cause value (e.g., emergency access), the remote WTRU may send an indication over the SL (e.g., in a SL MAC CE, SL RRC message, or SCI). In this case, the relay WTRU may use a first cause value (e.g., emergency access) and a second cause value (e.g., a new cause value) for other cases. For example, the remote WTRU may send its own connection establishment / / re-establishment / resumption cause value to the relay WTRU over Uu. If the cause value is one of the subset of cause values, the relay WTRU may use the first cause value (eg, emergency access), otherwise the relay WTRU may use the second cause value (eg, new cause value).

[0218] Based on the cause value (or information thereof) received from the remote WTRU, the relay WTRU may use a new cause value or an existing cause value for its own access. 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 the mapping. Such mapping may also depend on, for example, the RRC state of the remote / relay WTRU, the relay WTRU's own access category, the access categories of other remote WTRUs connected to the relay WTRU (the relay WTRU may be in a specific RRC state), network preferences, sidelink configuration and / or measurements (e.g., CBR, CR, SL, RSRP, and / or resource load at the relay).

[0219] For example, with respect to the RRC state of a remote / relay WTRU, the relay WTRU may be configured with different mappings depending on the RRC state of the remote WTRU or its own RRC state. For example, with respect to the relay WTRU's own access category, 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 on the highest / lowest access category of the other remote WTRUs, for example, where such remote WTRUs may be in a particular RRC state. For example, the relay WTRU may determine a cause value based on a mapping of a received cause value (or cause value information) to a relay cause value, where such a mapping may be defined as being specific to the access category of a particular connected remote WTRU (e.g., having the highest / lowest access category).

[0220] Regarding network preference / configuration, for example, the network may use SIB / RRC signaling to change the mapping. For example, the relay WTRU may receive one or more explicit mappings 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) that may indicate that the relay WTRU should use a first mapping instead of a second mapping.

[0221] Regarding measurements of the sidelink (e.g., CBR, CR, SL RSRP and / or resource load at the relay), for example, the relay WTRU can change the mapping (or determine the mapping) based on measurements of the sidelink channel (such as measurements of CBR, measurements of CR, or measurements of relay load).

[0222] In some embodiments, the relay WTRU may determine the recovery cause for its own recovery procedure based on the access identity of the remote WTRU. The relay WTRU may receive the access identity of the remote WTRU 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 may determine the access identity based on the knowledge of whether the remote WTRU requests emergency services. Alternatively or in addition, the relay WTRU may receive the access identity of the remote WTRU from the network (for example, in dedicated RRC signaling). The remote WTRU may send the access identity to the connected relay WTRU when a Uu connection is established via the relay. Alternatively or in addition, the remote WTRU may send the access identity after mobility (for example, reselection and PC5-RRC connection from a direct (over Uu) link to a new relay or connected mode mobility). When connected to a relay WTRU, the remote WTRU may trigger a SL transmission to the relay WTRU when the access identity changes.

[0223] When the relay WTRU is in RRC_INACTIVE mode, the relay WTRU may use the access identity of the remote WTRU when determining its establishment cause. Alternatively or in addition, when the remote WTRU is in RRC_INACTIVE mode, the relay WTRU may use the access identity of the remote WTRU when determining its establishment cause. Alternatively or in addition, the relay WTRU may use the access identity of the remote WTRU when determining its establishment cause only when both the relay WTRU and the remote WTRU are in RRC_INACTIVE mode. When the relay WTRU has received a paging for the remote WTRU, the relay WTRU may use the access identity of the remote WTRU when determining its establishment cause. Specifically, the relay WTRU may determine whether the I-RNTI of the remote WTRU has been included in the paging message of the remote WTRU to determine whether to use the access identity of the remote WTRU. 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 PO of the remote WTRU contains the I-RNTI. For example, the relay WTRU may make such a determination based on whether the paging message contains an indication of the presence of an I-RNTI for the remote WTRU.

[0224] The relay WTRU may determine a time period after receiving a paging message intended for the remote WTRU (e.g., based on configuration or pre-configuration) during which the relay WTRU should determine its establishment cause based on the remote WTRU's access identity. Such behavior may be used if the relay WTRU initiates a resume / establishment upon receiving a remote WTRU transmission in response to a paging. Alternatively, a relay WTRU in RRC_INACTIVE / RRC_IDLE may initiate a connection establishment / resumption immediately upon receiving a paging message intended for the remote WTRU and may use the remote WTRU's access identity for such connection establishment / resumption to determine the establishment cause.

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

[0226] 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 the remote WTRU initiates a re-establishment procedure, set the establishment cause to highPriorityAccess if the remote WTRU initiates a re-establishment procedure, and / or set the establishment cause to a new cause value for relay access in other cases. A relay WTRU in RRC_INACTIVE mode may set the establishment cause to emergency if the remote WTRU has established emergency services and the remote WTRU initiates a re-establishment procedure, set the establishment cause to highPriorityAccess if the remote WTRU initiates a re-establishment procedure, set the establishment cause to a value determined based on the remote WTRU's access identity if the remote WTRU has received a paging message from the relay WTRU, and set the establishment cause to a new cause value for relay access in other cases.

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

Claims

1. A wireless transmit / receive unit (WTRU), the WTRU comprising: A processor and a transceiver, wherein the processor and the transceiver are configured to: Detecting sidelink radio link failure; in response to detecting the sidelink radio link failure, starting a first timer based on a first timer value associated with selection of a candidate node, wherein the candidate node is a relay node or a network node; selecting the candidate node for connection reestablishment, wherein the selected candidate node is the relay node; receiving configuration information from at least one of the relay node or the network node, wherein the configuration information includes at least a second timer value associated with a second timer associated with the connection reestablishment; stopping a first timer when selecting the candidate node; determining whether the configuration information further includes a third timer value associated with the second timer, wherein the third timer value is to be used for the connection re-establishment when the WTRU is configured as a remote WTRU; In a case where the configuration information further includes the third timer value, starting the second timer using the third timer value when selecting the candidate node; In a case where the configuration information does not include the third timer value, starting the second timer using the second timer value when selecting the candidate node; and A reestablishment request message is transmitted to the relay node.

2. The WTRU of claim 1 , wherein: The second timer value is associated with the connection re-establishment via the network node.

3. The WTRU of claim 1 , wherein the processor and the transceiver are further configured to: In case the WTRU does not receive a response to the re-establishment request message before the second timer expires, enters idle mode.

4. The WTRU of claim 1 , wherein: The third timer value is greater than the second timer value.

5. The WTRU of claim 1 , wherein: The first timer is a T311 timer.

6. The WTRU of claim 1 , wherein: The second timer is a T301 timer.

7. The WTRU of claim 1 , wherein: The detection of the sidelink radio link failure includes one or more of: determining a number of consecutive hybrid automatic repeat request (HARQ) discontinuous transmissions (DTX) performed, or determining a number of consecutive retransmissions performed.

8. The WTRU of claim 1 , wherein: The configuration information includes at least one system information block (SIB).

9. The WTRU of claim 1 , wherein: Selecting the candidate node for the connection re-establishment includes measuring signal quality associated with the candidate node.

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

11. A method performed by a wireless transmit / receive unit (WTRU), the method comprising: Detecting sidelink radio link failure; in response to detecting the sidelink radio link failure, starting a first timer based on a first timer value associated with selection of a candidate node, wherein the candidate node is a relay node or a network node; selecting the candidate node for connection reestablishment, wherein the selected candidate node is the relay node; receiving configuration information from at least one of the relay node or the network node, wherein the configuration information includes at least a second timer value associated with a second timer associated with the connection reestablishment; stopping a first timer when selecting the candidate node; determining whether the configuration information further includes a third timer value associated with the second timer, wherein the third timer value is to be used for the connection re-establishment when the WTRU is configured as a remote WTRU; In a case where the configuration information further includes the third timer value, starting the second timer using the third timer value when selecting the candidate node; In a case where the configuration information does not include the third timer value, starting the second timer using the second timer value when selecting the candidate node; and A reestablishment request message is transmitted to the relay node.

12. The method according to claim 11, wherein The second timer value is associated with the connection re-establishment via the network node.

13. The method of claim 11, the processor and the transceiver are further configured to enter an idle mode if the WTRU does not receive a response to the re-establishment request message before the second timer expires.

14. The method according to claim 11, wherein The third timer value is greater than the second timer value.

15. The method according to claim 11, wherein The first timer is a T311 timer.

16. The method according to claim 11, wherein The second timer is a T301 timer.

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

18. The method according to claim 11, wherein The configuration information includes at least one system information block (SIB).

19. The method according to claim 11, wherein Selecting the candidate node for the connection re-establishment includes measuring signal quality associated with the candidate node.

20. The method according to claim 11, wherein Selecting the candidate node for the connection re-establishment includes determining a priority associated with the candidate node, measuring a signal quality associated with the candidate node, and determining an area identifier associated with the candidate node.

Images