RLF and recovery associated with multi-hop and multi-connectivity relays

Abstract

Related systems, methods, and means for radio link failure (RLF) and recovery for multi-hop and multi-connectivity relays are described herein. A wireless transmit / receive unit (WTRU) can act as a relay to another WTRU (e.g., a remote WTRU). For example, a first WTRU can act as a relay WTRU (e.g., a relay from the WTRU to a network) to a second WTRU (e.g., a remote WTRU). The first WTRU can provide information associated with cell reselection and / or re-establishment to the second WTRU (e.g., if the first WTRU experiences a radio link failure).

Description

Technical Field

[0004]

[0001] (Cross - reference to related applications) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 228,874, filed Aug. 3, 2021, the disclosure of which is incorporated herein by reference in its entirety.

Background Art

[0002] Mobile communications using wireless communication have been continuously evolving. The fifth generation may be referred to as 5G. Previous (conventional) generations of mobile communications may be, for example, the fourth generation (4G) long - term evolution (LTE).

Summary of the Invention

[0003] Systems, methods, and means related to radio link failure (RLF) and recovery for multi - hop and multi - connectivity relay are described herein. A wireless transmit / receive unit (WTRU) can act as a relay to another WTRU (e.g., a remote WTRU). For example, a first WTRU can operate as a relay WTRU (e.g., a relay from the WTRU to the network) with respect to a second WTRU (e.g., a remote WTRU). The first WTRU can provide information associated with cell reselection and / or re - establishment to the second WTRU (e.g., when the first WTRU experiences a radio link failure). <​​In the example, a relay WTRU associated with a remote WTRU can receive threshold and logical channel weight notifications. The relay WTRU can determine the number of hops from the relay WTRU to the network. The relay WTRU can send radio link failure (RLF) notifications to the remote WTRU. For example, an RLF notification may be a first-type RLF notification or a second-type RLF notification. If the relay WTRU is associated with a first operating condition and does not receive a second-type RLF notification from the parent relay, the relay WTRU can determine the values ​​associated with the logical channel weight and hop count. If the value is less than the threshold, the RLF notification may be a first-type RLF notification. If the value is greater than the threshold, the RLF notification may be a second-type RLF notification. If the relay WTRU is associated with a second operating condition, or if the relay WTRU receives a second-type RLF notification from the parent relay, the RLF notification may be a second-type RLF notification.

[0005] In the example, the action may be based on a sidelink (SL) and / or user-to-user (Uu) RLF in the relay WTRU. The WTRU can send and / or forward requests notified of SL RLF and / or recovery. The WTRU may receive a set of remote WTRUs to forward RLF notifications and / or recover from the network. If the WTRU receives an RLF notification from its parent WTRU, it can determine its action. In the example, the successful (re)selection and / or re-establishment of a cell may be notified to the remote WTRUs. Whether to perform cell and / or relay (re)selection may be conditional on one or more aspects in the relay or its child WTRU(s). Whether to select a relay may be conditional on whether the relay is connected via Radio Resource Control (RRC_CONNECTED). Relay WTRU notifications of RLFs to remote WTRUs may depend on the type of RLF (e.g., master RLF (M-RLF) or secondary RLF (S-RLF)). Relay WTRUs and / or remote WTRUs may interrupt SL transmission and / or reception based on RLF notification transmission and / or reception. Remote WTRUs may have different behaviors based on the reception of different RLF types from relay WTRUs. Remote WTRUs may determine, based on RLF notifications, which Uu bearer(s) should interrupt transmission on. Remote WTRUs may activate, deactivate, or switch Packet Data Convergence Protocol (PDCP) entities based on the reception of RLF notifications.

[0006] In the example, a relay WTRU can receive notification from a first WTRU of a request to relay an RLF notification. The relay WTRU can determine the relay request based on the Radio Resource Control (RRC) state. The relay WTRU can send notification of the relay request to a second WTRU. In the example, the relay WTRU can determine the distance value based on one or more relay characteristics. Provided that an RLF notification is received from the second WTRU, the relay WTRU can send an RLF notification to the first WTRU, and if the distance value is less than the threshold, a first RLF notification type is sent, and if the distance value is greater than or equal to the threshold, a second RLF notification is sent. [Brief explanation of the drawing]

[0007] [Figure 1A] This is a system diagram illustrating a typical communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] This is a system diagram illustrating a typical wireless transmit / receive unit (WTRU) that can be used in a communication system illustrated in Figure 1A, according to one embodiment. [Figure 1C] This is a system diagram illustrating a typical radio access network (RAN) and a typical core network (CN) that may be used in a communication system illustrated in Figure 1A, according to one embodiment. [Figure 1D] This is a system diagram illustrating further representative RANs and further representative CNs that may be used in the communication system illustrated in Figure 1A according to one embodiment. [Figure 2] This diagram shows a user-plane radio protocol stack for WTRU versus network relay (e.g., PC5) involving Layer 2. [Figure 3] This diagram shows a control plane radio protocol stack for WTRU versus network relay (e.g., PC5) involving Layer 2. [Figure 4] This figure illustrates exemplary radio link failure (RLF) and recovery in a multi-hop and / or multi-connectivity WTRU-to-network (NW) relay. [Figure 5] This diagram shows an exemplary architecture in which a relay WTRU is configured in dual connectivity (DC) with a master cell group (MCG) and a secondary cell group (SCG). [Figure 6] This diagram shows an exemplary architecture in which the relay WTRU consists of an MCG and an SCG. [Modes for carrying out the invention]

[0008] Figure 1A illustrates 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 DFT-Spread OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtering OFDM, and Filter Bank Multi Carrier (FBMC).

[0009] As shown in Figure 1A, the communication system 100 may include radio transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, Public Switched Telephone Network (PSTN) 108, the Internet 110, and other networks 112, but it will be understood that the disclosed embodiments intend any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a radio environment. For example, WTRU102a, 102b, 102c, and 102d, any of which may be referred to as “station” and / or “STA”, may include User Equipment (UE), 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 devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., for 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 electronics devices, devices operating in commercial and / or industrial wireless networks, etc. Any of WTRU102a, 102b, 102c, and 102d may be interchangeably referred to as UE.

[0010] The communication system 100 may also include base stations 114a and / or base stations 114b. Each of the base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106 / 115, the Internet 110, and / or other networks 112. For example, base stations 114a and 114b may be a Base Transceiver Station (BTS), Node-B, eNodeB (eNB), HomeNodeB, Home eNodeB, gNodeB (gNB), NR NodeB, Site Controller, Access Point (AP), Wireless Router, etc. Although base stations 114a and 114b are each depicted 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.

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

[0012] Base stations 114a and 114b may communicate with one or more WTRUs 102a, 102b, 102c, and 102d via the 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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0029] 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 determine its location based on receiving location information from base stations (e.g., base stations 114a, 114b) via the air interface 116 and / or 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.

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

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

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

[0033] RAN104 may include eNode-B160a, 160b, and 160c, but it will be understood that RAN104 may include any number of eNode-B while maintaining consistency with one embodiment. Each of eNode-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, eNode-B160a, 160b, and 160c may implement MIMO technology. Thus, eNode-B160a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU102a.

[0034] Each of the eNode-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 eNode-B160a, 160b, and 160c may communicate with each other via the X2 interface.

[0035] The CN106 shown in Figure 1C may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (or PGW) 166. Although each of the aforementioned elements is illustrated 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.

[0036] The MME162 can be connected to each of the eNode-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.

[0037] 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 also 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.

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

[0039] 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. In addition, 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.

[0040] Although the WTRU is described 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.

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

[0042] A WLAN in Infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) of the BSS and one or more stations (STAs) associated with the AP. The AP may have access to or interfaces with another type of wired / wireless network that carries traffic entering and / or leaving the Distribution System (DS) or BSS. Traffic originating outside the BSS and destined for the STA may reach and be delivered to the STA via the AP. Traffic originating from the STA to destinations outside the BSS may be sent to the AP and then delivered to their respective destinations. Traffic between STAs within the BSS may be transmitted, for example, via the AP; a source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Inter-layer 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.

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

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

[0045] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. The 40 MHz and / or 80 MHz channels mentioned above can be formed by combining multiple 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 transmission 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).

[0046] 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 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using the non-TVWS spectrum. According to a typical embodiment, 802.11ah may support meter-type control / machine-type communications, such as MTC devices in a macro coverage area. MTC devices may have specific features, 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).

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

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

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

[0050] RAN113 may include gNB180a, 180b, and 180c, but it will be understood that RAN113 may include any number of gNBs while maintaining consistency with the embodiment. Each of gNB180a, 180b, and 180c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, gNB180a, 180b, and 180c may implement MIMO technology. For example, gNB180a and 108b may use beamforming to transmit and / or receive signals to gNB180a, 180b, and 180c. Thus, gNB180a may, for example, use multiple antennas to transmit radio signals to 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).

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

