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

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 a first radio link configuration and a second radio link configuration and a first threshold and a second threshold, where the first threshold is greater than the second threshold; determining that the uplink data is pending for transmission on a first transmission to the network entity via the second WTRU, wherein the first transmission is associated with the first communication link; determining a channel condition of a second transmission from the network entity, wherein the second transmission is associated with a second communication link; and performing a first radio link procedure using the first radio link configuration based on the measurement of the channel condition being greater than the second threshold and less than the first threshold.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to and the benefit of U.S. Provisional Application No. 63 / 394,783, filed in the U.S. Patent and Trademark Office on August 3, 2022, and U.S. Provisional 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 as if fully set forth below for all available purposes. Technical Field

[0003] 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 wireless transmit / receive units having dual connectivity to a network via a direct network connection (e.g., directly connected to a network entity) and / or connected to the network through a relay wireless transmit / receive unit. Summary of the invention

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

[0005] In one embodiment, a method for wireless communication implemented by a WTRU 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, wherein the first threshold is greater than the second threshold; determining that uplink data is pending for transmission on a first transmission to a network entity via a second WTRU, wherein the first transmission is associated with a first communication link; determining a channel condition for a second transmission from the network entity, wherein the second transmission is associated with a second communication link; and based on a measurement of the channel condition being greater than the second threshold and less than the first threshold, performing a first radio link process using the first radio link configuration.

[0006] In one embodiment, a WTRU for wireless communication includes a circuit comprising a transmitter, a receiver, a processor and a memory, the WTRU being configured to: receive configuration information indicating 1) a first radio link configuration and a second radio link configuration and 2) a first threshold and a second threshold, wherein the first threshold is greater than the second threshold; determine that uplink data is pending for transmission on a first transmission to a network entity via a second WTRU, wherein the first transmission is associated with a first communication link; determine a channel condition for a second transmission from the network entity, wherein the second transmission is associated with a second communication link; and based on a measurement of the channel condition being greater than the second threshold and less than the first threshold, perform a first radio link process using the first radio link configuration. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] A more detailed understanding can be obtained from the following detailed description, which is given by way of example in conjunction with its accompanying drawings. As with the detailed description, the figures in such drawings are exemplary. Therefore, the drawings and detailed description should not be considered limiting, and other equally effective examples are possible and expected. In addition, like reference numerals ("ref.") in the accompanying drawings ("Figures") indicate similar elements, and wherein:

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

[0009] Figure 1B is an example of an embodiment in which Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within an illustrated communication system;

[0010] Figure 1C is an example of an embodiment that can be used according to one or more embodiments Figure 1A A system diagram of an example Radio Access Network (RAN) and an example Core Network (CN) used within the illustrated communication system;

[0011] Figure 1D is an example of an embodiment that can be used according to one or more embodiments Figure 1A A system diagram of another example RAN and another example CN used within the illustrated communication system;

[0012] Figure 2 is a diagram showing a protocol view of a split bearer in dual connectivity;

[0013] Figure 3 is a diagram showing an RLC configuration in dual connectivity when data repetition is employed;

[0014] Figure 4 is a diagram illustrating a protocol stack of a user plane of an L2 U2N relay architecture;

[0015] Figure 5 is a diagram illustrating a protocol stack of a control plane of an L2 U2N relay architecture;

[0016] Figure 6 is a diagram illustrating a multipath model at the protocol stack level for a WTRU in dual connectivity, where both connection paths go to the same cell;

[0017] Figure 7 is a diagram illustrating a multipath model at the protocol stack level for a WTRU in dual connectivity, where the two connection paths pass through different cells;

[0018] Figure 8 is a flow chart illustrating RLM / RLF processing for a dual connected WTRU according to one or more embodiments;

[0019] Fig. 9 is a flow chart illustrating a radio link reestablishment for a dual connected WTRU according to one or more embodiments;

[0020] Fig. 10A is a diagram illustrating an example of multipath wireless communication according to one or more embodiments; and

[0021] Fig. 10B is a flow chart illustrating an example process for RLM and / or RLF detection in multipath communications according to one or more embodiments. DETAILED DESCRIPTION

[0022] introduction

[0023] In the following specific embodiments, many specific details are set forth to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it should be understood that such embodiments and examples can be practiced without some or all of the specific details set forth herein. In other cases, well-known methods, procedures, components, and circuits are not described in detail to avoid blurring the following description. In addition, embodiments and examples not specifically described herein can be practiced in place of embodiments and other examples explicitly, implicitly, and / or inherently described, disclosed, or otherwise provided (collectively referred to as "provided") herein, or practiced in combination with these embodiments and examples.

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

[0025] Example Communication System

[0026] The methods, devices, and systems provided herein are well suited for communications involving both wired and wireless networks. Wired networks are well known. Figures 1A to 1D An overview of various types of wireless devices and infrastructure is provided, wherein various elements of the network can utilize the methods, apparatuses, and systems provided herein, perform the methods, apparatuses, and systems provided herein, be arranged according to the methods, apparatuses, and systems provided herein, and / or be adapted and / or configured for the methods, apparatuses, and systems provided herein.

[0027] Figure 1A 1 is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content 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, and filter bank multi-carrier (FBMC), etc.

[0028] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, Internet 110 and other networks 112, but it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the UE 102a, 102b, 102c, 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to send and / or receive wireless signals and may include a user equipment (WTRU), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, 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, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated process chain environment), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

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

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

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

[0032] More specifically, as noted above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA. For example, the base station 114a in the RAN 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 use Wideband CDMA (WCDMA) to establish the air interface 116. WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink Packet Access (HSDPA) and / or High Speed ​​Uplink Packet Access (HSUPA).

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

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

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

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

[0037] Figure 1AThe base station 114b in 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 local areas such as commercial venues, homes, vehicles, campuses, industrial facilities, sky corridors (e.g., for use by drones), and roads. 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 an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology (such as IEEE 802.15) to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or a femtocell. As Figure 1A As shown, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106 / 115.

[0038] The RAN 104 / 113 may be in communication with the CN 106 / 115, which may be any type of network configured to provide voice, data, applications and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, 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 described in detail in the text and video, the CN 106 / 115 may be configured to provide voice, data, applications and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, 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. Figure 1A Although not shown in the figure, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

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

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

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

[0042] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC) and state machine, etc. The processor 118 may perform signal decoding, 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. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it is understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

[0044] Although the transmit / receive element 122 Figure 1B Although depicted as a single element in the figure, 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.

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

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

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

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

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

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

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

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

[0053] Each of the evolved Node Bs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in uplink (UL) and / or downlink (DL), etc. Figure 1C As shown, the eNode-Bs 160a, 160b, 160c may communicate with each other via an X2 interface.

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

[0055] The MME 162 may be connected to each of the evolved Node-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, and selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c. 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.

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

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

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

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

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

[0061] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for a BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or out of the BSS. Traffic originating from outside the BSS and destined for the STA may be reached by the AP and may be delivered to the STA. Traffic originating from the STA and destined for a target outside the BSS may be transmitted to the AP to be delivered to the corresponding target. Traffic between STAs within the BSS may be transmitted by the AP, for example, wherein the source STA may transmit traffic to the AP, and the AP may deliver traffic to the target STA. Traffic between STAs within the BSS may be considered and / or referred to as point-to-point traffic. Point-to-point traffic may be transmitted between the source STA and the target STA (e.g., directly between them) using a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (eg, all STAs in the STA) may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad hoc" communication mode.

[0062] When using the 802.11ac infrastructure operation mode or a similar operation mode, the AP may send 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 dynamically set via signaling. The primary channel may be an operating channel of the BSS and may be used by the STA to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access / collision avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. For CSMA / CA, a STA (e.g., each STA) (including the AP) may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0063] A high throughput (HT) STA may communicate using a 40 MHz wide channel (eg, via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels) to form a 40 MHz wide channel.

[0064] Very high throughput (VHT) STA can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz channels and / or 80MHz channels can be formed by combining continuous 20MHz channels. 160MHz channels can be formed by combining 8 continuous 20MHz channels, or by combining two non-continuous 80MHz channels (this can be called 80+80 configuration). For 80+80 configuration, after channel coding, the data can pass through a segment parser that can divide the data into two streams. Each stream can be processed by inverse fast Fourier transform (IFFT) and time domain processing separately. These streams can be mapped to two 80MHz channels, and the data can be sent by sending STA. At the receiver of the receiving STA, the above-mentioned operation for 80+80 configuration can be reversed, and the combined data can be transmitted to the medium access control (MAC).

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

[0066] WLAN systems that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include channels that can be designated as primary channels. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA (which supports the minimum bandwidth operating mode) from all STAs operating in the BSS. In the example of 802.11ah, for STAs (e.g., MTC-type devices) that support (e.g., only support) a 1MHz mode, the primary channel may be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy, for example, because a STA (supporting only a 1MHz operating mode) is sending to the AP, the entire available band may be considered busy even if most of the band remains idle and may be available.

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

[0068] Figure 1D 1 is a system diagram illustrating the RAN 113 and the CN 115 in accordance with an embodiment. As noted above, the RAN 113 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.

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

[0070] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with parameter sets that may be scalable. For example, 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 transmit time intervals (TTIs) of varying or scalable lengths (e.g., containing different numbers of OFDM symbols and / or varying absolute time lengths over time).

[0071] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c while not accessing other RANs (e.g., such as the eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with the gNB 180a, 180b, 180c while also communicating / connecting with another RAN, such as the eNodeB 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement the DC principle 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 eNodeB 160a, 160b, 160c may act as a mobility anchor for the WTRUs 102a, 102b, 102c, and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

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

[0073] Figure 1DThe illustrated CN 115 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possible data networks (DNs) 185a, 185b. Although each of the foregoing elements is depicted as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0074] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, support of network slicing (e.g., handling of different PDU sessions with different requirements), selecting a specific SMF 183a, 183b, management of registration areas, termination of NAS signaling, mobility management, etc. The AMF 182a, 182b may use network slicing in order to customize CN support for the WTRU 102a, 102b, 102c based on the type of services utilized by the WTRU 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced mobile broadband (eMBB) access, and / or services for machine type communication (MTC) access, etc. The AMF a82a, 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-APro, and / or non-3GPP access technologies, such as WiFi.

