Methods, architectures, devices and systems for congestion control in multipath sidelink relays

Abstract

Processes, methods, architectures, devices, systems, apparatuses, and computer program products relating to congestion control in multipath sidelink relays are described herein. According to an embodiment, a method implemented in a wireless transmit / receive unit (WTRU) includes transmitting data for a separate bearer associated with a link to a base station and a sidelink to a relay WTRU. The data may include first data that may be transmitted over the sidelink using a first set of congestion control parameters. The method may include determining that a quality degradation occurs on a link to a base station. The method may include transmitting additional data for the split bearers. In various embodiments, the additional data may include second data that may be transmitted via the sidelink using a second set of congestion control parameters based on a determination that a quality degradation occurs on the link to the base station.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This patent application claims the benefit of U.S. patent application No. 63 / 358,586, filed on July 6, 2022, which is incorporated herein by reference. Technical Field

[0003] The present disclosure relates generally to the fields of communications, software, and coding, including, for example, methods, architectures, devices, and systems related to congestion control in multipath sidelink relays. Background Art

[0004] The 3rd Generation Partnership Project (3GPP) Release 17 introduced sidelink (SL) relaying to extend network coverage. For example, wireless transmit / receive unit (WTRU) to network relaying can be used for this purpose. Summary of the invention

[0005] Methods, architectures, devices, and systems related to congestion control in a multipath sidelink relay are described herein. In an embodiment, a method implemented in a WTRU is described herein. The method may include transmitting data for a separate bearer associated with a link to a base station and a sidelink to a relay WTRU. In various embodiments, the data may include first data that may be transmitted via the sidelink using a first set of congestion control parameters. The method may include determining that quality degradation has occurred on the link to the base station. The method may include transmitting additional data for the separate bearer. In various embodiments, the additional data may include second data, which may be transmitted via the sidelink using the second set of congestion control parameters based on determining that quality degradation has occurred on the link to the base station.

[0006] In an embodiment, a WTRU is described herein, the WTRU comprising a processor and a transmitter and a receiver (e.g., a transceiver) operably coupled to the processor. The WTRU may be configured to transmit data for a separate bearer associated with a link to a base station and a side link to a relay WTRU. In various embodiments, the data may include first data that may be transmitted via the side link using a first set of congestion control parameters. The WTRU may be configured to determine that quality degradation occurs on the link to the base station. The WTRU may be configured to transmit additional data for the separate bearer. In various embodiments, the additional data may include second data, which may be transmitted via the side link using the second set of congestion control parameters based on determining that quality degradation occurs on the link to the base station. In various embodiments, the second data may be associated with a second grant for a second side link transmission, and the second side link transmission associated with the second grant may be limited to transmission of a second set of logical channels associated with the second set of congestion control parameters. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] A more detailed understanding may be obtained from the following detailed description given by way of example in conjunction with the accompanying drawings. As with the detailed description, each of the figures in such drawings is an example. Therefore, the figures (figures) and detailed description should not be considered limiting, and other equally effective examples are possible and possible. In addition, the same reference numerals ("labels") in the various figures indicate the same elements, and wherein:

[0008] Figure 1A is a system diagram illustrating an example communication system;

[0009] Figure 1B It shows that it can be Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within a communication system is shown;

[0010] Figure 1C It shows that it can be Figure 1A A system diagram of an example radio access network (RAN) and an example core network (CN) used within the illustrated communication system;

[0011] Figure 1D It shows that it can be Figure 1A A system diagram of yet another example RAN and yet another example CN used within the communication system shown;

[0012] Figure 2 is a system diagram illustrating an example of a user plane protocol stack for a Layer 2 (L2) WTRU to Network (U2N) relay;

[0013] Figure 3is a system diagram illustrating an example of a control plane protocol stack for an L2 U2N relay;

[0014] Figure 4 is a diagram illustrating an example method for congestion control in a multipath sidelink relay;

[0015] Figure 5 is a diagram illustrating an example method for congestion control in a multipath sidelink relay;

[0016] Figure 6 is a diagram illustrating an example method for SL channel busy rate (CBR) reporting; and

[0017] Figure 7 is a diagram of an example method for changing a set of congestion control parameters based on receiving multipath information. DETAILED DESCRIPTION

[0018] In the following detailed description, many specific details are set forth to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it will be understood that such embodiments and examples can be practiced without some or all of the specific details set forth herein. In other cases, well-known methods, programs, components and circuits are not described in detail to avoid blurring the following description. In addition, the embodiments and examples not specifically described herein can replace the embodiments and other examples explicitly, implicitly and / or inherently described, disclosed or otherwise provided (collectively referred to as "providing") herein to practice or practice in combination with them. Although various embodiments in which equipment, systems, devices, etc. and / or any of its elements perform operations, processes, algorithms, functions, etc. and / or any part thereof are described and / or claimed herein, it should be understood that any embodiment described and / or claimed herein assumes that any equipment, systems, devices, etc. and / or any of its elements are configured to perform any operations, processes, algorithms, functions, etc. and / or any part thereof.

[0019] Exemplary Communication System

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

[0021] Figure 1Ais a system diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content by sharing system resources (including wireless broadband). 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 (ZT) unique word (UW) discrete Fourier transform (DFT) spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), etc.

[0022] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104 / 113, a core network (CN) 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110 and other networks 112, but it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include (or be) a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of an industrial and / or automated process chain), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, 102d may be interchangeably referred to as a UE.

[0023] The communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d, for example, to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or the network 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B (NB), an eNode-B (eNB), a master Node B (HNB), a master eNode-B (HeNB), a gNode-B (gNB), a NR Node B (NR NB), a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

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

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

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

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

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

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

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

[0031] Figure 1A The base station 114b in the example may be, for example, a wireless router, a master Node-B, a master eNode-B, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business location, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, and the like. In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-a, LTE-a Pro, NR, etc.) to establish any of a small cell, a pico cell, or a femto cell. As Figure 1A As shown, base station 114b may be directly connected to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106 / 115.

[0032] The RAN 104 / 113 may be in communication with the CN 106 / 115, which may be any type of network configured to provide voice, data, applications and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calls, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although Figure 1ANot shown, but it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT or a different RAT as the RAN 104 / 113. For example, in addition to being connected to the RAN 104 / 113, which may be utilizing an NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) that employs any of GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or Wi-Fi radio technologies.

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

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

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

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

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

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

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

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

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

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

