Method and apparatus for radio link failure and recovery in multipath sidelink relaying

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 priority to and the benefit of U.S. Provisional Patent Application No. 63 / 394,783, filed in the U.S. Patent and Trademark Office on August 3, 2022, and U.S. Provisional Patent Application No. 63 / 421,856, filed in the U.S. Patent and Trademark Office on November 2, 2022, the entire contents of each of which are incorporated herein by reference in their entirety and for all applicable purposes as if fully set forth below.

[0002] FIELD OF THE INVENTION The present disclosure relates to wireless communications. For example, one or more embodiments disclosed herein relate to methods and apparatus for radio link failure, radio link monitoring, and / or radio 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 relayed wireless transmit / receive unit. Summary of the Invention

[0003] One or more embodiments disclosed herein relate to a method and apparatus for radio link failure (RLF) and recovery in multipath wireless communications.

[0004] In one embodiment, a method implemented by a WTRU for wireless communication includes receiving configuration information indicating 1) a first radio link configuration and a second radio link configuration, and 2) a first threshold and a second threshold, 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.

[0005] In one embodiment, a WTRU for wireless communication comprising circuitry including a transmitter, a receiver, a processor, and a 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, where the first threshold is greater than the second threshold; determine 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; determine channel conditions for a second transmission from the network entity, the second transmission associated with the second communications link; and perform 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. [Brief explanation of the drawings]

[0006] A more detailed understanding can be had from the following detailed description, given by way of example in conjunction with the drawings that accompany this specification. The figures in such drawings, like the detailed description, are illustrative. Therefore, the figures and detailed description should not be considered limiting, as other equally effective embodiments are possible and likely to be so. Moreover, like reference numerals ("ref") within the figures ("FIG") indicate like elements. [Figure 1A] 1 is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] 1B is a system diagram illustrating an exemplary wireless transmit / receive unit (WTRU) that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 1C] 1B is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system shown in FIG. 1A, in accordance with one or more embodiments. [Figure 1D] 1B is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communication system shown in FIG. 1A, according to one or more embodiments. [Figure 2] FIG. 1 illustrates a protocol view of split bearers in dual connectivity. [Figure 3] FIG. 10 is a diagram illustrating an RLC configuration in dual connectivity when dual connectivity is adopted. [Figure 4] FIG. 1 illustrates a user plane protocol stack of the L2 U2N relay architecture. [Figure 5] FIG. 1 illustrates a protocol stack for the control plane of an L2 U2N relay architecture. [Figure 6] FIG. 10 illustrates a multipath model at the protocol stack level for a WTRU in dual connectivity where both connection paths are to the same cell. [Figure 7]FIG. 10 illustrates a multipath model at the protocol stack level for a WTRU in dual connectivity where two connection paths pass through different cells. [Figure 8] 10 is a flowchart illustrating RLM / RLF processing for a dual connectivity WTRU in accordance with one or more embodiments. [Figure 9] 10 is a flowchart illustrating radio link re-establishment for a dual connectivity WTRU, in accordance with one or more embodiments. [Figure 10A] FIG. 1 illustrates an exemplary multipath wireless communication in accordance with one or more embodiments. [Figure 10B] 1 is a flowchart illustrating an example procedure for RLM and / or RLF detection in multi-path communication, in accordance with one or more embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0007] Introduction In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the embodiments and / or examples disclosed herein. It will be understood, however, that such embodiments and examples may be practiced without some or all of the specific details set forth herein. In other instances, well-known methods, procedures, components, and circuits have not been 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, embodiments and other examples explicitly, implicitly, and / or inherently described, disclosed, or otherwise provided herein (collectively "provided").

[0008] Although various embodiments are described and / or claimed herein in which apparatus, systems, devices, etc. and / or any elements thereof perform operations, processes, algorithms, functions, etc. and / or any portions thereof, it should be understood that any embodiment described and / or claimed herein assumes that any apparatus, system, device, etc. and / or any elements thereof are configured to perform any operation, process, algorithm, function, etc. and / or any portion thereof.

[0009] Examples of communication systems The methods, apparatus, and systems provided herein are well suited for communications involving both wired and wireless networks. Wired networks are well known. An overview of various types of wireless devices and infrastructure is provided with respect to Figures 1A-1D, and various elements of the networks may utilize, perform, be arranged, and / or be adapted and / or configured in accordance with the methods, apparatus, and systems provided herein.

[0010] 1A is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. Communication system 100 may be a multiple-access system that provides content, such as voice, data, video, messaging, broadcasts, etc., to multiple wireless users. Communication system 100 may enable multiple wireless users to access such content through sharing of system resources, including wireless bandwidth. For example, the communication system 100 may 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 filtered OFDM, filter bank multicarrier (FBMC), etc.

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

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

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

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

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

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

[0017] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access, which may establish the air interface 116 using 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 jointly implement LTE radio access and NR radio access, e.g., using dual connectivity (DC) principles. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to and from 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 a wireless technology such as IEEE 802.11 (i.e., Wireless Fidelity, WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access, WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), or the like.

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

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

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

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

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

[0025] The processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) 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 functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[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) over the air interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive IR signals, UV signals, or visible light signals, for example. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF signals and light signals. It will be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0027] 1B as a single element, 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 wireless signals over the air interface 116.

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

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

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

[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, information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) over the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

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

[0033] The WTRU 102 may include a full-duplex radio where transmission and reception of some or all of the signals (e.g., associated with a particular subframe for both the uplink (e.g., for transmission) and downlink (e.g., for reception)) may be parallel and / or simultaneous. The full-duplex radio may include an interference management unit 139 to reduce and or substantially eliminate self-interference either through hardware (e.g., chokes) or signal processing via a processor (e.g., via a separate processor (not shown) or processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio for transmission and reception of some or all of the signals (e.g., associated with a particular subframe for either the uplink (e.g., for transmission) or downlink (e.g., for reception)).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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] 1D is a system diagram illustrating the RAN 113 and the CN 115, according to one embodiment. As noted above, the RAN 113 may use NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also communicate with the CN 115.

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

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

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

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

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

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

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

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

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

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

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

[0063] One or more emulation devices may perform one or more functions, inclusive, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in test scenarios in a test lab and / or in an undeployed (e.g., test) wired and / or wireless communication network to implement testing of one or more components. One or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may include, e.g., one or more antennas) may be used by the emulation devices to transmit and / or receive data.

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

[0065] Like any bearer, the WTRU has one Packet Data Convergence Protocol (PDCP) entity associated with it, and the peer PDCP entity on the network side is terminated at one of the gNBs (either master or secondary). In the downlink (DL), the core network (CN) sends data to the gNB where the PDCP terminates (gNB1 in Figure 2 above), and it is up to the network to either send the data directly to the WTRU over the link between that gNB and the WTRU, or to forward PDCP PDUs to gNB2 (e.g., over the Xn interface), which then sends the data to the WTRU over the link between itself and the WTRU.

[0066] In the 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 for that bearer is below this threshold, PDCP pushes data only to the Radio Link Control (RLC) associated with the primary path. However, if the buffer size becomes larger than the threshold, the WTRU can push data to either path (i.e., it is up to the WTRU implementation).

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

[0068] When replication is configured for a radio bearer by RRC, at least one secondary RLC entity is added to the radio bearer to process the replicated PDCP packet data units (PDUs), as shown in Figure 3. 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 transmitting the same PDCP PDU multiple times, once to each activated RLC entity of the radio bearer. PDCP control PDUs are not replicated and are always transmitted to the primary RLC entity. Therefore, packet replication, with multiple independent transmission paths, increases reliability and reduces latency, making it particularly beneficial for URLLC services.

