Method and apparatus for link management and recovery for side link relays

Abstract

This document describes methods and devices for link management and recovery of side link relays. [Solution] 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 also 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 among the alternative relays; and sending a reconfiguration message to the selected second relay indicating the use of the same or equivalent SLRB configuration. If the response indicates that the 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.

Description

Technical Field

[0001] (Cross - reference to Related Applications) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 061,532, filed Aug. 5, 2020, and U.S. Provisional Patent Application No. 63 / 185,801, filed May 7, 2021, the contents of which are incorporated herein by reference.

Summary of the Invention

[0002] This specification describes methods and apparatuses for link management and recovery for sidelink relays. The method includes transmitting a packet to a network via a first relay and using a sidelink radio bearer (SLRB) configuration, where the transmitted packet includes an identifier associated with the first relay; receiving a message identifying an alternative relay; and detecting a radio link failure. The method may further include obtaining a signal quality measurement of a reference signal associated with the alternative relay; selecting a second relay having the highest signal quality from the alternative relays; and transmitting a reconfiguration message indicating to use the same SLRB configuration or an equivalent SLRB configuration to the selected second relay. If a response indicates that the reconfiguration of the second relay is successful, the packet may be transmitted via the second relay using the same or an equivalent SLRB configuration. The packet may include an identifier associated with the second relay.

Brief Description of the Drawings

[0003] A more detailed understanding can be obtained from the following description given by way of example in conjunction with the accompanying drawings, in which like reference numerals in the figures indicate like elements. [Figure 1A] FIG. is a system diagram showing an exemplary communication system in which one or more of the disclosed embodiments may be implemented. [Figure 1B]This is a system diagram showing an exemplary wireless transmit / receive unit (WTRU) that may be used in the communication system shown in Figure 1A, according to one embodiment. [Figure 1C] This is a system diagram showing an exemplary radio access network (RAN) and an exemplary core network (CN) that may be used in the communication system shown in Figure 1A according to one embodiment. [Figure 1D] This is a system diagram showing further exemplary RAN and further exemplary CN that may be used in the communication system shown in Figure 1A according to one embodiment. [Figure 2] This figure shows an example of a user-plane radio protocol stack for Layer 2 evolved WTRU inter-network relay. [Figure 3] This figure shows an example of a control plane radio protocol stack for Layer 2 evolved WTRU inter-network relay. [Figure 4] This figure shows an example of a relay between WTLs. [Figure 5] This figure shows an example of WTRU network relay. [Figure 6] This is an example flowchart of a re-establishment or recovery procedure. [Modes for carrying out the invention]

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

[0005] As shown in Figure 1A, the communication system 100 may include radio 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, but it will be understood that the disclosed embodiments intend any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a radio environment. For example, WTRUs 102a, 102b, 102c, and 102d, all of which may be referred to as stations (STAs), may be configured to transmit and / or receive radio signals and may include user equipment (WTRUs), mobile stations, fixed or mobile subscriber units, subscriber-based units, pagers, mobile phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain context), consumer electronic devices, and devices operating on commercial and / or industrial wireless networks. Any of WTRUs 102a, 102b, 102c, and 102d may interchangeably be referred to as WTRUs.

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

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

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

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

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

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

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

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

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

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

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

[0017] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multimode capability (for example, WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different radio networks via different radio links). For example, WTRU 102c shown in Figure 1A may be configured to communicate with base station 114a, which may use cellular-based radio technology, and base station 114b, which may use IEEE 802 radio technology.

[0018] Figure 1B is a system diagram showing an exemplary WTRU102. As shown in Figure 1B, the WTRU102 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 understood that the WTRU102 may include any partial combination of the aforementioned elements while maintaining consistency with one embodiment.

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

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

[0021] The transmitting / receiving element 122 is shown in FIG. 1B as a single element, but the WTRU 102 can include any number of transmitting / receiving elements 122. More specifically, the WTRU 102 can utilize MIMO technology. Thus, in one embodiment, the WTRU 102 can include two or more transmitting / receiving elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via the air interface 116.

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

[0023] The processor 118 of the WTRU 102 may be coupled to the speaker / microphone 124, keypad 126, and / or display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit) and may receive data input by a user therefrom. The processor 118 may also output user data to the speaker / microphone 124, keypad 126, and / or display / touchpad 128. Further, the processor 118 may access information from and store data in any suitable type of memory, such as the non-removable memory 130 and / or the 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 a memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

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

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

[0026] The processor 118 may be further coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, and the like. Peripherals 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, barometer, gesture sensor, biometric sensor, humidity sensor, etc.

[0027] WTRU102 may include a full-duplex radio in which the transmission and reception of some or all of a signal (for example, associated with specific subframes of both UL (for example, for transmission) and DL (for example, for reception) may occur simultaneously and / or together. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference via hardware (e.g., chokes) or signal processing via a processor (e.g., via a separate processor (not shown) or processor 118). In one embodiment, WTRU102 may include a half-duplex radio for the transmission and reception of some or all of a signal (for example, associated with specific subframes of either UL (for example, for transmission) or DL ​​(for example, for reception)).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0053] UPF184a and 184b may be connected via the N3 interface to one or more gNB180a, 180b, and 180c within RAN104, thereby providing WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices. UPF184 and 184b may perform other functions such as packet routing and forwarding, enforcement of user plane policies, support for multi-homed PDU sessions, processing of user plane QoS, buffering of DL packets, and mobility anchoring.

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

[0055] With regard to Figures 1A-1D and the corresponding descriptions in Figures 1A-1D, one or more of the functions described herein with respect to one or more of the WTRU102a-d, base stations 114a-b, e-nodes B160a-c, MME162, SGW164, PGW166, gNB180a-c, AMF182a-b, UPF184a-b, SMF183a-b, DN185a-b, and / or any other devices described herein may be performed by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0069] Figure 2 shows an example of a user-plane radio protocol stack for a Layer 2 evolved WTRU inter-network relay. As shown in Figure 2, remote WTRU201 can interface with Layer 2 relay WTRU202 via a sidelink (i.e., remote WTRU201 and relay WTRU202 can communicate via the PC5 interface). Layer 2 relay WTRU202 and eNB203 can have a lower-layer link established with the eNB via an air interface (Uu).

[0070] PDCP and IP links can be established between the remote WTRU201 and the eNB203, while RLC, MAC, and PHY, as well as non-3GPP transport layer links, can be established between the remote WTRU201 and the Layer 2 relay WTRU202 via PC5, and between the evolved Layer 2 relay WTRU202 and the eNB203 via Uu. Relay of user plane data from the remote WTRU201 to the core network (CN)204 via Layer 2 evolved WTRU inter-network relays, and vice versa, can be performed above the RLC layer (e.g., at the PDCP and IP layers).

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

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

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

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

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

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

