WO2025019348A1

WO2025019348A1 - Split bearer threshold determination for multipath with multiple indirect paths

Info

Publication number: WO2025019348A1
Application number: PCT/US2024/037871
Authority: WO
Inventors: Martino M. Freda; Oumer Teyeb; Tuong Duc HOANG; Ananth KINI
Original assignee: InterDigital Patent Holdings Inc
Current assignee: InterDigital Patent Holdings Inc
Priority date: 2023-07-14
Filing date: 2024-07-12
Publication date: 2025-01-23
Anticipated expiration: 2026-01-14
Also published as: CN121753471A

Abstract

Systems, methods, devices, and instrumentalities are described herein related to split bearer threshold determination. A remote wireless transmit/receive unit (WTRU) may receive configuration information indicating a first split bearer threshold associated with a first number of available indirect paths and a second split bearer threshold associated with a second number of available indirect paths. The remote WTRU may determine a number of available indirect paths (e.g., the first number of available indirect paths or the second number of available indirect paths). On a condition that the number of available indirect paths is the first or second number of available indirect paths, the first or second split bearer threshold may be selected. A path may be determined based on whether an amount of data available for transmission exceeds the selected first or second split bearer threshold. Data may be sent using the determined path.

Description

SPLIT BEARER THRESHOLD DETERMINATION FOR MULTIPATH WITH MULTIPLE INDIRECT

PATHS

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of Provisional U.S. Patent Application No. 63/526,850, filed July 14, 2023, the disclosure of which is incorporated herein by reference in its entirety.

BACKGROUND

[0002] Mobile communications using wireless communication continue to evolve. A fifth generation may be referred to as 5G. A previous (legacy) generation of mobile communication may be, for example, fourth generation (4G) long term evolution (LTE).

SUMMARY

[0003] Systems, methods, devices, and instrumentalities are described herein related to split bearer threshold determination (e.g., for multipath with multiple indirect paths).

[0004] A wireless transmit/receive unit (WTRU) (e.g., a remote WTRU) may be configured in multipath (e.g., with a primary path via Uu and multiple non-primary paths via i ndirect/relayfs)). The remote WTRU may be configured with a split bearer threshold that may be used to send data over a primary path or a non-primary path. The remote WTRU may be configured with (e.g., receive configuration information indicating) a different split bearer threshold (e.g., threshold for the amount of data that may be sent (e.g., transmitted) by the split bearer on the indirect/non-primary path) for each combination of number of available indirect paths.

[0005] A remote WTRU may receive configuration information indicating a first split bearer threshold (e.g., a first threshold amount of data allowed for transmitting data using an indirect path) associated with a first number of available indirect paths (e.g., which may be applicable if the number of available paths is equal to X) and a second split bearer threshold (e.g., a second threshold amount of data allowed for transmitting data using an indirect path) associated with a second number of available indirect paths (e.g., which may be applicable if the number of available paths is equal to Y, etc., where X and Y may be respective values or ranges of values).

[0006] In examples, the remote WTRU may be configured to receive, from a relay WTRU (e.g., from each of the relay WTRUs), a unicast (e.g., a respective unicast) sidelink discontinuous reception (SL DRX) configuration associated with (e.g., each associated with) an indirect path. The remote WTRU may determine whether an indirect path is an available indirect path based on the received unicast SL DRX configuration. In examples, the remote WTRU may be configured to receive, from a relay WTRU (e.g., from each of the relay WTRUs), a failure notification (e.g., respective failure notification(s)) associated with (e.g., each associated with) an indirect path. The remote WTRU may determine whether an indirect path is an available indirect path based on the received failure notification.

[0007] The remote WTRU may determine a number of available indirect paths. In examples, the determined number of indirect paths may be the first number of available indirect paths or the second number of available indirect paths. The remote WTRU may determine the number of available indirect paths based on at least one of: the number of indirect paths (e.g., the number of different relay WTRUs) configured for which there is no pending path failure signaled by the relay WTRU (e.g., in a failure notification) (e.g., Uu-RLF, relay flow control, etc.); or a number of indirect paths for which there is no SL DRX configuration.

[0008] The remote WTRU may select the split bearer threshold associated with the determined number of available indirect paths. In examples, the remote WTRU may select the first split bearer threshold on a condition that the number of available indirect paths is the first number of available indirect paths. The remote WTRU may select the second split bearer threshold on a condition that the number of available indirect paths is the second number of available indirect paths. The WTRU may determine a path based on whether an amount of data available for transmission satisfies (e.g., exceeds) the split bearer threshold (e.g., the selected first split threshold or the selected second split bearer threshold). The remote WTRU may send data using the determined path.

[0009] In examples, the WTRU may determine that the amount of data available for transmission at the split bearer is above the selected split bearer threshold (e.g., the first split bearer threshold or the second split bearer threshold). The remote WTRU may determine the path is the direct/primary path or the indirect/non-primary path (e.g., determine to use the direct/primary path or the indirect/non-primary path) based on a determination that the amount of data available for transmission is above the selected split bearer threshold (e.g., the first split bearer threshold or the second split bearer threshold). The remote WTRU may send (e.g., transmit) data using the split bearer via the determined direct/primary path or the indirect/non-primary path.

[0010] In examples, the WTRU may determine that the amount of data available for transmission at the split bearer is equal to or below the selected split bearer threshold (e.g., the first split bearer threshold or the second split bearer threshold). The remote WTRU may determine the path is the direct/primary path (e.g., determine to use the direct/primary path) based on a determination that the amount of data available for transmission is equal to or below the selected split bearer threshold (e.g., the first split bearer threshold or the second split bearer threshold). The remote WTRU may send (e.g., transmit) data for the split bearer via the determined primary path (e.g., via the primary path only).

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] FIG. 1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented.

[0012] FIG. 1 B is a system diagram illustrating an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0013] FIG. 1 C is a system diagram illustrating an example radio access network (RAN) and an example core network (ON) that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0014] FIG. 1 D is a system diagram illustrating a further example RAN and a further example ON that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0015] FIG. 2 illustrates an example of a remote WTRU that is out of coverage.

[0016] FIG. 3A illustrates an example user plane protocol stack for a L2 WTRU-to-network relay.

[0017] FIG. 3B illustrates an example control plane protocol stack for a L2 WTRU-to-network relay.

[0018] FIG. 4 illustrates an example of a remote WTRU in coverage that is connected via a direct path and an indirect path.

DETAILED DESCRIPTION

[0019] FIG. 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word DFT-Spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0020] As shown in FIG. 1A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104/113, a ON 106/115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated 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 a “STA”, may be configured to transmit and/or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a UE. [0021] The communications systems 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 the 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, a NR NodeB, 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.

[0022] The base station 114a may be part of the RAN 104/113, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and/or the 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 a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a wireless service to a specific geographical area that may be relatively fixed or that may change over time. The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In an embodiment, the 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 desired spatial directions. [0023] 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).

[0024] More specifically, as noted above, the communications 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, and the like. For example, the base station 114a in the RAN 104/1 13 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115/116/117 using wideband CDMA (WCDMA). 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).

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

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

[0027] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by 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., a eNB and a gNB).

[0028] 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), and the like.

[0029] The base station 114b in FIG. 1 A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, 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 an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106/115.

[0030] 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 varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106/115 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, it will be 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 be utilizing a NR radio technology, the CN 106/115 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0031 ] The CN 106/115 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or the other networks 112. The PSTN 108 may include circuit- switched telephone networks that provide 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), user datagram protocol (UDP) and/or the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 112 may include wired and/or wireless communications 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.

[0032] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with 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.

[0033] FIG. 1 B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1 B, the WTRU 102 may include 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, among others. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0034] 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 in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. 1 B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

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

[0038] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or 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 the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0039] The processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the 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, and the like.

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

[0041] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and/or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and/or Augmented Reality (VR/AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors, the sensors may be one or more of 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.

[0042] 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 particular subframes for both the 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 to reduce and or substantially eliminate self-interference via either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via 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 particular subframes for either the UL (e.g., for transmission) or the downlink (e.g., for reception)).

[0043] FIG. 1 C is a system diagram illustrating the RAN 104 and the CN 106 according to 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.

[0044] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-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 eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRU 102a.

[0045] Each of the eNode-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 the UL and/or DL, and the like. As shown in FIG. 1 C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0046] The CN 106 shown in FIG. 1 C 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 are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator.

[0047] The MME 162 may be connected to each of the eNode-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, and the like. 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. [0048] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the 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 user planes during inter- eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

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

[0050] 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 communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.

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

[0052] In representative embodiments, the other network 112 may be a WLAN.

[0053] A WLAN in Infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have an access or an interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic in to and/or out of the BSS. Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. The traffic between STAs within a BSS may be considered and/or referred to as peer-to- peer traffic. The peer-to-peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS may use an 802.11e DLS or an 802.11 z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an “ad- hoc” mode of communication. [0054] When using the 802.11 ac infrastructure mode of operation or a similar mode of operations, 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., 20 MHz wide bandwidth) or a dynamically set width via signaling. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) may be implemented, for example in in 802.11 systems. For CSMA/CA, the STAs (e.g., every 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.

[0055] High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

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

[0057] Sub 1 GHz modes of operation are supported by 802.11 af and 802.11 ah. The channel operating bandwidths, and carriers, are reduced in 802.11 af and 802.11 ah relative to those used in 802.11 n, and 802.11 ac. 802.11 af supports 5 MHz, 10 MHz and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non- TVWS spectrum. According to a representative embodiment, 802.11 ah may support Meter Type Control/Machine-Type Communications, such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and/or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0058] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.11 n, 802.11 ac, 802.11 af, and 802.11 ah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest 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, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11 ah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and/or other channel bandwidth operating modes. Carrier sensing and/or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode), transmitting to the AP, the entire available frequency bands may be considered busy even though a majority of the frequency bands remains idle and may be available.

[0059] In the United States, the available frequency bands, which may be used by 802.11 ah, are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11 ah is 6 MHz to 26 MHz depending on the country code.

[0060] FIG. 1 D is a system diagram illustrating the RAN 113 and the CN 115 according to an embodiment. As noted above, the RAN 113 may employ an 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.

[0061] 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, gNBs 180a, 108b may utilize beamforming to transmit signals to and/or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, may use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum while the remaining component carriers may be on licensed spectrum. In an embodiment, the 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).

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