[0052] 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-node-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 unlicensed 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 eNode-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 eNode-B160a, 160b, and 160c. In a non-standalone configuration, eNode-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.

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

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

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

[0056] SMF183a and 183b may be connected to AMF182a and 182b in CN115 via the N11 interface. SMF183a and 183b may also be connected to UPF184a and 184b in CN115 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 assigning UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types may be IP-based, non-IP-based, Ethernet-based, etc.

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

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

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

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

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

[0062] References to a timer in this specification may refer to time, period, tracking time, tracking period, etc. References to timer expiration in this specification may refer to determining that time has occurred or that a period has expired.

[0063] Systems, methods, and means related to radio link failure (RLF) and recovery for multi-hop and multi-connectivity relays are described herein. A wireless transmit / receive unit (WTRU) can act as a relay to another WTRU (e.g., a remote WTRU). For example, a first WTRU can act as a relay WTRU (e.g., a WTRU-to-network relay) to a second WTRU (e.g., a remote WTRU). The first WTRU can provide the second WTRU with information related to cell reselection and / or re-establishment (e.g., if the first WTRU experiences a radio link failure).

[0064] In the example, a relay WTRU associated with a remote WTRU can receive threshold and logical channel weight notifications. The relay WTRU can determine the number of hops from the relay WTRU to the network. The relay WTRU can send radio link failure (RLF) notifications to the remote WTRU. For example, an RLF notification may be a first-type RLF notification or a second-type RLF notification. If the relay WTRU is associated with a first operating condition and does not receive a second-type RLF notification from the parent relay, the relay WTRU can determine the values ​​associated with the logical channel weight and hop count. If the value is less than the threshold, the RLF notification may be a first-type RLF notification. If the value is greater than the threshold, the RLF notification may be a second-type RLF notification. If the relay WTRU is associated with a second operating condition, or if the relay WTRU receives a second-type RLF notification from the parent relay, the RLF notification may be a second-type RLF notification.

[0065] In the example, the action may be based on a sidelink (SL) and / or user-to-user (Uu) RLF in the relay WTRU. The WTRU can send and / or forward requests notified of SL RLF and / or recovery. The WTRU may receive a set of remote WTRUs to forward RLF notifications and / or recover from the network. If the WTRU receives an RLF notification from its parent WTRU, it can determine its action. In the example, the successful (re)selection and / or re-establishment of a cell may be notified to the remote WTRUs. Whether to perform cell and / or relay (re)selection may be conditional on one or more aspects in the relay or its child WTRU(s). Whether to select a relay may be conditional on whether the relay is connected via Radio Resource Control (RRC_CONNECTED). Relay WTRU notifications of RLFs to remote WTRUs may depend on the type of RLF (e.g., master RLF (M-RLF) or secondary RLF (S-RLF)). Relay WTRUs and / or remote WTRUs may interrupt SL transmission and / or reception based on RLF notification transmission and / or reception. Remote WTRUs may have different behaviors based on the reception of different RLF types from relay WTRUs. Remote WTRUs may determine, based on RLF notifications, which Uu bearer(s) should interrupt transmission on. Remote WTRUs may activate, deactivate, or switch Packet Data Convergence Protocol (PDCP) entities based on the reception of RLF notifications.

[0066] In the example, a relay WTRU can receive notification from a first WTRU of a request to relay an RLF notification. The relay WTRU can determine the relay request based on the Radio Resource Control (RRC) state. The relay WTRU can send notification of the relay request to a second WTRU. In the example, the relay WTRU can determine the distance value based on one or more relay characteristics. Provided that an RLF notification is received from the second WTRU, the relay WTRU can send an RLF notification to the first WTRU, and if the distance value is less than the threshold, a first RLF notification type is sent, and if the distance value is greater than or equal to the threshold, a second RLF notification is sent.

[0067] A relay WTRU (for example, if the relay WTRU may be an SL relay WTRU that can be used as an exemplary relay WTRU) may determine whether and / or how to send a notice of radio link failure (RLF) to a child node (e.g., a child relay or remote WTRU) based on one or more of the following: a request from the child node, the hop count associated with the relay WTRU (e.g., the number of hops from the relay WTRU or remote WTRU to a network device such as a gNB or base station), or the QoS of the relayed data (e.g., the priority / weight of a logical channel such as an RLC channel).

[0068] An SL relay WTRU can do one or more of the following (for example, associated with notifying child nodes of an RLF): The SL WTRU can receive requests to relay RLF notifications (for example, from one or more remote WTRUs). The SL WTRU can decide to send its own request (for example, to the parent relay WTRU) to receive an RLF notification (for example, from the parent relay WTRU), and this decision may be based on one or more of the following: receiving requests to relay RLF failure notifications from one or more remote WTRUs, or whether the SL relay WTRU is in an operating condition (for example, the RRC_CONNECTED state). The SL WTRU can send a request to the parent relay WTRU. An SL WTRU can determine the distance metric based on one or more of the following: hop count to the network (e.g., gNB, base station, etc.), hop count from the SL WTRU to the network, QoS of the relayed data (e.g., channel priority / weight of logical channels such as RLC channels), or operating conditions of the SL WTRU (e.g., RRC operating conditions such as CONNECTED, IDLE, etc.). The SL WTRU can forward the distance metric to child WTRUs. If an RLF notification is received from a parent relay WTRU and / or an RLF is triggered in an SL relay WTRU, the SL relay WTRU may send an RLF notification to the requesting remote WTRU(s) (e.g., all remote WTRUs), wherein a first type of RLF notification is sent if the relay WTRU has a distance metric below a threshold, and a second type of RLF notification is sent otherwise; send the notification; initiate relay and / or cell reselection and / or re-establishment depending on the operating conditions of the relay WTRU (e.g., RRC operating conditions); or, if a first RLF notification is sent and the re-establishment is successful, send a notification to the requesting remote WTRU indicating that the re-establishment was successful.

[0069] The SL remote WTRU can, for example, determine whether and / or when it should trigger a re-establishment following the receipt of an RLF notification from the relay, based on the type of RLF notification.

[0070] An SL remote WTRU may, for example, send a request to the relay WTRU to receive an RLF notification if the SL remote WTRU is moving to or has moved to RRC_CONNECTED. The SL remote WTRU may, upon receiving a first RLF notification type from the relay WTRU, start and / or track a recovery time (e.g., via a recovery timer), and / or trigger cell and / or relay reselection and / or re-establishment upon the expiration of the recovery time (e.g., recovery timer) and / or receiving a recovery failure from the relay WTRU. The SL remote WTRU may, upon receiving a second RLF notification type, perform cell and / or relay reselection and / or re-establishment based on the receipt of the notification (e.g., immediately upon receipt).

[0071] NR Sidelink can support vehicle-to-anything (V2X) related road safety services. Broadcast, groupcast, and / or unicast communications can be supported in out-of-coverage and in-network coverage scenarios. Sidelink-based relay functionality can support sidelink and / or network coverage extension and / or power efficiency improvements, for example, considering a wide range of applications and services.

[0072] Coverage extensions for sidelink-based communications may include WTRU-to-network coverage extensions or WTRU-to-WTRU coverage extensions. With respect to WTRU-to-network coverage extensions, WTRU coverage reachability may be used for a WTRU to reach a server(s) within a packet data network (PDN) and / or a corresponding WTRU outside the immediate vicinity area. WTRU-to-network relay techniques limited to evolved universal terrestrial radio access (EUTRA) based technologies may not be applicable to NR-based systems for NG-RAN and NR-based sidelink communications. For example, in the case of WTRU-to-WTRU coverage extensions, proximity reachability may be limited to single-hop sidelink links via EUTRA-based or NR-based sidelink technologies, which can cause problems in scenarios without Uu coverage, for example, given limited single-hop sidelink coverage.

[0073] Overall, sidelink connectivity can be extended within the NR framework to support enhanced QoS requirements.

[0074] In the example, WTRU-to-network relay may be provided. In some scenarios, relaying via ProSe WTRU-to-network relay can extend network coverage to out-of-coverage WTRUs by using PC5(D2D) between the out-of-coverage WTRU and the WTRU-to-network relay.

[0075] A ProSe WTRU-to-Network relay can provide general Layer 3 (L3) forwarding functionality, for example, by relaying certain types of IP traffic between a remote WTRU and the network. One-to-one and one-to-many sidelink communication can be used between a remote WTRU and a ProSe WTRU-to-NW relay. For remote WTRUs and relay WTRUs, single-carrier (e.g., public safety ProSe carrier) operation may be supported (e.g., Uu and PC5 may be the same carrier for relay WTRUs and remote WTRUs). A remote WTRU may be authorized by a higher layer and may reside within the coverage of a public safety ProSe carrier, or outside the coverage of any supporting carrier, including the public safety ProSe carrier for WTRU-to-Network relay discovery, (re)selection, and / or communication. A ProSe WTRU-to-Network relay may (e.g., always) be within the coverage of EUTRAN. ProSe WTRU-to-Network relays and remote WTRUs can perform sidelink communication and sidelink discovery, respectively.

