Method and apparatus for radio link failure and recovery in multi-path sidelink relay.

Abstract

The present disclosure relates to methods and apparatus for radio link failure, radio link monitoring, and / or radio link recovery in multipath wireless communications. For example, a method implemented by a first WTRU includes receiving configuration information indicating first and second radio link configurations and first and second thresholds, where the first threshold is greater than the second threshold, determining that uplink data is pending for a first transmission to a network entity via a second WTRU, the first transmission associated with the first communications link, determining channel conditions for a second transmission from the network entity, the second transmission associated with the second communications link, and performing a first radio link procedure using the first radio link configuration based on the measured channel conditions being greater than the second threshold and less than the first threshold.

Description

Technical Field

[0001] (Cross - Reference to Related Applications) This application claims the priority and benefit of U.S. Provisional Patent Application No. 63 / 394,783, filed with the United States Patent and Trademark Office on August 3, 2022, and U.S. Provisional Patent Application No. 63 / 421,856, filed with the United States Patent and Trademark Office on November 2, 2022, and the entire contents of each of them are incorporated herein by reference as if fully set forth below in their entirety and for all applicable purposes.

[0002] (Field of the Invention) This disclosure relates to wireless communication. For example, one or more embodiments disclosed herein relate to methods and apparatuses for wireless link failure, wireless link monitoring, and / or wireless link recovery in a wireless transmit / receive unit having dual connectivity to a network via a direct network connection (e.g., a direct connection to a network entity) and / or a connection to the network through a relay wireless transmit / receive unit.

Summary of the Invention

[0003] One or more embodiments disclosed herein relate to methods and apparatuses for wireless link failure (RLF) and recovery in multi - path wireless communication.

[0004] In one embodiment, a method implemented by a WTRU for wireless communication includes: 1) receiving configuration information indicating a first radio link configuration and a second radio link configuration, and 2) a first threshold and a second threshold, wherein the first threshold is greater than the second threshold; determining that uplink data is pending for a first transmission to a network entity via a second WTRU, which is associated with a first communication link; determining the channel state of a second transmission from the network entity, which is associated with a second communication link; and performing a first radio link procedure using the first radio link configuration based on the channel state measurement being greater than the second threshold and less than the first threshold.

[0005] In one embodiment, a WTRU for wireless communication, comprising a circuit including a transmitter, receiver, processor, and memory, is configured to receive configuration information indicating 1) a first radio link configuration and a second radio link configuration, and 2) a first threshold and a second threshold, wherein the first threshold is greater than the second threshold; to determine that uplink data is pending for a first transmission to a network entity via a second WTRU, which is associated with the first communication link; to determine the channel state of a second transmission from the network entity, which is associated with the second communication link; and to perform a first radio link procedure using the first radio link configuration based on whether the measured channel state is greater than the second threshold and less than the first threshold. [Brief explanation of the drawing]

[0006] A more detailed understanding can be obtained from the following detailed description, provided in conjunction with the drawings attached to this specification. The figures in such drawings, as well as the detailed description, are illustrative. Therefore, the figures and detailed description should not be considered limiting, and other equally effective embodiments are possible and likely. Furthermore, similar reference numerals ("ref") within the figures ("FIG") indicate similar elements. [Figure 1A] This is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] This is a system diagram illustrating an exemplary wireless transmit / receive unit (WTRU) that may be used in a communication system illustrated in Figure 1A, according to one embodiment. [Figure 1C] This is a system diagram showing exemplary radio access networks (RAN) and exemplary core networks (CN) that may be used in the communication system shown in Figure 1A, according to one or more embodiments. [Figure 1D] This is a system diagram showing further exemplary RANs and further exemplary CNs that may be used in the communication system shown in Figure 1A, according to one or more embodiments. [Figure 2] This figure shows the protocol view of a split bearer in dual connectivity. [Figure 3] This figure shows the RLC configuration in a dual connectivity setup. [Figure 4] This diagram shows the user plane protocol stack of the L2 U2N relay architecture. [Figure 5] This diagram shows the protocol stack of the control plane in an L2 U2N relay architecture. [Figure 6] This figure shows a multi-path model at the protocol stack level for WTRU in dual connectivity where both connection paths lead to the same cell. [Figure 7]This figure shows a multi-path model at the protocol stack level for WTRU in dual connectivity where two connection paths pass through different cells. [Figure 8] This flowchart shows RLM / RLF processing for dual connectivity WTRU according to one or more embodiments. [Figure 9] This flowchart shows the wireless link re-establishment for a dual connectivity WTRU according to one or more embodiments. [Figure 10A] This figure shows an exemplary multipath wireless communication using one or more embodiments. [Figure 10B] This flowchart shows an exemplary procedure for RLM and / or RLF detection in multipath communication according to one or more embodiments. [Modes for carrying out the invention]

[0007] Introduction The following detailed description includes numerous specific details to provide a complete understanding of the embodiments and / or examples disclosed herein. However, it will be understood that such embodiments and examples may be practiced without some or all of the specific details described herein. In other examples, well-known methods, procedures, components and circuits are not described in detail so as not to obscure the following description. Furthermore, embodiments and examples not specifically described herein may be practiced in place of, or in combination with, those embodiments and other examples explicitly, implicitly, and / or essentially (collectively "provided") described, disclosed or otherwise provided herein.

[0008] While various embodiments are described and / or claimed herein, including apparatus, systems, devices, etc. and / or any elements thereof, that perform operations, processes, algorithms, functions, etc. and / or any parts thereof, it should be understood that any embodiment described and / or claimed herein assumes that any apparatus, systems, devices, etc. and / or any elements thereof are configured to perform any operation, process, algorithm, function, etc. and / or any part thereof.

[0009] Examples of communication systems The methods, apparatus, and systems provided herein are well suited to communications, including both wired and wireless networks. Wired networks are well known. Outlines of various types of wireless devices and infrastructure are provided with respect to Figures 1A to 1D, and various elements of a network may be utilized, implemented, deployed, and / or adapted and / or configured for them in accordance with the methods, apparatus, and systems provided herein.

[0010] 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 employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word DFT-Spread OFDM (ZT UW DTS-s OFDM), unique-word OFDM (UW-OFDM), resource block filtering OFDM, and filter bank multicarrier (FBMC).

[0011] As shown in Figure 1A, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, and 102d, RAN 104 / 113, CN 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, but it will be understood that the disclosed embodiments intend any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRU102a, 102b, 102c, 102d, any of which may be referred to as “station” and / or “STA”, may be configured to transmit and / or receive radio signals and may include user equipment (UE), mobile stations, fixed subscriber units or mobile subscriber units, subscriber-based units, pagers, mobile phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, radio sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other 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 radio devices operating in industrial and / or automated processing chain contexts), consumer electronics devices, devices operating on commercial radio networks and / or industrial radio networks, etc. WTRU102a, 102b, 102c, and 102d can all be referred to as UE for compatibility purposes.

[0012] 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 base transceiver stations (BTS), node B, enode B, home node B, home enode B, gNB, NR node B, 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.

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

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

[0015] More specifically, as described above, the communication system 100 can be a multiple access system and can adopt one or more channel access methods such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a of RAN104 / 113 and WTRU102a, 102b, 102c can establish the air interface 116 using wideband CDMA (WCDMA), and can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA). WCDMA can include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed Downlink Packet Access (HSDPA) and / or High-Speed Uplink Packet Access (HSUPA).

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

[0017] In one embodiment, the base station 114a and WTRU102a, 102b, 102c can implement radio technologies such as NR radio access, and this technology can establish the air interface 116 using New Radio (NR).

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

[0019] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 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, Interim Standard 2000 (IS-2000), IS-95, IS-856, Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0020] 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, for example), 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.

[0021] RAN104 / 113 may 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 implement 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 or different RAT as RAN104 / 113. For example, in addition to being connected to RAN104 / 113 which can utilize NR radio technology, CN106 / 115 may also communicate with another RAN (not shown) by employing GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0022] CN106 / 115 may also function as a gateway for WTRU102a, 102b, 102c, 102d to access PSTN108, the Internet 110, and / or other networks 112. PSTN108 may include a circuit-switched telephone network providing 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 common communication protocols such as the transmission control protocol (TCP), the user datagram protocol (UDP), and / or the Internet protocol (IP) of the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may employ the same RAT as RAN104 / 113 or a different RAT.

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

[0024] 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, non-removable memory 130, removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be understood that the WTRU 102 may include any partial combination of the aforementioned elements while maintaining consistency with one embodiment.

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

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

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

[0028] The transceiver 120 may be configured to modulate the signal transmitted by the transmit / receive element 122 and demodulate the signal received by the transmit / receive element 122. As described above, the WTRU 102 may have multimode capabilities. 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.

[0029] The processor 118 of the WTRU102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit) and may receive user input from these. The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. 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 that memory.

[0030] The processor 118 may be configured to receive power from the power supply 134 and 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.

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

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

[0033] WTRU102 may include a full-duplex radio where the transmission and reception of some or all of the signals (e.g., associated with specific subframes for both uplink (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 139 for reducing and / or substantially eliminating self-interference via either hardware (e.g., chokes) or signal processing via a processor (e.g., via a separate processor (not shown) or processor 118). In one embodiment, WTRU102 may include a half-duplex radio for the transmission and reception of some or all of the signals (e.g., associated with specific subframes for either uplink (e.g., transmission) or downlink (e.g., reception)).

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

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

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

[0037] 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 depicted as part of CN106, it should be understood that any of these elements may be owned and / or operated by a legal entity other than the CN operator.

[0038] The MME162 can be connected to each of the e-nodes B162a, 162b, and 162c in RAN104 via the S1 interface and can function as a control node. For example, the MME162 may perform roles such as authenticating users of WTRU102a, 102b, and 102c, activating / deactivating bearers, and selecting a specific serving gateway 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.

[0039] The SGW164 can be connected to each of the e-nodes B160a, 160b, and 160c in RAN104 via the S1 interface. The SGW164 can generally route and forward user data packets to and from WTRU102a, 102b, and 102c. The SGW164 can perform other functions, such as anchoring the user plane during e-node 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.

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

[0041] 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 functions as an interface between CN106 and PSTN108. In addition, CN106 may provide WTRU102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0042] 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 with a communication network (for example, temporarily or permanently).

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

[0044] A WLAN in Infrastructure Basic Service Set (BSS) mode may have access points (APs) of the BSS and one or more stations (STAs) associated with the APs. APs may have access to or interfaces with a Distribution System (DS) or another type of wired / wireless network that carries traffic within and / or outside the BSS. Traffic originating outside the BSS and destined for an STA may reach and be delivered to the STA via an AP. Traffic originating from an STA for a destination outside the BSS may be sent to the AP to be delivered to its respective destination. Traffic between STAs within the BSS may be sent, for example, via an AP, where a source STA may send traffic to an AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between a source STA and a destination STA (for example, directly between them) using 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 one another. The IBSS mode of communication may be referred to herein as “ad hoc” communication mode.

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

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

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

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

[0049] 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 an 802.11ah embodiment, 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 the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. For example, if the primary channel is busy due to an STA (which only supports 1MHz operating mode) transmitting to the AP, the entire available frequency band may be considered busy, even though a large portion of the frequency band remains idle and could potentially be available.

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

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

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

[0053] WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using transmissions associated with scalable neurology. 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).

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

[0055] Each of the gNB180a, 180b, and 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling on uplink (UL) and / or downlink (DL), support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data toward user plane functions (UPF) 184a and 184b, routing of control plane information toward access and mobility management functions (AMF) 182a and 182b, and the like. As shown in Figure 1D, the gNB180a, 180b, and 180c may communicate with each other via the Xn interface.

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