[0063] 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 the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration WTRUs 102a, 102b, 102c may communicate with/connect to gNBs 180a, 180b, 180c while also communicating with/connecting to another RAN such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In the non-standalone configuration, eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and/or throughput for servicing WTRUs 102a, 102b, 102c.

[0064] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, support of network slicing, dual connectivity, interworking between NR and E- UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1 D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

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

[0066] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of NAS signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, and/or the like. 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. [0067] The SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 115 via an N11 interface. The SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 115 via an N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating UE IP address, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and the like. A PDU session type may be IP-based, non-IP based, Ethernetbased, and the like.

[0068] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet- switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The 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, and the like.

[0069] 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 serves 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 the other networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to a local Data Network (DN) 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0070] In view of Figures 1A-1 D, and the corresponding description of Figures 1A-1 D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and/or any other device(s) described herein, may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and/or to simulate network and/or WTRU functions.

[0071] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and/or in an operator network environment. For example, the one or more emulation devices may perform the one or more, 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. The one or more emulation devices may perform the one or more, or all, functions while being temporarily implemented/deployed as part of a wired and/or wireless communication network. The emulation device may be directly coupled to another device for purposes of testing and/or may performing testing using over-the-air wireless communications.

[0072] The one or more emulation devices may perform the one or more, including all, functions while not being implemented/deployed as part of a wired and/or wireless communication network. For example, the emulation devices may be utilized in a testing scenario in a testing laboratory and/or a non-deployed (e.g., testing) wired and/or wireless communication network in order to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and/or wireless communications via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and/or receive data.

[0073] Systems, methods, devices, and instrumentalities are described herein related to split bearer threshold determination (e.g., for multipath with multiple indirect paths).

[0074] A WTRU (e.g., a remote WTRU) may be configured in multipath (e.g., with a primary path via Uu and multiple non-primary paths via indirectZrelay(s)). The remote WTRU may be configured with a split bearer threshold that may be used to send data over a primary path or a non-primary path. The remote WTRU may be configured with (e.g., receive configuration information indicating) a different split bearer threshold (e.g., threshold for the amount of data that may be sent (e.g., transmitted) by the split bearer on the indirect/non-primary path) for each combination of number of available indirect paths.

[0075] A remote WTRU may receive configuration information indicating a first split bearer threshold (e.g., a first threshold amount of data allowed for transmitting data using an indirect path) associated with a first number of available indirect paths (e.g., which may be applicable if the number of available paths is equal to X) and a second split bearer threshold (e.g., a second threshold amount of data allowed for transmitting data using an indirect path) associated with a second number of available indirect paths (e.g., which may be applicable if the number of available paths is equal to Y, etc., where X and Y may be respective values or ranges of values).

[0076] In examples, remote WTRU may be configured to receive, from a relay WTRU (e.g., from each of the relay WTRUs), a unicast (e.g., a respective unicast) SL DRX configuration associated with (e.g., each associated with) an indirect path. The remote WTRU may determine whether an indirect path is an available indirect path based on the received unicast SL DRX configuration. In examples, the remote WTRU may be configured to receive, from a relay WTRU (e.g., from each of the relay WTRUs), a failure notification (e.g., respective failure notification (s)) associated with (e.g., each associated with) an indirect path. The remote WTRU may determine whether an indirect path is an available indirect path based on the received failure notification.

[0077] The remote WTRU may determine a number of available indirect paths. In examples, the determined number of indirect paths may be the first number of available indirect paths or the second number of available indirect paths. The remote WTRU may determine the number of available indirect paths based on at least one of: the number of indirect paths (e.g., the number of different relay WTRUs) configured for which there is no pending path failure signaled by the relay WTRU (e.g., in a failure notification) (e.g., Uu-RLF, relay flow control, etc.); or a number of indirect paths for which there is no SL DRX configuration.

[0078] The remote WTRU may select the split bearer threshold associated with the determined number of available indirect paths. In examples, the remote WTRU may select the first split bearer threshold based on the number of available indirect paths being the first number of available indirect paths. The remote WTRU may select the second split bearer threshold based on the number of available indirect paths being the second number of available indirect paths. The WTRU may determine a path based on whether an amount of data available for transmission satisfies (e.g., exceeds) the split bearer threshold (e.g., the selected first split threshold or the selected second split bearer threshold). The remote WTRU may send data using the determined path.

[0079] In examples, the WTRU may determine that the amount of data available for transmission at the split bearer is above the selected split bearer threshold (e.g., the first split bearer threshold or the second split bearer threshold). The remote WTRU may determine the path is the direct/primary path or the i ndirect/non-primary path based on a determination that the amount of data available for transmission is above the selected split bearer threshold (e.g., the first split bearer threshold or the second split bearer threshold). The remote WTRU may send (e.g., transmit) data using the split bearer via the determined direct/primary path or the indirect/non-primary path.

[0080] In examples, the WTRU may determine that the amount of data available for transmission at the split bearer is equal to or below the selected split bearer threshold (e.g., the first split bearer threshold or the second split bearer threshold). The remote WTRU may determine the path is the direct/primary path or based on a determination that the amount of data available for transmission is equal to or below the selected split bearer threshold (e.g., the first split bearer threshold or the second split bearer threshold). The remote WTRU may send (e.g., transmit) data for the split bearer via the determined primary path (e.g., via the primary path only). [0081] Systems, methods, devices, and instrumentalities are described herein related to applying split bearer threshold(s) to individual indirect paths.

[0082] A device, such as a wireless transmit/receive unit (WTRU), may include a processor configured to perform one or more actions. The WTRU may determine or receive an indication of a plurality of indirect paths. The plurality of indirect paths (e.g., each of the plurality of indirect paths) may be associated with a relay WTRU (e.g., a respective relay WTRU). The WTRU may determine that an indirect path of the plurality of indirect paths is an anchor path. The WTRU may send data using the anchor path (e.g., if an amount of data is below an anchor path data threshold).

[0083] In examples, the indirect path may be determined to be the anchor path based on a determination that a number of hops on the indirect path is a minimum number of hops compared to another indirect path of the plurality of indirect paths. In examples, the indirect path may be determined to be the anchor path based on a determination that the indirect path is served by a cell that serves a direct path associated with the WTRU.

[0084] Systems, methods, devices, and instrumentalities are described herein related to data splitting between direct and indirect paths.

[0085] A device, such as a wireless transmit/receive unit (WTRU), may include a processor configured to perform one or more actions. The WTRU may determine or receive an indication of a primary path and a number of available indirect paths. The WTRU may select a data split based on a number of available indirect paths and/or a respective flow control level associated with each of the available indirect paths. The WTRU may send data using the primary path and the number of available indirect paths. The data may be sent based on the data split.

[0086] The WTRU may receive a flow control message (e.g., a respective flow control message) for an available indirect path (e.g., each available indirect path). The flow control level (e.g., respective flow control level) associated with an available indirect path (e.g., each of the available indirect paths) may be based on the flow control message (e.g., respective flow control message).

[0087] In examples, the data split may be selected based on a mapping of the data split to the number of available indirect paths and the flow control level associated with an available indirect path (e.g., each of the available indirect paths). In examples, the data may be sent using the primary path and the number of available indirect paths over an evaluation window. The WTRU may determine the data split cannot be satisfied. The WTRU may send an indication (e.g., to the network) indicating the data split cannot be met. [0088] Systems, methods, devices, and instrumentalities are described herein related to activation and deactivation of an indirect path.

[0089] A device (e.g., a wireless transmit/receive unit (WTRU)) may include a processor configured to perform one or more actions. The WTRU may determine or receive an indication of a first indirect path associated with a first relay. The discontinuous reception (DRX) associated with the first relay may be enabled. The WTRU may determine whether to disable DRX for the first relay. The determination of whether to disable DRX may be based on a comparison of a buffer status associated with the first indirect path to a buffer threshold. The WTRU may send a DRX indication to the first relay using the first indirect path. The DRX indication may indicate whether to disable DRX associated with the first relay.

[0090] The WTRU may receive a control flow indication associated with the first relay. The WTRU may select a data split for the first indirect path based on the control flow indication. The WTRU may send data using the first indirect path. The data may be sent based on the data split. In examples, the data may be sent over a preconfigured window. In examples, the DRX indication may indicate to disable DRX associated with the first relay when the buffer status is above the buffer threshold for a period of time. [0091] A device, such as a wireless transmit/receive unit (WTRU), may include a processor configured to perform one or more actions. The WTRU may determine or receive a first indirect path associated with a first relay. The DRX associated with the first relay may be disabled. The WTRU may determine a DRX indication indicating whether to enable DRX for the first relay. The DRX indication may be based on a comparison of a buffer status associated with the first indirect path to a buffer threshold. The WTRU may send the DRX indication to the first relay using the first indirect path. In examples, the DRX indication may indicate to enable DRX associated with the first relay when the buffer status is below the buffer threshold for a period of time.

[0092] The term special cell (SpCell) may refer to the primary cell (P Cell) of the master cell group (MCG) or the PSCell of the secondary cell group (SCG) (e.g., depending on whether the medium access control (MAC) entity is associated to the MCG or the SCG).

[0093] Feature(s) associated with WTRU to network relay for out of coverage (OOC) WTRUs are provided herein.

[0094] Sidelink-based (SL-based) WTRU to network relays may be specified. Sidelink relay(s) may be introduced to support ProSe WTRU-to-network relay (U2N relay) function (e.g., to provide connectivity to the network for U2N remote WTRU(s)). L2 and L3 U2N relay architectures may be supported. The L3 U2N relay architecture may be transparent to the serving RAN of the U2N relay WTRU (e.g., except for controlling sidelink resources).

[0095] A U2N relay WTRU may be in RRC_CONNECTED to perform relaying of unicast data. For L2 U2N relay operation, one or more of the following RRC state combinations may be supported: both U2N relay WTRU and U2N remote WTRU may be in RRC CONNECTED to perform transmission/reception of relayed unicast data; or the U2N relay WTRU may be in RRCJDLE, RRCJNACTIVE or RRC_CONNECTED (e.g., if all the U2N remote WTRU(s) that are connected to the U2N relay WTRU are either in RRCJNACTIVE or in RRCJDLE). [0096] For L2 U2N relay, the U2N remote WTRU may be configured to use resource allocation mode 2 for data to be relayed. A single unicast link may be established between one L2 U2N relay WTRU and one L2 U2N remote WTRU. The traffic of U2N remote WTRU via a given U2N relay WTRU and the traffic of the U2N relay WTRU may be separated in different Uu RLC channels over Uu.