[0069] When configuring Data Radio Bearer (DRB) duplication, Radio Resource Control (RRC) also sets the state of PDCP duplication (either activated or deactivated) at (re)configuration time. After configuration, the PDCP duplication state can be dynamically controlled by the Media Access Control (MAC) Control Element (CE); in DC, the WTRU applies MAC CE commands regardless of their origin (MCG or SCG).

[0070] When replication of a Signaling Radio Bearer (SRB) is configured, the state of PDCP replication is always active and cannot be dynamically controlled. When configuring replication of a DRB with two or more secondary RLC entities, the RRC also sets the state of each of them (i.e., either 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 replication transmission. The primary RLC entity cannot be deactivated. When replication 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 activating replication for a DRB, the network shall ensure that at least one serving cell is activated for each logical channel associated to the activated RLC entity of the DRB, and if deactivation of an SCell leaves no serving cell activated for the logical channels of the DRB, the network shall ensure that replication is also deactivated for the RLC entity associated to the logical channel.

[0072] When duplication is activated, the original PDCP PDU and the corresponding duplicate shall not be transmitted on the same carrier. The logical channels of a radio bearer configured with duplicates can belong either to the same MAC entity (called CA duplicates) or to different MAC entities (called DC duplicates).

[0073] CA replication may also be configured in either or both MAC entities along with DC replication when replication across more than two RLC entities is configured for a radio bearer. In CA replication, logical channel mapping restrictions are used in the MAC entity 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 an SpCell.

[0074] When CA duplication is deactivated for a DRB within a MAC entity (i.e., none of the RLC entities for the DRB within the MAC entity are activated or only one remains activated), the logical channel mapping restriction for the logical channels of the DRB is lifted as long as CA duplication 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. Additionally, in case of CA replication, when an RLC entity restricted to only SCells reaches the maximum number of retransmissions for a PDCP PDU, the WTRU shall notify the gNB but shall not trigger a Radio Link Failure (RLF).

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

[0077] For a WTRU in a DC, the WTRU performs Radio Link Monitoring / Radio Link Failure (RLM / RLF) on the PCell of the MCG and the PSCell of the SCG. RLF is declared separately for the MCG and the 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 an RRC connection re-establishment procedure. During fast MCG link recovery, the WTRU suspends MCG transmission for all radio bearers and reports the failure via an MCG failure information message to the master node (MN) via the SCG using the split SRB1 or SRB3 SCG leg.

[0079] The WTRU includes in the MCG Failure Information message any measurement results available according to the current measurement configuration of both the MN (i.e., the node gNB associated with the MCG) and the Secondary Node (SN) (node ​​associated with the SCG). When Fast MCG Link Recovery is triggered, the WTRU maintains the current measurement configuration from both the MN and the SN and continues measurements based on the configurations from the MN and SN, if possible. If the WTRU does not receive an RRC Reconfiguration message, MobilityFromNRCommand message, MobilityFromEUTRACommand message, or RRC Release message within a certain period of time after Fast MCG Link Recovery is initiated, it initiates an 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] Upon SCG failure, if the MCG transmission of the radio bearers is not suspended, the WTRU suspends SCG transmission for all radio bearers instead of triggering re-establishment and reports SCG failure information to the MN. If an SCG failure is detected while the MCG transmission for all radio bearers is suspended, the WTRU initiates the RRC connection re-establishment procedure.

[0082] In all SCG failure cases, the WTRU maintains the current measurement configuration from both the MN and the SN, and the WTRU continues to make measurements based on the configuration from the MN and the SN, if possible.

[0083] The WTRU includes the available measurement results according to the current measurement configurations of both the MN and the SN in the SCG failure information message.

[0084] In the embodiments described above and below, re-establishment consists of the WTRU 1) performing cell selection and / or sending a re-establishment request RRC message upon cell selection.

[0085] Relay in wireless communication networks Release 17 of the 3GPP specifications specifies SL-based UE-to-network relaying. To provide network connectivity for U2N remote WTRUs, sidelink relaying is introduced to support 5G ProSe WTRU-to-Network Relay (U2N Relay) functionality. 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 shall be in RRC_CONNECTED state to perform relaying of unicast data.

[0087] For L2 U2N relay operation, the following RRC state combinations are supported: 1) Both the U2N relay WTRU and the U2N remote WTRU shall be in the RRC connected state to perform relayed unicast data transmission / reception, 2) As long as all U2N remote WTRUs connected to the U2N relay WTRU are in either the RRC_INACTIVE or RRC_IDLE state, the U2N relay WTRU can be in the RRC_IDLE, RRC_INACTIVE, or RRC_CONNECTED state. For 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 shall be separated on different Uu RLC channels over Uu.

[0089] L2 U2N Relay Protocol Architecture The protocol stacks for the user plane and control plane of the L2 U2N relay architecture are presented in Figures 4 and 5, respectively. The Sidelink Relay Adaptation Protocol (SRAP) sublayer is located above the RLC sublayer for both the control plane (CP) and user plane (UP) on both the PC5 and Uu interfaces. The Uu Service Data Adaptation Protocol (SDAP), PDCP, and RRC are terminated between the L2 U2N remote WTRU and the gNB, and 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] For L2 U2N relaying, the SRAP sublayer on the PC5 hop is for bearer mapping purposes only. The SRAP sublayer is not present 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 is not present on the PC5 hop, but the SRAP sublayer is present on the Uu hop for both DL and UL.

[0091] In the case of L2 U2N relay, for the uplink, The Uu SRAP sublayer supports UL bearer mapping between the ingress PC5 relay RLC channel and the egress Uu relay RLC channel for relaying over the L2 U2N relay WTRU Uu interface. For uplink relay traffic, different end-to-end RBs (SRBs or DRBs) 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 and the local remote WTRU ID are included in the UL Uu SRAP header so that the gNB can correlate received packets with the specific PDCP entity associated with the correct Uu radio bearer for the remote WTRU. The PC5 SRAP sublayer in the L2 U2N remote WTRU supports UL bearer mapping between the remote WTRU Uu radio bearer and the egress 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 a remote WTRU to a Uu relay RLC channel over the relay WTRU Uu interface. The Uu SRAP sublayer supports DL bearer mapping and data multiplexing between an L2 U2N remote WTRU and / or multiple end-to-end radio bearers (SRBs or DRBs) of different L2 U2N remote WTRUs and one Uu relay RLC channel over the relay WTRU Uu interface. The Uu SRAP sublayer supports remote WTRU identification for DL ​​traffic. The remote WTRU Uu radio bearer identification and the local remote WTRU ID are included in the Uu SRAP header by the gNB in ​​the DL for the relay WTRU to map received packets 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 egress PC5 relay RLC channel. The PC5 SRAP sublayer in the remote WTRU correlates the received packet to the particular PDCP entity associated with the correct Uu radio bearer of 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 with 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. The Uu DRBs and Uu SRBs are mapped to different PC5 relay RLC channels and Uu relay RLC channels in both the PC5 and Uu hops.

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

[0094] Sidelink Scheduling The sidelink supports two scheduling modes—Mode 1 and Mode 2. For an in-coverage WTRU, 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 RRC_CONNECTED state, the WTRU receives SL grants directly from the network in Downlink Control Information (DCI). In this case, the WTRU reports buffer status for SL data grouped by destination index (a destination index corresponds to a unique L2 destination ID or a source / destination L2 ID pair). The WTRU can send a Scheduling Request (SR) if no SL grant is available for the transmission of the pending data.

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