[0076] Relay selection or re-selection for relays from ProSe WTRU to NW may be performed based, for example, on a combination of AS layer quality measurements (e.g., reference signal received power (RSRP)) and higher layer criteria.

[0077] The eNB can control whether a WTRU operates as a ProSe WTRU to network relay. ProSe WTRU to network relay operation may be supported in a cell if, for example, the eNB broadcasts information (e.g., arbitrary information) associated with ProSe WTRU to network relay operation. The eNB may provide transmit resources for ProSeWTRU to network relay discovery, for example, using broadcast signaling for the RRC_IDLE state and / or dedicated signaling for the RRC_CONNECTED state. The eNB may provide receive resources for ProSe WTRU to network relay discovery, for example, using broadcast signaling. Before initiating relay discovery to WTRU to the network, the eNB may broadcast minimum and / or maximum WTRU link quality (e.g., RSRP) thresholds that relays may respect to ProSe WTRU to the network. In RRC_IDLE, the WTRU may use the thresholds to autonomously start or stop WTRU to network relay discovery if the eNB broadcasts a pool of transmit resources. In RRC_CONNECTED, a WTRU may use a threshold(s) to determine whether the UE can indicate to the eNB that the WTRU is a relay WTRU and wishes to initiate ProSe WTRU vs. Network Relay Discovery. The WTRU may initiate a request for ProSe-WTRU vs. Network Relay Discovery resources by dedicated signaling (e.g., considering broadcasted thresholds) if the eNB does not broadcast a transmit resource pool for ProSe-WTRU vs. Network Relay Discovery. A ProSe-WTRU vs. Network Relay may perform ProSe WTRU vs. Network Relay Discovery (e.g., while in RRC_IDLE) if the ProSe-WTRU vs. Network Relay is initiated by broadcast signaling.ProSe WTRU to network relay may perform relay discovery if the ProSe WTRU to network relay is initiated by dedicated signaling (for example, as long as it is RRC_CONNECTED).

[0078] A ProSe WTRU to network relay that performs sidelink communication for ProSe WTRU to network relay operation may be in RRC_CONNECTED. For example, if ProSe receives a Layer 2 link establishment request and / or a Temporary Mobile Group Identification (TMGI) monitoring request (e.g., a higher layer message) from a remote WTRU, it can indicate to the eNB that it is a ProSe WTRU to network relay and intends to perform ProSe WTRU to network relay sidelink communication. In the example, the eNB may provide resources for ProSe WTRU to network relay communication.

[0079] A remote WTRU may decide to initiate monitoring for ProSe WTRU to Network Relay Discovery. Depending on the configuration of resources for ProSe WTRU to Network Relay Discovery, the remote WTRU may send a ProSe WTRU to 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 and / or communicate with the ProSe WTRU to Network Relay WTRU by sending a ProSe WTRU to 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 to Network Relay Discovery and / or communication. The eNB may provide transmit resources using broadcast and / or dedicated signaling and / or provide receive resources using broadcast signaling for the operation of ProSe WTRU to Network Relay. A remote WTRU may, for example, stop using ProSe WTRU versus network relay discovery and / or communication resources if the RSRP broadcast threshold is exceeded. The time for traffic switching from Uu to PC5, or vice versa, may be determined by the upper layer.

[0080] A remote WTRU can perform wireless measurements on the PC5 interface and use them, along with higher-layer criteria, for ProSe WTRU-to-network relay selection and reselection. A ProSe WTRU-to-network relay may be considered suitable with respect to the wireless criteria if, for example, the PC5 link quality exceeds a configured threshold (e.g., pre-configured or provided by the eNB). The remote WTRU may select a ProSe WTRU-to-network relay that meets the higher-layer criteria and provides the best PC5 link quality among (e.g., all) suitable ProSe WTRU-to-network relays.

[0081] A remote WTRU may trigger a ProSe WTRU-to-Network Relay reselection, for example, if the current PC5 signal strength of the ProSe WTRU-to-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) from the ProSe WTRU-to-Network Relay.

[0082] WTRU-to-Network (NW) relays can be used for wearable devices. ProSe WTRU-to-NW relays can use an L3 (e.g., IP layer) relay approach. A WTRU-to-NW relay for wearables can be expected to be an L2 relay based on the protocol stack shown in Figure 2, for example. Figure 2 shows a user-plane radio protocol stack for a WTRU-to-Network relay (e.g., PC5) involving Layer 2. Figure 3 shows a control-plane radio protocol stack for a WTRU-to-Network relay (e.g., PC5) involving Layer 2.

[0083] Connection establishment for unicast links in NR V2X may be provided. Relay technology may be based on a one-to-one communication link established at a higher layer (e.g., the ProSe layer) between WTRUs (e.g., two WTRUs such as a remote WTRU and a WTRU-to-NW relay). Such a connection may be transparent to the AS layer, and connection management signaling and procedures performed at the higher layer may be carried out by the AS layer data channel. In this example, the AS layer may not be aware of the one-to-one connection.

[0084] In NR V2X, the AS layer can support unicast links between WTRUs (e.g., two WTRUs). Unicast links can be initiated by higher layers (e.g., in a ProSe one-to-one connection). The AS layer can be notified of the existence of a unicast link and of data (e.g., arbitrary data) being transmitted unicast between peer WTRUs. With such knowledge, the AS layer can support HARQ feedback, Channel Quality Indicator (CQI) feedback, and / or power control schemes that may be related to unicast.

[0085] Unicast links at the AS layer may be supported via PC5-RRC connections. A PC5-RRC connection can be defined as follows: A PC5-RRC connection may be a logical connection between pairs of source layer 2IDs and destination layer 2IDs within an AS. One PC5-RRC connection may correspond to one PC5 unicast link. PC5-RRC signaling may be initiated based on the establishment of its corresponding PC5 unicast link. PC5-RRC connections and their corresponding sidelink SRBs and / or sidelink DRBs may be released when the PC5 unicast link is released, for example, as indicated by a higher layer.

[0086] For a unicast PC5-RRC connection (e.g., each unicast PC5-RRC connection), one sidelink signaling radio bearer (SRB) may be used to transmit PC5-S messages (e.g., before PC5-S security is established). One sidelink SRB may be used to transmit PC5-S messages to establish PC5-S security. One sidelink SRB may be used to transmit PC5-S messages after protected PC5-S security has been established. One sidelink SRB may be used to transmit PC5-RRC signaling, which may be transmitted protected only after PC5-S security has been established (e.g., may only be transmitted).

[0087] PC5-RRC signaling may include, for example, a sidelink configuration message (e.g., RRCReconfigurationSidelink), where the WTRU may configure parameters associated with the Rx of the sidelink radio bearers (e.g., each SLRB) in the peer WTRU. In the example, the reconfiguration message may configure parameters for protocols in the L2 stack (e.g., each protocol) (e.g., Service Data Adaptation Protocol (SDAP), Packet Data Convergence Protocol (PDCP), etc.). The receiving WTRU may, for example, confirm or reject the configuration depending on whether it can support the configuration proposed by the peer WTRU.

[0088] RLF can be used for single-hop WTRU versus NW relays. The following may relate to RLF for SL relays and integrated access and backhaul (IAB).

[0089] In the example, if a Uu RLF is detected by a relay WTRU, the relay WTRU can send a PC5-S message to its connected remote WTRU(s), which can trigger a relay reselection. In the example, a Uu RLF notification from a relay WTRU can trigger a remote WTRU connection re-establishment. In the example, a Uu RLF notification from a relay WTRU can trigger a remote WTRU connection re-establishment. In the example, a remote WTRU can trigger a remote WTRU connection re-establishment based on its detection of a PC5 RLF.

[0090] In the example, one or more of the following may apply to the IAB: The trigger for generating a Type 2 RLF notification may be upon RLF detection (e.g., it may occur). The trigger for sending a Type 3 RLF notification may be a normal recovery after a BH RLF (e.g., it may indicate one). Type 2 and Type 3 BH RLF notifications may be sent via a backhaul adaptive layer (BAP) control PDU. Based on the receipt of a Type 2 notification, the IAB node does not need to initiate RRC re-establishment.

[0091] In single-hop, single-connectivity, and WTRU-to-NW relay configurations, a remote WTRU (e.g., in RRC_CONNECTED) can perform recovery based, for example, on a failure of the Uu connection. Recovery can be achieved by causing the relay WTRU to indicate the failure to the remote WTRU, triggering the remote WTRU to reselect (e.g., cell and / or relay) and re-establish (e.g., similar to the WTRU). A similar mechanism may exist in the IAB (e.g., BH RLF notification).

[0092] A reasonable time for a relay WTRU to send a notification to a remote WTRU(s) may be based on a re-establishment failure. The relay WTRU may first attempt recovery before the remote WTRU attempts a similar procedure (e.g., by re-selecting a new relay).