[0097] FIG. 2 illustrates an example of a remote WTRU that is OOC. Layer 2 WTRU may be introduced to network relays (e.g., if a remote WTRU is out of coverage). In multipath, a remote WTRU may be assumed to be in coverage and may utilize one or more of Uu path, or SL (e.g., relayed) path.

[0098] Multi-path support may enhance reliability and throughput (e.g., by switching among or utilizing the multiple paths simultaneously). A WTRU may be connected to the same gNB using one direct path and one indirect path (e.g., via a Layer-2 WTRU-to-Network relay, or via another WTRU, for example, where the WTRU-WTRU inter-connection may be ideal). Support of Layer-3 WTRU-to-Network relay in multi-path scenario may be assumed to have no RAN impact.

[0099] Feature(s) associated with L2 U2N relay protocol architecture are provided herein.

[0100] FIG. 3A illustrates the protocol stacks for the user plane of L2 U2N relay architecture. FIG. 3B illustrates the protocol stack for the control plane of L2 U2N relay architecture. The SRAP sublayer may be placed above the RLC sublayer for cyclic prefix (CP) and UP at the PC5 interface and/or the Uu interface. The Uu SDAP, PDCP and RRC may be terminated between the L2 U2N remote WTRU and the gNB, while SRAP, radio link control (RLC), medium access control (MAC) and physical layer (PHY) may be terminated in each hop (e.g., the link between L2 U2N remote WTRU and L2 U2N relay WTRU and the link between L2 U2N relay WTRU and the gNB).

[0101] For L2 U2N relay, the SRAP sublayer over PC5 hop may be for the purpose of bearer mapping. The SRAP sublayer may not be present over PC5 hop for relaying the L2 U2N remote WTRU’s message on BCCH and PCCH. For the L2 U2N remote WTRU’s message on SRB0, the SRAP sublayer may not be present over PC5 hop, but the SRAP sublayer may be present over Uu hop for downlink (DL) and uplink (UL).

[0102] For the L2 U2N relay, for uplink, the Uu sublayer may support UL bearer mapping between ingress PC5 relay RLC channels for relaying and egress Uu relay RLC channels over the L2 U2N relay WTRU Uu interface. For uplink relaying traffic, the different end-to-end RBs (e.g., SRBs or DRBs) of the same remote WTRU and/or different remote WTRUs may be multiplexed (e.g., over the same Uu relay RLC channel). For the L2 U2N relay, for uplink, the Uu SRAP sublayer may support L2 U2N remote WTRU identification for the UL traffic. The identity information of L2 U2N remote WTRU Uu Radio Bearer and a local remote WTRU ID may be included in the Uu SRAP header at UL (e.g., in order for gNB to correlate the received packets for the specific PDCP entity associated with the right Uu Radio Bearer of a remote WTRU). For the L2 U2N relay, for uplink, the PC5 SRAP sublayer at the L2 U2N remote WTRU may support UL bearer mapping between remote WTRU Uu radio bearers and egress PC5 relay RLC channels. [0103] For the L2 U2N relay, for downlink, the Uu SRAP sublayer may support DL bearer mapping at gNB to map end-to-end radio bearer (e.g., signaling radio bearer (SRB), data radio bearer (DRB)) of remote WTRU into Uu relay RLC channel over relay WTRU Uu interface. The Uu SRAP sublayer may support DL bearer mapping and data multiplexing between multiple end-to-end radio bearers (e.g., SRBs or DRBs) of a L2 U2N remote WTRU and/or different L2 U2N remote WTRUs and one Uu relay RLC channel over the relay WTRU Uu interface. For the L2 U2N relay, for downlink, the Uu SRAP sublayer may support remote WTRU identification for DL traffic. The identity information of remote WTRU Uu radio bearer and a local remote WTRU ID may be included into the Uu SRAP header by the gNB at DL (e.g., in order for relay WTRU to map the received packets from remote WTRU Uu radio bearer to its associated PC5 relay RLC channel). For the L2 U2N relay, for downlink, the PC5 SRAP sublayer at the relay WTRU may support DL bearer mapping between ingress Uu relay RLC channels and egress PC5 relay RLC channels. For the L2 U2N relay, for downlink, the PC5 SRAP sublayer at the remote WTRU may correlate the received packets for the specific PDCP entity associated with the right Uu radio bearer of a remote WTRU (e.g., based on the identity information included in the Uu SRAP header).

[0104] A local remote WTRU ID may be included in a PC5 SRAP header and a Uu SRAP header. The L2 U2N relay WTRU may be configured by the gNB with the local remote WTRU ID to be used in SRAP header. The remote WTRU may obtain the local remote ID from the gNB via Uu RRC messages (e.g., RRCSetup, RRCReconfiguration, RRCResume and RRCReestablishment). Uu DRB(s) and Uu SRB(s) may be mapped to different PC5 relay RLC channels and Uu relay RLC channels in PC5 hop and Uu hop. The gNB may be responsible to avoid collision on the usage of local remote WTRU ID. The gNB may update the local remote WTRU ID by sending the updated local remote ID (e.g., via a RRCReconfiguration message) to the relay WTRU. The serving gNB may perform a local remote WTRU ID update (e.g., independent of the PC5 unicast link L2 ID update procedure).

[0105] Feature(s) associated with sidelink scheduling are provided herein.

[0106] Sidelink may support two scheduling modes (e.g., mode 1 and mode 2). For an in-coverage WTRU, the gNB may control whether a WTRU transmits using mode 1 or mode 2.

[0107] In mode 1 scheduling (e.g., that may be used for a sidelink WTRU in RRC_CONNECTED), a WTRU may receive SL grants directly from the network in DCI. The WTRU may report buffer status for SL data grouped by a destination index (e.g., where a destination index may correspond to a unique L2 destination ID, or pair of source/destination L2 ID). The WTRU may report SL SR if a SL grant is not available for transmission of the pending data. [0108] In mode 2 scheduling, which may be used by a WTRU in any RRC state or a WTRU which may be out of coverage, a WTRU may be configured with a resource pool from which it performs autonomous resource selection and scheduling. Resources may be selected by the WTRU (e.g., based on information in previous SCI transmissions by other WTRUs, such as sensing results).

[0109] Feature(s) associated with advanced multipath are provided herein. Multipath SL relaying may be implemented such that a remote WTRU in coverage can send data via the Uu path and a single SL WTRU- to-NW relay. The same gNB may be used for the cell of the relay WTRU and the cell controlling the remote WTRU (e.g., same cell or different cell cases may be considered). DC architecture (e.g., split bearers with data split at PDCP) may be assumed for multipath.

[0110] FIG. 4 illustrates an example of a remote WTRU in coverage that is connected via a direct path and an indirect path (e.g., via a relay WTRU). Multiple indirect paths through different relays (e.g., where relayed paths may include multiple hops) may be implemented. A WTRU in coverage may be connected in DC (e.g., via a direct path and an indirect path), but the WTRU may use multiple indirect paths (e.g., CA- like architecture or DC-like architecture). A WTRU OOC may use multiple relays to connect to the network (e.g., in CA-like architecture or DC-like architecture).

[0111] Dual connectivity (DC) may use a split bearer threshold for the WTRU to determine if to use the SCG for each split bearer (e.g., Uu primary path and a relayed/indirect secondary path). Multipath may allow for multiple relay WTRUs on the indirect path. Multiple paths may be present. The status of a path (e.g., each path) may change based on the relay status.

[0112] If multiple indirect paths are present, data may be split on the indirect path depending on the model of the indirect paths (e.g., each indirect path). If DC-like modeling is used, the WTRU may split the data at PDCP. The decision for splitting the data may be made prior to requesting resources from the network. If multiple indirect paths are present, one of the paths may or may not be preferred over the others (e.g., the factors may be different than multipath or CA).

[0113] For multipath, the same cell may control the direct and indirect path (e.g., contrary to DC). Determining a split bearer threshold may be restrictive for the network for multipath if a single gNB or cell controls the direct and indirect paths. For a WTRU that is OOC, the sidelink discontinuous reception (SL- DRX) may depend on WTRU implementation. If limited data may be expected on the multiple paths in multipath without a direct Uu path, maintaining SL-DRX may be preferred. For large amounts of data, disabling DRX may be preferred.

[0114] Feature(s) associated with split bearer threshold determination for multipath with multiple indirect paths are provided herein. A remote WTRU in multipath (e.g., primary path via Uu, and non-primary path via i ndi rect/relay) with multiple indirect paths via different relays may determine whether to perform routing to an indirect path based on an amount of buffered data for a bearer and/or a number of active (e.g., non- DRX) and/or available (e.g., non-failed) indirect paths (e.g., as failure may be indicated by the relay WTRUs).

[0115] In examples, one or more of the following may be performed (e.g., associated with a remote WTRU determining and/or using a split bearer threshold). A WTRU (e.g., a remote WTRU used as an example herein) may be configured in multipath (e.g., with a primary path via Uu and multiple non-primary paths via indirectZrelay(s)). The remote WTRU may be configured with a split bearer that may be used to send data over a primary path or one or more non-primary paths. The remote WTRU may be configured with (e.g., receive configuration information indicating) a different split bearer threshold (e.g., threshold for the amount of data that may be routed (e.g., transmitted) by the split bearer on the indirect/non-primary path) for each combination of number of available indirect paths. In examples, the remote WTRU may receive configuration information (e.g., from a network node) that indicates a first split bearer threshold (e.g., a first threshold amount of data allowed for transmitting data using a first indirect path) associated with a first number of available indirect paths (e.g., which may be applicable if the number of available paths is equal to X) and a second split bearer threshold (e.g., a second threshold amount of data allowed for transmitting data using a second indirect path) associated with a second number of available indirect paths (e.g., which may be applicable if the number of available paths is equal to Y, etc., where X and Y may be respective values or ranges of values).

