Connection management and recovery associated with multipath sidelink relays

Abstract

Systems, methods, and instrumentalities are described herein for connection management and recovery associated with multipath sidelink relays. A relay wireless transmit / receive unit (WTRU) may provide RRC state information associated with the relay WTRU to a remote WTRU. The WTRU may receive configuration information indicating a condition for initiating a relay (re) selection or a PC5-RRC connection to the relay WTRU. Conditions may be set for initiating transmissions on a relay (e.g., secondary) path, where the conditions may depend on RRC state information, cell ID, and / or QoS at the relay WTRU.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 334,813 filed on April 26, 2022, U.S. Provisional Application No. 63 / 395,017 filed on August 4, 2022, U.S. Provisional Application No. 63 / 421,725 ​​filed on November 2, 2022, U.S. Provisional Application No. 63 / 445,434 filed on February 14, 2023, and U.S. Provisional Application No. 63 / 456,918 filed on April 4, 2023, the contents of which are incorporated herein by reference in their entirety. Background Art

[0003] Mobile communications using wireless communications continue to evolve. The fifth generation of mobile communications radio access technology (RAT) may be referred to as 5G New Radio (NR). The previous generation (legacy) mobile communications RAT may be, for example, fourth generation (4G) Long Term Evolution (LTE). Summary of the invention

[0004] Systems, methods, and means for connection management and recovery associated with a multipath sidelink relay are described herein. A relay wireless transmit / receive unit (WTRU) may provide RRC state information associated with a relay WTRU to a remote WTRU. The WTRU may receive configuration information indicating conditions for initiating a relay (re)selection or a PC5-RRC connection to the relay WTRU. Conditions may be set for initiating a transmission on a relay (e.g., secondary) path, wherein the conditions may depend on the RRC state information, cell ID, and / or QoS at the relay WTRU.

[0005] A remote WTRU (e.g., in RRC_CONNECTED) may determine whether routing to a secondary (e.g., relayed) path may be performed. Routing may be determined based on bearer QoS, the RRC state of the relay WTRU, and / or the cell ID served by the relay. The remote WTRU may receive configuration information for multipath data transmission. The configuration information may indicate a direct path (e.g., a Uu path) and / or an indirect path (e.g., via a sidelink relay, such as a relay WTRU). The remote WTRU may receive multiple (e.g., two) split bearer thresholds for (e.g., each) split bearer. The (e.g., each) split bearer threshold may be associated with state information of the relay WTRU. For example, a first threshold may be associated with an RRC connected state, and a second threshold may be associated with an RRC idle or inactive state (e.g., where the second threshold may be higher than the first threshold). The WTRU may determine a split bearer threshold, or receive an indication of a split bearer threshold. The remote WTRU may route data via both a primary path and a secondary path (e.g., via both a direct path and an indirect path, such as via splitting data between the direct path and the indirect path or duplicating data to be sent on both the direct path and the indirect path). For example, the remote WTRU may determine to use a first split bearer threshold, for example, based on receiving an indication that the relay WTRU is in an RRC connection. The remote WTRU may determine that the amount of data associated with the transmission is greater than the first split bearer threshold. Based on the determination that the amount of data is greater than the first split bearer threshold associated with the RRC connection, the WTRU may transmit the data using the indirect path. For example, the remote WTRU may determine to use a second split bearer threshold, for example, based on receiving an indication that the relay WTRU is in RRC idle / inactive. The remote WTRU may determine that the amount of data associated with the transmission is greater than the second split bearer threshold. Based on the determination that the amount of data is greater than the second split bearer threshold associated with RRC inactive / idle, the WTRU may transmit the data using the indirect path. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0007] Figure 1B is an example of a method that can be used according to one embodiment. Figure 1A System diagram of an example wireless transmit / receive unit (WTRU) for use within the communication system illustrated in FIG.

[0008] Figure 1C is an example of a method that can be used according to one embodiment. Figure 1A System diagram of an example radio access network (RAN) and an example core network (CN) used within the communication system illustrated in FIG.

[0009] Figure 1D is an example of a method that can be used according to one embodiment. Figure 1A System diagram of yet another example RAN and yet another example CN used within the communication system illustrated in .

[0010] Figure 2 An example user plane radio protocol stack for a Layer 2 evolved WTRU to network relay (PC5) is illustrated.

[0011] Figure 3 An example control plane radio protocol stack for a Layer 2 Evolved WTRU to Network Relay (PC5) is illustrated.

[0012] Figure 4A An example is illustrated in which multiple paths of bearers may be served by the same cell.

[0013] Figure 4B An example of multiple paths in which bearers may be served by different cells is illustrated.

[0014] Figure 5 An example of determining a transmission path using status information is illustrated. DETAILED DESCRIPTION

[0015] 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, filter bank multi-carrier (FBMC), etc.

[0016] 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 WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a 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.

[0017] 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 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. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0018] 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 transmit 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. A cell may be further divided into cell sectors. For example, a 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 one 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 transmit and / or receive signals in a desired spatial direction.

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

[0020] 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, SC-FDMA, etc. 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 115 / 116 / 117. WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High Speed ​​UL Packet Access (HSUPA).

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

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

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

[0024] 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), GSM EDGE (GERAN), etc.

[0025] Figure 1AThe base station 114b in the example may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business location, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In 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 micro-micro cell base station or a femto cell base station. 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.

[0026] 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, 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.

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

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

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

[0030] 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), a 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.

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

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

[0033] 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 to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

[0034] 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, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from and store data in a memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

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

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

[0037] 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, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, etc. Peripheral device 138 may include one or more sensors, which may be one or more of the following: a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0038] The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with specific subframes for both UL (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 for reducing and / or substantially eliminating self-interference via hardware (e.g., a choke) or via signal processing performed by a processor (e.g., a separate processor (not shown) or via the processor 118). In an embodiment, the WRTU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with specific subframes for both UL (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

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

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

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

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

[0043] 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, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, etc. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0044] 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 inter-evolved Node-B handover, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.

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

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

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

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

[0049] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STA) 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 carries traffic away from 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 sent to the AP to be delivered to the corresponding target. Traffic between STAs within the BSS may be sent by the AP, for example, wherein the source STA may send 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 sent between the source STA and the target STA (e.g., directly between them) using direct link establishment (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.

[0050] When using the 802.11ac infrastructure operation mode or a similar operation mode, the AP may transmit a beacon 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 a working 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.

[0051] High throughput (HT) STAs may communicate using a 40 MHz wide channel, for example, via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0052] 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. The stream can be mapped to two 80MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above-mentioned operation for the 80+80 configuration can be reversed, and the combined data can be sent to the medium access control (MAC).

[0053] 802.11af and 802.11ah support operating modes below 1 GHz. 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).

[0054] 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 operation 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 operation 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 (which only supports a 1MHz operation mode) is transmitting to the AP, the entire available band may be considered busy even if most of the band remains idle and may be available.

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

[0056] Figure 1D1 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.

[0057] 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 transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a may, for example, use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a. In one 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 located on an unlicensed spectrum, while the remaining component carriers may be located on a licensed spectrum. In one 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).

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

[0059] 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 evolved Node-B 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 evolved Node-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the evolved Node-B 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.

[0060] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or 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. Figure 1D As shown, gNBs 180a, 180b, and 180c may communicate with each other via an Xn interface.

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

[0062] 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 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, services for machine type communication (MTC) access, etc. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

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

[0064] 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, providing mobility anchoring, etc.

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

[0066] 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 reference to one or more of the following may be performed by one or more simulation devices (not shown): WTRU102a-d, base station 114a-b, evolved Node B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b and / or any other device described herein. The simulation device may be one or more devices configured to emulate 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.

[0067] The simulation device may be designed to implement one or more tests of other devices in a laboratory environment and / or in a carrier 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.

[0068] 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 may include one or more antennas) can be used by the simulation device to transmit and / or receive data.

[0069] References to timers herein may refer to a time, a time period, time tracking, time period tracking, combinations thereof, etc. References to expiration of a timer herein may refer to a determination that a time has occurred or a time period has expired.

[0070] Systems, methods, and means for connection management and recovery associated with a multipath sidelink relay are described herein. A relay wireless transmit / receive unit (WTRU) may provide RRC state information associated with a relay WTRU to a remote WTRU. The WTRU may receive configuration information indicating conditions for initiating a relay (re)selection or a PC5-RRC connection to the relay WTRU. Conditions may be set for initiating a transmission on a relay (e.g., secondary) path, wherein the conditions may depend on the RRC state information, cell ID, and / or QoS at the relay WTRU.

[0071] A remote WTRU (e.g., in RRC_CONNECTED) may determine whether routing to a secondary (e.g., relayed) path may be performed. Routing may be determined based on bearer QoS, the RRC state of the relay WTRU, and / or the cell ID served by the relay. The remote WTRU may receive configuration information for multipath data transmission. The configuration information may indicate a direct path (e.g., a Uu path) and / or an indirect path (e.g., via a sidelink relay, such as a relay WTRU). The remote WTRU may receive multiple (e.g., two) split bearer thresholds for (e.g., each) split bearer. The (e.g., each) split bearer threshold may be associated with state information of the relay WTRU. For example, a first threshold may be associated with an RRC connected state, and a second threshold may be associated with an RRC idle or inactive state (e.g., where the second threshold may be higher than the first threshold). The WTRU may determine a split bearer threshold, or receive an indication of a split bearer threshold. The remote WTRU may route data via both a primary path and a secondary path (e.g., via both a direct path and an indirect path, such as via splitting data between the direct path and the indirect path or duplicating data to be sent on both the direct path and the indirect path). For example, the remote WTRU may determine to use a first split bearer threshold, for example, based on receiving an indication that the relay WTRU is in an RRC connection. The remote WTRU may determine that the amount of data associated with the transmission is greater than the first split bearer threshold. Based on the determination that the amount of data is greater than the first split bearer threshold associated with the RRC connection, the WTRU may transmit the data using the indirect path. For example, the remote WTRU may determine to use a second split bearer threshold, for example, based on receiving an indication that the relay WTRU is in RRC idle / inactive. The remote WTRU may determine that the amount of data associated with the transmission is greater than the second split bearer threshold. Based on the determination that the amount of data is greater than the second split bearer threshold associated with RRC inactive / idle, the WTRU may transmit the data using the indirect path.

[0072] The remote WTRU may determine to refrain from routing data via an indirect path (eg, not route any data), for example, based on state information (eg, based on a determination that the relay WTRU is in an RRC idle or inactive state).

[0073] The remote WTRU may release its multipath configuration (eg, the configuration associated with the indirect path), for example, based on the state information (eg, based on a determination that the relay WTRU is in an RRC idle or inactive state).

[0074] Systems, methods and means for connection management and recovery associated with multipath sidelink relays are described herein. A wireless transmit / receive unit (WTRU) may perform operations associated with connection management and / or recovery in a multipath sidelink relay. In an example, the WTRU may select a path to perform connection establishment. The WTRU may notify the network of the availability of another path during establishment. Successful connection establishment over Uu may define the PC5-RRC link behavior of the WTRU. The relay WTRU may provide RRC state information associated with the relay WTRU to the remote WTRU. The WTRU may receive configuration information indicating conditions for initiating a relay (re)selection or a PC5-RRC connection to the relay WTRU. Conditions may be set for initiating transmission on a relay (e.g., secondary) path, wherein the conditions may depend on RRC state information, cell ID and / or QoS at the relay WTRU. The WTRU may, for example, initiate a Uu RRC message / process (e.g., or other process) via the relay WTRU prior to data transmission. The WTRU may initiate a process in response to receipt of a sidelink transfer indication (e.g., UuMessageTransferSidelink). The WTRU may initiate the procedure in response to detection of a sidelink radio link failure (SL-RLF), for example in response to detection of SL-RLF instead of receipt of UuMessageTransferSidelink.The relay WTRU may provide additional information to the remote WTRU for bearer reconfiguration and / or recovery.

[0075] The remote WTRU may perform transmission of an RRC message based on knowledge of the arrival conditions and the RRC state of the relay WTRU. The remote WTRU may determine the type of RRC message, for example, based on knowledge of the cell ID served by the relay, the amount of data, and / or the RRC state of the relay WTRU. The remote WTRU may be configured for multipath operation (e.g., in the case where the WTRU may send / receive data via a direct Uu path and a SL relay path). For example, the remote WTRU may determine to operate using multipath operation, receive an indication to operate using multipath operation, etc. The remote WTRU may transmit and / or receive from a direct Uu path. The remote WTRU may receive status information (e.g., in a discovery message) from the relay WTRU. The remote WTRU may be configured with a data buffering threshold. The data buffering threshold may be used to determine whether (e.g., when) to initiate transmission via the relay path. The remote WTRU may determine to initiate data transmission (e.g., UL UP data transmission) via the relay path based on Uu and / or SL measurements or the link state of the Uu (e.g., Uu RLF is triggered). Based on the decision to initiate data transmission, the remote WTRU may determine whether to initiate the transmission of an RRC message prior to data transmission, for example, based on the reason for the initiation of the data transmission (e.g., data-triggered or Uu RLF), whether the relay WTRU is served by the same or different cell as the remote WTRU, and status information from the relay (e.g., no RRC messages if / when the relay WTRU is connected, same cell situation, and transmission triggered by measurement). If the transmission of an RRC message is triggered, the remote WTRU may determine the type of RRC message (e.g., a DC-like RRC message such as MCGFailure or RRCReconfigurationComplete for different cell situations, and UEAssistanceInformation / SidelinkUEInformation for the same cell situation) based on whether the relay is served by the same cell and the reason for the initiation of the data transmission. If the transmission of the RRC message is successful, the remote WTRU may initiate data transmission via the relay path. Similar behavior may apply to the transmission of Uu RRC messages by the remote WTRU via an indirect path.

[0076] A remote WTRU (e.g., in RRC_CONNECTED) may determine a recovery action after receiving a Uu Information message from a relay WTRU, for example based on an event type and bearer configuration / quality of service (QoS) indicated by the relay WTRU. The remote WTRU may be configured for multipath operation (e.g., where the WTRU may send and / or receive data via a direct Uu path and a SL relay path). For example, the remote WTRU may determine to operate using multipath operation, receive an indication to operate using multipath operation, etc. The remote WTRU may receive and decode a Uu Information message from a relay WTRU, for example via PC5-RRC. The remote WTRU may determine a cause / value and / or type of the message. The remote WTRU may determine a bearer recovery action, whether to release the PC5-RRC connection, and / or notify the network, for example based on an event type and bearer configuration / QoS in a Uu Information message received from the remote WTRU. The remote WTRU may suspend bearers (e.g., all bearers) configured via a relay path or a relay path of a split bearer and transmit data (e.g., all data) via Uu, for example, in the case where a HO indication may be received from the relay WTRU. If a connection establishment failure or Uu RLF is received from the relay, the remote WTRU may perform the following operations: release bearers (e.g., all bearers) configured via a relay path or a relay path of a split bearer and transmit data (e.g., all data) via Uu; release the PC5-RRC connection; notify the network of the connection establishment failure or Uu RLF via an uplink Uu RRC message; and the like. The remote WTRU may suspend bearers (e.g., all bearers) configured via a relay path or a relay path of a split bearer and notify the network of cell reselection (e.g., via an uplink Uu RRC message), for example, in the case where a cell reselection indication is received from the relay WTRU.

[0077] A remote WTRU (e.g., in RRC_CONNECTED) may determine whether routing to a secondary (e.g., relayed) path may be performed. Routing may be determined based on bearer QoS, the RRC state of the relay WTRU, and / or the cell ID served by the relay. The remote WTRU may be configured to receive multiple (e.g., two) split bearer thresholds for (e.g., each) split bearer. The WTRU may determine the split bearer threshold, or receive an indication of the split bearer threshold. The remote WTRU may be configured (e.g., for each bearer) with information indicating whether routing via a secondary path with a different cell ID is allowed. For example, the remote WTRU may receive the information, determine the information, etc. The remote WTRU may route data via both the primary path and the secondary path. For example, if the amount of data for the bearer is above the first split bearer threshold, the relay WTRU is in RRC connection, and the cell ID serving the relay WTRU is the same as the cell ID serving the remote WTRU or for the bearer for allowing data to be routed via the path served by the cell ID. The remote WTRU may be configured to route data via both the primary path and the secondary path. For example, if the amount of data for the bearer is above a second split bearer threshold, and if the cell ID serving the relay WTRU is the same as the cell ID serving the remote WTRU or for the bearer allowing routing of data via the path served by the cell ID, the remote WTRU may be configured to route the data to the primary path (e.g., only the primary path), for example, in other ways.