[0057] AMF182a and 182b can be connected to one or more gNB180a, 180b, and 180c in RAN113 via the N2 interface and can function as control nodes. For example, AMF182a and 182b may be responsible for user authentication of 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 can be used by AMF182a and 182b to customize CN support for WTRU102a, 102b, and 102c based on the type of service utilizing WTRU102a, 102b, and 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, and services for machine type communication (MTC) access. AMFa82a,182b may provide control plane functionality for switching between RAN113 and other RANs (not shown) using other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

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

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

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

[0061] In view of Figures 1A to 1D and their corresponding descriptions, one or more of the functions described herein with respect to one or more of the WTRU102a to d, base stations 114a to b, e-nodes 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 implemented 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.

[0062] Emulation devices may be designed to implement one or more tests of other devices in a laboratory and / or carrier 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 perform tests using terrestrial wireless communications.

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

[0064] Dual connectivity Split Bearer in Dual Connectivity In dual connectivity (DC), a WTRU is serviced by two nodes, each having a set of cells known as a Master Cell Group (MCG) and a Secondary Cell Group (SCG). A bearer may be associated with only an MCG or an SCG, or it may be configured as a split bearer. Figure 2 shows a split bearer protocol diagram, where gNB 1 is in the MCG and gNB 2 is in the SCG.

[0065] Like any bearer, a WTRU has one associated Packet Data Convergence Protocol (PDCP) entity, and the network-side peer PDCP entity is terminated in one of the gNBs (either master or secondary). Downlink (DL), the Core Network (CN) sends data to the gNB to which the PDCP terminates (gNB1 in Figure 2 above), and it is up to the network whether to send the data directly to the WTRU via the link between that gNB and the WTRU, or to forward the PDCP PDU to gNB2 (e.g., via the Xn interface), and gNB2 sends the data to the WTRU via the link between itself and the WTRU.

[0066] In an uplink (UL), the WTRU is configured with the path to the MCG as the primary path and the path to the SGC as the secondary path. A threshold known as the UL split buffer threshold is also configured. If the UL buffer size of its bearer is less than this threshold, the PDCP pushes data only to the Radio Link Control (RLC) associated with the primary path. However, if the buffer size is greater than the threshold, the WTRU can push data to either path (i.e., it is left to the WTRU implementation).

[0067] Packet duplication Data replication is a technique for ultra-reliable low-latency communication (URLLC) in fifth-generation cellular systems. It involves the use of multiple radio links, each delivering the same data between the terminal and the network, to enhance transmission reliability.

[0068] When replication is configured for a radio bearer by RLC, as shown in Figure 3, at least one secondary RLC entity is added to the radio bearer to process the replicated PDCP packet data units (PDCP Packet Data Units, PDUs). The logical channel (LCH) corresponding to the primary RLC entity is called the primary logical channel, and the logical channel corresponding to the secondary RLC entity is called the secondary logical channel. All RLC entities involved in replication have the same RLC mode. Therefore, replication in PDCP involves sending the same PDCP PDU multiple times, i.e., once to each activated RLC entity of the radio bearer. The PDCP control PDU is not replicated and is always sent to the primary RLC entity. Thus, by using multiple independent transmission paths, packet replication increases reliability, reduces latency, and is particularly beneficial for RLC services.

[0069] When configuring a Data Radio Bearer (DRB) replication, Radio Resource Control (RRC) also sets the PDCP replication status (either activated or deactivated) during (re)configuration. After configuration, the PDCP replication status can be dynamically controlled by Media Access Control (MAC) Control Elements (CE), and in DCs, WTRUs apply MAC CE commands regardless of their origin (MCG or SCG).

[0070] When a replica of a Signaling Radio Bearer (SRB) is configured, the state of the PDCP replica is always active and cannot be dynamically controlled. When configuring a replica of a DRB with two or more secondary RLC entities, the RRC also sets the state of each of them (i.e., activated or deactivated). The MAC CE can then dynamically control whether each of the secondary RLC entities configured for the DRB should be activated or deactivated, i.e., which RLC entity should be used for replica transmission. The primary RLC entity cannot be deactivated. When a replica is deactivated for a DRB, all secondary RLC entities associated with that DRB are deactivated. When a secondary RLC entity is deactivated, it is not re-established, the HARQ buffer is not flushed, and the transmitting PDCP entity should instruct the secondary RLC entity to discard all replicated PDCP PDUs.

[0071] When DRB replication is activated, the network should ensure that at least one serving cell is activated for each logical channel associated with the DRB-activated RLC entity, and if SCell deactivation does not leave an activated serving cell for the DRB-logical channel, the network should also ensure that replication is deactivated for the RLC entity associated with the logical channel.

[0072] When a replica is activated, the original PDCP PDU and its corresponding replica shall not be transmitted on the same carrier. The logical channel of a radio bearer configured with replicas may belong to either the same MAC entity (referred to as a CA replica) or a different MAC entity (referred to as a DC replica).

[0073] CA replication can also be configured on one or both MAC entities, along with DC replication, if replication across three or more RLC entities is configured for a radio bearer. CA replication uses logical channel mapping restrictions in MAC entities to ensure that different logical channels of a radio bearer in the MAC entity are not transmitted on the same carrier. When CA replication is configured for an SRB, one of the logical channels associated with the SRB is mapped to a SpCell.

[0074] When CA replication is deactivated for a DRB within a MAC entity (i.e., none of the RLC entities of the DRB within the MAC entity are activated, or only one remains activated), the logical channel mapping restrictions on the DRB's logical channels are removed as long as CA replication remains deactivated for the DRB within the MAC entity.

[0075] When an RLC entity acknowledges the transmission of a PDCP PDU, the PDCP entity shall instruct other RLC entities to discard it. In addition, in the case of CA replication, when an RLC entity limited to SCells only reaches the maximum number of retransmissions for a PDCP PDU, the WTRU shall notify the gNB but shall not trigger a Radio Link Faillure (RLF).

[0076] RLF and recovery in Uu RLF is monitored by the WTRU on the PCell in single connectivity. RLF is triggered when the T310 timer (started following several consecutive out-of-sync instructions from lower layers) expires. When RLF is detected, the WTRU triggers a re-establishment. If the WTRU is configured for a conditional handover (CHO) and the cell selection performed following the RLF results in a CHO candidate, the WTRU performs the CHO on the CHO candidate cell instead of the previous cell.

[0077] For WTRUs in the DC, the WTRU performs Radio Link Monitoring / Radio Link Failure (RLF) on the MCG's PCell and the SCG's PSCell. RLF is declared separately for the MCG and SCG.

[0078] If an RLF is detected for the MCG and fast MCG link recovery is configured, the WTRU triggers fast MCG link recovery. Otherwise, the WTRU initiates the RRC connection re-establishment procedure. During fast MCG link recovery, the WTRU suspends MCG transmission for all radio bearers and uses the SCG leg of split SRB1 or SRB3 to report the failure to the Master Node (MN) via the SCG through an MCG failure information message.

[0079] The WTRU includes available measurement results in the MCG failure information message according to the current measurement configuration of both the MN (i.e., the node associated with the MCG, gNB) and the Secondary Node (SN) (the node associated with the SCG). When fast MCG link recovery is triggered, the WTRU maintains the current measurement configuration from both the MN and SN and, if possible, continues measurements based on the configuration from the MN and SN. If the WTRU does not receive an RRC reconfiguration message, MobilityFromNRCommand message, MobilityFromEUTRACommand message, or RRC release message within a certain period after fast MCG link recovery is initiated, it initiates the RRC connection re-establishment procedure.

[0080] Upon receiving an RRC reconfiguration message, a MobilityFromNRCommand message, or a MobilityFromEUTRACommand message, the WTRU resumes MCG transmission for all radio bearers. Upon receiving an RRC release message, the WTRU releases all radio bearers and configurations.

[0081] If MCG transmissions by radio bearers are not interrupted during an SCG failure, the WTRU will interrupt SCG transmissions for all radio bearers and report SCG failure information to the MN, instead of triggering re-establishment. If an SCG failure is detected while MCG transmissions to all radio bearers are interrupted, the WTRU will initiate the RRC connection re-establishment procedure.

[0082] In all SCG failure cases, the WTRU will maintain the current measurement configuration from both the MN and SN, and will continue measurements based on the configuration from the MN and SN, if possible.

[0083] The WTRU includes available measurement results in the SCG fault information message according to the current measurement configuration for both MN and SN.

[0084] In the embodiments described above and below, re-establishment consists of a procedure in which WTRU 1) performs cell selection and / or sends a re-establishment request RRC message when a cell is selected.

[0085] Relay in wireless communication networks Release 17 of the 3GPP specification defines SL-based UE to network relay. To provide network connectivity to U2N remote WTRUs, sidelink relay is introduced to support the 5G ProSe WTRU-Network Relay (U2N Relay) function. Both L2 and L3 U2N relay architectures are supported. The L3 U2N relay architecture is transparent to the serving RAN of the U2N relay WTRU, except for controlling sidelink resources.

[0086] The U2N relay WTRU is assumed to be in the RRC_CONNECTED state in order to perform unicast data relay.

[0087] In L2 U2N relay operation, the following combinations of RRC states are supported: 1) Both the U2N relay WTRU and the U2N remote WTRU are in an RRC connected state to perform transmission / reception of relayed unicast data; 2) The U2N relay WTRU can be in the RRC_IDLE, RRC_INACTIVE, or RRC_CONNECTED state, as long as all U2N remote WTRUs connected to the U2N relay WTRU are in either the RRC_INACTIVE or RRC_IDLE state. In L2 U2N relay, the U2N remote WTRU can only be configured to use resource allocation mode 2 for relayed data.

[0088] A single unicast link is established between one L2 U2N relay WTRU and one L2 U2N remote WTRU. The traffic of the U2N remote WTRU via a given U2N relay WTRU, and the traffic of the U2N relay WTRU, are separated on different Uu RLC channels on the Uu.

[0089] L2 U2N relay protocol architecture The protocol stacks for the user plane and control plane of the L2 U2N relay architecture are shown in Figures 4 and 5, respectively. The Sidelink Relay Adaptation Protocol (SRAP) sublayer is located on top of the RLC sublayer for both the Control Plane (CP) and User Plane (UP) in both the PC5 interface and the Uu interface. The Uu Service Data Adaptation Protocol (SDAP), PDCP, and RRC are terminated between the L2 U2N remote WTRU and the gNB, while SRAP, RLC, MAC, and PHY (physical) are terminated at each hop (i.e., the link between the L2 U2N remote WTRU and the L2 U2N relay WTRU, and the link between the L2 U2N relay WTRU and the gNB).

[0090] In the case of L2 U2N relay, the SRAP sublayer on the PC5 hop exists solely for bearer mapping purposes. The SRAP sublayer does not exist on the PC5 hop for relaying L2 U2N remote WTRU messages on the Broadcast Control Channel (BCCH) and Paging Control Channel (PCCH). For L2 U2N remote WTRU messages on SRB0, the SRAP sublayer does not exist on the PC5 hop, but it does exist on the Uu hop for both DL and UL.