[0116] The remote WTRU may be configured to receive/receive, from a relay WTRU (e.g., from each of the relay WTRUs), a unicast (e.g., a respective unicast) SL DRX configuration associated with (e.g., each associated with) an indirect path. The remote WTRU may determine whether an indirect path is an available indirect path based on the received unicast SL DRX configuration. In examples, the remote WTRU may be configured to receive/receive, from relay WTRU(s), a failure notification (e.g., respective failure notification(s)) associated with an indirect path (e.g., if multiple failure notifications are received, each may be associated with a respective indirect path). The remote WTRU may determine whether an indirect path is an available indirect path based on the received failure notification.

[0117] The remote WTRU may determine a number of available indirect paths. The number of indirect paths may be the first number of available indirect paths or the second number of available indirect paths. The remote WTRU may determine the number of available indirect paths based on at least one of: the number of indirect paths (e.g., the number of different relay WTRUs) configured for which there is no pending path failure signaled by the relay WTRU (e.g., in a failure notification) (e.g., Uu-RLF, relay flow control, etc.); or a number of indirect paths for which there is no SL DRX configuration.

[0118] The remote WTRU may select the split bearer threshold associated with the determined number of available indirect paths. In examples, the remote WTRU may select the first split bearer threshold on a condition that the number of available indirect paths is the first number of available indirect paths. The remote WTRU may select the second split bearer threshold on a condition that the number of available indirect paths is the second number of available indirect paths. The WTRU may determine a path based on whether an amount of data available for transmission exceeds the split bearer threshold (e.g., the selected first split threshold or the selected second split bearer threshold). The remote WTRU may send data using the determined path.

[0119] In examples, the WTRU may determine that the amount of data available for transmission at the split bearer is above the selected split bearer threshold (e.g., the first split bearer threshold or the second split bearer threshold). The remote WTRU may determine the transmission path is the direct/primary path or any of the indirect/non-primary paths (e.g., determine to use the direct/primary path or any of the i ndirect/non-primary paths) based on a determination that the amount of data available for transmission is above the selected split bearer threshold (e.g., the first split bearer threshold or the second split bearer threshold). The remote WTRU may route (e.g., transmit) data using the split bearer via the determined direct/primary path or any of the indirect/non-primary paths.

[0120] In examples, the WTRU may determine that the amount of data available for transmission at the split bearer is equal to or below the selected split bearer threshold (e.g., the first split bearer threshold or the second split bearer threshold). The remote WTRU may determine the path is the direct/primary path (e.g., determine to use the direct/primary path) based on a determination that the amount of data available for transmission is equal to or below the selected split bearer threshold (e.g., the first split bearer threshold or the second split bearer threshold). The remote WTRU may route (e.g., transmit) data for the split bearer via the determined primary path (e.g., via the primary path only).

[0121] Feature(s) associated with applying a split bearer threshold to individual indirect paths are provided herein. A remote WTRU in multipath may determine whether to route data to one or multiple indirect paths based on one or more of: a number of hops in each indirect path, a cell ID served by the relay in the indirect path, or the amount of data buffered for transmission.

[0122] In examples, one or more of the following may be performed (e.g., for a remote WTRU to determine to route data to indirect path(s)). A remote WTRU may be configured with a bearer that is associated with at least two indirect paths (e.g., associated with different relay(s)). The remote WTRU may be configured with an anchor path data threshold. The remote WTRU may determine that one of the indirect paths is an anchor path for the bearer if: the WTRU is configured with a direct Uu path for the bearer and a cell serving the relay WTRU on that path is the same as the PCell on the direct Uu path; or the number of hops on the one indirect path is less than the number of hops on the other indirect paths. [0123] If the remote WTRU determines that it has an anchor path for the bearer, the remote WTRU may send (e.g., transmit) data (e.g., all available data) to the anchor path until the amount of buffered data is above a threshold and on such a condition send (e.g., transmit) data to the anchor path or the other indirect path(s). If the remote WTRU determines that it does not have an anchor path for the bearer, the remote WTRU may send (e.g., transmit) data to the anchor path or the other indirect path(s).

[0124] Feature(s) associated with data splitting between direct path(s) and indirect path(s) are provided herein. A remote WTRU in multipath may determine an amount of data to route to direct path(s) and indirect path(s) (e.g., each of the direct path(s) and indirect path(s)). A remote WTRU may determine a number of available paths. The remote WTRU may receive respective flow control indication(s) from the relay WTRUs (e.g., each relay WTRU) on the indirect path(s). The determination of the amount of data to route to direct path(s) and indirect path(s) may be based on the number of available paths and/or the flow control indications.

[0125] In examples one or more of the following may be performed (e.g., associated with a remote WTRU splitting data between direct path(s) and indirect path(s)). A remote WTRU may be configured in multipath with a primary path (e.g., via Uu) and a non-primary path (e.g., via indirect/relay(s)). The remote WTRU may be configured with a split bearer that may be used to send data over a primary path or a nonprimary path. The remote WTRU may be configured with (e.g., receive configuration information indicating) splits of data (e.g., percentage splits of data) between a primary path and a non-primary path. A respective split of data may be configured (e.g., receive configuration information) for a respective number of available indirect paths (e.g., a respective split of data for each number (or range) of indirect paths) or a combination of a respective number of available indirect paths and associated respective congestion level(s) (e.g., as may be indicated by each relay associated with the indirect paths). The remote WTRU may be configured with an evaluation window.

[0126] The remote WTRU may receive respective flow control message(s) from the relay WTRUs (e.g., each relay WTRU) associated with the indirect path(s) (e.g., on each indirect path). The flow control message(s) may indicate one of a number of flow control levels. The remote WTRU may select the configured data split based on a number of available paths (e.g., as determined or received by the remote WTRU) and/or the flow control indications (e.g., flow control levels associated with relay WTRUs on each path). The remote WTRU may send (e.g., transmit) data according to the selected data split. The split bearer may use the selected data split to send data to the primary path and the non-primary path (e.g., over the evaluation window). The remote WTRU may inform the network if the data split cannot be met (e.g., CBR limitation).

[0127] Feature(s) associated with activation and deactivation of an indirect path are provided herein. A remote WTRU may enable/disable SL-DRX on a link associated with a relay WTRU (e.g., based on the buffer status and respective flow control indications the relay WTRUs).

[0128] In examples one or more of the following may be performed (e.g., associated with a remote WTRU activating and/or deactivating DRX on a link associated with a relay WTRU). A remote WTRU may be configured with at least two indirect paths (e.g., via different relays). The remote WTRU may be configured with a percentage data split over multiple indirect paths. The remote WTRU may be configured with a respective percentage data split for a respective combination (e.g., each combination) of flow control levels that may be indicated by the relay WTRU(s). The remote WTRU may be configured with a buffer threshold for SL-DRX enable/disable.

[0129] The remote WTRU may receive respective flow control level indications from the relay WTRUs associated with each of the indirect paths. The remote WTRU may determine (e.g., based on each of the received flow control level indications) the corresponding percentage data split for each of the indirect paths. The remote WTRU may (e.g., over a (pre)configured window) ensure that the percentage of data routed to each path matches the percentage data split.

[0130] The remote WTRU may determine to enable/disable DRX (e.g., based on the actual buffer status being above/below the configured threshold). When the buffer status is above a threshold for at least a period of X and DRX is enabled on a link associated with a relay WTRU, the remote WTRU may send (e.g., transmit) a disable DRX indication to the relay WTRU. When the buffer status is below a threshold for at least a period of Y and DRX is disabled on a link associated with a relay WTRU, the remote WTRU may send (e.g., transmit) an enable DRX indication to the relay WTRU. The remote WTRU may send (e.g., transmit) DRX enable/disable to each of the relays (e.g., based on the determination(s)). The remote WTRU may send (e.g., transmit) data buffered for each indirect path to the associated relay.

[0131] Feature(s) associated with remote WTRU routing behavior are provided herein. Routing behavior may include one or more of the following: the WTRU determining the conditions (e.g., in terms of buffered amount of data) in which data can (e.g., start to) be transmitted to a path or multiple paths or not; the WTRU determining the amount (e.g., exact amount) of data to be transmitted to a path or multiple paths; the WTRU determining which path or paths to transmit data to first; the WTRU determining which path or paths to prioritize; or the WTRU determining what data (type of data) to transmit to a path or paths.

[0132] For example, the WTRU may determine which path or paths to transmit an RRC message to (e.g., when the SRB may be a split bearer). For example, the WTRU may determine which path or paths to transmit a control PDU for a given protocol layer (e.g., PDCP control PDU, MAC CE, etc.). For example, the WTRU may determine which path or paths to transmit a data PDU containing an additional QoS indication (e.g., PSDB, or associated with other XR related information).

[0133] A remote WTRU may determine a split bearer threshold for multipath with multiple indirect paths. A remote WTRU in multipath (e.g., a primary path via Uu, and a non-primary path via indirect/relay) with multiple indirect paths via different relays may determine to perform routing to an indirect path based on an amount of buffered data for the bearer and/or a number of active (e.g., non-DRX)/available (e.g., nonfailed) indirect paths as indicated by the relay WTRUs. [0134] A remote WTRU may be configured in multipath (e.g., with a primary path via Uu and multiple non-primary paths via indirect/relayfs)).

[0135] The remote WTRU may be configured with a split bearer that may send data over primary path or non-primary path.

[0136] The remote WTRU may be configured with (e.g., receive configuration information indicating) a different split bearer threshold (e.g., threshold for the amount of data that may be sent (e.g., transmitted) by the split bearer on the indirect/non-primary path) for each combination of number of available indirect paths. In examples, the remote WTRU may receive configuration information (e.g., from a network node) that indicates a first split bearer threshold (e.g., a first threshold amount of data allowed for transmitting data using a first indirect path) associated with a first number of available indirect paths and a second split bearer threshold (e.g., a second threshold amount of data allowed for transmitting data using a second indirect path) associated with a second number of available indirect paths.

[0137] The remote WTRU may be configured to receive/receive, from a relay WTRU (e.g., from each of the relay WTRUs), a unicast (e.g., a unicast) SL DRX configuration associated with (e.g., each associated with) an indirect path. The remote WTRU may determine whether an indirect path is an available indirect path based on the received unicast SL DRX configuration.

