Segmented bearer threshold determination for multiple paths with multiple indirect paths

Abstract

Systems, methods, devices, and tools related to segmentation bearer threshold determination are described herein. 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., a first number of available indirect paths or a second number of available indirect paths). The first or second partition bearer threshold may be selected under the condition that the number of available indirect paths is the first number or the second number of available indirect paths. A path may be determined based on whether the amount of data available for transmission exceeds the selected first split bearer threshold or the second split bearer threshold. Data may be transmitted using the determined path.

Description

[0001] Cross-references to related applications This application claims the benefit of Provisional U.S. Patent Application No. 63 / 526,850, filed July 14, 2023, the entire contents of which are incorporated herein by reference. Background Technology

[0002] Mobile communication using wireless communication continues to evolve. The fifth generation can be called 5G. The previous generation (traditional) mobile communication can be, for example, the fourth generation (4G) Long Term Evolution (LTE). Summary of the Invention

[0003] This paper describes systems, methods, devices, and instruments related to segmentation bearer threshold determination (e.g., for multipath with multiple indirect paths).

[0004] A wireless transmit / receive unit (WTRU) (e.g., a remote WTRU) can be configured in a multipath (e.g., having a primary path via Uu and multiple non-primary paths via (one or more) indirect / relay paths). The remote WTRU can be configured with a segmented bearer threshold, which can be used to transmit data via either the primary or non-primary path. The remote WTRU can be configured with different segmented bearer thresholds for each combination of the multiple available indirect paths (e.g., a threshold for the amount of data that can be transmitted (e.g., sent) on the indirect / non-primary paths by the segmented bearer) (e.g., the remote WTRU can be configured to receive configuration information indicating the different segmented bearer thresholds).

[0005] A remote WTRU can receive configuration information indicating a first segmented bearer threshold (e.g., a first threshold amount of data allowed to transmit data using indirect paths) associated with a first number of available indirect paths (e.g., the first segmented bearer threshold is applicable if the number of available paths is equal to X) and a second segmented bearer threshold (e.g., a second threshold amount of data allowed to transmit data using indirect paths) associated with a second number of available indirect paths (e.g., the second segmented bearer threshold is applicable if the number of available paths is equal to Y, etc., where X and Y can be corresponding values ​​or ranges of values).

[0006] In the example, the remote WTRU can be configured to receive unicast (e.g., corresponding unicast) side-link discontinuous reception (SL DRX) configurations associated with indirect paths (e.g., each associated with an indirect path) from relay WTRUs (e.g., each associated with an indirect path). The remote WTRU can determine whether the indirect path is an available indirect path based on the received unicast SL DRX configurations. In the example, the remote WTRU can be configured to receive failure notifications (e.g., one or more corresponding failure notifications) associated with indirect paths (e.g., each associated with an indirect path) from relay WTRUs (e.g., each associated with an indirect path). The remote WTRU can determine whether the indirect path is an available indirect path based on the received failure notifications.

[0007] The remote WTRU can determine the number of available indirect paths. In the example, the determined number of indirect paths can be a first number of available indirect paths or a second number of available indirect paths. The remote WTRU can determine the number of available indirect paths based on at least one of the following: the number of indirect paths configured to not have pending path failures signaled by a relay WTRU (e.g., in failure notification) (e.g., Uu-RLF, relay flow control, etc.) (e.g., the number of different relay WTRUs); or the number of indirect paths configured to not exist.

[0008] The remote WTRU can select a split bearer threshold associated with the determined number of available indirect paths. In the example, the remote WTRU can select a first split bearer threshold if the number of available indirect paths is a first number. The remote WTRU can select a second split bearer threshold if the number of available indirect paths is a second number. The WTRU can determine a path based on whether the amount of data available for transmission meets (e.g., exceeds) a split bearer threshold (e.g., the selected first split bearer threshold or the selected second split bearer threshold). The remote WTRU can use the determined path to send data.

[0009] In the example, the WTRU can determine that the amount of data available for transmission at the segmented bearer is higher than a selected segmented bearer threshold (e.g., a first segmented bearer threshold or a second segmented bearer threshold). Based on this determination, the remote WTRU can determine whether the path is a direct / primary path or an indirect / non-primary path (e.g., determining whether to use a direct / primary path or an indirect / non-primary path). The remote WTRU can then use the segmented bearer to send (e.g., transmit) data via the determined direct / primary path or indirect / non-primary path.

[0010] In the example, the WTRU can determine that the amount of data available for transmission at the segmented bearer is equal to or less than a selected segmented bearer threshold (e.g., a first segmented bearer threshold or a second segmented bearer threshold). Based on this determination that the amount of data available for transmission is equal to or less than the selected segmented bearer threshold (e.g., a first segmented bearer threshold or a second segmented bearer threshold), the remote WTRU can determine that the path is a direct / primary path (e.g., determine to use a direct / primary path). The remote WTRU can then transmit (e.g., broadcast) the data for the segmented bearer via the determined primary path (e.g., only via the primary path). Attached Figure Description

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

[0012] Figure 1B The illustration shows a method according to one embodiment. Figure 1A The diagram shows a system diagram of an example wireless transmit / receive unit (WTRU) used in a communication system.

[0013] Figure 1C The illustration shows a method according to one embodiment. Figure 1A The diagram illustrates a system diagram of an example radio access network (RAN) and an example core network (CN) used in the communication system.

[0014] Figure 1D The illustration shows a method according to one embodiment. Figure 1A The illustrated system diagram shows yet another example RAN and yet another example CN used in the communication system.

[0015] Figure 2 The illustration shows an example of a remote WTRU outside of coverage.

[0016] Figure 3A The diagram illustrates an example user plane protocol stack for L2 WTRU to network relay.

[0017] Figure 3B The diagram illustrates an example control plane protocol stack for L2 WTRU to network relay.

[0018] Figure 4 The illustration shows an example of a remote WTRU within the coverage area connected via direct and indirect paths. Detailed Implementation

[0019] Figure 1AThis is a schematic diagram illustrating an example communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multi-access system that provides content such as voice, data, video, messages, and broadcasts to multiple wireless users. The communication system 100 enables multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail Unique Word DFT Spread Spectrum OFDM (ZT UWDTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0020] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, Public Switched Telephone Network (PSTN) 108, Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain environments), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

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

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

[0023] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116. Air interface 116 can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Any suitable radio access technology (RAT) can be used to establish air interface 116.

[0024] More specifically, as described above, the communication system 100 can be a multi-access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 / 113 can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish air interfaces 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 one embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as evolved UMTS terrestrial radio access (E-UTRA), which may use Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro) to establish air interface 116.

[0026] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can establish an air interface 116 using a new radio (NR).

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

[0028] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0029] For example, Figure 1A Base station 114b can be a wireless router, home node B, home eNodeB, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area, such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for drone use), roads, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b can be directly connected to the Internet 110. Therefore, base station 114b may not need to access the Internet 110 via CN 106 / 115.

[0030] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. Data can have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, and / or perform advanced security functions such as user authentication. Although in Figure 1AAlthough not shown, it should be understood that RAN104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs that use the same RAT as or a different RAT than RAN 104 / 113. For example, in addition to being connected to RAN 104 / 113, which may utilize NR radio technology, CN 106 / 115 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0031] CN 106 / 115 can also serve as a gateway for WTRU 102a, 102b, 102c, 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 / 113 or a different RAT.

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

[0033] Figure 1B This is a system diagram illustrating example WTRU 102. (Example:) Figure 1B As shown, among other things, WTRU 102 may include, in particular, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and / or other peripheral devices 138, etc. It should be understood that WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

[0034] Processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. Processor 118 may perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, which may be coupled to transmitting / receiving element 122. Although Figure 1B The processor 118 and transceiver 120 are depicted as separate components, but it should be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0035] Transmitting / receiving element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) over air interface 116. For example, in one embodiment, transmitting / receiving element 122 can be an antenna configured to transmit and / or receive RF signals. In one embodiment, transmitting / receiving element 122 can be, for example, a transmitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In yet another embodiment, transmitting / receiving element 122 can be configured to transmit and / or receive both RF and optical signals. It should be understood that transmitting / receiving element 122 can be configured to transmit and / or receive any combination of wireless signals.

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

[0037] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 can have multi-mode capability. Therefore, for example, transceiver 120 may include multiple transceivers to enable WTRU 102 to communicate via multiple RATs, such as, for example, NR and IEEE 802.11.

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

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

[0040] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to, or instead of, information from the GPS chipset 136, the WTRU 102 may receive location information on the air interface 116 from base stations (e.g., base stations 114a, 114b) and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that the WTRU 102 may acquire location information using any suitable location determination method while remaining consistent with the embodiments.

[0041] The processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or videos), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral devices 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, attitude sensors, biosensors, and / or humidity sensors.

[0042] WTRU 102 may include a full-duplex radio for which the transmission and reception of some or all signals (e.g., signals associated with specific subframes for 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 hardware (e.g., chokes) or via signal processing by a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, WTRU 102 may include a half-duplex radio for which the transmission and reception of some or all signals (e.g., signals associated with specific subframes for UL (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

[0043] Figure 1C This diagram illustrates a system diagram of RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with CN 106.

[0044] RAN 104 may include eNode-Bs 160a, 160b, and 160c; however, it should be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. eNode-Bs 160a, 160b, and 160c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c on air interface 116. In one embodiment, eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, for example, eNode-B 160a may use multiple antennas to transmit and / or receive radio signals from WTRU 102a.

[0045] Each of the eNode-B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, etc. Figure 1C As shown, eNode-B 160a, 160b, and 160c can communicate with each other on the X2 interface.

[0046] Figure 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (or PGW) 166. While each of the foregoing elements is described as part of CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0047] The MME 162 can connect to each of the eNode-Bs 162a, 162b, and 162c in RAN 104 via the S1 interface and can act as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, etc. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

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

[0049] SGW 164 can connect to PGW 166, which can provide WTRU 102a, 102b, 102c with access to packet-switched networks such as Internet 110, so as to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0050] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRU 102a, 102b, and 102c with access to a circuit-switched network such as PSTN 108, facilitating communication between WTRU 102a, 102b, and 102c and traditional landline communication equipment. For example, CN 106 may include, or be able to communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN 106 and PSTN 108. Furthermore, CN 106 can provide WTRU 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0051] Despite WTRU in Figure 1A-1D While described as a wireless terminal, it is conceivable that, in some representative embodiments, such a terminal may use (e.g., temporarily or permanently) a wired communication interface with a communication network.