[0077] The Integrated Access and Backhaul (IAB) framework described in Release 16 can support flow control feedback as follows: For a link, the transmitter of a BAP entity in 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 by the receiver. If an egress BH RLC channel is configured for the BAP control PDU, the egress BH RLC channel can submit the BAP control PDU to the configured egress BH RLC channel of the egress link. If an egress BH RLC channel is not configured for the BAP control PDU, the BAP control PDU can be submitted to any egress BH RLC channel of the egress link.

[0078] The various problems for which solutions are proposed in this specification can be understood as follows:

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

[0080] In the case of relayed links with sidelinks (e.g., relaying from a WTRU to a network (NW) or relaying between WTRUs), link management on one link is not necessarily visible to another, so individual link management procedures may be insufficient. Therefore, a mechanism to make a failure on one link visible to another may be desirable. For example, in a WTRU-to-network relay scenario, a relaying WTRU may trigger a TX-based RLF across the relayed link. However, such an RLF may not be visible to a remote WTRU if the remote WTRU does not have periodic transmissions of its own to trigger similar RLFs, or if the SL channels are not reciprocal. In such cases, recovery may be delayed, making it difficult to achieve continuity of service. Specifically, given the premise that the network may be able to transmit data via Uu (in the event of an SL failure), but should not require WTRUs connected via WTRU-to-network relays to perform all necessary Uu procedures (e.g., for power saving purposes), it is not possible to know whether a WTRU is reachable after a failure.

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

[0082] This specification describes methods for link management and recovery for side-link relays. Link management mechanisms applicable to both WTRU-to-WTRU relays and WTRU-to-network relays are discussed in detail here.

[0083] Figure 4 shows an exemplary architecture for link management and recovery in the context of inter-WTRU relay. Relay WTRU402 can be used as an inter-WTRU relay, as shown in Figure 4. The first link shown in Figure 4 may correspond to the link between source WTRU401 and relay WTRU402. The second link may refer to the link between relay WTRU402 and either the destination or next-hop WTRU403 in an inter-WTRU multihop link or an inter-WTRU network multihop link. Generally speaking, the destination can be a WTRU or a network node, depending on whether the relay is an inter-WTRU relay or an inter-WTRU network relay, for example. In the case shown in Figure 4, the destination is the former destination WTRU404. Without loss of generality, the term source WTRU may also refer to a relay WTRU that is serviced by another relay along the link to the destination.

[0084] Figure 5 shows another exemplary architecture for link management and recovery, particularly in the context of WTRU network-to-network relays. A relay WTRU can be used as a WTRU network-to-network relay, as shown in Figure 5. The first link shown in Figure 4 may correspond to the link between source WTRU 501 and relay WTRU 502. The second link may refer to the link between relay WTRU 502 and either the destination or next-hop WTRU 503 in a WTRU-to-WTRU multi-hop link or a WTRU network-to-WTRU multi-hop link. In the case shown in Figure 5, the destination is node B504. Without loss of generality, the term source WTRU as used in relation to Figure 5 may also refer to a relay WTRU that is serviced by another relay along the link to the destination.

[0085] In some embodiments, a WTRU configured as an SL relay (e.g., a WTRU-to-network relay or an inter-WTRU relay) can transmit link problem instructions to one or more other WTRUs via a sidelink. Such instructions may be transmitted, for example, to the source WTRU of a relayed connection or to another WTRU involved in the relay connection, according to the architecture described herein and shown in the drawings. Such instructions may be transmitted when a link problem is detected between the relay WTRU and the NW (in the case of an inter-WTRU relay), or when a link problem is detected between the relay WTRU and another WTRU (e.g., a destination WTRU or another relay WTRU, according to the architecture described herein and shown in the accompanying drawings).

[0086] A link problem indication (LPI) may be an L2 protocol message transmitted via a PC5-RRC message, an SL MAC control element (CE), or any combination of L2 control PDUs 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, a WTRU may transmit an LPI as a PC5-RRC message, and together with the message may include an SL medium access control (MAC) CE and / or adaptive control PDU containing some of the information described herein and associated with the LPI. Alternatively or additionally, an LPI may be transmitted via a side-link control information (SCI) message.

[0087] An LPI can be broadcast / groupcast to all source WTRUs served by a particular relay WTRU. For example, a relay WTRU can be configured with an L2 source / destination ID (or logically equivalent source / destination ID) for sending an LPI or similar status message to each or a subset of the source WTRUs served by the relay WTRU. The relay WTRU (and the corresponding source WTRU) can determine such an L2 ID based on any combination of one or more instructions received from the upper layer, derive the L2 ID from the RAN ID, or determine the L2 ID based on the configured L2 ID of the relay WTRU itself 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, for example, based at least on the upper layer, the relay WTRU and the corresponding WTRU can explicitly receive L2 from the upper layer and / or from the network, for example, when operating as / using the relay WTRU. When a relay WTRU determines the L2 ID by deriving it from at least the RAN ID, it may use any function of the RAN ID, such as the cell radio network temporary identifier (C-RNTI), inactive RNTI (I-RNTI), or international mobile subscriber identity (IMSI).

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

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

[0090] When a source WTRU recognizes the L2 source / destination ID associated with sending an LPI message, it can monitor the source / destination ID for receiving a groupcast LPI message sent by a relay WTRU.

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

[0092] In some embodiments, when the content of the LPI is limited (e.g., including only RLF instructions), the LPI may be transmitted over a dedicated PHY channel such as a physical sidelink control channel (PSCCH), a physical sidelink shared channel (PSSCH), or a physical sidelink feedback channel (PSFCH). Several dedicated resources may be configured for transmitting LPI over any of the dedicated PHY channels. In detail, a PSFCH resource (e.g., occurring periodically) can be configured in an inter-WTRU relay for transmitting LPI. For example, a relay WTRU may transmit instructions (e.g., a HARQ acknowledgment (ACK) or a HARQ negative acknowledgment (NACK)) over the PSFCH resource when transmitting an LPI. A relay WTRU may be configured (e.g., by the network) using one such PSFCH resource per destination WTRU or relay WTRU for the second link and / or information to be sent (e.g., according to the contents of the LPI).

[0093] The source WTRU can receive dedicated configurations / resources associated with the PHY channel associated with the LPI (for example, in PC5-RRC signaling with the relay WTRU during link establishment). The source WTRU can monitor such resources and decide to receive the LPI associated with the relayed link.

[0094] A relay WTRU can send a Link Problem Recovery Instruction (LPRI). Such an LPRI may be associated with the event that triggered the LPI. A WTRU that sends an LPI can begin monitoring for LPRI transmissions. A WTRU can send an LPRI whenever the conditions that triggered the associated LPI are relaxed. Any of the conditions referred to herein for an LPI may be considered for an LPRI when the LPI condition is relaxed. For example, a WTRU may send an LPI associated with a buffer status above a CR / resource pool dependency threshold, and then send an LPRI when such a buffer status falls below another (possibly relevant) threshold.