[0091] In the case of L2 U2N relay, relative to the uplink, The -Uu SRAP sublayer supports UL bearer mapping between the ingress PC5 relay RLC channel and the outgress Uu relay RLC channel for relaying via the L2 U2N relay WTRU Uu interface. For uplink relay traffic, different end-to-end RBs (SRB or DRB) of the same remote WTRU and / or different remote WTRUs can be multiplexed over the same Uu relay RLC channel. - The Uu SRAP sublayer supports L2 U2N remote WTRU identification for UL traffic. The L2 U2N remote WTRU Uu radio bearer identification information and local remote WTRU ID are included in the UL's Uu SRAP header so that the gNB correlates incoming packets to a specific PDCP entity associated with the correct Uu radio bearer of the remote WTRU. - The PC5 SRAP sublayer in L2 U2N remote WTRUs supports UL bearer mapping between the remote WTRU Uu radio bearer and the exit PC5 relay RLC channel.

[0092] In the case of L2 U2N relay, for the downlink, The Uu SRAP sublayer supports DL bearer mapping in the gNB to map end-to-end radio bearers (SRBs, DRBs) of remote WTRUs to Uu relay RLC channels via the relay WTRU Uu interface. The Uu SRAP sublayer supports DL bearer mapping and data multiplexing between multiple end-to-end radio bearers (SRBs or DRBs) of L2 U2N remote WTRUs and / or different L2 U2N remote WTRUs and a single Uu relay RLC channel via the relay WTRU Uu interface. - The Uu SRAP sublayer supports remote WTRU identification for DL ​​traffic. The identification information of the remote WTRU Uu radio bearer and the local remote WTRU ID are included in the Uu SRAP header by the gNB in ​​DL so that the relay WTRU can map packets received from the remote WTRU Uu radio bearer to its associated PC5 relay RLC channel. - The PC5 SRAP sublayer in the relay WTRU supports DL bearer mapping between the ingress Uu relay RLC channel and the outgress PC5 relay RLC channel. - The PC5 SRAP sublayer in the remote WTRU correlates the received packet to a specific PDCP entity associated with the appropriate Uu radio bearer in the remote WTRU, based on the identification information contained in the Uu SRAP header. The local remote WTRU ID is included in both the PC5 SRAP header and the Uu SRAP header. The L2 U2N relay WTRU is configured by the gNB using the local remote WTRU ID used in the SRAP header. The remote WTRU obtains the local remote ID from the gNB via Uu RRC messages, including RRCSetup, RRCReconfiguration, RRCResume, and RRCReestablishment. Uu DRBs and Uu SRBs are mapped to different PC5 relay RLC channels and Uu relay RLC channels at both PC5 hops and Uu hops.

[0093] It is the gNB's responsibility to avoid conflicts in the use of local remote WTRU IDs. The gNB can update local remote WTRU IDs by sending the updated local remote ID to the relay WTRU via the RRCReconfiguration message. A serving gNB can perform local remote WTRU ID updates independently of the PC5 unicast link L2 ID update procedure.

[0094] Scheduling in Sidelink The sidelink supports two scheduling modes – Mode 1 and Mode 2. For WTRUs within coverage, the gNB can control whether the WTRU transmits using Mode 1 or Mode 2.

[0095] In Mode 1 scheduling, which can be used for sidelink WTRUs in the RRC_CONNECTED state, the WTRU receives SL authorization directly from the network in Downlink Control Information (DCI). In this case, the WTRU reports the buffer status for SL data grouped by destination index (the destination index corresponds to a unique L2 destination ID or a source / destination L2 ID pair). If SL authorization is not available for sending pending data, the WTRU can send a Scheduling Request (SR).

[0096] In Mode 2 scheduling, which can be used by WTRUs in any RRC state, or when a WTRU is outside coverage, the WTRU consists of a resource pool that performs autonomous resource selection and scheduling. Resources are selected by the WTRU based on information (i.e., sensing results) from previous Sidelink Control Information (SCI) transmissions by other WTRUs.

[0097] Multipath operation Release 17 of the 3GPP specification introduces Layer 2 WTRUs for network forwarding. The primary use case considered is that of remote WTRUs located outside of coverage. However, Release 18 is planned to specify multipathing. In multipathing, remote WTRUs are assumed to be within coverage and can therefore utilize either Uu paths, SL (forwarding) paths, or both. A description of multipathing operation for Release 18 is as follows [2].

[0098] In the following scenarios [RAN2, RAN3], we will examine the benefits and potential solutions for multi-path support (e.g., by switching between multiple paths or using multiple paths simultaneously) to improve reliability and throughput. A.WTRUs are connected to the same gNB either 1) via a Layer 2 WTRU-to-Network relay, or 2) via another WTRU (assuming WTRU-WTRU interconnects are ideal) using one direct and one indirect path, and the solution for 1) will be reused for 2) without ruling out the possibility of excluding parts of the solution that are unnecessary for operation for 2).

[0099] In multi-path operation, the direct link between the remote WTRU and the gNB, as well as the backhaul link between the relay WTRU and the gNB, can be serviced by the same gNB, or even by the same cell of the same gNB. Furthermore, if Mode 1 is selected for scheduling the SL between the remote WTRU and the relay WTRU, scheduling of all links (Uu between the remote WTRU and the gNB, backhaul Uu between the relay WTRU and the gNB, and SL between the remote WTRU and the relay WTRU) is performed by the gNB. Even when Mode 2 is used and the resource pool is pre-configured by the gNB for SLs that the remote WTRU can use autonomously, the gNB still determines the resource pool configuration and therefore has control over scheduling on the SLs (though not as real-time as in Mode 1).

[0100] Since different MAC entities are used for Uu links and SLs, and the same PDCP entity is configured for a given bearer using multiple routes (e.g., a split bearer), multiple routes can be modeled similarly to DCs from a protocol architecture perspective. However, if the same gNB serves cells for Uu and SL, this can be considered similar to the case of CA (Carrier Aggregation). However, in a CA, one MAC entity is utilized, which is not actually the case shown here. To complicate matters further, Uu and SL can be served by the same cell of a given gNB (i.e., not even a CA).

[0101] Figures 6 and 7 illustrate examples of how multiple routes can be modeled at the protocol level. Figure 6 shows multiple routes to the same cell, and Figure 7 shows an example of multiple routes to two different cells.

[0102] RLF failure and recovery in multi-pathway sidelinks Multipathing can include the same scheduler controlling the Uu and SL routes of a remote WTRU. As a result, bearers (including SRBs) can be configured to use either route. Unlike DC, multipathing does not have a master node concept, and both routes terminate at the same node in the network. Consequently, it becomes unnecessary for the remote WTRU to monitor the radio links of both paths simultaneously, which can lead to unnecessary power consumption. The links on which the WTRU should monitor RLF should also be synchronized with the links that the network can use to transmit RRC signaling. However, the RLM / RLF mechanism to be used may depend on whether multipathing is used to ensure reliability (i.e., both routes are important) or to maintain coverage (i.e., the ability to maintain connectivity through only a single route is required). In the case of multiple paths where one path goes through an SL relay, RLFs are detected based on HARQ feedback instead of the usual RLM. This mechanism for RLF detection can be unreliable, especially when the amount of data transmitted through the SL path is limited.

[0103] Finally, the recovery behavior for multiple paths may depend on the factors mentioned above, and if a master node is not present, it needs to be defined differently for multiple paths than for DCs.

[0104] Multipath communication In the embodiments described herein, a remote WTRU in a multi-path configuration refers to a WTRU connected to the network via two different paths: a direct Uu path and a path to network relay via an SL WTRU. The connections via the two paths may be to the same gNB / scheduler (i.e., the remote WTRU and relay WTRU are under the control of the same gNB) or to different gNBs / schedulers (i.e., the remote WTRU and relay WTRU are under the control of different gNBs). However, the embodiments discussed herein may be equally applicable when a remote WTRU maintains multiple paths (two or more) or two or more paths to network relay WTRUs via an SL WTRU.

[0105] Typical steps for a WTRU to recognize inter-gNB changes performed by a relay WTRU. A method for determining whether cells belong to the same / different gNBs. Embodiments for RLM / RLF described herein may depend on knowledge in the WTRU of whether two cells (e.g., a cell associated with a direct route and a cell associated with an indirect / relay route) belong to the same gNB or to different gNBs. Depending on whether the cells belong to the same gNB or different gNBs, the remote WTRU may perform different procedures described herein. Such information may be determined using one of the following solutions. -List of cells: For example, a network can provide a list of cells associated with a particular cell (e.g., a cell with a direct route). If another cell is in this list of cells, the remote WTRU determines that the cell is part of the same gNB as the particular cell.

[0106] - Broadcast / transmission identification information by cell For example, a cell may transmit identification information (e.g., in a System Information Block (SIB) or by dedicated RRC signaling) that is used to determine whether two different cells are associated with the same gNB. For example, if cells transmit the same identification information, the WTRU may assume that they are part of the same gNB. - Explicitly as part of a procedure initiated by the network (e.g., Handover (HO), Reconfiguration, etc.) ○For example, a remote WTRU may be connected via multiple paths, including a direct link to cell 1 and an indirect link via a relay connected to cell 2. Cells 1 and 2 may belong to the same gNB. The relay WTRU can receive HO commands from the network and notify the remote WTRU of them. Upon receiving an HO command, the remote WTRU may need to determine whether the target cell (cell 3) is part of the same gNB. This can be indicated directly by the network using flags or instructions within the HO command itself. Specifically, this is as follows: ■ A relay WTRU can receive instructions in an HO command that should be forwarded to a remote WTRU in an notification message. Specifically, if an instruction is sent (for example, a flag is set to true), such an HO can represent a gNB HO in the relay WTRU. ■ A relay WTRU can include instructions or flags in notification messages sent to a remote WTRU. ■Remote WTRU is ●When an HO notification is received indicating that the source cell and target cell are associated with different gNBs, the procedure associated with the inter-gNB HO (as described herein) can be performed. ●When an HO notification is received that does not indicate that the source cell and target cell are associated with different gNBs, the procedure associated with the intra-gNB HO (i.e., the indirect and direct pathways are associated with the same gNB) (as described herein) can be performed.