[0052] In a representative embodiment, another network 112 may be a WLAN.

[0053] A WLAN in Infrastructure Basic Services Set (BSS) mode can have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can access or interface with a distributed system (DS) or another type of wired / wireless network that transmits traffic to and / or out of the BSS. Traffic originating outside the BSS destined for a STA can reach and be delivered to the STA via the AP. Traffic originating from a STA destined for an external BSS can be sent to the AP for delivery to the appropriate destination. For example, traffic between STAs within the BSS can be transmitted via the AP, where the source STA can send traffic to the AP, and the AP can deliver traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be transmitted between source and destination STAs (e.g., directly between them) using Direct Link Establishment (DLS). In some representative embodiments, the DLS can use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode is sometimes referred to here as an "ad-hoc" communication mode.

[0054] When using 802.11ac infrastructure operating mode or a similar operating mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of a fixed width (e.g., a wide bandwidth of 20 MHz) or dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, such as in an 802.11 system, Carrier Sense Multiple Access (CSMA / CA) with collision avoidance can be implemented. For CSMA / CA, each STA, including the AP, can sense the primary channel. If a particular STA senses / detects and / or determines that the primary channel is busy, that particular STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

[0055] High-throughput (HT) STAs can communicate using a 40 MHz wide channel, for example, by combining a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels.

[0056] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels, or by combining two non-consecutive 80 MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data passes through a segment resolver, which splits the data into two streams. Each stream can be processed separately using Inverse Fast Fourier Transform (IFFT) and time-domain processing. These streams can be mapped onto two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operation of the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0057] 802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidth and carrier in 802.11af and 802.11ah are reduced compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV whitespace (TVWS) spectrum, while 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.11ah can support metering-type control / machine-type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support for (e.g., only) certain and / or limited bandwidths. MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0058] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include channels that can be designated as the primary channel. The bandwidth of the primary channel can be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STA among all STAs operating in the BSS that supports the minimum bandwidth operating mode. In the example of 802.11ah, for STAs that support (e.g., only support) the 1 MHz mode (e.g., MTC type devices), the primary channel can be 1 MHz wide, 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 Sense and / or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, because an STA (which only supports the 1 MHz operating mode) is transmitting to the AP, the entire available band can be considered busy, even if most of the available band remains idle and can be available.

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

[0060] Figure 1D This diagram illustrates a system diagram of RAN 113 and CN 115 according to one embodiment. As described above, RAN 113 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR radio technology. RAN 113 can also communicate with CN 115.

[0061] RAN 113 may include gNBs 180a, 180b, and 180c; however, it should be understood that RAN 113 may include any number of gNBs while remaining consistent with the embodiments. gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c on air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Therefore, for example, gNB 180a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In one embodiment, gNBs 180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers (not shown) to WTRU 102a. A subset of these component carriers can be on unlicensed spectrum, while the remaining component carriers can be on licensed spectrum. In one embodiment, gNBs 180a, 180b, and 180c can implement Coordinated Multipoint (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0062] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable digitization. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can differ for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing a variable number of OFDM symbols and / or a continuously variable absolute time).

[0063] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can utilize one or more of gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate / connect with gNBs 180a, 180b, and 180c, while also communicating / connecting with another RAN such as eNode-Bs 160a, 160b, and 160c. For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c, as well as one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-Bs 160a, 160b, and 160c can act as mobility anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0064] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slicing support, dual connectivity, interoperability between NR and E-UTRA, routing user plane data to User Plane Functions (UPF) 184a and 184b, and routing control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other on the Xn interface.

[0065] Figure 1DThe CN 115 shown 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. Although each of the foregoing elements is depicted as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0066] AMF 182a and 182b can connect to one or more gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can act as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating NAS signaling, mobility management, and so on. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the service types used by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services relying on Ultra Reliable Low Latency Time (URLLC) access, services relying on Enhanced Massive Mobile Broadband (eMBB) access, services for Machine Type Communication (MTC) access, and / or so on. AMF 162 can provide control plane functions for handover between RAN 113 and other RANs (not shown) employing other radio technologies such as LTE, LTE-A, LTE-A Pro and / or non-3GPP access technologies such as WiFi.

[0067] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 115 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 115 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure the routing of services through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0068] UPF 184a and 184b can be connected to one or more gNBs 180a, 180b, and 180c in RAN 113 via the N3 interface. This N3 interface provides WTRU 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

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

[0070] Given Figure 1A-1D as well as Figure 1A-1D The corresponding descriptions herein indicate that one or more of the following functions can be performed by one or more emulation devices (not shown): 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, SMF183a-b, DN 185a-b, and / or any other device(s) described herein. An emulation device can be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device can be used to test other devices and / or simulate network and / or WTRU functions.

[0071] Simulation devices can be designed to perform tests on one or more other devices in laboratory and / or carrier network environments. For example, one or more simulation devices can perform 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 to test other devices within the communication network. One or more simulation devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices can be directly coupled to another device for testing purposes and / or can perform tests using over-the-air wireless communication.

[0072] One or more simulation devices may perform one or more functions, including all functions, rather than being implemented / deployed as part of a wired and / or wireless communication network. For example, simulation devices may be used to test test scenarios in laboratory and / or non-deployment (e.g., testing) wired and / or wireless communication networks to implement the testing of one or more components. One or more simulation devices may be test devices. Simulation devices may transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas).

[0073] This paper describes systems, methods, apparatus, and tools related to determining segmentation bearer thresholds (e.g., for multipaths with multiple indirect paths).

[0074] A WTRU (e.g., a remote WTRU) can be configured in a multipath environment (e.g., having a primary path via Uu and multiple non-primary paths via one or more indirect / relay paths). The remote WTRU can be configured with a segmented bearer threshold, which can be used to transmit data via either the primary or non-primary path. The remote WTRU can be configured with different segmented bearer thresholds for each combination of the multiple available indirect paths (e.g., a threshold for the amount of data that can be transmitted (e.g., sent) on the indirect / non-primary paths by the segmented bearer) (e.g., the remote WTRU can be configured to receive configuration information indicating the different segmented bearer thresholds).

[0075] The remote WTRU can receive configuration information indicating a first segmented bearer threshold associated with a first number of available indirect paths (e.g., a first threshold amount of data allowed to transmit data using indirect paths) (e.g., the first segmented bearer threshold is applicable if the number of available paths is equal to X) and a second segmented bearer threshold associated with a second number of available indirect paths (e.g., a second threshold amount of data allowed to transmit data using indirect paths) (e.g., the second segmented bearer threshold is applicable if the number of available paths is equal to Y, etc., where X and Y can be corresponding values ​​or ranges of values).

[0076] In the example, a remote WTRU can be configured to receive unicast (e.g., corresponding unicast) SL DRX configurations associated with indirect paths (e.g., each associated with an indirect path) from a relay WTRU (e.g., each of the relay WTRUs). The remote WTRU can determine whether an indirect path is available based on the received unicast SL DRX configurations. In the example, a remote WTRU can also be configured to receive failure notifications (e.g., one or more corresponding failure notifications) associated with indirect paths from a relay WTRU (e.g., each of the relay WTRUs). The remote WTRU can determine whether an indirect path is available based on the received failure notifications.

[0077] The remote WTRU can determine the number of available indirect paths. In the example, the determined number of indirect paths can be a first number of available indirect paths or a second number of available indirect paths. The remote WTRU can determine the number of available indirect paths based on at least one of the following: the number of indirect paths configured to not exist as signaled by a relay WTRU (e.g., in a failure notification) (e.g., Uu-RLF, relay flow control, etc.) that have failed pending paths (e.g., the number of different relay WTRUs); or the number of indirect paths configured to not exist.

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

[0079] In the example, the WTRU can determine that the amount of data available for transmission at a segmented bearer is higher than a selected segmented bearer threshold (e.g., a first segmented bearer threshold or a second segmented bearer threshold). Based on this determination, the remote WTRU can determine whether the path is a direct / primary path or an indirect / non-primary path. The remote WTRU can then use the segmented bearer to send (e.g., transmit) data via the determined direct / primary or indirect / non-primary path.

[0080] In the example, the WTRU can determine that the amount of data available for transmission at the segmented bearer is equal to or less than a selected segmented bearer threshold (e.g., a first segmented bearer threshold or a second segmented bearer threshold). The remote WTRU can determine whether the path is a direct / primary path or not based on this determination. The remote WTRU can then send (e.g., transmit) the data for the segmented bearer via the determined primary path (e.g., via the primary path only).

[0081] This article describes systems, methods, devices, and tools related to applying segmented bearer thresholds (one or more) to individual indirect paths.

[0082] Devices such as Wireless Transmit / Receive Units (WTRUs) may include processors configured to perform one or more actions. A WTRU may determine or receive indications of multiple indirect paths. These multiple indirect paths (e.g., each of multiple indirect paths) may be associated with a relay WTRU (e.g., a corresponding relay WTRU). A WTRU may determine that one of the indirect paths is an anchor path. A WTRU may use the anchor path to transmit data (e.g., if the data volume is below an anchor path data threshold).

[0083] In the example, an indirect path can be identified as the anchor path based on the determination that it has the minimum number of hops compared to another indirect path among multiple indirect paths. In the example, an indirect path can also be identified as the anchor path based on the determination that it is served by a cell that serves the direct path associated with the WTRU.

[0084] This article describes systems, methods, devices, and tools related to data segmentation between direct and indirect paths.

[0085] Devices such as Wireless Transmit / Receive Units (WTRUs) may include processors configured to perform one or more actions. The WTRU can determine or receive indications of a primary path and multiple available indirect paths. The WTRU can select data segments based on the number of available indirect paths and / or the corresponding flow control level associated with each of said available indirect paths. The WTRU can use the primary path and said multiple available indirect paths to transmit data. This data can be transmitted based on data segments.

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