[0095] A source WTRU receiving an LPRI can cancel any relay, relay reselection / reconfiguration, or other actions that may have been initiated as a result of receiving the LPRI.

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

[0097] In some cases, the WTRU may initiate part of the relay reselection procedure upon receiving an LPRI, and then complete the reselection / reconfiguration if the WTRU does not receive an LPRI indicating a relaxation of the conditions, or if the timer expires without receiving such an LPRI.

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

[0099] Regarding RLFs on a second link associated with a destination, for example, a relay WTRU can send an LPI when it triggers an RLF associated with the second link to the destination WTRU in an inter-WTRU relay connection. Specifically, a WTRU can send an LPI to its source WTRU when an RLF occurs for a destination to which the source WTRU is connected via relay. For example, a relay WTRU can send an LPI when it triggers a Uu RLF associated with the second link in an inter-WTRU network relay.

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

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

[0102] Regarding the degree of CBR / CR, for example, a WTRU may transmit an LPI when the measured CBR / CR satisfies some configured pre-configured condition. Such conditions may further depend on the QoS of the data transmitted by the relay and / or SLRB / relay configuration in the relay. Such conditions may depend on other conditions referred to herein for transmitting an LPI. Such conditions may consist of the CBR / CR reaching some configured or pre-configured value, possibly over a period of time. For example, a WTRU may transmit an LPI when the measured channel busy ratio (CBR) exceeds a configured or pre-configured threshold, possibly over a period of time. For example, a WTRU may transmit an LPI when the channel occupancy (CR) exceeds a configured pre-configured threshold.

[0103] With respect to relay-specific CRs, a WTRU can determine the relay-specific CR. In particular, a relay WTRU can measure the amount of resources reserved / utilized for sending relayed traffic and / or the ratio of CRs applicable to relayed traffic. A WTRU can determine such a ratio by determining the ratio of traffic in its buffer to relayed traffic versus non-relayed traffic, and can multiply such a ratio by the measured CR. A WTRU can determine the relay-specific CR by determining the amount of resources relative to the total number of resources in the resource pool used to send data to a destination ID that is associated with or from an LCH associated with a relayed link.

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

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

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

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