[0075] The SMF 183a, 183b may be connected to the AMF 182a, 182b in the CN 115 via the N11 interface. The SMF 183a, 183b may also be connected to the UPF 184a, 184b in the CN 115 via the N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b, and configure traffic routing through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions such as managing and allocating UE IP addresses, 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.

[0076] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the 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 UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring, etc.

[0077] The CN 115 may facilitate communications with other networks. For example, the CN 115 may include or may 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. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired networks 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 via the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and the N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0078] Given that Figures 1A to 1D as well as Figures 1A to 1D Corresponding to the description of the present invention, one or more or all of the functions described herein with respect to one or more of the following items may be performed by one or more simulation devices (not shown): WTRU 102a-102d, base station 114a-114b, evolved Node B 160a-160c, MME 162, SGW 164, PGW 166, gNB 180a-180c, AMF 182a-182b, UPF 184a-184b, SMF 183a-183b, DN 185a-185b and / or any other device described herein. The simulation device may be one or more devices configured to mimic one or more or all of the functions described herein. For example, the simulation device may be used to test other devices and / or simulate network and / or WTRU functions.

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

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

[0081] Dual Connection

[0082] Split bearer in dual connectivity

[0083] In Dual Connectivity (DC), the WTRU is served by two nodes, each node comprising a set of cells referred to as a Master Cell Group (MCG) and a Secondary Cell Group (SCG), respectively. A bearer may be associated with only an MCG or with an SCG, or it may be configured as a split bearer. Figure 2 A protocol view of a split bearer is shown where gNB 1 is in the MCG and gNB 2 is in the SCG.

[0084] Like any bearer, the WTRU will have one Packet Data Convergence Protocol (PDCP) entity associated with it, and the peer PDCP entity on the network side terminates at one of the gNBs (primary gNB or secondary gNB). In the downlink (DL), the core network (CN) transmits data to the gNB where the PDCP terminates (described above). Figure 2 The PDCP PDU is forwarded to gNB1 in the WTRU, and the network decides whether to transmit the data directly to the WTRU via the link between the gNB and the WTRU, or to forward the PDCP PDU to gNB2 (e.g., via the Xn interface), and gNB2 will transmit the data to the WTRU via the link between itself and the WTRU.

[0085] 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 value called the UL split buffer threshold is also configured. If the UL buffer size for the bearer is less than the threshold, the PDCP will push data only to the Radio Link Control (RLC) associated with the primary path. However, if the buffer size becomes greater than the threshold, the WTRU may push data to either path (i.e., left to the WTRU implementation).

[0086] Group Repeat

[0087] Data repetition is a technology used in fifth generation cellular systems for ultra-reliable low latency communications (URLLC). Data repetition requires the use of multiple radio links, each of which transfers the same data between the terminal and the network to improve transmission reliability.

[0088] When repetition is configured for a radio bearer via RRC, at least one secondary RLC entity is added to the radio bearer to handle repeated PDCP packet data units (PDUs), such as Figure 3 As depicted in , 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 the repetition have the same RLC mode. Therefore, repetition in PDCP includes submitting the same PDCP PDU multiple times: once to each activated RLC entity of the radio bearer. The PDCP control PDU may not be repeated and may always be submitted to the primary RLC entity. Packet repetition therefore increases reliability and reduces latency by utilizing multiple independent transmission paths, and is particularly beneficial for URLLC services.

[0089] When repetition is configured for a Data Radio Bearer (DRB), the Radio Resource Control (RRC) also sets the state (activate or deactivate) of the PDCP repetition upon (re)configuration. After configuration, the PDCP repetition state can then be dynamically controlled with the help of the Medium Access Control (MAC) Control Element (CE), and in DC, the WTRU applies the MAC CE commands regardless of their source (MCG or SCG).

[0090] When repetition is configured for a signaling radio bearer (SRB), the state of the PDCP repetition is always active and cannot be dynamically controlled. When repetition is configured for a DRB with more than one secondary RLC entity, the RRC also sets the state of each of these secondary RLC entities (i.e., activated or deactivated). Subsequently, the MAC CE can be used to dynamically control whether each configured secondary RLC entity for the DRB should be activated or deactivated (i.e., which RLC entities should be used for repeated transmission). The primary RLC entity cannot be deactivated. DRB When repetition is deactivated for a DRB, all secondary RLC entities associated with the DRB are deactivated. When a secondary RLC entity is deactivated, it will not be rebuilt, the HARQ buffer will not be refreshed, and the sending PDCP entity should instruct the secondary RLC entity to discard all duplicate PDCP PDUs.

[0091] When repetition is activated for DRB, the network ensures that at least one serving cell is activated for each logical channel associated with the activated RLC entity of the DRB; and when deactivation of the SCell does not leave a serving cell activated for the logical channel of the DRB, the network should ensure that repetition is also deactivated for the RLC entity associated with the logical channel.

[0092] When repetition is activated, the original PDCP PDU and the corresponding repetition shall not be sent on the same carrier.The logical channels configured with repeated radio bearers may belong to the same MAC entity (referred to as CA repetition) or to different MAC entities (referred to as DC repetition).

[0093] When repetition on more than two RLC entities is configured for a radio bearer, CA repetition can also be configured in either or both of the MAC entities together with DC repetition. In CA repetition, logical channel mapping restrictions are used in the MAC entity to ensure that different logical channels of the radio bearers in the MAC entity are not sent on the same carrier. When CA repetition is configured for an SRB, one of the logical channels associated with the SRB is mapped to the SpCell.

[0094] When CA repetition is deactivated for DRB in the MAC entity (i.e., none or only one of the RLC entities of the DRB in the MAC entity remains activated), the logical channel mapping restriction of the logical channel of the DRB is lifted as long as CA repetition remains deactivated for the DRB in the MAC entity.

[0095] When the RLC entity confirms the transmission of the PDCP PDU, the PDCP entity shall indicate to other RLC entities to discard the PDCP PDU. In addition, in case of CA repetition, when the RLC entity limited to the SCell reaches the maximum number of retransmissions of the PDCP PDU, the WTRU notifies the gNB but does not trigger a Radio Link Failure (RLF).

[0096] RLF and recovery in Uu

[0097] RLF is monitored by the WTRU on the PCell in a single connection. RLF is triggered when the T310 timer (started after multiple consecutive out-of-sync indications from lower layers) expires. On detection of RLF, the WTRU triggers a re-establishment. If the WTRU is configured with conditional handover (CHO) and the cell selection performed after RLF results in a CHO candidate, the WTRU performs a CHO to the CHO candidate cell instead of the previous cell.

[0098] For a WTRU in 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 for the MCG and SCG respectively.

[0099] If RLF is detected for the MCG and fast MCG link recovery is configured, the WTRU triggers fast MCG link recovery. Otherwise, the WTRU performs the RRC connection reestablishment procedure. During fast MCG link recovery, the WTRU suspends MCG transmission for all radio bearers and reports the failure to the master node (MN) via the SCG via the MCG Failure Information message using the SCG branch that splits SRB1 or SRB3.

[0100] The WTRU includes in the MCG Failure Information message the measurements 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) (the node associated with the SCG). Once the fast MCG link recovery is triggered, the WTRU maintains the current measurement configuration from both the MN and the SN, and continues the measurements based on the configuration from the MN and the SN if possible. If the WTRU does not receive an RRC Reconfiguration message, a MobilityFromNRCommand message, a MobilityFromEUTRACommand message, or an RRC Release message within a certain time period after initiating the fast MCG link recovery, the WTRU initiates the RRC connection reestablishment procedure.

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

[0102] SCG In case of SCG failure, if MCG transmission for radio bearers is not suspended, the WTRU suspends SCG transmission for all radio bearers and reports SCG failure information to the MN instead of triggering reestablishment. If SCG failure is detected while MCG transmission for all radio bearers is suspended, the WTRU initiates the RRC connection reestablishment procedure.

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

[0104] The WTRU includes in the SCG Failure Information message the measurement results available according to the current measurement configuration of both the MN and the SN.

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

[0106] Relay in wireless communication network

[0107] 3GPP Release 17 has specified SL-based UE-to-network relay. Sidelink relay is introduced to support 5G ProSe UE-to-network relay (U2N relay) functionality to provide connectivity to the network for U2N remote WTRUs. Both L2 and L3 U2N relay architectures are supported. Except for controlling the sidelink resources, the L3 U2N relay architecture is transparent to the serving RAN of the U2N relay WTRU.

[0108] A U2N relay WTRU should be in the RRC_CONNECTED state to perform relay of unicast data.

[0109] 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 transmission / reception of relayed unicast data; and 2) The U2N relay WTRU may be in the RRC_IDLE, RRC_INACTIVE or RRC_CONNECTED state as long as all U2N remote WTRUs connected to the U2N relay WTRU are in the RRC_INACTIVE or RRC_IDLE state. For L2 U2N relay, the U2N remote WTRU may be configured to use resource allocation mode 2 only for data to be relayed.

[0110] 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 and the traffic of the U2N relay WTRU via a given U2N relay WTRU should be separated in different Uu RLC channels over Uu.

[0111] L2 U2N Relay Protocol Architecture

[0112] The protocol stacks for the user plane and control plane of the L2 U2N relay architecture are respectively Figure 4 and Figure 5 The Sidelink Relay Adaptation Protocol (SRAP) sublayer is placed above the RLC sublayer for both the control plane (CP) and the user plane (UP) at both the PC5 interface and the Uu interface. The Uu Service Data Adaptation Protocol (SDAP), PDCP, and RRC terminate between the L2 U2N Remote WTRU and the gNB, while the SRAP, RLC, MAC, and PHY (Physical) terminate in 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).