[0097] Multipath Operation Release 17 of the 3GPP specifications introduces Layer 2 WTRUs in network relaying. The main use case considered is that of a remote WTRU that is out of coverage. However, Release 18 is planned to specify multipath. In multipath, the remote WTRU is assumed to be in coverage and therefore can utilize either the Uu path, the SL (relay) path, or both. A description of multipath operation for Release 18 follows [2]:

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

[0099] In multipath operation, the direct link between the remote WTRU and the gNB and the backhaul link between the relay WTRU and the gNB may be served by the same gNB, or even by the same cell of the same gNB. Also, when 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 a 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 SL (although not in as real-time as in Mode 1).

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

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

[0102] RLF Failure and Recovery in Multipath Sidelinks Multipath may involve the same scheduler controlling the Uu and SL paths of the remote WTRU. As a result, bearers (including SRBs) may be configured to use either path. Unlike DC, with multipath, there is no master node concept; both paths terminate at the same node in the network. As a result, it is unnecessary for the remote WTRU to simultaneously monitor the radio links of both paths, which may result in unnecessary power consumption. The links on which the WTRU should monitor RLF should also be synchronized with the links the network can use to transmit RRC signaling. However, the RLM / RLF mechanism to be used may depend on whether multipath is used to ensure reliability (i.e., both paths are important) or to maintain coverage (i.e., the ability to maintain connectivity via only a single path is required). In the multipath case, where one path is via SL relays, RLF is detected based on HARQ feedback instead of the usual RLM. This mechanism for RLF detection can be unreliable, especially when the amount of data sent over the SL path is limited.

[0103] Finally, the recovery behavior for multipath may depend on the factors mentioned above and may need to be defined differently for multipath than for DC in the absence of a master node.

[0104] Multipath Communication In the embodiments described herein, a remote WTRU in a multi-path refers to a WTRU connected to a network via two different paths: a direct Uu path and a path to a network relay via an SL WTRU. The connection 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 to multiple paths (two or more), or when two or more paths to a network relay WTRU via an SL WTRU are maintained by the remote WTRU.

[0105] Exemplary Procedure for a WTRU to Recognize Inter-gNB Changes Performed by a Relay WTRU Method for determining whether cells belong to the same / different gNB Embodiments for RLM / RLF herein may rely on knowledge at the WTRU of whether two cells (e.g., a cell associated with a direct path and a cell associated with an indirect / relay path) belong to the same gNB or to different gNBs. The remote WTRU may perform different procedures described herein depending on whether the cells are associated with the same gNB or different gNBs. Such information may be determined using any of the following solutions: -List of cells: For example, the network may provide a list of cells associated with a particular cell (e.g., a direct path cell). 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] -Identification information broadcast / transmitted by the cell For example, a cell may transmit (e.g., in a System Information Block (SIB) or by dedicated RRC signaling) an identity that is used to determine if two different cells are associated with the same gNB. For example, if cells transmit the same identity, the WTRU can assume that they are part of the same gNB. Explicitly as part of a network-initiated procedure (e.g., Handover (HO), reconfiguration, etc.) For example, a remote WTRU may be multipath connected, with a direct link to cell 1 and an indirect link via a relay connected to cell 2. Cell 1 and cell 2 may belong to the same gNB. The relay WTRU may receive the HO command from the network and may inform the remote WTRU thereof. Upon receiving the HO command, the remote WTRU may need to determine whether the target cell (cell 3) is part of the same gNB. This may be indicated directly by the network using a flag or indication in the HO command itself. Specifically: ■ The relay WTRU may receive an indication in the HO command to be forwarded to the remote WTRU in the notification message. Specifically, if the indication is sent (e.g., the flag is set to true), such HO may represent a gNB to gNB HO at the relay WTRU. ■ The relay WTRU may include an indication or flag in the notification message to the remote WTRU. ■Remote WTRU is Upon receiving a HO notification with an indication that the source cell and target cell are associated with different gNBs, the procedures associated with inter-gNB HO (as described herein) may be performed. ● Upon receiving an HO notification without an indication that the source cell and target cell are associated with different gNBs, the procedure (described herein) associated with intra-gNB HO (i.e., the indirect path and the direct path are associated with the same gNB) may be performed.