[0043] The processor 118 may also be coupled to other components / peripherals 138, which may include one or more software and / or hardware modules / units that provide additional features, functionality, and / or wired or wireless connectivity. For example, the components / peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (e.g., for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, module, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, etc. Components / peripherals 138 may include one or more sensors, which may be gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

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

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

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

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

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

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

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

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

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

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

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

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

[0056] When using the 802.11ac infrastructure mode of operation or a similar mode of operation, the AP can send beacons on a fixed channel, such as a primary channel. The primary channel can be a fixed width (e.g., a 20 MHz wide bandwidth) or a width dynamically set via signaling. The primary channel can be an operating channel of the BSS and can be used by STAs to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access-collision avoidance (CSMA / CA) can be implemented, for example, in an 802.11 system. For CSMA / CA, STAs (e.g., each STA) including the AP can sense the primary channel. If the primary signal is sensed / detected by a particular STA and / or is determined to be busy, the particular STA can back off. One STA (e.g., only one station) can transmit in a given BSS at any given time.

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

[0058] Very high throughput (VHT) STA can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz and / or 80MHz channels can be formed by combining continuous 20MHz channels. A 160MHz channel can be formed by combining 8 continuous 20MHz channels, or by combining two discontinuous 80MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, the data can be passed through a fragment parser after channel coding, which can divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing can be performed on each stream respectively. The stream can be mapped to two 80MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above-mentioned operation of the 80+80 configuration can be reversed, and the combined data can be sent to a media access control (MAC) layer, an entity, etc.

[0059] 802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah relative to those channel operating channels and carriers used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz and 20MHz bandwidths in TV white space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz and 16MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support meter type control / machine type communication (MTC), such as MTC devices in macro coverage. MTC devices may have certain capabilities, for example, limited capabilities, including support for (e.g., only support for) certain and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

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

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

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

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

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

[0065] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without also having access to other RANs (e.g., such as the eNode Bs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchors. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRU 102a, 102b, 102c may communicate / connect with the gNB 180a, 180b, 180c while also communicating / connecting with another RAN (such as the eNode-B 160a, 160b, 160c). For example, the WTRU 102a, 102b, 102c may implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNode-B 160a, 160b, 160c may serve as a mobility anchor for the WTRU 102a, 102b, 102c, and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput to serve the WTRU 102a, 102b, 102c.

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

[0067] Figure 1DThe illustrated CN 115 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least two session management functions (SMFs) 183a, 183b, and at least one data network (DN) 185a, 185b. Although each of the foregoing elements is depicted as part of the CN 115, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

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

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

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

[0072] Given that Figures 1A to 1D and Figures 1A to 1D 102a to 102d, base stations 114a to 114b, eNode-Bs 160a to 160c, MMEs 162, SGWs 164, PGWs 166, gNBs 180a to 180c, AMFs 182a to 182b, UPFs 184a to 184b, SMFs 183a to 183b, DNs 185a to 185b, and / or any other elements / devices described herein. A simulation device may be one or more devices configured to simulate one or more or all of the functions described herein. For example, a simulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0073] The simulation device can be designed to implement one or more tests of other devices in a laboratory environment and / or an operator network environment. For example, one or more simulation devices can perform one or more or all functions when 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 when temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation device can be directly coupled to another device for testing purposes, and / or can use over-the-air wireless communication to perform testing.

[0074] One or more simulation devices can perform one or more (including all) functions when not implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used for testing scenarios in a test laboratory and / or a wired and / or wireless communication network that is not deployed (e.g., testing) to implement testing of one or more components. One or more simulation devices can be test equipment. The simulation device can use direct RF coupling and / or wireless communication via RF circuits (e.g., which can include one or more antennas) to transmit and / or receive data.

[0075] Throughout the embodiments described herein, the terms "base station", "network" and "gNB" are collectively referred to as "network" and may be used interchangeably to designate any network element, such as a network element acting as a serving base station. The embodiments described herein are not limited to gNBs and are applicable to any other type of serving base station.

[0076] For clarity, throughout the embodiments described herein, satisfying conditions, failing to satisfy conditions, and configuring condition parameters are described relative to thresholds (e.g., greater than or less than a threshold), values ​​(e.g., thresholds), configuration values ​​(e.g., thresholds), etc. For example, satisfying a condition may be described as being above a value (e.g., a threshold), and failing to satisfy a condition (e.g., a performance criterion) may be described as being below a value (e.g., a threshold). The embodiments described herein are not limited to threshold-based conditions. Any variety of other conditions and parameters (e.g., falling within or not falling within a value range) may be applicable to the embodiments described herein.

[0077] Throughout the embodiments described herein, (e.g., configuration) information may be described as being received by the WTRU from the network, such as through system information or via any kind of protocol message. Although not explicitly mentioned throughout the embodiments described herein, the same (e.g., configuration) information may be pre-configured in the WTRU (e.g., via any kind of pre-configuration method, such as via factory settings) so that the (e.g., configuration) information can be used by the WTRU without being received from the network.

[0078] Throughout the embodiments described herein, the expression “the WTRU may be configured with a set of parameters” is equivalent to or may be used interchangeably with “the WTRU may receive configuration information indicating a set of parameters (e.g., received from another network element (e.g., gNB)”. Throughout the embodiments described herein, the expression “the WTRU may report a measurement value”, “the WTRU may determine to report a measurement value” and “the WTRU may be configured to report a measurement value” is equivalent to or may be used interchangeably with “the WTRU may transmit (e.g., report) information indicating a measurement value”.

[0079] In the embodiments described herein, the term Uu is used to refer to any of the data, transmission, interface, characteristics, etc. associated with the (uplink / downlink) link to the base station.

[0080] 3GPP Release 17 introduces SL-based WTRU to network relay, which may be referred to herein as U2N relay WTRU. Sidelink (SL) relay is introduced to support 5G Proximity (ProSe)-based WTRU to network relay (U2N relay) functionality to provide network connectivity for (e.g., remote) WTRUs (which may be referred to herein as U2N remote WTRUs). In 3GPP Release 17, either of the Layer 2 (L2) and Layer 3 (L3) U2N relay architectures may be supported. Except for controlling the sidelink resources, the L3 U2N relay architecture may be transparent to the serving RAN of the U2N relay WTRU.

[0081] Throughout the embodiments described herein, the terms "U2N remote WTRU", "remote WTRU" and "WTRU" are collectively referred to as "remote WTRU" and may be used interchangeably to designate any WTRU that is connected to a network via a relay WTRU. Throughout the embodiments described herein, the terms "U2N relay WTRU", "relay WTRU" and "WTRU" are collectively referred to as "relay WTRU" and may be used interchangeably to designate any WTRU that is capable of relaying data between a remote WTRU and a network.

[0082] For example, a U2N relay WTRU may be in a connected state (eg, RRC_CONNECTED) to perform relaying of unicast data.

[0083] For L2 U2N relay operation, the following (e.g., RRC) state combinations may apply. For example, the U2N relay WTRU and the U2N remote WTRU may be in a connected state (e.g., RRC CONNECTED) to perform any of transmission and reception of unicast data to the relay. For example, in the case where (e.g., all) U2N remote WTRUs that may be connected to the U2N relay WTRU are in any of an inactive state (e.g., RRC_INACTIVE) and an idle state (e.g., RRC_IDLE), the U2N relay WTRU may be in an idle state (e.g., RRC_INACTIVE), an inactive state (e.g., RRC_INACTIVE), and a connected state (e.g., RRC_CONNECTED).

[0084] Two modes may be used for centralized and distributed scheduling of WTRU transmissions, which may be referred to herein as Mode 1 and Mode 2. Centralized scheduling (e.g., Mode 1) may occur at the gNB (e.g., in-coverage mode), and distributed scheduling (e.g., Mode 2) may be performed by the WTRU. In Mode 1, the WTRU may be scheduled by the gNB on dedicated radio resources for data transmission. In Mode 2, the WTRU may autonomously select radio resources from a resource pool, which may be either configured by the network or pre-configured in the WTRU.

[0085] For example, for L2 U2N relay, the U2N remote WTRU may be configured to use resource allocation mode 2 to relay data.

[0086] For example, a (e.g., single) unicast link may be established between one L2 U2N relay WTRU and one L2 U2N remote WTRU. For example, traffic of the U2N remote WTRU via the U2N relay WTRU and traffic of the U2N relay WTRU may be separated into different (e.g., Uu RLC) channels over Uu.

[0087] Example of L2 U2N relay protocol architecture

[0088] Figure 2 is a system diagram illustrating an example of a user plane protocol stack for L2 U2N relay.

[0089] Figure 3 is a system diagram illustrating an example of a control plane protocol stack for an L2 U2N relay.

[0090] like Figure 2 and Figure 3As shown, the sidelink relay adaptation protocol (SRAP) sublayer 201, 202, 203, 204, 301, 302, 303, 304 may be placed above the control position (CP) and the radio link control (RLC) sublayer of the user plane (UP) at the PC5 interface 21, 31 and the Uu interface 22, 32. The Uu service data adaptation protocol (SDAP) 207, 208, the packet data convergence protocol (PDCP) 205, 206, 305, 306 and the radio resource control (RRC) 307, 308 may terminate between the L2 U2N remote WTRU and the gNB. The SRAP, RLC, MAC and PHY may terminate at each hop (e.g., the link between the L2 U2N remote WTRU and the L2 U2N relay WTRU and the link between the L2 U2N relay WTRU and the gNB).

[0091] For L2 U2N relay, the SRAP sublayer on PC5 (e.g., hop) may be used for bearer mapping. For example, the SRAP sublayer for relaying messages for the L2 U2N remote WTRU on either the broadcast control channel (BCCH) and the physical control channel (PCCH) may not exist (e.g., not used) on PC5 (e.g., hop). For example, for messages for the L2 U2N remote WTRU on signaling radio bearer 0 (SRB0), the SRAP sublayer may not exist (e.g., not used) on PC5 (e.g., hop), and the SRAP sublayer may not exist (e.g., not used) on Uu (e.g., hop) for either the downlink (DL) and uplink (UL).

[0092] For L2 U2N relay, with respect to the uplink, the Uu SRAP sublayer may support (e.g., operate, apply) UL bearer mapping between an incoming PC5 relay RLC channel and an outgoing Uu relay RLC channel for relaying by the L2 U2N relay WTRU Uu. For uplink relay traffic, different end-to-end radio bearers (RBs), such as any of a signaling radio bearer (SRB) and a data radio bearer (DRB) of either the same remote WTRU and a different remote WTRU, may be multiplexed on the same Uu relay RLC channel.

[0093] For uplink L2 U2N relay, the Uu SRAP sublayer may support (e.g., operate, apply) L2 U2N remote WTRU identification for UL traffic. Information indicating the identity of the L2 U2N remote WTRU Uu radio bearer and information indicating the local remote WTRU identifier (ID) may be included in the Uu SRAP header at the UL so that the gNB can associate received packets for a (e.g., specific) PDCP entity associated with the corresponding Uu radio bearer of the remote WTRU.

[0094] For uplink L2 U2N relay, the PC5 SRAP sublayer at the L2 U2N remote WTRU may support (eg, operate, apply) UL bearer mapping between the remote WTRU Uu radio bearers and the outgoing PC5 relay RLC channels.

[0095] For L2 U2N relay, with respect to the downlink, the Uu SRAP sublayer may support (e.g., perform, apply) DL bearer mapping at the gNB to map (e.g., associate) the end-to-end radio bearers (SRBs, DRBs) of the remote WTRU to the Uu relay RLC channels through the relay WTRU Uu interface. For example, the Uu SRAP sublayer may support (e.g., perform, apply) any of DL bearer mapping (e.g., association) and data multiplexing between multiple end-to-end radio bearers (SRBs or DRBs) of one or more L2 U2N remote WTRUs and one Uu relay RLC channel through the relay WTRU Uu interface.

[0096] For downlink L2 U2N relay, the Uu SRAP sublayer may support remote WTRU identification for DL ​​traffic. For example, either information indicating the identity of the remote WTRU Uu radio bearer and information indicating a local remote WTRU identifier (ID) may be included in the Uu SRAP header by the gNB at the DL so that the relay WTRU may map (e.g., associate) packets received from the remote WTRU Uu radio bearer to its associated PC5 relay RLC channel.

[0097] For downlink L2 U2N relay, the PC5 SRAP sublayer at the relay WTRU may support (eg, perform, apply) DL bearer mapping (eg, association) between the incoming Uu relay RLC channel and the outgoing PC5 relay RLC channel.

[0098] For downlink L2 U2N relay, the PC5 SRAP sublayer at the remote WTRU may associate received packets for a (eg, specific) PDCP entity associated with the corresponding Uu radio bearer of the remote WTRU based on identity information that may be included in the UuSRAP header.

[0099] For example, the local remote WTRU ID may be included in any one of the PC5 SRAP header and the Uu SRAP header. For example, the L2 U2N relay WTRU may be configured by the gNB with a local remote WTRU ID to be used in the SRAP header (e.g., configuration information indicating the local remote WTRU ID may be received from the gNB). For example, the remote WTRU may obtain (e.g., receive) information indicating the local remote ID from the gNB via any Uu RRC message (e.g., any one of the RRCSetup message, the RRCReconfiguration message, the RRCResume message, and the RRCReestablishment message). For example, any one of the Uu DRB and the Uu SRB may be mapped to different PC5 relay RLC channels and Uu relay RLC channels in any one of the PC5 hop and the Uu hop.

[0100] For example, the gNB may avoid conflicts when using the Local Remote WTRU ID. The gNB may update the Local Remote WTRU ID by, for example, sending information indicating the updated Local Remote ID to the relay WTRU in a (e.g., RRCReconfiguration) message. The serving gNB may perform the Local Remote WTRU ID update independently of the PC5 unicast link L2 ID update procedure.

[0101] Multipath Example

[0102] Release 17 of the 3GPP specification introduced Layer 2 WTRU to Network Relays to address situations where a remote WTRU is out of coverage. In Release 18, multipath issues may be addressed. In multipath, a remote WTRU may (e.g., be assumed to be) in coverage and may use any combination of Uu paths and SL (relay) paths. For example, multipath may allow for enhanced reliability and throughput (e.g., by switching between multiple paths and utilizing any of the multiple paths simultaneously). For example, a WTRU may connect to the same gNB using one direct path and one indirect path via either an L2 U2N relay and another WTRU.

[0103] Example of congestion control in SL

[0104] The SL channel busy rate (CBR) may be a physical layer measurement that may be used in the SL to manage SL resource congestion. Throughout the embodiments described herein, SL CBR and CBR may be used interchangeably to refer to the side link channel busy rate. In Mode 2 (WTRU autonomous) scheduling mode, the WTRU may perform measurements of the CBR. In Mode 2 scheduling mode, the WTRU may be configured with (e.g., maximum) transmission parameter values ​​(e.g., any one of the modulation and coding scheme (MCS), Tx power, maximum number of selected subchannels) and a channel occupancy rate (CR) that may be used for transmissions associated with (e.g., specific) priorities. For example, different groups (e.g., each group) of parameters may be configured for different ranges of the measured CBR at the WTRU. In Mode 1 scheduling mode, the WTRU may be configured to report information indicating the CBR measurement value to the network, and the network may use the reported CBR measurement value to allocate an appropriate amount of SL resources for Mode 1.

[0105] Overview

[0106] In case of using mode 2, congestion control may be used to control congestion of SL resources. In multipath, for example, replication may be used to improve the reliability of transmission, and congestion control on the SL may compromise the QoS guarantees (e.g., targets) of Uu services that may be subject to higher reliability expectations. For example, the gNB may configure congestion control parameters to the WTRU in multipath, assuming that the direct Uu path may operate correctly (e.g., under normal conditions). The embodiments described herein may allow revisiting (e.g., updating) congestion control (e.g., policies, parameters) such that congestion control does not affect (e.g., impact) the reliability expectations (e.g., targets) of Uu data transmitted via the relay WTRU, for example in the context of multipath transmission and for example in the event of Uu path degradation.

[0107] In an embodiment, the remote WTRU may determine the congestion control parameters on the SL based on the Uu channel conditions.

[0108] In an embodiment, the remote WTRU may be configured in multipath to transmit data for split bearers via either Uu (direct) and sidelink (indirect to U2N relay).

[0109] In an embodiment, the remote WTRU may be configured with a first set of congestion control parameters (e.g., any of maximum SL power, maximum number of selected resources, etc.) and a second set of congestion control parameters. For example, the remote WTRU may transmit first data for a split bearer via a (e.g., first, direct) link to a base station and a (e.g., second) link (e.g., side link) to a relay WTRU, where the first data may be transmitted using a first congestion control operation mode (e.g., a first set of congestion control parameters).

[0110] In an embodiment, in the event of an event associated with Uu quality degradation (e.g., any of a Uu radio link failure (RLF), a Uu hybrid automatic repeat request (HARQ) error number, a Uu listen-before-talk (LBT) failure), the remote WTRU may transmit second data for a split bearer using a second congestion control operation mode. For example, a second set of congestion control parameters may be used for transmissions associated with a SL logical channel (LCH) mapped to (e.g., associated with) a split bearer.

[0111] Embodiments of multipath examples are described herein where a remote WTRU may transmit and receive via either a first (e.g., direct, Uu) path or a second (e.g., indirect via SL relay) path. Embodiments described herein may also be applicable to other multipath examples where, for example, more than two paths (e.g., any of multiple SL carriers) may be used, and where the remote WTRU and the relay WTRU may be connected via an ideal connection.

[0112] Example of replication decision depending on measured congestion

[0113] In an embodiment, the WTRU may determine whether to perform duplication of a protocol data unit (PDU) on multiple (e.g., more than one) paths based on measured SL congestion. For example, the WTRU may be configured with conditions that allow or do not allow (e.g., prevent) duplication. For example, the WTRU may be configured with conditions that may specify (e.g., determine) when duplication may be performed or not performed. For example, the WTRU may receive configuration information indicating conditions under which duplication may be allowed (e.g., performed) or not allowed (e.g., not performed, prevented). For example, the conditions for allowing (e.g., performing) duplication at the WTRU may also depend on other factors (e.g., parameters) described herein, such as any of the priority of the data, the configuration of the primary path of the bearer, etc.

[0114] In one example, a remote WTRU configured with multipath transmission for uplink (e.g., associated with a single bearer (e.g., a split bearer)) may perform duplication, if the measured SL CBR fails to satisfy the channel occupancy condition (e.g., is below a threshold), may perform duplication. Otherwise, for example, if the measured SL CBR satisfies the channel occupancy condition (e.g., is above a threshold), the WTRU may be prevented from duplicating PDUs (e.g., PDU duplication may be disabled) and the WTRU may be allowed to transmit on one link, e.g., only on (Uu or SL).

[0115] In another example, the number of carriers that may be used for duplication on the SL may be based on (e.g., dependent on) the measured CBR. For example, if the channel occupancy condition is met, the WTRU may determine that the number of carriers that may be used for PDU duplication may be less than or equal to (e.g., at most) a value X. In a first example, the channel occupancy condition may be met if the measured CBR is within a given CBR value range. In a second example, the channel occupancy condition may be met if the measured CBR is below a threshold.

[0116] In another example, the remote WTRU may perform data replication for the bearer based on a combination of the SL CBR and which UL path(s) (e.g., either a direct path to a base station and an indirect path via a relay) or which primary path(s) may be configured for the bearer. For example, the remote WTRU may use different (e.g., replication) congestion control behaviors based on the SL CBR of the resource pool associated with either the UL path and the primary path that may be configured to the remote WTRU. For example, the WTRU may be configured with a primary path for the bearer, or may be configured with a (e.g., default) UL path for the bearer. For example, the primary path may be used by the WTRU to send some (e.g., all) SRB data. For example, the primary path for the bearer may be used by the WTRU to send UL data until a condition is met (e.g., a (e.g., configured) buffer threshold amount is reached), after which the WTRU may use another path. For example, the UL path may be used by the WTRU to send (e.g., all) data for a (e.g., specified) DRB. For example, if the primary path for the bearer is SL, the remote WTRU may perform duplication without (e.g., independently) taking any consideration of any SL CBR. For example, if the primary path for the bearer is Uu, the remote WTRU may perform duplication if the measured CBR meets the channel occupancy condition (e.g., is below a threshold).

[0117] Embodiments of conditions based on ranges and thresholds are described herein. Any other type of condition may be applicable to the embodiments described herein, for example, any of a threshold and a range further depending on the transmission priority. For example, such a condition (e.g., any of a threshold and a range) may also be configured for each split bearer on Uu.

[0118] Example of congestion control behavior at a remote WTRU depending on Uu characteristics

[0119] Throughout the embodiments described herein, the expressions “operating with (e.g., first, second) congestion control behavior,” “transmitting using (e.g., first, second) congestion control behavior,” “transmitting using (e.g., first set, second set) congestion control operating mode,” and “transmitting using (e.g., first set, second set) congestion control parameters” may be used interchangeably to describe different sets of parameters that may be used to operate different variations of congestion control on one or more links.

[0120] In an embodiment, the WTRU may determine its congestion control behavior (e.g., to be used via the SL) based on one or more characteristics related to, for example, a Uu (direct) link (e.g., path) to the gNB. For example, the congestion control behavior determination may be performed for (e.g., only) one bearer. For example, after an event on the Uu link, the WTRU may change the congestion control behavior of a first or first group of LCHs, and the WTRU may not change the congestion control behavior of a second or second group of LCHs. For example, the congestion control behavior may be determined for a bearer configured with replication. For example, a WTRU that may, for example, perform replication on a (e.g., a specific) split bearer may determine its congestion control behavior based on one or more Uu characteristics (e.g., one or more characteristics of the link to the gNB).

[0121] The Uu characteristics that the WTRU may base its determination (eg, update) of its congestion control behavior (eg, to be used via the SL) on may include any combination of the following examples.

[0122] For example, the Uu characteristics may include Uu measurements (e.g., measurements that may be performed on the Uu link to the gNB), such as any of Uu reference signal received power (RSRP), channel quality indicator (CQI), etc. For example, in case the Uu RSRP satisfies the power condition (e.g., is above a threshold), the WTRU may operate with a first congestion control behavior (e.g., via SL), and in case the Uu RS RP fails to satisfy the power condition (e.g., is below a threshold), may operate with a second congestion control behavior (e.g., via SL).

[0123] For example, the Uu characteristics may include a Uu RLF determination. For example, the WTRU may operate with a first congestion control behavior (e.g., via SL) in the event that a Uu RLF has not been triggered (e.g., detected), and may operate with a second congestion control behavior (e.g., via SL) after a Uu RL may be triggered (e.g., detected) and / or when a Uu RLF may be suspended.

[0124] For example, the Uu characteristics may include beam failure detection (BFD). For example, the WTRU may operate with a first congestion control behavior (e.g., via SL) in the event that BFD has not been triggered (e.g., detected), and may operate with a second congestion control behavior (e.g., via SL) after BFD may have been triggered (e.g., detected) and / or when BFD may be suspended.

[0125] For example, the Uu characteristics may include Uu HARQ feedback characteristics. For example, in the event that the number of (e.g., consecutive) HARQ negative acknowledgements (NACKs) received over Uu satisfies a condition (e.g., is below a threshold), the WTRU may operate with a first congestion control behavior (e.g., via SL), and in the event that the number of (e.g., consecutive) HARQ NACKs received over Uu fails to satisfy the condition (e.g., is above a threshold), the WTRU may operate with a second congestion control behavior (e.g., via SL).

[0126] For example, the Uu characteristics may include an unlicensed spectrum channel access failure (e.g., any of Uu LBT and access to unlicensed spectrum associated with Uu). For example, in the event that the WTRU fails to successfully perform LBT (and / or in the event that the WTRU cannot access a shared channel), the WTRU may operate with a first congestion control behavior (e.g., via SL), otherwise, it may operate with a second congestion control behavior (e.g., via SL).

[0127] For example, the Uu characteristics may include a buffer status. For example, if the amount of data buffered at the WTRU (e.g., associated with one or more bearers) satisfies a filing condition (e.g., is above a threshold), the WTRU may operate with a first congestion control behavior (e.g., via SL), otherwise, it may operate with a second congestion control behavior (e.g., via SL). In a specific example, the filing condition (e.g., threshold) may be zero.

[0128] For example, the Uu characteristic may include receiving any of explicit network signaling and implicit network signaling. For example, the WTRU may operate in a first congestion control behavior (e.g., via the SL) and, after receiving any of explicit signaling and implicit signaling from the network indicating a change in congestion control behavior, may operate in (e.g., initiate, start) a second congestion control behavior (e.g., via the SL). For example, the WTRU may receive explicit information, such as an explicit indication of a change in congestion control behavior. For example, any of a dedicated MAC control element (CE), downlink control information (DCI), a radio resource control (RRC) message, etc., received by the WTRU may indicate that the WTRU changes from a first congestion control behavior to a second congestion control behavior. In another example, the WTRU may receive an implicit indication (e.g., a message), which may include a scheduling grant (e.g., a DCI), for example, which has a standard (e.g., a configuration grant with a specific value of a new data indicator (NDI)).

[0129] For example, after an event (e.g., quality degradation) occurs on Uu (e.g., RLF), a WTRU operating in a first congestion control behavior (e.g., via SL) may transition (e.g., switch) to a second congestion control behavior (e.g., via SL). After the event occurs, the WTRU may use the second congestion control behavior (e.g., via SL) until network signaling is received (e.g., an RRC reconfiguration message is received), for example, indicating a reconfiguration of a congestion control behavior associated with the first congestion control behavior.

[0130] For example, a relay WTRU may receive information from the network indicating that any of a PDU, a group of PDUs, and data associated with an LCH may be duplicated in the downlink. For example, a relay WTRU may receive information in a protocol header indicating that a PDU received at the relay may (e.g., also) be duplicated by the network on the Uu link. For example, a relay WTRU may receive information (e.g., a MAC CE) indicating that the network may have initiated duplication for one or more DL bearers over either a relay path and a direct path. Upon receiving such an indication, the relay WTRU may change to a second congestion control behavior for the duplicated data.

[0131] For example, the Uu characteristics may include (e.g., a configured amount of time (e.g., a timer)). For example, after any of the events described herein, a WTRU operating with a first congestion control behavior (e.g., via a SL) may change to a second congestion control behavior. For example, the WTRU starts a timer and may remain in the second congestion control behavior until the timer may expire. After determining that a certain amount of time has passed after starting to operate with the second congestion control behavior (e.g., upon expiration of the timer), the WTRU may switch back to the first congestion control behavior.

[0132] For example, the congestion control behavior may be based on the bearers whose data may be included in the SL transmission. For example, in the case where the SL transmission includes data from any of the first bearer and the first group of bearers, the WTRU may operate with the first congestion control behavior, and in the case where the SL transmission includes data from any of the second bearer and the second group of bearers, the WTRU may operate with the second congestion control behavior. For example, the WTRU may determine the bearers that may use the second congestion control behavior based on any of the following: (1) explicit configuration allowing such behavior, (2) whether the bearer is configured with replication, (3) whether the bearer is configured with a primary path on Uu, (4) the LCH priority configured for the bearer, (5) the packet delay budget (PDB) configured for the SL RLC bearer (e.g., compared to conditions such as a threshold), and (6) buffer status (e.g., when the Uu event may allow the use of the second congestion control behavior, the WTRU may determine whether the bearer may use the second congestion control behavior based on its buffer status (e.g., the amount of data exceeding the threshold)). For example, the WTRU may operate with a first congestion control behavior for SL data that may be directed to (eg, for) a SL WTRU, and operate with a second congestion control behavior for SL data that may include relayed Uu data.

[0133] For example, the Uu characteristics may include whether the bearer is configured with replication. For example, in the case where the SL transmission includes data from a bearer configured with replication, the WTRU may operate with a first congestion control behavior, and in the case where the SL transmission does not include data from a bearer configured with replication (e.g., the SL transmission includes data from a bearer for which replication may be prevented), the WTRU may operate with a second congestion control behavior.

[0134] For example, the Uu characteristics may include QoS parameters for the data to be transmitted. For example, in the event that the priority satisfies the priority condition (e.g., is above a threshold), the WTRU may operate with a first congestion control behavior, and in the event that the priority fails to satisfy the priority condition (e.g., is below a threshold), the WTRU may operate with a second congestion control behavior. For example, for a bearer on a multipath configured with a guaranteed bit rate (GBR) that satisfies a bit rate condition (e.g., is above a threshold), the WTRU may operate with a second congestion control behavior.

[0135] For example, the Uu characteristic may include using an exception resource pool. For example, the WTRU may initiate using an exception resource pool on the SL. In the case where a WTRU configured with multipath initiates transmission through an exception resource pool on the SL, the WTRU may initiate (e.g., transition to, switch to) using a second congestion control behavior on the SL.

[0136] For example, the Uu characteristics may include the amount of data sent on the SL compared to the Uu. For example, in the case where the ratio of data set on the SL compared to the Uu satisfies the condition, the WTRU may use (e.g., switch to) a second congestion control behavior after using the first congestion control behavior. For example, the condition may be determined to be satisfied based on either a (e.g., configured) split bearer threshold and whether the buffer status is higher than a current split bearer threshold. For example, in the case where the amount of data (e.g., threshold) routed via the relay link is greater than the amount of information routed via the Uu link, the WTRU may use the second congestion control behavior. For example, in the case where the (e.g., configured) split bearer threshold is higher than the (e.g., configured) threshold, the WTRU may use the second congestion control behavior (e.g., operate with the second congestion control behavior).

[0137] For example, the congestion control behavior may be determined based on the WTRU's power saving parameters (e.g., expectations, requirements). For example, whether the WTRU uses the second congestion control behavior or any of the above conditions may also depend on the WTRU's power saving parameters (e.g., expectations, requirements). For example, a WTRU with a power saving expectation may use the second congestion control behavior. For example, a WTRU with a power saving expectation may have more relaxed conditions associated with initiating the use of the second congestion control behavior than another WTRU without a power saving expectation. For example, the WTRU may receive information from the network indicating that the WTRU may be allowed to have a power saving expectation. The WTRU may receive an indication of a power saving expectation from an upper layer and may transmit information indicating a (e.g., newly updated) power saving expectation to the network.

[0138] Example of congestion control behavior

[0139] In various embodiments, (e.g., the first set and / or the second set) congestion control parameters may include any of the following: (i) modulation and coding scheme, (ii) transmission power, (iii) channel occupancy, and (iv) a number of retransmissions associated with a range of sidelink channel busy rates.

[0140] Congestion control behavior (eg, operating mode) according to any embodiment described herein may include any combination of the following examples.

[0141] In a first example, the congestion control behavior may include enabling and disabling any of any (eg, current) congestion parameters on the SL. For example, the WTRU may enable and disable any of congestion control for relaying data based on Uu characteristics.

[0142] In a second example, the congestion control behavior may include using a different (set of) congestion control parameters for relayed data. For example, the WTRU may use a first set of congestion control parameters for relayed data and a second set of congestion control parameters for non-relayed data. For example, any of the modulation and coding scheme (MCS), transmit (Tx) power, channel occupancy (CR), number of retransmissions, etc. within a (e.g., given) CBR range may have different values ​​for relayed data and non-relayed data.

[0143] In a third example, the congestion control behavior may include using different congestion control parameters for transmissions associated with different bearers. For example, the WTRU may use a first set of congestion control parameters to transmit first data on the SL, where the first data may be associated with any one of a first bearer and a first group of bearers, and the WTRU may use a second set of congestion control parameters to transmit second data on the SL, where the second data may be associated with any one of a second bearer and a second group of bearers.

[0144] In a fourth example, the congestion control behavior may include enabling, disabling, and using any of one or more (e.g., different) congestion control parameters (e.g., only) for certain parameters. For example, any of enabling, disabling, and using only a subset of congestion control parameters (e.g., only MCS, only maximum number of retransmissions, etc.) may be performed.

[0145] In a fifth example, the congestion control behavior may include applying different CBR metrics to determine a CBR range for applicable congestion control parameters. For example, the WTRU may apply any of a first CBR measurement value (e.g., determined on a first pool, determined within a first time period, etc.) and a second CBR measurement value. For example, the WTRU may apply or not apply an (e.g., configured) offset to the measured CBR.

[0146] Example of LCH restriction based on congestion control parameters

[0147] In an embodiment, a WTRU may be configured with a first set of LCHs that may use a first congestion control behavior (e.g., associated with a first congestion control behavior), and a second set of LCHs that may use a second congestion control behavior (e.g., associated with a second congestion control behavior). For example, the WTRU may enable logical channel priority (LCP) restrictions associated with either the first set of LCHs or the second set of LCHs. For example, in the case where a grant is used to include data from an LCH of the first set, the WTRU may (e.g., only) include data from the first set in the same grant (and / or vice versa). For example, in the case where the WTRU transmits LCH data from a first set of LCHs based on a first grant, the WTRU may transmit only data from the first set of LCHs based on the first grant (e.g., without transmitting data from the second set of LCHs). For example, in the case where the WTRU selects a first grant for transmitting data from an LCH associated with a first congestion control behavior, the WTRU may then select (e.g., only) data from an LCH associated with the first congestion control behavior (e.g., for transmission) based on (e.g., based on) the same first grant. For example, (e.g., first / second) data may be associated with a (e.g., first / second) grant for (e.g., first / second) transmission, and the (e.g., first / second) transmission associated with the (e.g., first / second) grant may be restricted to transmission of (e.g., first group / second group) of logical channels associated with the (e.g., first / second) congestion control behavior.

[0148] For example, according to any of the embodiments described herein, the WTRU may apply LCH restriction (e.g., on the SL) after an event (e.g., quality degradation) occurs on the Uu. For example, before an event (e.g., quality degradation) occurs (e.g., Uu RLF), the WTRU may use a first congestion control behavior for (e.g., all) transmissions on the SL, for example, associated with a multipath. For example, after an event (e.g., quality degradation) occurs (e.g., Uu RLF), the WTRU may be allowed to perform transmissions with a second congestion control behavior for (e.g., only) a subset of LCHs. For example, the WTRU may enable LCH restriction at this time, so that (e.g., only) LCHs that may be associated with the second congestion control behavior may be allowed to be multiplexed into a grant (e.g., multiplexed based on the grant), where any data is configured to use (e.g., allowed to use) the second congestion control behavior. For example, in the case where a transport block (TB) includes (e.g., only includes) data from an LCH associated with a second congestion control behavior (e.g., the use of the second congestion control behavior may be allowed), the WTRU may transmit the TB using the second congestion control behavior.

[0149] Example of congestion control in multipath SL relay

[0150] In an embodiment, a remote WTRU may be configured with split bearers on multiple paths (e.g., one path via Uu and one relay path via SL). For example, the WTRU may transmit first data on a path (e.g., link) to a base station and on a SL path (e.g., link) to a relay WTRU. For example, the WTRU may be configured with a first set of congestion control parameters (e.g., a normal set used under normal conditions) and a second set of congestion control parameters (e.g., used in the event that quality degradation is detected on the (e.g., Uu) link to the base station). For example, the WTRU may monitor quality degradation (e.g., Uu RLF) via a direct Uu path. For example, in the event that no quality degradation is detected (e.g., the quality of the direct Uu path meets the quality condition and the Uu path is not in RLF), the WTRU may use the first set of congestion control parameters, e.g., for multipath transmission. In the event that quality degradation (e.g., Uu RLF) is detected on the link to the base station, the remote WTRU may move (e.g., all) traffic for the split bearer to the relay path via a side link. For example, in the event that quality degradation is detected on the link to the base station (e.g., Uu RLF), the remote WTRU may operate with (e.g., begin using) a second set of congestion control parameters for transmissions on the sidelink. For example, the WTRU may also limit (e.g., constrain) the use of the second set of congestion control parameters (e.g., only) to transmissions associated with the bearer for which replication may be configured (e.g., enabled). For example, the WTRU may also limit (e.g., constrain) the use of the second set of congestion control parameters (e.g., only) to transmissions from the bearer configured to use the second set of congestion control parameters. For example, transmissions from the bearer configured to use the second set of congestion control parameters may include information such as a flag indicating that the second set of congestion control parameters may be used. In another example, the second set of congestion control parameters may be included (e.g., indicated) in the bearer configuration information that may be received by the remote WTRU.

[0151] In an embodiment, a remote WTRU may be configured with split bearers on multiple paths (one path via Uu and one relay path via SL). For example, a remote WTRU may be configured with a subset of split bearers that may have a primary path configured on Uu (e.g., a link to a base station). For example, the WTRU may perform congestion control on the SL based on a set of configured congestion control parameters. In the event that quality degradation (e.g., LBT failure) occurs (e.g., is detected) on Uu (e.g., a link to a base station), the WTRU may disable congestion control for transmissions on the SL associated with the subset of split bearers that have a primary path configured on Uu (e.g., a link to a base station).

[0152] Example of multipath data transmission using different Tx pools

[0153] In an embodiment, the WTRU may use one or more (e.g., different) subsets of SL resources to transmit data associated with multipath transmission. For example, the WTRU may be configured with a separate Tx pool and any one of one or more different resource subsets on the side link (e.g., by receiving configuration information indicating the separate Tx pool and any one of one or more different resource subsets on the side link) for transmitting data associated with multipath transmission. For example, the WTRU may be configured with different (e.g., multiple groups) of congestion control parameters associated with different pools (e.g., by receiving configuration information indicating the congestion control parameters) (wherein a set of congestion control parameters may be associated with a set of resources for SL transmission). For example, the WTRU may use any (e.g., separate) Tx resource pool for transmission based on any of the conditions for using (e.g., different) congestion control parameters described herein.

[0154] Example indicating the presence of replication (multipath) on SL transport

[0155] In an embodiment, the WTRU may transmit information indicating the presence of either multipath data or duplicated data on a side link. For example, either a relay WTRU or a remote WTRU may determine, based on the methods described herein, that data should be indicated as being duplicated on a side link. For example, the data may be associated with a bearer configured for duplication. For example, the relay WTRU may receive information indicating that the data may be associated with duplication. For example, the WTRU includes information indicating that the data may be duplicated on the SL. For example, the WTRU may transmit information indicating multipath class data (wherein the multipath class data may be associated with any condition that changes the congestion control behavior described herein, such as any of the following: (1) multipath data duplicated on two links, (2) multipath data associated with a bearer that may have a primary path on either Uu and SL, (3) multipath data associated with a bearer whose buffering (e.g., level) may satisfy a condition (e.g., above a threshold), etc.). For example, information indicating the presence of data duplication may be sent in a side link control information (SCI) (e.g., included in the side link control information). For example, the information indicating the presence of data duplication may be sent by including a SL MAC CE in a transmission on the SL. For example, the information indicating the presence of data duplication may be sent in a PC5-RRC message (e.g., sent by either of the remote WTRU and the relay WTRU to either of the relay WTRU and the remote WTRU, respectively).

[0156] Example of congestion control behavior depending on the reception of multipath class indications

[0157] In an embodiment, a (eg, first) WTRU performing transmissions on a SL may control its congestion control behavior based on information received from other (eg, second) WTRUs indicating similar multipath transmissions.

[0158] In a first example, a (e.g., first) WTRU may perform SL-only transmissions (e.g., V2X transmissions that do not relay any Uu data). The (e.g., first) WTRU may change its congestion control behavior based on information received from other (e.g., second) WTRUs indicating the presence of multipath-like transmissions (and information associated therewith). For example, the WTRU may determine whether to change its congestion control behavior based on the amount of multipath transmissions indicated, which may include any of the following:

[0159] - The SL resource occupancy (e.g., percentage occupancy) associated with the multipath class transmission satisfies a condition (e.g., is above a threshold);

[0160] -The CBR calculated based only on multipath services meets the condition (for example, is higher than the threshold);

[0161] - The SL resource occupancy (eg, percentage occupancy) associated with a multipath class transmission that may have a priority that satisfies a first condition (eg, is above a first threshold) may satisfy a second condition (eg, is above a second threshold).

[0162] In cases where relayed Uu data transmissions should be prioritized (e.g., based on some Uu condition in accordance with any of the embodiments described herein), changing the congestion control behavior as described in the first example can allow for reducing any of the transmission power, amount of resources used, etc., of SL transmissions that are not associated with relayed Uu data.

[0163] In a second example, a relay WTRU may receive information, for example in a PC5-RRC message from another WTRU (e.g., a remote WTRU), that may indicate that one or more SL data bearers may carry data that may be replicated by the remote WTRU via multipath. For example, in accordance with any of the embodiments described herein, the relay WTRU may change the congestion control behavior associated with the indicated SL bearers. This may enable multihop relaying on the SL portion of the multipath for the remote WTRU. For example, a relay WTRU on a path of a multihop relay may (e.g., consistently) change the congestion control behavior associated with the relay traffic that may be associated with the multipath data.

[0164] Example of SL CBR report triggering depending on Uu characteristics

[0165] In an embodiment, according to any embodiment described herein, the WTRU may be configured with a trigger (e.g., condition) for reporting SL CBR that may depend on any of the Uu (e.g., and SL) characteristics (e.g., receiving configuration information indicating the trigger).

[0166] In an embodiment, according to any of the embodiments described herein, the WTRU may determine one or more Uu characteristics. For example, the one or more Uu characteristics may include any of RLF, BFD, LBT failure, RSRP, CQI, the number of consecutive HARQ NACKs, the amount of data buffered at the WTRU, and the amount of data sent over SL compared to Uu. The WTRU may determine to transmit SL CBR information to the base station based on the one or more Uu characteristics. Determining to transmit SL CBR information may include, for example, performing any of the following based on the one or more Uu characteristics: (i) starting periodic transmission of SL CBR signals, (ii) stopping periodic transmission of SL CBR information, and (iii) modifying the periodicity of periodic transmission of SL CBR information.

[0167] In an embodiment, according to any of the embodiments described herein, the WTRU may determine one or more SL characteristics of the SL. The WTRU may determine to transmit SL CBR information to the base station based on the one or more SL characteristics. Determining to transmit SL CBR information may include, for example, performing any of the following based on the one or more SL characteristics: (i) starting periodic transmission of SL CBR signals, (ii) stopping periodic transmission of SL CBR information, and (iii) modifying the periodicity of periodic transmission of SL CBR information.

[0168] For example, the WTRU may initiate a SL CBR report (e.g., may transmit information indicating a channel busy rate) based on the amount of data routed via the SL relay path. For example, if the amount of data routed to the SL relay path satisfies a condition (e.g., is above any one of a configured threshold and a predetermined threshold, where the threshold may be 0), the WTRU may initiate a SLCBR report (e.g., transmit) to the network.

[0169] For example, the WTRU may determine the periodicity of SL CBR report transmissions based on the amount of data routed via the SL relay path.

[0170] For example, in the event that the WTRU determines that duplication is enabled, for example, for one or more split bearers in a multipath, the WTRU may initiate SL CBR reporting (eg, may transmit information indicating the SL CBR).

[0171] Any Uu characteristics for enabling the use of the second congestion control behavior according to any embodiment described herein may be used for any of: controlling (e.g., either of initiating and stopping) SL CBR reporting, and modifying any parameters associated with the reporting (e.g., any of the periodicity of the reporting, the (e.g., resource) pools included in the reporting, etc.).

[0172] Example of congestion control method in multipath SL relay

[0173] Figure 4 4 is a diagram illustrating an example congestion control method 400 in a multipath sidelink relay. In an embodiment, the method 400 may be implemented in a WTRU. As shown at 410, the WTRU may transmit first data for a split bearer via a link to a base station and via a sidelink to a relay WTRU, where the first data may be transmitted using a first congestion control operation mode. As shown at 420, the WTRU may detect a quality degradation on the link to the base station. As shown at 430, the WTRU may transmit second data for the split bearer using a second congestion control operation mode.

[0174] In various embodiments, the second congestion control operating mode may be based on congestion of the side link.

[0175] In various embodiments, the second congestion control mode of operation may include performing replication on the link and the side link, conditional upon channel occupancy conditions being met on the side link.

[0176] In various embodiments, the channel occupancy condition may be satisfied on the side link when the channel busy rate is below a threshold.

[0177] In various embodiments, the second congestion control mode of operation may be based on characteristics of the link to the base station.

[0178] In various embodiments, the characteristics of the link to the base station may include any of the following: (1) a quality measurement of the link to the base station, (2) a radio link failure of the link to the base station, (3) a beam failure on the link to the base station, (4) a hybrid automatic repeat request feedback characteristic of the link to the base station, (5) an unlicensed spectrum channel access failure, and (6) a buffer status associated with the link to the base station.

[0179] In various embodiments, the WTRU may receive signaling information indicating a switch to a second congestion control mode of operation.

[0180] In various embodiments, the WTRU may switch back to the first congestion control mode of operation after determining that a certain amount of time has passed after starting to use the second congestion control mode of operation.

[0181] In various embodiments, a second congestion control mode of operation may be used to transmit second data to the relay WTRU on the sidelink.

[0182] In various embodiments, using the second congestion control mode of operation may include using different congestion control parameters for relayed data and non-relayed data.

[0183] In various embodiments, using the second congestion control mode of operation may include using different congestion control parameters for transmissions associated with different bearers.

[0184] In various embodiments, using the second congestion control mode of operation may include using different congestion control parameters for transmissions associated with different sets of transmission resources.

[0185] In various embodiments, use of the second congestion control mode of operation may be limited to transmissions associated with a subset of logical channels.

[0186] In various embodiments, use of the second congestion control mode of operation may be limited to transmissions associated with bearers for which duplication may be enabled.

[0187] In various embodiments, transmitting the second data using the second congestion control operating mode may include duplicating the second data and transmitting information indicating that the second data may be duplicated.

[0188] In various embodiments, the WTRU may transmit channel busy rate information associated with the side link to the base station based on characteristics of the link to the base station.

[0189] In various embodiments, the WTRU may transmit channel busy rate information associated with the side link to the base station, provided that the amount of data transmitted via the side link satisfies a total amount condition.

[0190] In various embodiments, the total volume condition may be satisfied when the amount of data transmitted via the side link is above a threshold.

[0191] In various embodiments, channel busy rate information associated with the side link may be transmitted with a certain periodicity according to the amount of data transmitted via the side link.

[0192] Figure 5 is a diagram illustrating an example method 500 for congestion control in a multipath sidelink relay. The method 500 may be implemented in a WTRU. As shown at 510, the WTRU may transmit data for a split bearer associated with a link to a base station and a sidelink to a relay WTRU. The data may include first data that may be transmitted via the sidelink using a first set of congestion control parameters. As shown at 520, the WTRU may determine that quality degradation has occurred on the link to the base station. As shown at 530, the WTRU may transmit additional data for the split bearer. The additional data may include second data that may be transmitted via the sidelink using a second set of congestion control parameters based on determining that quality degradation has occurred on the link to the base station.

[0193] In various embodiments, in the event that any one of a radio link failure, a beam failure detection, and a listen-before-talk failure occurs on the link to the base station, it may be determined that quality degradation occurs on the link to the base station.

[0194] In various embodiments, quality degradation may be determined to have occurred on a link to a base station if a link quality metric associated with the link to the base station fails to satisfy a quality condition.

[0195] In various embodiments, the link quality metric associated with the link to the base station may include any of a reference signal received power and a channel quality indicator. In the event that the link quality metric is below the first threshold, the link quality metric may fail to satisfy the quality condition.

[0196] In various embodiments, the link quality metric associated with the link to the base station may include a number of consecutive hybrid automatic repeat request negative acknowledgments received from the base station on the link. In the event that the number of consecutive hybrid automatic repeat request negative acknowledgments is above a second threshold, the link quality metric may fail to meet the quality condition.

[0197] In various embodiments, the first and second sets of congestion control parameters may include any of: (i) modulation and coding scheme, (ii) transmission power, (iii) channel occupancy, and (iv) a number of retransmissions associated with a range of sidelink channel busy rates.

[0198] In various embodiments, the WTRU may switch back to (eg, use) the first set of congestion control parameters upon determining that a certain amount of time has passed after starting to use the second set of congestion control parameters.

[0199] In various embodiments, the WTRU may switch back to (eg, use) the first set of congestion control parameters after receiving signaling information from the base station indicating the switch back to the first set of congestion control parameters.

[0200] In various embodiments, different congestion control parameters may be used on the sidelink to transmit relayed data and non-relayed data.

[0201] In various embodiments, different congestion control parameters may be used on the sidelink for transmissions associated with different bearers.

[0202] In various embodiments, data replication may be performed on the link to the base station and the side link, subject to the channel occupancy condition being met on the side link.

[0203] In various embodiments, when the channel busy rate on the side link is lower than a third threshold, the channel occupancy condition may be satisfied on the side link.

[0204] In various embodiments, the WTRU may receive configuration information indicating either a first set of congestion control parameters and a second set of congestion control parameters.

[0205] In various embodiments, use of the second set of congestion control parameters may be limited to transmissions associated with bearers for which duplication may be enabled.

[0206] In various embodiments, use of the second set of congestion control parameters may be limited to transmissions from bearers configured to use the second set of congestion control parameters.

[0207] In various embodiments, the WTRU may transmit channel busy rate information associated with the side link to the base station based on characteristics of the link to the base station.

[0208] In various embodiments, the WTRU may transmit channel busyness rate information associated with the sidelink to the base station based on the amount of data transmitted via the sidelink.

[0209] In various embodiments, the second data may be associated with a second grant for second sidelink transmission, and the second sidelink transmission associated with the second grant may be limited to transmission of a second set of logical channels associated with a second set of congestion control parameters.

[0210] In various embodiments, the first data may be associated with a first grant for first sidelink transmissions, and the first sidelink transmissions associated with the first grant may be limited to transmissions of a first set of logical channels associated with a first set of congestion control parameters.

[0211] Example Methodology for SL CBR Reporting

[0212] Figure 6 6 is a diagram illustrating an example method 600 for SL CBR reporting. The method 600 may be implemented in a WTRU. As shown at 610, the WTRU may transmit data for a separate bearer associated with a link to a base station and a side link to a relay WTRU. As shown at 620, the WTRU may determine one or more characteristics of either the link to the base station and the side link to the relay WTRU. As shown at 630, the WTRU may determine to transmit sidelink channel busy rate information to the base station based on one or more characteristics of either the link to the base station and the side link to the relay WTRU.

[0213] In various embodiments, the side link channel busy rate information may be periodically transmitted to the base station.

[0214] In various embodiments, determining to transmit side link channel busy rate information may include, for example, performing any of the following based on one or more characteristics of either the link to the base station and the side link to the relay WTRU: (i) starting periodic transmission of the side link channel busy rate information, (ii) stopping periodic transmission of the side link channel busy rate information, and (iii) modifying the periodicity of the periodic transmission of the side link channel busy rate information.

[0215] In various embodiments, starting, stopping, or modifying the periodicity of the periodic transmission of the sidelink channel busy rate information may be determined based on whether a first condition associated with a link to a base station is satisfied.

[0216] In various embodiments, the first condition may be met in the event of any of a radio link failure, beam failure detection, and listen-before-talk failure on the link to the base station. For example, in the event of any of a RLF, BFD, and LBT failure on the link to the base station, the WTRU may stop periodically transmitting SL CBR information to the base station.

[0217] In various embodiments, the first condition may be satisfied if either of a reference signal received power and a channel quality indicator associated with the link to the base station is below a threshold value. For example, if either of an RSRP and a CQI associated with the link to the base station is below a threshold value, the WTRU may either start periodic transmission of SL CBR information or reduce the periodicity of the periodic transmission (e.g., transmit more frequently).

[0218] In various embodiments, the first condition may be satisfied if the number of consecutive hybrid automatic repeat request negative acknowledgements received on the link to the base station is above a threshold. For example, if the number of consecutive HARQ NACKs received on the link to the base station is above a threshold, the WTRU may either start periodic transmission of SL CBR information or reduce the periodicity of the periodic transmission (e.g., transmit more frequently).

[0219] In various embodiments, the first condition may be satisfied when the amount of data buffered at the WTRU is below a threshold. For example, when the amount of data buffered at the WTRU is below a threshold, the WTRU may either stop the periodic transmission of the SL CBR information or increase the periodicity of the periodic transmission (e.g., transmit less frequently).

[0220] In various embodiments, the first condition may be based on the amount of data sent via the side link to the relay WTRU compared to the link to the base station. For example, if the amount of data sent via the side link is higher than the amount of data sent via the link to the base station (e.g., higher than a threshold), the first condition may be met. For example, if the amount of data sent via the side link is higher than the amount of data sent via the link to the base station (e.g., higher than a threshold), the WTRU may either start periodic transmission of SL CBR information or reduce the periodicity of the periodic transmission (e.g., transmit more frequently).

[0221] In various embodiments, the periodicity of the periodic transmission of the SL CBR information may be determined to be started, stopped, or modified based on whether a second condition associated with the sidelink to the relay WTRU is satisfied.

[0222] In various embodiments, a second condition associated with the sidelink may be met if the amount of data routed via the sidelink is above a threshold.

[0223] In various embodiments, when the amount of data routed via the side link is higher than a threshold, it may be determined to start periodic transmission of the side link channel busy rate information.

[0224] In various embodiments, whether to start or stop the periodic transmission of the SL CBR information may be determined based on whether duplication for split bearers is enabled.

[0225] In various embodiments, starting the periodic transmission of the SL CBR information may be determined based on duplication for split bearers being enabled.

[0226] In various embodiments, the periodicity of transmitting the SL CBR information to the base station may be based on the amount of data routed via the sidelink.

[0227] Example Method for Congestion Control Behavior Based on Multipath Information

[0228] Figure 7 7 is a diagram of an example method 700 for changing a set of congestion control parameters based on receiving multipath information. The method 700 may be implemented in a first WTRU. As shown at 710, the first WTRU may transmit first data via a sidelink to a second WTRU using a first set of congestion control parameters. As shown at 720, the first WTRU may receive multipath information from a second WTRU indicating that a multipath exists at the second WTRU. As shown at 730, the WTRU may determine to use a second set of congestion control parameters based on the multipath information to transmit second data via a sidelink to the second WTRU.

[0229] In various embodiments, the multipath information may indicate that a side link congestion metric associated with multipath traffic related to the side link satisfies a condition.

[0230] In various embodiments, the side link congestion metric associated with the multipath service may include any one of a side link resource occupancy rate and a side link resource occupancy percentage associated with the multipath service. In various embodiments, the condition may be satisfied when the side link congestion metric associated with the multipath service is above a first threshold.

[0231] In various embodiments, the side link congestion metric associated with the multipath traffic may include a side link channel busy rate based only on the multipath traffic, and the condition may be met if the side link congestion metric associated with the multipath traffic is above a second threshold.

[0232] In various embodiments, the side link congestion metric associated with the multipath service may include any one of a side link resource occupancy rate and a side link resource occupancy percentage associated with the transmission of the multipath service with priority. In various embodiments, the condition may be met when the side link congestion metric associated with the transmission of the multipath service with priority is above a third threshold.

[0233] In various embodiments, in the event that the transmission of the multipath traffic has a priority level higher than a fourth threshold, the transmission of the multipath traffic may have priority.

[0234] In various embodiments, the second set of congestion control parameters may be determined to reduce transmission power as compared to (eg, relative to) the first set of congestion control parameters.

[0235] In various embodiments, the second set of congestion control parameters may be determined to reduce an amount of sidelink resources used for transmission as compared to (eg, relative to) the first set of congestion control parameters.

[0236] Any features, variations or embodiments described for the method are compatible with an apparatus device including means for processing any of the disclosed methods, an apparatus including a processor configured to process any of the disclosed methods, a computer program product including program code instructions, and a non-transitory computer-readable storage medium storing the program instructions.

[0237] Although features and elements are provided above in specific combinations, it will be understood by those skilled in the art that each feature or element can be used alone or in any combination with other features and elements. The present disclosure is not limited in terms of the specific embodiments described in the present application, which are intended to be illustrations of various aspects. Without departing from its spirit and scope, many modifications and changes can be made, as will be apparent to those skilled in the art. Any element, action or instruction used in the description of the present application should not be interpreted as being critical or necessary to the present invention unless explicitly provided as such. In addition to those listed herein, functionally equivalent methods and devices within the scope of the present disclosure are apparent to those skilled in the art from the foregoing description. Such modifications and changes are intended to fall within the scope of the appended claims. The present disclosure is limited only by the terms of the appended claims and the full scope of equivalents given by such claims. It should be understood that the present disclosure is not limited to specific methods or systems herein.

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

[0239] It will also be understood that the terms used herein are used only for the purpose of describing specific embodiments and are not intended to be limiting. As used herein, the term "video" or the term "image" may mean any of a snapshot, a single image, and / or a plurality of images displayed over a certain time basis. As another example, when referred to herein, the term "user equipment" and its abbreviation "UE", the term "remote" and / or the term "head-mounted display" or its abbreviation "HMD" may mean or include (i) a wireless transmit and / or receive unit (WTRU); (ii) any of many embodiments of a WTRU; (iii) a device with wireless capabilities and / or wired capabilities (e.g., wearable) that is configured with some or all of the structure and functionality of a WTRU; (iii) a device with wireless capabilities and / or wired capabilities that is configured with less than all of the structure and functionality of a WTRU; or (iv) a similar device. References herein to Figures 1A to 1D Details of an example WTRU are provided, which may be representative of any WTRU set forth herein. As another example, various disclosed embodiments herein are described above and below as utilizing a head mounted display. Those skilled in the art will recognize that devices other than a head mounted display may be utilized, and some or all of the present disclosure and various disclosed embodiments may be modified accordingly without undue experimentation. Examples of such other devices may include drones or other devices configured to stream information to provide an adapted reality experience.

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

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

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

[0243] Those of ordinary skill in the art will appreciate that the actions and symbolic representations of operations or instructions include manipulation of electrical signals by the CPU. The electrical system represents data bits, which may cause the final conversion or reduction of electrical signals and maintain the data bits in memory locations in the storage system, thereby reconfiguring or otherwise changing the operation of the CPU and other processing of signals. The memory locations where the data bits are maintained are physical locations having specific electrical, magnetic, optical, or organic properties that correspond to or represent the data bits. It should be understood that the embodiments are not limited to the above-mentioned platforms or CPUs, and other platforms and CPUs may support the provided methods.

[0244] The data bits may also be maintained on a computer-readable medium, including a magnetic disk, an optical disk, and any other volatile (e.g., random access memory (RAM)) or non-volatile (e.g., read-only memory (ROM)) mass storage system readable by a CPU. The computer-readable medium may include cooperating or interconnected computer-readable media that reside only on a processing system or distributed among multiple interconnected processing systems that may be local or remote to the processing system. It should be understood that the embodiments are not limited to the above-mentioned memories, and other platforms and memories may support the provided methods.

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

[0246] There is little difference between hardware and software implementations of various aspects of the system. The use of hardware or software is usually (but not always, as in some cases, the choice of hardware or software may become important) a design choice that represents a cost-efficiency trade-off. There may be various vehicles (e.g., hardware, software, and / or firmware) with which the processes and / or systems and / or other technologies described herein can be implemented, and the preferred vehicle may change with the context in which the processes and / or systems and / or other technologies are deployed. For example, if the implementer determines that speed and accuracy are most important, then the implementer may select a primary hardware and / or firmware vehicle. If flexibility is most important, then the implementer may select a primary software implementation. Alternatively, the implementer may select some combination of hardware, software, and / or firmware.

[0247] The foregoing detailed description has been described various embodiments of the apparatus and / or process by using block diagrams, flow charts and / or examples. Insofar as such block diagrams, flow charts and / or examples include one or more functions and / or operations, it will be understood by those skilled in the art that each function and / or operation within such block diagrams, flow charts or examples can be implemented individually and / or collectively by a wide range of hardware, software, firmware or indeed any combination thereof. In an embodiment, several parts of the subject matter described herein may be implemented via an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP) and / or other integrated formats. However, those skilled in the art will recognize that all or part of some aspects of the embodiments disclosed herein may be equivalently implemented in an integrated circuit, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware or almost as any combination thereof, and according to the present disclosure, designing circuit systems and / or writing codes for software and / or firmware will be completely within the skill range of those skilled in the art. In addition, those skilled in the art will appreciate that the mechanisms of the subject matter described herein can be distributed as a program product in a variety of forms, and that the illustrative examples of the subject matter described herein apply regardless of the particular type of signal-bearing medium used to actually carry out the distribution. Examples of signal-bearing media include, but are not limited to, the following: recordable media such as floppy disks, hard drives, CDs, DVDs, digital tapes, computer memory, etc.; and transmission media such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.).

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