[0113] For L2 U2N relay, the SRAP sublayer on the PC5 hop is used only for bearer mapping purposes. For relaying messages for L2 U2N remote WTRUs on the Broadcast Control Channel (BCCH) and / or the Paging Control Channel (PCCH), the SRAP sublayer is not present on the PC5 hop. For messages for L2 U2N remote WTRUs on SRB0, the SRAP sublayer is not present on the PC5 hop, but is present on the Uu hop for both DL and UL.

[0114] For L2 U2N relay, for uplink:

[0115] - 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 may be multiplexed on the same Uu relay RLC channel;

[0116] - The Uu SRAP sublayer supports L2 U2N Remote WTRU identification for UL traffic. The identification information of the L2U2N Remote WTRU Uu radio bearer and the local Remote WTRU ID are included in the Uu SRAP header at UL so that the gNB can associate the received packets for a specific PDCP entity associated with the correct Remote WTRU Uu radio bearer of the Remote WTRU;

[0117] - The PC5 SRAP sublayer at the L2 U2N remote WTRU supports UL bearer mapping between the remote WTRU Uu radio bearers and the egress PC5 relay RLC channels.

[0118] For L2 U2N relay, for downlink:

[0119] - The Uu SRAP sublayer supports DL bearer mapping at the gNB to map the end-to-end radio bearers (SRBs, DRBs) of the remote WTRU into the Uu relay RLC channel over the relay WTRU Uu interface. The Uu SRAP sublayer supports DL bearer mapping and data multiplexing between multiple end-to-end radio bearers (SRBs or DRBs) of L2 U2N remote WTRUs and / or different L2 U2N remote WTRUs and one Uu relay RLC channel over the relay WTRU Uu interface;

[0120] - The Uu SRAP sublayer supports remote WTRU identification for DL ​​traffic. The identification information of the remote WTRU Uu radio bearer and the local remote WTRU ID are included in the Uu SRAP header by the gNB at the DL so that the relay WTRU maps packets received from the remote WTRU Uu radio bearer to its associated PC5 relay RLC channel;

[0121] - The PC5 SRAP sublayer at the relay WTRU supports DL bearer mapping between the ingress Uu relay RLC channel and the egress PC5 relay RLC channel;

[0122] - The PC5 SRAP sublayer at the remote WTRU associates the received packets with a specific PDCP entity associated with the correct Uu radio bearer of the remote WTRU based on the identification information included in the Uu SRAP header.

[0123] The Local Remote WTRU ID is included in the PC5 SRAP header and the Uu SRAP header. The L2U2N relay WTRU is configured by the gNB with the Local Remote WTRU ID to be 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. In both the PC5 hop and the Uu hop, the Uu DRBs and Uu SRBs are mapped to different PC5 relay RLC channels and Uu relay RLC channels.

[0124] The gNB is responsible for avoiding conflicts in the use of the Local Remote WTRU ID. The gNB may update the Local Remote WTRU ID by transmitting 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.

[0125] Scheduling in the sidelink

[0126] The sidelink supports two scheduling modes: Mode 1 and Mode 2. For a WTRU within coverage, the gNB can control whether the WTRU uses Mode 1 or Mode 2 for transmission.

[0127] In Mode 1 scheduling, which is available for sidelink WTRUs in RRC_CONNECTED state, the WTRU receives a SL grant directly from the network in the downlink control information (DCI). In this case, the WTRU reports the buffer status of SL data grouped by destination index (where the destination index corresponds to a unique L2 destination ID, or a source / destination L2 ID pair). If a SL grant is not available for the transmission of pending data, the WTRU may send a SL Scheduling Request (SR).

[0128] In Mode 2 scheduling, which can 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 from which it performs autonomous resource selection and scheduling. The resources are selected by the WTRU based on information (i.e., sensing results) in previous Sidelink Control Information (SCI) transmissions of other WTRUs.

[0129] Multipath Operation

[0130] Release 17 of the 3GPPP specification has introduced Layer 2 WTRUs to network relays. The main use case considered is the case where the remote WTRU is out of coverage. However, in Release 18, the specification of multipath is expected. In multipath, it is assumed that the remote WTRU is within the coverage area, and therefore the remote WTRU can utilize the Uu path, the SL (relay) path, or both. The description of the multipath operation of Rel 18 is as follows [2]:

[0131] Study the benefits and potential solutions of multipath support to enhance reliability and throughput (e.g., by switching or utilizing multiple paths simultaneously) in the following scenarios [RAN2, RAN3]:

[0132] A. The WTRU uses one direct path and one indirect path to connect to the same gNB via 1) Layer 2 WTRU to network relay or 2) via another WTRU (where WTRU-WTRU interconnection is assumed to be ideal), where the solution for 1) will be reused for 2) without excluding the possibility of excluding parts of the solution that are not necessary for the operation of 2).

[0133] 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. Additionally, if Mode 1 is selected for scheduling of the SL between the remote WTRU and the relay WTRU, scheduling of all links (e.g., 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 if Mode 2 is used and the resource pools are pre-configured by the gNB for the SLs that the remote WTRU can use autonomously, the gNB is still the gNB that decides the resource pool configuration and therefore has control over the scheduling on the SL (even if it is not in real time as in the case of Mode 1).

[0134] From a protocol architecture perspective, multipath can be modeled similar to DC in that different MAC entities are used for the Uu link and the SL, and the same PDCP entity is configured for a given bearer using multipath (e.g., split bearer). However, if the same gNB is serving the cells for both Uu and SL, this case can be considered similar to that of CA (carrier aggregation). However, in CA, one MAC entity is utilized, which is not the case in practice. Even more complicated, Uu and SL can be served by the same cell of a given gNB (i.e., not even CA).

[0135] Figure 6 and Figure 7 An example of how to model multipath at the protocol level is illustrated. Figure 6 illustrates multipath in the same cell, and Figure 7 An example of multipath to two different cells is illustrated.

[0136] RLF Failure and Recovery in Multipath Side Links

[0137] 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 concept of a master node and both paths terminate in the same node of the network. As a result, monitoring the radio links on both paths simultaneously at the remote WTRU may be unnecessary and may result in unnecessary power consumption. The link that the WTRU should monitor for RLF should also be synchronized with the link that 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 a connection via only a single path is required).

[0138] For the case of multipath where one of the paths is relayed via SL, RLF is detected based on HARQ feedback instead of normal RLM. This mechanism for RLF detection may not be very reliable, especially when the amount of data transmitted via the SL path is limited.

[0139] Finally, assuming that no master node exists, recovery operations for multipathing may also depend on the above factors and need to be defined for multipathing in a different way for DC.

[0140] Multipath Communication

[0141] In the embodiments discussed herein, a remote WTRU in multipath refers to a WTRU that is connected to the network via two different paths (a direct Uu path and a path via a SL WTRU to a network relay). The connections via the two paths may be to the same gNB / scheduler (i.e., the remote WTRU and the relay WTRU are controlled by the same gNB) or to different gNBs / schedulers (i.e., the remote WTRU and the relay WTRU are controlled by different gNBs). However, the embodiments discussed herein may equally apply to multiple paths (more than one path), or to situations where two or more paths via a SL WTRU to a network relay WTRU are maintained by the remote WTRU.

[0142] Representative procedures for the WTRU to identify an inter-gNB change performed by a relay WTRU

[0143] Method for determining whether cells belong to the same / different gNB

[0144] The implementations herein for RLM / RLF may depend on knowledge at the WTRU of whether the 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 different gNBs. Depending on whether the cells are associated with the same gNB or with different gNBs, the remote WTRU may perform different procedures described herein. Such information may be determined using any of the following solutions:

[0145] -Cell List:

[0146] o For example, the network may provide a cell list associated with a particular cell (e.g., a cell of the direct path). If another cell is in this cell list, the remote WTRU determines that the cell is part of the same gNB as the particular cell

[0147] -Identifier broadcast / sent by the cell

[0148] o For example, a cell may send (e.g., in a system information block (SIB) or through dedicated RRC signaling) an identity that is used to determine whether two different cells are associated with the same gNB. For example, if the cells send the same identity, the WTRU may assume that they are part of the same gNB

[0149] - Explicitly as part of a procedure initiated by the network (eg handover (HO), reconfiguration, etc.).

[0150] ○ For example, a remote WTRU may be connected in a multipath manner via 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 a HO command from the network and may notify the remote WTRU of the command. 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:

[0151] ■The relay WTRU may receive an indication in the HO command to be forwarded to the remote WTRU in a notification message. Specifically, if the indication is transmitted (e.g., a flag is set to true), such a HO may represent an inter-gNB HO at the relay WTRU.

[0152] ■ The relay WTRU may include an indication or flag in the notification message to the remote WTRU

[0153] ■Remote WTRU,

[0154] ● upon receiving a HO notification indicating that the source cell and the target cell are associated with different gNBs, procedures associated with inter-gNB HO (as described herein) may be performed,

[0155] ● Upon receiving a HO notification that does not indicate that the source cell and the target cell are associated with different gNBs, the procedures associated with intra-gNB HO (as described herein) may be performed (i.e., the indirect path and the direct path are associated with the same gNB)

[0156] Representative process of RLM / RLF in multipath

[0157] A remote WTRU in a multipath determines the path on which to monitor for RLM / RLF

[0158] In one solution, the remote WTRU may determine which path to perform RLM / RLF on based on one or more of the following factors or any combination thereof. Although not explicitly mentioned in the examples below, similar factors may be used to determine the attributes of the RLM / RLF performed, which may include the configuration used (e.g., whether a first set of parameters, timers, constants, etc. associated with the RLM / RLF determination or a second set of parameters are used) and / or the strength (normal RLM or relaxed RLM is used) and / or other aspects of the RLM / RLF. In addition, the remote WTRU may determine whether / how to perform RLM / RLF on one path (e.g., direct or indirect) based on conditions associated with another path (indirect or direct), where such conditions are described in the following factors. 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, the first condition may be used to determine the second condition to be used in the determination. Specifically, these factors may include:

[0159] -Measurement of Uu path quality:

[0160] o For example, if the RSRP measured on the Uu path is below a threshold, the WTRU may perform RLM / RLF on the Uu path, and if the RSRP measured on the Uu path is above a threshold, the WTRU may stop performing RLM / RLF on the Uu path. The motivation for this approach is that if the WTRU can assume that there is a SL path that can be relied upon, then the WTRU may assume that RLM / RLF on the Uu path is unnecessary when the Uu link has good path quality.

[0161] ■For example, (1) if the RSRP measured on the Uu path is lower than a first threshold, the WTRU may perform RLM / RLF on the Uu path, (2) if the RSRP measured on the Uu path is between the first threshold and the second threshold, the WTRU may perform relaxed RLM / RLF on the Uu path, and (3) if the RSRP measured on the Uu path is higher than the second threshold, the WTRU may not perform any RLM / RLF.

[0162] ■ For example, if the RSRP measured on the Uu path is above a threshold, the WTRU may perform RLM / RLF on the Uu path, and may perform RLF on the relay path only if the RSRP measured on the Uu path is below a threshold. These two thresholds may be the same threshold or different thresholds. The motivation for this approach is that for large Uu RSRP, the network may send RRC signaling on the Uu path, and the WTRU should monitor for RLF based on the Uu path only.

[0163] -Measurement of SL path quality

[0164] o For example, if the SL quality (e.g., SL RSRP) is above / below a threshold, the WTRU may perform RLM / RLF on the Uu path

[0165] ■ For example, a combination of Uu and SL quality criteria may be considered to determine on which link to perform RLF. For example:

[0166] ● If the SL RSRP is above a threshold, and the Uu RSRP is above a threshold, the WTRU may perform RLF on the SL path only. 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 this approach is that the WTRU may turn off Uu RLM monitoring if it is ensured that the WTRU has a good enough SL link as a backup.

[0167] • 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 (as determined by the WTRU or configured by the network). Otherwise, the WTRU may perform RLF on both paths.

[0168] • 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, the WTRU may perform RLF on one link (determined by the WTRU or configured by the network).

[0169] -SL specific measurements such as CBR

[0170] o For example, if the SL channel busy ratio (CBR) is above a threshold, the WTRU may perform RLM / RLF on the Uu path. The advantage of this approach is that in the presence of congestion on the SL, regardless of whether the Uu RSRP is good or not, the Uu RLM is maintained.

[0171] - The presence or amount of UL data transmitted in the SL path or in the Uu path

[0172] o This can be measured based on the amount of data routed by the Packet Data Protocol (PDP), the amount of data in the WTRU's SL RLC buffer, or the Channel Occupancy (CR) measured on the sidelink

[0173] o For example, if the SL CR is above a threshold, the WTRU may perform RLM / RLF on the Uu path. The advantage of this approach is that the WTRU may ensure that there is enough data transmitted by the WTRU via the SL path to ensure a reliable HARQ-based RLF mechanism to monitor the multipath links.

[0174] o For example, if the WTRU has data for a SL logical channel with HARQ feedback enabled, the WTRU may perform RLM / RLF on the Uu path

[0175] - Messages received from the relay WTRU

[0176] o In one embodiment, the remote WTRU may change its RLM / RLF behavior based on receiving a Uu RLF indication from a relay WTRU. Specifically, if the remote WTRU is not monitoring RLM / RLF on the Uu path for a given time and receives a Uu RLM / RLF indication from a relay WTRU, the remote WTRU may notify the network of this via Uu and then initiate / recover 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 an indication (from the network or relay WTRU) that the Uu link at the relay WTRU has been restored.

[0177] o In one embodiment, the remote WTRU may change 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 via the relay WTRU, the remote WTRU may perform RLM / RLF via the Uu path. Otherwise, the remote WTRU may perform relaxed RLM / RLF or no RLM / RLF via the Uu path.

[0178] -QoS / bearer configuration at the remote WTRU

[0179] o For example, the use of the SL path for RLF may be further conditioned on the WTRU being configured with at least one SL LCH and configured HARQ feedback

[0180] o For example, the use of the SL path for RLF may be further conditioned on the WTRU being configured with at least one SL RLC channel configured with RLC Acknowledged Mode (AM)

[0181] o For example, the WTRU may be allowed to use the first condition discussed herein to determine the RLF behavior for some QoS flows / bearers and the second condition discussed herein to determine the RLF behavior for some other QoS flows / bearers. For example, certain QoS flows / bearers may always require the WTRU to monitor for RLM / RLF on the Uu path when they are established and / or when they have data available.

[0182] ○ For example, the remote WTRU may perform RLM / RLF on Uu based on the presence / number of SL LCHs configured with HARQ feedback enabled and / or the amount of data for transmission present in the buffer for such HARQ enabled LCHs. For example, if all SL LCHs are configured without HARQ feedback enabled, the remote WTRU may monitor Uu RLM / RLF. For example, if the number of SL LCHs configured with HARQ feedback enabled is above a threshold, the remote WTRU may monitor Uu RLM / RLF. For example, if the amount of data buffered at the WTRU SL LCHs with HARQ feedback enabled is below a threshold, the remote WTRU may monitor Uu RLM / RLF. For example, when the cells associated with the direct link and the indirect link are the same and / or the WTRU is configured with a split SRB, the WTRU may use the above determination to determine whether to monitor Uu RLM / RLF.

[0183] o For example, when the number of SL LCHs configured with HARQ enabled feedback and / or the amount of data to send present in the buffer for such HARQ enabled LCHs is above a threshold, the remote WTRU may perform relaxed RLM / RLF on the Uu. The WTRU may also determine relaxed parameters associated with relaxed RLM / RLF (e.g., percentage of reference signals to monitor, value of a timer / counter associated with RLM / RLF, etc.) based on such conditions.

[0184] - Whether the relay and remote WTRU are controlled by the same / different cell / scheduler / gNB

[0185] o For example, the WTRU may use the first rule or condition discussed herein in a same-cell case and a different rule or condition in a multi-cell case.

[0186] o For example, the WTRU may always perform RLF on both paths in different cell situations, but may use other conditions discussed herein to determine whether to perform RLF on both paths in same cell situations

[0187] -Path configuration of SRB in multipath

[0188] o For example, the WTRU may perform RLM / RLF on the Uu path, or if the SRB is configured to be transmitted only on the Uu path, the WTRU has rules that favor RLM / RLF detection on the Uu path, or if the SRB is transmitted only on the SL path, the WTRU has rules that favor RLF monitoring on the SL, or if the SRB may be transmitted on both paths, the WTRU has rules that can flexibly determine the path based on RSRP (as discussed herein)

[0189] -Repeated configuration of SRB in multipath

[0190] o For example, if the SRB is configured to repeat, the WTRU may perform RLF on both the Uu link and the SL link

[0191] -RRC state of the relay WTRU

[0192] o For example, the WTRU may be in multipath, whereby the relay WTRU is in an idle inactive state, in which case all UL / DL data is routed via Uu. In this case, the remote WTRU may always monitor for RLM / RLF via Uu. When the relay WTRU is in a connected state, the remote WTRU may use other rules to determine the RLM / RLF monitoring

[0193] - Whether the path corresponds to a direct path or an indirect path

[0194] o For example, the WTRU may use a first rule (herein) to determine whether to monitor for RLF on a direct path, and a second rule (herein) to determine whether to monitor for RLF on an indirect path

[0195] o For example, the WTRU may always monitor for RLF on the indirect path and may determine whether to monitor for RLF on the direct path based on another rule in this document

[0196] - Whether the indirect path is associated with a 3GPP link (e.g., PC5) or a non-3GPP link

[0197] o 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, when the indirect path is associated with a 3GPP link, the remote WTRU may perform relaxed RLM / RLF on Uu.

[0198] When one link declares RLF and / or recovery fails, the remote WTRU may initiate an RLM / RLF Process

[0199] In one embodiment, when one link declares a failure, the remote WTRU may initiate RLM / RLF on another link. Such failure may be RLF of the link, failure in reestablishment of the link, sending of a failure RRC message (e.g., a message like SCGFailure or a message like MCGFailure), or any failure associated with the same condition for triggering RLF (e.g., reaching a certain number of consecutive HARQ DTXs on the link). For example, the remote WTRU may be configured to monitor for RLF on both the SL and the Uu, but may only monitor for SL-based RLF at a given time. If the remote WTRU detects RLF on the SL, the remote WTRU may initiate RLM / RLF monitoring on the Uu. The remote WTRU may also use such operation only under the conditions of a specific network architecture and / or bearer architecture for which such operation is configured. Specifically, such operation may be useful when the network transmits RRC signaling on one path, and due to the RLF on the path, it may be desirable to switch the path used for RRC signaling to another path. For example, after detecting RLF on one path, the WTRU may initiate RLF on another path when any one or more of the following conditions apply:

[0200] - Conditions associated with the configuration of one or more bearers (SRBs or DRBs). For example, this behavior may apply when a split SRB is configured with no duplication. Specifically, when a split SRB is configured with duplication, the WTRU may perform RLM / RLF on both paths. When an SRB is configured on only a single path, the WTRU may perform RLM / RLF on that path only and initiate a reestablishment when RLF is triggered.

[0201] -Conditions associated with the relationship between cells on the direct path and the indirect path (e.g., the same cell on both paths, cells belonging to the same gNB, or a configured cell list). For example, this behavior may apply when the WTRU is configured with the same cell on both the direct path and the indirect path. Specifically, when different cells are configured on different paths, the RLF on one path may initiate an MCG-like failure procedure, where the remote WTRU reports the failure and waits for further network configuration. On the other hand, when the same cell is configured on both paths, reconfiguration of the non-faulty path may not be required, and the WTRU may simply initiate failure monitoring on the non-faulty path in the expectation of receiving an RRC message on the non-faulty path.