[0078] Uplink transmissions may be delayed and / or suspended. For example, the remote WTRU may delay and / or suspend UL transmissions to ensure that the connection establishment of the relay WTRU may be successful.

[0079] The RRC connection may be initiated, for example, by a relay WTRU. The relay WTRU may determine a trigger associated with initiating the RRC connection. For example, the trigger condition may be based on one or more of: whether multipath is configured, an indication received from a corresponding remote WTRU, or network signaling.

[0080] In multipath operation, the WTRU may determine which path to use to transmit a message (e.g., a UL RRC message). For example, the WTRU may autonomously change the primary path used for transmission (e.g., based on a condition). The WTRU may autonomously change the primary path used for transmission based on a trigger (e.g., a predefined trigger). When in multipath operation, the WTRU may autonomously change the Pcell (e.g., based on a condition). The WTRU may report to the network a relay connected to one or more cells. The WTRU may change the primary path of the SRB, for example, based on receiving a message from a relay WTRU. The WTRU may initiate a process associated with a Uu path (e.g., similar to a reestablishment), for example, based on receiving a message from a relay WTRU.

[0081] A failure procedure may be enabled and / or implemented. A failure procedure may be associated with a message (e.g., a ReconfigurationComplete message) that was not successfully sent. For example, the WTRU may initiate a failure procedure based on determining that a ReconfigurationComplete message was unsuccessfully sent.

[0082] A re-establishment (eg, a re-establishment procedure) may be performed. For example, the re-establishment may be initiated (eg, by a remote WTRU) based on a failed path addition. The re-establishment procedure (eg, actions) may depend on the selected path and / or cell relationship.

[0083] Relays may be used, such as WTRU to network relays, and / or WTRU to WTRU relays (eg, based on PC5 / sidelink).

[0084] Sidelink operations (e.g., NR sidelink) may be used, for example, to support (e.g., V2X-related) road safety services. Sidelink operations may provide support for broadcast, multicast, and / or unicast communications in both out-of-coverage scenarios and in-network coverage scenarios. Sidelink-based relay functionality may be improved, for example, including sidelink / network coverage extension and power efficiency improvements (e.g., to allow for a wider range of applications and services).

[0085] Coverage extension for sidelink-based communications may be enabled. For example, coverage extension for sidelink-based communications may include WTRU-to-network coverage extension. The WTRU may use (e.g., may require) Uu coverage reachability to reach a server in the PDN network or a corresponding WTRU outside a neighboring area. WTRU-to-network relaying may be limited (e.g., limited to EUTRA-based technologies) and may not be applicable to NR-based systems (e.g., for both NG-RAN and NR-based sidelink communications).

[0086] For example, coverage extension for sidelink-based communications may include WTRU-to-WTRU coverage extension. Proximity reachability may use (e.g., may be limited to) a single-hop sidelink, for example, via an EUTRA-based or NR-based sidelink technology. A single-hop sidelink may not be sufficient, for example, in situations where there is no Uu coverage (e.g., considering limited single-hop sidelink coverage).

[0087] Sidelink connectivity may be extended (e.g., in the NR framework), for example, to support enhanced quality of service (QoS) requirements.

[0088] Scheduling assignment (SA) requirements may be supported, e.g., for sidelink-based WTRU-to-network and / or WTRU-to-WTRU relaying. SA requirements may be supported, e.g., focusing on one or more of the following (e.g., for layer 3 relay and layer 2 relay): relay (re)selection criteria and procedures; relay / remote WTRU authorization; QoS for relay functionality; service continuity; security of relay connections (e.g., after SA3 has provided its conclusion); and impact on user plane protocol stacks and control plane procedures (e.g., connection management of relay connections).

[0089] The upper layer operation of the discovery model or process for sidelink relay may be changed. This may be done, for example, by assuming that there may be no new physical layer channels or signals.

[0090] A relay system may be used between the wireless transceiver and the network. Relay (e.g., via a ProSe WTRU-to-network relay) may be used to extend network coverage to WTRUs that may be out of the WTRU's coverage, for example, by using PC5 (e.g., device-to-device (D2D) communication / link) between the out-of-coverage WTRU and the WTRU-to-network relay.

[0091] A WTRU-to-network relay (e.g., a ProSe WTRU-to-network relay) may provide forwarding functionality (e.g., a generic L3 forwarding functionality) that may relay IP traffic (e.g., any type of IP traffic) between a remote WTRU and a network. One-to-one and one-to-many sidelink communications may be used between a remote WTRU and a WTRU-to-network relay (e.g., a ProSe WTRU-to-network relay). For both the remote WTRU and the relay WTRU, (e.g., only one single) carrier (e.g., a public safety ProSe carrier) operation may be supported (e.g., Uu and PC5 may be the same carrier for the relay / remote WTRU). The remote WTRU may be authorized (e.g., by upper layers) and may be within the coverage of a public safety ProSe carrier or outside the coverage of any supported carrier, e.g., including a public safety ProSe carrier for WTRU-to-network relay discovery, (re)selection and / or communication. The ProSe WTRU-to-network relay may be within the coverage of the EUTRAN (e.g., always in coverage). The ProSe WTRU to network relay and remote WTRU may perform sidelink communication and / or sidelink discovery (eg, as described herein).

[0092] Relay selection may be performed, for example, for WTRU to network (NW) relaying.

[0093] Relay selection / reselection (eg, for ProSe WTRU to NW relay) may be performed based on a combination of (eg, AS layer quality) measurements (eg, RSRP) and criteria (eg, upper layer criteria), for example, as described herein.

[0094] The eNB may control whether a WTRU may act as a ProSe WTRU to network relay. ProSe WTRU to network relay operation may be supported (e.g., in a cell), e.g., in a scenario where the eNB broadcasts information (e.g., any information) associated with the ProSe WTRU to network relay operation. The eNB may provide one or more of: transmission resources for ProSe WTRU to network relay discovery (e.g., using broadcast signaling for RRC_IDLE state and dedicated signaling for RRC_CONNECTED state); reception resources for ProSe WTRU to network relay discovery (e.g., using broadcast signaling); minimum and / or maximum Uu link quality (RSRP) thresholds (e.g., via broadcast) that the ProSe WTRU to network relay may consider (e.g., need to comply with), e.g., before it may initiate a WTRU to network relay discovery procedure; etc. The WTRU may use the threshold to start or stop (e.g., autonomously start or stop) the WTRU to network relay discovery procedure (e.g., while in RRC_IDLE), for example, in the case where (e.g., when) the eNB broadcasts the transmission resource pool. The WTRU may use the threshold to determine whether it can indicate to the eNB that it is a relay WTRU and wishes to initiate ProSe WTRU to network relay discovery, for example, while in RRC_CONNECTED.

[0095] The WTRU may initiate a request for ProSe-WTRU to network relay (ProSe UE to network relay) discovery resources (e.g., via dedicated signaling) while taking into account (e.g., complying with) a broadcast threshold, for example, in a scenario where the eNB prohibits broadcasting (e.g., does not broadcast) a transmission resource pool for ProSe-WTRU to network relay discovery.

[0096] The WTRU may perform ProSe WTRU to network relay discovery (e.g., if / when in RRC_IDLE), for example, in case a ProSe-WTRU to network relay is initiated (e.g., by broadcast signaling). The WTRU may perform relay discovery (e.g., as long as it is in RRC_CONNECTED), for example, in case a ProSe WTRU to network relay is initiated (e.g., by dedicated signaling).

[0097] A ProSe WTRU to network relay that performs sidelink communication for ProSe WTRU to network relay (e.g., ProSe UE to network relay) operation may be in (e.g., must be in) RRC_CONNECTED. The ProSe WTRU to network relay may indicate to the eNB that the ProSe WTRU to network relay may be a ProSe WTRU to network relay and that it intends to perform ProSe WTRU to network relay sidelink communication, e.g., based on (e.g., after) receiving a setup request (e.g., a layer 2 link setup request) or a monitoring request (e.g., a temporary mobile group identity (TMGI) monitoring request, e.g., via an upper layer message) from a remote WTRU. The eNB may provide resources for ProSe WTRU to network relay communication.

[0098] The remote WTRU may decide to monitor (e.g., when to start monitoring) for ProSe WTRU to network relay discovery. The remote WTRU may transmit a ProSe WTRU to network relay discovery request message (e.g., while in RRC_IDLE or in RRC_CONNECTED), e.g., depending on the configuration of resources for ProSe WTRU to network relay discovery. The eNB may broadcast a threshold value that the remote WTRU may use to determine whether it may transmit a ProSe WTRU to network relay discovery request message, e.g., to connect with a ProSe WTRU to network relay WTRU or to communicate with a ProSe WTRU to network relay WTRU. The remote WTRU (e.g., an RRC_CONNECTED remote WTRU) may use the broadcasted threshold value to determine whether it may indicate to the eNB that it is a remote WTRU and wants to participate in ProSe WTRU to network relay discovery and / or communication. The eNB may use broadcast or dedicated signaling to provide transmission resources and use broadcast signaling to provide reception resources for ProSe WTRU to network relay operation. The remote WTRU may refrain from using (e.g., stop using) the ProSe WTRU to network relay discovery and communication resources, for example, in the event that (e.g., when) the RSRP exceeds a broadcast threshold. For example, the time (e.g., the precise time) associated with a service switch (e.g., from Uu to PC5 or vice versa) may be determined (e.g., by higher layers).

[0099] The remote WTRU may, for example, perform measurements (e.g., radio measurements) at a PC5 interface. The remote WTRU may use the measurements (e.g., together with higher layer criteria) for ProSe WTRU to network relay selection and reselection. A ProSe WTRU to network relay may be considered suitable (e.g., in terms of radio criteria), for example, in a situation where the PC5 link quality exceeds a configured threshold (e.g., pre-configured or provided by the eNB). The remote WTRU may select a ProSe WTRU to network relay that meets the criteria (e.g., higher layer criteria) and has the best PC5 link quality (e.g., among all suitable ProSe WTRU to network relays).

[0100] The remote WTRU may trigger ProSe WTRU to network relay reselection, for example, based on one or more of the following: when the current ProSe WTRU to network relay PC5 signal strength is lower than a configured signal strength threshold; when the remote WTRU receives a release message (e.g., a layer 2 link release message, such as an upper layer message), for example, from the ProSe WTRU to the network relay; and the like.

[0101] WTRU to network relay may be used for wearable devices.

[0102] WTRU to NW relay can be used for commercial use cases tailored for wearable devices and IoT devices. The WTRU to NW relay for wearable devices can be an L2 relay (e.g., based on Figure 2 and Figure 3 ), for example, as opposed to ProSe WTRU to NW relaying which may use an L3 (IP layer) relay approach.

[0103] Figure 2 An example user plane radio protocol stack for a Layer 2 evolved WTRU to network relay (PC5) is illustrated.

[0104] Figure 3 An example control plane radio protocol stack for a Layer 2 Evolved WTRU to Network Relay (PC5) is illustrated.

[0105] Connection establishment for unicast links (e.g., in NR V2X) may be enabled.

[0106] Relay operation may be enabled, for example, based on a one-to-one communication link (e.g., established at an upper layer (ProSe layer)) between two WTRUs (e.g., a remote WTRU and a WTRU-to-NW relay). Such a connection may be transparent (e.g., to the AS layer and connection management signaling), and the procedures performed (e.g., at an upper layer) may be carried by a data channel (e.g., an AS layer data channel). For example, the AS layer may not be aware of such a one-to-one connection.

[0107] The AS layer may support unicast links between two WTRUs (e.g., in NR V2X). Such unicast links may be initiated (e.g., by upper layers), for example, as in a ProSe one-to-one connection. The AS layer may be informed of the existence of such unicast links and / or data (e.g., any data) that may be transmitted between peer WTRUs in a unicast manner. With such knowledge, the AS layer may support HARQ feedback, CQI feedback, and / or power control schemes that may be specific to unicast.

[0108] A unicast link (e.g., at the AS layer) may be supported (e.g., possibly via a PC5-RRC connection). A PC5-RRC connection may be defined, for example, based on the following. A PC5-RRC connection may be a logical connection between a source layer 2ID and a target layer 2ID pair (e.g., in an AS). A (e.g., one) PC5-RRC connection may correspond to a (e.g., one) PC5 unicast link. PC5-RRC signaling may be initiated, for example, based on its corresponding PC5 unicast link establishment (e.g., after its corresponding PC5 unicast link establishment). The PC5-RRC connection and the corresponding sidelink SRB and sidelink DRB may be released, for example, when (e.g., when) the PC5 unicast link (e.g., as indicated by an upper layer) is released.

[0109] For (e.g., each) PC5-RRC connection that is unicast, (e.g., one) sidelink SRB may be used to transmit PC5-S messages, e.g., before PC5-S security has been established. (e.g., one) sidelink SRB may be used to transmit PC5-S messages, e.g., to establish PC5-S security. (e.g., one) sidelink SRB may be used to transmit PC5-S messages, e.g., after PC5-S security has been established (e.g., the PC5-S security may be protected). (e.g., one) sidelink SRB may be used to transmit PC5-RRC signaling, e.g., the signaling may be protected and sent after PC5-S security has been established (e.g., only sent after PC5-S security has been established).

[0110] PC5-RRC signaling may include a sidelink configuration message (e.g., RRCReconfigurationSidelink), for example, where a (e.g., one) WTRU may configure RX related parameters of (e.g., each) SLRB in a peer WTRU. Such reconfiguration message may configure parameters for each protocol, for example, in an L2 stack (e.g., SDAP, PDCP, etc.). The receiving WTRU may confirm or reject such configuration, for example, depending on whether it can support the configuration suggested by the peer WTRU.

[0111] RRC behavior / state and WTRU behavior (e.g., corresponding WTRU behavior) may be provided. A WTRU may be characterized by its behavior / RRC state, for example, the RRC state may be RRC_CONNECTED, RRC_INACTIVE, or RRC_IDLE. The WTRU behaviors associated with these states may be as follows. The WTRU behaviors associated with RRC_IDLE may include one or more of the following: PLMN selection; broadcast of system information; cell reselection mobility; paging for mobile terminated data (e.g., which may be initiated by 5GC); DRX for CN paging (e.g., which may be configurable by NAS); etc. WTRU behaviors associated with RRC_INACTIVE may include one or more of the following: PLMN selection; broadcast of system information; cell reselection mobility; paging (e.g., initiated by NG-RAN), such as RAN paging; RAN-based notification area (RNA) managed by NG-RAN; DRX for RAN paging (e.g., configurable by NG-RAN); a 5GC-NG-RAN connection (e.g., both C-plane / U-plane) may be established for the WTRU; WTRU AS context may be stored (e.g., in NG-RAN and WTRU); NG-RAN may know the RNA to which the WTRU belongs; and the like. WTRU behaviors associated with RRC_CONNECTED may include one or more of the following: a 5GC-NG-RAN connection for the WTRU may be established (e.g., both C-plane / U-plane); the WTRU AS context may be stored (e.g., in the NG-RAN and the WTRU); the NG-RAN may know the cell to which the WTRU belongs; transmission of unicast data to / from the WTRU; network controlled mobility (e.g., including measurements).

[0112] SL WTRU to NW relay may involve an out of coverage (OOC) remote WTRU. The remote WTRU may operate in multipath, for example, in (e.g., when) in coverage (e.g., one path is through direct Uu and another path may be via SL WTRU to NW relay). Operating in multipath may allow the remote WTRU to use both relay paths and non-relay paths in a more flexible manner.

[0113] For multipath, at the remote WTRU, a PDCP entity for each bearer (e.g., a single PDCP entity per bearer) may be configured and associated with two different RLC entities. For example, one entity may be associated with Uu and the other entity may be associated with SL. The (e.g., common) PDCP entity may route data to either RLC entity (e.g., similar to in dual connectivity, e.g., as in Figure 2 as shown in .

[0114] Compared to dual connectivity (DC), multipath may have differences. For example, (e.g., in multipath), the two paths may be served by the same cell or different cells (e.g., different scheduling entities). This may make certain DC RRC procedures unnecessary for the same cell case, or different procedures may be used (e.g., required), e.g., specifically for error handling, path selection, and path configuration.

[0115] In multipath, the relay path may experience mobility and / or error conditions at the relay WTRU, of which the remote WTRU may be informed. RRC features for these conditions may be used (e.g., required), which, for example, do not exist for legacy DC.

[0116] In multipath, active data transmission may be maintained, for example, when a relay WTRU of a PC5-RRC connection is in RRC_IDLE / RRC_CONNECTED. Keeping a relay WTRU in RRC_CONNECTED may not be feasible, for example, in a situation where (e.g., when) a remote WTRU has a direct path to the network. Data routing rules and state transition triggers may be used (e.g., required) to handle relay WTRUs in different RRC states.

[0117] Multipath connection management may be enabled and / or performed (e.g., based on multipath configuration information). A remote WTRU in a multipath may refer to a remote WTRU served by a network node (e.g., a gNB) or by another WTRU (e.g., in the case of V2X), for example, where the remote WTRU may send / receive data to its target (e.g., via multiple paths). The path (e.g., one such path) may be a direct path, such as a Uu path (e.g., for a case where the service may be provided by a gNB), for example, where the remote WTRU is within coverage. The path (e.g., another path) may be via an SL relay (e.g., a relay WTRU). In an example, the paths (e.g., a direct Uu path and an indirect SL path) may be indicated by configuration information, for example, as multipath data transmission information. In an example, the remote WTRU may be served by a gNB (e.g., such as via a single Uu path and a single SL relay path). Figure 4A and Figure 4B ). The operation may be applied to additional situations in an extended case, such as, for example: multiple (e.g., more than two) direct and / or relay paths; multiple direct (e.g., only direct) paths; multiple relay (e.g., only relay) paths; a relay path may be a path of a multi-hop path; and the like.