[0138] The remote WTRU may be configured to receive/receive, from relay WTRU(s), a failure notification (e.g., respective failure notification(s)) associated with an indirect path (e.g., if multiple failure notifications are received, each may be associated with a respective indirect path). The remote WTRU may determine whether an indirect path is an available indirect path based on the received failure notification. [0139] The remote WTRU may determine a number of available indirect paths. The number of indirect paths may be the first number of available indirect paths or the second number of available indirect paths. The remote WTRU may determine the number of available indirect paths based on at least one of: the number of indirect paths (e.g., the number of different relay WTRUs) configured for which there may be no pending path failure signaled by the relay WTRU (e.g., in a failure notification) (e.g., Uu-RLF, relay flow control, etc.) or a number of indirect paths for which there may be no SL DRX configuration (e.g., on the path).

[0140] The remote WTRU may select the split bearer threshold associated with the number of available indirect paths. In examples, the remote WTRU may select the first split bearer threshold on a condition that the number of available indirect paths is the first number of available indirect paths. The remote WTRU may select the second split bearer threshold on a condition that the number of available indirect paths is the second number of available indirect paths. The WTRU may determine a path based on whether an amount of data available for transmission exceeds the split bearer threshold (e.g., the selected first split threshold or the selected second split bearer threshold). The remote WTRU may send data using the determined path.

[0141] In examples, the WTRU may determine that the amount of data available for transmission at the split bearer is above the selected split bearer threshold (e.g., the first split bearer threshold or the second split bearer threshold). The remote WTRU may determine the transmission path is the direct/primary path or the indirect/non-primary path (e.g., determine to use the direct/primary path or the indirect/non-primary path) based on a determination that the amount of data available for transmission is above the selected split bearer threshold (e.g., the first split bearer threshold or the second split bearer threshold). The remote WTRU may send (e.g., transmit) data for the split bearer via the determined direct/primary path or the indirect/non-primary path.

[0142] In examples, the WTRU may determine that the amount of data available for transmission at the split bearer is equal to or below the selected split bearer threshold (e.g., the first split bearer threshold or the second split bearer threshold). The remote WTRU may determine the path is the direct/primary path (e.g., determine to use the direct/primary path) based on a determination that the amount of data available for transmission is equal to or below the selected split bearer threshold (e.g., the first split bearer threshold or the second split bearer threshold). The remote WTRU may send (e.g., transmit) data for the split bearer via the determined primary path.

[0143] A remote WTRU may determine splitting data between direct and indirect paths. Properties associated with the indirect path may be used to determine when to start using the indirect path for transmitting data that may be sent over a direct path and an indirect path. A remote WTRU may be configured with a routing rule (e.g., below PDCP layer) for routing data between an RLC entity (e.g., RLC entities) associated with direct path and an RLC entity (e.g., RLC entities) associated with an indirect path. A remote WTRU may be configured with rule(s) about whether/when to send data over the direct path(s) and whether/when to send data over the indirect path(s). Routing rules may be based on routing behavior. [0144] A WTRU may have a primary path, which may include a Uu RLC entity. A WTRU may further have a non-primary path, which may include a SL RLC entity. The RLC entity may be used for communication over multiple SL paths (e.g., each SL path associated with different set of relay WTRUs may be used to forward the packet from the source (e.g., a TX WTRU) to the destination (e.g., a network node, or an RX WTRU)). The WTRU may have multiple RLC entities. Each RLC entity may correspond to a different next hop relay.

[0145] Factors determining the routing rules between a primary path and a secondary path may include one or more of: the number of next hop relay WTRUs that the non-primary path may communicate over; the number of SL relay paths between the TX WTRU and the destination; the commonality between two or more SL paths associated with multihop; an activation/deactivation status associated with a next hop or a SL path; a DRX configuration; a presence of a failed SL-path; or flow control indications from a relay WTRU over a specific path.

[0146] The number of next hop relay WTRUs that the non-primary path may communicate over may be a factor used to determine the routing rules between a primary path and a secondary path. For example, the non-primary RLC entity may be associated with a number of distinct next hop nodes (e.g., relay WTRUs). The routing rules between the primary and non-primary path may be based on (e.g., depend) on the number of next hop nodes.

[0147] The number of SL relay paths between the TX WTRU and the destination may be a factor used to determine the routing rules between a primary path and a secondary path. For example, the non-primary RLC entity may transmit data over different multihop SL relay paths. Multiple SL paths may be possible with a single next hop relay/node (e.g., if the paths diverge at a later node, and/or converge into a single path at a later node). Routing rules may be based on (e.g., depend) on the number of SL relay paths.

[0148] The commonality between two or more SL paths associated with multihop may be a factor used to determine the routing rules between a primary path and a secondary path. For example, in multihop, if multiple SL relay paths share some common hops (e.g., the links between two relay WTRUs) the two SL relay paths may be considered to share some commonality. The routing rules may be based on (e.g., depend) on one or more of: the number of paths having commonality, the degree of commonality (e.g., how much of the SL paths are actually consisting of common links), etc.

[0149] An activation/deactivation status associated with a next hop or a SL path may be a factor used to determine the routing rules between a primary path and a secondary path. For example, a remote WTRU may autonomously activate/deactivate a path based on (pre)configured rules. The network may activate/deactivate a path for a remote WTRU (e.g., using RRC signaling or MAC CE). The remote WTRU may determine routing rules based on one or more of: the number of activated/deactivated SL paths, whether an activated/deactivated SL path contains a specific relay or not, the specific activate/deactivated paths, etc.

[0150] DRX configuration may be a factor used to determine the routing rules between a primary path and a secondary path. For example, a factor for routing rules may be if DRX is configured on the first hop of a SL path or not. For example, a factor for routing rules may be if DRX is configured on any hop associated with a SL path. For example, a factor for routing rules may be if any DRX parameter meets a specific criteria (e.g., the DRX on period may be larger than a threshold, the DRX periodicity may be smaller than a threshold, whether the DRX may be aligned between two different SL paths/hops, etc.). [0151] Presence of a failed SL-path may be a factor used to determine the routing rules between a primary path and a secondary path. For example, a factor for routing rules may be if SL RLF or Uu RLF was detected by the remote WTRU on a path. For example, a factor for routing rules may be if SL RLF or Uu RLF was indicated by the relay WTRU associated with a path to the remote WTRU.

[0152] Flow control indications from a relay WTRU over a specific path may be a factor used to determine the routing rules between a primary path and a secondary path. For example, a factor for routing rules may be any condition(s) associated with flow control and/or load indications on a relayed path, for example, condition(s) such as the load associated with a relay WTRU may be above a threshold.

[0153] A remote WTRU may be configured with multiple split bearer thresholds to be applied for an end- to-end bearer (e.g., a single end-to-end bearer may have multiple split bearer thresholds applied). The split bearer thresholds may be used for the remote WTRU to determine when to start transmitting data over the non-primary path. The remote WTRU may transmit data for a bearer to the primary path when the buffer status for the bearer is below the configured split bearer threshold. When the buffer status is above the configured split bearer threshold, the WTRU may transmit data to the primary path and the non-primary path.

[0154] For the same bearer, the WTRU may apply a first split bearer threshold under a first condition/factor (e.g., a condition/factor as described herein) and may apply a second split bearer threshold under a second condition/factor (e.g., a condition/factor as described herein).

[0155] The remote WTRU may determine the number of available indirect paths as the number of indirect paths that are configured. The number of available indirect paths may include the number of PC5- RRC connections the remote WTRU has to a relay WTRU (e.g., whereby the relay WTRU includes a possible path to the intended destination). The number of available indirect paths may include the number of PC5-RRC connections to relay WTRUs (e.g., whereby each PC5-RRC connection includes a possible path for the particular bearer for which the split threshold may be considered). The remote WTRU may apply a first split buffer threshold if the number of configured paths may be a first number or within a first range. The remote WTRU may apply a second first split bearer threshold if the number of configured paths may be a second number or within a second range.

[0156] In examples (e.g., applicable in multihop), the remote WTRU may determine the number of available indirect paths as the number of distinct paths (e.g., where a path comprises a sequence of PC5- RRC connections over multiple hops of relay WTRUs) the remote WTRU can send data to (e.g., that may be specific to a bearer). For example, a different path may be associated with a different sequence of L2 IDs, a different sequence of local WTRU IDs, path IDs, etc. There may be some overlap of relays within the paths. The remote WTRU may apply a first split bearer threshold if the number of configured paths may be a first number or within a first range. The remote WTRU may apply a second split bearer threshold if the number of configured paths may be a second number or within a second range. [0157] The remote WTRU may determine the number of available indirect paths as the number of configured indirect paths which are activated (e.g., via activation at the remote WTRU or via such activation by the network). The remote WTRU may apply a first split bearer threshold if the number of configured paths may be a first number or within a first range. The remote WTRU may apply a second split bearer threshold if the number of configured paths may be a second number or within a second range.

[0158] The remote WTRU may determine the number of available indirect paths as the number of configured indirect paths for which the SL may not be configured with DRX or for which the configured DRX has more than a threshold amount of inactive time. The remote WTRU may apply a first split bearer threshold if the number of non-DRX or non-inactive paths may be a first number or within a first range. The remote WTRU may apply a second split bearer threshold if the number of non-DRX or non-inactive paths may be a second number or within a second range.

[0159] The remote WTRU may determine the number of available indirect paths as the number of configured indirect paths for which flow control indications from the relay do not indicate (e.g., any need) to restrict transmission to that specific path or that have a flow control level below a specific threshold. Specifically, the remote WTRU may apply a first split bearer threshold if the number of relayed paths having flow control below a threshold is a first value or in a first range of values. The remote WTRU may apply a second split bearer threshold if the number of relayed paths having flow control below a threshold is a second value or a second range of values.

[0160] The remote WTRU may determine the split bearer threshold based on some function of the flow control level from SL replayed paths (e.g., each of the SL relayed paths). For example, a function may be the minimum, the maximum, or the average of the paths with value above the threshold, etc. The WTRU may be configured with a table that maps the flow control function of the indirect paths to the split bearer threshold used for routing between a direct and indirect path.

[0161] Conditions for using a split bearer threshold or another threshold (e.g., as specified by examples herein) may be applied without loss of generality to other factors mentioned herein on routing between direct and indirect paths (e.g., when the WTRU can/cannot use an indirect path, whether to transmit RRC on direct and/or indirect paths, etc.)

[0162] Feature(s) associated with split bearer threshold applied to individual indirect paths are provided herein. A remote WTRU in multipath may determine whether to route data to one or multiple indirect paths based on one or more of: a number of hops in each indirect path, a cell ID served by the relay in the indirect path, or the amount of data buffered for transmission.