[0202] - Conditions associated with whether the WTRU-WTRU (indirect) link is an ideal link. This behavior may apply, for example, when the indirect link between the WTRUs is a non-3GPP link. Specifically, when a PC5 link is configured, the remote WTRU may monitor for RLF on both links; however, when a non-3GPP link is configured, it is assumed that the link is ideal (and cannot fail), and the remote WTRU may rely on the relay WTRU to monitor for RLM / RLF on the Uu on its behalf.

[0203] - A condition associated with whether the path that triggered the RLF is a direct path or an indirect path. For example, the behavior may be applied when the RLF is triggered on an indirect path, but not applied when the RLF is triggered on a direct path. For example, the remote WTRU may always monitor for RLF on PC5-RRC, as the additional power consumed by RLM monitoring is very small compared to Uu.

[0204] -Conditions associated with the type of SL RLF that can be triggered. Specifically, this behavior may only apply to certain cases of SL failure, for example, only when SL RLF is triggered based on HARQ DTX, only when SL RLF is triggered based on T400 expiration, only when SL RLF is triggered based on Uu RLF indication received from relay WTRU, etc.

[0205] In a related embodiment, the WTRU may perform relaxed RLM on one path and may initiate normal RLM / RLF when RLF (or similar failure event) occurs on another path.

[0206] The remote WTRU routes data via the SL path based on conditions related to RLM / RLF

[0207] In one embodiment, the WTRU may modify the routing rules for UL data on a split bearer based on the configuration of the SRB and / or other factors that may define its RLF behavior / requirements. Specifically, based on the other rules discussed herein, the WTRU may need to monitor for RLF on the SL. If the WTRU has such a requirement, the WTRU may perform routing via the SL path such that sufficient data is transmitted via the SL path for the UL split bearer. For example, the WTRU may be configured with a certain percentage of data (perhaps for each split bearer) to be routed via the SL path, and may ensure that this percentage is met whenever other conditions (as described herein) require the WTRU to monitor for 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 the split bearer threshold based on the conditions discussed herein (e.g., Uu and / or SL quality).

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

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

[0210] Although not depicted in the flow chart, in an embodiment, if and when RLF is triggered on one and only one of the two paths, recovery (e.g., a process similar to SGCFailure) may be performed on the other of the two links. If RLF is triggered on both links, radio link reestablishment is performed.

[0211] Representative recovery process in multipath

[0212] Remote WTRU determines recovery process in a multipath manner

[0213] When a problem is detected on one or both links (eg, RLF detection or indication from the relay WTRU), the remote WTRU may perform one or more of several recovery procedures.

[0214] The remote WTRU may perform any or several (e.g., sequentially or simultaneously) recovery procedures including:

[0215] - Perform the rebuild process

[0216] -Perform multipath reconstruction type 1

[0217] - Perform multipath reconstruction type 2

[0218] -Perform CHO process

[0219] - Send Uu RRC message, such as a failure message similar to MCGFailure or SCGFailure message

[0220] -Perform MCGFailure-like operations

[0221] ○ For example, send an RRC error message and start a timer. If the timer expires and the network does not receive the reconfiguration, initiate a reestablishment message

[0222] -Perform SCGFailure-like operations

[0223] o For example, an RRC error message is sent, but no timer is started. Normal operation may continue on links that are still operational

[0224] o For example, the WTRU may send different RRC messages depending on whether it is initiating a procedure similar to SCGFailure or a procedure similar to MCGFailure

[0225] - Perform relay reselection process and possibly provide reselection results to the network

[0226] -Performing a conditional handover (CHO), HO, or CHO-like procedure where the WTRU uses the configuration provided to it to change the PCell, possibly to a different path, such as a path associated with an established or established 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 some failure during the add procedure, as described herein.

[0227] - Trigger measurement reports of available / measured relays only, Trigger measurement reports of available / measured cells only, Trigger measurement reports of both relays and cells

[0228] ○ Specifically, the conditions discussed herein may be used to determine which measurement report to transmit

[0229] - Release PC5-RRC connection

[0230] ○ Specifically, the conditions discussed herein can be used to determine whether to maintain or release a PC5-RRC connection

[0231] - Release multipath connections / configurations

[0232] ○ Specifically, the conditions discussed herein may be used to determine whether to release a multipath connection / configuration at a remote WTRU and rely on a single path connection

[0233] - Indicates the cause of the RLF (e.g., SL-RLF detected or Uu RLF received from a relay WTRU)

[0234] ○ Specifically, the conditions in this article can be used to determine whether to include the reasons for the RRC message transmitted to the network, such as detecting SL-RLF, receiving Uu RLF, triggering HARQ-based SL RLF, triggering RLC-based SL RLF, triggering T400-based SL RLF, etc.

[0235] - suspending one of the paths associated with the multipath configuration (i.e. suspending all transmissions performed on the bearers associated with that path)

[0236] The remote WTRU determines the message type / content / SRB type of the recovery message (e.g., RRC message) in a multipath manner

[0237] The remote WTRU may include different content in the recovery message (e.g., a message similar to MCGFailure, a message similar to SCGFailure) or may use different RRC messages together on different SRBs (SRB0 or ​​SRB1). For example, depending on the conditions herein, the WTRU may include or not include specific parameters in the message. Specifically, the remote WTRU may include any one or more of the following data in such a failure message:

[0238] -Carrier frequency associated with the fault path

[0239] - Measurements of other relay WTRUs

[0240] - An indication of whether the measurement result associated with the measurement of other relays is associated with the sidelink discovery reference signal received power (SD-RSRP) or the sidelink reference signal received power (SL-RSRP)

[0241] - An indication of whether the measurement result is associated with a relay station with which the remote WTRU has a PC5-RRC connection, which may be associated with measurements of other relay stations

[0242] - An indication of whether the measurement result is associated with a relay WTRU in RRC_CONNECTED (or the state of a relay WTRU), which may be associated with measurements of other relays

[0243] - Fault type, fault indication or similar information, which may indicate any of the following:

[0244] ○ RLF of the relay WTRU, or the type of RLF failure of the relay WTRU (e.g., T310 expired, randomAccessProblem, etc.)

[0245] ○ SL RLF detected by the remote WTRU

[0246] ○ HO of a remote WTRU

[0247] ○Cell reselection by a remote WTRU

[0248] ○ The remote WTRU fails to establish an RRC connection

[0249] - An indication that a failure occurred during the processing of the add / change procedure (see Rebuild Type 2 herein)

[0250] The set of actions (e.g., procedures) and / or the type / content of the message performed by the remote WTRU may depend on any of the conditions discussed in the previous section. Specifically, the WTRU may perform one or more sets of actions instead of one or another set of actions based on conditions associated with any one or a combination of the following factors:

[0251] -Measurement of Uu path quality

[0252] -Measurement of SL path quality

[0253] -SL specific measurements such as CBR or CR

[0254] - A message received from the relay WTRU (i.e., a specific message being transmitted or a specific indication)

[0255] -QoS / bearer configuration at the remote WTRU

[0256] -Whether the relay and remote WTRU are controlled by the same / different cell / scheduler / gNB. For example, the remote WTRU may be configured with a method for determining whether the second cell is part of the same gNB as the first cell (e.g., a cell list, a subset of bits in the cell ID are common, the area ID or similar information broadcast by both cells is the same, etc.).

[0257] -Path configuration of SRB in multipath

[0258] -Repeated configuration of SRB in multipath

[0259] -RRC state of the relay WTRU

[0260] - The path on which the RLF is triggered (Uu / direct or SL / indirect or both)

[0261] -RLF monitoring behavior (e.g., whether the WTRU is monitoring Uu RLF, SL RLF, whether the WTRU is performing relaxed Uu RLF monitoring)

[0262] -RLF fault type itself

[0263] - Whether the WTRU-WTRU connection for the indirect path is a 3GPP link (e.g., PC5) or a non-3GPP link (e.g., ideal link)

[0264] - Which paths failed (direct or indirect)

[0265] - Which path corresponds to the WTRU's Pcell, relative to which path the failure occurs

[0266] Representative process for recovery process and message content

[0267] In an example embodiment, a WTRU that triggers Uu RLF individually may determine whether to perform a MCGFailure-like procedure or a SCGFailure-like procedure via the SL path based on whether the WTRU is sending a UL via the relay path or has data pending for sending via the relay path. For example, the WTRU may be configured with a threshold amount of data associated with a SL LCH with HARQ feedback enabled. If the amount of data in the buffers of all SL LCHs with HARQ feedback enabled is above the threshold, the WTRU may perform a recovery procedure similar to SCGFailure. Otherwise, the WTRU may perform a recovery procedure similar to MCGFailure.

[0268] In another example embodiment, a WTRU detecting a SL RLF may determine whether to perform one of a SCGFailure-like procedure, a MCGFailure-like procedure, or a reestablishment based on a measured Uu RSRP, which may be 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 a SCGFailure-like procedure. If the measured Uu RSRP is between a first threshold and a second threshold that is lower than the first threshold, the WTRU may perform a MCGFailure-like procedure. If the Uu RSRP is lower than the second threshold, the WTRU may perform a reestablishment procedure.

[0269] 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 determine whether to perform an SCGFailure-like procedure, an MCGFailure-like procedure, or a re-establishment based on the Uu RLM / RLF monitored by the WTRU at the SL RLF. Specifically, if the WTRU is performing Uu RLM / RLF, the WTRU may perform an MCGFailure-like procedure. If the WTRU is performing loose RLM on the Uu path, the WTRU may perform an MCGFailure-like procedure. If the WTRU is not performing Uu RLM, then depending on other factors (e.g., Uu RSRP), the WTRU may perform an MCGFailure-like procedure or a re-establishment.