[0118] Multiple paths can be modeled.

[0119] For modeling of multipath, a PDCP entity at a WTRU (e.g., a single PDCP entity) may be configured (e.g., via multipath configuration information) with multiple (e.g., two) different RLC entities (e.g., one RLC entity for a direct Uu path and one RLC entity for a SL path via a SL WTRU to a NW relay). A bearer (e.g., a single bearer) configured with multiple (e.g., two) paths may be served by the same cell or different cells in the network (e.g., as described for Figure 4A and Figure 4B ), for example, depending on the cell served by the relay.

[0120] Figure 4A An example is illustrated in which multiple paths are carried out by the same cell.

[0121] Figure 4B An example of multiple paths in which bearers may be served by different cells is illustrated.

[0122] A connection establishment process may be performed.

[0123] The WTRU may select a path to perform the connection establishment. In an example, the WTRU may select a path to initiate the connection establishment based on, for example, one or more of: Uu and / or SL measurements; whether a PC5-RRC connection with the relay can be established (e.g., has been established); the RRC state of the relay WTRU for which the remote WTRU has a PC5-RRC connection; the RRC state of the remote WTRU; the QoS and / or configuration of the bearers (e.g., any bearers) that may be configured at the remote WTRU; whether the relay WTRU may connect to the same / different cell; etc.

[0124] For example, the WTRU may select a path for initiating connection establishment based on Uu and / or SL measurements. For example, other conditions (e.g., as described herein) for selecting a path may depend on whether the Uu measurements (e.g., for a direct link) and / or the SL measurements (e.g., to a relay WTRU) are above a threshold. For example, a relay WTRU may broadcast (e.g., in discovery) or provide (e.g., in a PC5-RRC message) information about the measurements of its own Uu link, which may, for example, modify the conditions (e.g., as described herein) for the remote WTRU to select a Uu or relay SL path.

[0125] For example, the WTRU may select a path over which to initiate connection establishment based on whether a PC5-RRC connection with the relay can be established (e.g., has already been established). For example, a remote WTRU within coverage may initiate connection establishment (e.g., only) via Uu, for example, unless it has a PC5-RRC connection established with the relay. In the event that a PC5-RRC connection can be established with the relay, the remote WTRU may initiate the connection via either path, or it may use other rules (e.g., as described herein) to determine which path to establish the connection via.

[0126] For example, the WTRU may select a path over which to initiate connection establishment to a relay WTRU to which the remote WTRU has a PC5-RRC connection based on the RRC state of the relay WTRU to which the remote WTRU has a PC5-RRC connection. For example, a remote WTRU within coverage may initiate connection establishment (e.g., only) via Uu, for example, unless the relay WTRU of the PC5-RRC connection is in RRC_CONNECTED. In the case of an RRC_CONNECTED relay WTRU, the remote WTRU may initiate connection via either path or may use other rules (e.g., as described herein) to determine which path to establish the connection via.

[0127] For example, the WTRU may select a path for initiating a connection establishment to the remote WTRU based on the RRC state of the remote WTRU. For example, a remote WTRU in RRC_INACTIVE may determine a path for connection establishment based on the QoS / configuration of a bearer (e.g., a bearer whose data arrival may trigger the connection establishment). A remote WTRU in RRC_IDLE may refrain from using (e.g., not using) QoS related conditions (e.g., any QoS related conditions) to determine a path on which to establish an RRC connection.

[0128] For example, the WTRU may select a path for which to initiate connection establishment based on the QoS and / or configuration of (e.g., any) bearers configured at the remote WTRU. The remote WTRU may determine the path and / or the rules to apply to select the path, for example, based on the configured bearers or bearers on which data (e.g., UL data) has arrived. For example, the remote WTRU may be configured with bearers (e.g., specific bearers) that prioritize or allow connections via a path (e.g., only one path, such as Uu only when both paths are available).

[0129] The WTRU may notify the NW of the availability of another path during establishment. In an example, a WTRU (e.g., a remote WTRU) may notify the NW of the availability of another path. The remote WTRU may notify the NW of the availability of another path during connection establishment signaling. For example, during connection establishment / recovery (e.g., which may occur via Uu), the remote WTRU may notify the network of the PC5-RRC connection with the potential relay WTRU. The remote WTRU may (e.g., alternatively) notify the network that the PC5-RRC connection is released (e.g., when the remote WTRU is in IDLE / INACTIVE) or is changed (e.g., from one relay to another). For example, the remote WTRU may report (e.g., in a connection establishment / resumption completion message, a connection / resumption request, or similar / subsequent RRC messages) one or more of the following information: the presence / absence of a PC5-RRC connection with the relay (e.g., the connection with the relay may be a PC5-RRC or may be any other connection that may allow the remote WTRU to be scheduled in a multipath, and such a connection may be statically configured (e.g., via RRC signaling, upper layer signaling), or may be the result of a discovery operation); a relay WTRU ID (e.g., an L2 ID); an ID of a cell to which the relay WTRU can connect; measurements on the PC5-RRC; the RRC state of the relay WTRU; information about the protocol stack between the remote WTRU and the relay WTRU (e.g., whether an adaptation layer can be supported, supported data segmentation types (e.g., DC class at the PDCP, LWIP class at the IP layer, segmentation at the RLF, etc.)); and the like.

[0130] The remote WTRU may notify the network of the relay WTRU connection. The remote WTRU may, for example, notify the network based on connection establishment / restore with the network. The remote WTRU may (e.g., alternatively) notify the network based on establishment / release of the relay WTRU's connection.

[0131] A successful connection establishment over Uu may define the PC5-RRC link behavior of the WTRU. In an example, a remote WTRU with a PC5-RRC connection may maintain / release the PC5-RRC connection, for example, based on whether the Uu connection establishment may be successful and / or based on other factors associated with the Uu connection establishment, such as one or more of the following: bearer / QoS configuration (e.g., that may be obtained after the connection establishment); Uu / SL measurements; NW indication (e.g., explicit NW indication); the cell serving the relay compared to the cell serving the remote WTRU; the RRC state of the relay WTRU; etc.

[0132] After the remote WTRU's connection establishment attempt via Uu, the remote WTRU may release the PC5-RRC connection, for example, in the case where the bearers configured after establishment are such that the remote WTRU does not perform (e.g., needs to) maintain the PC5-RRC connection. The remote WTRU may be configured with a set of conditions (e.g., as described herein) that may cause the remote WTRU to release the PC5-RRC connection (e.g., after the remote WTRU successfully establishes a Uu RRC connection).

[0133] The path configuration process may be executed and / or enabled. The SL path may be enabled.

[0134] The relay WTRU may provide (eg, via indication) RRC state information of the relay WTRU to one or more remote WTRUs.

[0135] The relay WTRU may transmit such state information (e.g., explicitly). For example, the relay WTRU may transmit an indication of an RRC state (e.g., a first value for an indication of RRC_IDLE or no indication, a second value for an indication of RRC_INACTIVE or no indication, and a third value for an indication of RRC_CONNECTED or no indication). For example, the relay WTRU may transmit an indication (e.g., an explicit indication) of whether the WTRU is in a particular RRC state. For example, the relay WTRU may send a first value for an indication or no indication (e.g., if the relay WTRU is in RRC_CONNECTED), and may send a second value for an indication or no indication (e.g., in a situation where the relay WTRU is not in RRC_CONNECTED).

[0136] The relay WTRU may (e.g., implicitly) transmit such state information. For example, the relay WTRU may indicate one or more of the following to the remote WTRU, which may implicitly provide (e.g., indicate) the RRC state of the relay WTRU to the remote WTRU. The relay WTRU may perform one or more of the following (e.g., if / when the RRC state changes): indicate to the remote WTRU whether to monitor paging via Uu; indicate to the remote WTRU whether to request SI from the relay or from Uu; indicate to the remote WTRU whether to request SI using a dedicated SIB request or an SI request (e.g., via the relay); provide the remote WTRU with SL DRX configuration information and / or assistance information; indicate to the remote WTRU whether to suspend the relay path; etc.

[0137] The relay WTRU may indicate to the remote WTRU whether to monitor for paging via Uu (e.g., if / when the RRC state changes). For example, if (e.g., when) the relay WTRU moves to RRC_CONNECTED, it may indicate to the remote WTRU to monitor for paging via Uu. If (e.g., when) the relay WTRU moves to RRC_IDLE / RRC_INACTIVE, the relay WTRU may indicate to the remote WTRU that monitoring for paging via Uu is prohibited (e.g., not monitoring) and / or receiving paging via SL.

[0138] The relay WTRU may indicate to the remote WTRU (e.g., if / when the RRC state changes) whether to request SI from the relay or from Uu. For example, if (e.g., when) the relay WTRU moves to RRC_CONNECTED, it may indicate to the remote WTRU that the SI is requested (e.g., directly via Uu). If (e.g., when) the relay WTRU moves to RRC_INACTIVE / RRC_IDLE, it may indicate to the remote WTRU that it may request SI via the relay WTRU.

[0139] The relay WTRU may (e.g., if / when the RRC state changes) indicate to the remote WTRU whether to request SI using a dedicated SIB request or an SI request (e.g., via the relay). For example, if (e.g., when) the relay WTRU moves to RRC_CONNECTED, it may indicate to the remote WTRU (e.g., via dedicatedSIBRequest) that SI is requested. Otherwise, the relay WTRU may indicate to the remote WTRU that SI is requested via an SI request.

[0140] The relay WTRU may provide SL DRX configuration information and / or assistance information to the remote WTRU (e.g., if / when the RRC state changes). For example, if (e.g., when) the relay WTRU moves to RRC_IDLE / RRC_INACTIVE, it may use the configuration information (e.g., PC5-RRC configuration to initiate SL DRX) or it may transmit assistance information for SL DRX configuration. If (e.g., when) the relay WTRU moves to RRC_CONNECTED, it may cancel / release any previously configured SL DRX configuration.

[0141] The relay WTRU may indicate to the remote WTRU (e.g. if / when the RRC state changes) whether to suspend the relay path. For example, if (e.g. when) the relay WTRU moves to RRC_IDLE / RRC_INACTIVE, it may initiate a PC5-RRC message indicating that the remote WTRU should suspend the relay path for the bearer and (e.g. only) use the Uu path. Such indication may be used by the remote WTRU to suspend the relay path / leg of (e.g. any) split bearer or to suspend (e.g. any) bearer that may be (e.g. completely) operable on the relay path. If (e.g. when) the relay WTRU moves to RRC_CONNECTED, it may initiate a PC5-RRC message to resume / enable such bearer. The remote WTRU may use such indication as an implicit indication of the RRC state of the relay WTRU.

[0142] The relay WTRU may provide RRC status information using one or more of the following: discovery messages, PC5-RRC messages, control PDUs (eg, adaptation layer control PDUs), SCI, control elements (eg, PC5 MAC CEs), etc.

[0143] The relay WTRU may provide (e.g., periodically or regularly) status information (e.g., such as in the transmission of a discovery message). The relay WTRU may (e.g., alternatively) provide status information, for example, when (e.g., when) status information (e.g., or information as described herein) changes.

[0144] The WTRU may be configured with conditions for initiating relay (re)selection or a PC5-RRC connection to a relay WTRU.

[0145] In an example, the remote WTRU may be configured with conditions to perform relay (re)selection, initiate a PC5-RRC connection, or initiate / use a SL relay or relay path. Such conditions may be configured and / or met, for example, in the case where (for example, when) the WTRU may be within the coverage of Uu and / or is configured with another SL relay path. Such conditions may be monitored if (for example, when) the WTRU is in (for example, any) RRC state. The condition may be associated with one or more of the following conditions: data-based conditions (for example, if the amount of data available for transmission at the WTRU is above a threshold, the remote WTRU may initiate relay selection); Uu measurements and / or PC5 measurements (for example, if the measured Uu RSRP is below a threshold, the remote WTRU may initiate relay selection, where in the example the measurement conditions may be combined with the data-based conditions); triggers based on Uu mobility; and the like.

[0146] The condition may be associated with a trigger based on Uu mobility (e.g., performing relay (re)selection, initiating PC5-RRC connection, or initiating / using SL relay or relay path). For example, the remote WTRU may receive (e.g., may be configured with) a condition to initiate a relay (re)selection procedure and / or a PC5-RRC connection procedure and / or a PC5-RRC release procedure, for example, based on a mobility trigger (e.g., HO, re-establishment to a different cell, CHO, etc.). Such conditions and corresponding WTRU behavior may depend on (e.g., further depend on) the RRC state of the remote WTRU. Such conditions and corresponding WTRU behavior may depend on (e.g., further depend on) the cell ID, gNB ID, cell list, or the like associated with the direct cell and the cell to which the relay WTRU may be attached.

[0147] A remote WTRU in RRC CONNECTED may have a PC5-RRC connection with a WTRU that may act as a relay WTRU. The remote WTRU may release the PC5-RRC connection and initiate a relay reselection procedure, for example, based on receipt of a handover (HO) command (e.g., via a direct link). The remote WTRU may receive (e.g., be configured with) conditions (e.g., as described herein) on whether to perform such reselection based on HO.

[0148] The remote WTRU in RRC_CONNECTED may determine whether to release the PC5-RRC connection and / or trigger relay (re)selection. The determination to release the PC5-RRC connection and / or trigger relay (re)selection may, for example, be based on whether a handover (HO) may be performed to the same cell to which the current relay may be connected. The remote WTRU may maintain the PC5-RRC connection, for example, in the case where the HO may be to the same cell. The remote WTRU may release the PC5-RRC connection and / or perform relay reselection and / or initiate reporting of relay measurements, for example, in the case where the HO may be to a different cell.

[0149] The remote WTRU in RRC_CONNECTED may determine whether to release the PC5-RRC connection and / or trigger relay (re)selection. For example, this may be based on whether the HO is performed to potentially related cells (e.g., in the same configured cell group or configured area) and / or whether these cells belong to the same gNB.

[0150] The remote WTRU may receive (e.g., in a HO / reconfiguration command) an indication whether to release an existing PC5-RRC connection, initiate a PC5-RRC connection to a new relay (which may be provided in the HO command), initiate measurements / reporting to other relays, or a combination of these. The WTRU may restrict (e.g., any) measurements or measurement reports to relays whose cells are part of the same gNB / group as the cell on the direct Uu link. The WTRU may restrict measurements or measurement reports, for example, to relays whose cells may be the same as the cell on the direct Uu link. The remote WTRU may perform the restriction of measurements, for example, where in this case: it is indicated (e.g., via a flag) in the HO command.

[0151] A remote WTRU in RRC_CONNECTED may trigger a relay reselection procedure, for example, based on a HO from one cell to another.

[0152] The conditions for initiating transmission on a relay (eg, secondary) path (eg, an indirect path, such as, for example, a path using a relay WTRU) may depend on RRC state information, cell ID, and / or QoS at the relay WTRU.

[0153] In an example, a relay WTRU having a direct Uu link (e.g., a direct path) for data transmission / reception may determine conditions for initiating transmission / routing on a secondary (possibly relayed) link based on one or more of: the RRC state of the relay WTRU, the cell ID of the relay (e.g., compared to the cell served by the remote WTRU), the QoS of the bearer configured at the remote WTRU, and / or the use of data available for transmission; etc.

[0154] Figure 5 An example of determining a transmission path using status information is illustrated.