[0163] A remote WTRU may be configured with a bearer having at least two indirect paths (e.g., via different relay(s)). The remote WTRU may be configured with an anchor path data threshold. The remote WTRU may determine that one of the indirect paths may be an anchor path for the bearer if: the WTRU is configured with a direct Uu path for the bearer and the cell serving the relay WTRU on that path is the same as the PCell on the direct Uu path; or the number of hops on one of the indirect paths is less than the number of hops on the other indirect paths.

[0164] If the remote WTRU determines that it has an anchor path for the bearer, the remote WTRU may send (e.g., transmit) available data (e.g., all available data) to the anchor path until the amount of buffered data is above a threshold and then send (e.g., transmit) data to the anchor path or the other path(s). If the remote WTRU determines that it does not have an anchor path for the bearer, the remote WTRU may send (e.g., transmit) data to the anchor path or the other indirect path(s).

[0165] Feature(s) associated with data splitting between direct and indirect paths are provided herein. A remote WTRU in multipath may determine the amount of data to route to each of the direct and indirect paths (e.g., based on the number of available paths and/or flow control indications from the relay WTRUs on each indirect path).

[0166] In examples one or more of the following may be performed (e.g., for data splitting between direct and indirect paths). A remote WTRU may be configured in multipath with a primary path via Uu and a nonprimary path via indirect/relay(s). The remote WTRU may be configured with a split bearer that may send data over a primary path or a non-primary path. The remote WTRU may be configured with a percentage split of data between a primary path and a non-primary path. The percentage split of data may be configured for a (e.g., for each) number of available indirect paths and/or congestion level(s) (e.g., indicated by each relay WTRU on the indirect paths). The remote WTRU may be configured with an evaluation window.

[0167] The remote WTRU may receive flow control message(s) from each of the relay WTRUs on the indirect paths. The flow control message(s) may (e.g., each) indicate one of a number of flow control levels. The remote WTRU may select the configured data split based on number of available paths and/or the flow control levels on each path (e.g., a table may map a number of paths and/or flow control indication on each path to a data split). The remote WTRU may send (e.g., transmit) data according to the selected data split for the split bearer to the primary path and the non-primary path (e.g., over the evaluation window). The remote WTRU may inform the network in case the data split cannot be met (e.g., CBR limitation).

[0168] A remote WTRU may determine data routing rules with multiple indirect paths. A remote WTRU in multipath (e.g., with multiple indirect paths) may determine the data routing rules based on factors related to the indirect path(s) of interest. The remote WTRU may have multiple indirect paths. The remote WTRU may (e.g., may also) have one or multiple direct paths. The remote WTRU may be a WTRU communicating (e.g., via direct and/or indirect) with the network. The indirect paths may include at least one WTRU to network relay. The WTRU may be a source WTRU communicating with a destination WTRU via multiple SL paths (e.g., direct, or indirect via at least one U2U relay). The routing rules may be associated with a single bearer. For example, the routing rules may include determining a split bearer operation for a bearer configured over the indirect paths. The routing rules may be associated with multiple bearers or data (e.g., all data) routed to the destination. For example, the rules may include determining the relative amount of data across bearers (e.g., all bearers) to be transmitted via paths (e.g., each path). [0169] Determining the amount of data routed to the different paths may include one or more of the following behaviors: the WTRU determining the conditions (e.g., in terms of buffered amount of data) in which data can (e.g., start to) be transmitted to a path or multiple paths or not; the WTRU determining the amount (e.g., exact amount) of data to be transmitted to a path or multiple paths; the WTRU determining which path or paths to transmit data to first; the WTRU determining which path or paths to prioritize; or the WTRU determining what data (e.g., type of data) to transmit to a path or paths.

[0170] For example, the WTRU may determine which path or paths to transmit an RRC message to (e.g., if the SRB is a split bearer). For example, the WTRU may determine which path or paths to transmit a control PDU for a given protocol layer (e.g. PDCP control PDU, MAC CE, etc.). For example, the WTRU may determine which path or paths to transmit data PDU including a QoS indication, such as an additional QoS indication (e.g., PSDB, or associated with other XR related information).

[0171] A remote WTRU may determine the data routing rules associated with transmitting data to multiple indirect paths. The data routing rules may be based on one or more of the following factors: the number of hops associated with one or more of the indirect paths; the cell ID associated with the relay(s) on one or more of the indirect paths (e.g., in relation to the cell ID associated with the direct path); the amount of data buffered at the WTRU (e.g., possibly associated with a specific bearer); the type of data (e.g., in terms of bearer type and/or additional information provided with a packet data unit (PDU)); the measurements of channel quality (e.g., reference signal received power (RSRP)) or congestion (e.g. CBR) on the one or more paths or of the sidelink; information provided by the relay WTRU(s) on the one or more paths (e.g., measurements, failure indication, notification, buffer occupancy, flow control); the DRX configuration on the paths; the carriers (e.g., number, nature, relationship between different paths) over which the WTRU may be communicating over a specific path; or the number of SL paths.

[0172] Data routing rules may be based on a number of hops associated with one or more of the indirect paths. A remote WTRU may determine a number of hops associated with each of the indirect hops based on an indication from the relay WTRU itself and/or upper layer configuration. The remote WTRU may determine routing rules for data that depend on the number of hops associated with one or more of the indirect paths. The remote WTRU may determine that one of the indirect paths is considered as an anchor path (e.g., data transmission for a bearer may be performed first on that path and may be performed on other paths after a condition may be met) if that specific indirect path has a number of hops that may be shorter than other path(s) (e.g., any other path). The remote WTRU may determine that one of the paths may be considered an anchor path if that path is a direct path (e.g., a direct SL path). The remote WTRU may determine the amount or ratio of data to be routed to a path based on the number of hops associated with the path. Specifically, the WTRU may be (pre-)configured with a ratio of data, possibly for a given bearer, to be routed to a path for each number of hops associated with the path.

[0173] Data routing rules may be based on the cell ID associated with the relay(s) on one or more of the indirect paths (e.g., in relation to the cell ID associated with the direct path). A remote WTRU may determine routing rules that depend on the cell ID serving one of the relays (e.g., in relation to other relays, in relation to a direct path) the remote WTRU may have with the network or the destination WTRU. For example, a remote WTRU may determine that an indirect path may be considered as the anchor path (e.g., for any bearer that may be configured on indirect paths only) if the WTRU has a direct path to a cell that is the same cell as the cell serving the relay on the indirect path. For example, a remote WTRU may determine that an anchor path should be determined (e.g., by the remote WTRU) if there is at least one indirect path having a relay controlled by a cell that is the same as the cell on the direct path. For example, a remote WTRU may determine a different routing rule (e.g., a different split bearer threshold, a different ratio of data to be sent to the path) depending on if the path and/or bearer is associated to a relay having a cell that has the same cell ID as the path associated with the anchor path, or the cell on the direct path. For example, a remote WTRU may determine an anchor path using examples described herein. The remote WTRU may transmit data (e.g., for a specific bearer) to paths (e.g., all paths) having a relay connected to the same cell as the anchor path (e.g., regardless of the buffer status at the WTRU). The remote WTRU may transmit data to paths where the cell may not be the same as the anchor path if the amount of data on the path may be larger than a threshold.

[0174] Data routing rules may be based on the amount of data buffered at the WTRU (e.g., associated with a specific bearer).The routing rules/decisions may (e.g., may further) depend on the amount of data buffered at the WTRU (e.g., in relation to a buffer threshold).

[0175] Data routing rules may be based on the type of data (e.g., in terms of bearer type or additional information provided with a PDU). The WTRU may use a first routing rule for SRB and a second routing rule for DRB. The WTRU may be configured with a path or paths which allow transmission of data for which the PSDB satisfies some condition (e.g. PSDB is less than a threshold) (e.g., in conjunction with another condition derived from another factor).

[0176] Data routing rules may be based on the measurements of channel quality (e.g., RSRP) or congestion (e.g. CBR) on the one or more paths, or of the sidelink. The routing rules/decisions may (e.g., may further) depend on the measured sidelink RSRP on a particular path, the relative sidelink RSRP between paths, etc. [0177] Data routing rules may be based on information provided by the relay WTRU(s) on one or more paths (e.g., measurements, failure indication, notification, buffer occupancy, flow control, etc.). Relay WTRU(s) may provide this information about subsequent hops. The WTRU may determine the anchor path as the path having the shortest buffer occupancy, minimum flow control restrictions, and/or best average measurements (e.g., for multipath) (e.g., as indicated by the relay WTRU of that path). The WTRU may change the anchor path from a first path to a second path if the WTRU receives a notification message (e.g. HO, Uu RLF, next hop radio link failure (RLF), etc.) associated with the first path.

[0178] Data routing rules may be based on the DRX configuration on the paths. The WTRU may determine the anchor path based on if DRX is configured on that path or not. The WTRU may select a path as an anchor path if DRX is not configured on that path. The WTRU may determine the ratio of data to be transmitted on a path (e.g., for a specific bearer) based on if DRX is configured on that path or not. For example, the WTRU may be configured with a formula for determining the ratio of data to send on a path that depends on the total number of paths and on if DRX is configured on a path or not. The WTRU may determine the ratio of data to be transmitted on a path based on the DRX configuration. The WTRU may be configured with a formula for the ratio of data to transmit on a path that depends on a DRX configuration parameter (e.g., DRX cycle, on duration, etc.).

[0179] Data routing rules may be based on the carriers (e.g., number, nature, relationship between different paths) over which the WTRU may be communicating over a specific path. The WTRU may determine the anchor path based on a relationship between the carriers configured for that path and/or other paths. For example, the WTRU may determine the anchor path to be a path which that is configured with a carrier that is to be used for transmission to (e.g., all) the other paths or the largest number of other paths.

[0180] Data routing rules may be based on the number of SL paths. For example, rules for a determination of the ratio of data to be transmitted to a given path may depend on the number of paths. For example, rules herein (e.g., for a determination of the anchor based on the number of hops) may further be defined by the number of paths associated with a number of hops.

[0181] Feature(s) associated with data splitting between direct and indirect paths are provided herein. A remote WTRU in multipath may determine the amount of data to route to each of the direct and indirect paths based on the number of available paths and/or flow control indications from the relay WTRUs on each indirect path.