[0107] Representative procedures for RLM / RLF in multipath The remote WTRU in the multipath determines the path on which RLM / RLF is monitored. In one solution, the remote WTRU may determine on which paths it should perform RLM / RLF based on one or more, or any combination of, the following factors: While not explicitly mentioned in the examples below, 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 strength (whether to use normal RLM or relaxed RLM) and / or other aspects of the RLM / RLF. Furthermore, the remote WTRU may determine whether / how to perform RLM / RLF on one path (e.g., direct or indirect) based on conditions associated with other paths (indirect or direct), such conditions being described below. When determining whether / how to perform Uu RLM / RLF and / or whether / how to perform SL RLF, a combination of the following factors may be considered: In some embodiments, a first condition may be used to determine a second condition to be used in the decision. Specifically, the factors may include the following: -Uu path quality measurements: For example, the WTRU may perform RLM / RLF on the Uu path if the RSRP measured on the Uu path is below a threshold, and may stop performing RLM / RLF on the Uu path if the RSRP measured on the Uu path is above a threshold, because the WTRU may assume that RLM / RLF on the Uu path is unnecessary when the Uu link has good path quality if it can assume that there is an SL path to fall back to. For example, (1) the WTRU may perform RLM / RLF on the Uu path if the RSRP measured on the Uu path is below a first threshold, (2) may perform relaxed RLM / RLF on the Uu path if the RSRP measured on the Uu path is between the first threshold and a second threshold, and (3) may not perform RLM / RLF if the RSRP measured on the Uu path is above the second threshold. For example, the WTRU may perform RLM / RLF on the Uu path if the RSRP measured on the Uu path is above a threshold, and may perform RLF on the relayed path only if the RSRP measured on the Uu path is below a threshold. These two thresholds may be the same or different. The reason for this approach is that in the case of a large Uu RSRP, the network may send RRC signaling on the Uu path, and the WTRU should monitor RLF based on only the Uu path. -SL route quality measurement For example, the WTRU may perform RLM / RLF on the Uu path if the SL quality (e.g., SL RSRP) is above / below a threshold For example, a combined criterion of Uu quality and SL quality may be considered to determine on which links RLF should be performed. For example: If the SL RSRP is above a threshold and the Uu RSRP is above a threshold, the WTRU may perform RLF only on the SL path. If the SL RSRP is below a threshold or the Uu RSRP is below a threshold, the WTRU may 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 an approach is that the WTRU can turn off Uu RLM monitoring when it is sure that it has a sufficiently good SL link as a backup. If the SL RSRP is above a first threshold and the Uu RSRP is above a second threshold, the WTRU may perform RLF on either the SL path or the Uu path (determined by the WTRU or configured by the network), otherwise it may perform RLF on both paths. If the SL RSRP is below a first threshold and the Uu RSRP is below a second threshold, the WTRU may perform RLF on both paths, otherwise it may perform RLF on one link (determined by the WTRU or configured by the network). -SL specific measurements such as CBR For example, the WTRU may perform RLM / RLF on the Uu path if the SL Channel Busy Ratio (CBR) is above a threshold. The advantage of such an approach is that if congestion exists on the SL, Uu RLM is maintained regardless of whether the Uu RSRP is good or not. - the presence or amount of UL data being transmitted on the SL or Uu path o This can be measured based on the amount of data routed by the Packet Data Protocol (PDP), the amount of data in the SL RLC buffer of the WTRU, or the Channel Occupancy Ratio (CR) measured on the sidelink For example, the WTRU may perform RLM / RLF on the Uu path if the SL CR is above a threshold. The advantage of such an approach is that the WTRU can be sure that enough data is being sent by the WTRU over the SL path to warrant a reliable HARQ-based RLF mechanism for monitoring the multipath link. o For example, if the WTRU has data for an SL logical channel with HARQ feedback enabled, the WTRU may perform RLM / RLF on the Uu path. - A message received from a relay WTRU o In one embodiment, the remote WTRU may change its RLM / RLF behavior based on receiving a Uu RLF indication from the relay WTRU. Specifically, if the remote WTRU is not monitoring RLM / RLF on the Uu path at a given time and receives a Uu RLM / RLF indication from the relay WTRU, the remote WTRU may notify the network over Uu of this and then start / resume RLM / RLF on the Uu path. The WTRU may continue to perform RLM / RLF on the Uu path until reconfigured with a new relay WTRU or until there is an indication (from the network or relay WTRU) that the Uu link at the relay WTRU has been restored. In one embodiment, the remote WTRU may modify its RLM / RLF behavior based on a flow control message received from the relay WTRU. Specifically, the remote WTRU may receive a flow control indication 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 may perform RLM / RLF over the Uu path. Otherwise, the remote WTRU may perform relaxed RLM / RLF or no RLM / RLF over the Uu path. QoS / bearer configuration in the remote WTRU o For example, the condition for using the SL path for RLF may be further conditioned on the WTRU being configured with at least one SL LCH with HARQ feedback configured. For example, the condition for using the SL path for RLF may be further conditioned on the WTRU being configured with at least one SL RLC channel configured in RLC Acknowledged Mode (AM). For example, a WTRU may be permitted to use a first condition described herein to determine the RLF behavior for some QoS flows / bearers, and a 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 data available. For example, the remote WTRU may 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, the remote WTRU may monitor Uu RLM / RLF if all SL LCHs are configured without HARQ feedback enabled. For example, the remote WTRU may monitor Uu RLM / RLF if the number of SL LCHs configured with HARQ feedback enabled is above a threshold. For example, the remote WTRU may monitor Uu RLM / RLF if the amount of data buffered in the WTRU SL LCH with HARQ feedback enabled is below a threshold. For example, the WTRU may use the above determination on whether to monitor Uu RLM / RLF when the cells associated with the direct and indirect links are the same and / or when the WTRU is configured with split SRBs. For example, the remote WTRU may perform 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. The WTRU may further determine mitigation parameters associated with relaxed RLM / RLF (e.g., percentage of reference signals to monitor, values ​​of timers / counters associated with RLM / RLF, etc.) based on such conditions. Whether the relay and remote WTRUs are controlled by the same / different cells / schedulers / gNBs For example, the WTRU may use a first rule or condition described herein for the same cell and a different rule or condition for multiple cells. For example, the WTRU may always run RLF on both paths in the different cell case, but may use other conditions described herein to decide whether to run RLF on both paths in the same cell case. -SRB route configuration for multiple routes For example, the WTRU may perform RLM / RLF on the Uu path, or may have a rule that prioritizes RLM / RLF detection on the Uu path if SRBs are configured to be transmitted only on the Uu path, or may have a rule that prioritizes RLF monitoring on the SL if SRBs are transmitted only on the SL path, or may have a rule that allows flexible route determination based on RSRP (as described herein) if SRBs can be transmitted on both paths. - SRB replication configuration in multiple paths For example, if the SRB is configured for replication, the WTRU can perform RLF for both the Uu link and the SL link. RRC state of relay WTRU For example, the WTRU may be in a multipath state whereby the relay WTRU is in IDLE / INACTIVE, in which case all UL / DL data is routed via Uu. In such a case, the remote WTRU may always monitor RLM / RLF via Uu. When the relay WTRU is in CONNECTED state, the remote WTRU may use other rules to determine RLM / RLF monitoring. -Whether the route corresponds to a direct or indirect route o For example, the WTRU may use a first rule to determine whether to monitor RLF on the direct path and a second rule (herein) to determine whether to monitor RLF on the indirect path. For example, the WTRU may always monitor the RLF on the indirect path and may decide whether to monitor the RLF on the direct path based on other rules herein. - Whether the indirect path is associated with a 3GPP link (e.g., PC5) or a non-3GPP link For example, if the indirect path is associated with a 3GPP link (i.e., PC5), the remote WTRU may perform Uu RLM / RLF (or vice versa, i.e., the remote WTRU will perform SL RLM / RLF). Alternatively, if the indirect path is associated with a non-3GPP link, the remote WTRU may not perform Uu RLM / RLF (or vice versa, i.e., the remote WTRU will perform SL RLM / RLF). Alternatively, the remote WTRU may perform relaxed RLM / RLF over Uu if the indirect path is associated with a 3GPP link.

[0108] A remote WTRU may initiate an RLM / RLF procedure on one link when the other link declares an RLF and / or recovery failure. In one embodiment, a remote WTRU can initiate RLM / RLF on one link when the other link declares a failure. Such a failure can be an RLF on that link, a failure to re-establish that link, transmission of a failure RRC message (e.g., an SCGFailure-like message or an MCGFailure-like message), or any failure related to the same condition used to trigger RLF (e.g., reaching a certain number of consecutive HARQ DTXs on a link). For example, the remote WTRU can be configured to monitor RLF on the SL and Uu, but can only monitor SL-based RLF at a given time. If the remote WTRU detects RLF on the SL, the remote WTRU can initiate RLM / RLF monitoring on the Uu. The remote WTRU can further use such operation only under the conditions of the particular network architecture and / or bearer architecture for which such operation is configured. In particular, such operation can be useful when the network transmits RRC signaling on one path and an RLF on that path can be expected to switch the path for RRC signaling to another path. For example, the WTRU may initiate RLF on one path following detection of RLF on another path when any one or more of the following conditions apply: Conditions associated with the configuration of one or more bearers (SRB or DRB). For example, this behavior may apply when configured with split SRB without replication. Specifically, the WTRU can perform RLM / RLF on both paths when split SRB is configured with replication. When configured with only 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 the 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 may apply when the WTRU is configured with the same cell on both the direct and indirect paths. Specifically, when configured with different cells on different paths, the RLF on one path may initiate an MCG-like failure procedure, where the remote WTRU reports a failure and awaits 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; the WTRU may instead just initiate failure monitoring on the non-faulty path in the hope of receiving an RRC message on the non-faulty path. Conditions associated with whether the WTRU-WTRU (indirect) link is an ideal link. For example, behavior can apply when the indirect link between WTRUs is a non-3GPP link. Specifically, when configured with a PC5 link, the remote WTRU can monitor RLF on both links, but when configured with 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 RLM / RLF on the Uu on its behalf. -Conditions related to whether the path on which RLF is triggered is direct or indirect. For example, this behavior may apply when RLF is triggered on an indirect path, but may not apply when RLF is triggered on a direct path. For example, the remote WTRU may always monitor for RLF over PC5-RRC, since there is little additional power consumed for RLM monitoring compared to Uu. Conditions associated with the type of SL RLF that may be triggered. In particular, the behavior may apply only for some cases of SL failure, such as when only an SL RLF based on HARQ DTX is triggered, when only an SL RLF based on T400 expiry is triggered, when only an SL RLF based on receipt of a Uu RLF indication from a relaying WTRU is triggered, etc.

[0109] In related embodiments, the WTRU may be performing relaxed RLM on one path and may initiate regular RLM / RLF when an RLF (or similar failure event) occurs on the other path.