[0107] Typical Procedures for RLM / RLF in Multipath Systems In a multi-path remote WTRU, the RLM / RLF determines which path is monitored. In one solution, a remote WTRU can determine which path to perform RLM / RLF on based on one or more, or any combination of, the following factors. Although not explicitly mentioned in the following examples, similar factors may be used to determine the characteristics of the RLM / RLF to be performed, which may include the configuration used (e.g., whether to use a first set of parameters, timers, constants, etc. related to the RLM / RLF decision, or a second set of parameters) and / or intensity (whether to use a normal RLM or a relaxed RLM) and / or other forms of the RLM / RLF. Furthermore, a remote WTRU can determine whether / how to perform RLM / RLF on one path (e.g., directly or indirectly) based on conditions associated with other paths (indirect or direct), such conditions are described below. When deciding whether / how to perform RLM / RLF and / or whether / how to perform SL RLF, the following combinations of factors may be considered. In some embodiments, the first condition may be used to determine the second condition to be used in the decision. Specifically, the factors may include: - Measuring Uu path quality: For example, WTRU can perform RLM / RLF on a Uu path if the measured RSRP on the Uu path is below a threshold, and can stop performing RLM / RLF on the Uu path if the measured RSRP on the Uu path is above the threshold. This approach is taken because WTRU can assume that RLM / RLF on the Uu path is unnecessary when the Uu link has good path quality, assuming that there is a fallback SL path. ■For example, (1) WTRU can perform RLM / RLF on the Uu path if the RSRP measured on the Uu path is below a first threshold, (2) can perform relaxed RLM / RLF on the Uu path if the RSRP measured on the Uu path is between the first and second thresholds, and (3) does not perform RLM / RLF if the RSRP measured on the Uu path is above the second threshold. ■For example, a WTRU can perform RLM / RLF on a Uu path if the measured RSRP on that Uu path exceeds a threshold, and can only perform RLF on the relayed path if the measured RSRP on the Uu path falls below the threshold. These two thresholds may be the same or different. This approach is taken because, in the case of a large Uu RSRP, the network can send RRC signaling on the Uu path, and the WTRU should monitor RLF based only on the Uu path. - Measuring SL path quality For example, WTRU can perform RLM / RLF on a Uu path if the SL quality (e.g., SL RSRP) is above / below a threshold. ■For example, a combination of Uu quality and SL quality criteria may be considered to determine which links RLF should be run on. For example: ●If both the SL RSRP and the Uu RSRP are above the threshold, the WTRU can perform RLF only on the SL path. If either the SL RSRP or the Uu RSRP is below the threshold, the WTRU can perform RLF on the Uu path, and whether RLF is measured on the SL may depend on other factors discussed herein. The advantage of such a method is that the WTRU can turn off Uu RLM monitoring if it is certain that it has a sufficiently good SL link as a backup. ●If SL RSRP exceeds the first threshold and Uu RSRP exceeds the second threshold, the WTRU can perform RLF on either the SL route or the Uu route (determined by the WTRU or configured by the network). Otherwise, RLF can be performed on both routes. ●If SL RSRP is below the first threshold and Uu RSRP is below the second threshold, the WTRU can perform RLF on both paths. Otherwise, it can perform RLF on one link (determined by the WTRU or configured by the network). -SL-specific measurements such as CBR For example, WTRU can perform RLM / RLF on Uu paths if the SL channel busy ratio (CBR) exceeds a threshold. The advantage of such a method is that Uu RLM is maintained regardless of whether Uu RSRP is good or not, even if congestion exists on the SL. - The existence or amount of UL data being transmitted via SL or Uu routes. This can be measured based on the amount of data routed by the Packet Data Protocol (PDP), the amount of data in the WTRU's SL RLC buffer, or the Channel Occupancy Ratio (CR) measured on the sidelink. For example, a WTRU can perform RLM / RLF on a Uu path if the SL CR exceeds a threshold. The advantage of such a method is that the WTRU can be confident that sufficient data is being transmitted by the WTRU via the SL path to ensure a reliable HARQ-based RLF mechanism for monitoring multipath links. For example, if a WTRU has data for an SL logical channel with HARQ feedback enabled, the WTRU can perform RLM / RLF on the Uu path. -Message received from relay WTRU ○In one embodiment, a remote WTRU can change its RLM / RLF behavior based on receiving a Uu RLF instruction from a relay WTRU. Specifically, if a remote WTRU is not monitoring RLM / RLF on the Uu path at a given time and receives a Uu RLM / RLF instruction from a relay WTRU, the remote WTRU can notify the network via the Uu and then start / resume RLM / RLF on the Uu path. The WTRU can continue to perform RLM / RLF on the Uu path until it is reconfigured with a new relay WTRU or until it receives an instruction (from the network or the relay WTRU) that the Uu link in the relay WTRU has been restored. ○In one embodiment, a remote WTRU can modify its RLM / RLF behavior based on flow control messages received from a relay WTRU. Specifically, the remote WTRU can receive flow control instructions from the relay. If the flow control message indicates that the remote WTRU should reduce the data rate through the relay WTRU, the remote WTRU can perform RLM / RLF via the Uu path. Otherwise, the remote WTRU can perform a relaxed RLM / RLF via the Uu path or not perform RLM / RLF at all. - QoS / bearer configuration in remote WTRU For example, the condition for using an SL route for an RLF may be further specified as the WTRU being configured with at least one SL LCH configured with HARQ feedback. For example, the condition for using an SL pathway for RLF can be further specified as the WTRU being configured using at least one SL RLC channel configured in Acknowledged Mode (AM). For example, a WTRU may be permitted to use the first condition described herein to determine the RLF behavior for some QoS flows / bearers, and the second condition described herein to determine the RLF behavior for some other QoS flows / bearers. For example, some QoS flows / bearers may always require the WTRU to monitor RLM / RLF on the Uu path when established and / or when they have available data. For example, a remote WTRU can perform RLM / RLF on the Uu based on the presence / number of SL LCHs configured with HARQ feedback enabled, and / or the amount of data present for transmission in the buffer for such HARQ-enabled LCHs. For example, a remote WTRU can monitor Uu RLM / RLF if all SL LCHs are configured without HARQ feedback enabled. For example, a remote WTRU can monitor Uu RLM / RLF if the number of SL LCHs configured with HARQ feedback enabled exceeds a threshold. For example, a remote WTRU can monitor Uu RLM / RLF if the amount of data buffered in the WTRU SL LCH with HARQ feedback enabled falls below a threshold. For example, a WTRU can use the above decision on whether to monitor Uu RLM / RLF when the cells associated with direct and indirect links are the same, and / or when the WTRU is configured with a split SRB. For example, a remote WTRU can perform a relaxed RLM / RLF on the Uu when the number of SL LCHs configured with HARQ feedback enabled, and / or the amount of data present for transmission in the buffer for such HARQ-enabled LCHs, exceeds a threshold. Based on such conditions, the WTRU can further determine relaxation parameters associated with the relaxed RLM / RLF (e.g., the percentage of the reference signal to be monitored, the value of the timer / counter associated with the RLM / RLF, etc.). - Whether relay and remote WTRUs are controlled by the same / different cell / scheduler / gNB For example, WTRU may use the first rule or condition described herein for the same cell, and different rules or conditions for multiple cells. For example, WTRU can always perform RLF on both paths in the case of different cells, but other conditions described herein can be used to determine whether to perform RLF on both paths in the case of the same cell. - SRB routing configuration in multiple routes For example, a WTRU may have rules that prioritize RLM / RLF detection on Uu paths if RLM / RLF can be performed on Uu paths, or if SRBs are configured to be transmitted only on Uu paths, or if SRBs are transmitted only on SL paths, it may have rules that prioritize RLF monitoring on SL paths, or if SRBs can be transmitted on both paths, it may have rules that allow for flexible routing based on RSRP (as described herein). - SRB replication configuration in multiple paths For example, if an SRB is configured for replication, the WTRU can perform RLF on both Uu and SL links. - RRC status of relay WTRU For example, a WTRU may have multiple paths, causing the relay WTRU to be in an IDLE / INACTIVE state, in which case all UL / DL data is routed through the Uu. In such a case, the remote WTRU can always monitor RLM / RLF through the Uu. When the relay WTRU is in a CONNECTED state, the remote WTRU can use other rules to determine RLM / RLF monitoring. - Whether the route corresponds to a direct route or an indirect route. For example, a WTRU may use the first rule to determine whether to monitor RLFs on a direct path and the second rule (as specified herein) to determine whether to monitor RLFs on an indirect path. For example, a WTRU can always monitor RLFs on indirect paths and can decide whether to monitor RLFs on direct paths based on other rules in this specification. - Is the indirect route associated with a 3GPP link (e.g., PC5) or a non-3GPP link? ○For example, if the indirect route is associated with a 3GPP link (i.e., PC5), the remote WTRU can perform Uu RLM / RLF (or vice versa, i.e., the remote WTRU will perform SL RLM / RLF). Alternatively, if the indirect route is associated with a non-3GPP link, the remote WTRU does not need to perform Uu RLM / RLF (or vice versa, i.e., the remote WTRU will perform SL RLM / RLF). Alternatively, if the indirect route is associated with a 3GPP link, the remote WTRU can perform relaxed RLM / RLF on the Uu.

[0108] A remote WTRU can initiate an RLM / RLF procedure on one link when other links declare an RLF and / or recovery failure. In one embodiment, a remote WTRU can initiate RLM / RLF on one link when another link declares a failure. Such failures could be an RLF on that link, a failure to re-establish that link, the transmission of a failure RRC message (e.g., an SCGFailure-like message or an MCGFailure-like message), or any failure related to the same conditions used to trigger an RLF (e.g., reaching a certain number of consecutive HARQ DTX on the link). For example, a remote WTRU may be configured to monitor RLFs on both the SL and Uu, but at a given time, it may only monitor SL-based RLFs. If the remote WTRU detects an RLF on the SL, it can initiate RLM / RLF monitoring on the Uu. The remote WTRU may further use such behavior only under the conditions of the specific network architecture and / or bearer architecture in which such behavior is configured. Specifically, such behavior may be useful when a network transmits RRC signaling on one path, and an RLF on that path is expected to cause the path for RRC signaling to switch to another path. For example, a WTRU can initiate an RLF on one path following the detection of an RLF on another path if one or more of the following conditions are met: -Conditions associated with the configuration of one or more bearers (SRB or DRB). For example, this behavior may apply when configured with a split SRB without replication. Specifically, when a split SRB is configured with replication, the WTRU can perform RLM / RLF on both paths. When configured with only an SRB on a single path, the WTRU can perform RLM / RLF only on that path and initiate re-establishment when RLF is triggered. --Conditions associated with the relationship between cells on direct and indirect paths (e.g., the same cell on both paths, the same gNB, or cells belonging to the configured cell list). For example, the behavior can apply when a WTRU is configured with the same cell on both the direct and indirect paths. Specifically, when configured with different cells on different paths, an RLF on one path can initiate an MCG-like failure procedure, where the remote WTRU reports a failure and waits for further network configuration. On the other hand, when configured with the same cell on both paths, it may not be necessary to reconfigure the non-faulty path, and the WTRU can simply initiate failure monitoring on the non-faulty path instead, expecting to receive an RRC message on the non-faulty path. -A condition associated with whether a WTRU-WTRU (indirect) link is an ideal link. For example, the behavior can apply when the indirect link between WTRUs is a non-3GPP link. Specifically, when configured as a PC5 link, the remote WTRU can monitor the RLF on both links, but when configured using a non-3GPP link, the link is assumed to be ideal (and cannot fail), and the remote WTRU can rely on the relay WTRU to monitor the RLM / RLF on the Uu instead. -Conditions related to whether the path that triggered the RLF is a direct or indirect path. For example, this behavior may apply when the RLF is triggered on an indirect path, but not when the RLF is triggered on a direct path. For example, a remote WTRU can always monitor the RLF on the PC5-RRC because it consumes very little additional power for RLM monitoring compared to a Uu. -Conditions associated with the type of SL RLF that can be triggered. Specifically, the behavior may apply only to certain cases of SL failures, such as when an SL RLF is triggered based on a HARQ DTX, when an SL RLF is triggered based only on T400 expiration, or when an SL RLF is triggered based only on the receipt of a Uu RLF instruction from a relay WTRU.

[0109] In the relevant embodiments, the WTRU may be performing a mitigated RLM on one path and initiating a normal RLM / RLF when an RLF (or similar failure event) occurs on the other path.

[0110] The remote WTRU routes data via the SL route based on conditions related to RLM / RLF. In one embodiment, the WTRU may modify routing rules for UL data on split bearers based on the configuration of the SRB and / or other factors that can define its RLF behavior / requirements. Specifically, the WTRU may be required to monitor RLF on the SL based on other rules discussed herein. If the WTRU has such requirements, the WTRU may perform routing through the SL path so that sufficient data for the UL split bearers is transmitted through the SL path. For example, the WTRU may be configured, in some cases, with a percentage of data routed through the SL path per split bearer, and it can be ensured that this percentage is met whenever other conditions (described herein) require the WTRU to monitor RLF on the SL. For example, the WTRU may be configured with different split bearer thresholds (e.g., a value of 0), and the WTRU may apply its split bearer thresholds based on conditions (e.g., Uu and / or SL quality) described herein.