[0155] In an example, a remote WTRU having a direct Uu link for data transmission / reception may determine conditions (e.g., such as sending duplicate data via both direct and indirect paths, splitting data between direct and indirect paths, or sending data via (e.g., only) the indirect path) for initiating transmission / routing on a secondary (potentially relay) link based on the RRC state of the relay WTRU (e.g., sending duplicate data via both direct and indirect paths, splitting data between direct and indirect paths, or sending data via (e.g., only) the indirect path). Figure 5 For example, Figure 5 As shown, if (e.g., when) the relay WTRU may be in an RRC connection (e.g., if the determined amount of data available for transmission exceeds a first threshold associated with the RRC connection state, such as Figure 5 ), the remote WTRU may be configured with (e.g., receives configuration information, such as multipath transmission configuration information, indicating) a first condition (e.g., in terms of the amount of data available for transmission that may initiate the use of the secondary path), and if (e.g., when) the relay WTRU may be in IDLE / INACTIVE (e.g., if the determined amount of data available for transmission exceeds a second threshold associated with an RRC idle or inactive state, such as Figure 5 ), the remote WTRU may be configured with (e.g., receives configuration information, such as multipath transmission configuration information, indicating) a second condition. For example, the WTRU may select a split bearer threshold (e.g., condition) based on the indicated state information associated with the relay WTRU (e.g., the split bearer threshold may be determined as a first threshold / condition associated with a relay WTRU in an RRC connected state, and the split bearer threshold may be determined as a second threshold / condition associated with a relay in an RRC inactive or idle state, such as Figure 5). The WTRU may determine that for a relay WTRU indicated as being in an RRC connected state, the amount of data exceeds a first threshold associated with the RRC connected state, and based on the determination that the amount of data exceeds the first threshold, the remote WTRU may use an indirect path (e.g., via the relay WTRU) to transmit the data. The WTRU may determine that for a relay WTRU indicated as being in an RRC idle / inactive state, the amount of data exceeds a second threshold associated with the RRC idle / inactive state, and based on the determination that the amount of data exceeds the first threshold, the remote WTRU may use an indirect path (e.g., via the relay WTRU) to transmit the data. The second threshold associated with the RRC inactive / idle state may be higher than the first threshold associated with the RRC connected state (e.g., to avoid switching the SL relay to a connected state for short data bursts). If (e.g., only or only when) the data available for transmission may be associated with a specific bearer, the remote WTRU may be allowed to route the data to a secondary path if (e.g., when) the relay WTRU is in RRC_IDLE / RRC_INACTIVE. A WTRU may be configured with a first bearer or bearer type, wherein the first bearer or bearer type may allow routing to a secondary path for an RRC_IDLE / INACTIVE relay, and a second bearer or bearer type, wherein routing to the secondary path may be performed (e.g., only performed) for the second bearer or bearer type if (e.g., when) the relay WTRU is in RRC_CONNECTED. For example, if the remote WTRU triggers Uu RLF, it may initiate data transmission via the secondary path (e.g., as long as the relay WTRU is in RRC_CONNECTED). Otherwise, if the relay WTRU is in RRC_IDLE / RRC_INACTIVE, the remote WTRU may trigger a re-establishment or CHO, for example, based on triggering the Uu RLF.

[0156] In an example, a relay WTRU having a direct Uu link for data transmission / reception may determine conditions for initiating transmission / routing on a secondary (potentially relayed) link based on the cell ID of the relay (e.g., compared to the cell served by the remote WTRU). If (e.g., when) the relay WTRU is served by the same cell as the remote WTRU, the remote WTRU may be configured with a first condition (e.g., in terms of the amount of data available for transmission that may initiate use of the secondary path), and if (e.g., when) the relay WTRU is served by a different cell than the remote WTRU, the remote WTRU may be configured with a second condition. If (e.g., when) the relay WTRU may be served by the same cell ID as the remote WTRU, the remote WTRU may route (e.g., may be allowed to route) data to the secondary path, for example, if (e.g., only if or only if) the data available for transmission may be associated with a bearer (e.g., a specific bearer). The WTRU may be configured with a first bearer or bearer type and a second bearer or bearer type, wherein the first bearer or bearer type may allow routing to a secondary path for the same / different cell scenarios; and the second bearer or bearer type may restrict (e.g., not allow) routing to a secondary path. If the remote WTRU triggers Uu RLF, the remote WTRU may initiate data transmission (e.g., via a secondary path) if (e.g., as long as) the relay WTRU is served by the same cell as the remote WTRU. Otherwise, if the relay WTRU may be served by a different cell, the remote WTRU may trigger re-establishment or CHO based on triggering UuRLF. The remote WTRU may be configured with a set of cell IDs for which data transmission may be allowed on the bearer to any path.

[0157] In an example, a relay WTRU having a direct Uu link for data transmission / reception may determine one or more conditions for initiating transmission / routing on a secondary (potentially relay) link based on the QoS of the bearer configured at the remote WTRU and / or utilizing the data available for transmission. For example, the conditions (e.g., as described herein) may depend on the bearer, the QoS of the flow mapped to the bearer, the configuration of the bearer (e.g., split vs. non-split bearer), or any (e.g., specific) configuration element associated with the bearer.

[0158] The WTRU may initiate a Uu RRC message / procedure or another procedure via a relay (eg, prior to data transmission).

[0159] A remote WTRU may have a PC5-RRC connection with a relay WTRU while performing active data transmission on Uu. The remote WTRU may be configured with conditions, such as to initiate transmission / reception of data for a Uu RRC connection via the relay WTRU. Such conditions may be conditions (e.g., any of these conditions), such as described herein (e.g., conditions for performing relay (re)selection). Such conditions may be applicable to determine whether to transmit data via an indirect link. Such conditions may be applicable to determine whether an RRC message may be used (e.g., required) to transmit data via an indirect link. Such conditions may be applicable to determine whether to transmit a completion message via an indirect link or a direct link (e.g., during reconfiguration where an indirect link may be added). Such conditions may be applicable to determine whether the WTRU (e.g., first) transmits an RRC message (e.g., before transmitting data via an indirect link). The remote WTRU may (e.g., alternatively) initiate transmission / reception following an indication (e.g., an explicit indication) by the network. For example, the remote WTRU may receive an RRC message (e.g., RRCReconfiguration) that may initiate or allow transmission / reception via the relay path of the multipath connection. For example, the remote WTRU may receive signaling (e.g., MAC CE) that enables such transmission / reception (e.g., by configuring UL PDCP duplication on a split bearer). For example, the remote WTRU may receive (e.g., in an RRC message) an indication as to whether to transmit data to the indirect link or to first transmit the RRC message and then the data.