[0093] In multi-hop configurations, the techniques described herein may not be used. Having relay WTRUs (e.g., each relay WTRU) attempt to re-establish themselves before indicating failure to subsequent relays can result in delays at relay nodes. In the example, some of the relay WTRUs along the chain may not be in RRC_CONNECTED, and having them perform network access (e.g., updating the network with new connectivity information) may be undesirable. In the example, the amount of time a remote WTRU waits (e.g., an acceptable amount of time) may vary depending on the QoS supported by the remote WTRU. Different approaches may be possible regarding which relay WTRUs (e.g., along the chain) may be required to attempt to re-establish themselves, and when to initiate the re-establishment (e.g., immediately based on RLF, or waiting for the parent to attempt recovery).

[0094] When an RLF is indicated by the parent relay WTRU, it can be determined when re-establishment should be performed (for example, in a remote WTRU or a relay WTRU in a multi-hop architecture).

[0095] Figure 4 shows an exemplary RLF and recovery in a multi-hop and / or multi-connectivity WTRU-to-NW relay. In the example, the RLF may propagate to connected WTRUs (e.g., all connected WTRUs) in the multi-hop relay. The multi-hop relay can act as a relay WTRU for multiple remote WTRUs. Remote WTRUs may be relay WTRUs for their own remote WTRUs (e.g., in a multi-hop architecture). A remote WTRU can refer to a WTRU attached in the downlink direction (e.g., in a WTRU-to-Network relay) as described herein, and may include an attached remote WTRU that can be a relay WTRU. A relay WTRU can refer to a WTRU attached in the uplink direction (e.g., for a WTRU-to-Network relay) that can act as a relay for a remote WTRU (e.g., WTRU-to-Network) as described herein.

[0096] The techniques described herein can be applied to different relay scenarios. In the examples, the relay WTRU may be an SL WTRU to NW relay, an SL WTRU to WTRU relay, or an IAB node.

[0097] A single connectivity may be provided. One or more actions may be included, for example, based on SL / UU RLF in a relay WTRU.

[0098] Based on the detection of a Uu RLF, the detection of an (e.g., SL) RLF, the detection of a beam fault (e.g., with respect to a Uu or SL via the remote and / or relay WTRU), and / or the receipt of an RLF notification from the parent relay WTRU, the relay WTRU may perform one or more of the following actions. The actions may include one or more of the following: A relay WTRU may trigger Uu re-establishment, trigger relay re-selection, cancel a previously initiated procedure (e.g., re-establishment, re-selection, and / or access procedure), initiate an access procedure with the network, send notifications to higher layers and / or release a PC5-S connection, for example, by sending a PC5-S message (e.g., at higher layers via higher layer signaling) as opposed to sending an RLF notification (e.g., as described herein), for example, by sending a notification of the success or failure of a recovery procedure to a remote WTRU when a procedure is completed (e.g., a re-establishment or re-selection procedure is completed), or by sending a notification to the remote WTRU of the cell on which recovery was performed, or whether recovery was performed on the same cell or group of cells. Initiating an access procedure with the network may include connection establishment, restart procedures, RNA procedures, RACH procedures, small data transmission, and / or beam failure notifications. A relay WTRU can send notices to one or more of its connected remote WTRUs and / or child relay WTRUs, which may include one or more of the following: The relay WTRU can relay received RLF notices (e.g., received from its own relay WTRU) to one or more remote WTRUs (e.g., one or more of the remote WTRUs at the next hop). The relay WTRU can generate an RLF notice message (e.g., a new RLF notice message) and send that message to one or more of the relay WTRU's remote WTRUs and / or child relay WTRUs.A relay WTRU can generate RLF notification messages of different types and / or RLF notification messages containing different information (e.g., the type of RLF notification received from the parent WTRU, the operating conditions of the relay WTRU (e.g., RRC conditions), logical channel priority (e.g., weights), the number of hops from the relay WTRU to the network (e.g., gNB, base station, etc.), values ​​associated with the logical channel priority and number of hops, or thresholds associated with the values, depending on one or more conditions described herein, not limited to these).

[0099] The type and / or information provided in the action(s), the order of the actions, and / or messaging (e.g., RLF notification messages, message type, or any other messaging) may depend on whether the relay WTRU is acting as a relay to another remote WTRU (e.g., merely acting as a relay) or whether the relay WTRU is a WTRU with its own Uu traffic (e.g., the relay WTRU is a remote WTRU). This can be determined by the presence of its own DRB in the relay WTRU (e.g., whether the relay WTRU has its own Uu traffic), which may be conditional on the presence of PDCP entities and / or SDAP entities in the relay WTRU, the presence of a DRB configuration in the relay WTRU, and / or the presence of an adaptation layer associated with remote WTRU transmissions. Whether the relay WTRU has its own UU traffic can be determined by whether the relay WTRU has an RRC state with the network (e.g., RRC_IDLE, RRC_INACTIVE, or RRC_CONNECTED). For example, based on the receipt of an RLF notification and / or the determination of an SL RLF with the parent relay WTRU, if the relay WTRU does not have an established Uu DRB (e.g., any established Uu DRB), it may forward the RLF notification to the attached remote WTRU and / or child relay WTRU (e.g., send an RLF notification). In the example, if the relay WTRU has its own established Uu DRB, the relay WTRU may trigger a re-establishment procedure (e.g., if the relay WTRU is in RRC_CONNECTED) or a re-selection procedure (e.g., if the relay WTRU is in RRC_INACTIVE or RRC_IDLE).

[0100] Actions, their order, and / or the types and / or information provided in messaging (e.g., RLF notification messages, message types, and any other messaging) may depend, for example, on the operating conditions of the relay WTRU (e.g., RRC operating conditions) if the relay WTRU is configured in an RRC state. A relay WTRU can trigger a re-establishment if it is in RRC_CONNECTED. Otherwise (e.g., if the WTRU is not in the RRC_CONNECTED state), the relay WTRU can relay the received RLF notification to its remote WTRU(s), or, for example, if the relay WTRU triggers an RLF, it can send an RLF notification to its remote WTRU(s).

[0101] The actions(s), the order of the actions, and / or the types and / or information provided in messaging (e.g., RLF notification messages, message types, and any other messaging) may depend on the RRC status of the attached remote WTRU (e.g., any attached remote WTRU in the downlink direction) and / or the parent relay WTRU (e.g., in the uplink direction), based on information that may be received from the WTRU (e.g., as described herein). For example, if one or more of the remote WTRUs and / or child relay WTRUs indicate that they are in RRC_CONNECTED and / or RRC_INACTIVE, the relay WTRU may forward and / or send RLF notifications to the attached remote and / or child relay WTRUs and / or trigger re-establishment and / or cell and / or relay re-selection procedures. In the example, if the attached remote WTRU and / or child relay WTRU are RRC_IDLE and / or RRC_INACTIVE, the relay WTRU may release the RRC 5-RRC connection and maintain the RRC connection until it receives a recovery notification from the relay or the parent relay, and / or until the expiration of time (e.g., via a timer without recovery events), after which the relay WTRU may release the RRC 5-RRC connection.

[0102] Actions(s), the order of actions, and / or the type and / or information provided in messaging (e.g., RLF notification messages, message types, etc.) may depend on the number of hops, the weight (e.g., of or associated with a logical channel, such as the highest priority logical channel), and / or a distance metric calculated by the relay WTRU (e.g., calculated to a value), which may represent the number of hops or overall weight (e.g., a value) of the route to the destination node, where the overall weight (e.g., a value) may be based on a combination of the number of hops and the weight / priority of the logical channel (e.g., the highest priority logical channel). The destination node may be a network-side node such as a gNB or base station. If the number of hops or overall weight (e.g., a value calculated based on the number of hops and the weight / priority of the logical channel) exceeds a threshold, the relay WTRU may send a notification to the remote WTRU and / or child relay WTRUs of the RLF without initiating a recovery or reselection procedure. If the hop count and / or overall weight (e.g., a value calculated based on the hop count and logical channel weight / priority) falls below a threshold, the relay WTRU may trigger a recovery procedure or a reselection procedure (in addition to potentially sending a notification). In the example, the relay WTRU may send a first RLF notification type if the hop count and / or overall weight (e.g., a value calculated based on the hop count and logical channel weight / priority) falls below a threshold, and otherwise send a second RLF notification type and / or weight. The WTRU may calculate the overall weight based on the hop count, operating conditions (e.g., RRC operating conditions such as RRC_CONNECTED or RRC_IDLE), QoS (e.g., logical channel weight / priority such as the highest priority logical channel), and / or one or more of the other factors described herein.For example, a WTRU can combine the number of hops with QoS (e.g., logical channels, e.g., the weight / priority of the highest priority logical channel, which may be a Radio Link Control (RLC) channel, e.g., the highest priority channel) to determine an overall weighted value of the distance to a network (e.g., a gNB, base station, etc.) (e.g., a value mathematically associated with the logical channel weight and the number of hops), for example, by multiplying the number of hops by a coefficient selected based on the priority of the logical channel, where the logical channel may be associated with one or more remote WTRUs. A WTRU can combine the number of hops with operating conditions (e.g., RRC operating conditions). For example, a WTRU can combine the number of hops with RRC operating conditions by multiplying the number of hops by a first coefficient for RRC_CONNECTED WTRUs, a second coefficient for RRC_INACTIVE WTRUs, and a third coefficient for RRC_IDLE WTRUs.