[0111] Figure 8 is a flowchart illustrating the process for performing RLM / RLF in a DC WTRU according to an exemplary embodiment. In step 801, the WTRU determines whether the RSRP exceeds a first threshold. If so, the flow proceeds to step 803, where the WTRU determines whether there is pending data for the transit path. If so, the WTRU performs RLF only on the SL transit path (step 805). On the other hand, if there is no pending data for the SL transit path, the WTRU performs RLM on the SL transit path and mitigated RLM within the Uu path (step 813).

[0112] Returning to step 801, if the Uu RSRP is below the first threshold, the flow proceeds to step 807, where it is determined whether the Uu RSRP is above a second threshold that is lower than the first threshold. If so, the flow proceeds to step 809, where the WTRU determines whether it has pending UL data for the SL relay path. If so, the WTRU performs an RLM on the SL relay path and a mitigated RLM on the Uu path (step 811). Otherwise, the WTRU performs an RLM on both paths (step 813).

[0113] Although not shown in the flowchart, in one embodiment, if the RLF is triggered on only one of the two paths, recovery (e.g., an SGCFailure-like procedure) may be performed on the other of the two links. If the RLF is triggered on both links, a radio link re-establishment is performed.

[0114] Typical steps for recovery via multiple pathways The remote WTRU determines the recovery procedure across multiple paths. When a remote WTRU detects a problem on one or both links (e.g., RLF detection or instruction from a relay WTRU), it can perform one or more of several recovery procedures. The remote WTRU can perform any or several recovery procedures (e.g., sequentially or simultaneously), including: - Perform the re-establishment procedure. - Execute multipath re-establishment type 1 - Execute multi-path re-establishment type 2 - Perform the CHO procedure -Sends a Uu RRC message, such as an MCGFailure or SCGFailure message, which is a fault message similar to an MCGFailure or SCGFailure message. - Follow the instructions provided by MCGFailure. ○For example, send an RRC error message and start the timer. If the timer expires without receiving a network reconfiguration, start a re-establishment message. - Follow the instructions provided by SCGFailure. For example, an RRC error message may be sent, but the timer may not be started. Normal operation can still continue via a working link. For example, a WTRU can send different RRC messages depending on whether it is initiating an SCGFailure-like procedure or an MCGFailure-like procedure. - Execute the relay reselection procedure and, if necessary, provide the reselection results to the network. -Perform a conditional handover (CHO), HO, or CHO-like procedure, and the WTRU performs a conditional handover (CHO), HO, or CHO-like procedure using the configuration provided to it, for example, changing to a route associated with multiple routes. For example, a cell add received by the WTRU can initiate an HO or CHO-like procedure, where the WTRU performs a Pcell change to that cell as a result of any failure during the add procedure, as described herein. - Trigger measurement reports for available / measured relays only, trigger measurement reports for available / measured cells only, or trigger measurement reports for both measured relays and cells. Specifically, the conditions described herein may be used to determine which measurement reports should be submitted. - Release the PC5-RRC connection. Specifically, the PC5-RRC connection can be used to determine whether to maintain or release the PC5-RRC connection. - Release multipath connections / configurations Specifically, the conditions described herein can be used to determine whether to release multi-routing / configuration in a remote WTRU and whether to rely on a single routing connection. - Indicates the cause of the RLF (e.g., a detected SL-RLF or reception of a Uu RLF from a relay WTRU). In particular, the conditions of this specification may be used to determine whether the cause of the detected SL-RLF, Uu RLF reception, triggered HARQ-based SL RLF, triggered RLC-based SL RLF, triggered T400-based, and RRC messages transmitted to the network. - Interrupt one of the routes associated with a multi-routing configuration (i.e., interrupt all transmissions performed for bearers associated with that route).

[0115] The remote WTRU determines the message type / content / SRB type of recovery messages (e.g., RRC messages) across multiple paths. A remote WTRU may, depending on the circumstances, include different content in recovery messages (e.g., MCGFailure-like messages, SCGFailure-like messages) or use different RRC messages entirely via different SRBs (SRB0 or ​​SRB1). For example, a WTRU may include or not include certain parameters in its messages, depending on the conditions of this specification. Specifically, a remote WTRU may include any one or more of the following data in such a fault message: - Carrier frequency associated with the fault path - Measurement of other relay WTRUs - An indication of whether the measurement result is related to Sidelink Discovery Reference Signal Receive Power (SD-RSRP) or Sidelink Reference Signal Receive Power (SL-RSRP), as associated with measurements of other relays. -Indicators that may be related to measurements of other relays, such as whether the measurement results indicate whether the remote WTRU is associated with a relay that has a PC5-RRC connection. - An indication that the measurement result is associated with (or the status of) a relay WTRU in RRC_CONNECTED, which may be related to measurements of other relays. - Fault type, fault indication, or similar information that may indicate any of the following: ○ RLF of the relay WTRU, or the RLF failure type of the relay WTRU (e.g., T310 expiration, randomAccessProblem, etc.) SL RLF detected by remote WTRU ○HO via remote WTRU ○Cell reselection via remote WTRU ○ Failure to establish RRC connection via remote WTRU - An indication that a failure occurred during the processing of an additional / modified procedure (see Re-establishment Type 2 in this specification).

[0116] The set of actions (e.g., procedures) and / or the type / content of messages performed by a remote WTRU may depend on any of the conditions described in the previous section. Specifically, a WTRU may perform one or more sets of actions versus one or another set of actions based on conditions associated with any or a combination of the following factors: -Uu path quality measurement - Measuring SL path quality - SL-specific measurements such as CBR or CR - Messages received from relay WTRUs (i.e., specific messages or instructions being transmitted) - QoS / bearer configuration in remote WTRU - Whether relay and remote WTRUs are controlled by the same / different cell / scheduler / gNB For example, a remote WTRU may be configured using a method for determining whether a second cell is part of the same gNB as the first cell (e.g., a list of cells, a common subset of bits in the cell ID, the same area ID or similar broadcasted by the two cells). - SRB routing configuration in multiple routes - SRB replication configuration in multiple paths - RRC status of relay WTRU - The path that triggered the RLF (Uu / direct or SL / indirect or both) -RLF monitoring behavior (e.g., whether WTRU is monitoring Uu RLF and SL RLF, and whether WTRU is performing mitigated Uu RLF monitoring) -RLF failure type itself - Whether the WTRU-WTRU connection in the indirect path is a 3GPP link (e.g., PC5) or a non-3GPP link (e.g., an ideal link) - Which path failed (directly or indirectly)? - For failed paths, which path corresponds to the WTRU Pcell?

[0117] Typical steps for recovery procedures and message content In an exemplary embodiment, a WTRU that triggers a Uu RLF on its own may decide whether to perform an MCGFailure-like procedure or an SCGFailure-like procedure via the SL path, based on whether the WTRU has been transmitting UL data via the relay path or has data pending for transmission via the relay path. For example, a WTRU may be configured with a threshold amount of data associated with an SL LCH, with HARQ feedback enabled. If the amount of data in the buffers of all SL LCHs with HARQ feedback enabled exceeds the threshold, the WTRU may perform an SCGFailure-like recovery procedure. Otherwise, the WTRU may perform an MCGFailure-like recovery procedure.

[0118] In another exemplary embodiment, a WTRU detecting an SL RLF may decide whether to perform one of the following procedures: an SCGFailure-like procedure, an MCGFailure-like procedure, or a re-establishment procedure, based on the measured Uu RSRP, which may be associated with the last measurement reported to the network or the last measurement performed on the WTRU. For example, if the measured Uu RSRP is above a first threshold, the WTRU may perform an SCGFailure-like procedure. If the measured Uu RSRP is between the first threshold and a second threshold lower than the first threshold, the WTRU may perform an MCGFailure-like procedure. If the Uu RSRP is below the second threshold, the WTRU may perform a re-establishment procedure.

[0119] In another exemplary embodiment, a WTRU that triggers an RLF on an SL path (or receives a Uu RLF instruction from a relay WTRU) may decide whether to perform an SCGFailure-like procedure, an MCGFailure-like procedure, or a re-establishment based on the Uu RLM / RLF monitored by the WTRU at the time of the SL RLF. In particular, if the WTRU is performing a Uu RLM / RLF, the WTRU may perform an MCGFailure-like procedure. If the WTRU is performing a mitigation RLM on the Uu path, the WTRU may perform an MCGFailure-like procedure. If the WTRU is not performing a Uu RLM, the WTRU may perform either an MCGFailure-like procedure or a re-establishment depending on other factors (e.g., Uu RSRP).

[0120] In another exemplary embodiment, a WTRU triggering an RLF on a single link can decide whether to perform an MCGFailure-like procedure or an SCGFailure-like procedure depending on whether the path corresponds to the same cell or a different cell. Specifically, if it is the same cell, the remote WTRU can perform an SCGFailure-like procedure; if it is a different cell, the remote WTRU can perform an MCGFailure-like procedure. In a similar example, the procedure followed may depend on which cell is configured as the serving cell. Specifically, if the RLF occurs on a path associated with a Pcell, the WTRU can perform an MCGFailure-like procedure; if the RLF occurs on a path associated with a cell that is not a Pcell, the WTRU can perform an SCGFailure-like procedure.

[0121] In another exemplary embodiment, a WTRU triggering an RLF on one link can decide whether to perform an MCGFailure-like procedure or an SCGFailure-like procedure depending on whether the indirect path is a PC5 link or a non-3GPP link. Specifically, if the indirect path is a non-3GPP link, the RLF triggered on one link may initiate an MCGFailure-like procedure or may not initiate any fault procedure at all (i.e., the remote WTRU does not send an RRC message to the network). If the indirect path is a PC5, the remote WTRU may initiate an SCGFailure-like procedure when an SL RLF occurs and an MCGFailure-like procedure when a Uu RLF occurs.

[0122] In another exemplary embodiment, a WTRU can determine fault procedure steps based on the SRB configuration while on multiple paths. Specifically, if a WTRU detects an RLF on a link not configured to carry an SRB (for example, if the WTRU is configured with SRB1 on only one path), and an RLF is detected on a link where an SRB is not configured, the remote WTRU can report a fault message to the network, interrupt or release transmissions to or from the bearer on the failed link, and continue operation on the unaffected links. On the other hand, if the remote WTRU is configured with a split SRB and a fault occurs on a link, the remote WTRU can report the fault, interrupt all transmissions, and wait for reconfiguration from the network. If reconfiguration is not received before the timer expires, the remote WTRU can trigger a re-establishment. On the other hand, if an RLF occurs on a link where the SRB is configured as non-split, the remote WTRU can trigger a re-establishment.

[0123] In one exemplary embodiment, the WTRU may include an RLF fault type indication if recovery is performed via the Uu, but may not include an RLF fault type indication if recovery is performed via the SL. For example, the remote WTRU may indicate in an error message on the Uu whether the error was caused by SL RLF detection by the remote WTRU, reception of a Uu RLF indication by the relay WTRU, or reception of another indication message (e.g., a handover (HO) indication from the relay WTRU). Specifically, the remote WTRU may include a fault type representing a fault on the SL path.

[0124] In one exemplary embodiment, the WTRU can determine, based on the link that failed, the type of measurement to be included in the measurement report during a failure (relay only, cell only, or both cell and relay). Specifically, if a Uu RLF is triggered, the WTRU may include only cell measurements in the error message sent via the relay path. If an SL RLF is triggered, the WTRU may include only relay measurements in the error message sent via the Uu path. If the WTRU performs a re-establishment, it may include both cell and relay measurements.