[0110] The remote WTRU routes the data over the SL path based on the conditions associated with the RLM / RLF. In one embodiment, the WTRU may modify the routing rules for UL data on split bearers based on the SRB configuration and / or other factors that may 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 a requirement, the WTRU may perform routing over the SL path such that sufficient data for the UL split bearer is transmitted over the SL path. For example, the WTRU may be configured with a percentage of data to be routed over the SL path, possibly per split bearer, and may ensure that the 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 a different split bearer threshold (e.g., a value of 0), and the WTRU may apply that split bearer threshold based on conditions described herein (e.g., Uu and / or SL quality).

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

[0112] Returning to step 801, if the Uu RSRP is below the first threshold, 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, flow proceeds to step 809, where the WTRU determines whether there is UL data pending for the SL relay path. If so, the WTRU performs RLM on the SL relay path and relaxed RLM on the Uu path (step 811). If not, the WTRU performs RLM on both paths (step 813).

[0113] Although not shown in the flowchart, in one embodiment, if 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 RLF is triggered on both links, radio link re-establishment is performed.

[0114] Representative procedures for multipath recovery. The remote WTRU determines the recovery procedure in multipath. Upon detecting a problem on one or both links (e.g., an RLF detection or indication from a relay WTRU), the remote WTRU may perform one or more of several recovery procedures. The remote WTRU may perform any or several recovery procedures (e.g., sequentially or simultaneously), including the following: -Perform re-establishment procedures -Perform multipath re-establishment type 1 -Perform multipath re-establishment type 2 - Perform CHO procedures Send Uu RRC messages such as failure messages similar to MCGFailure or SCGFailure messages - Performing MCGFailure-like procedures For example, send an RRC error message and start a timer. If the timer expires without receiving a reconfiguration by the network, start a re-establishment message. - Performing an SCGFailure-like procedure. o For example, send an RRC error message but do not start a timer: normal operation can continue over the still-operational link. For example, the WTRU may send different RRC messages depending on whether it initiates an SCGFailure-like procedure or an MCGFailure-like procedure - Performing relay reselection procedures and possibly providing the results of the reselection to the network Perform conditional handover (CHO), HO, or CHO-like procedure: The WTRU performs a conditional handover (CHO), HO, or CHO-like procedure using a configuration provided to it, e.g., changing to a path associated with multipath. For example, a cell add received by the WTRU may initiate a 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 reporting of available / measured relays only, trigger measurement reporting of available / measured cells only, trigger measurement reporting of both measured relays and cells. o Specifically, the conditions described herein may be used to determine which measurement reports should be transmitted - Release the PC5-RRC connection Specifically, the PC5-RRC connection may be used to decide whether to maintain or release the PC5-RRC connection. -Release multi-path connections / configurations o Specifically, the conditions described herein may be used to determine whether to release a multi-path connection / configuration at the remote WTRU and rely on a single path connection Indicates the cause of the RLF (e.g., a detected SL-RLF or receipt of a Uu RLF from a relaying WTRU). In particular, the conditions herein may be used to determine whether RRC messages sent to the network include those due to a detected SL-RLF, reception of a Uu RLF, a triggered HARQ-based SL RLF, a triggered RLC-based SL RLF, a triggered T400-based, etc. - Suspending one of the paths associated with the multipath configuration (i.e., suspending all transmissions performed for bearers associated with that path)

[0115] The remote WTRU determines the message type / content / SRB type of the recovery message (e.g., RRC message) in multipath The remote WTRU may include different content in the recovery message (e.g., an MCGFailure-like message, an SCGFailure-like message), possibly over a different SRB (SRB0 or ​​SRB1), or may use a different RRC message entirely. For example, the WTRU may or may not include certain parameters in the message, subject to the terms herein. Specifically, the remote WTRU may include any one or more of the following data in such a failure message: - Carrier frequency associated with the fault path Measurements of other relay WTRUs - an indication of whether the measurement result is associated with Sidelink Discovery Reference Signal Receive Power (SD-RSRP) or Sidelink Reference Signal Receive Power (SL-RSRP), associated with measurements of other relays An indication of whether the measurement results are associated with a relay with which the remote WTRU has a PC5-RRC connection, and may be associated with measurements of other relays. An indication of whether the measurement result is associated with a relay WTRU in RRC_CONNECTED (or the state of the relay WTRU), which may be associated with measurements of other relays. -Fault type, fault indication, or similar information, which may indicate any of the following: RLF of the relay WTRU or RLF failure type of the relay WTRU (e.g., T310 expired, randomAccessProblem, etc.) SL RLF detected by remote WTRU ○HO by remote WTRU Cell reselection by remote WTRU Failure of the remote WTRU to establish an RRC connection -Indication that a failure occurred during the processing of an add / change procedure (see Reestablishment Type 2 herein)

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

[0117] Representative Procedures for Recovery Procedures and Message Content In an example embodiment, a WTRU that triggers the Uu RLF alone can determine whether to perform an MCGFailure-like or SCGFailure-like procedure over the SL path based on whether the WTRU has transmitted UL data over the relay path or has data pending for transmission over the relay path. For example, the WTRU may be configured with a threshold amount of data associated with the SL LCH with HARQ feedback enabled. If the amount of data in the buffers of all SL LCHs with HARQ feedback enabled is above a threshold, the WTRU may perform an SCGFailure-like recovery procedure. Otherwise, the WTRU may perform an MCGFailure-like recovery procedure.

[0118] In another example embodiment, a WTRU that detects an SL RLF may determine whether to perform one of an SCGFailure-like procedure, an MCGFailure-like procedure, or re-establishment based on a measured Uu RSRP, possibly associated with the last measurement reported to the network or associated with the last measurement performed at 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 that is 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 example embodiment, a WTRU that triggers an RLF on the SL path (or receives a Uu RLF indication from a relay WTRU) may decide whether to perform an SCGFailure-like procedure, an MCGFailure-like procedure, or re-establishment based on the Uu RLM / RLF monitored by the WTRU during the SL RLF. In particular, if the WTRU is performing Uu RLM / RLF, the WTRU may perform an MCGFailure-like procedure. If the WTRU is performing relaxed RLM on the Uu path, the WTRU may perform an MCGFailure-like procedure. If the WTRU is not performing Uu RLM, the WTRU may perform either an MCGFailure-like procedure or re-establishment, depending on other factors (e.g., Uu RSRP).

[0120] In another example embodiment, a WTRU that triggers RLF on one 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, and if it is a different cell, the remote WTRU can perform an MCGFailure-like procedure. In a similar example, the procedure to follow can 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, and if the RLF occurs on a path associated with a cell that is not the PCell, the WTRU can perform an SCGFailure-like procedure.

[0121] In another example embodiment, a WTRU that triggers 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 can initiate an MCGFailure-like procedure or cannot initiate a failure procedure at all (i.e., the remote WTRU does not send an RRC message to the network). If the indirect path is PC5, the remote WTRU can initiate an SCGFailure-like procedure during an SL RLF and an MCGFailure-like procedure during a Uu RLF.

[0122] In another exemplary embodiment, the WTRU may determine failure procedure steps based on the SRB configuration while in multipath. Specifically, if the WTRU detects an RLF on a link not configured to carry SRBs (e.g., the WTRU is configured with SRB1 on only one path) and an RLF is detected on a link where no SRB is configured, the remote WTRU may report a failure message to the network, suspend or release transmissions to the bearer or bearers on the failed link, and continue operation of the unfailed link. On the other hand, if the remote WTRU is configured with split SRBs and a failure occurs on the link, the remote WTRU may report the failure, suspend all transmissions, and wait for reconfiguration from the network. If a reconfiguration is not received before a timer expires, the remote WTRU may trigger reestablishment. On the other hand, if an RLF occurs on a link where the SRB is configured as non-split, the remote WTRU may trigger reestablishment.

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