[0249] The subject matter described herein sometimes illustrates different parts that are included in different other parts or connected with different other parts.It should be understood that the architecture of such description is only an example, and many other architectures that realize the same function can actually be implemented.In a conceptual sense, any arrangement of parts for realizing the same function is effectively "associated" so that the desired function can be realized.Therefore, any two parts that are combined to realize a specific function in this article can be regarded as "associated" with each other so that no matter how the architecture or intermediate parts realize the desired function.Similarly, any two parts that are associated in this way can also be regarded as "operably connected" or "operably coupled" to realize the desired function, and any two parts that can be associated in this way can also be regarded as "operably coupled" to realize the desired function.The specific example of operable coupling includes (but is not limited to) parts that can be matched physically and / or physically interact, and / or parts that can be wirelessly interacted and / or wirelessly interacted, and / or parts that can be logically interacted and / or parts that can be logically interacted.

[0250] With respect to the use of substantially any plural and / or singular terms herein, those skilled in the art can translate from the plural to the singular and / or from the singular to the plural where appropriate to the context and / or application. For clarity, the various singular / plural arrangements may be expressly set forth herein.

[0251] Those skilled in the art will understand that, in general, the terms used herein and particularly in the appended claims (e.g., the bodies of the appended claims) are generally intended to be "open" terms (e.g., the term "including" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "includes" should be interpreted as "including but not limited to," etc.). Those skilled in the art will further understand that if a specific number of an introduced claim statement is intended, such intent will be expressly stated in the claim, and in the absence of such a statement, such intent is not present. For example, where only one item is intended, the term "single" or similar language may be used. To aid understanding, the following appended claims and / or the description herein may include the use of the introductory phrases "at least one" and "one or more" to introduce multiple claim statements. However, the use of such phrases should not be interpreted as implying that a claim recitation introduced by the indefinite article "a" or "an" will limit any particular claim including such introduced claim recitation to embodiments including only one such recitation, even if the same claim includes the introductory phrases "one or more" or "at least one" and an indefinite article such as "a" or "an" (e.g., "a" and / or "an" should be interpreted as meaning "at least one" or "one or more"). The same is true for the use of definite articles to introduce claim recitations. In addition, even if a specific number of introduced claim recitations is explicitly recited, one skilled in the art will recognize that such recitation should be interpreted as meaning at least the recited number (e.g., merely reciting "two recitations" without other modifiers means at least two recitations or two or more recitations). Furthermore, in those cases where a convention similar to “at least one of A, B, and C, etc.” is used, generally, such construction is intended to represent the convention that one skilled in the art would understand (e.g., “a system having at least one of A, B, and C” would include, but is not limited to, systems having only A, only B, only C, both A and B, both A and C, both B and C, and / or both A, B, and C, etc.). In those cases where a convention similar to “at least one of A, B, or C, etc.” is used, generally, such meaning is intended in the sense that one skilled in the art would understand the convention (e.g., “a system having at least one of A, B, or C” would include, but is not limited to, systems having only A, only B, only C, both A and B, both A and C, both B and C, and / or both A, B, and C, etc.). One skilled in the art would further understand that any transitional word and / or phrase (whether in the specification, claims, or drawings) that actually gives two or more alternatives should be understood to contemplate the possibility of including one of the items, any one of the items, or both of the items.For example, the phrase "A or B" will be understood to include the possibility of "A" or "B" or "A and B." In addition, the term "any" as used herein followed by a list of multiple items and / or categories of items is intended to include "any," "any combination," "any multiple," and / or "any combination of multiples," either alone or in combination with other items and / or other categories of items. Furthermore, the term "set," as used herein, is intended to include any number of items, including zero. Additionally, the term "number," as used herein, is intended to include any number, including zero. And the term "plurality," as used herein, is intended to be synonymous with "multiple."

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