[0125] In an exemplary embodiment, a remote WTRU is in a multi-path and can release the PC5-RRC connection when it receives an HO instruction from a relay WTRU and the HO is performed for a cell belonging to a different gNB. If the relay HO is performed for a cell of the same gNB, the remote WTRU can simply interrupt transmission over the relayed path and / or release the relay path configuration without releasing the PC5-RRC connection.

[0126] In another example, a WTRU can determine the behavior associated with an indirect link (RRC connection) and / or the bearer associated with the indirect link based on the type of failure triggered by a message in the remote WTRU. For example, if a remote WTRU receives a Uu RLF instruction from a relay WTRU, the remote WTRU may release / dismantle the PC5-RRC connection and / or release the multipath configuration. On the other hand, if a remote WTRU receives an HO instruction from a relay WTRU, the remote WTRU may suspend indirect bearer or transmission over the indirect link but maintain the PC5-RRC connection and wait for the network to reconfigure the indirect link. The remote WTRU may also wait for a period of time for the indirect link to be reconfigured, and then, if no reconfiguration of the indirect link is received from the network, it may release the PC5-RRC connection.

[0127] In another example, a WTRU can decide whether to report an RLF / failure on the indirect path to the network based on the link type (PC5 or non-3GPP link). Specifically, if a WTRU detects or is notified of a link failure by a relay WTRU, it can report a failure to the network if the link is a PC5 link. If the link is a non-3GPP link, the remote WTRU may not report an RLF / failure, but instead may simply suspend transmission over the indirect link.

[0128] In another example, a WTRU may decide whether to report an RLF / failure on the indirect route to the network based on the type of failure reported by the relay WTRU and / or the cell ID served by the relay. Specifically, a remote WTRU may receive an alert message with an instruction type (HO, cell reselection, failure to establish RRC connection, Uu RLF, etc.). In some cases, for example, if the establishment of an RRC connection Uu RLF fails, the remote WTRU may report an RLF / failure on the indirect route to the network and then potentially interrupt the multi-route / bearer / transmission as described herein. In other cases, for example, in the case of cell reselection, the remote WTRU may report a failure to the network without taking any other actions related to its transmission and / or configuration. In yet another case, for example, in the case of HO, the remote WTRU may not report a failure to the network and similar actions related to the bearer. Alternatively, whether the remote WTRU triggers a report may depend on whether the cell ID of the relay WTRU is part of the same gNB or a different gNB, which is determined by the remote WTRU through comparison with a list. Regardless of whether a failure is reported, the remote WTRU can still suspend its bearer associated with the indirect link.

[0129] In one exemplary embodiment, a WTRU experiencing RLF on both the Uu link and the SL link can perform a re-establishment procedure.

[0130] Measurements of relays in a multi-path network may be limited to relays connected to the same cell. In one embodiment, the WTRU can filter relay measurements sent to the gNB to limit them to relays served by the same cell / gNB that directly serves the remote WTRU via multiple paths. For example, the WTRU can send measurements along with an error message during a recovery procedure following an SL-RLF, which may include potential relays and their SL-RSRP / SD-RSRP. In this way, a remote WTRU that was on multiple paths at the time of the error can filter the measurements to include only those of relays connected to the same cell / gNB as the remote WTRU. Alternatively, the remote WTRU can prioritize sending measurements of relays connected to the same cell / gNB. Specifically, if the remote WTRU can detect relays that have potentially above-a-threshold SL RSRP / SD RSRP and are connected to the same cell, the WTRU can send only those relay measurements. Otherwise, the WTRU can send measurements of other relays. The advantage of such an embodiment is that it reduces the overhead of sending all relay measurements when multiple paths are limited to cases where the remote WTRU and relay WTRU are controlled by the same cell.

[0131] Whether the WTRU filters relay measurements to include only relays connected to the same gNB may further depend on other factors described herein. For example, during normal operation (e.g., not under RLF conditions), potential relay measurements may be filtered to include only relays connected to the same gNB, as long as the Uu RSRP is above a threshold. Otherwise, the WTRU may include all measurements. The advantage of such an embodiment is that the WTRU can provide measurements of other relays (not necessarily controlled by the same cell) only if there is a possibility of cell changes by the network.

[0132] Figure 9 is a flowchart of an exemplary procedure for performing radio link recovery in a DC WTRU upon RLF detection, according to one specific exemplary embodiment. In step 901, if the RLF is triggered only on the Uu path, the flow proceeds to step 903, where the WTRU determines whether there is pending data on the SL relay path. If so, the WTRU determines whether the RSRP on the other path (in this example, the SL relay path) exceeds a first threshold (step 905). If so, the WTRU performs an SCGFailure-like procedure on the SL relay path (e.g., sending an RRC message and continuing operation on that path) (step 907). Otherwise, the flow proceeds to step 909, where the WTRU determines whether the RSRP on the SL relay path exceeds a second threshold lower than the first threshold. If so, the flow proceeds to step 911, where the WTRU performs an MCGFailure-like procedure on the SL relay path (e.g., sending an RRC message and setting a timer for radio link re-establishment). Otherwise, the flow proceeds to step 913 instead, where the WTRU performs the radio link re-establishment procedure.

[0133] Returning to the top of Figure 9, on the one hand, if RLF is triggered only on the SL relay path (step 915), the flow proceeds from step 915 to step 917, where the WTRU determines whether RLM / RLF is currently being performed on the Uu path. If so, the flow proceeds from step 917 to step 919, where the WTRU determines whether the RSRP on the Uu path is above a first threshold. If so, the flow proceeds from step 919 to step 921, where the WTRU performs an SCGFailure-like procedure on the Uu path. Otherwise, the flow instead proceeds from step 919 to step 923, where the WTRU determines whether the RSRP on the Uu path is above a second threshold that is lower than the first threshold. If so, the flow proceeds from step 923 to step 925, where the WTRU performs an MCGFailure-like procedure on the Uu path. Otherwise, the flow proceeds from step 923 to step 913, where the WTRU performs a radio link re-establishment procedure.

[0134] Returning to the top of Figure 9, if the RLF is triggered for both paths (step 927), the flow proceeds directly to step 913, where the WTRU performs the radio link re-establishment procedure. Although step 927 is shown in Figure 9 as a decision step for illustrative purposes, it should be noted that in practice, since the flowchart assumes that the RLF has been triggered, step 927 can be omitted. Thus, if the two conditions described in steps 901 and 915 are not met, the condition in step 927 is essentially met.

[0135] Typical procedure - MAC CE can switch the primary path and implicitly initiate RLM / RLF. In one embodiment, a remote WTRU can receive a MAC CE that enables or stops RLM / RLF on the link and / or changes the intensity of the RLF (e.g., relaxed RLM vs. normal RLM). In another embodiment, a remote WTRU can receive a MAC CE that changes the applicability of a route for transmitting / receiving SRB1. Specifically, a remote WTRU may be configured with a split SRB, but at a given time, it may transmit / receive the SRB and / or perform RLM / RLF on only one of the routes. Other routes may be configured with the SRB, but SRB transmission / reception may be disabled on those routes. Upon receiving a MAC CE, the remote WTRU can enable / disable SRB reception / transmission on the route. Specifically, if a split SRB is configured, a remote WTRU with an RRC message may transmit the RRC message via a route where only the SRB is enabled.

[0136] In another embodiment, the same MAC CE can enable / disable RLM / RLF and enable / disable / modify SRB transmission / reception on the path.

[0137] Typical procedures for re-establishing multiple pathways A new method for re-establishment may be used by a remote WTRU in a multi-path configuration. Specifically, re-establishment can be triggered by a WTRU in a multi-path configuration because the WTRU is not currently configured to monitor the SRB on one of the two paths (e.g., to conserve power). If the RLF is triggered on the path with the SRB, the WTRU cannot perform an MCGFailure / SCGFailure-like procedure and can usually rely on re-establishment. However, since the other path was used during the multi-path operation, the remote WTRU is likely already functioning and functioning properly on this path (e.g., the remote WTRU is receiving / transmitting data on this path and potentially reporting measurements for this path). Therefore, the full legacy re-establishment procedure may not be necessary.

[0138] Therefore, in one family of embodiments, a remote WTRU can trigger a new RRC procedure, thereby initiating / continuing a connection on one of multiple paths in the event of a failure that would normally lead to a re-establishment procedure. Potential differences between such a new RRC procedure and a conventional re-establishment procedure may include: - The remote WTRU does not trigger cell / relay selection, but instead directly performs the procedure on the cell / relay that was being used in the multipath. - The remote WTRU can release the configuration and (re)use the RRC configuration that is already available in the WTRU, rather than triggering a re-establishment. - A remote WTRU can avoid re-establishing or resetting one or more protocol layers, as in the case of re-establishment (for example, data buffers are not necessarily flushed).

[0139] In one particular embodiment of this type, a remote WTRU can apply the procedure using the RRC configuration for a new route that is already available and applied in the WTRU. Specifically, if the WTRU is operating with multiple routes and performs the procedure on one of two routes, the WTRU can continue to use the configuration associated with the multiple route for each of the protocol layers applicable to that route. This type of embodiment is most similar to a re-establishment that does not require cell / relay selection and does not reset the protocol layer. This procedure is sometimes referred to herein as multi-route re-establishment type 1.

[0140] In another type of embodiment, a remote WTRU may apply a procedure using an RRC configuration received in a message (e.g., route change / route addition) received before the procedure is triggered due to an error. Specifically, the remote WTRU may trigger the procedure as a result of a failure that occurred after the RRC configuration was received. This type of embodiment is most similar to a CHO where the configuration is received via an RRC message and applied when a failure is triggered. This procedure is sometimes referred to herein as multi-route re-establishment type 2.

[0141] The type of RRC message and / or SRB sent / received may depend on whether SRB1 is configured. The re-establishment procedure for multiple routes can be triggered using an RRC message that uses SRB0 or ​​SRB1.

[0142] For example, when a WTRU triggers a Type 1 procedure, whether SRB0 or ​​SRB1 is used for the initial RRC message may depend on whether the path on which the procedure is performed (i.e., the path used to send the message) was previously configured with SRB1. If it is configured with SRB1, the remote WTRU can send the RRC message on SRB1 (e.g., similar to the MCG / SCGFailure message). The remote WTRU can then anticipate a reconfiguration message. Similar to the MCGFailureInformation procedure in legacy systems, the remote WTRU can trigger a re-establishment if the reconfiguration is not received within a certain period of time. If it is not configured with SRB1, the remote WTRU can send the RRC message on SRB0 (e.g., similar to the RRCReestablishmentRequest). The remote WTRU can then wait for a response message (e.g., similar to the re-establishment message). In either case, the remote WTRU can continue sending on the DRB via a non-faulty path and does not need to perform a PHY / MAC / RLC layer reset on either path. Specifically, in the case of SRB0, data transmission can continue to be performed using the previous security key. SRB0 may use the configuration specified for sending / receiving RRC messages. Alternatively, (considering that SRB1 has not been previously configured on this path) transmission may be used on SRB1 messages, using the specified / default configuration for SRB1 instead.

[0143] In the uplink RRC message, the remote WTRU may further indicate the reason for the failure (e.g., the RLF type, or whether it was caused by an SL RLF).