[0270] In another example embodiment, a WTRU that triggers an RLF on a link may determine whether to perform a MCGFailure-like procedure or a SCGFailure-like procedure depending on whether the path corresponds to the same cell or a different cell. Specifically, in the case of the same cell, the remote WTRU may perform a SCGFailure-like procedure, while in the case of a different cell, the remote WTRU may perform a MCGFailure-like procedure. In a similar example, the procedure followed may depend on which cell is configured as a serving cell. Specifically, if the RLF occurs on a path associated with a Pcell, the WTRU may perform a MCGFailure-like procedure, while if the RLF occurs on a path associated with a cell that is not a Pcell, the WTRU may perform a SCGFailure-like procedure.

[0271] In another example embodiment, a WTRU that triggers an RLF on one link may determine whether to perform an MCGFailure-like procedure or an SCGFailure-like procedure depending on whether the indirect path is a PC5 link or a non-3GPP link. Specifically, if the indirect path is a non-3GPP link, the RLF triggered on one link may initiate an MCGFailure-like procedure or no failure procedure at all (i.e., the remote WTRU does not send any RRC message to the network). If the indirect path is PC5, the remote WTRU may initiate an SCGFailure-like procedure on the SL RLF and an MCGFailure-like procedure on the Uu RLF.

[0272] In another example embodiment, the WTRU may determine the failure process steps based on the SRB configuration when in multipath. Specifically, if the WTRU detects RLF on a link that is not configured to carry SRBs (e.g., the WTRU is configured with SRB1 on only one path) and detects RLF on a link that is not configured with SRBs, the remote WTRU may report a failure message to the network, suspend or release the bearer on the failed link or transmission to the bearer, and continue operating on the non-faulty link. On the other hand, if the remote WTRU is configured with a split SRB 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 the reconfiguration is not received before the timer expires, the remote WTRU may trigger a reconstruction. On the other hand, if RLF occurs on a link where the SRB is configured as non-split, the remote WTRU may trigger a reconstruction.

[0273] In an example embodiment, the WTRU may include an RLF failure type indication when performing recovery via Uu, but may not include an RLF failure type indication when performing recovery via SL. For example, the remote WTRU may indicate in an error message on Uu whether the error was caused by SL RLF detection by the remote WTRU, reception of a Uu RLF indication by the relay WTRU, or reception of other indication messages (e.g., a handover (HO) indication from the relay WTRU). Specifically, the remote WTRU may include a failure type indicating a failure on the SL path.

[0274] 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 at the time of failure based on the link that failed. Specifically, if Uu RLF is triggered, the WTRU may include only measurements of the cell in the error message transmitted via the relay path. If SL RLF is triggered, the WTRU may include only measurements of the relay in the error message transmitted via the Uu path. If the WTRU performs a reestablishment, the WTRU may include measurements of both the cell and the relay.

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

[0276] 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 in the remote WTRU. For example, if the remote WTRU receives a Uu RLF indication from the relay WTRU, the remote WTRU may release / remove the PC5-RRC connection and / or release the multipath configuration. On the other hand, if the remote WTRU receives a HO indication from the relay WTRU, the remote WTRU may suspend the indirect bearer or transmission via the indirect link, but maintain the PC5-RRC connection, and wait for the network to reconfigure the indirect link. The remote WTRU may also wait for a certain period of time for the reconfiguration of the indirect link, after which, if the reconfiguration of the indirect link is not received from the network, the remote WTRU may release the PC5-RRC connection.

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

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

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

[0280] Measurements of relays in multipath can be limited to relays connected to the same cell

[0281] In one embodiment, the WTRU may filter measurements of relays transmitted to the gNB in ​​order to limit them to those relays served by the same cell / gNB as the cell / gNB that directly serves the remote WTRU via multipath. For example, the WTRU may send measurements with an error message during the recovery process after SL-RLF and may include potential relays and their SL-RSRP / SD-RSRP. In doing so, the remote WTRU that was in the multipath at the time of the error may filter the measurements to include only measurements of relays connected to the same cell / gNB as the remote WTRU. Alternatively, the remote WTRU may preferentially send measurements of relays connected to the same cell / gNB. Specifically, if the remote WTRU is able to detect relays connected to the same cell (potentially with SL RSRP / SD RSRP above a threshold), the WTRU may only transmit measurements of those relays. Otherwise, the WTRU may send measurements of other relays. An advantage of this embodiment is that the overhead of transmitting all relay measurements is reduced when the multipath is limited to the case where the remote WTRU and the relay WTRU are controlled by the same cell.

[0282] Whether the WTRU filters measurements of relays to include only relays connected to the same gNB may also depend on other factors discussed herein. For example, during normal operation (e.g., not during an RLF condition), measurements of potential relays may be filtered to only those 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 this implementation is that the WTRU may provide measurements of other relays (not necessarily controlled by the same cell) only when the network may change cells.

[0283] Fig. 9is a flow chart of an exemplary process for performing radio link recovery in a DC WTRU upon RLF detection according to a specific exemplary embodiment. At step 901, if RLF is triggered only on the Uu path, the process proceeds to step 903, where the WTRU determines whether there is data pending for the SL relay path. If yes, the WTRU determines whether the RSRP on another path (in this example, the SL relay path) is higher than a first threshold (step 905). If yes, the WTRU performs a process similar to SCGFailure on the SL relay path (e.g., sends an RRC message and continues to operate on the path) (step 907). If no, the process proceeds to step 909, where the WTRU determines whether the RSRP on the SL relay path is higher than a second threshold that is lower than the first threshold. If yes, the process proceeds to step 911, where the WTRU performs a process similar to MCGFailure on the SL relay path (e.g., sends an RRC message and sets a timer for radio link reestablishment). If no, the process proceeds to step 913, where the WTRU performs a radio link reestablishment process.

[0284] Return to Fig. 9 On the top of, on the other hand, if RLF is triggered only on the SL relay path (step 915), the process proceeds from step 915 to step 917, where the WTRU determines whether it is currently performing RLM / RLF on the Uu path. If yes, the process proceeds from step 917 to step 919, where the WTRU determines whether the RSRP on the Uu path is higher than a first threshold. If yes, the process proceeds from step 919 to step 921, where the WTRU performs a process similar to SCGFailure on the Uu path. If no, the process proceeds from step 919 to step 923, where the WTRU determines whether the RSRP on the Uu path is higher than a second threshold that is lower than the first threshold. If yes, the process proceeds from step 923 to step 925, where the WTRU performs a process similar to MCGFailure on the Uu path. If no, the process proceeds from step 923 to step 913, where the WTRU performs a radio link reestablishment process.

[0285] Return to Fig. 9 At the top of , if RLF is triggered for both paths (step 927), the flow proceeds directly to step 913, where the WTRU performs the radio link reestablishment procedure. Fig. 9 In the flowchart, for the sake of convenience, step 927 is shown as a decision step, but in fact, since the flowchart assumes that RLF is triggered, step 927 may be omitted. Therefore, if the two conditions set forth in steps 901 and 915 are not met, the condition in step 927 is inherently met.

[0286] Representative process - MAC CE that can switch the primary path and implicitly initiate RLM / RLF

[0287] In one embodiment, the remote WTRU may receive a MAC CE that may initiate 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 suitability of a path for transmission / reception of SRB1. Specifically, the remote WTRU may be configured with a split SRB, but may only transmit / receive SRBs and / or perform RLM / RLF on one of the paths at a given time. Although configured with SRBs, another path may disable SRB transmission / reception on the path. Upon receiving the MAC CE, the remote WTRU may enable / disable SRB reception / transmission on the path. Specifically, when a split SRB is configured, the remote WTRU with an RRC message may send the RRC message via only the path that enables SRBs.

[0288] In another embodiment, the same MAC CE may enable / disable RLM / RLF and enable / disable / change SRB transmission / reception on the path.

[0289] Representative process for reconstruction in multipath

[0290] The new method for re-establishment may be used by the remote WTRU in a multipath manner. Specifically, since the WTRU is not currently configured to monitor SRBs on one of the two paths (e.g., to save power), re-establishment may be triggered by the WTRU in a multipath manner. If an RLF is triggered on a path with SRBs, the WTRU cannot perform procedures like MCGFailure / SCGFailure and may typically resort to re-establishment. However, the remote WTRU is already operating on the other path because this path is being used during multipath operation and may be operating normally (e.g., the remote WTRU is receiving / transmitting data on this path and potentially reporting measurements for this path). Therefore, the full traditional re-establishment process may not be required.

[0291] Therefore, in a series of embodiments, a remote WTRU may trigger a new RRC procedure whereby the remote WTRU initiates / continues a connection on one of the multiple paths when a failure would normally result in a re-establishment procedure. Potential differences between this new RRC procedure and the traditional re-establishment procedure may include:

[0292] - The remote WTRU does not trigger the cell / relay selection, but directly performs the process on the cell / relay it uses in a multipath manner

[0293] - The remote WTRU may (re)use the RRC configuration already available at the WTRU, rather than releasing the configuration and triggering a re-establishment

[0294] - The remote WTRU may avoid re-establishing or resetting one or more protocol layers (eg, data buffers are not necessarily flushed), as is the case with a re-establishment.

[0295] In a specific implementation 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 in a multipath mode 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 implementation is most similar to a reestablishment that does not require the selection of a cell / relay and does not reset the protocol layers. This procedure may be referred to herein as Multipath Reestablishment Type 1.

[0296] In another type of implementation, the remote WTRU may apply the procedure using an RRC configuration received in a message (e.g., path change / path addition) 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 occurred after the RRC configuration was received. This type of implementation is most similar to CHO, where the configuration is received via an RRC message and applied when a failure is triggered. This procedure may be referred to herein as Multipath Reestablishment Type 2.

[0297] The type of RRC message and / or SRB transmitted / received may depend on whether SRB1 is configured.