[0103] The type and / or information provided in the action(s), the order of the actions, and / or messaging (e.g., RLF notification messages, message types, etc.) may depend on preference and / or request information provided by the remote WTRU (e.g., as described herein). For example, preference information may represent the remote WTRU's ability to perform cell and / or relay selection at a given time. Preference information may represent the remote WTRU's coverage status (e.g., in-coverage (IC) or out-of-coverage (OOC)). Preference information may represent the availability of an alternative relay WTRU and / or the existence of a direct Uu connection. Depending on the content of the preference information, the relay WTRU may determine whether to send an RLF notification immediately or only after a re-establishment by itself or its parent has failed. Depending on the content of the preference information, the relay WTRU may determine whether to send a re-establishment success or failure notification after notifying its child WTRU of the RLF notification. For example, if the expectation is that the child WTRU can perform re-establishment immediately after the RLF notification, the relay WTRU may not send a notification of a failed or successful re-establishment after the RLF notification to the child WTRU. The relay WTRU may trigger re-establishment if it receives notification from at least one remote and / or child relay WTRU that the remote WTRU and / or child relays request and / or prefer that the relay WTRU perform its own re-establishment procedure.

[0104] Actions(s), the order of actions, and / or the types and / or information provided in messaging (e.g., RLF notification messages, message types, or any other messaging) may depend on notifications from one or more remote WTRUs and / or child relay WTRUs for successful recovery (e.g., re-establishment, re-selection, access, etc.). For example, a relay WTRU may cancel an access procedure based on receiving notifications from a remote WTRU and / or child relay WTRU of a successful re-establishment by that remote WTRU.

[0105] The type and / or information provided in the action(s), the order of the actions, and / or messaging (e.g., RLF notification message, message type, etc.) may depend on the hop interface (e.g., Uu or SL) and / or the hop count of the link where the RLF was detected. A relay WTRU may indicate whether the RLF is a Uu RLF or an SL RLF via RLF notifications to remote WTRUs and / or child relay WTRUs. A relay WTRU may indicate the hop count and / or overall weight to the network (e.g., gNB, base station, etc.) of the link where the RLF occurred via RLF notifications to remote WTRUs and / or child relay WTRUs. A relay WTRU may include hop and / or link identification (e.g., hop count) along with the RLF notification.

[0106] Actions(s), the order of actions, and / or the type and / or information provided in messaging (e.g., RLF notification messages, message types, and any other messaging) may depend on a configured time (e.g., a configured timer). For example, a relay WTRU may start a time (e.g., a timer) based on the receipt of an RLF notification. A relay WTRU may perform its own recovery procedure (e.g., re-establishment) and / or trigger cell and / or relay re-selection procedures. Based on the expiration of a time (e.g., a timer without recovery or receipt of recovery), a relay WTRU may send messages to remote WTRUs and / or child relay WTRUs. The value of the configured time (e.g., configured timer), and / or whether to configure the time (e.g., timer compared to immediately starting the procedure), may depend on the measured constant bitrate (CBR) at the relay WTRU, the QoS of the expected data being relayed by the relay WTRU (based on, for example, the configuration of the RLC channel configured with the child or parent relay WTRU, the state of the child relay WTRU, remote WTRU, or relay WTRU, and / or the number of hops and / or overall weight of the route to the network associated with the relay WTRU (e.g., gNB, base station, etc.)).

[0107] The actions(s), the order of the actions, and / or the types and / or information provided in messaging (e.g., RLF notification messages, message types, etc.) may depend on the relay architecture (e.g., L2 relay vs. L3 relay). For example, based on the receipt of an RLF notification from a parent relay WTRU and / or detection of an SL RLF by the parent relay WTRU, an L2 relay may forward and / or send an RLF notification to a child relay WTRU, while an L3 relay WTRU may release the PC5-RRC connection and / or send a notification to a higher layer (e.g., without sending an RLF notification).

[0108] Actions, the order of actions, and / or the type and / or information provided in messaging (e.g., RLF notification messages, message types, etc.) may depend on the coverage status of the relay WTRU. Coverage status may include whether the relay WTRU is in coverage of the same cell, RNA, Public Land Mobile Network (PLMN), or a similar group of cells serving the relay WTRU or remote WTRU (e.g., based on notifications received by the remote WTRU), or is out of the scope (OOC), depending on the circumstances. For example, coverage status may include whether the relay WTRU can discover and / or select a parent relay WTRU and / or cell served by the same cell, RNA, PLMN, or similar group of cells serving the relay WTRU or remote WTRU (e.g., based on notifications received by the remote WTRU). For example, a relay WTRU may determine, based on the detection of SL-RLFs and / or Uu RLFs, or based on the receipt of RLF notifications from the parent node, whether it should send a notification message to a remote WTRU and / or a child relay, or what type of notification it should send, depending on whether it can find (e.g., (re)select) the same cell that it is currently serving through the parent relay WTRU.