[0124] In an example embodiment, the WTRU may determine the type of measurements (relay only, cell only, or both cell and relay) to include in the measurement report during a failure based on the link where the failure occurred. Specifically, if a Uu RLF is triggered, the WTRU may include only cell measurements in the error message sent over the relay path. If a SL RLF is triggered, the WTRU may include only relay measurements in the error message sent over the Uu path. When the WTRU performs re-establishment, the WTRU may include both cell and relay measurements.

[0125] In an example embodiment, a remote WTRU may be in a multipath environment and receive an HO indication from a relay WTRU, and may release the PC5-RRC connection when the HO is performed to a cell belonging to a different gNB. If the relay HO is to a cell of the same gNB, the remote WTRU may simply suspend transmission over the relayed path and / or release the relay path configuration without releasing the PC5-RRC connection.

[0126] In another example, the WTRU may determine the behavior associated with the indirect link (RRC connection) and / or the bearer associated with the indirect link based on the type of failure triggered by the message at the remote WTRU. For example, if the remote WTRU receives a Uu RLF indication from the relay WTRU, the remote WTRU may release / tear down the PC5-RRC connection and / or release the multipath configuration. On the other hand, if the remote WTRU receives an HO indication from the relay WTRU, the remote WTRU may suspend the 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 a time period for reconfiguration of the indirect link, and then release the PC5-RRC connection if no reconfiguration of the indirect link from the network is received.

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

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

[0129] In one example embodiment, a WTRU that experiences RLF on both the Uu link and the SL link may perform a re-establishment procedure.

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

[0131] Whether the WTRU filters the measurements of relays 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 during an RLF condition), measurements of potential relays may be filtered to only relays connected to the same gNB as long as the Uu RSRP is above a threshold. Otherwise, the WTRU may include all measurements. An advantage of such an embodiment is that the WTRU can provide measurements of other relays (not necessarily controlled by the same cell) only when there may be a possibility of a cell change by the network.

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

[0133] Returning to the top of FIG. 9 , on the other hand, if RLF is triggered only on the SL relay path (step 915), then flow proceeds from step 915 to step 917, where the WTRU determines whether it is currently performing RLM / RLF on the Uu path. If so, then 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, then flow proceeds from step 919 to step 921, where the WTRU performs an SCGFailure-like procedure on the Uu path. If not, then flow proceeds instead 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, then flow proceeds from step 923 to step 925, where the WTRU performs an MCGFailure-like procedure on the Uu path. If not, then flow proceeds from step 923 to step 913, where the WTRU performs a radio link re-establishment procedure.

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

[0135] Representative Procedure - MAC CE that can switch primary route and implicitly initiate RLM / RLF In one embodiment, the remote WTRU may receive a MAC CE that may start or stop RLM / RLF on a link and / or change the strength of RLF (e.g., relaxed RLM vs. normal RLM). In another embodiment, the remote WTRU may receive a MAC CE that changes the applicability of a path for transmission / reception of SRB1. Specifically, the remote WTRU may be configured with split SRBs, but may transmit / receive SRBs and / or perform RLM / RLF on only one of the paths at a given time. The other path may be configured with SRBs, but SRB transmission / reception may be disabled on that path. Upon receiving the MAC CE, the remote WTRU may enable / disable SRB reception / transmission on the path. Specifically, if split SRBs are configured, a remote WTRU with an RRC message may send the RRC message over a path with only SRBs enabled.

[0136] In another embodiment, the same MAC CE can enable / disable RLM / RLF and enable / disable / change SRB sending / receiving on the path.

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

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

[0139] In one particular embodiment of this type, the remote WTRU may apply the procedure using the RRC configuration for the new path that is already available and applied at the WTRU. Specifically, if the WTRU is operating with multipath and performs the procedure for one of the two paths, the WTRU may continue to use the configuration associated with the multipath for each of the protocol layers applicable to that path. This type of embodiment is most similar to re-establishment, where no cell / relay selection is required and no protocol layers are reset. This procedure may be referred to herein as multipath re-establishment type 1.

[0140] In another type of embodiment, the remote WTRU may apply the procedure using an RRC configuration received in a message (e.g., route change / route add) received before the procedure was triggered due to an error. Specifically, the remote WTRU may trigger the procedure as a result of a failure that occurs after receiving the RRC configuration. This type of embodiment is most similar to CHO, where the configuration is received via an RRC message and applied upon triggering a failure. This procedure may be referred to herein as multipath 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 multipath can be triggered using an RRC message using 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 for transmitting the message) was previously configured with SRB1. If configured with SRB1, the remote WTRU may send the RRC message on SRB1 (e.g., similar to an MCG / SCGFailure message). The remote WTRU may then expect a reconfiguration message. Similar to the MCGFailureInformation procedure in legacy systems, the remote WTRU may trigger reestablishment if a reconfiguration is not received within a certain period of time. If not configured with SRB1, the remote WTRU may send the RRC message on SRB0 (e.g., similar to an RRCReestablishmentRequest). The remote WTRU may wait for a response message (e.g., similar to a reestablishment message). In either case, the remote WTRU may continue transmitting on the DRB via the non-failed path and may not perform a PHY / MAC / RLC layer reset on either path. Specifically, for SRB0, data transmission can continue to be performed using the previous security key. SRB0 may use the specified configuration for sending / receiving RRC messages. Alternatively, transmission on SRB1 messages may be used, using the specified / default configuration for SRB1 instead (considering that SRB1 has not been previously configured on this path).

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

[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 performing a route addition) included a configuration for SRB1. If no configuration was provided, the WTRU may use SRB0 or ​​may send the RRC message with a default or specified configuration, but if the received message includes an SRB1 configuration, the remote WTRU may 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., the message may be similar to a complete message).

[0145] In the uplink RRC message, the remote WTRU may further indicate that the path add / modify failed and that the remote WTRU has applied the configuration provided in the path add / modify message to perform the re-establishment. The WTRU may further identify a specific configuration if there were multiple configurations that may have been provided to the WTRU.

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

[0147] A representative procedure for multipath re-establishment type 1 may be triggered as a result of an RLF on another path 1. In one embodiment, the remote WTRU may perform a multipath re-establishment Type 1 over a first path as a result of an RLF detected on a second path, the first and second paths being paths previously configured for the WTRU during multipath.

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

[0149] 10A provides an example of a multipath wireless communication in which a remote WTRU is configured with multipath and performs RLM and RLF detection on Uu depending on 1) the radio conditions on Uu and 2) the presence / amount of uplink data being transmitted to the network via the relay link (relay WTRU).

[0150] 10B , an example 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 a circuit including a transmitter, a receiver, a processor, and a 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, where the first threshold is greater than the second threshold. The WTRU may determine that uplink data is pending for a first transmission of a network entity via another WTRU (e.g., a relay WTRU), the first transmission associated with the first communication link. The WTRU may determine channel conditions for a second transmission from the network entity, the second transmission associated with the second communication link. The WTRU may perform a first radio link procedure using the first radio link configuration based on the measured channel condition being greater than the second threshold and less than the first threshold.

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

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

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

[0154] In some examples, the configuration information indicates a radio resource control (RRC) configuration, and the WTRU may use the RRC configuration for the first or second communication link before detecting the RLF. The WTRU may determine the type of radio link recovery procedure based on the channel conditions, the type of RLF, and / or pending uplink data.