[0182] A remote WTRU may be configured in multipath with a primary path via Uu and a non-primary path via indirectZrelay(s). The remote WTRU may be configured with a split bearer that may send data over a primary path or a non-primary path. The remote WTRU may be configured with a percentage split of data between a primary path and a non-primary path. The percentage split of data may be configured for a (e.g., for each) number of available indirect paths and/or congestion level(s) (e.g., indicated by each relay WTRU on the indirect paths). The remote WTRU may be configured with an evaluation window.

[0183] The remote WTRU may receive flow control message(s) from each of the relay WTRUs on the indirect paths. The flow control message(s) may (e.g., each) indicate one of a number of flow control levels. The remote WTRU may select the configured data split based on number of available paths and/or the flow control levels on each path (e.g., a table may map a number of paths and/or flow control indication on each path to a data split). The remote WTRU may send (e.g., transmit) data according to the selected data split for the split bearer to the primary path and the non-primary path (e.g., over the evaluation window). The remote WTRU may inform the network in case the data split cannot be met (e.g., CBR limitation).

[0184] A remote WTRU may measure the proportion/percentage of data sent via multiple paths. A remote WTRU may ensure a configured/desired proportion/percentage of data is sent over each of the direct and indirect paths (e.g., a proportion of data routed to each of the indirect paths in the case of multiple indirect paths). A remote WTRU may ensure a proportion on average or may ensure a proportion is met over a sampling window. Over a configured window of time, the WTRU may ensure that a (preconfigured proportion of a number of packets transmitted are over the direct path and the remainder are transmitted over the indirect path.

[0185] A remote WTRU may determine the proportion/percentage in the presence of multiple indirect paths. A remote WTRU may determine a ratio of data routed to each of the direct or indirect paths. A remote WTRU may determine the percentage of data (e.g., to be routed) over the direct and indirect path based on condition(s) associated with the indirect paths (e.g., as described herein). A remote WTRU may be configured with multiple direct/indirect data ratios to be applied for a single end to end bearer. A remote WTRU may be configured with direct/indirect data ratio(s) over multiple bearers (e.g., all bearers). The remote WTRU may determine the number of available indirect paths as the number of indirect paths which are configured. The remote WTRU may apply a first direct/indirect data ratio if the number of configured paths is a first number or within a first range. The remote WTRU may apply a second direct/indirect data ratio if the number of configured paths is a second number or within a second range.

[0186] The remote WTRU (e.g., in multihop) may determine the number of available indirect paths as the number of distinct paths (e.g., where a path consists of a sequence of PC5-RRC connections over multiple hops of relay WTRUs) the remote WTRU may send data to (e.g., specific to a bearer). For example, a different path may be associated with a different sequence of L2 IDs, a different sequence of local WTRU IDs, or path IDs, etc. (e.g., with some overlap of relays within the paths). The remote WTRU may apply a first direct/indirect data ratio if the number of configured paths is a first number or within a first range. The remote WTRU may apply a second direct/indirect data ratio if the number of configured paths is a second number or within a second range. [0187] The remote WTRU may determine the number of available indirect paths as the number of configured indirect paths which are activated (e.g., via activation at the remote WTRU or via activation by the network). The remote WTRU may apply a first direct/indirect data ratio if the number of configured paths is a first number or within a first range. The remote WTRU may apply a second direct/indirect data ratio if the number of configured paths is a second number or within a second range.

[0188] The remote WTRU may determine the number of available indirect paths as the number of configured indirect paths for which the SL may not be configured with DRX or for which the configured DRX has more than a threshold amount of inactive time. The remote WTRU may apply a first direct/indirect data ratio if the number of non-DRX or non-inactive paths is a first number or within a first range. The remote WTRU may apply a second direct/indirect data ratio if the number of non-DRX or non-inactive paths is a second number or within a second range.

[0189] The remote WTRU may determine the number of available indirect paths as the number of configured indirect paths for which flow control indications from the relay do not indicate to (e.g., any need to) restrict transmission to that specific path or that have a flow control level below a specific threshold. The remote WTRU may apply a first direct/indirect data ratio if the number of relayed paths having flow control below a threshold is a first value or in a first range of values. The remote WTRU may apply a second direct/indirect data ratio if the number of relayed paths having flow control below a threshold is a second value or a second range of values.

[0190] The remote WTRU may determine the direct/indirect data ratio based on a function of the flow control level from the SL relayed path(s) (e.g., each of the SL relayed paths). For example, the function may be the minimum, the maximum, or the average of the paths with a value above the threshold, etc. The WTRU may be configured with a table that maps the flow control function of the indirect paths to the direct/indirect data ratio used for routing between direct and indirect paths.

[0191] A remote WTRU may report failure to meet the desired/configured proportion/percentage. A remote WTRU may fail to meet the configured proportion due to other configured limitations (e.g., a maximum number of resources used on the indirect path, RLF status on the indirect path, flow control on the indirect path, etc.). The remote WTRU may report the failure to the network (e.g., after a hysteresis, for example, if the failure persists for a period of time). The WTRU may report the statistics and/or the reason why the desired ratio may not be met to the network.

[0192] Feature(s) associated with activation of an indirect path are provided herein. A remote WTRU may enable/disable SL-DRX on a link with a relay WTRU based on the buffer status and/or the flow control indications from the relay(s) (e.g., each of the relays).

[0193] A remote WTRU may be configured with at least two indirect paths (e.g., via different relays). The remote WTRU may be configured with a percentage data split over the multiple indirect paths. The remote WTRU may be configured with a percentage data split for a combination (e.g., each combination) of flow control levels that may be indicated by the relay WTRU(s)). The remote WTRU may be configured with a buffer threshold for SL-DRX enable/disable.

[0194] The remote WTRU may receive flow control level indications from the relay WTRUs associated with each of the indirect paths. The remote WTRU may determine (e.g., based on each of the received flow control level indications) the corresponding percentage data split for each of the indirect paths. The remote WTRU may (e.g., over a pre-configured window) ensure that the percentage of data routed to each path matches the percentage data split.

[0195] The remote WTRU may determine to enable/disable DRX (e.g., based on the actual buffer status being above/below the configured threshold). When the buffer status is above a threshold for at least a period of X, and DRX is enabled, the remote WTRU may send (e.g., transmit) a disable DRX indication to a relay WTRU. When the buffer status is below a threshold for at least a period of Y, and DRX is disabled, the remote WTRU may send (e.g., transmit) an enable DRX indication to a relay WTRU.

[0196] The remote WTRU may send (e.g., transmit) DRX enable/disable to each of the relays based on the determination. The remote WTRU may send (e.g., transmit) data buffered for each indirect path to the associated relay.

[0197] A remote WTRU may activate/deactivate an indirect path. A remote WTRU may activate/deactivate an indirect path if configured with indirect path(s) (e.g., multiple indirect paths) via different relays. Activation/deactivation may include one or more of: a change of whether data may be transmitted via a particular SL path; a change of whether SL DRX may be configured/operated on a particular SL path; a change of the SL DRX configuration on a particular path; or a change in a PC5 configuration aspect on a particular path.

[0198] Activation/deactivation may include a change of whether data (e.g., data associated with a specific bearer) may be transmitted via that particular SL path. In examples, a WTRU may maintain a PC5- RRC connection with a relay WTRU but may not transmit data intended to the network via a deactivated SL path (e.g., until such SL path may be activated). Activation/deactivation may include a change of whether SL DRX may be configured/operated on a particular SL path. Activation/deactivation may include a change of the SL DRX configuration on a particular path. In examples, an activated SL path may be associated with a first SL DRX configuration and a deactivated path may be associated with a second SL DRX configuration. Activation/deactivation may include a change in a PC5 configuration aspect on a particular path, such as a LCH configuration, MAC configuration, PHY configuration, etc.

[0199] Activation/deactivation of a SL path may involve sending (e.g., transmission of) a PC5-RRC message to the relay WTRU (e.g., to change the DRX configuration) or to a MAC CE. Activation/deactivation of a SL path may include not routing multipath data (e.g., data associated with a bearer) to that SL path via the relay (e.g., the relay being deactivated).

[0200] Feature(s) associated with conditions/triggers for activation/deactivation of a direct path are provided herein. A remote WTRU may activate/deactivate a direct path based on condition(s) related to one more of the following: a bearer QoS; a number of hops; flow control; arrival of data; SL measurements; sensing results; measured/experienced latency; a message received from a relay WTRU; path redundancy; network signaling; a measured time; or Uu measurements (e.g., Uu RSRP).

[0201] A remote WTRU may activate/deactivate a direct path based on condition(s) related to bearer QoS. For example, activation/deactivation may be allowed by the WTRU, possibly based on other conditions, if the WTRU may be configured with a bearer(s) allowing it. For example, activation/deactivation may be allowed by the WTRU if (e.g., only if) data of a configured bearer(s) are available for transmission. For example, activation/deactivation may depend on properties (e.g., maximum bit rate) of a bearer.

[0202] A remote WTRU may activate/deactivate a direct path based on condition(s) related to number of hops. For example, activation/deactivation of a SL path may occur if the number of hops associated with the path is above/below a threshold. For example, activation/deactivation of a SL path may occur if the number of hops associated with another path is above/below a threshold.

[0203] A remote WTRU may activate/deactivate a direct path based on condition(s) related to flow control. For example, activation/deactivation of a SL path may occur if the flow control level of a path is below/above a threshold. For example, activation/deactivation of a SL path may occur if the flow control level(s) (possibly combined) of other SL paths reaches a threshold.

[0204] A remote WTRU may activate/deactivate a direct path based on condition(s) related to arrival of data. For example, activation/deactivation of a SL path may occur if the WTRU receives an XR PDU set, possibly with certain PSDB. For example, activation/deactivation of an SL path may occur if the WTRU receives a PDU burst.

[0205] A remote WTRU may activate/deactivate a direct path based on condition(s) related to SL measurements (e.g., CBR, CR, RSRP, CQI, etc.). For example, activation/deactivation may occur/be allowed if the WTRU detects a condition associated with any of the SL measurements associated with that SL path or other SL paths, such as CBR, CR, RSRP, CQI, etc.

[0206] A remote WTRU may activate/deactivate a direct path based on condition(s) related to sensing results. For example, activation/deactivation may occur based on some sensing results, such as detection of pre-emption, some condition on the number of available resources, etc.