[0253] As will be understood by those skilled in the art, for any and all purposes, such as in providing a written description, all ranges disclosed herein also encompass any and all possible sub-ranges and combinations of sub-ranges thereof. Any listed range can be easily identified as fully describing and capable of decomposing the same range into at least equal halves, one-third, one-quarter, one-fifth, one-tenth, etc. As a non-limiting example, each range discussed herein can be easily decomposed into a lower third, a middle third, and an upper third, etc. As will be understood by those skilled in the art, all languages ​​such as "at most", "at least", "greater than", "less than", etc. include the enumerated numbers, and refer to the ranges that can be subsequently subdivided into sub-ranges as discussed above. Finally, as will be understood by those skilled in the art, the range includes each individual member. Therefore, for example, a group with 1 to 3 units refers to a group with 1, 2 or 3 units. Similarly, a group with 1 to 5 units refers to a group with 1, 2, 3, 4 or 5 units, and so on.

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

Claims

1. A method implemented in a wireless transmit / receive unit (WTRU), the method comprising: transmitting data for a separate bearer associated with a link to a base station and a side link to a relay WTRU, wherein the data includes first data transmitted via the side link using a first set of congestion control parameters; determining that quality degradation has occurred on the link to the base station; as well as Further data for the separate bearer is transmitted, wherein the further data comprises second data transmitted via the sidelink using a second set of congestion control parameters based on a determination that quality degradation has occurred on the link to the base station.