[0155] conclusion While features and elements have been provided above in particular combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. The present disclosure should not be limited in terms of the specific embodiments described herein; these embodiments are intended as illustrations of various aspects. It will be apparent to those skilled in the art that many modifications and variations may be made without departing from the spirit and scope of the present invention. No element, act, or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly stated as such. Functionally equivalent methods and apparatuses within the scope of the present disclosure, in addition to those enumerated herein, 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. The present disclosure should be limited only by the terms of such claims, along with the full scope of equivalents to which such claims are entitled. It is understood that the present disclosure is not limited to any particular method or system.

[0156] The foregoing embodiments are discussed with respect to the terminology and structure of infrared-enabled devices (i.e., infrared emitters and receivers) for simplicity, however, the discussed embodiments are not limited to these systems and may also be applied to other systems that use other forms of electromagnetic waves, or non-electromagnetic waves such as acoustic waves.

[0157] It should also be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the term “video” or “image” may mean either a snapshot, a single image, and / or multiple images displayed over time. As another example, when referred to herein, the term “user equipment” and its abbreviation “UE,” “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-enabled (e.g., tetherable) device configured to have, among other things, some or all of the structure and functionality of a WTRU, (iii) a wireless-enabled and / or wired-enabled device configured to have less than all of the structure and functionality of a WTRU, or (iv) the like. Details of an exemplary WTRU that may represent any WTRU listed herein are provided herein with respect to FIGS. 1A-1D . As another example, various embodiments disclosed herein above and below are described as utilizing a head-mounted display. Those skilled in the art will recognize that devices other than head-mounted displays may be utilized and that some or all of the present disclosure and various disclosed embodiments may be modified accordingly without undue experimentation. Examples of such other devices may include drones or other devices configured to stream information to provide an adaptive reality experience.

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

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

[0160] Additionally, in the above embodiments, it should be noted that processing platforms, computing systems, controllers, and other devices include processors. These devices may include at least one central processing unit ("CPU") and memory. In accordance with the practices of those skilled in the art of computer programming, references to acts and symbolic representations of operations or instructions may be performed by various CPUs and memories. Such acts and operations or instructions may be referred to as being "executed," "executed by a computer," or "executed by a CPU."

[0161] Those skilled in the art will understand that the operations and symbolically represented operations or instructions include the manipulation of electrical signals by a CPU. The electrical system represents data bits that may cause a resulting transformation or reduction of the electrical signals, and maintains the data bits in memory locations in a memory system, thereby reconfiguring or otherwise altering the operation of the CPU and the processing of other signals. The memory locations where the data bits are maintained are physical locations that have particular 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 that other platforms and CPUs may support the provided methods.

[0162] The 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 system readable by a CPU. The computer-readable media may include cooperative or interconnected computer-readable media that reside exclusively on a processing system or that are distributed among multiple interconnected processing systems, which may be local or remote to the processing system. It should be understood that embodiments are not limited to the memories mentioned above, and that other platforms and memories may support the provided methods.

[0163] In an example embodiment, any of the operations, processes, etc. described herein may be implemented as computer-readable instructions stored on a computer-readable medium, which may be executed by a processor of a mobile, a network element, and / or any other computing device.

[0164] There is little distinction between hardware and software implementations of aspects of a system. The use of hardware or software is generally (though not always, the choice between hardware and software can be important in certain contexts) a design choice that represents a trade-off between cost and efficiency. There may be various implementations (e.g., hardware, software, and / or firmware) in which the processes and / or systems and / or other techniques described herein may be effective, and the preferred implementation may vary depending on the context in which the processes and / or systems and / or other techniques are deployed. For example, if an implementer determines that speed and accuracy are paramount, the implementer may select a primarily hardware and / or firmware implementation. If flexibility is paramount, the implementer may select a primarily software implementation. Alternatively, the implementer may select some combination of hardware, software, and / or firmware.

[0165] The foregoing detailed description has illustrated various embodiments of devices and / or processes 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 may be individually and / or collectively implemented by a wide range of hardware, software, firmware, or indeed any combination thereof. In one embodiment, some portions of the subject matter described herein may be implemented via an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a digital signal processor (DSP), and / or other integrated form. However, those skilled in the art will recognize that certain aspects of the embodiments disclosed herein may be equivalently implemented, in whole or in part, in integrated circuits, 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 practical combination thereof, and that designing circuitry and / or writing software and / or firmware code is within the skill of those skilled in the art in light of this disclosure. Additionally, those skilled in the art will understand that the subject matter mechanisms described herein may be distributed as program products in various forms, and that exemplary embodiments of the subject matter described herein apply regardless of the particular type of signal-bearing medium used to actually effect the distribution. Examples of signal bearing media include, but are not limited to, recordable media such as floppy disks, hard disk drives, CDs, DVDs, digital tape, computer memory, and transmission media such as digital and / or analog communications media (e.g., fiber optic cables, wave guides, wired communications links, wireless communications 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 use engineering techniques to integrate such described devices and / or processes into a data processing system. 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; computational entities, such as an operating system, drivers, a graphical user interface, and application programs; one or more interaction devices, such as a touchpad or screen; and / or a control system, including feedback loops 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 may be implemented utilizing any suitable commercially available components, such as those typically found in data computing / communication systems and / or network computing / communication systems.

[0167] The subject matter described herein may depict different components contained within or connected to different other components. It should be understood that such depicted architectures are merely examples, and that in fact many other architectures that achieve the same functionality may be implemented. Conceptually, any arrangement of components to achieve the same functionality is effectively “associated” such that the desired functionality may be achieved. Thus, any two components herein that combine to achieve a particular function may be considered to be “associated” with each other such that the desired functionality is achieved, regardless of the architecture or intervening components. Similarly, any two components so associated may be considered to be “operably connected” or “operably coupled” to each other to achieve the desired functionality, and any two components that can be associated in this way may also be considered to be “operably couplable” to each other to achieve the desired functionality. Examples of operably couplable include, but are not limited to, components that are physically matable and / or physically interacting, and / or components that can wirelessly interact and / or wirelessly interacting, and / or components that logically interact and / or logically interacting.

[0168] With respect to the use of virtually any plural and / or singular term herein, those skilled in the art can convert from plural to singular and / or from singular to plural as appropriate to the context and / or application. Various singular / plural permutations may be expressly set forth herein for purposes of clarity.

[0169] Those skilled in the art will understand that, in general, the terms used in this specification, and particularly in the appended claims (e.g., the body of the appended claims), are generally intended as "open" terms (e.g., the term "including" should be interpreted as "including, but not limited to," the term "having" should be interpreted as "having at least," the term "including" should be interpreted as "including, but not limited to," etc.). Furthermore, where a specific number of introduced claim recitations are intended, such intention will be explicitly stated in the claim; in the absence of such statement, those skilled in the art will understand that no such intention exists. For example, where only one item is intended, the term "single" or similar language may be used. To assist in understanding, the following appended claims and / or description of this specification may include the use of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed as meaning that the introduction of a claim recitation with the indefinite article "a" or "an" limits any particular claim that includes such an introduced claim recitation to embodiments that include only that one recitation, even if the same claim also includes the introductory phrase "one or more" or "at least one" and an indefinite article such as "a" or "an" (e.g., "a" and / or "an" should be interpreted to mean "at least one" or "one or more"). The same applies to the use of definite articles used to introduce claim recitations. Additionally, even when a specific number of introduced claim recitations is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number (e.g., the simple recitation "two recitations" without any other modifiers means at least two recitations, or more than two recitations).Furthermore, when notation similar to "such as at least one of A, B, and C" is used, such structure is generally intended as the meaning that one of ordinary skill in the art would understand the notation (e.g., "a system having at least one of A, B, and C" includes, but is not limited to, systems having A only, B only, C only, A and B together, A and C together, B and C together, and / or A, B, and C together). When notation similar to "such as at least one of A, B, or C" is used, such structure is generally intended as the meaning that one of ordinary skill in the art would understand the notation (e.g., "a system having at least one of A, B, or C" includes, but is not limited to, systems having A only, B only, C only, A and B together, A and C together, B and C together, and / or A, B, and C together). Those skilled in the art will further appreciate that, whether in the specification, claims, or drawings, any disjunctive word and / or phrase presenting two or more alternative terms should be understood to contemplate the possibility of including one of the terms, either of the terms, or both terms. For example, the phrase "A or B" is understood to include the possibilities of "A" or "B" or "A and B." Additionally, 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 plurality of," and / or "any combination of" of the items and / or categories of items, individually or in combination with other items and / or other categories of items. Furthermore, as used herein, the term "set" is intended to include any number of items, including zero. Additionally, 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 "plurality."

[0170] Additionally, where features or aspects of the disclosure are described in terms of a Markush group, those skilled in the art will recognize that the disclosure is also thereby 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 in terms of providing a written description, all ranges disclosed herein encompass any possible subranges and combinations of subranges. Any recited range can be readily recognized as fully descriptive and allowing the same range to be broken down into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each range discussed herein may be readily broken down into a lower third, middle third, upper third, etc. Also, as will be understood by those skilled in the art, all terms such as "up to," "at least," "more than," and "less than" refer to ranges that are inclusive of the recited numbers and that can subsequently be broken down into subranges, as discussed above. Finally, as will be understood by those skilled in the art, ranges include 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, the claims should not be read as limited to the provided order or to the provided elements unless specifically so stated. Additionally, the use of the term "means for" in any claim is intended to invoke 35 U.S.C. 112, paragraph 6, or means-plus-function claim format, and any claim without the term "means for" is not so intended.

[0173] Suitable processors include, by way of example, a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), an application specific standard product (ASSP), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), and / or a state machine.