[0298] The reestablishment process for the multipath may be triggered using an RRC message using SRB0 or ​​SRB1.

[0299] For example, if the 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 message transmission) was previously configured with SRB1. If SRB1 is configured, the remote WTRU may send an 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 a conventional system, the remote WTRU may trigger a reestablishment if a reconfiguration is not received within a certain period of time. If SRB1 is not configured, the remote WTRU may send an 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 to send on the DRB via the non-faulty path and may not perform any reset of the PHY / MAC / RLC layer on either path. Specifically, for the SRB0 case, data transmission may continue using the previous security keys. SRB0 may send / receive RRC messages using the specified configuration. Alternatively, the sending on SRB1 message may use the specified / default configuration of SRB1 instead (considering that SRB1 has not been previously configured on this path before).

[0300] In the uplink RRC message, the remote WTRU may also indicate the cause of the failure (eg, RLF type or whether it was caused by SL RLF, etc.).

[0301] For example, if the WTRU triggers a Type 2 procedure after receiving an RRC message (but before applying the message), whether SRB0 or ​​SRB1 is used for the initial RRC message may depend on whether the received message (in the example below, the RRC message that performs path addition) contains a configuration for SRB1. If no configuration is provided, the WTRU may use SRB0 or ​​may send an RRC message with a default or specified configuration, whereas if the received message contains an SRB1 configuration, the remote WTRU may send an uplink RRC message using the configuration in the received message. In addition, the WTRU may not expect any response message, for example, in the case where SRB1 is used (i.e., the message may be similar to a full message).

[0302] In the uplink RRC message, the remote WTRU may also indicate that the path add / change failed and the remote WTRU applies the configuration provided in the path add / change message to perform the re-establishment. If there are multiple configurations that may have been provided to the WTRU, the WTRU may further identify the specific configuration.

[0303] In case of Type 2, data transmission via DRB may be initiated under any of the following conditions:

[0304] - Immediately after the transmission of an uplink RRC message

[0305] - Immediately after the RACH procedure (if a direct path is to be added)

[0306] - Immediately after the establishment of the PC5-RRC connection (if an indirect path is to be added)

[0307] -After receiving the DL confirmation message

[0308] - Depends on whether SRB0 or ​​SRB1 is used (or if it is part of a configuration associated with type 2)

[0309] o For example, if SRB0 is used, the WTRU may wait to receive a response before initiating data transmission

[0310] o 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 also not expect any response message after the transmission of the UL RRC message

[0311] Representative procedures for multipath reestablishment type 1 may be triggered as a result of RLF of another path

[0312] In one embodiment, the remote WTRU may perform a multipath reestablishment type 1 via a first path as a result of a RLF detected on a second path, where the first path and the second path are paths previously configured to the WTRU during the multipath period.

[0313] Representative process for multipath reconstruction type 2 may be triggered as a result of a failure during path addition / change

[0314] In one embodiment, as a result of a failure during the path add / change procedure, the remote WTRU may initiate a multipath re-establishment type 2 procedure. For example:

[0315] -Failure of indirect path during addition of direct path: The remote WTRU may receive a path addition for adding a direct path via an indirect path. During the addition, the remote WTRU may receive a notification (e.g., Uu RLF) from a relay WTRU or a SL RLF may be triggered. Upon receiving the notification, the remote WTRU may perform a multipath reestablishment type 2 to the cell associated with the direct path. Specifically, the remote WTRU may send a complete message via the direct path. The remote WTRU may also indicate (e.g., within the complete message) that the remote WTRU has performed a multipath reestablishment type 2 procedure instead of adding due to 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 the direct path as a PCell (instead of assuming that the PCell is on the indirect path). Specifically, the remote WTRU may use the received configuration, thereby assuming that the bearers associated with the indirect path are suspended, and only use the direct path bearer or multiple bearer paths until further reconfiguration.

[0316] - Failure of direct path during addition of indirect path: Similarly, the remote WTRU may receive a path addition via the direct path to add an indirect path. During the addition, the remote WTRU may trigger a Uu RLF. Upon detecting a Uu RLF, the remote WTRU may perform a Type 2 procedure on the cell associated with the indirect path and indicate the procedure in the complete message.

[0317] - Failure of direct path during change of indirect path: The remote WTRU may receive a reconfiguration to change the indirect path (ie, to a different relay WTRU) and trigger a Uu RLF during the path change procedure. As a result, the remote WTRU may initiate a Type 2 procedure via the new indirect path.

[0318] Fig. 10A An example of multipath wireless communication is provided. In this example, the remote WTRU is configured with multipath and performs RLM and RLF detection on Uu based on 1) the radio conditions on Uu and 2) the presence / amount of uplink data sent to the network via the relay link (relay WTRU).

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

[0320] In one example, the WTRU may perform a radio link failure (RLF) detection procedure on a first communication link based on a measurement of a channel condition 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 a measurement of a channel condition being less than a second threshold.

[0321] In various embodiments, the first radio link process includes radio link failure (RLF) detection, radio link monitoring (RLM) and / or radio link recovery on the second communication link. The second radio link process 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 used to compare the channel conditions associated with the second communication link. In some cases, the channel conditions include a reference signal received power (RSRP) of the second transmission. The measurement of the channel condition includes the value of the measured reference signal received power (RSRP) of the second transmission.

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

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

[0324] in conclusion

[0325] Although features and elements are provided above in specific combinations, it will be understood by those of ordinary skill in the art that each feature or element may be used alone or in any combination with other features and elements. The present disclosure is not limited to the specific embodiments described in the present application, which are intended to be illustrative of various aspects. Many modifications and variations can be made without departing from the essence and scope of the present invention, as they will be apparent to those skilled in the art. Unless explicitly provided as such, any element, action or description used in the present application specification should not be understood as being essential or necessary to the present invention. According to the foregoing description, in addition to those listed herein, functionally equivalent methods and devices within the scope of the present disclosure will be apparent to those skilled in the art. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure is limited only to the terms of the appended claims and the full range of equivalent forms of such entitled claims. It should be understood that the present disclosure is not limited to a specific method or system.

[0326] For simplicity, the foregoing embodiments are discussed with reference to the terminology and structure of infrared capable devices (i.e., infrared transmitters and receivers). However, the embodiments discussed are not limited to these systems, but can be applied to other systems using other forms of electromagnetic waves or non-electromagnetic waves (such as sound waves).

[0327] It should also be understood that the terms used herein are used only for the purpose of describing specific embodiments and are not intended to be limiting. As used herein, the term "video" or the term "image" may mean any of a snapshot, a single image, and / or a plurality of images displayed on a temporal basis. For example, when referred to herein, the term "user equipment" and its abbreviation "UE", the term "remote" and / or the term "head-mounted display" or its abbreviation "HMD" may mean or include (i) a wireless transmit and / or receive unit (WTRU); (ii) any of a plurality of embodiments of the WTRU; (iii) a wirelessly-enabled and / or wiredly-enabled (e.g., tetherable) device configured with (in particular) some or all of the structure and functionality of the WTRU; (iii) a wirelessly-enabled and / or wiredly-enabled device configured with less than all of the structure and functionality of the WTRU; or (iv), etc. This document is relative to Figures 1A to 1DDetails of an example WTRU are provided that may represent any WTRU described herein. As another example, various disclosed embodiments 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 embodiments 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 adapted reality experience.

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

[0329] Variations of the methods, devices, and systems provided above are possible without departing from the scope of the present invention. In view of the various embodiments that can be applied, it should be understood that the illustrated embodiments are merely examples and should not be considered to limit the scope of the following claims. For example, the embodiments provided herein include handheld devices that may include or be used with any suitable voltage source (such as a battery, etc.) that provides any suitable voltage.

[0330] In addition, in the embodiments provided above, processing platforms, computing systems, controllers and other devices including processors are indicated. These devices may include at least one central processing unit ("CPU") and memory. According to the practice of those skilled in the art of computer programming, references to the symbolic representations of actions and operations or instructions may be performed by various CPUs and memories. Such actions and operations or instructions may be referred to as being "executed", "computer executed" or "CPU executed".

[0331] Those of ordinary skill in the art will appreciate that the actions and symbolic representations of operations or instructions include manipulation of electrical signals by the CPU. The electrical system represents data bits, which may result in the ultimate transformation of electrical signals or reduction of electrical signals and the retention of data bits at memory locations in the memory system, thereby reconfiguring or otherwise changing the operation of the CPU and performing other processing of signals. The memory location that holds the data bits is a physical location that has specific electrical, magnetic, optical, or organic properties that correspond to or represent the data bits. It should be understood that the embodiments are not limited to the above-mentioned platforms or CPUs, and other platforms and CPUs may also support the provided methods.

[0332] 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 the CPU. The computer-readable media may include cooperating or interconnected computer-readable media that reside solely on the processing system or distributed across multiple interconnected processing systems that may be local or remote relative to the processing system. It should be understood that the embodiments are not limited to the above-mentioned memories, and other platforms and memories may also support the provided methods.

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

[0334] There is little difference between hardware implementation and software implementation of various aspects of the system. The use of hardware or software is usually (but not always, because in some contexts, the choice between hardware and software may become important) a design choice that represents a trade-off between cost and efficiency. There may be various media (e.g., hardware, software, and / or firmware) that can implement the processes and / or systems and / or other technologies described herein, and the preferred media may vary with the context of the deployment process and / or system and / or other technologies. For example, if the implementer determines that speed and accuracy are most important, the implementer may choose a media that is primarily hardware and / or firmware. If flexibility is most important, the implementer may choose a specific implementation that is primarily software. Alternatively, the implementer may choose some combination of hardware, software, and / or firmware.