2. The method according to claim 1, wherein: In the event that any one of a radio link failure, a beam failure detection, and a listen-before-talk failure occurs on the link to the base station, it is determined that quality degradation occurs on the link to the base station.

3. The method according to any one of claims 1 to 2, wherein: In an event that a link quality metric associated with the link to the base station fails to satisfy a quality condition, it is determined that quality degradation has occurred on the link to the base station.

4. The method according to claim 3, wherein: The link quality metric associated with the link to the base station comprises any one of a reference signal received power and a channel quality indicator, and wherein the link quality metric fails to satisfy the quality condition if the link quality metric is below a first threshold.

5. The method according to any one of claims 3 and 4, wherein: The link quality metric associated with the link to the base station comprises a number of consecutive hybrid automatic repeat request negative acknowledgments received from the base station on the link, and wherein the link quality metric fails to satisfy the quality condition if the number of consecutive hybrid automatic repeat request negative acknowledgments is above a second threshold.

6. The method according to any one of claims 1 to 5, wherein: The first set of congestion control parameters and the second set of congestion control parameters include any of the following items: (i) modulation and coding scheme, (ii) transmission power, (iii) channel occupancy, and (iv) a number of retransmissions associated with a range of side link channel busy rates.

7. The method according to any one of claims 1 to 6, comprising: After determining that a certain amount of time has passed after commencing use of the second set of congestion control parameters, switching back to the first set of congestion control parameters.