[0087] In the example, data partitioning can be selected based on the number of available indirect paths to which data is partitioned and the mapping of flow control levels associated with each available indirect path (e.g., each of the available indirect paths). In the example, data can be sent using the primary path and the multiple available indirect paths within an evaluation window. The WTRU can determine that a data partition cannot be satisfied. The WTRU can (e.g., send an indication to the network) that a data partition cannot be satisfied.

[0088] This article describes systems, methods, devices, and tools related to the activation and deactivation of indirect paths.

[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. Discontinuous reception (DRX) associated with the first relay may be enabled. The WTRU may determine whether DRX is disabled for the first relay. The determination of whether DRX is disabled may be based on a comparison of a buffer state associated with the first indirect path with a buffer threshold. The WTRU may use the first indirect path to send a DRX indication to the first relay. The DRX indication may indicate whether DRX associated with the first relay is disabled.

[0090] The WTRU can receive a control flow indication associated with the first relay. The WTRU can select a data segment for the first indirect path based on the control flow indication. The WTRU can use the first indirect path to send data. Data can be sent based on data segmentation. In the example, data can be sent over a pre-configured window. In the example, when the buffer state is above a buffer threshold for a period of time, the DRX indication can indicate that DRX associated with the first relay is disabled.

[0091] Devices such as Wireless Transmit / Receive Units (WTRUs) may include processors configured to perform one or more actions. The WTRU may determine or receive a first indirect path associated with a first relay. DRX associated with the first relay may be disabled. The WTRU may determine a DRX indication indicating whether DRX is enabled for the first relay. The DRX indication may be based on a comparison of a buffer state associated with the first indirect path with a buffer threshold. The WTRU may send the DRX indication to the first relay using the first indirect path. In the example, the DRX indication may indicate that DRX associated with the first relay is enabled when the buffer state is below the buffer threshold for a period of time.

[0092] The term Special Cell (SpCell) can refer to the primary cell (PCell) of a primary cell group (MCG) or the PSCell of a secondary cell group (SCG) (e.g., depending on whether the Media Access Control (MAC) entity is associated with an MCG or an SCG).

[0093] This article provides one or more features associated with WTRU-to-network relay for out-of-coverage (OOC) WTRUs.

[0094] Sidelink-based (SL-based) WTRU-to-network trunks can be specified. One or more sidelink trunks can be introduced to support ProSe WTRU-to-network trunk (U2N trunk) functionality (e.g., providing network connectivity for one or more U2N remote WTRUs). L2 and L3 U2N trunk architectures can be supported. The L3 U2N trunk architecture can be transparent to the serving RAN of the U2N trunk WTRU (e.g., except for controlling sidelink resources).

[0095] U2N relay WTRUs can be in RRC_CONNECTED (RRC connected) to perform unicast data relay. For L2U2N relay operation, one or more of the following RRC state combinations can be supported: both the U2N relay WTRU and the U2N remote WTRU can be in RRC CONNECTED to perform unicast data transmission / reception for relay; or the U2N relay WTRU can be in RRC_IDLE (RRC idle), RRC_INACTIVE (RRC inactive), or RRC_CONNECTED (for example, if all(one or more) U2N remote WTRUs connected to the U2N relay WTRU are in RRC_INACTIVE or RRC_IDLE).

[0096] For L2 U2N relays, the U2N remote WTRU can be configured to use resource allocation mode 2 for the data to be relayed. A single unicast link can be established between an L2 U2N relay WTRU and an L2 U2N remote WTRU. Traffic from the U2N remote WTRU via a given U2N relay WTRU and traffic from the U2N relay WTRU can be separated in different Uu RLC channels on Uu.

[0097] Figure 2 An example of a remote WTRU in OOC is illustrated. Layer 2 WTRUs can be introduced into network relays (e.g., if the remote WTRU is outside coverage). In multipath, it can be assumed that the remote WTRU is within coverage and one or more of the Uu path or SL (e.g., relayed) path can be utilized.

[0098] Multipath support can enhance reliability and throughput (e.g., by switching between or utilizing multiple paths simultaneously). A WTRU can connect to the same gNB using a direct path and an indirect path (e.g., via a Layer 2 WTRU to a network trunk, or via another WTRU, where a WTRU-WTRU interconnection might be ideal). Supporting Layer 3 WTRU to a network trunk in a multipath scenario can be considered to have no impact on the RAN.

[0099] This article provides one or more features associated with the L2 U2N relay protocol architecture.

[0100] Figure 3A The diagram illustrates the protocol stack for the user plane of the L2 U2N relay architecture. Figure 3B The diagram illustrates the protocol stack for the control plane of an L2 U2N trunk architecture. The SRAP sublayer can be placed on top of the RLC sublayer for cyclic prefix (CP), and UP is on the PC5 interface and / or Uu interface. Uu SDAP, PDCP, and RRC can terminate between the L2 U2N remote WTRU and gNB, while SRAP, Radio Link Control (RLC), Media Access Control (MAC), and Physical Layer (PHY) can terminate at each hop (e.g., the link between the L2 U2N remote WTRU and the L2 U2N trunk WTRU, and the link between the L2 U2N trunk WTRU and the gNB).

[0101] For L2 U2N relays, the SRAP sublayer on the PC5 hop may be for bearer mapping purposes. The SRAP sublayer may not exist on the PC5 hop used to relay L2 U2N remote WTRU messages on the BCCH and PCCH. For L2U2N remote WTRU messages on SRB0, the SRAP sublayer may not exist on the PC5 hop, but for downlink (DL) and uplink (UL), the SRAP sublayer may exist on the Uu hop.

[0102] For L2 U2N trunking, for the uplink, the Uu sublayer can support UL bearer mapping between the ingress PC5 trunk RLC channel used for trunking and the egress Uu trunk RLC channel on the L2 U2N trunk WTRU Uu interface. For uplink trunking services, different end-to-end RBs (e.g., SRBs or DRBs) of the same remote WTRU and / or different remote WTRUs can be multiplexed (e.g., on the same Uu trunk RLC channel). For L2 U2N trunking, for the uplink, the Uu SRAP sublayer can support L2 U2N remote WTRU identification for UL services. The identity information of the L2 U2N remote WTRU Uu radio bearer and the local remote WTRU ID can be included in the Uu SRAP header at the UL (e.g., to allow the gNB to correlate received packets for a specific PDCP entity associated with the correct Uu radio bearer of the remote WTRU). For L2 U2N trunks, for the uplink, the PC5 SRAP sublayer at the L2 U2N remote WTRU can support UL bearer mapping between the remote WTRU Uu radio bearer and the egress PC5 trunk RLC channel.

[0103] For L2 U2N trunks, for the downlink, the Uu SRAP sublayer can support DL bearer mapping at the gNB to map end-to-end radio bearers (e.g., signaling radio bearers (SRBs), data radio bearers (DRBs)) of remote WTRUs to Uu trunk RLC channels on the trunk WTRU Uu interface. The Uu SRAP sublayer can support DL bearer mapping and data multiplexing between multiple end-to-end radio bearers (e.g., SRBs or DRBs) of L2 U2N remote WTRUs and / or different L2 U2N remote WTRUs and a single Uu trunk RLC channel on the trunk WTRU Uu interface. For L2 U2N trunks, for the downlink, the Uu SRAP sublayer can support remote WTRU identification for DL ​​services. The identity information of the remote WTRU Uu radio bearer and the local remote WTRU ID can be included by the gNB at the DL in the Uu SRAP header (e.g., so that packets received by the trunk WTRU from the remote WTRU Uu radio bearer can be mapped to its associated PC5 trunk RLC channel). For L2 U2N relays, for the downlink, the PC5 SRAP sublayer at the relay WTRU can support DL bearer mapping between the ingress Uu relay RLC channel and the egress PC5 relay RLC channel. For L2 U2N relays, for the downlink, the PC5 SRAP sublayer at the remote WTRU can correlate received packets for a specific PDCP entity associated with the correct Uu radio bearer of the remote WTRU (e.g., based on identity information included in the Uu SRAP header).

[0104] The local remote WTRU ID can be included in the PC5 SRAP header and the Uu SRAP header. The L2 U2N trunk WTRU can be configured by the gNB with the local remote WTRU ID to be used in the SRAP header. The remote WTRU can obtain the local remote ID from the gNB via Uu RRC messages (e.g., RRCSetup, RRCReconfiguration, RRCResume, and RRCReestablishment). In PC5 and Uu hops, one or more Uu DRBs and one or more Uu SRBs can be mapped to different PC5 trunk RLC channels and Uu trunk RLC channels. The gNB may be responsible for avoiding conflicts in the use of the local remote WTRU ID. The gNB can update the local remote WTRU ID by sending an updated local remote ID to the trunk WTRU (e.g., via an RRCReconfiguration message). The serving gNB can perform local remote WTRU ID updates (e.g., independently of the PC5 unicast link L2 ID update procedure).

[0105] This article provides one or more features associated with sidelink scheduling.

[0106] The side link can support two scheduling modes (e.g., mode 1 and mode 2). For WTRUs within the coverage area, the gNB can control whether the WTRU uses mode 1 or mode 2 for transmission.

[0107] In Mode 1 scheduling (e.g., it can be used for a side-link WTRU in RRC_CONNECTED), the WTRU can receive SL grants directly from the network in the DCI. The WTRU can report the buffer status of SL data grouped by destination indexes (e.g., where the destination index may correspond to a unique L2 destination ID, or a pair of source / destination L2 IDs). If the SL grant is not available for the transfer of pending data, the WTRU can report an SL SR.

[0108] In Mode 2 scheduling (which can be used by WTRUs in any RRC state or potentially outside the coverage area), WTRUs can be configured with a resource pool from which they perform autonomous resource selection and scheduling. Resources can be selected by the WTRU (e.g., based on information from previous SCI transmissions by other WTRUs, such as sensing results).

[0109] This document describes one or more features associated with advanced multipath. Multipath SL relay can be implemented, allowing remote WTRUs within coverage area to transmit data via a Uu path and a single SL WTRU to an NW relay. The same gNB can be used for both the cell relaying the WTRU and the cell controlling the remote WTRU (e.g., cases of the same cell or different cells can be considered). A DC architecture can be assumed for multipath (e.g., with segmented bearers for data segmented at the PDCP).

[0110] Figure 4 The illustration shows an example of remote WTRUs within coverage area connected via direct and indirect paths (e.g., via relay WTRUs). Multiple indirect paths via different relays can be implemented (e.g., where relay paths may include multiple hops). WTRUs within coverage area can be connected at a DC (e.g., via direct and indirect paths), but WTRUs can use multiple indirect paths (e.g., a CA-like architecture or a DC-like architecture). WTRU OOCs can use multiple relays to connect to the network (e.g., in a CA-like architecture or a DC-like architecture).

[0111] Dual connectivity (DC) can use a segmented bearer threshold for WTRUs to determine whether to use SCG for each segmented bearer (e.g., Uu primary path and trunk / indirect auxiliary path). Multipathing allows multiple trunk WTRUs on indirect paths. Multiple paths may exist. The state of a path (e.g., each path) can change based on the trunk state.

[0112] If multiple indirect paths exist, data can be partitioned along the indirect paths based on a model of each indirect path. If a DC-like model is used, WTRU can partition the data using PDCP. The decision to partition the data can be made before requesting resources from the network. If multiple indirect paths exist, one of the indirect paths may be superior to the others, or it may not be superior to the others (e.g., this factor may differ from multipath or CA).

[0113] For multipath, the same cell can control both direct and indirect paths (e.g., the opposite of a DC). If a single gNB or cell controls both direct and indirect paths, determining the bearer segmentation threshold may be restrictive for multipath networks. For WTRUs in OOC, Sidelink Discontinuous Reception (SL-DRX) may depend on the WTRU implementation. Maintaining SL-DRX may be preferred if limited data can be expected on multiple paths in a multipath multipath without a direct Uu path. For large amounts of data, disabling DRX may be preferred.

[0114] This document provides one or more features associated with the determination of the segmented bearer threshold for a multipath with multiple indirect paths. In a multipath with multiple indirect paths via different relays (e.g., a primary path via Uu and a non-primary path via indirect / relay), a remote WTRU can determine whether to perform routing to an indirect path based on the amount of buffered data used for bearer and / or the number of active (e.g., non-DRX) and / or available (e.g., non-failed) indirect paths (e.g., because failures can be indicated by relay WTRUs).

[0115] In the example, one or more of the following can be performed (e.g., associated with determining and / or using a segmented bearer threshold with a remote WTRU). The WTRU (e.g., the remote WTRU used as an example in this document) can be configured in a multipath (e.g., having a primary path via Uu and multiple non-primary paths via (one or more) indirect / relay paths). The remote WTRU can be configured with a segmented bearer that can be used to transmit data via the primary path or one or more non-primary paths. For each combination of multiple available indirect paths, the remote WTRU can be configured with a different segmented bearer threshold (e.g., a threshold for the amount of data that can be routed (e.g., transmitted) by the segmented bearer on the indirect / non-primary paths) (e.g., the remote WTRU can be configured to receive configuration information indicating different segmented bearer thresholds). In the example, the remote WTRU may (e.g., from a network node) receive configuration information indicating a first segmented bearer threshold associated with a first number of available indirect paths (e.g., a first threshold amount of data allowed to transmit data using the first indirect path) (e.g., the first segmented bearer threshold is applicable if the number of available paths is equal to X) and a second segmented bearer threshold associated with a second number of available indirect paths (e.g., a second threshold amount of data allowed to transmit data using the second indirect path) (e.g., the second segmented bearer threshold is applicable if the number of available paths is equal to Y, etc., where X and Y can be corresponding values ​​or ranges of values).

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

[0117] The remote WTRU can determine the number of available indirect paths. The number of indirect paths can be a first number or a second number. The remote WTRU can determine the number of available indirect paths based on at least one of the following: the number of indirect paths configured to not exist (e.g., the number of different trunk WTRUs) that have failed pending paths signaled by a trunk WTRU (e.g., in a failure notification) (e.g., Uu-RLF, trunk flow control, etc.); or the number of indirect paths configured to not exist.

[0118] The remote WTRU can select a split bearer threshold associated with the determined number of available indirect paths. In the example, the remote WTRU can select a first split bearer threshold if the number of available indirect paths is a first number. The remote WTRU can select a second split bearer threshold if the number of available indirect paths is a second number. The WTRU can determine the path based on whether the amount of data available for transmission exceeds the split bearer threshold (e.g., the selected first split bearer threshold or the selected second split bearer threshold). The remote WTRU can use the determined path to send data.

[0119] In the example, the WTRU can determine that the amount of data available for transmission at the segmented bearer is higher than a selected segmented bearer threshold (e.g., a first segmented bearer threshold or a second segmented bearer threshold). Based on this determination that the amount of data available for transmission is higher than the selected segmented bearer threshold (e.g., a first segmented bearer threshold or a second segmented bearer threshold), the remote WTRU can determine whether the transmission path is a direct / primary path or an indirect / non-primary path (e.g., determine to use either a direct / primary path or an indirect / non-primary path). The remote WTRU can route (e.g., transmit) data using the segmented bearer via either the determined direct / primary path or indirect / non-primary path.

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

[0121] This article provides one or more features associated with applying a segmented bearer threshold to individual indirect paths. A remote WTRU in a multipath can determine whether to route data to one or more indirect paths based on one or more of the following: the number of hops in each indirect path, the cell ID served by the relay in the indirect path, or the amount of data buffered for transmission.

[0122] In the example, one or more of the following can be performed (e.g., for the remote WTRU to determine which indirect path to route data to). The remote WTRU can be configured with bearers associated with at least two indirect paths (e.g., bearers associated with one or more different relays). The remote WTRU can be configured with anchor path data thresholds. 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 indirect path is less than the number of hops on other indirect paths, then the remote WTRU can determine that one of the indirect paths is the anchor path for the bearer.

[0123] If a remote WTRU determines that it has an anchor path for carrying data, the remote WTRU may send (e.g., transmit) data (e.g., all available data) to the anchor path until the buffered data volume exceeds a threshold, and under this condition, send (e.g., transmit) data to the anchor path or (one or more) other indirect paths. If a remote WTRU determines that it does not have an anchor path for carrying data, the remote WTRU may send (e.g., transmit) data to the anchor path or (one or more) other indirect paths.

[0124] This document provides one or more features associated with data segmentation between one or more direct paths and one or more indirect paths. A remote WTRU in a multipath can determine the amount of data to be routed to one or more direct paths and one or more indirect paths (e.g., each of one or more direct paths and one or more indirect paths). The remote WTRU can identify multiple available paths. The remote WTRU can receive one or more corresponding flow control indications from relay WTRUs (e.g., each relay WTRU) on one or more indirect paths. The determination of the amount of data routed to one or more direct paths and one or more indirect paths can be based on the multiple available paths and / or the flow control indications.

[0125] In the example, one or more of the following can be performed (e.g., associated with the remote WTRU splitting data between one or more direct paths and one or more indirect paths). The remote WTRU can be configured in a multipath with a primary path (e.g., via Uu) and a non-primary path (e.g., via one or more indirect / relays). The remote WTRU can be configured with a split bearer that can be used to send data via either the primary or non-primary path. The remote WTRU can be configured with data splitting between the primary and non-primary paths (e.g., percentage splitting of data) (e.g., receiving configuration information indicating such data splitting). Appropriate data splitting (e.g., corresponding data splitting for each number (or range) of indirect paths) can be configured (e.g., receiving configuration information) for a combination of a corresponding number of available indirect paths or a corresponding number of available indirect paths and one or more associated congestion levels (e.g., as indicated by each relay associated with an indirect path). The remote WTRU can be configured with an evaluation window.

[0126] A remote WTRU can receive one or more corresponding flow control messages from relay WTRUs (e.g., each relay WTRU) associated with one or more indirect paths (e.g., on each indirect path). The flow control messages may indicate one of multiple flow control levels. The remote WTRU can select a configured data segmentation based on the number of available paths and / or flow control indications (e.g., the flow control level associated with each relay WTRU on each path), as determined or received by the remote WTRU. The remote WTRU can transmit (e.g., broadcast) data based on the selected data segmentation. The segmented bearer can use the selected data segmentation to transmit data to primary and non-primary paths (e.g., within an evaluation window). If the data segmentation cannot be satisfied (e.g., CBR limitation), the remote WTRU can notify the network.

[0127] This document provides one or more features associated with the activation and deactivation of indirect paths. Remote WTRUs can enable / disable SL-DRX on links associated with relay WTRUs (e.g., based on the buffer status and corresponding flow control indications of the relay WTRU).

[0128] In the example, one or more of the following can be performed (e.g., associated with activating and / or deactivating DRX on a link associated with a trunk WTRU). The remote WTRU can be configured with at least two indirect paths (e.g., via different trunks). The remote WTRU can be configured with percentage data segmentation on multiple indirect paths. The remote WTRU can be configured with corresponding percentage data segmentation for a given combination (e.g., each combination) of flow control levels indicated by one or more trunk WTRUs. The remote WTRU can be configured with buffer thresholds for enabling / disabling SL-DRX.

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

[0130] A remote WTRU can determine whether DRX is enabled or disabled (e.g., based on the actual buffer state being above / below a configured threshold). When the buffer state is above the threshold for at least period X and DRX is enabled on the link associated with the trunk WTRU, the remote WTRU can send (e.g., transmit) a DRX disable indication to the trunk WTRU. When the buffer state is below the threshold for at least period Y and DRX is disabled on the link associated with the trunk WTRU, the remote WTRU can send (e.g., transmit) a DRX enable indication to the trunk WTRU. The remote WTRU can send (e.g., transmit) DRX enable / disable to each of the trunks (e.g., based on determination by one or more of them). The remote WTRU can send (e.g., transmit) data buffered for each indirect path to the associated trunk.

[0131] This document provides one or more characteristics associated with remote WTRU routing behavior. Routing behavior may include one or more of the following: conditions under which the WTRU determines whether (e.g., to begin) data can be broadcast to one or more paths or not (e.g., in terms of the amount of buffered data); the WTRU determines the amount of data to be broadcast to one or more paths (e.g., the exact amount); the WTRU determines which paths(s) to broadcast data to first; the WTRU determines which paths(s) to prioritize; or the WTRU determines what data (what type of data) to broadcast to one or more paths.

[0132] For example, the WTRU can determine which paths(s) to send RRC messages to (e.g., when the SRB can be a segmented bearer). For example, the WTRU can determine which paths(s) to send control PDUs (e.g., PDCP control PDUs, MAC CEs, etc.) for a given protocol layer. For example, the WTRU can determine which paths(s) to send data PDUs containing additional QoS indications (e.g., PSDBs, or additional QoS indications associated with other XR-related information).

[0133] The remote WTRU can determine the segmentation bearer threshold for a multipath with multiple indirect paths. In a multipath with multiple indirect paths via different relays (e.g., a primary path via Uu and a non-primary path via indirect / relay), the remote WTRU can determine the route to the indirect path based on the number of active (e.g., non-DRX) / available (e.g., non-failed) indirect paths as indicated by the relay WTRU and / or the amount of buffered data carried.

[0134] Remote WTRUs can be configured in a multipath (e.g., having a primary path via Uu and multiple non-primary paths via (one or more) indirect / relay paths).

[0135] Remote WTRUs can be configured with segmented bearers that can send data via the primary path or a non-primary path.

[0136] For each combination of multiple available indirect paths, the remote WTRU can be configured with different segmented bearer thresholds (e.g., a threshold for the amount of data that can be sent (e.g., transmitted) by segmented bearers on indirect / non-primary paths) (e.g., the remote WTRU can be configured to receive configuration information indicating these different segmented bearer thresholds). In the example, the remote WTRU can (e.g., from a network node) receive configuration information indicating a first segmented bearer threshold associated with a first number of available indirect paths (e.g., a first threshold amount of data allowed to be transmitted using the first indirect path) and a second segmented bearer threshold associated with a second number of available indirect paths (e.g., a second threshold amount of data allowed to be transmitted using the second indirect path).

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

[0138] A remote WTRU can be configured to receive / from one or more relay WTRUs failure notifications associated with indirect paths (e.g., one or more corresponding failure notifications) (e.g., if multiple failure notifications are received, each failure notification can be associated with a corresponding indirect path). The remote WTRU can determine whether an indirect path is available based on the received failure notifications.

[0139] The remote WTRU can determine the number of available indirect paths. The number of indirect paths can be a first number or a second number of available indirect paths. The remote WTRU can determine the number of available indirect paths based on at least one of the following: the number of indirect paths configured to not exist (e.g., the number of different trunk WTRUs) that have failed pending paths (e.g., in failure notifications) (e.g., Uu-RLF, trunk flow control, etc.); or (e.g., the number of indirect paths configured by the SL DRX on the path).

[0140] The remote WTRU can select a split bearer threshold associated with the number of available indirect paths. In the example, the remote WTRU can select a first split bearer threshold if the number of available indirect paths is a first number. The remote WTRU can select a second split bearer threshold if the number of available indirect paths is a second number. The WTRU can determine the path based on whether the amount of data available for transmission exceeds the split bearer threshold (e.g., the selected first split bearer threshold or the selected second split bearer threshold). The remote WTRU can use the determined path to send data.

[0141] In the example, the WTRU can determine that the amount of data available for transmission at the segmented bearer is higher than a selected segmented bearer threshold (e.g., a first segmented bearer threshold or a second segmented bearer threshold). Based on this determination, the remote WTRU can determine whether the transmission path is a direct / primary path or an indirect / non-primary path (e.g., determining whether to use a direct / primary path or an indirect / non-primary path). The remote WTRU can then transmit (e.g., broadcast) the data for the segmented bearer via the determined direct / primary path or indirect / non-primary path.

[0142] In the example, the WTRU can determine that the amount of data available for transmission at the segmented bearer is equal to or less than a selected segmented bearer threshold (e.g., a first segmented bearer threshold or a second segmented bearer threshold). The remote WTRU can determine whether the path is a direct / primary path (e.g., determine to use a direct / primary path) based on this determination. The remote WTRU can then send (e.g., transmit) the data for the segmented bearer via the determined primary path.

[0143] A remote WTRU can determine the segmentation of data between direct and indirect paths. Characteristics associated with indirect paths can be used to determine when to begin using indirect paths to transmit data that can be sent via both direct and indirect paths. A remote WTRU can be configured with routing rules (e.g., below the PDCP layer) for routing data between RLC entities (e.g., multiple RLC entities) associated with direct paths and RLC entities (e.g., multiple RLC entities) associated with indirect paths. A remote WTRU can be configured with rules regarding whether / when data is sent via (one or more) direct paths and whether / when data is sent via (one or more) indirect paths. Routing rules can be based on routing behavior.

[0144] A WTRU can have a primary path, which may include a Uu RLC entity. A WTRU can further have non-primary paths, which may include SL RLC entities. RLC entities can be used for communication via multiple SL paths (e.g., each SL path associated with a different set of relay WTRUs can be used to forward packets from a source (e.g., a TX WTRU) to a destination (e.g., a network node or an RX WTRU)). A WTRU can have multiple RLC entities. Each RLC entity can correspond to a different next-hop relay.

[0145] Factors that determine the routing rules between primary and secondary paths may include one or more of the following: the number of next-hop relay WTRUs through which non-primary paths communicate; the number of SL relay paths between the TX WTRU and the destination; commonalities between two or more SL paths associated with a multi-hop; the activation / deactivation status associated with a next-hop or SL path; DRX configuration; the existence of failed SL paths; or flow control indications from relay WTRUs on a particular path.

[0146] The number of next-hop relay WTRUs traversed for communication on non-primary paths can be a factor used to determine routing rules between primary and secondary paths. For example, a non-primary RLC entity may be associated with multiple distinct next-hop nodes (e.g., relay WTRUs). Routing rules between primary and non-primary paths 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 can be a factor used to determine routing rules between primary and secondary paths. For example, a non-primary RLC entity can transmit data via different multi-hop SL relay paths. Multiple SL paths may utilize a single next-hop relay / node (e.g., if the path branches at a later node and / or converges into a single path at a later node). Routing rules can be based on (e.g., depending on) the number of SL relay paths.

[0148] Commonalities between two or more SL paths associated with multi-hop routing can be a factor used to determine routing rules between primary and secondary paths. For example, in multi-hop routing, two SL trunk paths can be considered to share some commonalities if multiple SL trunk paths share some common hops (e.g., a link between two trunk WTRUs). Routing rules can be based on (e.g., depending on) one or more of the following: the number of paths with commonalities, the degree of commonality (e.g., how many SL paths actually consist of common links), etc.

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

[0150] DRX configuration can be a factor used to determine routing rules between primary and secondary paths. For example, a factor for routing rules could be whether the DRX is configured on the first hop of an SL path. Another factor could be whether the DRX is configured on any hop associated with an SL path. Yet another factor could be whether any DRX parameter meets specific criteria (e.g., the DRX activation period can be greater than a threshold, the DRX period can be less than a threshold, the DRX can be aligned between two different SL paths / hops, etc.).

[0151] The existence of a failed SL path can be a factor used to determine the routing rules between the primary and secondary paths. For example, a factor for a routing rule could be whether the SL RLF or Uu RLF is detected by a remote WTRU on the path. Another factor for a routing rule could be whether the relay WTRU associated with the path to the remote WTRU indicates an SL RLF or UuRLF.

[0152] Flow control indications from a trunk WTRU on a specific path can be factors used to determine routing rules between primary and secondary paths. For example, factors for routing rules can be any one or more conditions associated with flow control and / or load indications on the trunk path, such as one or more conditions such as the load associated with the trunk WTRU being higher than a threshold.

[0153] A remote WTRU can be configured with multiple split bearer thresholds to apply to an end-to-end bearer (e.g., multiple split bearer thresholds can be applied to a single end-to-end bearer). These split bearer thresholds can be used by the remote WTRU to determine when to begin transmitting data on non-primary paths. When the bearer's buffer state is below the configured split bearer threshold, the remote WTRU can transmit data for the bearer to the primary path. When the buffer state is above the configured split bearer threshold, the WTRU can transmit data to both the primary and non-primary paths.

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

[0155] The remote WTRU can determine the number of available indirect paths as the number of configured indirect paths. The number of available indirect paths can include the number of PC5-RRC connections the remote WTRU has to the relay WTRU (e.g., whereby the relay WTRU includes possible paths to the intended destination). The number of available indirect paths can also include the number of PC5-RRC connections to the relay WTRU (e.g., whereby each PC5-RRC connection includes possible paths for a specific bearer that can take a segmentation threshold into account). If the number of configured paths is a first number or within a first range, the remote WTRU can apply a first segmentation buffer threshold. If the number of configured paths is a second number or within a second range, the remote WTRU can apply a second first segmentation bearer threshold.

[0156] In the example (e.g., applicable to multi-hop), the remote WTRU can determine the number of available indirect paths as the number of distinct paths (e.g., which may be bearer-specific) to which the remote WTRU can send data (e.g., where paths include sequences of PC5-RRC connections on multi-hop relay WTRUs). For example, different paths can be associated with different L2 ID sequences, different local WTRU ID sequences, path IDs, etc. Some overlap in relays may exist within the paths. If the configured number of paths is a first number or within a first range, the remote WTRU can apply a first split bearer threshold. If the configured number of paths is a second number or within a second range, the remote WTRU can apply a second split bearer threshold.

[0157] The remote WTRU can determine the number of available indirect paths as the number of configured indirect paths that are activated (e.g., via activation at the remote WTRU or via such activation over the network). If the number of configured paths is a first number or within a first range, the remote WTRU can apply a first segmented bearer threshold. If the number of configured paths is a second number or within a second range, the remote WTRU can apply a second segmented bearer threshold.

[0158] The remote WTRU can determine the number of available indirect paths as the number of configured indirect paths for which the SL may not have a DRX configured or whose configured DRX has an inactivity time exceeding a threshold. If the number of non-DRX or non-inactive paths is a first number or within a first range, the remote WTRU can apply a first split bearer threshold. If the number of non-DRX or non-inactive paths is a second number or within a second range, the remote WTRU can apply a second split bearer threshold.

[0159] The remote WTRU can 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 that transmission should be constrained to that particular path (e.g., no indication of any need for it) or have a flow control level below a certain threshold. Specifically, if the number of relay paths with flow control below the threshold is a first value or within a first value range, the remote WTRU can apply a first split bearer threshold. If the number of relay paths with flow control below the threshold is a second value or within a second value range, the remote WTRU can apply a second split bearer threshold.

[0160] A remote WTRU can determine a segmented bearer threshold based on a function from the flow control level of the SL trunk path (e.g., each of the paths in the SL trunk). For example, the function could be the minimum, maximum, or average value of paths with values ​​above the threshold. The WTRU can be configured to map the flow control functions of indirect paths to a table of segmented bearer thresholds used for routing between direct and indirect paths.

[0161] Conditions can be applied using a split bearer threshold or another threshold (e.g., as specified in the examples herein) without losing the generality of other factors mentioned herein regarding routing between direct and indirect paths (e.g., whether RRCs are transmitted on direct and / or indirect paths when the WTRU can / cannot use indirect paths, etc.).

[0162] This article provides one or more features associated with the segmented bearer threshold applied to individual indirect paths. A remote WTRU in a multipath can determine whether to route data to one or more indirect paths based on one or more of the following: the number of hops in each indirect path, the cell ID served by the relay in the indirect path, or the amount of data buffered for transmission.

[0163] A remote WTRU can be configured with a bearer having at least two indirect paths (e.g., via one or more different relays). The remote WTRU can be configured with an anchor path data threshold. The remote WTRU can determine that one of the indirect paths can 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 a remote WTRU determines that it has an anchor path for carrying data, 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 exceeds a threshold, and then send (e.g., transmit) data to the anchor path or (one or more) other paths. If a remote WTRU determines that it does not have an anchor path for carrying data, the remote WTRU may send (e.g., transmit) data to the anchor path or (one or more) other indirect paths.

[0165] This article provides one or more features associated with data segmentation between direct and indirect paths. A remote WTRU in a multipath can determine the amount of data routed to each of the direct and indirect paths, for example, based on the number of available paths and / or flow control indications from relay WTRUs on each indirect path.

[0166] In the example, one or more of the following can be performed (e.g., for data partitioning between direct and indirect paths). A remote WTRU can be configured in a multipath having a primary path via Uu and non-primary paths via (one or more) indirect / relay paths. A remote WTRU can be configured with a partitioned bearer that can send data via either the primary or non-primary path. A remote WTRU can be configured for percentage partitioning of data between the primary and non-primary paths. Percentage partitioning of data can be configured for the number of available indirect paths (e.g., for each number) and / or (one or more) congestion levels (e.g., indicated by each relay WTRU on the indirect path). A remote WTRU can be configured with an evaluation window.

[0167] A remote WTRU can receive one or more flow control messages from each of the relay WTRUs on an indirect path. These flow control messages can, for example, each indicate one of multiple flow control levels. The remote WTRU can select a configured data segmentation based on the number of available paths and / or the flow control level on each path (e.g., a table can map the number of paths and / or the flow control indications on each path to data segments). The remote WTRU can send (e.g., transmit) data (e.g., on an evaluation window) to the primary and non-primary paths based on the selected data segmentation used to segment the bearer. If a data segmentation cannot be satisfied (e.g., CBR limitation), the remote WTRU can notify the network.

[0168] A remote WTRU can determine data routing rules with multiple indirect paths. A remote WTRU in a multi-path environment (e.g., with multiple indirect paths) can determine data routing rules based on factors associated with one or more indirect paths of interest. A remote WTRU can have multiple indirect paths. A remote WTRU can (e.g., may also) have one or more direct paths. A remote WTRU can be a WTRU communicating with a network (e.g., via direct and / or indirect paths). An indirect path can include at least one WTRU to a network relay. A WTRU can be a source WTRU communicating with a destination WTRU via multiple SL paths (e.g., directly or indirectly via at least one U2U relay). Routing rules can be associated with a single bearer. For example, routing rules can include determining bearer splitting operations for bearers configured on indirect paths. Routing rules can be associated with data routed to a destination (e.g., all data) or multiple bearers. For example, rules can include determining the relative amount of data to be transmitted across bearers (e.g., all bearers) via a path (e.g., each path).

[0169] Determining the amount of data routed to different paths can include one or more of the following behaviors: WTRU determines the conditions under which data can (e.g., begin) be emitted to one or more paths or not (e.g., in terms of the amount of buffered data); WTRU determines the amount of data to be emitted to one or more paths (e.g., the exact amount); WTRU determines which path(s) to emit data to first; WTRU determines which path(s) to prioritize; or WTRU determines what data (what type of data) to emit to one or more paths.

[0170] For example, the WTRU can determine which paths(s) to transmit RRC messages (e.g., if the SRB is a segmented bearer). For example, the WTRU can determine which paths(s) to transmit control PDUs (e.g., PDCP control PDUs, MAC CEs, etc.) for a given protocol layer. For example, the WTRU can determine which paths(s) to transmit data PDUs that include additional QoS indications (such as additional QoS indications (e.g., PSDBs, or those associated with other XR-related information)).

[0171] A remote WTRU can determine data routing rules associated with transmitting data to multiple indirect paths. Data routing rules can be based on one or more of the following factors: the number of hops associated with one or more indirect paths; the cell ID associated with one or more relays on one or more indirect paths (e.g., relative to the cell ID associated with a direct path); the amount of data buffered at the WTRU (e.g., possibly associated with a specific bearer); the data type (e.g., in terms of bearer type and / or additional information provided by Packet Data Units (PDUs); measurements of channel quality (e.g., Reference Signal Received Power (RSRP)) or congestion (e.g., CBR) on one or more paths or sidelinks; information provided by one or more relay WTRUs on one or more paths (e.g., measurements, failure indications, notifications, buffer occupancy, flow control); DRX configuration on the path; carriers through which the WTRU can communicate on a particular path (e.g., number, nature, relationship between different paths); or the number of SL paths.

[0172] Data routing rules can be based on the number of hops associated with one or more indirect paths. The remote WTRU can determine the number of hops associated with each indirect hop based on indications from the relay WTRU itself and / or upper-layer configuration. The remote WTRU can determine routing rules for data that depend on the number of hops associated with one or more indirect paths. If a particular indirect path has a shorter number of hops than one or more other paths (e.g., any other path), the remote WTRU can determine that particular indirect path is considered the anchor path (e.g., data transmission for the bearer can be performed first on this path and can be performed on other paths after conditions are met). If one of the paths is a direct path (e.g., a direct SL path), the remote WTRU can determine that this path can be considered the anchor path. The remote WTRU can determine the amount of data or the ratio of data to be routed to that path based on the number of hops associated with the path. Specifically, for each number of hops associated with the path, the WTRU can be (pre)configured to (pre-)specify the ratio of data that could be used for a given bearer to be routed to that path.

[0173] Data routing rules can be based on cell IDs associated with one or more relays on an indirect path (e.g., relative to cell IDs associated with a direct path). A remote WTRU can determine routing rules that depend on the cell IDs of relays serving the remote WTRU that it may have with the network or destination WTRU (e.g., relative to other relays, relative to the direct path). For example, if a WTRU has a direct path to the same cell as a relay serving on an indirect path, the remote WTRU can determine that the indirect path can be considered an anchor path (e.g., for any bearer that can be configured only on the indirect path). For example, if there is at least one indirect path with a relay controlled by the same cell as a cell on the direct path, the remote WTRU can determine that an anchor path should be determined (e.g., by the remote WTRU). For example, the remote WTRU can determine different routing rules (e.g., different bearer segmentation thresholds, different ratios of data to be sent to the path) based on whether the path and / or bearer are associated with a relay having the same cell ID as the path associated with the anchor path, or with a cell on the direct path. For example, the remote WTRU can use the examples described herein to determine the anchor path. A remote WTRU can transmit (e.g., for a specific bearer) data to paths (e.g., all paths) that have relays connected to cells that are the same as the anchor path (regardless of the buffer state at the WTRU). If the amount of data on a path may exceed a threshold, the remote WTRU can transmit data to paths where cells may not be the same as the anchor path.

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

[0175] Data routing rules can be based on the type of data (e.g., in terms of bearer type or utilizing additional information provided by the PDU). A WTRU can use a first routing rule for the SRB and a second routing rule for the DRB. A WTRU can be configured with one or more paths that allow the transmission of data that meets a certain condition (e.g., the PSDB is less than a threshold) (e.g., another condition derived from another factor).

[0176] Data routing rules can be based on measurements of channel quality (e.g., RSRP) or congestion (e.g., CBR) on one or more paths or sidelinks. Routing rules / decisions can (e.g., may further) depend on sidelink RSRP measured on a particular path, relative sidelink RSRP between paths, etc.

[0177] Data routing rules can be based on information provided by one or more relay WTRUs on one or more paths (e.g., measurements, failure indications, notifications, buffer occupancy, flow control, etc.). One or more relay WTRUs can provide this information about subsequent hops. A WTRU can determine the anchor path as the path with the shortest buffer occupancy, minimum flow control constraints, and / or best average measurements (e.g., for multipaths) (e.g., as indicated by the relay WTRU on that path). If a WTRU receives a notification message associated with the first path (e.g., HO, Uu RLF, next-hop radio link failure (RLF), etc.), the WTRU can change the anchor path from the first path to a second path.

[0178] Data routing rules can be based on DRX configurations on a path. The WTRU can determine the anchor path based on whether a DRX is configured on that path. If no DRX is configured on a path, the WTRU can select that path as the anchor path. The WTRU can determine (e.g., for a specific bearer) the rate of data to be transmitted on a path based on whether a DRX is configured on that path. For example, the WTRU can be configured with a formula to determine the rate of data to be transmitted on a path, which depends on the total number of paths and whether a DRX is configured on that path. The WTRU can determine the rate of data to be transmitted on a path based on DRX configuration. The WTRU can be configured with a formula for the rate of data transmitted on a path, which depends on DRX configuration parameters (e.g., DRX period, on-time duration, etc.).

[0179] Data routing rules can be based on carriers that the WTRU can communicate through on a specific path (e.g., number, nature, relationship between different paths). The WTRU can determine the anchor path based on the relationship between carriers configured for that path and / or other paths. For example, the WTRU can determine the anchor path as a path configured with carriers to be used for transmissions to (e.g., all) other paths or a maximum number of other paths.

[0180] Data routing rules can be based on the number of SL paths. For example, a rule used to determine the ratio of data to be broadcast to a given path can depend on the number of paths. For instance, the rules in this paper (e.g., rules for determining anchors based on hop count) can be further defined by the number of paths associated with the hop count.

[0181] This article provides one or more features associated with data segmentation between direct and indirect paths. A remote WTRU in a multipath can determine the amount of data routed to each of the direct and indirect paths based on multiple available paths and / or flow control indications from relay WTRUs on each indirect path.

[0182] A remote WTRU can be configured in a multipath with a primary path via Uu and non-primary paths via one or more indirect / relay paths. The remote WTRU can be configured with a segmented bearer that can transmit data via either the primary or non-primary path. The remote WTRU can be configured with a percentage of data segmentation between the primary and non-primary paths. The percentage segmentation of data can be configured for the number of available indirect paths (e.g., for each number) and / or (e.g., by the congestion level indicated by each relay WTRU on the indirect path) (one or more). The remote WTRU can be configured with an evaluation window.

[0183] A remote WTRU can receive one or more flow control messages from each of the relay WTRUs on an indirect path. Each of the flow control messages (e.g., each of the flow control messages) can indicate one of a plurality of flow control levels. The remote WTRU can select a configured data segmentation based on the number of available paths and / or the flow control level on each path (e.g., a table can map the number of paths and / or the flow control indications on each path to data segments). The remote WTRU can transmit (e.g., broadcast) data (e.g., on an evaluation window) based on the selected data segmentation for segmented bearers to the primary and non-primary paths. In cases where data segmentation cannot be satisfied (e.g., CBR limitations), the remote WTRU can notify the network.

[0184] A remote WTRU can measure the proportion / percentage of data transmitted via multiple paths. A remote WTRU can ensure that a configured / desired proportion / percentage of data is transmitted through each of the direct and indirect paths (e.g., the proportion of data routed to each of the indirect paths in the case of multiple indirect paths). A remote WTRU can ensure the average proportion, or it can ensure that the proportion is met within a sampling window. Within a configured time window, the WTRU can ensure that multiple packets with a (pre)configured proportion are transmitted on the direct path, and the remaining packets are transmitted on the indirect paths.

[0185] A remote WTRU can determine a ratio / percentage when multiple indirect paths exist. A remote WTRU can determine the ratio of data routed to each of the direct or indirect paths. A remote WTRU can determine the percentage of data (e.g., routed) on direct and indirect paths based on (e.g., as described herein) one or more conditions associated with the indirect paths. A remote WTRU can be configured with multiple direct / indirect data ratios to be applied to a single end-to-end bearer. A remote WTRU can be configured with one or more direct / indirect data ratios on multiple bearers (e.g., all bearers). A remote WTRU can determine the number of available indirect paths as the number of configured indirect paths. If the number of configured paths is a first number or within a first range, the remote WTRU can apply a first direct / indirect data ratio. If the number of configured paths is a second number or within a second range, the remote WTRU can apply a second direct / indirect data ratio.

[0186] A remote WTRU (e.g., in a multi-hop configuration) can determine the number of available indirect paths as the number of distinct paths to which the remote WTRU can send data (e.g., bearer-specific) (e.g., where paths consist of sequences of PC5-RRC connections on multiple hops of a relay WTRU). For example, different paths can be associated with different L2 ID sequences, different local WTRUID sequences, or path IDs, etc. (e.g., some overlap within the path with relays). If the number of configured paths is a first number or within a first range, the remote WTRU can apply a first direct / indirect data ratio. If the number of configured paths is a second number or within a second range, the remote WTRU can apply a second direct / indirect data ratio.

[0187] The remote WTRU can determine the number of available indirect paths as the number of configured indirect paths that are activated (e.g., via activation at the remote WTRU or via activation over the network). If the number of configured paths is a first number or within a first range, the remote WTRU can apply a first direct / indirect data ratio. If the number of configured paths is a second number or within a second range, the remote WTRU can apply a second direct / indirect data ratio.

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

[0189] The remote WTRU can 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 that transmissions will be constrained to that particular path (e.g., no indication of any need for it) or have a flow control level below a certain threshold. If the number of relay paths with flow control below the threshold is a first value or within a first value range, the remote WTRU can apply a first direct / indirect data ratio. If the number of relay paths with flow control below the threshold is a second value or within a second value range, the remote WTRU can apply a second direct / indirect data ratio.

[0190] A remote WTRU can determine the direct / indirect data ratio based on a function from the flow control level of one or more SL trunk paths (e.g., each of the SL trunk paths). For example, the function could be the minimum, maximum, or average value of paths with values ​​above a threshold. The WTRU can 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 the direct and indirect paths.

[0191] Remote WTRUs can report the percentage / proportion of unmet expectations / configurations. Due to limitations in other configurations (e.g., maximum number of resources used on indirect paths, RLF status on indirect paths, flow control on indirect paths, etc.), a remote WTRU may be unable to meet the configured percentage. Remote WTRUs can report failures to the network (e.g., after a lag, such as if the failure persisted for a period of time). WTRUs can report statistics and / or reasons for not meeting the expected ratio to the network.

[0192] This document provides one or more features associated with the activation of indirect paths. Remote WTRUs can enable / disable SL-DRX on links with relay WTRUs based on buffer status and / or flow control indications from one or more relays (e.g., each of the relays).

[0193] A remote WTRU can be configured with at least two indirect paths (e.g., via different relays). A remote WTRU can be configured with percentage data segmentation across multiple indirect paths. A remote WTRU can be configured with percentage data segmentation for combinations of flow control levels that can be indicated by one or more relay WTRUs (e.g., each combination). A remote WTRU can be configured with buffer thresholds for SL-DRX enabled / disabled.

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

[0195] A remote WTRU can determine whether DRX is enabled or disabled (e.g., based on the actual buffer state being above / below a configured threshold). When the buffer state is above the threshold for at least period X and DRX is enabled, the remote WTRU can send (e.g., transmit) a DRX-disabled indication to the relay WTRU. When the buffer state is below the threshold for at least period Y and DRX is disabled, the remote WTRU can send (e.g., transmit) a DRX-enabled indication to the relay WTRU.

[0196] A remote WTRU can enable / disable DRX based on determining each transmission (e.g., transmit) in the relay. A remote WTRU can also transmit (e.g., transmit) data buffered for each indirect path to the associated relay.

[0197] The remote WTRU can activate / deactivate indirect paths. If it is configured with one or more indirect paths via different relays (e.g., multiple indirect paths), the remote WTRU can activate / deactivate the indirect paths. Activation / deactivation can include one or more of the following: whether data can be transmitted via a specific SL path; whether SL DRX can be configured / operated on a specific SL path; changes to the SL DRX configuration on a specific path; or changes to the PC5 configuration on a specific path.

[0198] Activation / deactivation can include changes to whether data (e.g., data associated with a specific bearer) can be transmitted via a particular SL path. In the example, the WTRU can maintain a PC5-RRC connection with the relay WTRU, but can avoid transmitting data destined for the network via a deactivated SL path (e.g., until such an SL path can be activated). Activation / deactivation can include changes to whether an SL DRX can be configured / operated on a particular SL path. Activation / deactivation can include changes to the SL DRX configuration on a particular path. In the example, an activated SL path can be associated with a first SL DRX configuration, and a deactivated path can be associated with a second SL DRX configuration. Activation / deactivation can include changes to PC5 configuration on a particular path, such as LCH configuration, MAC configuration, PHY configuration, etc.

[0199] Activating / deactivating an SL path can involve sending (e.g., transmitting) a PC5-RRC message to a relay WTRU (e.g., to change DRX configuration) or to a MAC CE. Activating / deactivating an SL path can also include routing multipath data (e.g., bearer-associated data) to the SL path without traversing a relay (e.g., a deactivated relay).

[0200] This document provides one or more characteristics associated with the conditions / triggers for activating / deactivating direct paths. A remote WTRU can activate / deactivate a direct path based on one or more of the following conditions: bearer QoS; hop count; flow control; data arrival; SL measurement; sensing results; measurement / experienced latency; messages received from a relay WTRU; path redundancy; network signaling; measurement time; or Uu measurement (e.g., Uu RSRP).

[0201] A remote WTRU can activate / deactivate a direct path based on one or more conditions related to bearer QoS. For example, activation / deactivation may be permitted by the WTRU if it can be configured to allow activation / deactivation of one or more bearers, which may be based on other conditions. For example, activation / deactivation may be permitted if (e.g., only if) the data of the configured one or more bearers is available for transmission. For example, activation / deactivation may depend on bearer characteristics (e.g., maximum bit rate).

[0202] Remote WTRUs can activate / deactivate direct paths based on one or more hop count-related conditions. For example, activation / deactivation of an SL path may occur if the number of hops associated with it is higher / lower than a threshold. Similarly, activation / deactivation of another SL path may occur if the number of hops associated with it is higher / lower than a threshold.

[0203] Remote WTRUs can activate / deactivate direct paths based on one or more flow control-related conditions. For example, activation / deactivation of SL paths may occur if the flow control level of a path is below / above a threshold. Similarly, activation / deactivation of SL paths may occur if the flow control levels of other SL paths (possibly in combination) reach a threshold.

[0204] Remote WTRUs can activate / deactivate direct paths based on one or more conditions related to data arrival. For example, if the WTRU receives a set of XR PDUs that may have a certain PSDB, activation / deactivation of the SL path may occur. Similarly, if the WTRU receives a PDU burst, activation / deactivation of the SL path may occur.

[0205] A remote WTRU can activate / deactivate a direct path based on one or more conditions associated with SL measurements (e.g., CBR, CR, RSRP, CQI, etc.). For example, activation / deactivation can occur / can be allowed if the WTRU detects a condition associated with any SL measurement (e.g., CBR, CR, RSRP, CQI, etc.) associated with that SL path or other SL paths.

[0206] Remote WTRUs can activate / deactivate direct paths based on one or more conditions related to sensing results. For example, activation / deactivation can occur based on sensing results such as preemption being detected, conditions regarding the amount of available resources, etc.

[0207] A remote WTRU can activate / deactivate a direct path based on one or more conditions associated with the measurement / experienced latency. For example, a remote WTRU can determine or (e.g., receive from a network or peer WTRU) the measurement / experienced latency associated with a packet / PDU and can activate / deactivate the SL path in response.

[0208] A remote WTRU can activate / deactivate a direct path based on one or more conditions associated with a message received from a relay WTRU. For example, after receiving a message (such as HO, RLF indication, RRC failure, etc.) from a relay WTRU on this path or another path, a remote WTRU can deactivate the SL path, possibly for a period of time.

[0209] A remote WTRU can activate / deactivate a direct path based on one or more conditions related to path redundancy. For example, a remote WTRU can activate / deactivate a path based on the redundancy associated with another path compared to another path. For example, in a multi-hop scenario, a remote WTRU can determine the number of common links (i.e., relays) on two paths to determine a metric for path redundancy.

[0210] Remote WTRUs can activate / deactivate direct paths based on one or more conditions related to network signaling. For example, the network can explicitly trigger activation / deactivation at the remote WTRU. Alternatively, the network can configure the remote WTRU to perform activation / deactivation of one or more of the aforementioned conditions.

[0211] Remote WTRUs can activate / deactivate direct paths based on one or more conditions related to the measurement time. For example, activation / deactivation can be applied to the SL path for a period of time, possibly when the conditions can be met. For instance, activation / deactivation can be initiated when the conditions have been met for a period of time, or some time after the conditions have been detected.

[0212] A remote WTRU can be configured with a buffer threshold (e.g., for one DRB or all DRBs, it can control the enabling / disabling of DRX on one or more SL indirect paths). A WTRU can be configured with a buffer threshold applicable to enabling / disabling one or more specific SL paths. If the buffer state at the remote WTRU is above the threshold (e.g., for a (pre)configured amount of time), the remote WTRU can disable SL DRX on one or more SL paths. If the buffer state at the remote WTRU is below the threshold (e.g., for a (pre)configured amount of time), the remote WTRU can enable SL DRX on one or more SL paths. A remote WTRU can be configured with the number of SL paths, the proportion of SL paths, and / or a maximum / minimum number of SL paths to activate / deactivate based on the corresponding value of the buffer state 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 the number of available indirect paths. The device may select a segmented bearer threshold based on the determined number of available indirect paths. The device may determine whether the amount of data available for transmission exceeds the selected segmented bearer threshold. Based on the determination that the amount of data available for transmission exceeds the selected segmented bearer threshold, the device may determine the path to use. The device may use the determined path to transmit data.

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

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

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

[0217] While the implementation described herein may take into account 3GPP-specific protocols, it should be understood that the implementation described herein is not limited to this scenario and can be applied to other wireless systems. For example, although the solution described herein takes into account LTE, LTE-A, New Radio (NR), or 5G-specific protocols, it should be understood that the solution described herein is not limited to this scenario and can be applied to other wireless systems.

[0218] The processes described above can be implemented in computer programs, software, and / or firmware incorporated in computer-readable media for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as, but not limited to, internal hard disks and removable disks), magneto-optical media, and / or optical media (such as compact optical disc (CD)-ROMs and / or digital versatile discs (DVDs)). The processor associated with the software can be used to implement a radio frequency transceiver used in WTRUs, terminals, base stations, RNCs, and / or any host computer.

Claims

1. A wireless transmit / receive unit (WTRU), the WTRU comprising: The processor is configured as follows: Receive configuration information, wherein the configuration information indicates a first segmented bearer threshold associated with a first number of available indirect paths and a second segmented bearer threshold associated with a second number of available indirect paths; Determine the number of available indirect paths, where the number of available indirect paths is either a first number of available indirect paths or a second number of available indirect paths; Select the first segmentation carrying threshold when the number of available indirect paths is the first number of available indirect paths. Select the second segmentation bearer threshold when the number of available indirect paths is the second number of available indirect paths. The path is determined based on whether the amount of data available for transmission exceeds the selected first segment bearer threshold or the selected second segment bearer threshold; and Use the determined path to send data.

2. The WTRU according to claim 1, wherein, The processor is further configured to: The amount of data available for transmission is determined to be higher than either the first segment bearer threshold or the second segment bearer threshold; and Based on the determination that the amount of data available for transmission is higher than the first segmentation bearer threshold or the second segmentation bearer threshold, it is determined that an indirect path will be used.

3. The WTRU according to claim 1, wherein, The processor is further configured to: Determine that the amount of data available for transmission is equal to or less than the first segment bearer threshold or the second segment bearer threshold; and Based on the determination that the amount of data available for transmission is equal to or less than the first segmented bearer threshold or the second segmented bearer threshold, the direct path is determined to be used.

4. The WTRU according to any one of claims 1 to 3, wherein, The number of available indirect paths is determined based on at least one of the following: the number of indirect paths that do not have a signaled pending path failure status; or the number of indirect paths that do not have a unicast-side link discontinuous reception (SL DRX) configuration.

5. The WTRU according to any one of claims 1 to 4, wherein, The processor is further configured to: Receive failure notifications associated with indirect paths from the relay WTRU; and Whether the indirect path is an available indirect path is determined based on the received failure notification.

6. The WTRU according to any one of claims 1 to 5, wherein, The processor is further configured to: Receive unicast SL DRX configuration associated with the indirect path from the relay WTRU; and Whether the indirect path is an available indirect path is determined based on the received unicast SL DRX configuration.

7. The WTRU according to any one of claims 1 to 6, wherein, The first segmentation bearer threshold is a first threshold data amount allowed to transmit data using an indirect path from a first number of available indirect paths, and the second segmentation bearer threshold is a second threshold data amount allowed to transmit data using an indirect path from a second number of available indirect paths.

8. A method associated with a wireless transmit / receive unit (WTRU), the method comprising: Receive configuration information, wherein the configuration information indicates a first segmented bearer threshold associated with a first number of available indirect paths and a second segmented bearer threshold associated with a second number of available indirect paths; Determine the number of available indirect paths, where the number of available indirect paths is either a first number of available indirect paths or a second number of available indirect paths; Select the first segmentation carrying threshold when the number of available indirect paths is the first number of available indirect paths. Select the second segmentation bearer threshold when the number of available indirect paths is the second number of available indirect paths. The path is determined based on whether the amount of data available for transmission exceeds the selected first segment bearer threshold or the selected second segment bearer threshold; and Use the determined path to send data.

9. The method of claim 8, further comprising: Determine that the amount of data available for transmission is higher than the first segment bearer threshold or the second segment bearer threshold; as well as Based on the determination that the amount of data available for transmission is higher than the first segmentation bearer threshold or the second segmentation bearer threshold, it is determined that an indirect path will be used.

10. The method of claim 8, further comprising: Determine whether the amount of data available for transmission is equal to or less than the first segment bearer threshold or the second segment bearer threshold; as well as Based on the determination that the amount of data available for transmission is equal to or less than the first segmented bearer threshold or the second segmented bearer threshold, the direct path is determined to be used.

11. The method according to any one of claims 8 to 10, wherein, The number of available indirect paths is determined based on at least one of the following: the number of indirect paths that do not have a signaled pending path failure status; or the number of indirect paths that do not have a unicast-side link discontinuous reception (SL DRX) configuration.

12. The method according to any one of claims 8 to 11, further comprising: Receive failure notifications associated with indirect paths from the relay WTRU; as well as Whether the indirect path is an available indirect path is determined based on the received failure notification.

13. The method according to any one of claims 8 to 12, further comprising: Receive unicast SL DRX configuration associated with the indirect path from the relay WTRU; as well as Whether the indirect path is an available indirect path is determined based on the received unicast SL DRX configuration.

14. The method according to any one of claims 8 to 13, wherein, The first segmentation bearer threshold is a first threshold data amount allowed to transmit data using an indirect path from a first number of available indirect paths, and the second segmentation bearer threshold is a second threshold data amount allowed to transmit data using an indirect path from a second number of available indirect paths.

15. A wireless transmit / receive unit (WTRU), the wireless transmit / receive unit (WTRU) comprising: The processor is configured as follows: Receive indications for multiple indirect paths, each of which is associated with a corresponding relay WTRU; Determine that the indirect path among the plurality of indirect paths is an anchor path; and If the data volume is lower than the anchor path data threshold, then the anchor path is used to send the data.

16. A method associated with a wireless transmit / receive unit (WTRU), the method comprising: Receive indications for multiple indirect paths, each of which is associated with a corresponding relay WTRU; Determine that the indirect path among the plurality of indirect paths is an anchor path; and If the data volume is lower than the anchor path data threshold, then the anchor path is used to send the data.

17. A wireless transmit / receive unit (WTRU), the wireless transmit / receive unit (WTRU) comprising: The processor is configured as follows: Receive instructions for the main path and multiple available indirect paths; The data segmentation is selected based on the number of available indirect paths and the corresponding flow control level associated with each of the available indirect paths. as well as Data is sent using the main path and the plurality of available indirect paths, wherein the data is sent based on the data segmentation.

18. A method associated with a wireless transmit / receive unit (WTRU), the method comprising: Receive instructions for the main path and multiple available indirect paths; The data segmentation is selected based on the number of available indirect paths and the corresponding flow control level associated with each of the available indirect paths. as well as Data is sent using the main path and the plurality of available indirect paths, wherein the data is sent based on the data segmentation.

19. A wireless transmit / receive unit (WTRU), the wireless transmit / receive unit (WTRU) comprising: The processor is configured as follows: Receive an indication of a first indirect path associated with a first trunk, wherein the DRX associated with the first trunk 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 the buffer state associated with the first indirect path with a buffer threshold; and A DRX indication is sent to a first relay using a first indirect path, wherein the DRX indication indicates whether DRX associated with the first relay is disabled.

20. A method associated with a wireless transmit / receive unit (WTRU), the method comprising: Receive an indication of a first indirect path associated with a first trunk, wherein the DRX associated with the first trunk 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 the buffer state associated with the first indirect path with a buffer threshold; and A DRX indication is sent to a first relay using a first indirect path, wherein the DRX indication indicates whether DRX associated with the first relay is disabled.

Images