[0335] The above specific embodiments have been listed various embodiments of devices and / or processes by using block diagrams, flow charts and / or examples. Where such block diagrams, flow charts 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, flow charts or examples may be implemented individually and / or collectively by a wide range of hardware, software, firmware or almost any combination thereof. In embodiments, several parts of the subject matter described herein may be implemented via application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs) and / or other integrated formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein may be equivalently implemented in integrated circuits as a whole or in part as one or more computer programs running on one or more computers (e.g., one or more programs running on one or more computer systems), one or more programs running on one or more processors (e.g., one or more programs running on one or more microprocessors), firmware or almost any combination thereof, and according to the present disclosure, designing circuits and / or writing software and / or firmware codes will be completely within the technical scope of those skilled in the art. Furthermore, those skilled in the art will appreciate that the mechanisms of the subject matter described herein can be distributed as a program product in a variety of forms, and that the illustrative embodiments of the subject matter described herein apply regardless of the specific type of signal-bearing medium used to actually perform the distribution. Examples of signal-bearing media include, but are not limited to, the following: recordable type media (such as floppy disks, hard drives, CDs, DVDs, digital tapes, computer memory, etc.); and transmission type media (such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.)).

[0336] Those skilled in the art will recognize that it is common in the art to describe devices and / or processes in the manner set forth herein, and thereafter use engineering practices 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 via a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system generally may include one or more of the following: a system unit housing; a video display device; a memory, such as a volatile memory and a non-volatile memory; a processor, such as a microprocessor and a digital signal processor; a computing entity, such as an operating system, a driver, a graphical user interface, and an application; one or more interactive devices, such as a touch pad or a screen; and / or a control system, including a feedback loop and a control motor (e.g., a feedback for sensing position and / or velocity, a control motor for moving and / or adjusting components and / or quantities). A typical data processing system may be implemented using any suitable commercially available components, such as those typically found in data computing / communication and / or network computing / communication systems.

[0337] The subject matter described herein sometimes illustrates different components included in or connected to different other components. It should be understood that such depicted architectures are merely examples, and in fact many other architectures that achieve the same functionality can be implemented. In a conceptual sense, any arrangement of components that achieve the same functionality is effectively "associated" so that the desired functionality can be achieved. Therefore, any two components that are combined to achieve a specific functionality in this article can be considered to be "associated" with each other so that the desired functionality is achieved, regardless of the architecture or intermediate components. Similarly, any two components so associated can also be considered to be "operably connected" or "operably coupled" to each other to achieve the desired functionality, and any two components that can be so associated can also be considered to be "operably couplable" to each other to achieve the desired functionality. Specific examples of operable coupling include, but are not limited to, components that can physically cooperate and / or physically interact and / or components that can wirelessly interact and / or wirelessly interact and / or components that can logically interact and / or components that can logically interact.

[0338] With respect to substantially any plural and / or singular terms used herein, those skilled in the art may convert from the plural to the singular and / or from the singular to the plural as appropriate, depending on the context and / or application. For clarity, various singular / plural arrangements may be explicitly listed herein.

[0339] It will be understood by those skilled in the art that, in general, the terms used herein, and particularly in the appended claims (e.g., the bodies of the appended claims), are generally intended to be "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 "comprising" should be interpreted as "including but not limited to," etc.). It will also be understood by those skilled in the art that if a specific number of an introduced claim recitation is intended, such intent will be explicitly recited in the claim, and in the absence of such recitation, no such intent is present. For example, where only one item is intended, the term "single" or similar language may be used. To aid understanding, the following appended claims and / or the description herein 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 implying that any particular claim that includes such introduced claim recitation subject matter is limited to embodiments that include only one such recitation subject matter by the indefinite article "a" or "an" to introduce the claim recitation subject matter, even when the same claim includes the introductory phrases "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 as meaning "at least one" or "one or more"). The same applies to the use of definite articles to introduce claim recitation subjects. Furthermore, even if a specific number of introduced claim recitation subjects is explicitly recited, one skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number (e.g., the bare recitation of "two recitation subjects" means at least two recitation subjects or two or more recitation subjects in the absence of other modifiers). Additionally, in those instances where a convention similar to “at least one of A, B, and C, etc.” is used, generally speaking, such construction is meant to be understood by one skilled in the art (e.g., “a system having at least one of A, B, and C” would include, but is not limited to, systems having A alone, B alone, C alone, both A and B, both A and C, both B and C, and / or both A, B, and C, etc.). In those instances where a convention similar to “at least one of A, B, or C, etc.” is used, generally speaking, such construction is meant to be understood by one skilled in the art (e.g., “a system having at least one of A, B, or C” would include, but is not limited to, systems having A alone, B alone, C alone, both A and B, both A and C, both B and C, and / or both A, B, and C, etc.). It should also be understood by those skilled in the art that, in fact, any separate words and / or phrases presenting two or more alternative terms, whether in the specification, claims or drawings, should be understood to contemplate the possibility of including one of the terms, any one of the terms, or both of the terms.For example, the phrase "A or B" will be understood to include the possibilities of "A" or "B" or "A and B." In addition, as used herein, the term "any of..." followed by a listing of multiple items and / or multiple categories of items is intended to include "any of," "any combination," "any multiples," and / or "any combination of multiples" of the items and / or categories of items, either alone 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 "quantity" is intended to include any number, including zero. And, as used herein, the term "plurality" is intended to be synonymous with "multiple."

[0340] In addition, where features or aspects of the disclosure are described in terms of Markush groups, those skilled in the art will recognize that the disclosure is also described in terms of any individual member or subgroup of members of the Markush group.

[0341] As will be understood by those skilled in the art, for any and all purposes (such as in terms of providing a written description), all ranges disclosed herein also encompass any and all possible subranges and combinations of their subranges. Any listed range can be easily identified as fully describing and enabling the same range to be divided into at least equal halves, one-third, one-quarter, one-fifth, one-tenth, etc. As a non-limiting example, each range discussed herein can be easily divided into a lower third, a middle third, and an upper third, etc. As will be understood by those skilled in the art, all languages ​​such as "up to", "at least", "greater than", and "less than", etc. include the cited numbers and refer to the ranges that can be subsequently divided into subranges as described above. Finally, as will be understood by those skilled in the art, the range includes each individual number. Therefore, for example, a group with 1 to 3 units refers to a group with 1, 2, or 3 units. Similarly, a group with 1 to 5 units refers to a group with 1, 2, 3, 4, or 5 units, etc.

[0342] Furthermore, the claims should not be read as limited to the order or elements provided unless otherwise stated. Furthermore, the use of the term "means for..." in any claim is intended to invoke 35 U.S.C. § 112, 6 or parts-plus-function claim format, and any claim without the term "means for..." is not intended to be so.

[0343] Suitable processors include, by way of example, a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association 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 state machine.

[0344] The WTRU may be used in conjunction with a module, which may be implemented in hardware and / or software including: software defined radio (SDR) and other components such as a camera, a video camera module, a videophone, a speakerphone, a vibration device, a speaker, a microphone, a television transceiver, a hands-free headset, a keyboard, module, a frequency modulation (FM) radio unit, a near field communication (NFC) module, a liquid crystal display (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 any wireless local area network (WLAN) or ultra-wideband (UWB) module.

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

[0346] Furthermore, while the invention has been illustrated and described herein with reference to specific embodiments, the invention is not intended to be limited to the details shown. Rather, various modifications may be made to the details within the scope and range of equivalents of the claims without departing from the invention.

Claims

1. A method implemented in a first wireless transmit / receive unit (WTRU) for wireless communication, the method 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, wherein the first threshold is greater than the second threshold; determining that uplink data is pending for transmission on a first transmission to a network entity via a second WTRU, wherein the first transmission is associated with a first communication link; determining a channel condition of a second transmission from the network entity, wherein the second transmission is associated with a second communication link; as well as Based on the measure of the channel condition being greater than the second threshold and less than the first threshold, performing a first radio link procedure using the first radio link configuration.

2. The method of claim 1, further comprising performing a radio link failure (RLF) detection procedure on the first communication link based on the measurement of the channel condition being greater than the first threshold. 3 . The method of claim 1 , further comprising performing a second radio link procedure using the second radio link configuration based on the measurement of the channel condition being less than the second threshold.

4. The method according to any of the preceding claims, 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 according to any of the preceding claims, wherein the second radio link procedure comprises 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 the preceding claims, wherein each of the first threshold and the second threshold is used to compare the channel condition associated with the second communication link.

7. A method according to any preceding claim, wherein the channel condition comprises a reference signal received power (RSRP) of the second transmission.

8. A method according to any preceding claim, wherein the measurement of the channel condition comprises a value of a measured Reference Signal Received Power (RSRP) of the second transmission.

9. A method according to any of the preceding claims, 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 of the preceding claims, wherein the second communication link is a Uu path for communicating with the network entity.

11. 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 communication link or the second communication link before detecting the 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 for transmission.

13. A first wireless transmit / receive unit (WTRU) for wireless communication, the first WTRU comprising circuitry, the circuitry comprising a transmitter, a receiver, a processor, and a memory, the WTRU being configured to: 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, wherein the first threshold is greater than the second threshold; determining that uplink data is pending for transmission on a first transmission to a network entity via a second WTRU, wherein the first transmission is associated with a first communication link; determining a channel condition of a second transmission from the network entity, wherein the second transmission is associated with a second communication link; as well as Based on the measure of the channel condition being greater than the second threshold and less than the first threshold, performing a first radio link procedure using the first radio link configuration.

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

15. 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 measurement of the channel condition being less than the second threshold.

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

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

18. The WTRU of any one of claims 13 to 17, wherein each of the first threshold and the second threshold is used to compare the channel condition associated with the second communication link.

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

20. The WTRU of any one of claims 13 to 19, wherein the measurement of the channel condition comprises a value of a measured reference signal received power (RSRP) 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. A WTRU according to any one of claims 13 to 22, wherein the configuration information indicates a radio resource control (RRC) configuration, and the WTRU is also configured to use the RRC configuration for the first communication link or the second communication link before detecting 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 condition, the type of RLF and / or the uplink data pending for transmission.

Images