8. The method according to any one of claims 1 to 6, comprising: After receiving signaling information from the base station indicating switching back to the first set of congestion control parameters, switching back to the first set of congestion control parameters.

9. The method according to any one of claims 1 to 8, wherein: Different congestion control parameters are used on the sidelink to transmit relayed data and non-relayed data.

10. The method according to any one of claims 1 to 9, wherein: Different congestion control parameters are used on the sidelink for transmissions associated with different bearers.

11. The method according to any one of claims 1 to 10, wherein: Data replication is performed on the link to the base station and the side link under the condition that a channel occupancy condition is satisfied on the side link.

12. The method according to claim 11, wherein: When the channel busy rate on the side link is lower than a third threshold, the channel occupancy condition is met on the side link.

13. The method according to any one of claims 1 to 12, comprising: Configuration information indicating any one of the first set of congestion control parameters and the second set of congestion control parameters is received.

14. The method according to any one of claims 1 to 13, wherein: Use of the second set of congestion control parameters is limited to transmissions associated with the replication-enabled bearers.

15. The method according to any one of claims 1 to 14, wherein: Use of the second set of congestion control parameters is limited to transmissions from bearers configured to use the second set of congestion control parameters.

16. The method according to any one of claims 1 to 15, comprising: Channel busy rate information associated with the side link is transmitted to the base station based on characteristics of the link to the base station.