[0207] A remote WTRU may activate/deactivate a direct path based on condition(s) related to measured/experienced latency. For example, a remote WTRU may determine or receive (e.g. from the network or the peer WTRU) a measured/experienced latency associated with a packet/PDU, and may activate/deactivate a SL path in response.

[0208] A remote WTRU may activate/deactivate a direct path based on condition(s) related to a message received from a relay WTRU. For example, a remote WTRU may deactivate, possibly for a period of time, a SL path following reception of a message received from a relay WTRU on that path or another path, such as a HO, RLF indication, RRC failure, etc.

[0209] A remote WTRU may activate/deactivate a direct path based on condition(s) related to path redundancy. For example, a remote WTRU may activate/deactivate a path based on the redundancy associated with a path compared to another path. For example, for the case of multihop, the remote WTRU may determine the number of common links (i.e., relays) over the two paths to determine a measure of the path redundancy.

[0210] A remote WTRU may activate/deactivate a direct path based on condition(s) related to network signaling. For example, the network may explicitly trigger activation/deactivation at a remote WTRU. For example, the network may configure one or more of the above conditions for which the remote WTRU performs activation/deactivation of a path.

[0211] A remote WTRU may activate/deactivate a direct path based on condition(s) related to measured time. For example, activation/deactivation may apply on a SL path for a period of time, possibly while a condition may be met. For example, activation/deactivation may be initiated when a condition is met for a period of time, or after a period of time after a condition is detected.

[0212] A remote WTRU may be configured with a buffer threshold (e.g., for one DRB or all DRBs, which may control DRX enable/disable on one or more SL indirect paths). The WTRU may be configured with a buffer threshold applicable for enabli ng/disabli ng one or more particular SL paths. If the buffer status at the remote WTRU is above a threshold (e.g., for a (pre)configured amount of time), the remote WTRU may disable SL DRX on one or more of the SL paths. If the buffer status at the remote WTRU is below a threshold (e.g., for a (pre)configured amount of time), the remote WTRU may enable SL DRX on one or more SL paths. A remote WTRU may be configured with the number of SL paths, proportion of SL paths, and/or maximum/minimum number of SL paths to activate/deactivate for a respective value of buffer status at the remote WTRU.

[0213] A device, such as a wireless transmit/receive unit (WTRU), may include a processor configured to perform one or more actions. The device may determine a number of available indirect paths. The device may select a split bearer threshold based on the determined number of available indirect paths. The device may determine whether an amount of data available for transmission exceeds the selected split bearer threshold. The device may determine a path to use based on the determination of whether the amount of data available for transmission exceeds the selected split bearer threshold. The device may send data using the determined path.

[0214] The device may determine whether an indirect path is an available indirect path based on at least one of a SL DRX status and/or a path failure status associated with the indirect path. The device may receive a failure notification associated with a relay WTRU. The device may determine whether an indirect path is an available indirect path based on the received failure notification.

[0215] In examples, the determined path may be a primary path if the amount of data available for transmission does not exceed the split bearer threshold. In examples, if the amount of data available for transmission exceeds the split bearer threshold, an indirect path may be available for use as the determined path.

[0216] Although features and elements described above 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 other features and elements.

[0217] Although the implementations described herein may consider 3GPP specific protocols, it is understood that the implementations described herein are not restricted to this scenario and may be applicable to other wireless systems. For example, although the solutions described herein consider LTE, LTE-A, New Radio (NR) or 5G specific protocols, it is understood that the solutions described herein are not restricted to this scenario and are applicable to other wireless systems as well.

[0218] 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 over wired and/or wireless connections) and/or computer-readable storage media. Examples of computer- readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as, but not limited to, internal hard disks and removable disks, magneto-optical media, and/or optical media such as compact disc (CD)-ROM disks, and/or digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, terminal, base station, RNC, and/or any host computer.

Claims

CLAIMS What is Claimed:

1 . A wireless transmit/receive unit (WTRU), the WTRU comprising: a processor configured to: receive configuration information, wherein the configuration information indicates a first split bearer threshold associated with a first number of available indirect paths and a second split bearer threshold associated with a second number of available indirect paths; determine a number of available indirect paths, wherein the number of available indirect paths is the first number of available indirect paths or the second number of available indirect paths; on a condition that the number of available indirect paths is the first number of available indirect paths, select the first split bearer threshold; on a condition that the number of available indirect paths is the second number of available indirect paths, select the second split bearer threshold; determine a path based on whether an amount of data available for transmission exceeds the selected first split bearer threshold or the selected second split bearer threshold; and send data using the determined path.

2. The WTRU of claim 1 , wherein the processor is further configured to: determine that the amount of data available for transmission is above the first split bearer threshold or the second split bearer threshold; and determine to use an indirect path based on a determination that the amount of data available for transmission is above the first split bearer threshold or the second split bearer threshold.

3. The WTRU of claim 1 , wherein the processor is further configured to: determine that the amount of data available for transmission is equal to or below the first split bearer threshold or the second split bearer threshold; and determine to use a direct path based on a determination that the amount of data available for transmission is equal to or below the first split bearer threshold or the second split bearer threshold.

4. The WTRU of any of claims 1 to 3, wherein the number of available indirect paths is determined based on at least one of: a number of indirect paths for which there is no pending path failure status signaled; or a number of indirect paths for which there is no unicast sidelink discontinuous reception (SL DRX) configuration.

5. The WTRU of any of claims 1 to 4, wherein the processor is further configured to: receive, from a relay WTRU, a failure notification associated with an indirect path; and determine whether the indirect path is an available indirect path based on the received failure notification.

6. The WTRU of any of claims 1 to 5, wherein the processor is further configured to: receive, from a relay WTRU, a unicast SL DRX configuration associated with an indirect path; and determine whether the indirect path is an available indirect path based on the received unicast SL DRX configuration.

7. The WTRU of any of claims 1 to 6, wherein the first split bearer threshold is a first threshold amount of data allowed for transmitting the data using an indirect path of the first number of available indirect paths and the second split bearer threshold is a second threshold amount of data allowed for transmitting the data using an indirect path of the second number of available indirect paths.

8. A method associated with a wireless transmit/receive unit (WTRU), the method comprising: receiving configuration information, wherein the configuration information indicates a first split bearer threshold associated with a first number of available indirect paths and a second split bearer threshold associated with a second number of available indirect paths; determining a number of available indirect paths, wherein the number of available indirect paths is the first number of available indirect paths or the second number of available indirect paths; on a condition that the number of available indirect paths is the first number of available indirect paths, selecting the first split bearer threshold; on a condition that the number of available indirect paths is the second number of available indirect paths, selecting the second split bearer threshold; determining a path based on whether an amount of data available for transmission exceeds the selected first split bearer threshold or the selected second split bearer threshold; and sending data using the determined path.

9. The method of claim 8, further comprising: determining that the amount of data available for transmission is above the first split bearer threshold or the second split bearer threshold; and determining to use an indirect path based on a determination that the amount of data available for transmission is above the first split bearer threshold or the second split bearer threshold.

10. The method of claim 8, further comprising: determining that the amount of data available for transmission is equal to or below the first split bearer threshold or the second split bearer threshold; and determining to use a direct path based on a determination that the amount of data available for transmission is equal to or below the first split bearer threshold or the second split bearer threshold.

11 . The method of any of claims 8 to 10, wherein the number of available indirect paths is determined based on at least one of: a number of indirect paths for which there is no pending path failure status signaled; or a number of indirect paths for which there is no unicast sidelink discontinuous reception (SL DRX) configuration.

12. The method of any of claims 8 to 11 , further comprising: receiving, from a relay WTRU, a failure notification associated with an indirect path; and determining whether the indirect path is an available indirect path based on the received failure notification.

13. The method of any of claims 8 to 12, further comprising: receiving, from a relay WTRU, a unicast SL DRX configuration associated with an indirect path; and determining whether the indirect path is an available indirect path based on the received unicast SL DRX configuration.

14. The method of any of claims 8 to 13, wherein the first split bearer threshold is a first threshold amount of data allowed for transmitting the data using an indirect path of the first number of available indirect paths and the second split bearer threshold is a second threshold amount of data allowed for transmitting the data using an indirect path of the second number of available indirect paths.

15. A wireless transmit/receive unit (WTRU), comprising: a processor configured to: receive an indication of a plurality of indirect paths, wherein each of the plurality of indirect paths is associated with a respective relay WTRU; determine that an indirect path of the plurality of indirect paths is an anchor path; and send data using the anchor path if an amount of data is below an anchor path data threshold.

16. A method associated with a wireless transmit/receive unit (WTRU), the method comprising: receiving an indication of a plurality of indirect paths, wherein each of the plurality of indirect paths is associated with a respective relay WTRU; determining that an indirect path of the plurality of indirect paths is an anchor path; and sending data using the anchor path if an amount of data is below an anchor path data threshold.

17. A wireless transmit/receive unit (WTRU), comprising: a processor configured to: receive an indication of a primary path and a number of available indirect paths; select a data split based on the number of available indirect paths and a respective flow control level associated with each of the number of available indirect paths; and send data using the primary path and the number of available indirect paths, wherein the data is sent based on the data split.

18. A method associated with a wireless transmit/receive unit (WTRU), the method comprising: receiving an indication of a primary path and a number of available indirect paths; selecting a data split based on the number of available indirect paths and a respective flow control level associated with each of the number of available indirect paths; and sending data using the primary path and the number of available indirect paths, wherein the data is sent based on the data split.

19. A wireless transmit/receive unit (WTRU) comprising: a processor configured to: receive an indication of a first indirect path associated with a first relay, wherein DRX associated with the first relay is enabled; determine whether to disable DRX for the first relay, wherein the determination of whether to disable DRX is based on a comparison of a buffer status associated with the first indirect path to a buffer threshold; and send a DRX indication to the first relay using the first indirect path, wherein the DRX indication indicates whether to disable DRX associated with the first relay.

20. A method associated with a wireless transmit/receive unit (WTRU), the method comprising: receiving an indication of a first indirect path associated with a first relay, wherein DRX associated with the first relay is enabled; determining whether to disable DRX for the first relay, wherein the determination of whether to disable DRX is based on a comparison of a buffer status associated with the first indirect path to a buffer threshold; and sending a DRX indication to the first relay using the first indirect path, wherein the DRX indication indicates whether to disable DRX associated with the first relay.