[0174] The WTRU may be used in conjunction with hardware and / or software implemented modules such as, for example, a Software Defined Radio (SDR), and may also be implemented in other components such as a camera, a video camera module, a video phone, a speaker phone, a vibration device, a speaker, a microphone, a television transceiver, a hands-free headset, a keyboard, a Bluetooth® module, a frequency modulation (FM) radio unit, a Near Field Communication (NFC) module, an LCD display unit, an organic light emitting diode (OLED) display unit, a digital music player, a media player, a video game player module, an internet browser, and / or a wireless local area network (WLAN) or ultra wide band (UWB) module.

[0175] Although various embodiments have been described with respect to a communications system, it is contemplated that the system may be implemented in software on a microprocessor / general purpose computer (not shown). In particular embodiments, one or more of the functions of the various components may be implemented in software controlling a general purpose computer.

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

Claims

1. 1. A method implemented in a first wireless transmit / receive unit (WTRU) for wireless communication, comprising: receiving configuration information indicating 1) a first radio link configuration and a second radio link configuration, and 2) a first threshold and a second threshold, the first threshold being 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 being associated with a first communications link; determining channel conditions of a second transmission from the network entity, the second transmission being associated with a second communication link; and and performing a first radio link procedure using the first radio link configuration based on the measured channel condition being greater than the second threshold and less than the first threshold.

2. 10. The method of claim 1, further comprising: performing a radio link failure (RLF) detection procedure on the first communications link based on the measurement of the channel conditions being greater than the first threshold.

3. 10. The method of claim 1, further comprising: performing a second radio link procedure using the second radio link configuration based on the measured value of the channel conditions being less than the second threshold.

4. 4. The method of claim 1, wherein the first radio link procedure comprises radio link failure (RLF) detection, radio link monitoring (RLM), and / or radio link recovery on the second communication link.

5. The method of any one of claims 1 to 4, wherein the second radio link procedure includes radio link failure (RLF) detection, radio link monitoring (RLM), and / or radio link recovery on the second communication link.

6. The method of any one of claims 1 to 5, wherein the first threshold and the second threshold each are for comparing the channel conditions associated with the second communication link.

7. The method of any one of claims 1 to 6, wherein the channel conditions include a reference signal received power (RSRP) of the second transmission.

8. The method of any one of claims 1 to 7, wherein the measurements of the channel conditions include a measured Reference Signal Received Power (RSRP) value of the second transmission.

9. The method of any one of claims 1 to 8, wherein the first communication link is a side link (SL) relay path for communicating with the network entity via the second WTRU.

10. The method according to any one of claims 1 to 9, wherein the second communication link is a Uu path for communicating with the network entity.

11. 2. The method of claim 1, wherein the configuration information indicates a radio resource control (RRC) configuration, and the method further comprises using the RRC configuration for the first or second communication link before detecting an RLF.

12. The method of claim 1 , further comprising determining a type of radio link recovery procedure based on the channel conditions, a type of RLF, and / or the uplink data pending transmission.

13. A first wireless transmit / receive unit (WTRU) for wireless communication, comprising: a circuit including a transmitter, a receiver, a processor, and a memory; receiving configuration information indicating 1) a first radio link configuration and a second radio link configuration, and 2) a first threshold and a second threshold, the first threshold being 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 being associated with the first communications link; determining channel conditions of a second transmission from the network entity, the second transmission being associated with a second communication link; a first wireless transmit / receive unit (WTRU) for wireless communication configured to perform a first radio link procedure using the first radio link configuration based on the channel condition measurement being greater than the second threshold and less than the first threshold;

14. 14. The WTRU of claim 13, wherein the WTRU is further configured to perform a radio link failure (RLF) detection procedure on the first communications link based on the measurement of the channel conditions being greater than the first threshold.

15. 14. The WTRU of claim 13, wherein the WTRU is further configured to perform a second radio link procedure using the second radio link configuration based on the measured value of the channel condition being less than the second threshold.

16. The WTRU of any one of claims 13 to 15, wherein the first radio link procedure includes radio link failure (RLF) detection, radio link monitoring (RLM), and / or radio link recovery on the second communications link.

17. The WTRU of any one of claims 13 to 15, wherein the second radio link procedure includes radio link failure (RLF) detection, radio link monitoring (RLM), and / or radio link recovery on the second communications link.

18. The WTRU of any one of claims 13 to 17, wherein each of the first and second thresholds is for comparing the channel conditions associated with the second communications link.

19. The WTRU of any one of claims 13 to 18, wherein the channel conditions include a reference signal received power (RSRP) of the second transmission.

20. The WTRU of any one of claims 13 to 19, wherein the measurements of the channel conditions include a measured reference signal received power (RSRP) value of the second transmission.

21. The WTRU of any one of claims 13 to 20, wherein the first communication link is a side link (SL) relay path for communicating with the network entity via the second WTRU.

22. The WTRU of any one of claims 13 to 20, wherein the second communication link is a Uu path for communicating with the network entity.

23. The WTRU of any one of claims 13 to 22, wherein the configuration information indicates a radio resource control (RRC) configuration, and the WTRU is further configured to use the RRC configuration for the first or second communication link before detecting an RLF.

24. The WTRU of any one of claims 13 to 23, wherein the WTRU is further configured to determine a type of radio link recovery procedure based on the channel conditions, the type of RLF, and / or the uplink data waiting to be transmitted.

Images