[0108] For example, with respect to the QoS of configured bearers and / or data in a relay buffer, the WTRU may send an LPI based on any condition (and 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 (and possibly for relay connections). For example, the WTRU may send an LPI when the amount of data in buffered for any relayed LCH with latency below a threshold (or the remaining PDBs expected to be below a threshold) exceeds a threshold.

[0109] Regarding configuration by peer WTRUs, a relay WTRU may be configured by the peer WTRU (e.g., in PC5-RRC signaling) regarding whether or not to send an LPI when a specific trigger occurs. For example, when a relay WTRU detects an RLF on a second link, it may be configured to perform one or both of the following actions: upon detecting an RLF on a second link, the relay WTRU immediately releases the PC5-RRC connection associated with the second link and does not send an LPI, or it sends an LPI to the source WTRU (e.g., potentially including an RLF indication) and waits for confirmation before releasing the PC5-RRC connection. The relay WTRU may also suspend any transmissions performed on the second link associated with the link in the RLF. Such configurations may be provided as part of an SLRB configuration. For example, a relay WTRU may receive such configuration parameters for each SLRB and select a behavior based on at least one of the SLRBs in which the relevant behavior is configured.

[0110] The implicit configuration for whether or not to send an LPI can be defined with respect to the activation / deactivation status of the link itself, the WTRU location, the WTRU RRC state, and / or the WTRU coverage status. With respect to the activation / deactivation status of the link itself, for example, a relayed link may be activated / deactivated by the source WTRU and / or the NW and / or higher layers. A WTRU can only send an LPI when the link is activated, and may drop or buffer the LPI when the link is deactivated (e.g., to send it when activated). For example, a WTRU can broadcast an LPI to all source WTRUs as long as at least one link to the source WTRU is activated. With respect to the WTRU location, for example, a WTRU can be given zones or rules regarding its relative position to another WTRU or node B (e.g., gNB) regarding whether or not to send an LPI. With respect to the WTRU RRC state, for example, a WTRU can determine whether or not to send an LPI based on the current RRC state of the relay WTRU if another trigger is met. Regarding WTRU coverage status, for example, a WTRU can determine whether to send an LPI when another trigger is met, based on whether the WTRU is within the coverage of a Uu.

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

[0112] Regarding Uu quality / condition, the relay WTRU may send LPI as a result of either Uu cell RSRP / RSRQ (e.g., below threshold) and / or measured CQI (e.g., below threshold).

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

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

[0115] Regarding whether the current link configuration / status allows for the detection of RLF / link problems in the source WTRU based on the lack of feedback / response, for example, a relay WTRU can choose one of two behaviors in the RLF of a second link: immediately release the PC5-RRC connection associated with the second link and do not send an LPI, and / or send an LPI to the source WTRU (potentially including, e.g., an RLF instruction) and wait for confirmation before releasing the PC5-RRC connection. The WTRU relay WTRU can further suspend any transmissions performed on the second link associated with the link in the RLF.

[0116] The relay WTRU may, in its LPI to the source WTRU, include any of the following: a failure instruction, a relay-triggered relay selection / re-selection instruction initiated by the relay, or a relay-triggered triggered Uu re-establishment instruction; an amount associated with any of the conditions described herein for sending the LPI; the L2 source / destination ID of the next hop (where the LPI may be applicable (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 other LPI content applies; the cell ID of the cell where the relay WTRU experienced an RLF / re-establishment failure; or any conditions related to the RLF; a new cell ID applicable to the WTRU-to-WTRU network relay connection (assumed after receiving the LPI or completion of the re-selection procedure); one or more relay re-selection candidates (e.g., the relay's source / destination L2 ID and / or cell ID); and any associated measurement / selection metrics (e.g., SL / Uu RSRP measurement); and / or identifiers used by the WTRU after receiving the LPI (e.g., to continue communication after receiving the LPI and / or after successful re-selection).

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

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

[0119] A relay WTRU can create an SLRB for transmission to the source WTRU in response to the initiation of the link by the source WTRU. For example, a relay WTRU can create an SLRB toward the source WTRU upon receiving a PC5-RRC message from the source WTRU. Alternatively or additionally, a relay WTRU can create an SLRB toward the source WTRU in response to instructions from a higher layer 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 a higher layer. For example, such an SLRB may be used for transmitting LPI in a secure manner.

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

[0121] In some embodiments, a source WTRU can trigger an SL RLF following the reception of an LPI indicating an SL RLF. The source WTRU can remove all context associated with the PC5-RRC connection with the relay WTRU that sent the LPI and notify the upper layer of the SL RLF. In some embodiments, the source WTRU can initiate relay reselection following the reception of an LPI indicating an SL RLF on a second link. The source WTRU may optionally suspend transmission to the relay WTRU that sent the LPI while the reselection is being performed. If the reselection is successful, the source WTRU can notify the upper layer that the reselection was successful and / or optionally change the source / destination ID of any SLRBs transmitted through the original relay WTRU to the new source / destination ID provided by the upper layer following the reselection. If the reselection fails, the source WTRU can instead trigger an SL RLF.

[0122] The source WTRU can determine / modify any aspect of its RLF determination mechanism based on information in the LPI. In some embodiments, the WTRU can determine the maximum number of consecutive DTX in response to a HARQ-based transmission that triggers an RLF, based on any or a combination of the following parameters reported in the LPI. When a WTRU receives an LPI / LPRI, in response to a HARQ-based transmission that triggers an RLF, the WTRU may further change the maximum number of consecutive DTXs from a first value to a second value, and the following parameters, namely, 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 relayed links), the degree of latency associated with the data in the buffer (potentially associated with relaying the data), the TX resource pool configuration of the relay WTRU (which may be the same as or different from the TX resource pool configuration of the source WTRU), the CQI on the second link received by the relay WTRU from its peer WTRU and further reported by the relay WTRU to the source WTRU, any degree of channel capacity / efficiency of the second link measured by the relay WTRU, and / or whether the transmission is made to the relay WTRU or directly to the peer WTRU, as well as the number of hops associated with the relayed path, will be changed compared to the previous LPI / LPRI. Regarding the degree of latency associated with the data in the buffer, for example, a WTRU can calculate the average latency metric for the data in that buffer by assigning a latency value to each packet (for example, based on the LCH associated with that packet).

[0123] In some embodiments, the WTRU may set the number of consecutive DTXs to a first value if the CR measured by the relay WTRU is below a threshold, and to a second value if the CR is above the threshold. In some embodiments, the WTRU may, upon receiving an LPI, optionally pause the count of HARQ-based DTXs for RLF determination for a certain period of time, wherein such an LPI may include values ​​of the parameters mentioned in the above examples that satisfy some configured or preconfigured criteria. In some embodiments, the WTRU may reset the number of HARQ-based DTXs counted upon receiving an LPI / LPRI (where such an LPI / LPRI may include values ​​of the parameters mentioned in the above examples that satisfy some configured or preconfigured criteria).

[0124] In some embodiments, a WTRU can declare an RLF based on the number of HARQ-based DTX counted across a configurable window. The WTRU can thus execute an RLF only if the contents of the LPI meet certain conditions. For example, the WTRU can thus execute an RLF only when the CR and / or buffer status reported by the relay WTRU exceeds a threshold. The WTRU can further determine the number of HARQ-based DTX that trigger an RLF and / or window size based on such parameters in the LPI.

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

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

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

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

[0129] In some embodiments, the decision may be made by the source WTRU based on information provided by the relay WTRU. In other embodiments, the decision may be made by the relay WTRU based on information provided by the source WTRU. A WTRU (source or relay) can make such decisions based on any or a combination of the following information (each such information may be provided by or related to other WTRUs, and / or determined independently by this WTRU or related to this WTRU itself): namely, QoS or SLRB configuration, communication range requirements for the source WTRU and / or relay WTRU, synchronization sources for the source WTRU and / or relay WTRU (synchronization sources that potentially refer to the destination WTRU), locations for the source and / or relay (locations that potentially relate to each other, or locations related to another entity such as node B (e.g., gNB) or the destination WTRU), CBR / CR / CQI / RSRP or similar measurements, the number of potential relay WTRUs determined based on the relay discovery procedure, measurement quality criteria (e.g., RSRP measurement) or any function thereof (in some cases compared to current relay quality) for one or more potential relay WTRUs determined based on the relay discovery procedure, the number of relay hops, and / or Uu RSRP measurement of the link between the last hop relay and the NW (in the case of WTRU inter-network relays).

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

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

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

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

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

[0135] In one example, a WTRU can reset the number of consecutive DTXs in an RLF determination upon receiving from a relay / peer WTRU. Such receptions could be RLC buffer status, flow control instructions, measurement instructions, LPI / LPRI, RS transmissions, measurement reports, or any data / control transmissions. In another example, a WTRU might trigger an RLF based on a combination of several consecutive HARQ-based DTXs and a time period reached without reception from the relay WTRU. Such time differences may further depend on the SLRB configuration and / or QoS.

[0136] In any of the examples described herein, the success of reselection as a result of sending / receiving RLF and / or LPI messages may depend on performing all actions within a configured time or timer. A WTRU may start a timer, thereby determining that the reselection procedure may fail if the timer expires before the relevant actions are completed, or if the WTRU determines that the reselection procedure may fail if a time period elapses for the relevant actions to be completed. Such timers or durations may further depend on any or a combination of QoS / SLRB configurations for one or more services established via relays and / or CBRs. With respect to QoS / SLRB configurations, for example, a source / relay WTRU may be configured with a reselection timer or reselection duration associated with each SLRB. When reselection is triggered, the WTRU may set the timer to the minimum of the timers for each established SLRB, or consider the duration to be the minimum of the timers for each established SLRB. With respect to CBRs, for example, a source / relay WTRU may be configured with a reselection timer or reselection duration associated with a range of CBRs. When reselection is triggered, the WTRU can set the timer to a value associated with the CBR measured at the time of the reselection trigger.

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

[0138] In some embodiments, the WTRU that triggers relay reselection may execute the events described in the following paragraphs (potentially in sequence).

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

[0140] A WTRU can select a relay with the best RSRP measurement as a potential relay WTRU. A WTRU can also use higher-layer criteria (e.g., supported services) for relay selection (e.g., a relay with the best supported RSRP measurement for a higher-layer service). A WTRU can determine if it can initiate the PC5-RRC configuration procedure with a peer WTRU (e.g., the selected potential relay WTRU). A WTRU can reuse the configuration of an existing bearer / PC5-RRC connection with a relay (e.g., an SLRB configuration for a relay) for the configuration included in the PC5-RRC connection with the potential selected relay and / or for the TX-related parameters of the SLRB configuration. A WTRU can send and receive a PC5-RRC reconfiguration message using the L2 source / destination ID provided by the higher layer (associated with the new potential relay WTRU sending the discovery message). Alternatively or additionally, a WTRU may use a default L2 source / destination ID pair for relay reselection transmission, possibly also provided by the higher layer. Alternatively or additionally, the WTRU can use the L2 source / destination IDs provided with the sending / receiving of discovery messages to new potential relays to send PC5-RRC configuration messages.The use of the same / similar configuration may include using the same number of SLRBs, using the same configuration of one or more SLRBs or a subset of SLRB parameters, 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, or using an equivalent configuration such that such a configuration is derived from the original configuration to take into account any change in any of the following characteristics of the newly selected relay / path (such information may be provided before relay selection, for example in a discovery message, or stored, for example from a previous session with that relay): the difference in the number of hops between the old and new links, the difference in the capabilities of the new relay (e.g., the number of carriers supported), and / or the difference in the reported or measured values ​​of the new relay. An equivalent configuration may be configured or pre-configured for each configuration from the network.

[0141] If the WTRU has successfully performed the PC5-RRC configuration procedure with the selected potential relay, it can indicate to the upper layer that the relay selection or reselection procedure was successful. The WTRU may further perform one or a combination of the following subsequent actions: The WTRU may release the PC5-RRC context associated with the current relay WTRU. The WTRU may indicate to the upper layer that the reselection to the relay WTRU was successful and may indicate a source / destination ID that identifies the relay WTRU. The WTRU may create a new PC5-RRC connection associated with the new relay WTRU, and / or the WTRU may replace the source / destination ID associated with the current relay with the new source / destination ID associated with the relay WTRU in the PC5-RRC context of the current relay.

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

[0143] Figure 6 is a flowchart illustrating an exemplary re-establishment or recovery procedure. As shown in 601 of Figure 6, a remote WTRU can be connected to the network via a sidelink interface with a WTRU inter-network relay. A set of alternative relays can be configured for the remote WTRU, as shown in 602, by following one or more other procedures described herein, for example. As shown in 603, if the remote WTRU determines that an SL RLF has occurred (for example, by following one or more procedures described herein), the remote WTRU can select an appropriate relay, as shown in 604. As shown in Figure 6, such an appropriate relay may be a relay with the highest RSRP. Alternatively or additionally, any appropriate relay with an SL RSRP above the threshold may be selected. An appropriate relay may be a relay provided by the network in a configured list. An appropriate relay may be a relay whose measured SL RSRP is above the threshold, meets several higher-layer criteria associated with the discovery message, and has an acceptable PLMN. It should be noted that solutions in embodiments not shown may involve the selection of one or more appropriate relays by the procedures described herein. As shown in 605, if all relays in the set of alternative relays configured for the remote WTRU are exhausted, for example, if reconfiguration fails for all alternative relays, or if a suitable alternative relay cannot be found, the remote WTRU may determine that recovery has failed. If a suitable alternative relay can be found and selected, in 606, the remote WTRU may configure one or more SLRBs by sending an SL reconfiguration message to the selected relay. The remote WTRU may use the same SLRB configuration previously configured in the remote WTRU using the previous relay (for example, all SL RLC channels, or SL RLC channels for transmitting SLRB1). In 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 a relay responds with a failure, or if the remote WTRU does not receive a response, the remote WTRU may retry reconfiguration with a different suitable relay. The remote WTRU may retry such a procedure until the list of suitable relays is exhausted, or until the timer associated with relay reselection expires, or until a determined duration has elapsed. For example, if it is determined that the reconfiguration for the newly selected relay was successful based on the response received from the newly selected relay, in 608, the remote WTRU may update its current relay with the new L2 ID of the newly selected relay, and in 609, send a Uu re-establishment request message using its existing SL RLC channel for SRB1 transmission, except that the L2 ID may be changed for the new L2 ID. Specifically, the remote WTRU may maintain the same configuration of the SL RLC channel for transmission, replacing the L2 ID with that of the old relay as the new relay.

[0144] In the example shown in Figure 6, under the condition that recovery fails, the remote WTRU may delete its context, move to RRC_IDLE, trigger a relay reselection procedure and / or a cell reselection procedure. In embodiments, relay reselection may result in a new or different set of relays that are appropriate compared to the set of relays provided by the NW.

[0145] In some embodiments, a WTRU can perform relay selection or reselection and / or recovery (e.g., after an RLF) for relays from a set of configured relay WTRUs provided by the network. Specifically, a WTRU can determine which relay WTRU to select, reselect, or recover by selecting a WTRU from a list of WTRUs provided by the network. Such a list may be provided directly via a Uu (e.g., while the WTRU is in coverage). Alternatively or additionally, such a list may be provided by RRC signaling transmitted through the currently connected relay WTRU. When a remote WTRU detects any of the conditions defined herein (e.g., an SL RLF by a relay WTRU), it may select one of the relays from the list of relays provided by the network based on any or a combination of the relay measurements at the time of reselection or recovery, the ordering and / or priority associated with each relay, and / or the current location of the remote WTRU. With respect to the relay measurements or reselection or recovery at that time, for example, the remote WTRU may select a relay WTRU on the list that has the highest RSRP. In another example, a remote WTRU can select any relay WTRU that has an acceptable RSRP (e.g., an RSRP above a threshold). With respect to the ordering and / or priority associated with each relay, for example, a remote WTRU can receive preferences and / or priorities associated with each relay and perform reselection / recovery for the relay WTRU associated with the highest priority. In yet another example, a remote WTRU can determine a relay by further combining other factors described herein (e.g., RSRP measurements of relays) with such priorities. With respect to the current location of a remote WTRU, for example, a network can provide a set of permitted locations (e.g., zone IDs) for each relay WTRU, and the remote WTRU can select a relay associated with its current WTRU location (e.g., its current zone ID).

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

[0147] A WTRU may initiate recovery to a relay WTRU having a stored PC5-RRC configuration by sending an initial activation message on the SL, thereby including one or more of the following: a dedicated activation PC5-RRC message, an SL MAC CE, or an SCI addressed to the L2 destination ID of the new relay; the transmission of any UL or SL data that allows the WTRU to change the L2 destination ID to the L2 destination ID of the new relay; and / or a recovery L2 destination ID, or a dedicated activation or normal UL or SL transmission to a special L2 destination ID configured in the remote WTRU for recovery. Upon receiving such a message, the relay WTRU may activate a similarly stored configuration for receiving / transmitting to the remote WTRU.

[0148] A WTRU can be considered connected to the network via a WTRU-to-network relay if it has a PC5-RRC connection to a WTRU-to-network relay (for example, if the WTRU is determined to be a relay or has a PC5-RRC context that is specific to a relay). Specifically, a WTRU may be considered connected via a relay in response to one or more of the following: an instruction from a higher layer that a PC5-link with a relay WTRU has been initiated, and / or the receipt of a PC5-RRC message indicating a connection for a relay. For example, a WTRU may receive a PC5-RRC reconfiguration message that includes an instruction that the configuration is associated with a connection to a WTRU-to-network relay. In another example, a WTRU may receive a PC5-RRC reconfiguration message that, due to the content of the message, implicitly indicates the reconfiguration of a PC5-RRC connection for a relay. A PC5-RRC configuration message from a 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 Uu QoS entities to SL QoS entities, configuration for the Uu protocol layer (e.g., PDCP / SDAP), configuration / conditions for returning to the Uu, and / or configuration for monitoring the Uu while connected to the WTRU inter-network relay (including PDCCH configuration, Uu RLF configuration, and / or CQI reporting configuration). For example, a WTRU may receive a PC5-RRC message containing an embedded Uu RRC reconfiguration message that constitutes several aspects of the Uu connection, as described herein.

[0149] When connecting to a WTRU network-to-network relay, such a WTRU can suspend the execution of certain procedures to the Uu. For example, a WTRU can suspend monitoring RLF (legacy RLF) on the Uu and initiate relay-based link monitoring procedures with the relay WTRU. A WTRU can also perform new or limited RLF procedures with the network (on the Uu), as described herein. In another example, a WTRU can suspend receiving system information from the network and receive system information from the relay WTRU. In yet another example, a WTRU can suspend monitoring paging and receive paging from a peer WTRU. In yet another example, a WTRU can suspend monitoring PDCCH from the network for DL ​​allocation and UL grants. Alternatively or additionally, a WTRU can perform some limited PDCCH monitoring, as described herein. In yet another example, a WTRU can suspend all DRBs. In yet another example, a WTRU can replace some or all DRBs with their corresponding relayed DRBs. In another example, a WTRU can create a relayed DRB corresponding to Uu DRBs, and this DRB can be suspended.

[0150] WTRUs connected via WTRU inter-network relays can trigger a relay RLF procedure when an RLF related to the WTRU inter-network relay is detected. Such detection may result from any of the triggers described herein.

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

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

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

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

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

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

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

[0158] A WTRU may trigger a relay RLF procedure upon any of the following conditions, which are relayed to be received on a Uu: reception of a scheduling on the PDCCH (e.g., a DCI scheduled using the WTRU's C-RTNI, or a new RNTI indicating the resumption of a network-based scheduling), where such scheduling may be for UL and / or DL ​​data transmissions on the Uu; reception; reception of an RRC message resuming Uu-based (e.g., non-relay) operation, where such RRC message may be received directly on the Uu link; reception; reception for a MAC CE on the Uu; reception of a WTRU on a configured Uu monitoring opportunity; and / or an explicit instruction from the network in any of the above signaling mechanisms (e.g., an RRC message with an explicit instruction to trigger an SL RFL, or a WUS with an explicit instruction to trigger an SL RLF). With respect to the reception of an RRC message resuming Uu-based operation, for example, a WTRU may suspend all Uu DRBs and maintain SRBs when connected to a WTRU inter-network relay. When the WTRU receives an RRC message from the network on the SRB via the Uu, it can trigger a relay RLF and restart the DRB.

[0159] A WTRU may perform RLF-like actions simultaneously on both a Uu and an SL. A WTRU can notify the network of an RLF on one of the links via other links. For example, when a remote WTRU detects an SL RLF with a relay WTRU, it may perform an access procedure that may include either performing a RACH procedure (potentially if the TAT has expired) and / or sending an RRC message such as SLUEInformation, RRCResume, or UEAssistanceInformation, or another logically equivalent message. The WTRU may further indicate the occurrence of an SL RLF within such a message. When a WTRU detects a Uu RLF, it can notify the network of such an RLF by sending a Uu RRC message via the relay WTRU (e.g., encapsulated in PC5-RRC).

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

[0161] In some embodiments, the WTRU may release the PC5-RRC connection (e.g., release all context associated with the PC5-RRC connection with the relay and notify the upper layer) upon any of the following: reselection to a cell that does not support an existing relay, receipt of a re-establishment response, and / or a Uu RLF resulting in any re-establishment procedure. With respect to a Uu RLF resulting in reselection to 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 can be used on the cell, and the WTRU may trigger a PC5-RRC release if the selected cell does not support the current relay WTRU. With respect to receiving a re-establishment response, for example, the WTRU may receive instructions to release the PC5-RRC connection in the re-establishment response message. With respect to any re-establishment procedure, for example, the WTRU may be configured to release the PC5-RRC connection when a Uu re-establishment procedure is triggered.

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

[0163] A remote WTRU may be configured to measure the CSI on the Uu by RRC signaling (e.g., directly on the Uu or via an RRC encapsulated within a PC5-RRC). Alternatively or additionally, the remote WTRU may be configured to measure / transmit CSI measurements based on the measured quality of the relay WTRU, the measured quality on the Uu, the presence of another relay, the location of the remote WTRU and / or the relay WTRU, and / or any or a combination of QoS and / or other bearer configurations. Regarding the measured quality of the relay WTRU, for example, the remote WTRU may perform / transmit a Uu CSI measurement when the relay RSRP falls below a threshold. In another example, the remote WTRU may perform / transmit a Uu CSI measurement when the relay RSRP is between a first threshold and a second threshold. In yet another example, the remote WTRU may perform / transmit a Uu CSI measurement when the relay RSRP changes by a certain amount. Regarding the measured quality on the Uu, for example, the remote WTRU may perform / transmit a Uu CSI measurement when the Uu RSRP is above a threshold. In another example, a remote WTRU can perform / transmit a Uu CSI measurement when the Uu RSRP is between a first and a second threshold. Regarding the presence of other relays, for example, a remote WTRU can perform / transmit a Uu CSI measurement when there are no other detected potential relays where the measured RSRP exceeds the threshold. Regarding the location of the remote WTRU and / or relay WTRU, for example, a remote WTRU can be configured with a set of zones to which it should report CSI measurements. For example, a remote WTRU can report CSI measurement results based on the relay WTRU's reported zones, possibly combined with the location of the remote WTRU itself (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, a remote WTRU may decide to report CSI measurements based on the QoS of the transmitted data or on any configuration aspect related to the currently configured / established bearer.

[0164] A remote WTRU can transmit network CSI measurements to a relay WTRU via MAC CE or a logically equivalent message. Alternatively or additionally, a remote WTRU can transmit network CSI measurements to a relay via PC5-RRC messages. Alternatively or additionally, a remote WTRU can transmit network CSI measurements in a Uu RRC message encapsulated within a PC5-RRC message, or in any logically equivalent message.

[0165] In some embodiments, a remote WTRU can transmit CSI measurements to a relay WTRU via MAC CE. The remote WTRU can determine the time requirements for a CSI measurement based on one or a combination of the following: the network configuration, the speed of the remote WTRU, the CBR / CR measured in the remote WTRU and / or indicated by the relay WTRU, and / or the flow control instructions / information provided by the relay WTRU. The remote WTRU can drop a CSI measurement if the time from the trigger of the CSI measurement exceeds a threshold.

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

[0167] In some embodiments, a relay WTRU can transmit CQI measurements to the network from one or more remote WTRUs. For example, a relay WTRU can 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.

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

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

[0170] A relay WTRU can trigger a MAC CE to forward CSI measurements upon receiving any Uu CQI report from any remote WTRU and / or upon the expiration of a timer, such a timer may be started upon receiving a Uu CQI report from any remote WTRU. For example, a relay WTRU may set a timer upon receiving a Uu CQI report from a remote WTRU if such a timer is not already running. While the timer is running, the relay WTRU may trigger the transmission of its remote WTRU's CSI measurements along with any other CQI reports received (possibly from other WTRUs). The relay WTRU may further transmit a CQI report immediately after reception (e.g., before the expiration of any running timers or before the duration has elapsed) based on several conditions associated with the received CQI report (e.g., upon receiving a CQI report with a specific trigger type, priority indication, and / or timestamp value).

[0171] In some embodiments, a WTRU can store a Uu configuration along with the cell to which the WTRU is connected when a relay connection between WTRU networks is established. The WTRU can reuse such a stored configuration as part of a recovery procedure that is triggered based on any of the conditions described herein (for example, when a relay link fails). Alternatively or additionally, a WTRU can have multiple stored candidate Uu cell configurations having different cells. The WTRU can receive such candidate cells via dedicated RRC signaling on the Uu and / or via a relay WTRU. The WTRU can also reuse such a stored configuration as part of a recovery procedure.

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

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

[0174] A remote WTRU can delete stored Uu candidate configurations / cells when re-selecting a relay WTRU where such stored candidate configurations / cells are invalid. Alternatively or additionally, a WTRU can store all configured candidate configurations, but only one or more valid stored cell configurations can be considered as part of the recovery procedure.

[0175] The WTRU may, as described herein, execute a recovery procedure (e.g., a CHO procedure or similar) via the Uu using a stored Uu configuration following any SL relational condition that triggers recovery. The WTRU may further execute such recovery procedures depending on any or a combination of the following conditions: the WTRU performs cell reselection to a cell having a valid stored Uu candidate configuration; the cell on which reselection is performed has a specific quality (e.g., RSRP above a threshold); and / or the WTRU detects a cell having a specific quality (e.g., RSRP above a threshold) that has a stored valid Uu candidate configuration.

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

[0177] Cell selection / relay selection procedures 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 one procedure is being triggered or was already triggered at the start of re-establishment, relay support by the cell from which re-establishment is triggered (e.g., the cell originates from a relayable NodeB, e.g., a gNB), and QoS associated with the currently active bearer, or any configuration of the bearer / LCH.

[0178] A remote WTRU can trigger a cell selection or relay selection procedure when connected directly via a Uu and / or via a relay WTRU. Such a cell / relay re-selection procedure may typically be associated with a trigger that triggers a Uu re-establishment in the Uu. For example, a remote WTRU, upon triggering a Uu RLF, may initiate a re-establishment procedure, taking into account any available relay WTRUs. Such a new re-establishment procedure may begin with the initiation of a cell re-selection and / or relay selection procedure. Either or both of these may be initiated.

[0179] A remote WTRU can perform the cell selection, cell reselection, relay selection, and / or relay reselection procedures in sequence (e.g., one first, then the other). In such cases, the remote WTRU can determine the order of such procedures. Alternatively or additionally, a remote WTRU can perform two procedures in parallel. For example, depending on whether the relay reselection procedure or the cell reselection procedure was completed first (and provided the appropriate cell / relay), the remote WTRU can initiate re-establishment to the relay WTRU or directly to the cell.

[0180] The WTRU may decide whether to perform neither cell selection nor relay selection, to perform either cell selection or relay selection, to perform both cell selection and relay selection, and / or which to perform first, based on 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, e.g., in the relay's SIB); whether the WTRU is PC5-RRC connected to a relay WTRU; whether the remote WTRU is connected via Uu or via a relay WTRU; whether the WTRU has already initiated a relay reselection procedure (e.g., due to another trigger such as Uu RSRP, or as a result of some explicit / implicit instruction by the network to initiate such reselection); the current Uu RSRP measurement (e.g., with respect to a threshold); the network configuration; and / or any or a combination of SL measurements.

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

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

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

[0184] Regarding the determination of whether to perform cell selection or relay selection, or to perform one or both, and / or which to perform first, based on the network configuration, for example, a remote WTRU can be configured with a cell selection / relay selection order. Such a configuration may be explicit (e.g., an indicator in the SIB or a dedicated RRC) or may be tied to another network configuration based on some rule. For example, a WTRU can be configured with a bearer / QoS flow, and the WTRU should initiate one or the other selection procedure for that bearer / QoS flow, which may be in a specific order.

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

[0186] A remote WTRU can use a single timer (similar to T311, for example) or determine whether the duration has elapsed for both cell selection and relay selection. For example, a remote WTRU can start a timer (T3XX) upon re-establishment trigger and, if it fails to find either a suitable cell or relay before the duration elapses, can move to RRC_IDLE. 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, a remote WTRU can use a first timer or duration when configured to perform only cell selection, a second timer or duration when configured to perform only relay selection, and a third timer or duration when configured to perform both cell selection and relay selection. Furthermore, a remote WTRU may use different timers or durations depending on whether cell selection and relay selection are performed in parallel or sequentially, based on the conditions described herein.

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

[0188] The remote WTRU can stop a timer like T311 once it has selected a cell or relay (depending on which was found first). Alternatively or additionally, the remote WTRU can continue the timer like T311 until it has selected / found both 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 can determine that the duration has not elapsed and can start / continue relay selection until a suitable relay is also found. Alternatively or additionally, if the timer or duration like T311 has expired, the remote WTRU can start re-establishing to a suitable cell at the time of timer or duration expiration.

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

[0190] For example, a remote WTRU can determine such a threshold based on the current Uu RSRP measurement. For instance, a remote WTRU can set a higher SL RSRP threshold to determine if the relay is appropriate when the Uu RSRP is higher when a Uu RLF / re-establishment is triggered.

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

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

[0193] Regarding determining relay WTRUs based on measurements reported to the network, for example, a remote WTRU can be configured with measurements such as the RRM of an SL relay. The remote WTRU can directly trigger a re-establishment for relay WTRUs that are in the list of relays reported to the network by the WTRU based on the reported measurements.

[0194] Regarding determining the relay WTRU based on the previous relay selection procedure, for example, if the remote WTRU has already selected the appropriate relay, the remote WTRU can initiate re-establishment to the relay without performing cell / relay re-selection.

[0195] A remote WTRU can perform re-establishment via a relay or directly via a Uu. For example, a WTRU may decide to perform re-establishment based on a first suitable entity (e.g., a cell or relay) determined in the remote WTRU. For example, a remote WTRU can perform both cell selection and relay selection simultaneously and select a first suitable entity to initiate re-establishment. For example, a remote WTRU can configure an order for performing cell selection versus relay selection. For example, if a remote WTRU performing relay selection finds a suitable relay (e.g., SL RSRP exceeds the threshold, meets upper-layer criteria, and the relay is connected to a PLMN permitted for the remote WTRU) before a remote WTRU performing cell selection finds a suitable cell (e.g., Uu RSRP exceeds the threshold and permitted PLMN), the remote WTRU can initiate re-establishment via the relay.

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

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

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

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

[0200] In embodiments, a relay WTRU can determine cause values ​​for its own establishment / re-establishment / restart operation based on the properties or characteristics of a transmission from the remote WTRU itself. Such a remote WTRU transmission may be further associated, for example, with a transmission that initiated the connection by the relay WTRU. Such properties or characteristics may include any or a combination of the RLC channel from which data is received from the remote WTRU, Uu RRC messages / procedures triggered by the remote WTRU, a subset of resources (e.g., time or frequency) from which data is received from the remote WTRU, and / or explicit signaling from the remote WTRU.

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

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

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

[0204] Regarding explicit signaling from a remote WTRU, for example, a remote WTRU can send cause values ​​on the Uu to the relay WTRU for its own connection establishment / re-establishment / restart signaling. For example, a remote WTRU can send SL MAC CE, adaptation layer control messages, SL RRC messages, PHY signals (e.g., SCI), or other explicit signaling indicating the establishment cause. For example, a remote WTRU can send an explicit instruction when its establishment cause is one or a subset of values. A relay WTRU can select its own establishment cause from the establishment causes received from the remote WTRU. For example, a remote WTRU can send an instruction on the SL (e.g., in SL MAC CE, SL RRC messages, or SCI) when access by the remote WTRU is associated with a particular cause value (e.g., emergency access). In that case, the relay WTRU can use a first cause value (e.g., emergency access) and, in other cases, a second cause value (e.g., new cause value). For example, a remote WTRU can send a cause value to a relay WTRU for establishing / re-establishing / restarting its own connection on the Uu. If the cause value is one of a subset of cause values, the relay WTRU can use the first cause value (e.g., emergency access); otherwise, the relay WTRU can use the second cause value (e.g., new cause value).

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

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

[0207] Regarding network preferences / configurations, for example, a network can change mappings using SIB / RRC signaling. For example, a relay WTRU can receive explicit mappings applied by the network. For example, a relay WTRU can receive preference instructions (e.g., in SIB or RRC signaling, or another logically equivalent message) that indicate the relay WTRU should use a first mapping over a second mapping.

[0208] With regard to sidelink measurements (e.g., CBR, CR, SL RSRP, and / or resource load in relays), for example, a relay WTRU can modify (or determine) the mapping based on sidelink channel measurements such as CBR measurements, CR measurements, or relay load measurements.

[0209] In some embodiments, a relay WTRU can determine the reason for restarting its own restart procedure based on the access identification information of a remote WTRU. A relay WTRU can receive the remote WTRU's access identification information 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, a relay WTRU can determine the access identification information based on knowledge of whether the remote WTRU is requesting emergency service. Alternatively or additionally, a relay WTRU can receive the remote WTRU's access identification information from the network (e.g., in dedicated RRC signaling). A remote WTRU can transmit access identification information to a connected relay WTRU upon establishing a Uu connection via the relay. Alternatively or additionally, a remote WTRU can transmit access identification information following mobility (e.g., reselection and PC5-RRC connection to a new relay, or connection mode mobility from a direct (Uu-via) link). A remote WTRU can trigger an SL transmission to the relay WTRU if its access identification information changes while it is connected to the relay WTRU.

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

[0211] A relay WTRU can determine (for example, based on configuration or prior configuration) the timeframe for determining the cause of establishment of the relay WTRU based on the access identifier of the remote WTRU, following the receipt of a paging message addressed to the remote WTRU. Such behavior may be used when a relay WTRU initiates reactivation / establishment upon receiving a remote WTRU transmission in response to paging. Alternatively, a relay WTRU with RRC_INACTIVE / RRC_IDLE can initiate connection establishment / reactivation immediately after receiving a paging message directed to the remote WTRU, and can use the access identifier of the remote WTRU to determine the cause of establishment for such connection establishment / reactivation.

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

[0213] For example, a relay WTRU in RRC_IDLE mode can 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 it to highPriorityAccess if the remote WTRU initiates a re-establishment procedure, and / or set a new cause value for relay access. A relay WTRU in RRC_INACTIVE mode can set the establishment cause to emergency if the remote WTRU has established emergency services and the remote WTRU initiates a re-establishment procedure, set it to highPriorityAccess if the remote WTRU initiates a re-establishment procedure, set it to a value determined from the remote WTRU's access identification information if the remote WTRU receives a paging message from the relay WTRU, and otherwise set it to a new cause value for relay access.

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

Claims

1. A wireless transceiver unit (WTRU), Processor and Equipped with a transceiver, The processor and the transceiver are, To detect side link wireless link failures, In response to the detection of the side-link wireless link failure, a first timer is started based on a first timer value associated with the selection of a candidate node, wherein the candidate node is a relay node or a network node. The process involves selecting a candidate node for re-establishing the connection, wherein the selected candidate node is the relay node. Receiving configuration information from at least one of the relay node or network node, wherein the configuration information includes at least a second timer value associated with a second timer, and the second timer is associated with the connection re-establishment. When the candidate node is selected, the first timer is stopped, The determination of whether the configuration information also includes a third timer value associated with the second timer, wherein the third timer value is used for re-establishing the connection when the WTRU is configured as a remote WTRU. When the candidate node is selected, under the condition that the configuration information also includes the third timer value, the second timer is started using the third timer value. If the configuration information does not include the third timer value, and the candidate node is selected, the second timer is started using the second timer value. Sending a re-establishment request message to the relay node, WTRU is configured to execute.

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

3. The WTRU according to claim 1, further configured such that the processor and the transceiver enter an idle mode on the condition that the WTRU does not receive a response to the re-establishment request message before the expiration of the second timer.

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

5. The WTRU according to claim 1, wherein the first timer is a T311 timer.

6. The WTRU according to 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 the number of consecutive hybrid automatic retransmission request (HARQ) discontinuous transmissions (DTX) performed, or determining the number of consecutive retransmissions performed.

8. The WTRU according to claim 1, wherein the configuration information includes at least one system information block (SIB).

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

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

11. A method performed by a wireless transceiver unit (WTRU), To detect side link wireless link failures, In response to the detection of the side-link wireless link failure, a first timer is started based on a first timer value associated with the selection of a candidate node, wherein the candidate node is a relay node or a network node. The process involves selecting a candidate node for re-establishing the connection, wherein the selected candidate node is the relay node. Receiving configuration information from at least one of the relay node or network node, wherein the configuration information includes at least a second timer value associated with a second timer, and the second timer is associated with the connection re-establishment. When the candidate node is selected, the first timer is stopped, The determination of whether the configuration information also includes a third timer value associated with the second timer, wherein the third timer value is used for re-establishing the connection when the WTRU is configured as a remote WTRU. When the candidate node is selected, under the condition that the configuration information also includes the third timer value, the second timer is started using the third timer value. If the configuration information does not include the third timer value, and the candidate node is selected, the second timer is started using the second timer value. Sending a re-establishment request message to the relay node, A method that includes this.

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

13. The method of claim 11, further comprising the WTRU entering idle mode on the condition that it does not receive a response to the re-establishment request message before the expiration of the second timer.

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

15. The method of claim 11, wherein the first timer is a T311 timer.

16. The method of claim 11, wherein the second timer is a T301 timer.

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

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

19. The method of claim 11, wherein selecting a candidate node for re-establishing a connection includes measuring the signal quality associated with the candidate node.

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

Images