[0109] For example, a relay WTRU can notify (e.g., send a notification) a remote WTRU that has requested to receive an RLF notification, and the notification may be associated with (e.g., the occurrence of an RLF (e.g., in the relay WTRU) and / or the reception (e.g., by the relay WTRU) of an RLF notification from a parent WTRU (e.g., that notification). The relay WTRU may include information associated with (e.g., or dependent on) operating conditions, such as the relay WTRU's RRC operating conditions. Operating conditions may be RRC_IDLE or RRC_INACTIVE conditions. Operating conditions may be RRC_CONNECTED conditions. The relay WTRU may perform different recovery actions depending on the operating conditions. For example, based on the RLF determination and / or RLF notification from the parent relay WTRU, the relay WTRU may send an RLF notification to a remote WTRU (e.g., that requested to receive the notification). A relay WTRU may, for example, determine whether to send / send a first type of RLF notice based at least on whether the relay WTRU is in a first operating condition (e.g., RRC_CONNECTED). As disclosed herein, the determination to send / send a first type of RLF notice may further depend on values ​​associated with channel priority and / or hop count. For example, if the relay WTRU is in a first operating condition and the value is below a threshold, the relay WTRU may send a first type of RLF notice, or if the value is above the threshold (e.g., greater than or equal to the threshold), the relay WTRU may send a second type of RLF notice. In the example, the relay WTRU may send a second type of RLF notice if the relay WTRU is in RRC_IDLE and / or RRC_INACTIVE, or if the relay WTRU has no RRC state (e.g., no Uu traffic of its own). The relay WTRU can initiate recovery procedures (e.g., a re-establishment procedure for RRC_CONNECTED, or a re-selection procedure for RRC_IDLE / RRC_INACTIVE) in addition to sending notifications.A relay WTRU can send a recovery notification to a remote WTRU if recovery (e.g., re-establishment) is successful or unsuccessful, for example, if the relay WTRU is in RRC_CONNECTED. In the example, the relay WTRU may not send a recovery notification to the remote WTRU if the relay WTRU is in RRC_IDLE or RRC_INACTIVE, or if the relay WTRU does not have the configured RRC operating conditions.

[0110] For example, a relay WTRU can determine the type of RLF notice based at least on the QoS of the traffic currently being relayed (e.g., the priority of the associated channel). For example, a relay WTRU can determine the QoS of the current relay traffic (e.g., the priority of the associated channel) based on one or more parameters (e.g., specific parameters) of the channel configuration (e.g., inbound or outbound) (e.g., priority of an RLC). Based on one or more parameters (e.g., a relay WTRU may consist of conditions of parameters that map transmissions to types of notices), a relay WTRU can determine whether to send a first type of notice to a child WTRU or a second type of notice to a child WTRU.

[0111] In the example, a relay WTRU can determine the type of RLF notification to send to a child WTRU based at least on the type of notification received from the parent WTRU and / or other conditions determined in the relay WTRU. For example, a relay WTRU that receives a second type of notification (e.g., a notification to trigger re-establishment and / or re-selection without delay) can send (e.g., always send) the second type of notification to its child WTRU. A relay WTRU that receives a first type of RLF notification can send the first type of RLF notification to its child WTRU and / or can determine whether it should send / send the first type of notification based on the channel configuration conditions (e.g., RLC) described herein associated with its child WTRU(or child WTRU(or child WTRU)), and this determination may include other conditions described herein.

[0112] A relay WTRU can determine the type of RLF notice to send to its child WTRUs based on a combination of hop count and QoS (e.g., associated channel priority). The relay WTRU can receive or determine a hop count representing the number of hops the relay WTRU has traveled away from the network (e.g., gNB, base station, etc.). The relay WTRU can receive or determine a threshold, which may be a threshold number of hops for a given QoS level (for example, one or more of the following may apply: the QoS level may be a priority such as logical channel priority / weight; the number of hops for a given QoS level may be a value; or the QoS level may be determined by parameters associated with the (e.g., RLC) channel configuration of one or more connected children of the relay WTRU). The WTRU may, for example, send a second RLF type if the number of hops for a given QoS level exceeds the threshold. The WTRU may send a first RLF type if the number of hops for a given QoS level does not exceed the threshold.

[0113] A WTRU can transmit and / or forward a request to be notified of an SL RLF and / or recovery. Information from a remote WTRU that may affect behavior based on the RLF (e.g., as described herein) may be processed by the remote WTRU before being transmitted to the relay WTRU. For example, a WTRU (e.g., a remote WTRU or a relay WTRU) can transmit and / or forward a request to be notified of an SL RLF by a parent relay WTRU. For example, a WTRU (e.g., a remote WTRU or a relay WTRU) can transmit a request to be notified of an SL RLF by a parent relay WTRU based on one or more conditions described herein. A WTRU (e.g., a relay WTRU) can forward a request to a parent relay WTRU (e.g., based on receipt from a remote WTRU) and / or combine the request with its own requests based on its own conditions. A request may include an "or" action between a child remote WTRU (e.g., any of the child remote WTRUs) and a relay WTRU that satisfies the conditions described herein (e.g., any of the conditions). If a relay WTRU receives an affirmative request and / or notice from one or more of its remote WTRUs, or if the relay WTRU meets the conditions, the relay WTRU may send an affirmative request and / or notice to its parent relay WTRU. A WTRU (e.g., a relay WTRU or a remote WTRU) may initiate a request (e.g., a new request) and / or notice based on a change in its conditions. Requests and / or notices may be sent when a condition changes from unmet to met (e.g., it acts as a request) or from met to unmet (e.g., it acts as a cancellation). A relay WTRU may maintain the request state of one or more of its remote WTRUs and send notices based on RLF, successful recovery, or failed recovery to remote WTRUs in an affirmative request state (e.g., all remote WTRUs).

[0114] In the example, a WTRU (e.g., a relay or remote WTRU) can request an RLF notification type (e.g., a specific RLF notification type) from a parent relay WTRU. An RLF notification type may include receiving RLF notifications at different times (e.g., RLF detection, RLF recovery, failed RLF recovery, etc.), or may include triggering notifications at different times during RLF detection (e.g., based on the number of consecutive IS and / or OOS notifications from a Uu, and / or consecutive HARQ failures on the SL), and / or an RLF notification indicating whether the parent can re-establish and / or re-select the same or a different cell (e.g., a group) to which it is currently attached (e.g., via a different path).

[0115] A WTRU (e.g., a relay WTRU or remote WTRU) may satisfy the conditions for sending a request (e.g., receiving or not receiving an RLF notice) based on the WTRU's RRC state, the QoS of data in the WTRU (e.g., the priority / weight of logical channels such as channels, e.g., RLC channels), and / or the properties of one or more Uu bearers in the WTRU, the existence of alternative routes to the network, or the number of hops to the network and / or the overall weight (e.g., gNB, base station, etc.).

[0116] A WTRU (e.g., a relay WTRU or a remote WTRU) can satisfy the conditions for sending a request (e.g., receiving or not receiving an RLF notice) based on the WTRU's RRC state. For example, the conditions may be tied to one or more RRC states (e.g., a WTRU in RRC_CONNECTED). A WTRU can send a request if it transitions to RRC_CONNECTED and / or RRC_INACTIVE, and can send a cancellation if it transitions to RRC_IDLE and / or RRC_INACTIVE.

[0117] A WTRU (e.g., a relay WTRU or remote WTRU) can satisfy the conditions for sending a request (e.g., receiving or not receiving an RLF notification) based on the QoS of the data in the WTRU and / or the properties of one or more Uu bearers in the WTRU. For example, a WTRU may be configured with a set of LCH priorities that can trigger a request if a logical channel (LCH) with its priority is configured and / or has data available for transmission.

[0118] A WTRU (e.g., a relay WTRU or remote WTRU) may satisfy the conditions for sending a request (e.g., receiving or not receiving an RLF notice) based on the existence of an alternative route to the network. For example, a WTRU may send a request if it does not have a Uu route (e.g., a different relay route) to the configured network. For example, a WTRU may send a request if it is not configured for dual and / or multi-connectivity.

[0119] A WTRU (e.g., a relay WTRU or a remote WTRU) can satisfy the conditions for sending a request (e.g., receiving or not receiving an RLF notification) based on the number of hops to the gNB and / or the overall weight. For example, a WTRU can send a request if the configured number of hops and / or overall weight of the WTRU is above or below a threshold. For example, a WTRU can send a request if the WTRU has another available route with a number of hops or overall weight above or below a threshold.

[0120] A WTRU can receive notification of a set of remote WTRUs to which RLF notices should be forwarded and / or recovered from the network. A relay WTRU can receive from the network (e.g., via RRC messages, paging messages, and / or similar) a set of remote WTRUs to which RLF notices and / or recoveries can be sent (e.g., a set of WTRU IDs, path IDs, and / or similar). A relay WTRU may consist of an RLF notice message type to be sent to a given relay WTRU.

[0121] A WTRU can determine an action to take upon receiving an RLF notification from its parent relay WTRU. For example, a WTRU (e.g., a remote WTRU or relay WTRU) can determine a set of actions to be taken based on the receipt of an RLF notification. A remote WTRU can determine, based on the receipt of an RLF notification, whether and / or when to trigger a re-establishment procedure (e.g., immediately, after a certain time, or based on the receipt of a subsequent notification) based on one or more of the following: the RRC status of the remote WTRU, whether the remote WTRU is servicing other remote WTRUs as a relay WTRU, the QoS of data transmitted or received by the remote WTRU, the measured CBR, or the type and / or information received in the RLF notification. The QoS of data transmitted or received by the remote WTRU may be represented by parameters of one or more LCHs (e.g., LCH priority). For example, a remote WTRU may trigger a re-establishment if one or more logical channels with a priority above a threshold are configured. A remote WTRU can trigger a re-establishment if the WTRU is configured with at least one LCH indicating that it can trigger a re-establishment. The QoS of data transmitted or received by the remote WTRU may include determining the time (e.g., a timer) to wait for a subsequent notification based on the QoS. The measured CBR may be a condition for whether a re-establishment should be triggered or whether a subsequent notification should be waited for, based on whether the measured CBR is above or below a threshold. Measuring the CBR may include determining the time (e.g., a timer) to wait for a subsequent notification based on the CBR. The type and / or information received in an RLF notification may include the RRC status of that relay WTRU and / or parent relay WTRU (e.g., any parent relay WTRU) configured along its path to the network. The information may include the QoS requirements of that relay WTRU and / or parent relay WTRU (e.g., any parent relay WTRU) configured along its path to the network.The information may include the type of RLF notification received from the parent WTRU (e.g., type 1 or type 2).

[0122] A remote WTRU (e.g., one in RRC_CONNECTED) can determine, based on the receipt of an RLF notification (e.g., at that time), and based on the type of RLF notification received, whether to trigger a re-establishment procedure or delay triggering the re-establishment procedure. If a remote WTRU receives a first type of RLF notification from a relay WTRU (e.g., representing an RRC_CONNECTED relay WTRU), the remote WTRU may delay the start of re-establishment until it receives a recovery or recovery failure procedure from the relay WTRU (e.g., the remote WTRU may wait time to determine whether the affected relay WTRU is able to re-establish the connection). If a remote WTRU receives a second type of RLF notification (e.g., representing an RRC_IDLE and / or RRC_INACTIVE relay WTRU, or a relay WTRU with no RRC state), the remote WTRU may trigger a re-establishment procedure upon receipt of the RLF notification (e.g., without delay) (e.g., immediately). A remote WTRU can start a time (e.g., via a timer) based on the receipt of a first type of notification. If the time (e.g., timer) expires before a recovery notification is received, or if a recovery failure notification is received before the time (e.g., timer) expires, the remote WTRU can trigger a re-establishment. The remote WTRU can determine the value of the time (e.g., timer) based on the operating conditions of the relay WTRU (e.g., RRC operating conditions), the QoS of the data in the remote WTRU, the hop count (e.g., number of hops), or one or more of the overall weight associated with the route from the remote WTRU to the network (e.g., the overall weight (e.g., value) can be based on the number of hops and the logical channel (e.g., a combination of the weight / priority of the highest priority logical channel)).

[0123] A remote WTRU can determine a time (e.g., a timer) to trigger a re-establishment following an RLF notification, based on the QoS of the data it is transmitting (e.g., transmitted by one or more of its remote WTRUs). To determine the QoS of the data transmitted by a remote WTRU, a mechanism (e.g., any mechanism) for determining the QoS (e.g., linked to RLC channel configuration parameters based on the QoS flow configured in the WTRU itself) as described herein may be considered. A WTRU may be configured with a first time (e.g., a timer) associated with a first QoS level, a second time (e.g., a timer) associated with a second QoS level, and so on. Based on the receipt of an RLF notification (e.g., or determination of RLF), the WTRU may start the time (e.g., via a timer). If the time (e.g., a timer) expires without notification from the parent (e.g., receipt of a recovery notification), the WTRU may trigger its re-selection and / or re-establishment procedure. A WTRU may wait for a configured amount of time before initiating its re-establishment procedure, and such a time amount may be QoS-dependent.

[0124] In the example, the remote WTRU can determine the time (e.g., a timer) to trigger a re-establishment based on the RLF notification type received from the relay WTRU. For example, if the remote WTRU receives a first RLF notification type, it may wait for a first time before triggering a re-establishment, and if it receives a second RLF notification type, it may wait for a second time before triggering a re-establishment.

[0125] A combination of the techniques described herein (for example, determining the amount of time a WTRU waits before initiating its own re-establishment based on a combination of QoS, hop count, RLF notification type, etc.) may be used.

[0126] Successful (re)selection and re-establishment of a cell and / or relay may be notified to a remote WTRU. Whether or not cell and / or relay (re)selection is performed may be conditional on one or more aspects of the relay and / or its child WTRUs. A relay WTRU may trigger the cell (re)selection and / or relay (re)selection procedure based on the detection of an RLF or the receipt of an RLF notification from its parent WTRU. Whether or not a relay triggers the procedure may depend on the conditions and / or aspects described herein (e.g., the conditions for sending an RLF notification). For example, whether or not a relay triggers the procedure may depend on one or more of the following conditions: A relay WTRU may trigger cell and / or relay (re)selection if it is in RRC_CONNECTED and / or RRC_INACTIVE, one or more of the remote WTRUs are in RRC_CONNECTED and / or RRC_INACTIVE, or the relay WTRU has received an active request from a remote WTRU.

[0127] Whether a relay is selected may be conditional on the relay being in RRC_CONNECTED. A relay WTRU performing cell and / or relay (re)selection may restrict relay selection to relays in RRC_CONNECTED. A relay WTRU may enable restrictions based on the conditions(s) described herein. For example, conditions may include at least one of the remote WTRUs being in RRC_CONNECTED, depending on QoS and / or bearer configuration with the remote WTRUs, and / or based on a request from the relay WTRU.

[0128] The techniques described herein may be applied to one or more dual connectivity (DC) architectures for multi-connectivity (e.g., those described herein).

[0129] Figure 5 shows an exemplary architecture in which a relay WTRU (for example, a relay WTRU may be a WTRU used as an example) is configured in a data center using a master cell group (MCG) and a secondary cell group (SCG). For example, a relay WTRU can be configured in a DC, and the remote WTRU(s) may be unaware of its configuration. In the example, the remote WTRU may be unaware of the DC configuration and may be configured using a single PDCP entity. The relay WTRU may be configured to relay remote WTRU traffic via the MCG and / or SCG (for example, via a configuration that maps inlet RLC channels to outlet RLC channels on the MCG and / or SCG). In the example, the remote WTRU may be configured using two different PDCP entities, and it can determine which one to use based on the information provided by the relay WTRU. The remote WTRU may use the first PDCP entity (e.g., only the first PDCP entity) until an RLF or related event is triggered in the relay WTRU, after which it may begin using the second PDCP entity.

[0130] Figure 6 shows an exemplary architecture in which a relay WTRU consists of an MCG and an SCG. For example, a DC configuration may be present in a remote WTRU, where two legs (e.g., each of the two legs) can pass through the relay. The remote WTRU may be configured with two different sets of PDCP entities and / or bearers that can be used simultaneously. The relay WTRU can map the inlet RLC channels associated with the first PDCP entity and the inlet RLC channels associated with the second PDCP entity to the MCG and / or SCG (e.g., based on the configuration).

[0131] Relay WTRU notifications of RLFs to a remote WTRU may depend on the type of RLF (e.g., M-RLF or S-RLF). For example, a relay WTRU may send an RLF type notification to a remote WTRU based on the detection of an RLF (e.g., M-RLF for S-RLF or Uu RLF for SL RLF). A relay WTRU may send an RLF type notification to a remote WTRU through different RLF type transmissions (e.g., using different messages or IEs) and / or by providing different information to the remote WTRU within the RLF message. For example, based on an M-RLF, a relay WTRU may send a notification to a remote WTRU that the RLF is an M-RLF. Based on the detection of an S-RLF, a relay WTRU may send a notification to a remote WTRU that the RLF is an S-RLF.

[0132] In the example, whether and / or when a relay WTRU notifies a remote WTRU of an RLF may depend on the type of RLF triggered in the relay WTRU (e.g., M-RLF or S-RLF). For example, if the RLF is an M-RLF (e.g., only an M-RLF), the relay WTRU may notify the remote WTRU of the RLF, but may not send notification of an S-RLF to the remote WTRU, and vice versa.

[0133] Whether a relay WTRU notifies a remote WTRU of an RLF, and / or when it does, may depend on the type of RLF triggered in the relay WTRU (e.g., M-RLF or S-RLF), in addition to the bearer mapping and / or adaptation layer configuration in the relay WTRU (e.g., associated with the SRB for the remote WTRU). This may depend on whether the SL RLC channel carrying the remote WTRU SRB is mapped to an MCG or SCG Uu RLC channel in the relay WTRU. For example, a relay WTRU may notify a remote WTRU of an RLF (e.g., M-RLF or S-RLF) if the RLF corresponds to a cell group to which the SL RLC channel carrying the remote WTRU SRB is mapped (e.g., based on the adaptation layer configuration). A relay WTRU may not notify a RLF if, for example, the RLF occurs on a cell group to which the SL RLC channel carrying the remote WTRU SRB is not mapped (e.g., based on the adaptation layer configuration).

[0134] Whether and when a relay WTRU informs a remote WTRU of the RLF and / or the type of RLF indicated to the remote WTRU may depend on the SRB configuration in the relay WTRU and / or whether the relay WTRU is configured to perform the MCG failure procedure. For example, if the relay WTRU is configured to perform the MCG failure procedure based on the MCG RLF and / or if the relay WTRU is configured using split SRB1 or SRB3, the relay WTRU may send a first notification and / or notification type; if the WTRU is not configured to perform the MCG failure procedure, the relay WTRU may send a second notification type.

[0135] A relay WTRU and / or remote WTRU may interrupt SL transmission and / or reception based on RLF notification transmission and / or reception. For example, a relay WTRU and / or remote WTRU may interrupt one (e.g., or both) of SL transmission and / or reception based on RLF determination (e.g., by the relay WTRU), transmission of an SL RLF notification message (e.g., by the relay WTRU), and / or reception of an RLF notification message (e.g., by the relay WTRU or remote WTRU). For example, a relay WTRU may interrupt SL reception and / or forwarding of relay data in the UL direction based on M-RLF and continue to perform SL transmission and / or forwarding of relay data in the DL direction. For example, a remote WTRU may interrupt SL transmission and / or continue to perform SL reception based on reception of an RLF notification from a relay.

[0136] If a relay WTRU is configured to perform an MCG failure procedure, it may, upon an MCG failure, do one or more of the following: The relay WTRU may send a first RLF type to a remote WTRU. The remote WTRU may, upon receiving the notification, suspend relayed SL transmissions and / or receptions (e.g., all relayed SL transmissions and / or receptions). The relay WTRU may suspend SL transmissions and continue SL receptions (e.g., continue only SL receptions). The relay WTRU may suspend relays associated with its remote WTRU (e.g., SL transmissions and / or receptions) (e.g., all relays). The relay WTRU may suspend SL receptions and continue SL transmissions (e.g., continue only SL transmissions). The relay WTRU may initiate an MCG failure procedure with the network and wait for a response. If the MCG failure procedure time (e.g., procedure timer) expires, the MCG may send a second RLF type and / or notification to the remote WTRU. The relay WTRU may release the PC5 RRC connection based on the transmission of the second notice. If the MCG failure procedure is successful and the relay WTRU receives reconfiguration from the network, the relay WTRU may perform one or more of the following: The relay WTRU may send a notice to the remote WTRU, and the remote WTRU and / or the relay WTRU may resume any interrupted relay SL transmissions and / or receptions (e.g., any interrupted relay SL transmissions and / or receptions) based on the receipt or transmission of the notice. If the relay WTRU receives an embedded reconfiguration message for the remote WTRU, the relay WTRU may forward the message to the relay WTRU over the SL. The remote WTRU and / or the relay WTRU may resume any interrupted relayed SL transmissions and / or receptions (e.g., any interrupted relayed SL transmissions and / or receptions) based on the receipt or transmission of the message. The relay WTRU may not send any message (e.g., any message) and / or notice (e.g., any notice) to the relay WTRU.A relay WTRU may resume interrupted transmissions and / or receptions (e.g., any interrupted relayed SL transmissions and / or receptions) based on the reception of a network reconfiguration or based on some time following the reception of a network reconfiguration (e.g., defined by time).

[0137] If a relay WTRU is configured to perform MCG failure procedures, it may, based on an SCG failure, do one or more of the following: The relay WTRU may send a third RLF type to a remote WTRU. For example, a relay WTRU may not send an RLF notification (e.g., any RLF notification) to a remote WTRU if it is configured to do so based on other factors described herein.

[0138] If a relay WTRU is not configured to perform MCG fault procedures, it may, based on an MCG fault, do one or more of the following: The relay WTRU may transmit a fourth RLF.

[0139] If a relay WTRU is not configured to perform MCG failure procedures, it may, based on an SCG failure, do one or more of the following: The relay WTRU may send a third RLF type to a remote WTRU. For example, a relay WTRU may not send an RLF notification (e.g., any RLF notification) to a remote WTRU if it is configured to do so based on other factors described herein.

[0140] A remote WTRU may have different behaviors based on the reception of different RLF types from a relay WTRU. Depending on the type of RLF the remote WTRU receives, it may perform different actions, or sets of actions. An RLF type may be directly associated with an M-RLF or S-RLF in the relay WTRU. For example, an RLF type may be associated with an event (e.g., any event) in the relay WTRU as described herein.

[0141] One or more of the following events and / or behaviors may be associated with one or more events: Start re-establishment immediately; Start re-establishment after a specific time (e.g., a specific timer) has expired (e.g., resetting the timer following the receipt of another RLF type notification or NW message); Set a time based on the type of notification (e.g., a re-establishment timer or a timer until re-establishment is triggered following an RLF notification); Or modify the transmit parameters on the sidelink. Modifying the transmit parameters on the sidelink may include one or more of the following: Increase and / or decrease the maximum SL channel size and / or the number of channels; Enable or disable SL HARQ and / or SL RLF monitoring; Change the transmit mode (e.g., change from mode 1 to mode 2, or vice versa); Or change the sensing behavior (e.g., change from sensing-based to random selection, or vice versa).

[0142] One or more of the following events and / or behaviors may be associated with one or more events: Interrupt SL transmission for bearers (e.g., all bearers) without immediately initiating re-establishment; Interrupt SL transmission immediately (e.g., for a subset of bearers) without initiating re-establishment; Or determine that a procedure (e.g., re-establishment, re-selection, or any other RRC procedure) can be triggered by one RLF type rather than another RLF type. For example, reception of a first RLF may ensure that the WTRU triggers re-establishment if a second type is received, and reception of a third RLF type may ensure that the WTRU triggers re-establishment if a fourth RLF type is received.

[0143] One or more of the following events and / or behaviors may activate, deactivate, or switch PDCP entities (as described herein) that may be associated with one or more events, or interrupt one set of bearers compared to a different set of bearers.

[0144] A remote WTRU can determine, based on RLF notifications, which Uu bearers should suspend transmissions. For example, a remote WTRU can receive RLF type and / or information via an RLF notification (e.g., M-RLF vs. S-RLF) and, based on the information in the RLF notification, can determine the set of bearers to suspend. For example, a WTRU may consist of a set of bearers associated with a first RLF type and / or notification, and a second set of bearers associated with a second RLF type and / or notification. If a notification is received, the remote WTRU can suspend transmissions for the set of bearers associated with the notification (e.g., a specific notification). If a remote WTRU receives a type and / or notification (e.g., a specific type and / or notification), it can suspend transmissions for bearers (e.g., all transmissions for bearers), or transmissions for bearers associated with a relay via a specific relay.

[0145] A remote WTRU can activate, deactivate, or switch PDCP entities based on the receipt of an RLF notification. In the example, a remote WTRU may consist of two different PDCP entities (e.g., a first PDCP entity and / or a primary PDCP entity, and a second PDCP entity and / or a secondary PDCP entity). Under normal conditions, the remote WTRU can send data to the primary PDCP entity. Based on the receipt of a notification from the remote WTRU (e.g., an RLF notification), the remote WTRU can change to sending data via the second PDCP entity. The remote WTRU may continue to use the second PDCP entity for up to one or more of the following reasons: a notification from the relay WTRU (e.g., a recovery notification or a failure notification); a period of time (e.g., the expiration of a timer started when the first notification was received); or until it receives a notification from the relay WTRU and / or configuration from the network.

[0146] Following one or more of the events described herein, a remote WTRU may perform one or more of the following actions: trigger a re-selection and / or re-establishment or switch to use the first and / or primary PDCP entity. The behavior (e.g., the specific behavior described herein) may depend on the nature and / or type of the event.

[0147] A remote WTRU can switch from the primary PDCP entity to the secondary PDCP entity based on receiving an RLF notification from the relay WTRU. The remote WTRU can initiate a recovery time (e.g., via a recovery timer). Based on receiving a recovery failure notification and / or the expiration of the time (e.g., a timer), the remote WTRU can trigger a re-establishment procedure. Alternatively, based on receiving a recovery notification from the relay WTRU, the remote WTRU can switch back to using the primary PDCP entity.

[0148] Whether and / or when a PDCP entity switchover is permitted may depend on the RLF type and / or notification (e.g., M-RLF vs. S-RLF) from the current PDCP entity used by the relay WTRU and / or remote WTRU. For example, a remote WTRU may switch from the primary PDCP entity to the secondary PDCP entity if an M-RLF is indicated by the relay WTRU, but may not perform the switch if an S-RLF is indicated. For example, a remote WTRU may switch from the first entity to the second entity for one type of RLF, but not for another type of RLF. The remote WTRU may be using the secondary PDCP entity. If an S-RLF is received from the relay WTRU, the remote WTRU may switch to the primary PDCP entity. In the example, the remote WTRU may be using the primary PDCP entity. If an M-RLF is received from the relay WTRU, the remote WTRU may interrupt bearer transmissions and / or receptions (e.g., all bearer transmissions and / or receptions) and may not switch the PDCP entity.

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

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

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

Claims

1. A first WTRU related to a second wireless transmit / receive unit (WTRU), wherein the first WTRU is The processor comprises, Receiving threshold notifications and The number of hops from the first WTRU to the network is determined, A first WTRU is configured to transmit a radio link failure (RLF) notification to the second WTRU, wherein the type of the RLF notification is determined based on the threshold and value, where the value is based on one or more of the logical channel weight or the number of hops from the first WTRU to the network, and the type of the RLF notification is either a first type RLF notification or a second type RLF notification.

2. The first WTRU according to claim 1, wherein the type of the RLF notification is determined to be the first type of RLF notification if the value is greater than the threshold.

3. The first WTRU according to claim 1, wherein a first type of RLF notification indicates that the side link (SL) associated with the first WTRU remains connected.

4. The first WTRU according to claim 1, wherein the type of RLF notification is determined to be the second type of RLF notification if the value is less than the threshold.

5. The first WTRU according to claim 1, wherein the second type of RLF notification indicates that a reselection is to be performed.

6. The first WTRU according to claim 1, wherein the second type of RLF notification indicates disconnection from the SL associated with the first WTRU, and the second type of RLF notification indicates connection to the SL associated with the third WTRU.

7. The first WTRU according to claim 1, wherein the type of the RLF notification is associated with a first operating condition and is further determined based on the first WTRU not having received an RLF notification of the second type from the parent relay WTRU.

8. The first WTRU according to claim 1, wherein the processor is further configured to determine the WTRU RLF.

9. The first WTRU according to claim 1, wherein the first WTRU includes a relay WTRU and the second WTRU includes a remote WTRU.

10. The first WTRU according to claim 1, wherein the value is based on the logical channel weight and the number of hops from the first WTRU to the network.

11. A method for a first wireless transmitter / receiver (WTRU) relating to a second wireless transmitter / receiver (WTRU), wherein the method is Receiving threshold notifications and The number of hops from the first WTRU to the network is determined, A method comprising transmitting a radio link failure (RLF) notice to the second WTRU, wherein the type of the RLF notice is determined based on the threshold and value, wherein the value is based on one or more of the logical channel weight or the number of hops from the first WTRU to the network, and the type of the RLF notice is either a first type RLF notice or a second type RLF notice.

12. The method according to claim 11, wherein if the value is smaller than the threshold, the type of the RLF notification is determined to be the second type of RLF notification, and the second type of RLF notification is notified to perform a reselection.

13. The method according to claim 11, wherein the second type of RLF notification indicates disconnection from the SL associated with the first WTRU, and the second type of RLF notification indicates connection to the SL associated with the third WTRU.

14. The method according to claim 11, further comprising determining that an RLF has occurred.

15. The method according to claim 11, wherein the first WTRU includes a relay WTRU and the second WTRU includes a remote WTRU.

Images