[0160] Upon such a decision / trigger, the remote WTRU may be configured to perform one or more of the following actions (e.g., before routing data via the relay path): enable / activate one or more bearers on the SL path or branches of a split bearer operating on the SL path, which may involve enabling PDCP to route data via the SL RLC entity; transmit Uu RRC messages via the relay path (e.g., where the remote WTRU may be configured to transmit PC5-RRC messages to the relay, where such RRC messages (e.g., PC5 or Uu) may be transmitted prior to allowing the remote WTRU to perform UP data transmission to the relay WTRU); perform data transmission (e.g., first via a default bearer or SL RLC data channel), for example, before transmitting subsequent data (e.g., via other relay bearers or relay SL RLC channels); wait for an RRC message (e.g., an RRC message from the relay WTRU) to arrive at the relay WTRU; ACK) successfully transmitted via the relay path, e.g., before performing (e.g., any) data transmission (e.g., UP data transmission) via the relay path; wait for an indication from the relay WTRU and / or the network (e.g., via the relay path), e.g., before (e.g., any) data transmission (e.g., UP data transmission) can be performed via the relay path; wait for receipt of data (e.g., any data, any DL data) from the relay path (e.g., associated with the same RRC connection), e.g., before it can perform data transmission (e.g., UL data transmission) via the relay path; wait for an acknowledgment RRC message transmitted in response to its own RRC message, e.g., before it can perform data transmission (e.g., UL data transmission) via the relay path; initiate (e.g., immediately initiate) routing of data to the relay path, e.g., without any additional action being required; wait for a trigger (e.g., such as DCI, MAC) before transmitting data (e.g., UP data) via the SL CE and other NW messages) (for example, this may be to ensure that the RRC connection of the relay WTRU is successful, and / or where the remote WTRU may perform such behavior after another behavior (for example, the transmission of an RRC message); send an indication to the network (for example, an explicit / implicit indication) of its intention to perform transmission via the SL path (for example, the WTRU may trigger an UL RRC message to the network); delay the transmission of data (for example, UL UP data) for a period of time after (for example, possibly after) sending an explicit / implicit indication to the network; determine whether to transmit a message (for example, an RRC message) via a direct or indirect link or via both (for example, repetition); determine whether to transmit a message (for example, a PC5-RRC message), for example, in response to a reconfiguration message (for example, add / release) or a Uu RRC message; and the like.

[0161] Following such a decision / trigger, the remote WTRU may perform a data transmission (e.g., first via a default bearer or SL RLC data channel), e.g., before transmitting subsequent data (e.g., via other relay bearers or relay SL RLC channels). The method may trigger (e.g., enable) an RRC connection at the relay WTRU, e.g., when the relay WTRU may be in RRC_IDLE / RRC_INACTIVE. The remote WTRU and the relay WTRU may be indicated (e.g., configured with) a default SL RLC data channel. At the relay WTRU (e.g., for example, based on receipt of a message on the default SL RLC channel and if the relay WTRU may be in RRC_IDLE / RRC_INACTIVE), the relay WTRU may initiate an RRC connection.

[0162] Following such a decision / trigger, the remote WTRU may be configured to delay transmission of data (e.g., UL UP data) for a period of time after (e.g., possibly after) sending an explicit / implicit indication to the network (e.g., before routing the data via the relay path). For example, the remote WTRU may track the time after the transmission of the UL indication (e.g., start a timer). If it can be determined based on the tracked time (e.g., expiration of the timer) that the duration has elapsed in the absence of an indication from the network or WTRU that the data cannot be routed (e.g., an SL indication or similar error message as described herein), the WTRU may initiate routing of the data. The remote WTRU may (e.g., alternatively) track the time (e.g., start a timer) whereby it initiates routing based on receipt of the NW or relay WTRU indication and may trigger a recovery procedure based on determining that the duration has elapsed based on the tracked time (e.g., expiration of the timer).

[0163] The remote WTRU may perform (e.g., determine whether to perform) one or more operations (e.g., as described herein, such as one or more of the above-described behaviors) and / or select which of these operations (e.g., as described herein, such as one or more of the above-described behaviors) to perform prior to data transmission. For example, this may be based on one or more of the following: explicit network indications; implicit network indications; SL configuration information; information provided by the relay WTRU (e.g., RRC state); cell IDs of cells serving the relay and / or remote WTRU; time periods associated with previous sidelink activity (e.g., time since the last sidelink activity); QoS and / or bearer configuration information at the remote WTRU; and the like.

[0164] The remote WTRU may, for example, perform (e.g., determine whether to perform) one or more operations (e.g., as described herein) and / or which of the operations to perform prior to data transmission (e.g., as described herein) based on an explicit network indication. For example, the remote WTRU may receive a message (e.g., an RRC message) that may initiate data transmission on a SL relay path. The RRC message may include, for example, a reconfiguration message (e.g., which may add an indirect path to a multipath). The remote WTRU may receive as an indication in a message (e.g., an RRC message) whether to perform and / or which of the actions to perform prior to initiating SL data transmission (e.g., as described herein). For example, the reconfiguration message may include an (e.g., explicit) indication of whether the RRCReconfigurationComplete message should be sent via a direct path or via an indirect path. The relay WTRU may (e.g., alternatively) receive such configuration information prior to triggering (e.g., in an RRC message similar to a conditional handover configuration) to initiate UP data transmission via a relay (e.g., in a conditional routing command as described herein). For example, the remote WTRU may determine whether / which of the actions (e.g., as described herein) are to be performed prior to data routing based on information in the SIB (e.g., an indicator in the SIB that an RRC message transmission is to be performed prior to any data transmission).

[0165] The remote WTRU may, for example, perform (e.g., determine whether to perform) one or more actions (e.g., as described herein) based on an implicit network indication and / or which of the actions (e.g., as described herein) to perform prior to data transmission. For example, the remote WTRU may initiate one of the actions prior to data transmission based on one or more characteristics of a received network message (e.g., as described herein). For example, the remote WTRU may receive an embedded message (e.g., an embedded RRC message) to be transmitted (e.g., in an RRC message from the network) based on triggering a data transmission (e.g., UP data transmission) via a SL path. The remote WTRU may perform a message transmission (e.g., an RRC message transmission) via a relay path prior to initiating an UP data transmission, for example, in a scenario where the message (e.g., an RRC message) includes an embedded message (e.g., an embedded RRC message). The remote WTRU may reuse or transmit the received and embedded RRC message via the relay path.

[0166] The remote WTRU may, for example, perform (e.g., determine whether to perform) one or more operations (e.g., as described herein) based on the SL configuration and / or which of the operations (e.g., as described herein) to perform prior to data transmission. For example, the remote WTRU may perform (e.g., determine whether to perform) (e.g., any) action (e.g., as described herein) based on attributes associated with the PC5-RRC configuration information. The remote WTRU may transmit an RRC message, for example, in a situation where the PC5-RRC connection with the relay WTRU may be configured with SL DRX or it may be configured with SL DRX with (e.g., specific) attributes (e.g., SL DRX period above a threshold, SL on duration below a threshold, etc.).

[0167] The remote WTRU may, for example, perform (e.g., determine whether to perform) one or more operations (e.g., as described herein) and / or which of the operations (e.g., as described herein) to perform prior to data transmission based on information provided by the relay WTRU (e.g., RRC state). The remote WTRU may perform (e.g., determine whether to perform / which) actions (e.g., as described herein) based on indications, information, or the absence thereof provided by the relay WTRU (e.g., via PC5-RRC, discovery messages, adaptation layer control PDUs, etc.). For example, such determination and / or performance may be based on operations associated with providing information about the RRC state of the relay WTRU to the remote WTRU (e.g., as described herein). The remote WTRU may send a Uu RRC message (e.g., ReconfigurationComplete), for example, in a situation where (e.g., when) the relay WTRU may be in RRC_CONNECTED. The remote WTRU may transmit a PC5-RRC message (eg, SidelinkReconfiguration message), for example, in a situation where (eg, when) the relay WTRU may be in RRC_IDLE / RRC_INACTIVE.

[0168] The remote WTRU may, for example, perform (e.g., determine whether to perform) one or more operations (e.g., as described herein) based on the cell ID of the cell serving the relay and / or the remote WTRU and / or which of the operations (e.g., as described herein) may be performed prior to data transmission. The remote WTRU may refrain from transmitting a message (e.g., an RRC message), for example, in a situation where the cell ID of the cell serving the relay may be the same as the cell ID of the remote WTRU. Otherwise, the remote WTRU may transmit a message (e.g., an RRC message).

[0169] The remote WTRU may, for example, perform (e.g., determine whether to perform) one or more operations (e.g., as described herein) based on a time period associated with a previous sidelink activity (e.g., the time since the last sidelink activity) and / or which of the operations (e.g., as described herein) to perform prior to data transmission. For example, the remote WTRU may be (pre)configured with a time period since the last data / control transmission on the SL / relay path for which (e.g., one) action (e.g., as described herein) may be performed (e.g., required). The remote WTRU may perform a message transmission (e.g., an RRC message transmission), for example, in a situation where the remote WTRU has not transmitted / received any information to / from the relay WTRU (e.g., for at least the (pre)configured time period). Otherwise, the remote WTRU may initiate (e.g., directly initiate) data routing to the relay WTRU. The transmission / reception considered for determining the time period at the remote WTRU may be one or more of: UL data transmission by the remote WTRU; UL Uu RRC message transmission by the remote WTRU; messages on PC5 RRC (e.g., PC5-RRC, discovery, adaptation layer control PDUs such as flow control, etc.); relayed DL data transmission of UP data by a relay WTRU; relayed transmission of Uu RRC messages by a relay WTRU; etc. For example, the remote WTRU may transmit UL data without messages (e.g., RRC messages).

[0170] The remote WTRU may, for example, perform (e.g., determine whether to perform) one or more actions (e.g., as described herein) and / or which of the actions to perform prior to data transmission (e.g., as described herein) based on QoS and / or bearer configuration information at the remote WTRU. For example, the remote WTRU may be configured with per-bearer configuration information or per-bearer indications of whether an action may be performed (e.g., required) or which of the actions to perform (e.g., as described herein). Such an approach may be employed in situations where the network may prefer to page a relay WTRU that may be in RRC_IDLE / RRC_INACTIVE (e.g., rather than relaying on the remote WTRU that transmits the RRC message). For example, the remote WTRU may determine whether an RRC message transmission may be performed (e.g., required) based on per-bearer configuration information and / or a data buffer status at the remote WTRU associated with each bearer. The remote WTRU may determine whether to transmit (e.g., need to transmit) a message (e.g., an RRC message) based on one or more of the following: none of the bearers or at least one of the bearers is configured to require transmission of the RRC message; none of the bearers or at least one of the bearers is configured to not require transmission of the RRC message; none of the bearers or at least one of the bearers is configured with a priority above / below a threshold; none of the bearers or at least one of the bearers is configured as a split bearer and / or a bearer that may (e.g., only) be configured with a relay path; based on the amount of data available for transmission at the WTRU (e.g., potentially at one of the bearers configured as described herein). The remote WTRU may transmit the message (e.g., an RRC message), for example, in a situation where none of the bearers configured to allow transmission via the relay path has a priority above / below a threshold. The remote WTRU may transmit the RRC message, for example, in a situation where the bearer that triggered the transmission via the relay path has a priority above / below a threshold.

[0171] The remote WTRU may determine which path to transmit the RRC message (e.g., RRCReconfigurationComplete), for example, based on the configuration of the SRB. The WTRU may transmit the (e.g., Complete) message via the indirect path (e.g., whenever a Complete message results from adding an indirect path), for example, in the case where the WTRU is configured with a split SRB. The WTRU may (e.g., alternatively) transmit the (e.g., Complete) message (e.g., via a direct path), for example, in the case where the WTRU is configured with a non-segmented SRB (e.g., only via direct SRBs).

[0172] The remote WTRU may determine whether to send a Uu RRC message or a PC5 RRC message in response to a Uu reconfiguration (e.g., to add a path), for example, based on whether the remote WTRU's SRB is configured to split the SRB. The remote WTRU may send an indication to the relay WTRU on the sidelink (e.g., in a PC5-RRC message or an RRC reconfiguration message), for example, when the remote WTRU is configured with SRB transmission (e.g., only) via a direct path, and the remote WTRU receives a reconfiguration message to add an indirect path. In such a case, the remote WTRU may also transmit a Uu RRC message after the PC5-RRC message / unicast link establishment (e.g., such message is transmitted only via a direct link). The remote WTRU may (e.g., alternatively) transmit (e.g., only) a Uu RRC message (e.g., a completion message), for example, when the remote WTRU's SRB may be configured to split (e.g., SRB transmission may be allowed via an indirect path).

[0173] The PC5-RRC message may trigger the relay WTRU to become connected. Whether the remote WTRU decides to use the PC5-RRC message to force the relay WTRU to CONNECTED may depend on the remote WTRU's decision of where to send (e.g., to send) the completion message. The remote WTRU may receive (e.g., be configured with) rules (e.g., as described herein) to determine where to send the completion message (e.g., to the primary path only when split is not configured, to either path based on other conditions when split is configured). The remote WTRU may (e.g., based on the decision) trigger a corresponding PC5-RRC message, for example, in the event that the remote WTRU decides to send the completion message to the direct path.

[0174] The procedures described herein may be applicable to situations where a remote WTRU wishes to transmit data via an indirect path and determines, for example, based on the mechanisms described herein (e.g., absence of UL / DL data transmission from the relay, indication of the RRC state of the relay UE, etc.) that a trigger to initiate a connection to the relay may be used (e.g., required). The remote WTRU (e.g., if it determines to send data via an indirect path and such a trigger may be required) may perform transmission of an RRC message (Uu or PC5) prior to data transmission.

[0175] In a case where a remote wireless transmit / receive unit (WTRU) may be configured to transmit a radio resource control (RRC) message via a relay path before routing any data, the remote WTRU may determine the protocol of the RRC message (e.g., a Uu RRC message or a PC5-RRC message) and / or the type of RRC message (e.g., a specific UuRRC message to be transmitted) based on one or more of the following.

[0176] In the case where the remote WTRU may be configured to transmit a radio resource control (RRC) message via the relay path before routing any data, the remote WTRU may determine the protocol of the RRC message (e.g., a Uu RRC message or a PC5-RRC message) and / or the type of RRC message (e.g., a specific Uu RRC message to be transmitted) based on the condition that triggered / initiated the data transmission on the SL path. For example, the remote WTRU may select (e.g., a specific) RRC message and / or RRC type (e.g., as described herein) for the initiation condition (e.g., each of the initiation conditions).

[0177] In the case where the remote WTRU may be configured to transmit an RRC message via a relay path before routing any data, the remote WTRU may determine the protocol of the RRC message (e.g., a Uu RRC message or a PC5-RRC message) and / or the type of RRC message (e.g., a specific Uu RRC message to be transmitted) based on the QoS and / or bearer configuration information at the remote WTRU. The remote WTRU may select (e.g., one) RRC message or message type, for example, in the case where (e.g., when) the priority of the bearer / data may be above / below a threshold. Otherwise, the remote WTRU may select another RRC message or message type. The message or message type may be determined by the configuration parameters of the bearer, for example, for which data is available for transmission via the SL.

[0178] In the case where the remote WTRU may be configured to transmit an RRC message via a relay path before routing any data, the remote WTRU may determine the protocol of the RRC message (e.g., a UuRRC message or a PC5-RRC message) and / or the type of RRC message (e.g., a specific Uu RRC message to be transmitted) based on the cell ID of the cell serving the relay and / or the remote WTRU. The relay may transmit a first RRC message, for example, in a case where the cell ID of the cell serving the relay is the same as the cell serving the remote WTRU. The remote WTRU may transmit a second RRC message, for example, in a case where the cell ID of the cell serving the relay may be different from the cell serving the remote WTRU.

[0179] In a case where the remote WTRU may be configured to transmit RRC messages via a relay path before routing any data, the remote WTRU may determine the protocol of the RRC message (e.g., a Uu RRC message or a PC5-RRC message) and / or the type of RRC message (e.g., a specific Uu RRC message to be transmitted) based on whether the transmission / reception performed by the remote WTRU prior to initiating data transmission on the SL path is directly on Uu or via the SL relay.

[0180] In a case where the remote WTRU may be configured to transmit an RRC message via a relay path before routing any data, the remote WTRU may determine the protocol of the RRC message (e.g., a UuRRC message or a PC5-RRC message) and / or the type of RRC message (e.g., a specific Uu RRC message to be transmitted) based on the number of hops on the SL path of previous and / or new SL transmissions.

[0181] In an example, if the WTRU transmits (eg, determines to transmit) an RRC message to initiate a SL transmission based on one of the triggers, the remote WTRU may select the message based on one or more of the following rules.

[0182] In an example, if the WTRU transmits (e.g., determines to transmit) an RRC message to initiate SL transmission based on one of the triggers, the remote WTRU may select the message based on whether the relay cell may be the same cell as the remote WTRU on Uu. If the relay cell may be the same cell as the remote WTRU on Uu and the Uu RSRP is below a threshold, the WTRU may transmit a dummy RRC message or transmit a measurement report if (e.g., when) the relay WTRU is IDLE / INACTIVE, and the WTRU may refrain from transmitting (e.g., not transmitting) (e.g., any) RRC message if (e.g., when) the relay WTRU is CONNECTED. If the relay cell is the same cell as the remote WTRU on Uu and there is a Uu RLF, the WTRU may transmit UESidelinkInformation or UEAssistanceInformation if (e.g., when) the relay WTRU may be IDLE / INACTIVE, and the WTRU may transmit UESidelinkInformation or UEAssistanceInformation if / when the relay WTRU is CONNECTED.

[0183] In an example, if the WTRU transmits (e.g., determines to transmit) an RRC message to initiate a SL transmission based on one of the triggers, the remote WTRU may select the message based on whether the relay cell is different from the cell of the remote WTRU on Uu. If the relay cell is different from the cell of the remote WTRU on Uu and the Uu RSRP is below a threshold, the WTRU may transmit RRCComplete if (e.g., when) the relay WTRU is IDLE / INACTIVE, and the WTRU may transmit RRCComplete if (e.g., when) the relay WTRU is CONNECTED. If the relay cell is different from the cell of the remote WTRU on Uu and there is a Uu RLF, the WTRU may transmit MCGFailure if (e.g., when) the relay WTRU is IDLE / INACTIVE, and the WTRU may transmit MCGFailure if / when the relay WTRU is CONNECTED.

[0184] In an example, if the WTRU transmits (e.g., determines to transmit) an RRC message to initiate a SL transmission based on one of the triggers, the remote WTRU may select the message based on whether the WTRU is configured as RRC connected by the NW, and if so, the WTRU may use RRM measurements (e.g., use existing RRM measurements). RRC reconfiguration may add a relay (e.g., it may trigger a PC5-RRC connection if needed). RRC reconfiguration may trigger a RACH to the serving cell (e.g., if / when the WTRU moves within coverage on Uu).

[0185] In an example, if the WTRU transmits (e.g., determines to transmit) an RRC message to initiate a SL transmission based on one of the triggers, the remote WTRU may select a message based on whether the WTRU can trigger (e.g., autonomously trigger) a PC5-RRC connection to speed up the process while in RRC_CONNECTED (e.g., data trigger, reliability trigger on Uu, etc.).

[0186] In an example, if the WTRU transmits (e.g., determines to transmit) an RRC message to initiate a SL transmission based on one of the triggers, the remote WTRU may select the message based on whether the RRC message can be used to notify the network that a second path is being established. For example, if the RRC message can be used to notify the network that a second path may be being established, the WTRU may allow an IDLE / INACTIVE relay connection. The conditions for establishing the second path may be data triggered, etc. Data triggered (re)selection may be enabled. Establishing the second path may be followed by the transmission of a completion message, or an RRC exchange to obtain configuration information (e.g., the WTRU may already have the configuration information). The configuration information may be obtained directly from the Uu, for example, so that the WTRU may transmit a message to the NW via a relay path or via a Uu path (e.g., the Uu path may be a legacy path). The WTRU may decide which path to send the RRC message or which RRC message to send, for example, based on a status indication from the relay WTRU.

[0187] Conditional reselection may be performed (eg, as described herein). Conditional initiation of RRC procedures via a relay path may be enabled and / or performed.

[0188] UL transmission may be delayed / suspended by the remote WTRU, for example, to ensure successful connection establishment for the relay WTRU.

[0189] In an example, the remote WTRU may suspend the indirect path of any bearer for a period of time, for example, after the remote WTRU initiates the indirect path through one or more of the trigger mechanisms (e.g., transmission of a PC5-RRC message) as described herein (e.g., any of the trigger mechanisms therein). The remote WTRU may track time (e.g., start a timer) and maintain the indirect path of the (e.g., any) bearer that is suspended (e.g., while tracking time, while the timer is running), for example, after the transmission of the PC5-RRC message. The path may be enabled, for example, in the event that (e.g., when) the time period elapses (e.g., the timer expires). The remote WTRU may release the indirect path, suspend the indirect path, notify the network (via the direct path), or any combination thereof, for example, in the event that the remote WTRU receives a message from the relay WTRU (e.g., before the time period elapses, before the expiration of the timer (e.g., an RRC connection failure indication)).

[0190] The relay WTRU may determine a (eg, appropriate) trigger for initiating an RRC connection, for example, based on whether multipath is configured and corresponding remote WTRU and network signaling.

[0191] The relay WTRU may determine whether to initiate a Uu RRC connection based on the establishment / configuration of a PC5-RRC connection (e.g., a unicast link) (e.g., based on an indication from the remote WTRU). The remote WTRU may include a flag and / or configuration information associated with (e.g., specific to) multipath in a sidelink reconfiguration message (e.g., a PC5-RRC message), for example, to indicate that the relay WTRU may (e.g., should) trigger a connection (e.g., a PC5-RRC connection). The relay WTRU may (e.g., based on receiving such a flag or multipath configuration information from the remote WTRU) initiate an RRC connection, for example, in a situation where the relay WTRU may be in RRC_IDLE / RRC_INACTIVE.

[0192] The remote WTRU may determine whether to set such a flag, for example, depending on the suitability (e.g., need) of the relay path for multipath purposes. The remote WTRU may include such a flag (e.g., a multipath flag) in a message to the relay WTRU (e.g., a PC5 RRC reconfiguration message), for example, in a scenario where the remote WTRU has an active direct path and may be configured by the network to add / change an indirect path. The remote WTRU may refrain from transmitting (e.g., not transmitting) a flag, for example, in a scenario where the remote WTRU may refrain from adding (e.g., not adding) an indirect path for multipath. In an example, the remote WTRU may receive multipath configuration information from the network to be forwarded to the relay WTRU. The remote WTRU may include the received multipath configuration information in a message to the relay WTRU (e.g., a PC5-RRC reconfiguration message), for example, in a scenario where the remote WTRU receives such configuration information.

[0193] A relay WTRU may be configured with (e.g., different) discovery message transmissions (e.g., L2 IDs associated with discovery) that may be associated with a multipath relay versus other types of relays. A relay WTRU may initiate an RRC connection based on the establishment of a unicast link, for example, in the case where the relay WTRU is requested to initiate a unicast link from an L2 ID associated with a multipath.

[0194] The relay WTRU may receive information from the network regarding an appropriate trigger for initiating an RRC connection. This information may be present in the SIB or may be received in dedicated signaling and maintained while the relay WTRU may be in RRC_INACTIVE. This information may be used to determine whether (e.g., when / whether / how) the relay WTRU initiates a connection (e.g., an RRC connection) for multipath purposes based on a trigger (e.g., a trigger described herein), for example, in a situation where (e.g., when) the relay WTRU may be in RRC_IDLE / RRC_INACTIVE. For example, the relay WTRU may receive a list of remote WTRU identities from the network. The relay WTRU may trigger an RRC connection, for example, based on initiating a unicast link with such remote WTRUs in the list (e.g., in a situation where the relay WTRU may be in RRC_IDLE / RRC_INACTIVE). The relay WTRU may receive a flag / indication that (e.g., any) PC5-RRC connection initiated by the remote WTRU (e.g., in response to a specific discovery) may (e.g., should) trigger a Uu RRC connection.

[0195] The WTRU may decide on which path to transmit the UL RRC message.

[0196] The WTRU may determine a path on which to transmit an UL RRC message in a multipath scenario, for example, based on one or more of the following factors (e.g., rules) or a combination of the following factors (e.g., rules). (e.g., one) method may be to determine a path based on a factor or a combination of factors. A method (e.g., a different method, another method) may be to use a first rule (e.g., check the first condition) if (e.g., when) a third condition is met, and to use a second rule (e.g., check the second condition) if (e.g., when) the third condition is not met. For example, a factor (e.g., a rule) may be associated with one or more of the following: SRB configuration, whether the path can be a direct path or an indirect path; whether the same cell or different cells can be configured on the direct path and the indirect path; whether the link to the relay can be a 3GPP link or a non-3GPP link; whether the RRC message can be a response to a DL RRC message; the type of UL RRC message; the type of DL RRC message to which the UL RRC message can respond; the operation performed by the DL RRC message to which the UL RRC message can respond; whether the UL path determined based on another rule corresponds to a direct path or an indirect path; measurements of direct paths, indirect paths, side link pool conditions (e.g., CBR), etc.; measurement events that trigger measurement reports; indications from the network; based on the nature of the configuration message to which the remote WTRU may respond with a reconfiguration complete message; based on the path being added / modified, for example, in a scenario where the reconfiguration includes path addition / modification; based on the configuration of the data bearer; and the like.

[0197] The remote WTRU may determine a path on which to transmit an UL RRC message in a multipath scenario, for example, based on the SRB configuration. The remote WTRU may perform transmission of the RRC message to either path (e.g., based on other conditions) or both paths (e.g., if duplication is configured on the SRB), for example, in the case where the remote WTRU is configured with split SRBs (e.g., SRB transmission / reception on either path). The remote WTRU may transmit the RRC message to the path for which the SRB is configured (e.g., in other ways).

[0198] The WTRU may determine the path over which to transmit a UL RRC message in a multipath scenario, for example, based on whether the path is a direct path or an indirect path. The UL RRC message may indicate whether the transmission may be to a direct path or to an indirect path (e.g., whether a transmission to a direct path or to an indirect path is required), for example, in a scenario where the WTRU is configured with split SRBs. This may be combined with one or more of the following other factors: a message (e.g., a specific RRC message) or a message type (e.g., a measurement) should be sent (e.g., only) via a direct path; a (e.g., a specific) measurement event may be configured such that if (e.g., when) the event may be triggered, the corresponding measurement report may be sent (e.g., only) on the direct path; etc.

[0199] The WTRU may determine the path on which to transmit the UL RRC message in a multipath scenario, for example, based on whether the same cell or different cells may be configured on the direct path and the indirect path. The remote WTRU may (e.g., based on other conditions described herein) send the RRC message via either path, for example, in the case where the remote WTRU is configured via multipath with the same cell on both paths. The remote WTRU may (e.g., otherwise) send the RRC message on a primary path (e.g., a path associated with a PCell, or a path considered an anchor point). The remote WTRU may use a first rule to determine the path of the RRC message, for example, in the case where (e.g., when) different cells may be configured on the direct path and the indirect path (e.g., always transmit the RRC message only to the direct path unless duplicates are configured). The remote WTRU may use a second rule to determine the path for the RRC message, for example, in the case where (e.g., when) the same cell may be configured on the direct path and the indirect path (e.g., transmit to a path determined based on UU and / or SL quality). The remote WTRU may determine the path to send a message (e.g., a reconfiguration complete message), for example (e.g., for the case of path addition / change / removal) based on the cell ID of the direct and / or indirect path (e.g., whether the cell ID is the same on both paths). The remote WTRU may send the message (e.g., a reconfiguration complete message) to the direct path, for example, if the reconfiguration message is adding / changing the direct path and the cell ID of the direct path is different from the cell ID of the indirect path. Otherwise (e.g., if the cells are the same), the remote WTRU may send it to either path.

[0200] The WTRU may determine a path over which to transmit a UL RRC message in a multipath scenario, for example, based on a link to the relay (e.g., the link to the relay may be a first type of link (e.g., a 3GPP link, which may be, for example, a PC5-RRC link) or a second type of link (e.g., a non-3GPP link, which may be, for example, a wired link or a proprietary link). If the link may be a first type of link (e.g., PC5-RRC), the remote WTRU may transmit the message via a direct link. If the link may be a second type of link (e.g., a wired link or a proprietary link), the remote WTRU may transmit the message via a primary path.

[0201] The WTRU may determine the path over which to transmit the UL RRC message in a multipath scenario, for example, based on whether the RRC message is a response to a DL RRC message. For example, the remote WTRU may transmit the response message on the same link as the DL RRC message. The remote WTRU may transmit other RRC messages (e.g., measurement reports) via either link.

[0202] The WTRU may determine, for example, based on the type of the UL RRC message, a path over which to transmit the UL RRC message in a multipath scenario. The remote WTRU may transmit a UL RRC message of a (e.g., specific) type to a predefined path or to a path associated with a primary path. Measurement reports (e.g., all measurement reports) may be transmitted via the primary path. UEAssistanceInformation may be transmitted via a direct link. For example, this may apply to repetitions. For example, the remote WTRU may (e.g., be configured to) send (e.g., always send) a (e.g., specific) RRC message (e.g., a completion message) using PDCP repetition.

[0203] The WTRU may determine the path on which to transmit the UL RRC message in a multipath scenario, for example, based on the type of DL RRC message to which the UL RRC message may be a response.

[0204] The WTRU may determine the path on which to transmit the UL RRC message in a multipath scenario, for example, based on the operation performed by the DL RRC message to which the UL RRC message is responding. A release confirmation may be sent to the link opposite to the link that may be released. A add confirmation may be sent to the link that may be added. Such rules may be followed, for example, regardless of which path the add / release is received from.

[0205] The WTRU may determine a path on which to transmit an UL RRC message in a multipath scenario, for example, based on whether the UL path determined based on another rule corresponds to a direct path or an indirect path. A completion message in response to the path addition may be sent via a path that depends, for example, on the (e.g., specific) path being added and whether the path is a direct or indirect path. The remote WTRU may send a completion message, for example, for a reconfiguration of adding a path to a multipath. The remote WTRU may send a completion message, for example, via the added path (e.g., in the case where / when the added path is an indirect path). The remote WTRU may receive a completion message, for example, via a direct path or an indirect path (e.g., in the case where / when the added path is a direct path).

[0206] The WTRU may determine the path over which to transmit the UL RRC message in a multipath scenario, for example, based on measurements of the direct path, the indirect path, the sidelink pool conditions (e.g., CBR), etc. The remote WTRU may send the message via the direct path, for example, in a situation where the Uu RSRP of the direct path is above a threshold. The remote WTRU may send the message via the indirect path, for example, in a situation where the SL RSRP of the indirect path may be above a threshold. The remote WTRU may send the message on a non-primary path, for example, in a situation where the RSRP of the non-primary path may be above a threshold. The remote WTRU may be configured with or may indicate a Uu threshold above which the RRC message will be sent via the direct path. For example, the remote WTRU may indicate or may be configured with a CBR threshold above which the RRC message will be sent via the direct path.

[0207] The WTRU may determine a path over which to transmit an UL RRC message in a multipath scenario, for example, based on a measurement event that triggered a measurement report. If (for example, when) the event in question may be triggered, the remote WTRU may be indicated (for example, in the measurement event configuration information) a specific path (for example, direct / indirect, primary / non-primary) over which to send the corresponding measurement report. The remote WTRU configured with a split SRB may (for example, then) transmit the RRC measurement report on the path configured in the event that triggered the report. The remote WTRU may be indicated (for example, configured with) a rule (for example, a specific rule) associated with the path to be used, for example, based on what is being measured. For example, if the measurement may be triggered as a result of a relay WTRU measurement, the remote WTRU may send the corresponding measurement report via a direct path.

[0208] The WTRU may determine a path over which to transmit an UL RRC message in a multipath scenario, for example, based on an indication from the network. For example, a remote WTRU may receive a reconfiguration message with an indication of which path to use to send a reconfiguration complete message. A remote WTRU in a multipath may receive a reconfiguration via a direct path or an indirect path (e.g., either one thereof). The reconfiguration may indicate a path over which to send a reconfiguration complete message.

[0209] The WTRU may determine the path on which to transmit the UL RRC message in a multipath scenario, for example, based on the nature of the reconfiguration message to which the remote WTRU may respond with a reconfiguration complete (e.g., it may be assumed that SRB1 may be configured on both paths). The remote WTRU may be configured with certain rules / conditions on which path to send the reconfiguration complete message, for example, based on the configured paths and possible other conditions herein (e.g., the RRC state of the relay WTRU). The remote WTRU may send the reconfiguration complete message via the relay path (e.g., as long as the relay path may be configured with SRB1), for example, in the case where the remote WTRU receives a reconfiguration message to add / change / reconfigure the relay path. Otherwise (e.g., for a reconfiguration that changes the direct path), the remote WTRU may send the completion message to either path. The remote WTRU may send the reconfiguration complete message via the direct path, for example, in the case where the remote WTRU receives a reconfiguration message to change / reconfigure the direct path. The remote WTRU may send a reconfiguration complete message via the relay path, for example, if the remote WTRU receives a reconfiguration message to add / change a relay path and the subsequent (e.g., new) relay is detected as being in RRC_IDLE / RRC_INACTIVE. The remote WTRU may send a reconfiguration complete message via the relay path, for example, if the WTRU receives a reconfiguration message to change a relay path (e.g., otherwise it may send the message via either path).

[0210] The WTRU may determine the path on which to transmit the UL RRC message in a multipath scenario, for example, based on the added / modified path (e.g., if / when the configuration consists of path addition / modification). A completion message may be sent to the direct / indirect path, for example, in the case where (e.g., when) a direct / indirect path may be added.

[0211] The WTRU may determine a path on which to transmit an UL RRC message in a multipath scenario, for example based on the configuration of the data bearers. The remote WTRU may receive a reconfiguration message to add a path (e.g., an indirect path) and may send a completion message to the indirect path, for example, if the WTRU is configured with at least one bearer on the indirect path.

[0212] The WTRU may autonomously change the primary path, for example, based on a condition or based on a trigger (eg, a predefined trigger).

[0213] As used herein, the term primary path may refer to a direct path, or it may refer to a path where an RRC anchor point exists, a path corresponding to a PCell, a path for initially establishing an RRC connection, or a path for transmitting a UL RRC message.

[0214] The WTRU may autonomously decide / trigger a change of the primary path, for example based on predefined conditions or preconfigured conditions. The WTRU may operate under the assumption that non-repeated split SRBs follow rules similar to those for UL transmissions for dual connectivity (e.g., for non-repeated SRBs, the WTRU transmits RRC messages to the primary path (e.g., only to the primary path). The WTRU may indicate or may be configured with (e.g., (pre)configured) conditions whereby it may change the primary path, for example, without receiving signaling (e.g., explicit RRC signaling). The WTRU may notify the network explicitly (e.g., by transmitting an RRC message) or implicitly (e.g., by performing the next transmission of an RRC via the new path), for example, in the event that (e.g., once) the WTRU has determined to change the primary path. Subsequent (e.g., all subsequent) transmissions (e.g., RRC transmissions) may be performed on the updated (e.g., new) primary path (e.g., until explicitly configured or until a different (e.g., A new (e.g., triggers changing the path again), for example, in a situation where (e.g., once) the WTRU has determined to change the primary path. The WTRU may (e.g., further) be instructed (e.g., configured) to allow (e.g., for certain situations) the primary path change / decision. For example, the WTRU may be instructed by the network to allow the primary path change / decision. For example, if (e.g., when) the cells of the direct path and the indirect path are the same, the remote WTRU may (e.g., only) perform autonomous selection / change of the primary path. The WTRU may be instructed to allow the primary path change / decision based on the nature of the indirect link (e.g., PC5 or non-3GPP link) between the relay and the remote WTRU. For example, if (e.g., when) the indirect link between the relay and the remote WTRU is a non-3GPP link, the remote WTRU may (e.g., only) perform autonomous selection / change of the primary path).

[0215] The conditions for changing the primary path may be the same as the conditions for determining the UL path for RRC signaling (eg, as described herein).

[0216] In an example, the WTRU may be indicated and / or may be configured with a trigger for changing the primary path related to Uu quality and / or SL quality. The WTRU may change the primary path to an indirect / direct path if, for example, the primary path is via a direct / indirect path and the Uu / SL RSRP measured by the remote WTRU drops below a threshold for a period of time.

[0217] In an example, the WTRU may be instructed (e.g., configured) with a trigger for changing the primary path associated with the sidelink resource pool measurement. The WTRU may change the primary path to a direct path, for example, if the primary path is indirect and the CBR is above a threshold.

[0218] The remote WTRU may trigger a primary path change after receiving a notification message from a relay WTRU (e.g., associated with the mobility of the relay WTRU), for example, depending on the cell configured as the PCell at the remote WTRU. For example, the remote WTRU may change the primary path after receiving a HO indication received by the relay WTRU. The remote WTRU may change the primary path to a direct path based on the HO indication received from the relay WTRU or based on the detection of a cell change at the relay WTRU using reception of a SIB (e.g., whereby the HO may cause the cell of the relay WTRU to be different from the cell of the remote WTRU on a direct link), for example, in a scenario where the remote WTRU has an indirect path as the primary path and the same cell on the direct path and the indirect path. Such techniques may allow the remote WTRU to maintain the primary path associated with the PCell of the remote WTRU (e.g., in a scenario where the PCell is not changed (e.g., does not need to be changed) after the mobility of the relay WTRU.

[0219] The remote WTRU may trigger a primary path change after a measurement event and / or report is triggered. For example, the remote WTRU may be indicated (e.g., configured with) a measurement event associated with a change of the primary path (e.g., indirect path quality drops below a threshold). The remote WTRU may, for example, change the primary path based on the triggering of the measurement event and (e.g., simultaneously) send a corresponding measurement report to the changed (e.g., new) primary path.

[0220] The WTRU may autonomously (eg, based on conditions) change Pcell while in multipath.

[0221] In an example (e.g., based on similar conditions as described herein), the remote WTRU may change the PCell associated with the multipath from a current PCell (e.g., associated with a direct / indirect link) to a different (e.g., new) PCell (e.g., associated with another link). Similar conditions / triggers may be used to determine (e.g., at the WTRU) whether (e.g., when) such a PCell change may be performed. The remote WTRU may send an RRC message (e.g., ReconfigurationComplete) to indicate the (e.g., successful) change of the PCell, e.g., after such a PCell change. The remote WTRU may receive a HO indication from the relay WTRU (e.g., to change the relay WTRU's PCell to the same cell as the cell on the remote WTRU's direct link). The remote WTRU may (e.g., based on such an indication) change the PCell to a cell associated with the direct link, e.g., in the case where the remote WTRU's PCell is a cell associated with an indirect link.

[0222] The WTRU may (eg, be configured to) report to the network a relay connected to one or more cells.

[0223] The remote WTRU may (e.g., be configured to) (e.g., in RRC_CONNECTED) report measurements of the relay to the network. The remote WTRU may, for example, limit the (e.g., specific) relay WTRUs reported to the network based on the cells to which the reported relays may be connected (e.g., be configured to). The remote WTRU may report relay WTRUs (e.g., only relay WTRUs) that meet one or more of the following conditions: connected to the same cell / PLMN as the remote WTRU's current serving cell; connected to any cell / PLMN in the list of cells / PLMNs provided to the remote WTRU (e.g., in dedicated signaling or SIB); connected to (e.g., any) cell that may be part of the same cell group area as the remote WTRU's current serving cell; connected to (e.g., any) cell / PLMN that has an inherent / configured relationship with the cell to which the remote WTRU is currently connected (e.g., may be part of the same gNB, may be part of the same DU / CU); etc.

[0224] The WTRU may initiate a failure procedure to the network, for example, based on determining that a message (eg, a ReconfigurationComplete message) was not successfully sent.

[0225] The remote WTRU may initiate a failure procedure after transmission of a message (e.g., a ReconfigurationComplete message), for example, if the remote WTRU determines that transmission of the message (e.g., a ReconfigurationComplete message) was not successful. The remote WTRU may initiate transmission of a message (e.g., a reconfigurationComplete message) via an indirect path, for example, after receiving a Uu reconfiguration message that adds an indirect path (e.g., via a direct path). The remote WTRU may (e.g., decide to) transmit a message (e.g., a reconfigurationComplete message) via an indirect path based on a condition (e.g., as described herein).

[0226] The WTRU may determine that the transmission of a message (e.g., reconfigurationComplete) was unsuccessful, for example, based on one or more of the following (e.g., occurring within a time period after the transmission of ReconfigurationComplete): failure to receive an RLC ACK from the relay WTRU, for example, after multiple retries (e.g., the remote WTRU may determine the failure to transmit the reconfigurationComplete message after reaching the number of retransmissions at the RLC); receipt of a notification message with a (e.g., a specific cause) value from the relay WTRU (e.g., failure of the relay WTRU to establish an RRC connection, mobility at the relay WTRU, etc.); determination of a change in the serving cell of the relay WTRU or the serving gNB of the relay WTRU; failure to receive messages (e.g., RRC messages) and / or data from a path added as a result of sending the message (e.g., reconfigurationComplete message), for example, after a time period after the transmission of the message (e.g., reconfigurationComplete message); and the like.

[0227] The WTRU may determine that transmission of a message (e.g., a reconfigurationComplete message) was unsuccessful, for example, based on receiving a notification message with a (e.g., a particular cause) value from the relay WTRU (e.g., failure of the relay WTRU to establish an RRC connection, mobility at the relay WTRU, etc.). For example, the remote WTRU may determine the failure to transmit the reconfigurationComplete message after receiving a sidelink notification message with a cause value of relay connection failure (e.g., within a time period). For example, the remote WTRU may determine the failure to transmit the message (e.g., a reconfigurationComplete message) after receiving a sidelink notification message with a cause value of relay WTRU HO (e.g., within a time period). For example, the remote WTRU may determine the failure to transmit the message (e.g., a reconfigurationComplete message) after receiving a sidelink notification message with a cause value of relay WTRU reselection (e.g., within a time period).

[0228] The WTRU may determine that transmission of a message (e.g., a reconfigurationComplete message) was unsuccessful, for example, based on a determination of a change in the serving cell of the relay WTRU or the serving gNB of the relay WTRU. The remote WTRU may determine a failure to transmit a reconfiguration message, for example, in the event that the relay WTRU receives a HO from the relay WTRU, reselects by the relay WTRU to a different cell, or to a cell associated with a different gNB. Whether the HO / reselection is to a different gNB or to the same gNB may be used to determine whether a failure may be determined. Behavior as a result of the failure may be determined (e.g., as described herein).

[0229] The WTRU may determine that transmission of a message (e.g., a reconfigurationComplete message) was unsuccessful, for example, based on a failure to receive RRC messages and / or data from a path added as a result of sending the reconfigurationComplete message (e.g., after a period of time after transmission of the reconfigurationComplete message). The remote WTRU may determine a failure to transmit a message (e.g., a reconfigurationComplete message), for example, when the WTRU does not receive (e.g., any) messages (e.g., data and / or control messages) from a path added within a period of time X after transmission of the reconfigurationComplete message. During this period, the remote WTRU may (e.g., further) suspend UL transmissions to (e.g., only) the path, and may resume UL transmissions to the path, for example, if a DL message is received from the path before a time elapses (e.g., a timer expires). For example, such a failure may apply regardless of the path to which the message (e.g., a reconfigurationComplete message) may be transmitted. For example, the time period after which a failure may be declared (e.g., via a timer) may depend on the path in which the remote WTRU decided to send the message (e.g., a first timer may be used for a direct path, and a second timer may be used for an indirect path). For example, the time may be measured from the receipt of an RLC ACK (e.g., a SL RLC ACK for transmissions on the SL, and a Uu RLC ACK for transmissions on the direct path).

[0230] The WTRU may initiate a failure procedure / recovery procedure with the network (e.g., after determining that the reconfigurationComplete message transmission has failed). The type of recovery procedure may (e.g., further) depend on the type / cause of the failure (e.g., cause value), for example, as described herein. The type of recovery procedure may (e.g., further) depend on the primary path (e.g., whether the primary path and / or PCell may be considered an indirect path or a direct path).

[0231] The failure recovery process may include one or more of the following: for example, transmitting a message (e.g., a ReconfigurationFailure message) via a direct link; for example, transmitting another error message (e.g., an RRC error message) other than a reconfiguration failure message via a direct link, such as an SCGFailure message or a message similar to the SCGFailure message; releasing the PC5-RRC connection with the relay WTRU; restoring to the previous (e.g., RRC) configuration before the RRCReconfiguration is received by the remote WTRU (e.g., the remote WTRU that generates the reconfiguration complete message); suspending transmission / reception from the indirect link while maintaining transmission / reception activity via the direct link; tracking time (e.g., initiating a timer) and if another event occurs while tracking time (e.g., while the timer may be running), performing an action (e.g., any other action as described herein) based on the passage of time (e.g., when a timer expires) or any other action (e.g., any other action as described herein); suspending transmission / reception via the indirect link for a period of time, after which transmission / reception can be initiated normally; triggering reestablishment; and the like.

[0232] The failure recovery process may include, for example, transmitting another error message (e.g., an RRC error message) in addition to the reconfiguration failure message via the direct link, such as a SCGFailure message or a message similar to the SCGFailure message. For example, a SCGFailure-like message may be transmitted and may include a cause value associated with the cause value received in the notification message, the (e.g., new) cell ID of the relay WTRU (e.g., in the case of a HO or reselection performed by the relay WTRU), an indication that a Uu RLF was indicated by the relay WTRU, etc.

[0233] In an example, the remote WTRU may (e.g., after attempting to transmit a reconfiguration complete message via an indirect path) perform one or more of the following: the remote WTRU may revert to a previous RRC configuration (e.g., before transmitting the complete message via the indirect link) and transmit an RRCReconfigurationFailure message via the direct link, for example, in the following scenario: the failure may be caused by a notification from the relay related to a failure to establish an RRC connection at the relay; the remote WTRU may suspend transmission / reception via the indirect path and send an RRC message (e.g., a message similar to SCGFailure) to the network via the direct link, which may indicate the (e.g., new) serving cell ID of the relay WTRU, for example, in the following scenario: the failure may be caused by a notification from the relay WTRU indicating a HO performed by the relay WTRU; the remote WTRU may trigger a reestablishment, for example, in the following scenario: the failure may be caused by a Uu from the relay WTRU The remote WTRU may track time (e.g., initiate a timer) and suspend transmission via the indirect path, for example, in the following scenario: the failure may be caused by the notification of reselection made by the relay WTRU, and the remote WTRU may initiate normal transmission via the indirect path, for example, in the following scenario: time elapses (e.g., timer expires) without additional notification or reconfiguration.

[0234] The remote WTRU may consider one or more of the actions (e.g., as described herein), for example, based on a failure associated with the transmission of the ReconfigurationComplete (e.g., as long as an event (e.g., a notification received from the relay) is received within a time period after the transmission of the ReconfigurationComplete). The WTRU may consider the transmission of the ReconfigurationComplete message successful, for example, after a time period has expired without such an event, and (e.g., any) subsequent processing of the message from the relay may be handled based on the procedures as described herein (e.g., procedures associated with handling SL failures / mobility).

[0235] Can handle SL failure / mobility procedures.

[0236] In response to receiving a UuMessageTransferSidelink or in response to the WTRU detecting a SL-RLF, the WTRU may initiate different procedures. In this document, the terms UuMessageTransfer and SidelinkNotification may be used interchangeably. The term may refer to a message sent by a relay WTRU to a remote WTRU.

[0237] In response to receipt of a message (e.g., UuMessageTransferSidelink), the WTRU may perform one or more of the following procedures (e.g., different procedures). The WTRU may perform one or more of the following procedures based on detection of SL-RLF (e.g., detected by a remote WTRU). For example, receipt of a message (e.g., UuMessageTransferSidelink) may be replaced by detection of SL-RLF in the following procedures, and the following procedures may (e.g., still) apply without loss of generality.

[0238] The indication from the relay WTRU to the remote WTRU (e.g., the current indication) that may be supported via UuMessageTransferSidelink may include one or more of the following: a Uu RLF indication message (e.g., sent by the relay WTRU if / when the relay WTRU experiences Uu RLF); an indication that a HO was performed at the relay WTRU; an indication that a cell reselection was performed at the relay WTRU; or an indication that the relay WTRU failed to perform an RRC connection establishment. The indication from the relay WTRU to the remote WTRU may include an indication herein, such as an indication of a change of state of the relay WTRU (e.g., from RRC_CONNECTED to RRC_IDLE / RRC_INACTIVE).

[0239] The remote WTRU may (e.g., after receiving a UuMessageTransferSidelink from the relay WTRU) initiate one or more of the following actions: initiate relay and / or cell reselection; release the PC5-RRC connection with the relay WTRU; suspend a bearer (e.g., configured on the relay path), or an RLC entity / branch of a split bearer associated with the relay path; send an RRC message / indication to the network (e.g., where the content and / or type of the message, such as the RRC message type, e.g., the RRC message transmitted and the BSR may further depend on factors as described herein); initiate an RRC connection / resumption procedure, e.g., in an IDLE / INACTIVE situation (e.g., using an existing establishment / resumption cause, using a new establishment / resumption cause, including information related to the reception of the message in a completion message, or the cause or information included in the completion message may depend on the message and / or the BSR as described herein). or factors); reestablish or reset the protocol layer (e.g., reestablish PDCP, reset the MAC entity of the SL path or the bearer on the SL path, etc.); transmit a PDCP status report or request a PDCP status report; apply conditional reconfiguration (e.g., such as CHO, CPAC or conditional bearer reconfiguration); transition to RRC_IDLE (e.g., from RRC_CONNECTED); initiate a reestablishment procedure; perform relay reselection with or without reestablishment; perform (e.g., only) UL data transmission (e.g., on Uu or SL), for example by performing a RACH procedure, an SR procedure, or a BSR procedure before data transmission; perform reestablishment without reselecting a relay (e.g., a relay on a relay performs cell reselection); change the primary path of the bearer from a first path to a second path; initiate a procedure (e.g., similar to reestablishment) to a cell associated with a direct Uu path (e.g., directly to the cell); and the like.

[0240] The remote WTRU may initiate one or a combination of the first actions (e.g., after receiving a UuMessageTransferSidelink message), and may initiate one or a combination of the second actions (e.g., a time period after the first action, e.g., in the event that the condition was not met before the time period). The WTRU may perform a third action or a combination of actions, e.g., in the event that the condition is met. Such conditions may include conditions associated with the factor (e.g., as described herein), which may include: receiving a message (e.g., a reconfiguration) from the relay WTRU or the network; successful or failed reselection; successful or failed connection establishment by the remote WTRU; successful or failed conditional reconfiguration; receiving another (e.g., a different type) message (e.g., a UuMessageTransferSidelink message) from the relay WTRU indicating success or failure of an operation associated with the received first message; and the like.

[0241] One or more actions (e.g., one or more specific actions) performed by the remote WTRU may depend on one or more of the following factors (e.g., conditions). The WTRU may perform (e.g., only perform) an action (e.g., such as the following first action and / or second action), for example, if one or a combination of conditions associated with one or a combination of factors is satisfied. The WTRU may perform the first action, for example, if a first combination of conditions associated with a first combination of factors is satisfied, and the WTRU may perform the second action, for example, if a second combination of conditions associated with a second combination of factors is satisfied, and so on. Such factors (e.g., which may apply to the first and / or second actions) may include one or more of the following: the RRC state of the remote WTRU; the RRC state of the relay WTRU; the type of the UuMessageTransferSidelink message (e.g., Uu RLF, Ho, etc.); the content of the UuMessageTransferSidelink message; the bearer configuration at the remote WTRU; the QoS of the bearer at the remote WTRU; whether the relay WTRU is served by the same / different cell as the remote WTRU; whether the remote WTRU is configured with conditional bearer reconfiguration and / or CHO / CPAS; whether the remote WTRU is in coverage or out of coverage; whether the remote WTRU has triggered (e.g., has triggered) a Uu on Uu link. RLF; whether the remote WTRU has an active path on Uu (e.g., if / when in RRC_CONNECTED, has at least one bearer configured for transmission / reception on Uu, or if / when in IDLE / INACTIVE, resides on a cell in Uu); whether the remote WTRU is monitoring the PDCCH; whether the remote WTRU is operating in Mode 1 or Mode 2 on the sideline; depending on whether cell / relay reselection results in selection of a cell or relay; whether the remote WTRU is configured with duplication; whether the remote WTRU is configured with split bearers or bearers that only allow transmission to one path at a given time (e.g., only bearers); whether the path is configured as a primary path and it is considered to be the primary path; etc.

[0242] The one or more actions (e.g., one or more specific actions) performed by the remote WTRU may depend on the RRC state of the remote WTRU. For example, if the remote WTRU is in RRC_IDLE / RRC_INACTIVE, it may perform a first action (e.g., reselection, connection establishment) based on the reception of the message, and if the remote WTRU is in RRC_CONNECTED, it may perform a second action.

[0243] The action or actions (e.g., one or more specific actions) performed by the remote WTRU may depend on the UuMessageTransferSidelink message type (e.g., Uu RLF, HO, etc.). The action or actions performed by the remote WTRU may depend on the type of UuMessageTransferSidelink received (e.g., Uu RLF, HO, etc.).

[0244] One or more actions (e.g., one or more specific actions) performed by the remote WTRU may depend on the content of the Uu Message Transfer Sidelink message. For example, the content of the Uu Message Transfer Sidelink message may include the cell ID of the cell to which the remote WTRU is connected. For example, the behavior of the remote WTRU may depend on whether the cell ID indicated in the UuMessageTransferSidelink message is in the same or different RAN area, tracking area, or in the cell to which the remote WTRU is camped on Uu.

[0245] One or more actions (e.g., one or more specific actions) performed by the remote WTRU may depend on the bearer configuration at the remote WTRU. This may include the following: whether the remote WTRU has one or more bearers configured with legs on a relay path; whether the remote WTRU has one or more bearers configured with (e.g., only) a relay path; and whether the remote WTRU has one or more split bearers configured with duplication.

[0246] One or more actions (e.g., one or more specific actions) performed by the remote WTRU may depend on the QoS of the bearer at the remote WTRU. The QoS of the bearer at the remote WTRU may refer to the LCH priority configured for the SL or Uu RLC channel. For example, the remote WTRU may have different behaviors based on the reception of a message from the relay, depending on whether the remote WTRU can be configured with a bearer with a specific priority / QoS. The QoS of the bearer at the remote WTRU may refer to a QoS identification (QI) associated with the bearer (e.g., a 5G QI). The QoS of the bearer at the remote WTRU may refer to whether the bearer can be configured with attributes associated with a specific behavior (e.g., it can be configured per bearer or per RLC channel).

[0247] The one or more actions (e.g., one or more specific actions) performed by the remote WTRU may depend on whether the relay WTRU may be served by the same or a different cell as the remote WTRU. For example, if (e.g., when) the relay is served by a different cell than the remote WTRU, the remote WTRU may (e.g., only) perform a process based on receipt of a message.

[0248] One or more actions (e.g., one or more specific actions) performed by the remote WTRU may depend on whether the remote WTRU is configured with conditional bearer reconfiguration information and / or CHO / CPAC. For example, the remote WTRU may be configured with conditional reconfiguration information to be applied conditionally (e.g., some conditions). The remote WTRU may apply such configuration information based on receiving a message from the relay.

[0249] One or more actions (e.g., one or more specific actions) performed by the remote WTRU may depend on whether the remote WTRU has triggered (e.g., has triggered) a Uu RLF on the Uu link. The remote WTRU may perform a first action (e.g., transmit a Uu RRC message) based on receiving an RRC connection failure from the relay WTRU, for example, in the case where there is no pending Uu RLF on Uu, and may perform a second action (e.g., trigger a re-establishment) based on receiving an RRC connection failure from the relay, for example, in the case where there is a pending Uu RLF on Uu. The remote WTRU may release the PC5-RRC connection based on the reception of the RRC connection failure, for example, in the case where (e.g., when) the Uu link is not in Uu RLF. The remote WTRU may maintain the PC5-RRC connection and wait for the relay WTRU to perform another connection establishment, for example, in the case where the remote WTRU receives an RRC connection failure from the relay when the Uu link is in Uu RLF.

[0250] The one or more actions (e.g., one or more specific actions) performed by the remote WTRU may depend on whether the cell / relay reselection resulted in the selection of a cell or relay. The remote WTRU may release its bearer configuration, for example, if the remote WTRU selects a cell and was previously connected to a relay (e.g., when it would not otherwise release its bearer configuration).

[0251] One or more actions (e.g., one or more specific actions) performed by the remote WTRU may depend on whether the remote WTRU is configured with repetition. The remote WTRU may trigger re-establishment or initiation of RRC message transmission indicating a failure, for example, in a situation where the remote WTRU is configured with repetition and a message from the relay WTRU causes an interruption of data transmission via the relay path.

[0252] One or more actions (e.g., one or more specific actions) performed by the remote WTRU may depend on whether the remote WTRU is configured with split bearers or with bearers that are allowed to transmit to a path (e.g., only one path) at a given time (e.g., only bearers). For example, for a case where the relay WTRU and the remote WTRU are served by the same cell, the remote WTRU may be configured with a bearer with multiple (e.g., two) separate RLC entities (e.g., one on SL and one on Uu), but data may be routed (e.g., only allowed to be routed) to one of those RLC entities at a given time. In such a case, if the relay WTRU transmits a UuRLF indication to the remote WTRU while the remote WTRU is using the relay path, the remote WTRU may perform an UL transmission on the Uu path (e.g., without any additional RRC procedures). If the message is received while the Uu path is in RLF, the remote WTRU may trigger a re-establishment.

[0253] One or more actions (e.g., one or more specific actions) performed by the remote WTRU may depend on whether a path is configured as a primary path and which path is considered to be the primary path. The remote WTRU may perform different RRC procedures, for example, if a message is received from a relay, depending on which path is configured as the primary path, or which path is configured to allow transmission / reception of RRC signaling.

[0254] In an example, the remote WTRU may notify the network.

[0255] The remote WTRU (e.g., in RRC_CONNECTED) may notify the network, for example, based on the receipt of a UuMessageTransferSidelink. The remote WTRU may send a message (e.g., an RRC message) on Uu based on the receipt of a PC5-RRC message on the sidelink from the remote WTRU. The remote WTRU may, for example, in one option be used for messages (e.g., a single message) of (e.g., all) UuMessageTransferSidelink message type. The remote WTRU may transmit a SidelinkUEInformation message on Uu, for example, including the type of sidelink message (e.g., Uu RLF, CHO, etc.). In another option, the remote WTRU may transmit different RRC messages depending on the specific sidelink message received, for example, in an alternative (e.g., another) option. The remote WTRU may transmit a SCGFailureInformation message (e.g., in the event that a Uu RLF is received). The remote WTRU may transmit a SidelinkUEInformation message (e.g., with additional information about the (e.g., new) cell to which the relay has reselected), for example, in the case where the relay indicates that it has performed a cell reselection. The remote WTRU may refrain from transmitting (e.g., not transmitting) (e.g., any) RRC messages, for example, in the case where the relay indicates that it has performed a HO. The remote WTRU may provide the network with (e.g., additional) information about the indication received from the relay. The remote WTRU may provide a cell ID (e.g., a new cell ID) in the message, for example, for HO or reselection by the relay WTRU. Whether the message can be transmitted may depend on whether the cell ID has changed, or whether the (e.g., new) cell ID of the relay WTRU belongs to a different group compared to the cell ID of the direct path.

[0256] In an example, a remote WTRU in RRC_IDLE / RRC_INACTIVE may initiate a connection / recovery procedure. The remote WTRU may determine whether the connection / recovery procedure is performed, for example, based on a sidelink message and / or its content. For example, the remote WTRU may initiate (e.g., only) an RRC connection, for example, based on a connection establishment failure received by a relay WTRU. For example, the remote WTRU may initiate an RRC connection based on a cell reselection received by a relay and if the cell (e.g., a new cell) is in a different (e.g., new) RAN area, tracking area, cell group, or different from the cell where the WTRU resides directly on Uu. The remote WTRU may use an establishment cause (e.g., a new establishment cause), for example, to indicate the receipt of a sidelink message (e.g., one or any one of the sidelink messages). The remote WTRU may select an establishment cause based on a specific sidelink message type.

[0257] In an example, a remote WTRU (e.g., in RRC_CONNECTED) may determine whether to initiate an RRC message (e.g., if / when suspending or releasing bearers of a relay entity), for example, based on bearer configuration information and / or the amount of data on one or more bearers (e.g., the current amount of data). For example, the remote WTRU may suspend bearers (e.g., all bearers) or bearer branches associated with a secondary path and may notify the network (e.g., trigger an RRC message, or a BSR over Uu), for example, if the amount of buffered data for at least one bearer at the time of suspension is above a threshold configured for the bearer.

[0258] In an example, a remote WTRU (e.g., in RRC_CONNECTED) may determine the type of indication to send after suspending one or more bearers, e.g., based on whether the relay WTRU is served by the same cell as the remote WTRU itself (e.g., on Uu). The remote WTRU may trigger a BSR (e.g., in the same cell case). The remote WTRU may trigger an RRC message, e.g., when in a different cell case.

[0259] The remote WTRU may suspend or release one or more bearers or RLC entities of the bearers.

[0260] In an example, a remote WTRU (e.g., in RRC_CONNECTED) may suspend a bearer, for example, based on receiving (e.g., from a relay WTRU) a PC5-RRC message indicating one of the events at the relay (e.g., HO, Uu RLF, etc.). The remote WTRU may (e.g., alternatively) release one or more bearers or relay branches of a split bearer. The remote WTRU may (e.g., alternatively) move traffic of a bearer (e.g., a split bearer) from (e.g., one) branch to another branch. The remote WTRU may (e.g., alternatively) change a split bearer to a (e.g., a single) branch bearer. Whether / which operations are performed at the remote WTRU may depend on the type of message received. The remote WTRU may suspend a bearer associated with a relay path or suspend an RLC branch of a split bearer, for example, based on receiving a HO indication or a cell reselection indication from the relay WTRU. The remote WTRU may keep the bearer suspended, for example, until network reconfiguration information is received. The remote WTRU may release the bearer or change the split bearer to a single leg bearer, for example, based on the relay WTRU receiving a connection establishment failure or may receive an indication of a Uu RLF.

[0261] In an example, the remote WTRU may refrain from suspending (e.g., not suspending) a bearer or refrain from reestablishing (e.g., not reestablishing) a layer (e.g., any of the layers), for example, based on receiving a HO indication from the relay WTRU. The remote WTRU may suspend the bearer and perform RLC entity reestablishment (e.g., at some later time or event as described herein, such as, for example, reception of a reconfiguration message. For example, the remote WTRU may suspend the bearer and perform RLC entity reestablishment based on an indication of a failure to establish an RRC connection or a Uu RLF. Whether the remote WTRU continues to perform transmission, for example, refraining from suspending the bearer or not suspending the bearer may depend on the cell (e.g., the new cell) served by the relay after the HO. The remote WTRU may suspend the bearer or RLC branch transmitted on the relay path, for example, in a situation where the cell (e.g., the new cell) becomes the same as the cell served by the remote WTRU via Uu.

[0262] A remote WTRU may change the primary path of a bearer (e.g., SRB or DBR). The WTRU may change the primary path of a bearer, for example, based on (e.g., according to) receiving a MessageTransferSidelink from a relay WTRU. The remote WTRU may change (e.g., all) bearers configured as split bearers so that the primary path may be Uu, for example, based on (e.g., according to) receiving an indication of a backhaul RLF indication, HO / cell reselection, or a connection establishment failure. The remote WTRU may (e.g., alternatively) change the primary path of certain bearers (e.g., only SRBs, only DRBs with certain QoS characteristics, etc.) to Uu. Whether the WTRU changes the primary path may (e.g., further) depend on the type of message. The primary path may not be changed, for example, for HO and cell reselection. The primary path may be changed, for example, for Uu RLF and relay connection establishment failure. Whether the WTRU changes the primary path may depend on whether the cell ID associated with the relay WTRU is changed to a differently configured group, ran area, etc. The WTRU may maintain the primary path for the bearer, for example, if the cell ID remains within the same configured group, or if the cell IDs of the relay and remote WTRU are within the same group after a HO / reselection signaled by the relay WTRU.

[0263] The remote WTRU may transmit a re-establishment request or initiate a procedure (eg, a re-establishment-like procedure) over Uu to the NW.

[0264] The WTRU may transmit a re-establishment request to the NW on Uu, for example, after receiving a message from the network. The remote WTRU may initiate a legacy re-establishment procedure, for example, without cell selection (for example, assuming that the selected cell may be a cell associated with the direct Uu path before receiving the message from the relay). The remote WTRU may perform the procedure (for example, (only) the procedure) based on satisfying one or more (for example, specific) conditions (such as one or a combination of the following): the primary path of SRB1 is on the relay path; the relay WTRU message indicates that the (for example, new) cell (for example, on the relay path) is for HO that may be different from the cell on the direct path; the relay WTRU message indicates that the (for example, new) cell (for example, on the relay path) is for HO that may be part of a different cell group than the cell on the direct path; before receiving the message, the cells on the direct path and the indirect path are the same or different; before receiving the message from the relay WTRU, the WTRU communicates with the PCell via the relay path; and the like.

[0265] The WTRU may transmit an RRC message (e.g., another RRC message) (e.g., such as an RRC message that notifies the network of a relay message as discussed herein), for example, in a situation where the WTRU decides not to transmit a re-establishment request to the network or initiate a re-establishment-like process.

[0266] In an example, a combination of examples (eg, as described herein) may be performed.

[0267] The relay WTRU may provide additional information to the remote WTRU for bearer reconfiguration or recovery.

[0268] In an example, the relay WTRU may include additional information about events associated with the UuMessageTransferSidelink (e.g., HO, Uu RLF, etc.). Such information may be used by the remote WTRU for bearer reconfiguration or recovery actions, for example, when the remote WTRU may be in RRC_CONNECTED. The relay WTRU may derive such information, for example, based on information obtained from the network at the indicated events (e.g., each of the indicated events) (e.g., in the HO command). The relay WTRU may include (e.g., in the message) one or more of: security information; reestablishment / reset information; adaptation layer reconfiguration information; etc.

[0269] The relay WTRU may include (e.g., in a message) security information, such as, for example, security keys, key information, or an indication of whether a mobility event by the relay WTRU resulted in a key change at the relay WTRU. For example, a relay WTRU that receives a HO command from the network may provide an indication in PC5-RRC as to whether the relay WTRU received a masterKeyUpdate in the HO command. The remote WTRU may use the indication to determine whether to re-establish PDCP. The remote WTRU may re-establish PDCP, for example, if the relay WTRU indicates that it received a masterKeyUpdate. Otherwise, the remote WTRU may re-establish RLC and reset MAC without re-establishing PDCP.

[0270] The relay WTRU may include (e.g., in a message) re-establishment / reset information. For example, the relay WTRU may determine (e.g., after HO) whether to re-establish RLC (e.g., whether it needs to re-establish RLC). The relay WTRU may notify the remote WTRU in the UuMessageTransferSidelink (e.g., by including a to-remote-WTRU flag), for example, in the event that the relay WTRU determines to re-establish RLC. The remote WTRU may, for example, re-establish one or more protocol layers (e.g., re-establish PDCP and RLC) based on receipt of such an indication.

[0271] The relay WTRU may include (e.g., in a message) the adaptation layer reconfiguration information. The relay WTRU may receive the adaptation layer reconfiguration information, e.g., in a HO command. The relay WTRU may determine whether the reconfiguration information in the adaptation layer affects the remote WTRU. If the reconfiguration information in the adaptation information affects the remote WTRU, the relay WTRU may indicate this to the remote WTRU. The remote WTRU may reestablish one or more protocol layers and / or transmit a PDCP status report, e.g., based on receiving such an indication by the remote WTRU.

[0272] The relay WTRU may transmit an indication (e.g., an explicit indication) to the remote WTRU, for example, to trigger the remote WTRU to re-establish the protocol layer and / or transmit a status report. The relay WTRU may (e.g., alternatively) transmit information used (e.g., required) for re-establishment by the remote WTRU. The remote WTRU may determine to perform re-establishment, key update, status report, etc., for example, if (e.g., when) such information is included in a PC5-RRC message.

[0273] The WTRU may initiate a re-establishment after a failed path addition.

[0274] In an example, the WTRU may initiate a re-establishment procedure after a failed path addition. For example, a remote WTRU configured with an indirect path may receive (e.g., only receive) a direct path addition. The remote WTRU may trigger a re-establishment procedure (e.g., possibly on an indirect path), for example, in a situation where the direct path addition fails (e.g., RACH failure, no acknowledgement of a completion message is received, etc.). The WTRU may (e.g., further) determine whether to initiate a re-establishment procedure, for example, depending on the cell ID associated with the path being added. The remote WTRU may trigger a re-establishment based on the failure of the path addition, for example, in a situation where the direct path being added has a cell ID that is different from the indirect path cell ID. Otherwise, if the cell IDs may be the same, the remote WTRU may send another RRC message after the direct path addition fails, or may not send an RRC message.

[0275] The re-establishment procedure may depend on the selected path and / or cell relations.

[0276] In one example, a remote WTRU configured with multipath that triggers reestablishment may perform a path-dependent reestablishment procedure. The reestablishment (e.g., actions performed in the reestablishment) may depend on whether the WTRU selects a relay WTRU to perform the reestablishment via a relay, or selects a cell and performs the reestablishment via direct Uu. The reestablishment (e.g., alternatively) may depend on whether the same or different cells may be configured on the direct path and the indirect path. The procedures (e.g., actions) performed in the reestablishment may be different and may include one or more of the following: whether the WTRU releases the PC5-RRC connection; whether the WTRU selects (e.g., based on criteria) the best cell / relay or any cell / relay that meets a suitability criterion (e.g., RSRP above a threshold); whether the WTRU initiates CHO (e.g., if CHO candidates may be configured); whether the WTRU releases the multipath configuration; whether the relay is excluded in the relay / cell selection; and the like.

[0277] For example, the remote WTRU may release the PC5-RRC connection, for example, if the re-establishment results in the selection of a different relay WTRU. The remote WTRU may maintain the PC5-RRC connection, for example, if the remote WTRU selects a cell to perform re-establishment via Uu.

[0278] The remote WTRU may release the PC5-RRC connection, for example, in the case where the cell selected during the re-establishment process may be different from the PCell when the re-establishment is triggered. The remote WTRU may maintain the PC5-RRC connection, for example, in the case where the cell selected when the re-establishment is triggered may be the same as the PCell, or in the case where the cell selected may be the same as the cell serving the relay path.

[0279] In an example, the remote WTRU may trigger a re-establishment and perform a relay / cell selection. In the relay / cell selection, the remote WTRU may prioritize the relay selection over the same relay. The remote WTRU may maintain the PC5-RRC connection during the cell / relay reselection. If the remote WTRU selects the same relay WTRU, the PC5-RRC connection may already be established. In such a case, the PC5-RRC connection may not need to be torn down. The remote WTRU may prioritize the same relay WTRU by selecting the relay as long as the relay measurement is above a threshold (e.g., even if other cells / relays have better measurements).

[0280] The remote WTRU may exclude from selection (e.g., refrain from selection) (e.g., in relay / cell selection) a relay WTRU that is the same as the relay WTRU that was previously connected via a PC5-RRC connection in the multipath, for example, if the relay WTRU may still be connected to the same cell before the re-establishment is triggered. The remote WTRU may also perform such exclusion based on conditions related to the cause of the re-establishment (e.g., the re-establishment is triggered when the remote WTRU receives an indication of a Uu RLF from the relay WTRU and the relay WTRU may still be served by the same cell).

[0281] The remote WTRU may inform the network during re-establishment whether the PC5-RRC connection is maintained from the previous connection, and the specific relay WTRU associated with the PC5-RRC connection.

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

[0283] Although the implementations described herein may consider 3GPP specific protocols, it should be understood that the implementations described herein are not limited to such scenarios and are applicable to other wireless systems. For example, although the solutions described herein consider LTE, LTE-A, New Radio (NR) or 5G specific protocols, it should be understood that the solutions described herein are not limited to such scenarios and are also applicable to other wireless systems.

[0284] The processes described above may be implemented in a computer program, software, and / or firmware incorporated in a computer-readable medium for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as, but not limited to, built-in hard disks and removable disks), magneto-optical media, and / or optical media (such as compact disk (CD)-ROM disks and / or digital versatile disks (DVDs)). A processor associated with the software may be used to implement a radio frequency transceiver for a WTRU, terminal, base station, RNC, and / or any host computer.

Claims

1. A long-range wireless transmit / receive unit (WTRU), the WTRU comprising: a processor, the processor configured to: receiving configuration information including multipath data transmission information, a first threshold, and a second threshold, wherein the multipath data transmission information indicates a direct path and an indirect path, and wherein the indirect path is associated with a relay WTRU; receiving an indication indicating status information associated with the relay WTRU; determining a split bearer threshold based on the indication, wherein the split bearer threshold is determined to be one of the first threshold or the second threshold; Determine the amount of data; Determining that the data amount is greater than the split carrying threshold; as well as Based on the determination that the amount of data is greater than the split bearer threshold, data is transmitted using the indirect path.

2. The remote WTRU of claim 1, wherein the indication of state information associated with the relay WTRU indicates a connected mode, and wherein the split bearer threshold is determined to be the first threshold.

3. The remote WTRU of claim 1 , wherein the indication indicating status information associated with the relay WTRU indicates an idle mode or an inactive mode, and wherein the split bearer threshold is determined to be the second threshold.

4. The remote WTRU of claim 1, wherein the first threshold is lower than the second threshold.

5. The remote WTRU of claim 1 , wherein the direct path uses a Uu path, and wherein the indirect path uses a sidelink path.

6. The remote WTRU of claim 1 , wherein the data transmitted using the indirect path is a first set of data, and wherein the processor is further configured to: Based on the determination that the amount of data is greater than the split bearer threshold, a second set of data is sent using the direct path, wherein the first set of data is different from the second set of data.

7. The remote WTRU of claim 1 , wherein the data transmitted using the indirect path is a first set of data, and wherein the processor is further configured to: Based on the determination that the amount of data is greater than the split bearer threshold, a second set of data is sent using the direct path, wherein the first set of data is the same as the second set of data.

8. A method comprising: receiving configuration information including multipath data transmission information, a first threshold, and a second threshold, wherein the multipath data transmission information indicates a direct path and an indirect path, and wherein the indirect path is associated with a relay WTRU; receiving an indication indicating status information associated with the relay WTRU; determining a split bearer threshold based on the indication, wherein the split bearer threshold is determined to be one of the first threshold or the second threshold; Determine the amount of data; Determining that the data amount is greater than the split carrying threshold; as well as Based on the determination that the amount of data is greater than the split bearer threshold, data is transmitted using the indirect path.

9. The method of claim 8, wherein the indication of state information associated with the relay WTRU indicates a connected mode, and wherein the split bearer threshold is determined to be the first threshold.

10. The method of claim 8, wherein the indication indicating state information associated with the relay WTRU indicates an idle mode or an inactive mode, and wherein the split bearer threshold is determined to be the second threshold. The method of claim 8 , wherein the first threshold is lower than the second threshold.

12. The method of claim 8, wherein the direct path uses a Uu path, and wherein the indirect path uses a sidelink path.

13. The method of claim 8, wherein the data transmitted using the indirect path is a first set of data, and wherein the method further comprises: Based on the determination that the amount of data is greater than the split bearer threshold, a second set of data is sent using the direct path, wherein the first set of data is different from the second set of data.

14. The method of claim 8, wherein the data transmitted using the indirect path is a first set of data, and wherein the method further comprises: Based on the determination that the amount of data is greater than the split bearer threshold, a second set of data is sent using the direct path, wherein the first set of data is the same as the second set of data.

Images