[0144] For example, if a WTRU triggers a Type 2 procedure after receiving an RRC message (but before the message is applied), whether SRB0 or ​​SRB1 is used for the initial RRC message may depend on whether the received message (in the example below, the RRC message that performs route addition) contained configuration for SRB1. If no configuration is provided, the WTRU can use SRB0 or ​​send the RRC message with the default or specified configuration. However, if the received message contains SRB1 configuration, the remote WTRU can use the configuration in the received message to send the uplink RRC message. Furthermore, the WTRU may not expect any response message, for example, if SRB1 is used (i.e., if the message may be similar to a complete message).

[0145] In the uplink RRC message, the remote WTRU may further indicate that the route addition / modification failed and that the remote WTRU applied the configuration provided in the path addition / modification message to perform re-establishment. If there were multiple configurations that could have been provided to the WTRU, the WTRU may further identify a specific configuration.

[0146] In the case of Type 2, data transmission via DRB can be initiated under any of the following conditions: - Immediately after sending the uplink RRC message - Immediately after the RACH procedure (if direct routes are intended to be added) - Immediately after establishing the PC5-RRC connection (if an indirect route is intended to be added) -After receiving the download confirmation message - Depending on whether SRB0 or ​​SRB1 was used (or whether it was part of a configuration associated with Type 2) For example, if SRB0 is used, the WTRU can wait for a response before starting to transmit data. For example, if SRB1 is used, the WTRU may transmit data immediately after or simultaneously with the transmission of the RRC message. The WTRU may not expect any further response messages following the transmission of UL RRC message 1.

[0147] A typical procedure for multi-path re-establishment type 1 can be triggered as a result of RLF on another path 1. In one embodiment, a remote WTRU can perform multi-route re-establishment type 1 via a first route as a result of an RLF detected on a second route, where the first and second routes are routes previously configured for the WTRU during multi-routing.

[0148] A typical procedure for multi-route re-establishment type 2 can be triggered as a result of a failure during route addition / modification. In one embodiment, a remote WTRU may initiate a multi-route re-establishment type 2 procedure as a result of a failure during a route addition / modification procedure. For example: - Failure of indirect route during direct route addition: A remote WTRU can receive a route addition to add a direct route through an indirect route. During the addition, the remote WTRU can receive a notification (e.g., a Uu RLF) from the relay WTRU or trigger an SL RLF. Upon receiving the notification, the remote WTRU can perform a multi-route re-establishment type 2 for the cell associated with the direct route. Specifically, the remote WTRU can send a complete message through the direct route. The remote WTRU can further indicate (e.g., in the complete message) that it performed a multi-route re-establishment type 2 procedure rather than an addition as a result of a failure in the indirect route during the procedure. Specifically, the remote WTRU can include instructions in the complete message. The remote WTRU can then operate using the direct route as a PCell (rather than assuming the PCell is on the indirect route). Specifically, the remote WTRU can use the received configuration, thereby assuming that the bearer associated with the indirect route is suspended and that only the direct route bearer or bearer route will be used until further reconfiguration. - Direct route failure during indirect route addition: Similarly, a remote WTRU can receive a route addition to add an indirect route via a direct route. During the addition, the remote WTRU may trigger a Uu RLF. Upon detecting a Uu RLF, the remote WTRU may perform a Type 2 procedure on the cell associated with the indirect route and indicate this in a complete message. - Direct route failure during indirect route change: A remote WTRU receives a reconfiguration that changes the indirect route (i.e., to a different relay WTRU) and can trigger a Uu RLF during the route change procedure. As a result, the remote WTRU can initiate a Type 2 procedure through the new indirect route.

[0149] Figure 10A provides an example of multipath wireless communication. In this example, the remote WTRU is configured with multiple paths and performs RLM and RLF detection on the Uu depending on 1) the radio state on the Uu and 2) the presence / amount of uplink data transmitted to the network via relay links (relay WTRUs).

[0150] Referring to Figure 10B, an exemplary procedure for RLM and / or RLF detection in multipath communication is provided. In one embodiment, a WTRU for wireless communication (e.g., a multipath remote WTRU) comprising circuitry including a transmitter, receiver, processor, and memory is configured to receive configuration information indicating 1) a first radio link configuration and a second radio link configuration, and 2) a first threshold and a second threshold, wherein the first threshold is greater than the second threshold. The WTRU can determine that uplink data is pending for a first transmission from a network entity via another WTRU (e.g., a relay WTRU) associated with the first communication link. The WTRU can determine the channel state of a second transmission from the network entity associated with the second communication link. Based on the channel state measurement being greater than the second threshold and less than the first threshold, the WTRU can perform a first radio link procedure using the first radio link configuration.

[0151] In one example, the WTRU can perform a radio link failure (RLF) detection procedure on a first communication link based on the channel state measurement being greater than a first threshold. In another example, the WTRU can perform a second radio link procedure using a second radio link configuration based on the channel state measurement being less than a second threshold.

[0152] In various embodiments, the first radio link procedure includes radio link fault (RLF) detection, radio link monitoring (RLM), and / or radio link recovery on the second communication link. The second radio link procedure includes radio link fault (RLF) detection, radio link monitoring (RLM), and / or radio link recovery on the second communication link. Each of the first and second thresholds is for comparing the channel state associated with the second communication link. In some cases, the channel state includes the reference signal receive power (RSRP) of the second transmit. The channel state measurement includes the measured value of the reference signal receive power (RSRP) of the second transmit.

[0153] In some examples, the first communication link may be a sidelink (SL) relay path for communicating with a network entity via a second WTRU, and the second communication link may be a Uu path for communicating with a network entity.

[0154] In some examples, the configuration information indicates a Radio Resource Control (RRC) configuration, and the WTRU can use the RRC configuration for the first or second communication link before detecting an RLF. The WTRU can determine the type of radio link recovery procedure based on the channel status, the type of RLF, and / or the uplink data awaiting transmission.

[0155] conclusion While the features and elements are provided above in specific combinations, those skilled in the art will understand that each feature or element can be used individually or in any combination with other features and elements. This disclosure should not be limited in terms of the specific embodiments described herein, which are intended to be illustrative of various aspects. As will be apparent to those skilled in the art, many modifications and variations may be made without departing from the spirit and scope of the invention. Any elements, actions, or instructions used in the description of this application should not be construed as important or essential to the invention unless they are expressly presented as such. In addition to those enumerated herein, functionally equivalent methods and apparatus within the scope of this disclosure will be apparent to those skilled in the art from the foregoing description. Such modifications and variations are intended to fall within the scope of the appended claims. This disclosure should be limited only by the terms of such claims, along with the full scope of the equivalents to which the appended claims are entitled. It should be understood that this disclosure is not limited to any particular method or system.

[0156] For the sake of brevity, the embodiments described above have considered the terminology and structure of infrared-compatible devices (i.e., infrared radiators and receivers). However, the embodiments considered are not limited to these systems and may also be applicable to other systems using other forms of electromagnetic waves, or non-electromagnetic waves such as acoustic waves.

[0157] It should also be understood that the terms used herein are for the purpose of describing only specific embodiments and are not intended to limit them. Where used herein, the terms “video” or “image” may mean any of a snapshot, a single image, and / or a series of images displayed over time. As another example, where referred herein, the terms “user equipment” and its abbreviation “UE,” the term “remote,” and / or the term “head-mounted display” or its abbreviation “HMD” may mean or include (i) a wireless transmit and / or receive unit (WTRU), (ii) any of several embodiments of a WTRU, (iii) a wireless-enabled and / or wired (e.g., tetherable) device configured to have some or all of the structure and functions of a WTRU, (iii) a wireless-enabled and / or wired device configured to have fewer structure and functions than all of the structure and functions of a WTRU, or (iv) of the same kind. Details of exemplary WTRUs that may represent any WTRU listed herein are provided herein with respect to Figures 1A to 1D. As another example, the various embodiments disclosed above and below in this specification are described as utilizing a head-mounted display. Those skilled in the art will recognize that devices other than head-mounted displays may be used, and that some or all of the disclosure and the various disclosed embodiments can be modified accordingly without excessive experimentation. Examples of such other devices may include drones or other devices configured to stream information for providing an adaptive reality experience.

[0158] In addition, the methods provided herein may be implemented in computer programs, software, or firmware embedded in a computer-readable medium to be executed by a computer or processor. Examples of computer-readable mediums include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor associated with the software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, MME, EPC, AMF, or any host computer.

[0159] Modifications of the methods, apparatus, and systems provided above are possible without departing from the scope of the present invention. Considering the wide variety of applicable embodiments, it should be understood that the embodiments shown are merely examples and should not be construed as limiting the scope of the following claims. For example, embodiments provided herein include a portable device which may include, or be utilized with, any suitable voltage source, such as a battery, that provides any suitable voltage.

[0160] Furthermore, note that in the embodiments described above, other devices including processing platforms, computing systems, controllers, and processors may also be included. These devices may include at least one Central Processing Unit ("CPU") and memory. In accordance with the conventions of those skilled in the art of computer programming, references to operations and symbolic representations of arithmetic or instructions may be performed by various CPUs and memories. Such operations and arithmetic or instructions may be referred to as "executed," "executed by the computer," or "executed by the CPU."

[0161] Those skilled in the art will understand that operations and symbolically represented arithmetic or instructions involve the manipulation of electrical signals by the CPU. The electrical system represents data bits that can cause a resulting transformation or reduction of electrical signals, and maintains these data bits in memory locations of the memory system, thereby reconfiguring or otherwise altering the CPU's operations and other signal processing. The memory locations where the data bits are maintained are physical locations having specific electrical, magnetic, optical, or organic properties that correspond to or represent the data bits. It should be understood that embodiments are not limited to the platforms or CPUs mentioned above, and other platforms and CPUs may support the methods provided.

[0162] Data bits may also be maintained on computer-readable media, including magnetic disks, optical disks, and any other volatile (e.g., random access memory (RAM)) or non-volatile (e.g., read-only memory (ROM)) mass storage systems readable by the CPU. The computer-readable media may include cooperative or interconnected computer-readable media distributed across multiple interconnected processing systems, which may reside exclusively on a processing system or be local or remote to the processing system. It should be understood that embodiments are not limited to the memories mentioned above, and other platforms and memories may support the methods provided.

[0163] In exemplary embodiments, any of the actions, processes, etc., described herein may be implemented as computer-readable instructions stored on a computer-readable medium. These computer-readable instructions may be executed by a processor in a mobile device, a network element, and / or any other computing device.

[0164] There is little distinction between hardware and software implementations of a system configuration. The choice between using hardware and software is generally (though not always, in certain contexts the choice between hardware and software can be significant) a design choice representing a trade-off between cost and efficiency. Various means of implementation (e.g., hardware, software, and / or firmware) may exist in which the processes and / or systems and / or other technologies described herein may be effective, and the preferred means of implementation may vary depending on the context in which the processes and / or systems and / or other technologies are deployed. For example, if the implementer determines that speed and accuracy are paramount, they may primarily choose hardware and / or firmware as the means of implementation. If flexibility is paramount, the implementer may primarily choose a software implementation. Alternatively, the implementer may choose any combination of hardware, software, and / or firmware.