17. The method according to any one of claims 1 to 16, comprising: Channel busy rate information associated with the side link is transmitted to the base station based on an amount of data transmitted via the side link.

18. A wireless transmit / receive unit (WTRU) comprising a circuit system, the circuit system including a transmitter, a receiver, a processor and a memory, the WTRU being configured to: transmitting data for a separate bearer associated with a link to a base station and a side link to a relay WTRU, wherein the data includes first data transmitted via the side link using a first set of congestion control parameters; determining that quality degradation has occurred on the link to the base station; as well as transmitting additional data for the separate bearer, wherein the additional data comprises second data, the second data being transmitted via the sidelink using a second set of congestion control parameters based on a determination that quality degradation has occurred on the link to the base station, wherein the second data is associated with a second grant for second sidelink transmission, and wherein the second sidelink transmission associated with the second grant is limited to transmission of a second set of logical channels associated with the second set of congestion control parameters.

19. The WTRU of claim 18 wherein: The first data is associated with a first grant for a first sidelink transmission, and wherein the first sidelink transmission associated with the first grant is limited to transmission of a first set of logical channels associated with the first set of congestion control parameters.

20. The WTRU of any one of claims 18 to 19, wherein: The first set of congestion control parameters and the second set of congestion control parameters include any of the following items: (i) modulation and coding scheme, (ii) transmission power, (iii) channel occupancy, and (iv) a number of retransmissions associated with a range of side link channel busy rates.

Images