[0165] In the detailed description above, various embodiments of devices and / or processes have been shown through the use of block diagrams, flowcharts, and / or examples. To the extent that such block diagrams, flowcharts, and / or examples include one or more functions and / or operations, it will be understood by those skilled in the art that each function and / or operation within such block diagrams, flowcharts, or examples can be implemented individually and / or collectively by a wide range of hardware, software, firmware, or any actual combination thereof. In one embodiment, some parts of the subject matter described herein may be implemented via application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integrated forms. However, it will be recognized by those skilled in the art that some aspects of the embodiments disclosed herein can be equivalently implemented in an integrated circuit, in whole or in part, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or any actual combination thereof, and that designing circuits and / or writing software and / or firmware code is within the scope of the art in the art in light of this disclosure. In addition, it will be understood by those skilled in the art that the mechanisms of the subject matter described herein can be distributed as various forms of program products, and that the exemplary embodiments of the subject matter described herein are applicable regardless of the particular type of signaling medium used to actually carry out the distribution. Examples of signal transmission media include, but are not limited to, recordable media such as floppy disks, hard disk drives, CDs, DVDs, digital tapes, and computer memory, as well as transmitting media such as digital communication media and / or analog communication media (e.g., optical fiber cables, waveguides, wired communication links, wireless communication links, etc.).

[0166] Those skilled in the art will recognize that it is common in the art to describe devices and / or processes in the manner described herein and then integrate such described devices and / or processes into a data processing system using engineering techniques. That is, at least a portion of the devices and / or processes described herein can be integrated into a data processing system through a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system may generally include one or more of the following: a system unit housing, a video display device, memory such as volatile and non-volatile memory, a processor such as a microprocessor and a digital signal processor, computing entities such as an operating system, a driver, a graphical user interface, and an application program, one or more interaction devices such as a touchpad or a screen, and / or a control system including a feedback loop and control motors (e.g., feedback for sensing position and / or velocity, control motors for moving and / or adjusting components and / or quantities). A typical data processing system can be implemented using any suitable commercially available components, as is typically found in data computing / communication systems and / or network computing / communication systems.

[0167] The subject matter described herein may include different components that are contained within or connected to other different components. Such depicted architectures are merely examples, and it should be understood that in practice, many other architectures can be implemented to achieve the same function. Conceptually, any arrangement of components to achieve the same function is effectively “associated” in such a way that the desired function can be achieved. Therefore, any two components in this specification combined to achieve a particular function can be considered “associated” with each other, regardless of the architecture or intervening components, in such a way that the desired function can be achieved. Similarly, any two such associated components can be considered “operably connected” or “operably coupled” with each other to achieve the desired function, and any two components that can be associated in this way can also be considered “operably coupled” with each other to achieve the desired function. Specific examples of operably coupled components include, but are not limited to, physically matable and / or physically interactive components, and / or wirelessly interactive and / or wirelessly interactive components, and / or logically interactive and / or logically interactive components.

[0168] With regard to the use of substantially any plural and / or singular terms herein, those skilled in the art can convert from plural to singular and / or singular to plural as appropriate to the context and / or use. For clarity purposes, various singular / plural rearrangements may be explicitly described herein.

[0169] In general, it will be understood by those skilled in the art that the terms used herein, and in particular in the appended claims (e.g., the text of the appended claims), are generally intended to be “non-limiting” terms (for example, the term “contains” should be interpreted as “contains, but not limited to,” the term “has” should be interpreted as “has at least,” and the term “contains” should be interpreted as “contains, but not limited to,” etc.). Furthermore, where a description of a certain number of introduced claims is intended, such intent is explicitly stated in the claim, and where such statement is absent, such intent is not understood by those skilled in the art. For example, if only one item is intended, the term “single” or similar wording may be used. To aid understanding, the following descriptions of the appended claims and / or herein may include the use of the introductory phrases “at least one” and “one or more” to introduce the description of a claim. However, the use of such phrases should not be interpreted as meaning that the introduction of a claim description with the indefinite article "a" or "an" limits any particular claim containing such introduced claim description to embodiments containing only one such description, even if the same claim contains the introductory phrase "one or more" or "at least one" and an indefinite article such as "a" or "an" (for example, "a" and / or "an" are interpreted as meaning "at least one" or "one or more"). The same applies to the use of definite articles used to introduce claim descriptions. In addition, even if a specific number of introduced claim descriptions are explicitly described, it will be recognized by those skilled in the art that such descriptions should be interpreted as meaning at least the number described (for example, the simple description "two descriptions" without other modifiers means at least two descriptions or two or more descriptions).Furthermore, when expressions similar to "at least one of A, B, and C, etc." are used, such structures are generally intended to have a meaning that a person skilled in the art would understand (for example, "a system having at least one of A, B, and C" includes, but is not limited to, systems having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together). When expressions similar to "at least one of A, B, or C, etc." are used, such structures are generally intended to have a meaning that a person skilled in the art would understand (for example, "a system having at least one of A, B, or C" includes, but is not limited to, systems having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together). It will be further understood by those skilled in the art that any actual disjunctive words and / or phrases presenting two or more alternative terms in the specification, claims, or drawings should be understood as construed to include the possibility of including one of the terms, either of the terms, or both of the terms. For example, the phrase “A or B” is understood to include the possibility of “A” or “B” or “A and B.” Furthermore, as used herein, the term “any of” followed by a list of items and / or a list of categories of items is intended to include “any of,” “any combination of,” “any number of,” and / or “any number of,” items and / or categories of items, individually or in combination with other items and / or categories of other items. Furthermore, as used herein, the term “set” is intended to include any number of items, including zero. In addition, as used herein, the term “number” is intended to include any number, including zero. Also, as used herein, the term “multiple” is intended to be synonymous with “multiple.”

[0170] In addition, if any feature or aspect of the present disclosure is described in terms of the Markush group, a person skilled in the art will recognize that the present disclosure is also described in terms of any individual element or subgroup of elements of the Markush group.

[0171] As will be understood by those skilled in the art, for all purposes, including providing written descriptions, all scopes disclosed herein also encompass any possible sub-scopes and combinations of sub-scopes. Any enumerated scope may be readily recognized as fully explaining and enabling that the same scope can be broken down into at least equal 1 / 2, 1 / 3, 1 / 4, 1 / 5, 1 / 10, etc. In non-limiting embodiments, each scope considered herein may readily be broken down into a lower third, a middle third, an upper third, etc. Also, as will be understood by those skilled in the art, all words such as “up to,” “at least,” “more than,” and “less than” include the number described and refer to a scope that can be later broken down into sub-scopes as considered above. Finally, as will be understood by those skilled in the art, a scope includes each individual element. Thus, for example, a group having 1 to 3 cells refers to a group having 1, 2, or 3 cells. Similarly, a group having 1 to 5 cells refers to a group having 1, 2, 3, 4, or 5 cells, and so on.

[0172] Furthermore, unless otherwise specifically stated, the claims should not be read as being limited to the order or elements provided. In addition, the use of the term “means for” in any claim is intended to appeal to Section 112, paragraph 6 of the U.S. Patent Act, or the means-plus-function claim format, and no claim without the term “means for” is intended to appeal in that way.

[0173] Suitable processors include, for example, general-purpose processors, dedicated processors, conventional processors, digital signal processors (DSPs), multiple microprocessors, one or more microprocessors associated with a DSP core, controllers, microcontrollers, application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), field-programmable gate array (FPGA) circuits, any other type of integrated circuit (IC), and / or state machines.

[0174] WTRU can be used in conjunction with modules implemented in hardware and / or software, such as Software Defined Radio (SDR), and can also be implemented in other components such as cameras, video camera modules, video phones, speakerphones, vibration devices, speakers, microphones, TV transceivers, hands-free headsets, keyboards, Bluetooth® modules, frequency modulation (FM) radio units, Near Field Communication (NFC) modules, LCD display units, organic light-emitting diode (OLED) display units, digital music players, media players, video game player modules, internet browsers, and / or wireless local area network (WLAN) or ultra-wideband (UWB) modules.

[0175] Although various embodiments of the communication system have been described, it is intended that the system can be implemented in software on a microprocessor / general-purpose computer (not shown). In certain embodiments, one or more functions of the various components may be implemented in software that controls the general-purpose computer.

[0176] In addition, while the present invention is illustrated and described herein with reference to specific embodiments, it is not intended to be limited to the details shown. Rather, various modifications can be made in detail within the scope of the claims and their equivalents, and without departing from the present invention.

Claims

1. A wireless transmitter / receiver unit (WTRU), The processor comprises, A direct communication path to the network and an indirect communication path to the network are established, the indirect communication path comprising a first path between the WTRU and the relay WTRU and a second path between the relay WTRU and the network. A message indicating that a failure has occurred in the second path is received from the relay WTRU, Based on the message received from the relay WTRU, a failure in the indirect communication path is determined. A WTRU configured to transmit a fault message to the network via a direct communication path, the fault message indicating that the fault in the indirect communication path occurred on the second path between the relay WTRU and the network.

2. The WTRU according to claim 1, wherein the fault message includes a measurement based on whether the indirect communication path is a Third Generation Partnership Project (3GPP) communication path or a non-3GPP communication path.

3. The WTRU according to claim 2, wherein the measured value is the reference signal received power (RSRP).

4. The aforementioned processor, The WTRU according to claim 1, configured to interrupt transmission via the indirect communication path in response to detection of a fault in the indirect communication path.

5. The WTRU according to claim 1, wherein the first path comprises a side link between the WTRU and the relay WTRU, and the second path comprises a Uu link between the relay WTRU and the network.

6. The WTRU according to claim 1, wherein the direct communication path is a direct Uu communication path between the WTRU and the network.

7. A method performed by a wireless transmit / receive unit (WTRU), the method comprising establishing a direct communication path to a network and an indirect communication path to the network, the indirect communication path comprising a first path between the WTRU and a relay WTRU and a second path between the relay WTRU and the network, Receiving a message from the relay WTRU indicating that a failure has occurred in the second path, Based on the message received from the relay WTRU, determine the failure of the indirect communication path, A method comprising transmitting a fault message to the network via a direct communication path, the fault message indicating that the fault in the indirect communication path occurred on the second path between the relay WTRU and the network.

8. The method according to claim 7, wherein the fault message includes a measurement based on whether the indirect communication path is a Third Generation Partnership Project (3GPP) communication path or a non-3GPP communication path.

9. The method according to claim 8, wherein the measured value is the reference signal received power (RSRP).

10. The method described above is The method according to claim 7, further comprising interrupting transmission via the indirect communication path in response to detection of the fault in the indirect communication path.

11. The method according to claim 7, wherein the first path comprises a side link between the WTRU and the relay WTRU, and the second path comprises a Uu link between the relay WTRU and the network.

12. The method according to claim 7, wherein the direct communication path is a direct Uu communication path between the WTRU and the network.

13. A wireless transmitter / receiver unit (WTRU), The processor comprises, A direct communication path to the network and an indirect communication path to the network are established, the indirect communication path comprising a first path between the WTRU and the relay WTRU and a second path between the relay WTRU and the network. A side-link radio link fault (SL RLF) is detected on the first path. Based on the detection of SL RLF on the first path, a fault in the indirect communication path is determined. A WTRU configured to transmit a fault message to the network via a direct communication path, the fault message indicating that the fault in the indirect communication path occurred on the first path between the WTRU and the relay WTRU.

14. The WTRU according to claim 13, wherein the fault message includes a flag indicating that the fault in the indirect communication path occurred on the first path.

15. The WTRU according to claim 13, wherein the fault message includes a measurement based on whether the indirect communication path is a Third Generation Partnership Project (3GPP) communication path or a non-3GPP communication path.

16. The aforementioned processor, The WTRU according to claim 13, configured to interrupt transmission via the indirect communication path in response to detection of a fault in the indirect communication path.

17. The WTRU according to claim 13, wherein the first path comprises a side link between the WTRU and the relay WTRU, and the second path comprises a Uu link between the relay WTRU and the network.

18. The WTRU according to claim 13, wherein the direct communication path is a direct Uu communication path between the WTRU and the network.

Images