PBR determination of RLC channels

Abstract

Systems, methods, and facilities for determining a prioritized bit rate (PBR) for a radio link control (RLC) channel are described herein. For example, a device, such as a wireless transmit / receive unit (WTRU), receives first priority information and a first indication of a first prioritized bit rate (PBR) associated with a first ingress radio link control (RLC) channel. The WTRU may receive second priority information associated with a second ingress RLC channel and a second indication of a second PBR. The WTRU may determine a third PBR based on at least one of the first PBR, the first priority information, the second PBR, or the second priority information. The third PBR may be associated with an egress RLC channel. The WTRU may send a third indication (e.g., to the parent node and / or child node). The third indication may indicate a third PBR.

Description

[0001] Cross-reference to related applications This application claims the benefit of U.S. Provisional Application No. 63 / 531,147, filed August 7, 2023, the contents of which are incorporated herein by reference. Background Technology

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

[0003] This document describes systems, methods, and means for determining the Prioritized Bit Rate (PBR) of a Radio Link Control (RLC) channel. For example, a device such as a Wireless Transmit / Receive Unit (WTRU) may perform (e.g., be configured to perform) one or more of the following. The device (e.g., the WTRU) may be a relay WTRU, and / or may be associated with a relay WTRU.

[0004] The WTRU can receive priority information and PBR indications associated with an ingress RLC channel. For example, the WTRU can receive first priority information and a first PBR indication associated with a first ingress RLC channel, and can receive second priority information and a second PBR indication associated with a second ingress RLC channel. In this example, the first ingress RLC channel can be associated with a parent node (e.g., a first parent node), and the second ingress RLC channel can be associated with another parent node (e.g., a second parent node). In this example, the first ingress RLC channel can be associated with a parent node, and the second ingress RLC channel can be associated with a parent node (e.g., the same parent node).

[0005] The WTRU can determine the third PBR based on at least one of the first PBR, first priority information, second PBR, or second priority information. The third PBR can be associated with the egress RLC channel. The WTRU can map the first and second ingress RLC channels to the egress RLC channel.

[0006] The WTRU can send an indication, for example, to at least one of the parent or child nodes. For instance, the WTRU can send a third indication. The third indication can indicate a third PBR.

[0007] The WTRU can determine the Channel Occupancy Rate (CBR) associated with a resource pool. In the example, the WTRU can further determine a third PBR based on the CBR.

[0008] In the example, the WTRU can determine the valid PBR associated with the ingress RLC channel based on at least one of the PBR, priority information, or CBR associated with the resource pool. The WTRU can determine a first valid PBR associated with a first ingress RLC channel based on at least one of the first PBR, first priority information, or CBR associated with the resource pool, and a second valid PBR associated with a second ingress RLC channel based on at least one of the second PBR, second priority information, or CBR associated with the resource pool. The WTRU can send an indication (e.g., a fourth indication) to at least one of the parent or child nodes. The fourth indication can indicate at least one of the first or second valid PBR. Attached Figure Description

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

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

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

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

[0013] Figure 2 An example of WTRU to network relay is shown.

[0014] Figure 3 An example of a user plane protocol stack for L2 WTRU to network relay is shown.

[0015] Figure 4 An example of a WTRU-to-WTRU relay is shown.

[0016] Figure 5 An example architecture for an L2 WTRU to WTRU relay is shown.

[0017] Figure 6 An example of prioritizing bit rate (PBR) determination is shown.

[0018] Figure 7An example of WTRU mapping between the ingress RLC and the egress RLC is shown for multi-hop multipath relay.

[0019] Figure 8 An example of multipath with a common relay WTRU between multiple (e.g., two) paths is shown.

[0020] Figure 9 An example is shown where the source WTRU sends a 1-1 mapping request for multiple (e.g., two) replicated RLC channels.

[0021] Figure 10 An example is shown of how WTRU determines whether to map a new ingress RLC channel to an existing egress RLC channel. Detailed Implementation

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

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

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

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

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

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

[0028] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as evolved UMTS terrestrial radio access (E-UTRA), which may use Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro) to establish air interface 116.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0068] Figure 1DThe CN 115 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. Although each of the foregoing elements is depicted as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

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

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

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

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

[0073] Given Figure 1A-1D as well as Figure 1A-1D The corresponding descriptions herein indicate that one or more of the following functions can be performed by one or more emulation devices (not shown): WTRU 102a-d, Base Station 114a-b, eNode-B160a-c, MME 162, SGW 164, PGW 166, gNB180a-c, AMF 182a-b, UPF 184a-b, SMF183a-b, DN185a-b, and / or any other device(s) described herein. An emulation device can be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device can be used to test other devices and / or simulate network and / or WTRU functions.

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

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

[0076] The Radio Link Control (RLC) channel configuration procedure can be implemented in the network (e.g., New Radio (NR) Vehicle-to-Everything (V2X)). The RLC channel configuration procedure can provide configuration procedures for unicast, multicast, and / or broadcast. The Transmit (TX) WTRU can determine the sidelink (SL) bearer configuration (e.g., Packet Data Convergence Protocol (PDCP), RLC, Media Access Control (MAC), etc., and one or more configuration parameters) based on the Quality of Service (QoS) profile of one or more upper-layer QoS flows initiated by the TX WTRU.

[0077] The determination of the bearer configuration can be based on (e.g., depending on) the Radio Resource Control (RRC) state of the TX WTRU. For example, if / when the TX WTRU is in RRC_IDLE (RRC idle) / RRC_INACTIVE (RRC inactive) or outside network coverage (OOC), the WTRU can obtain the bearer configuration to use from, for example, a System Information Block (SIB) or a configuration (e.g., a pre-configuration). The SIB and / or pre-configuration can include a list (e.g., an exhaustive list) of bearer configurations to be used (e.g., for each) QoS profile. For example, if the QoS profile is not included in the SIB and / or pre-configuration, the WTRU can use a bearer configuration (e.g., a default bearer configuration). The WTRU can map QoS flows to the default bearer. The WTRU (e.g., in RRC_CONNECTED) can send the QoS profile of a QoS flow to the network (e.g., if / when the flow is initiated). The WTRU can receive the bearer configuration of the QoS flow from dedicated RRC signaling.

[0078] The network (e.g., in Mode 1) can manage the scheduling of one or more resources to the TX WTRU, for example, to support meeting the latency requirements associated with each transmission. For example, the WTRU can perform scheduling in Mode 2. Managing latency can be incorporated into the resource selection process, as in Mode 2. For example, if / when data triggers the resource selection process, the WTRU can utilize a resource selection window defined by the packet delay budget (PDB) of the priority data available for transmission (e.g., the highest priority data) to select one or more resources, which can support meeting the latency associated with the data. For example, the network may not participate in defining the PDB (e.g., in a logical channel) because the PDB is known to the TX WTRU from the QoS profile.

[0079] Figure 2 An example of WTRU to network relay is shown.

[0080] The RLC channel configuration process can be implemented in the WTRU to network relay. Figure 3 An example of the user plane protocol stack from L2 WTRU to network relay is shown.

[0081] Figure 3 An example of a user plane protocol stack for L2 WTRU to network relay is shown.

[0082] The WTRU can receive bearer configuration from the network in dedicated RRC signaling (e.g., using a regular Uu). The network can (e.g., for WTRU to NW trunk) configure the End-to-End Service Data Adaptation Protocol (SDAP) and PDCP to the remote WTRU, configure the Sidelink Trunk Adaptation Protocol (SRAP) to both the remote WTRU and the trunk WTRU, and configure RLC and below to both the remote WTRU and below. For example, the configuration can be performed by the network (e.g., using dedicated RRC signaling) because the remote WTRU (e.g., except for communicating with the network via a trunk) can be treated as a normal WTRU in the Uu. The remote WTRU can receive the Data Radio Bearer (DRB) configuration, for example, using dedicated signaling similar to that of the Uu (e.g., RRCReconfiguration messages), except that the DRB configuration can be received via the trunk signaling radio bearer (SRB).

[0083] The network can configure an adaptation layer (e.g., SRAP) in the WTRU to NW relay. The SRAP at the relay WTRU can handle the multiplexing of PC5 RLC channels to Uu RLC channels (e.g., in the uplink) and vice versa (e.g., in the downlink). The network can, for example, multiple PC5-RLC channels in the uplink to (e.g., the same) Uu RLC channels. The adaptation layer can perform routing (e.g., based on mapping) when the relay WTRU receives packets.

[0084] For transmissions from the WTRU to the NW trunk and / or sidelink, the remote WTRU may be in Mode 2 (e.g., by definition). The latency associated with an uplink transmission from the remote WTRU may include an SL portion and a Uu portion. The network may control the latency of the Uu portion. The WTRU may control the latency of the SL portion (e.g., through resource selection). There may be some coordination such that the sum of the latency satisfies the packet's PDB. The PDB associated with the packet may represent the end-to-end latency. The PDB may not be used to determine the resource selection window. The network may configure PDB segmentation. The network may provide the remote WTRU (e.g., for each SL LCH that can be relayed by a trunk) with a PDB that can be used for, for example, a resource selection process in Mode 2.

[0085] Figure 4 An example of a WTRU-to-WTRU relay is shown.

[0086] Figure 5 An example architecture for an L2 WTRU to WTRU relay is shown.

[0087] WTRUs participating in WTRU-to-WTRU relays (e.g., source WTRU, destination WTRU, and / or relay WTRU) may be within or outside coverage and may be in any RRC state.

[0088] Relay operations can support N-1 mapping between ingress and egress RLC channels. RLC channel configuration can include a Prioritized Bit Rate (PBR), which can be used to guarantee (e.g., the data rate per) RLC channel. The PBR can be determined for (e.g., per) egress RLC channel of a relay WTRU in a multi-hop / multipath scenario, while supporting N-1 mapping.

[0089] Multi-hop / multipath relays can be configured to satisfy end-to-end (E2E) QoS. One or more TxWTRUs in a multi-hop chain (e.g., all Tx WTRUs) can cooperate to determine the transmission parameters for each hop to satisfy E2E QoS. (e.g., each) WTRU can determine the Tx parameters.

[0090] Multi-hop / multipath trunking can include multiple (e.g., two) multipaths with a common trunk, which can reduce multipath diversity. The common trunk WTRU can enhance its transmission to maintain reliable data transmission from source to destination. During transmission enhancement for replicated RLC, replicated data from the source cannot be multiplexed with other data from other WTRUs (e.g., replicated data cannot be multiplexed with other data).

[0091] WTRU can use N-1 RLC channel mappings to determine whether to map a new ingress RLC channel to an existing channel or a new RLC channel.

[0092] A WTRU can determine the RLC channel configuration. A WTRU (e.g., a source WTRU and / or a relay WTRU) can determine the RLC channel configuration of the outgoing RLC channel. The RLC channel configuration may include one or more of the following parameters (e.g., in any combination): PDCP configuration; RLC mode (e.g., acknowledged mode (AM) or unacknowledged mode (UM)); MAC logic configuration; and / or PDB.

[0093] RLC channel configuration may include PDCP configuration, which may include one or more of the following: an indication of whether the radio bearer (RB) needs to enable / disable multipath replication and / or the number of replicated paths; and / or an indication of whether the RB needs multicarrier replication and / or the number of replicated carriers.

[0094] RLC channel configuration may include an RLC mode (e.g., AM or UM) and / or one or more associated parameters (e.g., for each mode). One or more parameters for AM mode may include one or more of the following: a maximum retransmission threshold, which can be used to declare a radio link failure (RLF); the sequence number length for AM mode; and / or a polling byte (PollPDU), which can be used to determine the polling frequency for receiving acknowledgments of Protocol Data Units (PDUs). One or more parameters for UM mode may include, for example, the sequence number length for UM mode.

[0095] RLC channel configuration may include MAC logic configuration, which may include one or more of the following (e.g., in any combination): LCH priority; LCH priority bit rate (PBR), which may be used to guarantee the data rate of data in the LCH; LCH bucket size duration (BSD); and / or HARQ feedback type (e.g., HARQ enabled / disabled).

[0096] RLC channel configuration can include packet delay budget (PDB), which can be the transmission delay budget in the current hop.

[0097] For example, the egress RLC channel configuration can be determined based on one or more of the following (e.g., any combination): the configuration of one / each ingress RLC channel; the number of ingress RLC channels mapped to the egress RLC channel; the number of parent nodes with ingress RLC channels mapped to the egress RLC channel; the number of parent nodes; the number of child nodes; the load of the WTRU, which can be determined based on the number of child nodes, the number of parent nodes, and / or the channel occupancy rate (CR) of the WTRU; the priority associated with one / each ingress RLC channel; the priority associated with the egress RLC channel; the channel occupancy rate (CBR) of the resource pool; and / or the determined values ​​of one or more egress RLC parameters.

[0098] The outgoing RLC channel configuration can include the configuration of one / each incoming RLC channel. For example, the priority of the incoming RLC channel can be the highest priority of the incoming RLC channel. For example (e.g., if HARQ is already enabled on the RLC channel), the WTRU can (e.g., determine) enable HARQ for the outgoing RLC channel.

[0099] The egress RLC channel configuration may include determined values ​​for one or more egress RLC parameters. For example, the WTRU may determine the priority of the RLC channel based on the determined PDB of the current hop. For example, the WTRU may determine the priority of the RLC channel based on whether the WTRU enables / disables multi-carrier replication of the RLC channel. For example, if the WTRU enables multi-carrier replication, the WTRU may decrease the priority of the RLC channel. Conversely, if the WTRU disables multi-carrier replication, the WTRU may increase the priority of the RLC channel.

[0100] A WTRU can receive configurations for multiple RLC channel configurations. In some examples, a WTRU (e.g., a source WTRU, a relay WTRU, etc.) can receive a set of possible RLC channel configurations. Each RLC channel configuration can have a set of values ​​associated with parameters included in the RLC channel configuration. (e.g., each) configured RLC channel can have an associated RLC channel configuration index. In some examples, this set of RLC channel configurations can be pre-configured. In some examples, this set of RLC channel configurations can be configured by a base station such as a gNB (e.g., via a dedicated RRC or SIB). In some examples, this set of RLC channel configurations can be received from another node.

[0101] A WTRU can establish QoS flows with associated QoS requirements. In some examples, a WTRU (e.g., a source WTRU) can establish a QoS flow with one or more of the following QoS requirements: flow bit rate; minimum range; resource type, such as guaranteed bit rate (GBR), delay-critical GBR, or non-GBR; priority; packet delay budget (PDB); reliability (e.g., packet error rate (PER)); and / or maximum data burst size (MDBV).

[0102] A source WTRU can map QoS flows to RLC channels. A source WTRU can establish one or more E2E QoS flows (e.g., with associated PC5 5QI (PQI) or 5G QoS Indicator (5QI) indices) for data communication between the source WTRU and the destination WTRU. A source WTRU can map (e.g., each) E2E QoS flow to one or more RLC channels. A WTRU can map (e.g., one) E2E QoS flow to multiple RLC channels. A WTRU can map multiple QoS flows to (e.g., one) RLC channel.

[0103] In multi-hop relay, a source can send its QoS flow to a destination via one or more intermediate relays. A WTRU or network node (e.g., a gNB) can be present in the path from the source node to the destination node, for example, including both the source and destination. The source and destination nodes can be WTRUs or network entities such as gNBs. A child node can refer to the transmitter of the next hop or the receiver of the current hop. A parent node can refer to the transmitter of the previous node, where the WTRU is the receiver.

[0104] The WTRU can receive RLC configuration from the preceding node. The preceding node can be or may include at least one of a relay WTRU or a source WTRU. The WTRU (e.g., a relay WTRU) can receive one or more ingress RLC channels from the parent node. The WTRU can receive ingress RLC channel configuration from the parent node (e.g., a source WTRU or a parent relay). The WTRU can (e.g., also) receive information about E2E QoS flows, which may be indicated, for example, via 5QI or PQI indices.

[0105] A WTRU can indicate the RLC configuration of its egress RLC channel to its child nodes. For example, a WTRU (e.g., a relay WTRU) can indicate the RLC channel configuration to its child nodes after determining its egress RLC channel configuration. The WTRU can also (e.g., further) indicate information about the E2E QoS flow ID (e.g., 5QI and / or PQI index) associated with its egress RLC channel and / or remaining PDB. The parent node's egress RLC channel can be equivalent to and / or can be used interchangeably with the child node's ingress RLC channel.

[0106] A WTRU can indicate egress RLC configuration information to its parent node. For example, a WTRU (e.g., a relay WTRU) can indicate one or more parameters of the RLC channel configuration back to its parent node after determining the egress RLC channel configuration. For instance, a WTRU can indicate to its parent node how the WTRU maps ingress and egress RLC channels.

[0107] A WTRU (e.g., a relay WTRU) may determine the priority bit rate (PBR) of the egress RLC channel, for example, based on the PBR and / or priority (e.g., the sum of PBRs) of the ingress RLC channel mapped to the egress RLC channel and / or the CBR of the resource pool.

[0108] In the example, the WTRU can receive priority information and a PBR indication associated with an ingress RLC channel. The WTRU can receive first priority information and a first PBR indication associated with a first ingress RLC channel. The WTRU can receive second priority information and a second PBR indication associated with a second ingress RLC channel. As described herein, the WTRU can be associated with a relay WTRU (e.g., it may be or may include a relay WTRU).

[0109] In the example, the first ingress RLC channel may be associated with a parent node (e.g., the first parent node), and the second ingress RLC channel may be associated with another parent node (e.g., the second parent node). In the example, the first ingress RLC channel may be associated with a parent node, and the second ingress RLC channel may be associated with a parent node (e.g., the same parent node).

[0110] A WTRU (e.g., a relay WTRU) can be configured to perform one or more of the following operations. For example, the WTRU can be configured with a PBR scaling factor (e.g., alpha_PBR) based on the resource pool's CBR and / or the priority associated with the ingress RLC channel. In some examples, the alpha_PBR of a high-priority RLC can be (e.g., always) set to equal one (1). In some examples, the alpha_PBR of a low-priority RLC can be set to equal one (1) for a low CBR and equal to 0.5 for a high CBR. The WTRU can receive (e.g., each) the PBR of the ingress RLC channel. For example, the WTRU can determine the PBR of the egress RLC channel based on the resource pool's CBR, PBR, and / or the priority mapped to the egress RLC (e.g., each) of the ingress RLCs. In some examples, the WTRU can determine (e.g., each) the alpha_PBR of the ingress RLC channel based on the resource pool's CBR. The PBR of the egress RLC channel can be equal to the sum of the PBRs of one or more (e.g., all) ingress RLC channels multiplied by the associated alpha_PBR. WTRU can indicate the PBR of the associated ingress RLC channel to the next hop.

[0111] As described herein, the WTRU can determine the PBR (e.g., the third PBR) based on at least one of the first PBR, first priority information, second PBR, or second priority information. The third PBR can be associated with the egress RLC channel.

[0112] In the example, WTRU can determine the CBR associated with the resource pool. WTRU can then determine a third PBR based on the CBR associated with the resource pool.

[0113] In the example, WTRU can map the first ingress RLC channel and the second ingress RLC channel to the egress RLC channel.

[0114] The WTRU can send indications (e.g., third indications). For example, the WTRU can send an indication to at least one of its parent or child nodes. This indication can be directed to a third PBR.

[0115] In the example, the WTRU can determine the CBR associated with a resource pool. The WTRU can determine the valid PBR associated with an ingress RLC channel based on at least one of the PBR, priority information, or the CBR associated with the resource pool. For example, the WTRU can determine a first valid PBR associated with a first ingress RLC channel based on at least one of a first PBR, first priority information, or the CBR associated with the resource pool. The WTRU can determine a second valid PBR associated with a second ingress RLC channel based on at least one of a second PBR, second priority information, or the CBR associated with the resource pool. The WTRU can send an indication (e.g., a fourth indication) to at least one of the parent or child nodes. The second indication can indicate at least one of the first or second valid PBR.

[0116] The WTRU can receive RLC configuration from the preceding node. The WTRU (e.g., a relay WTRU) can receive one or more ingress RLC channels from its parent node. The WTRU can receive ingress RLC channel configurations. The WTRU can (e.g., also) receive information about E2EQoS flows, which can be indicated by 5QI and / or PQI indices.

[0117] A WTRU can (e.g., determine) map multiple (e.g., at least one) ingress RLC channels to (e.g., one) egress RLC channel. A WTRU (e.g., a relay WTRU) can receive multiple RLC channels from one or more parent nodes. A WTRU can (e.g., determine) map multiple (e.g., N) ingress RLC channels to (e.g., one) egress RLC channel. N ingress RLC channels can be received from one or more parent nodes.

[0118] The WTRU can determine (e.g., for each) the effective PBR of an ingress RLC channel. This effective PBR can be used to determine the data rate that the relay WTRU can guarantee to the ingress RLC channel within its hop. The effective PBR of the ingress RLC channel can be determined, for example, based on the PBR of the RLC channel, the priority of the RLC channel, and / or the CBR of the resource pool. For example, the WTRU can be configured with a scaling factor (e.g., alpha_PBR) to determine the percentage of the required data rate that the WTRU can commit to supporting the ingress RLC. For example, the scaling factor can be configured as a function of the CBR range of the resource pool and / or the priority of the RLC channel. For example, the effective PBR can be determined based on the scaling factor of the ingress RLC channel and / or the required PBR (e.g., the effective PBR can be equal to alpha_PBR multiplied by the PBR).

[0119] The WTRU can be configured using the examples of alpha_PBR shown in Table 1. In the examples shown in Table 1, the WTRU can be configured with a high (e.g., higher) alpha_PBR value (e.g., -(1)) for low CBR (e.g., 0-0.5) and / or high RLC channel priority (e.g., 1-2). In the examples shown in Table 1, the alpha_PBR can be smaller (e.g., less) (e.g., 0.8) for low CBR and / or low RLC channel priority (e.g., 6-8).

[0120] Table 1 – Examples of alpha_PBR for CBR based on RLC channel priority and resource pool A WTRU (e.g., a relay WTRU) can determine the PBR of an egress RLC channel. The PBR of an egress RLC channel can be determined, for example, based on one or more of the following (e.g., any combination of): the PBR of each ingress RLC channel; the number of ingress RLC channels mapped to the egress RLC channel; the number of parent nodes of ingress RLC channels mapped to the egress RLC channel; the priority associated with the ingress RLC channel; the priority associated with the egress RLC channel; and / or the CBR of the resource pool.

[0121] The WTRU can determine the PBR of an egress RLC channel, for example, based on the resource pool's CBR, PBR, and / or the priority of each ingress RLC mapped to the egress RLC. The WTRU can first determine the effective PBR of each ingress RLC channel, which can be a function of the ingress RLC channel's priority and / or the resource pool's CBR. The WTRU can (e.g., then) determine the PBR of the egress RLC channel, which can be a function of the effective PBRs of the ingress RLC channels mapped to the egress RLC channel. For example, the effective PBR of the egress RLC channel can be (e.g., the total effective PBR of all) ingress RLC channels.

[0122] The WTRU can (e.g., alternatively) determine the PBR of the egress RLC channel based on, for example, the CBR of the resource pool and / or the priority of the egress RLC channel. For instance, the PBR of the egress RLC channel can be equal to alpha_PBR multiplied by the sum of the PBRs from (e.g., all) ingress RLC channels. alpha_PBR can be a scaling factor, which can be configured as a function of, for example, the priority of the egress RLC channel and / or the CBR of the resource pool.

[0123] A WTRU can indicate the effective PBR of the ingress RLC channel to its parent nodes. A WTRU (e.g., a relay WTRU) can indicate information about the determined PBR to one or more parent nodes, which can be used by the parent nodes to control the data rate of the ingress RLC channel. In some examples, a WTRU can indicate a scaling factor (e.g., alpha_PBR) and / or the effective PBR to one or more parent nodes. In some examples, a WTRU can indicate the CBR of the resource pool to one or more parent nodes.

[0124] Figure 6 An example of prioritizing bit rate (PBR) determination is shown.

[0125] like Figure 6 As shown in the example, relay 1 and relay 2 can have an N-1 mapping between the ingress RLC channel and N egress RLC channels. (For example, each) relay WTRU can receive an indication of the PBR from the child node. The received PBR can be used to determine the PBR of the egress RLC channel. The WTRU can indicate the determined PBR to the child node and / or the parent node.

[0126] The WTRU can determine the RLC channel mode. The WTRU (e.g., a relay WTRU) can determine the transmission mode of the exit RLC, for example, based on the transmission mode of the ingress RLC channel, the PDB segmentation received from the previous node (e.g., the PDB between the WTRU and the destination), and / or the number of hops to the destination.

[0127] A WTRU (e.g., a relay WTRU) can be configured to perform one or more of the following operations. For example, based on PDB segments received from a node (e.g., a source WTRU or relay WTRU, a child node, a parent node, a sub-WTRU, a parent WTRU, a network node such as a gNB) and / or the number of hops to the destination, the WTRU can be configured with conditions for switching modes (e.g., enabling / disabling Hybrid Automatic Repeat Request (HARQ), switching to RLC Unacknowledged Mode (UM), enabling carrier replication). The WTRU can receive the configuration of the ingress RLC channel from the preceding node, which can include one or more of the following: replicated vs. non-replicated (e.g., multipath and multicarrier replicated) mode; RLC Acknowledged Mode (AM) vs. RLC UM mode; and / or HARQ enabled / disabled mode. The WTRU can receive PDB segments from the preceding node of the ingress RLC channel (e.g., from the WTRU to the destination). The WTRU can determine the configuration of the egress RLC channel. For example, based on PDB segments and / or the number of hops to the destination, the WTRU can determine whether to maintain the same mode or switch to a different mode compared to the ingress RLC channel. For example, if the PDB is less than a threshold, the WTRU can disable HARQ, switch to RLC UM mode, and / or enable replication mode. The WTRU can map received data from the ingress RLC to the egress RLC. The WTRU can perform transmissions based on the determined egress RLC channel configuration.

[0128] WTRUs can be configured with RLC channel modes. WTRUs (e.g., relay WTRUs) can be configured with one or more of the following transmission modes for RLC channels: multicarrier replication enabled / disabled mode; multipath replication enabled / disabled mode; RLCAM / UM mode; and / or HARQ enabled / disabled mode.

[0129] A WTRU can be configured with RLC channel mode switching. A WTRU (e.g., a relay WTRU) can be configured with one or more RLC channel transmission modes. A WTRU can (e.g., further) be configured with one or more conditions to switch from one RLC channel transmission mode to another. For example, if (multiple) configured conditions are met, the WTRU can switch between (e.g., two) RLC channel transmission modes. Conversely, if (e.g., if one or more switching conditions are not met), the WTRU can use the same RLC channel transmission mode as the ingress RLC channel. The (multiple) RLC channel transmission mode switching conditions can be based on one or more of the following parameters (e.g., any combination): the remaining E2E PDB of the egress RLC channel; the remaining hop count to the destination WTRU; the CBR of the resource pool; the priority of the ingress RLC channel; the priority associated with each ingress RLC channel; the priority associated with the egress RLC channel; and / or determined values ​​of one or more egress RLC parameters.

[0130] For RLC channel transmission handover, the WTRU can be configured with one or more of the following conditions (e.g., any combination): the remaining E2E PDB of the outgoing RLC channel may be less than the configured threshold; and / or the reliability requirement (e.g., PER) of the outgoing RLC channel may be greater than the threshold.

[0131] An RLC channel transmission handover can occur if the remaining E2E PDB of the outgoing RLC channel is less than a configured threshold. The threshold can be a function of the remaining hop count to the destination. The WTRU can determine the E2E PDB of the outgoing RLC channel (e.g., unilaterally or independently). The WTRU can (e.g., alternatively) receive the E2EPDB of the outgoing RLC channel from a child node or parent node. For example, the WTRU can determine the E2E PDB threshold based on the hop count to the destination. For example, if the E2E PDB is greater than the E2EPDB threshold, the WTRU can switch to another RLC channel transmission mode. For example, if this is not the case (e.g., if the E2EPDB is less than the E2E PDB threshold), the WTRU can maintain the same RLC channel transmission mode. For example, if the E2E PDB of the outgoing RLC channel is less than the configured threshold, the WTRU can switch from HARQ enabled to HARQ disabled, from RLC AM to RLCUM mode, and / or from multi-carrier / multipath replication disabled to multi-carrier / multipath replication enabled.

[0132] RLC channel transmission handover can occur when the reliability requirement (e.g., PER) of the outgoing RLC channel exceeds a threshold. For example, if the PER requirement of the outgoing RLC channel is greater than the configured threshold, the WTRU can switch from multi-carrier / multipath replication disabled to multi-carrier / multipath replication enabled, from RLC UM mode to RLC AM mode, and / or from HARQ disabled to HARQ enabled. If the PER requirement of the outgoing RLC channel is less than the configured threshold, the WTRU can maintain (e.g., skip the handover) the transmission mode.

[0133] A WTRU can request the source WTRU to stop a QoS flow. For example, upon receiving remaining E2E QoS information from another node (e.g., a parent or child node), a WTRU (e.g., a relay WTRU) can send an indication to the source WTRU to, for example, stop the established QoS flow. For example, the WTRU can send an indication if it may be unable to meet the QoS requirements of the flow. For example, the WTRU can send a QoS flow stop indication if the remaining E2E QoS is less than a configured threshold. The threshold can be a function of the resource pool's CBR, the number of hops to the destination, the WTRU's channel occupancy, the channel to the parent node, and / or the channel to the child node.

[0134] Figure 7 An example of WTRU mapping between the ingress RLC and the egress RLC is shown for multi-hop multipath relay.

[0135] For example, such as Figure 7 As shown, relay 1 can receive the ingress RLC channel from the source WTRU. The WTRU can receive the remaining E2E PDB of the ingress RLC channel. The relay WTRU can map the ingress RLC channel from the source WTRU to the egress RLC channel. The remaining E2E PDB may be less than a configured threshold. The WTRU can (e.g., then determine) switch from multicarrier replication disabled to multicarrier replication enabled, and / or switch from HARQ enabled to HARQ disabled to the egress RLC channel.

[0136] As described herein, the WTRU can receive the ingress configuration of the ingress RLC channel. The ingress configuration may indicate (e.g., be configured to indicate) the first RLC channel transmission mode. The ingress configuration can be received from a previous node. The WTRU may be or may include a relay WTRU.

[0137] WTRU can receive PDB segments from the ingress RLC channel. It can receive PDB segments from the previous node.

[0138] The WTRU can determine the transmission mode of the egress RLC channel. For example, the WTRU can determine the transmission mode of the egress RLC channel based on whether certain conditions are met. The WTRU can determine whether the conditions are met based on PDB segmentation and the remaining hop count from the WTRU to the destination. The egress RLC channel transmission mode can be a first RLC channel transmission mode (e.g., the same transmission mode as the ingress RLC channel transmission mode) or a second RLC channel transmission mode. The second RLC channel transmission mode can be different from the ingress RLC channel transmission mode.

[0139] In the example, based on the determination of satisfied conditions, the WTRU can switch from the first RLC channel transmission mode to the second RLC channel transmission mode. The WTRU can use the second RLC channel transmission mode for the egress RLC channel.

[0140] In the example, based on the determination that the condition is not met, the WTRU can maintain the first RLC channel transmission mode (e.g., skip the switching transmission mode). The WTRU can use the first RLC channel transmission mode for the egress RLC channel.

[0141] The first RLC channel transmission mode and the second RLC channel transmission mode can be or can include at least one of the following transmission modes: HARQ enabled transmission mode, HARQ disabled transmission mode, RLC UM, RLC AM, carrier replication enabled transmission mode, carrier replication disabled transmission mode, multipath replication enabled transmission mode, or multipath replication disabled transmission mode.

[0142] In the example, WTRU can determine if the PDB is less than a threshold. WTRU can determine if a condition is met based on the determination that the PDB is not less than the threshold. The threshold can be a function of the number of hops to the destination.

[0143] In the example, WTRU can determine whether a condition is not met based on whether the PDB is less than a threshold. The threshold can be a function of the number of hops to the destination.

[0144] For example, a WTRU can be configured with one or more (e.g., multiple) PDB thresholds. A PDB threshold (e.g., each of multiple PDB thresholds) can be associated with a hop count to the destination. The WTRU can determine the hop count to the destination. For example, the WTRU can determine the hop count to determine which PDB threshold to use. In the example, if the hop count to the destination is high, the WTRU can be configured with a higher PDB threshold. In the example, if the hop count to the destination is low, the WTRU can be configured with a lower PDB threshold.

[0145] This condition may include (for example, may further include) at least one of the following: end-to-end PDB associated with the egress RLC channel, channel occupancy associated with the resource pool, priority information associated with the ingress RLC channel, priority information associated with the egress RLC channel, or at least one egress RLC parameter. Examples of egress RLC parameters may be or may include reliability requirements, PBR, etc.

[0146] The WTRU can use the egress RLC channel transmission mode to transmit data. For example, based on this determination (e.g., whether the condition is met or not), the WTRU can use the egress RLC channel transmission mode to transmit data (e.g., if the condition is met, a second RLC channel transmission mode different from the ingress RLC channel transmission mode is used, or if the condition is not met, a first RLC channel transmission mode the same as the ingress RLC channel transmission mode is used).

[0147] A WTRU can utilize a common relay to determine the RLC channel mapping for multiple paths. For example, if the WTRU is a common relay WTRU for two paths of the source WTRU, then the WTRU (e.g., a common relay WTRU) can determine to map multiple (e.g., two) replicated ingress RLC channels (e.g., a primary RLC channel and a replicated RLC channel) from the same source to multiple (e.g., two) different egress RLC channels and / or constrain data from multiple (e.g., two) egress RLC channels to be transmitted in the same transport block (TB).

[0148] A WTRU (e.g., a common relay WTRU for two paths) can be configured to perform one or more of the following operations: The WTRU can receive (e.g., from the network) a set of available RLC channel configurations associated with (e.g., each) a QoS flow. The WTRU can receive (e.g., in PC5 Radio Resource Control (RRC)) primary and replica RLC channels from a source (e.g., one) with the same destination from one or more (e.g., two) previous nodes. The WTRU can map ingress RLC channels to separate egress RLC channels. For example, the WTRU can determine to map two ingress RLC channels to two separate egress RLC channels. The WTRU can impose constraints on packets from egress RLC channels (e.g., two egress RLC channels). For example, (e.g., two) RLC channels can be associated with (e.g., two) sets of orthogonal carriers. For example, if LCHs from other RLC channels are included, the WTRU can apply Logical Channel Prioritization (LCP) constraints to exclude Logical Channels (LCHs) from (e.g., one) RLC channel. For example, a WTRU can constrain the modulation and coding scheme (MCS) or increase the transmission (Tx) power from (e.g., both) RLC channels. The WTRU can transmit data from (e.g., each) an egress RLC channel based on the RLC channel configuration.

[0149] As described herein, the WTRU can receive a set of available RLC channel configurations. This set of available RLC channel configurations can be associated with QoS flows. For example, the WTRU can receive a first set of available RLC channel configurations associated with a first QoS flow and a second set of available RLC channel configurations associated with a second QoS flow.

[0150] A WTRU may be or may include a public trunk WTRU. For example, a WTRU may be determined to be or include a public trunk WTRU based on at least one of an indication from a node, a discovery process, a connection request establishment request, or an RLC channel configuration indication. The node may be or may include at least one of a source WTRU, a destination WTRU, a parent node, a child node, or a network described herein.

[0151] The WTRU can receive both the primary ingress RLC channel and the replica ingress RLC channel. The primary ingress RLC channel and the replica ingress RLC channel can have the same destination.

[0152] The WTRU can determine to map the primary ingress RLC channel to the primary egress RLC channel and the replicated ingress RLC channel to the replicated egress RLC channel. The primary egress RLC channel can be associated with a first orthogonal carrier set. The replicated egress RLC channel can be associated with a second orthogonal carrier set.

[0153] The WTRU can apply a first constraint to the primary egress RLC channel and a second constraint to the replica egress RLC channel. The WTRU can transmit packets. For example, the WTRU can transmit packets to the primary egress RLC channel and / or the replica egress RLC channel. In the example, the WTRU can transmit packets (e.g., a first packet) to the primary egress RLC channel based on a first set of available RLC channel configurations and the first constraint. In the example, the WTRU can transmit packets (e.g., a second packet) to the replica egress RLC channel based on a second set of available RLC channel configurations and the second constraint.

[0154] In the example, the first and second constraints can be, or can include, at least one of an MCS constraint, an LCH constraint, or a transmission (TX) power constraint. The TX constraint can be configured to increase the TX power associated with the egress RLC channel.

[0155] As described in this article, the WTRU can determine whether the primary egress RLC channel includes the LCH. Based on the determination that the primary egress RLC channel includes the LCH, the WTRU can apply an LCP constraint to the replicated egress RLC channel. The second constraint may or may not be an LCP constraint.

[0156] A WTRU can determine whether it is a multipath common relay WTRU from the source WTRU to the destination WTRU. A WTRU can determine whether it is a multipath common relay WTRU based on whether it participates in multipath data transmission / reception from the source WTRU to the destination WTRU. A WTRU (e.g., a path common relay WTRU) can determine whether it is a multipath common relay WTRU from the source WTRU to the destination WTRU, for example, based on one or more of the following (e.g., any combination): an indication from another node (e.g., the source WTRU, the destination WTRU, one of the parent nodes, a child node, a base station, such as a gNB); and / or determination based on one or more processes such as a discovery process, a connection establishment request, and / or an RLC channel configuration indication (e.g., self-determination).

[0157] For example, based on indications from another node (e.g., source WTRU, destination WTRU, parent node, child node, and / or base station, such as gNB), a WTRU (e.g., a common relay WTRU for a path) can determine whether it is a common relay WTRU in a multipath configuration from the source WTRU to the destination WTRU. The source WTRU, destination WTRU, (e.g., a) parent node, and / or child node can implicitly / explicitly indicate to the common relay WTRU that it is a common relay WTRU in a multipath configuration from the source WTRU to the destination WTRU. For example, a WTRU (e.g., source WTRU or destination) can perform relay WTRU selection for multipaths. (e.g., each) path can be associated with a sequence of WTRU IDs from the source WTRU to the destination WTRU. The WTRU can detect that the common WTRU has its WTRU ID in multiple paths from the source WTRU to the destination WTRU. The source WTRU can (e.g., then) implicitly / explicitly indicate to the common relay WTRU that it is a common relay in multiple paths from the source to the destination.

[0158] A WTRU (e.g., a common relay WTRU for a path) can determine, for example, based on determination (e.g., self-determination), whether it is a common relay WTRU with a multipath configuration from a source WTRU to a destination WTRU. This determination (e.g., self-determination) can be based on one or more processes, such as a discovery process, a connection establishment request, and / or an RLC channel configuration indication. For example, a common relay WTRU can receive / send one or more messages (e.g., discovery messages, direct communication requests, etc.) from / to multiple parent WTRUs with the same source WTRU. The WTRU can (e.g., then) determine that it is a common relay WTRU from source to destination. For example, the WTRU can receive RLC channel configurations from multiple (e.g., two) WTRUs, which can implicitly / explicitly indicate that one RLC channel is the primary channel and another RLC channel is a replica channel. The WTRU can (e.g., then) determine that it is a common relay WTRU with a multipath configuration from a source WTRU to a relay WTRU.

[0159] A WTRU can receive multiple replicated RLC channels. A multipath common trunk WTRU can receive RLC channel configurations from multiple parent WTRUs, which may include a primary RLC channel from (e.g., one) parent node and one or more replicated RLC channels from other parent nodes. (E.g., each) RLC channel (e.g., the primary RLC channel and one or more replicated RLC channels) may be referred to as an RLC replicated channel.

[0160] A WTRU can constrain the mapping of multiple duplicate RLC channels. A WTRU (e.g., a common trunk WTRU) can perform the mapping between ingress RLC duplicate channels and egress RLC channels. A WTRU can (e.g., determine) map (e.g., each) an ingress RLC channel to (e.g., always) a single egress RLC channel (e.g., a one-to-one mapping of ingress and egress RLC channels). A WTRU can (e.g., determine) constrain (e.g., always constrain) multiple (e.g., two) ingress RLC duplicate channels to (e.g., one) egress RLC channels. A WTRU can (e.g., always) map multiple (e.g., two) ingress RLC duplicate channels to multiple (e.g., two) individual egress RLC channels. For example, based on one or more conditions (e.g., with the resource pool's CBR, WTRU, and next...). The WTRU may map multiple (e.g., two) RLC replica channels to an exit RLC channel, depending on one or more conditions associated with the channel configuration between child nodes and / or the exit RLC channel configuration described herein. For example, if one or more configuration conditions are not met, the WTRU may map multiple (e.g., two) ingress RLC replica channels to a single RLC channel. The WTRU may determine whether to map multiple (e.g., two) ingress RLC replicas to a single exit RLC channel, for example, based on one or more of the following (e.g., any combination): the CBR of the resource pool; the channel between the WTRU and the next child node; and / or the configuration of the exit RLC channel.

[0161] For example, based on the resource pool's CBR, the WTRU can determine whether to map multiple (e.g., two) ingress RLC replication channels to a single egress RLC channel. For instance, if the resource pool's CBR is less than a configured threshold, the WTRU may map multiple (e.g., two) ingress RLC replication channels to a single egress RLC channel. Conversely, if this is not the case (e.g., if the resource pool's CBR is greater than a configured threshold), the WTRU may not map multiple (e.g., two) ingress RLC replication channels to the same egress RLC channel.

[0162] For example, based on the channel between the WTRU and the next child node, the WTRU can determine whether to map multiple (e.g., two) ingress RLC replicas to a single egress RLC channel. For instance, if the SL-RSRP / SD-RSRP between the WTRU and the child node is greater than a configured threshold, the WTRU may map multiple (e.g., two) ingress RLC replica channels to a single egress RLC channel. Conversely, if this is not the case (e.g., if the SL-RSRP / SD-RSRP between the WTRU and the child node is less than a configured threshold), the WTRU may not map multiple (e.g., two) ingress RLC replica channels to the same egress RLC channel.

[0163] For example, based on the configuration of the egress RLC channel, the WTRU can determine whether to map multiple (e.g., two) ingress RLC copy channels to one egress RLC channel. For example, if the priority of the egress RLC channel is greater than a configured threshold, the WTRU can map multiple (e.g., two) ingress RLC copy channels to one egress RLC channel. For example, if the egress RLC channel is configured with HARQ enabled, the WTRU can map multiple (e.g., two) ingress RLC copy channels to one egress RLC channel. For example, if the egress RLC channel is configured with multi-carrier / multipath copy enabled, the WTRU can map multiple (e.g., two) ingress RLC copy channels to one egress RLC channel.

[0164] WTRUs can enhance the reliability of (e.g., each) replicated RLC channels. WTRUs can (e.g., then) perform one or more of the following operations (e.g., any combination) on data from exit RLC channels associated with one or more ingress RLC replicate channels (e.g., due to reduced multipath diversity gain caused by having a common relay WTRU, thus contributing to improved reliability of RLC replicated data); for example, configuring (e.g., each) exit RLC channels associated with (e.g., one) ingress RLC replicate channels with orthogonal carrier sets compared to another exit RLC channel associated with another ingress RLC replicate channel; configuring to constrain data from multiple (e.g., two) exit RLC channels associated with multiple (e.g., two) ingress RLC replicate channels to be multiplexed in the same TB; and / or adjusting one or more parameters of the exit RLC channel configuration, for example, compared to the ingress RLC replicate channels.

[0165] For example, compared to another exit RLC channel associated with another ingress RLC replication channel, the WTRU can use orthogonal carrier sets to configure (e.g., each) exit RLC channel associated with (e.g., one) ingress RLC replication channel. Orthogonal carrier sets can be used to allow replicated data to be transmitted on different carriers.

[0166] The WTRU can be configured to constrain data from multiple (e.g., two) egress RLC channels associated with multiple (e.g., two) ingress RLC replication channels to be multiplexed within the same TB. For example, this constraint can be enforced using a Logical Channel Prioritization (LCP) procedure. For instance, after selecting the LCH associated with (e.g., one) ingress RLC replication channel, the WTRU can select which logical channel (LCH) to multiplex in (e.g., one) MAC PDU. The WTRU can exclude one or more (e.g., all) LCHs associated with another ingress RLC replication channel to be multiplexed in the MAC PDU.

[0167] Compared to the ingress RLC replica channel, the WTRU can adjust one or more parameters of the egress RLC channel configuration. For example, for an egress RLC channel associated with an ingress RLC replica channel, the WTRU can enable HARQ feedback, switch to AM mode, enable multi-carrier / multipath replication, and increase the priority and / or reliability (e.g., PER) of the egress RLC channel compared to the priority of the ingress RLC channel. For example, the WTRU can configure the egress RLC channel to use a limited set of MCSs (e.g., low-index MCS) or increase the transmission power of the configured offset.

[0168] In some examples (e.g., such as) Figure 8 As shown), relay 3 can be a multipath common relay WTRU from the source WTRU to the destination WTRU. Relay 3 can receive multiple (e.g., two) ingress RLC copy channels from relay 1 and relay 2. The WTRU can map multiple (e.g., two) RLC channels to multiple (e.g., two) individual RLC channels. The WTRU can use multiple (e.g., two) carriers to transmit the RLC channels.

[0169] Figure 8 An example of multipath with a common relay WTRU between multiple (e.g., two) paths is shown.

[0170] A WTRU can apply RLC channel mapping constraints to multipaths with a common relay. For example, when establishing a QoS flow with multipath replication enabled, a WTRU (e.g., a source WTRU) can (e.g., determine) request (e.g., each) a relay WTRU in the path to constrain a one-to-one mapping between replicating ingress RLC channels (e.g., primary ingress RLC and replica ingress RLC) and egress RLC channels. For example, if a WTRU has a common relay WTRU across multiple (e.g., two) paths, the WTRU can forward that request to one or more subsequent relays.

[0171] A WTRU (e.g., a source WTRU) can be configured to perform one or more of the following operations: The WTRU can be configured with multipath from source to destination. The WTRU can establish a multipath radio bearer with multiple (e.g., two) associated exit RLC channels in (e.g., two) paths (e.g., a primary RLC channel and a replica RLC channel). The WTRU can receive path information (e.g., a list of relay WTRU IDs for one / each path). The WTRU can (e.g., if the two paths have a common relay) send a request to (e.g., two) first relays in (e.g., two) paths to perform one or more of the following: constrain a one-to-one mapping between the ingress RLC channel and the exit RLC channel; and / or forward the request to subsequent relay WTRUs until the common relay. The WTRU can use multiple (e.g., two) associated replica exit RLC channels in multiple (e.g., two) configured paths to transmit data for the multipath radio bearer.

[0172] A WTRU can establish a QoS flow with (e.g., requiring) multipath replication enabled. A WTRU (e.g., a source WTRU) can establish a QoS flow, which may require multipath replication enabled. A WTRU can map the QoS flow to multiple RLC channels. Each RLC channel can be transmitted to (e.g., one) path. The primary RLC channel can be transmitted in the primary path, and each replicated channel can be transmitted in another path.

[0173] A WTRU can determine whether it has a common relay WTRU for multipath. A WTRU (e.g., a source WTRU) can determine whether it is a common relay WTRU for multipath, for example, based on the set of WTRU IDs associated with each path. For example, if (e.g., one) WTRU ID (e.g., a relay WTRU ID) is common in multiple (e.g., two) or more paths, the WTRU can determine that multiple (e.g., two) paths have a common relay WTRU. For example, when a WTRU is performing path selection, the WTRU can obtain (e.g., determine) path information (e.g., the set of WTRU IDs in each path) from the discovery, relay selection, and / or path selection process. A WTRU can (e.g., alternatively) obtain (e.g., determine) path information from another node (e.g., from the destination WTRU, which can perform the path selection process).

[0174] The WTRU can send requests, such as RLC channel mapping constraint requests, to its child nodes. For example, when establishing a QoS flow with multipath replication enabled, the WTRU can send a mapping constraint request, which can be sent, for example, via NAS (e.g., PC5-S) or PC5 RRC messages to the set of child nodes associated with multipath replication. This request can include one or more of the following (e.g., any combination): constraining a one-to-one mapping between ingress RLC replicated channels and egress RLC channels; and / or forwarding the request along the path to the destination WTRU to subsequent relay WTRUs, up to the common relay WTRU.

[0175] A relay WTRU can apply an RLC mapping request from a source WTRU. A child node (e.g., a child relay WTRU) can (e.g., then) apply a one-to-one constraint, for example, by mapping an ingress RLC replica channel to a separate egress RLC channel. The WTRU can (e.g., then) send an egress RLC channel configuration to its child nodes. This configuration can indicate a one-to-one mapping constraint on its egress RLC channels. This indication can be, for example, by a one-to-one constraint flag in a message that includes the RLC channel configuration, which can help the public relay WTRU distinguish data from the RLC replica channel and / or implement one or more processes to improve the reliability of data from the RLC replica channel.

[0176] A WTRU can receive RLC replication channel mapping information from a public trunk WTRU. A WTRU (e.g., a source WTRU) can receive messages from another WTRU (e.g., a public trunk WTRU) indicating mapping information for its RLC replication channels. The public trunk WTRU can implicitly / explicitly indicate that one-to-one mapping constraints for RLC replication channels may not be required. For example, the public trunk WTRU can apply similar configurations to replicated and non-replicated RLC channels. Upon receiving an indication from a public trunk WTRU, the WTRU can, for example, forward constraint releases (e.g., one-to-one mapping constraint releases for RLC replication channels) to the child node. In some examples, the child node can reconfigure its RLC replication channel. In some examples, the child node can maintain the same configuration.

[0177] Figure 9 An example is shown where the source WTRU sends a 1-to-1 mapping request for multiple (e.g., two) replicated RLC channels.

[0178] In some examples (e.g., such as) Figure 9As shown, the source WTRU may have multipath connections with the destination WTRU. The multipath may have relay 4 as a common relay WTRU. For example, when establishing a QoS flow with multipath replication enabled, the source WTRU may send a one-to-one RLC mapping constraint for its RLC replication channel to relays 1 and 2. Relay 1 may (e.g., then) apply this constraint to the ingress RLC replication channel and send it to relay 3. Relay 2 may apply a one-to-one constraint, for example, because it is already directly connected to the common relay WTRU.

[0179] As described herein, a WTRU can establish multipaths associated with ingress and egress RLC channels. The ingress RLC channel may or may include a primary ingress RLC channel and a replicated ingress RLC channel. The egress RLC channel may or may include a primary egress RLC channel and a replicated egress RLC channel. The multipath includes a first path associated with the primary egress RLC channel and a second path associated with the replicated egress RLC channel. In the example, the WTRU can receive a multipath configuration. This configuration may or may include a multipath QoS flow with multipath replication enabled. Based on this configuration, the WTRU can establish, for example, multipaths associated with ingress and egress RLC channels.

[0180] The WTRU receives path information. For example, the WTRU may receive first path information and second path information. The first path information may be associated with a first path, and the second path information may be associated with a second path. The first path information may be or may include a list of relay WTRU IDs in the first path. The second path information may be or may include a list of relay WTRU IDs in the second path. The first path information and / or the second path information may be received from at least one of the following: a discovery process, a relay selection process, a path selection process, or an indication from the destination WTRU performing the path selection process.

[0181] The WTRU can determine that the first path associated with the first path and the second path associated with the second path have the same trunk. For example, the same trunk can be or may include a common trunk. For example, the WTRU can determine that the first and second paths have a common trunk based on a list of trunk WTRU IDs in the first and second paths. For example, the WTRU can determine that a WTRU ID from the list of trunk WTRU IDs in the first path matches a WTRU ID from the list of trunk WTRU IDs in the second path.

[0182] Based on the determination that the first path associated with the first path and the second path associated with the second path share a common relay, the WTRU can send a request to the first relay associated with the first path and the second relay associated with the second path. The first relay may be associated with a first group of child nodes, and the second relay may be associated with a second group of child nodes. The WTRU can send the request using at least one of a NAS message or a PC5 RRC message. The request may be or may include a mapping constraint that governs a one-to-one mapping between ingress RLC channels and egress RLC channels. The one-to-one mapping may or may include mapping a primary ingress RLC channel to a primary egress RLC channel and / or mapping a replicated ingress RLC channel to a replicated egress RLC channel.

[0183] WTRU can determine that the first relay associated with the first path and the second relay associated with the second path are common relays. Based on the determination that the first and second relays are common relays, WTRU can apply mapping constraints to the first and second relays.

[0184] In the example, the WTRU can determine that the first relay associated with the first path and the second relay associated with the second path are not common relays. Based on the determination that the first and second relays are not common relays, the WTRU can forward the request to one or more subsequent relays until a common relay is found. For example, based on the determination that the first relay associated with the first path and the second relay associated with the second path are not common relays, the WTRU can forward the request to a third and a fourth relay. The third relay can be a subsequent relay of the first relay, and the fourth relay can be a subsequent relay of the second relay. The third relay can be associated with a third path, and the fourth relay can be associated with a fourth path. As described herein, the request can be or can include a mapping constraint that constrains a one-to-one mapping between ingress RLC channels and egress RLC channels. A one-to-one mapping can be or can include mapping a primary ingress RLC channel to a primary egress RLC channel and / or mapping a replicated ingress RLC channel to a replicated egress RLC channel.

[0185] WTRU can determine that the third relay associated with the third path and the fourth relay associated with the fourth path are common relays. Based on the determination that the third and fourth relays are common relays, WTRU can apply mapping constraints to the third and fourth relays.

[0186] The WTRU can determine that the third relay associated with the third path and the fourth relay associated with the fourth path are not common relays. Based on the determination that the third and fourth relays are not common relays, the WTRU can continue to forward the request to the fifth and sixth relays. The fifth relay can be a successor relay of the third relay, and the sixth relay can be a successor relay of the fourth relay. The fifth relay can be associated with the fifth path, and the sixth relay can be associated with the sixth path. The WTRU can perform RLC channel mapping based on the PBR. For example, based on an effective total PBR not exceeding the (pre)configured PBR, the WTRU (e.g., a relay WTRU) can determine ingress RLC channels (e.g., new ingress RLC channels) with similar remaining PDBs to map to the same egress RLC channel.

[0187] A WTRU (e.g., a relay WTRU) can be configured to perform one or more of the following operations: The WTRU can establish an egress RLC channel to map to one or more ingress RLC channels. The WTRU can receive new ingress RLC channels. For example, the WTRU can configure the (e.g., effective) PBR of the RLC channel based on priority and Channel Occupancy Rate (CBR). The WTRU can determine that the new ingress RLC channel and the established egress RLC channel are similar. For example, if the PDB difference between two RLC channels is less than a configured threshold, then (e.g., the two) RLC channels can be similar. For example, if (e.g., the two) RLC channels have the same priority, then they can be similar. The WTRU can determine whether to map the new ingress RLC channel to an existing RLC channel, for example, based on the PBR and (e.g., the priority of all) ingress RLC channels (e.g., existing RLC channels mapped to the egress RLC channel and the new ingress RLC channel), the configured PBR of the egress RLC channel, and / or the CBR of the resource pool. In some examples, the WTRU may map a new RLC channel to an existing RLC channel based on one or more of the following conditions: (e.g., the sum of the configured PBRs of all) ingress RLC channels does not exceed a threshold; or (e.g., the sum of the effective PBRs of all) ingress RLC channels does not exceed the configured PBR of the egress RLC channel. For example, the WTRU may determine the alpha_PBR of each ingress RLC channel, for example, based on the priority of the RLC channel and the CBR of the resource pool. The WTRU may determine the sum of the effective PBRs of all) ingress RLC channels as (e.g., equal to) the sum of the PBRs of all) ingress RLC channels multiplied by the associated alpha_PBR. The WTRU may (e.g., otherwise) map a new ingress RLC channel to a new egress RLC channel. For example, if / when a packet associated with a new ingress RLC channel is received, the WTRU may transmit that packet on the determined egress RLC channel.

[0188] A WTRU can receive a new ingress RLC channel configuration. A WTRU (e.g., a relay WTRU) can receive a new ingress RLC channel configuration to request a WTRU mapping to its egress RLC channel and forward it to the destination WTRU. For example, the new ingress RLC channel can come from an existing parent node (e.g., an existing source WTRU) or from a new parent node (e.g., a new source WTRU).

[0189] The WTRU can determine whether multiple (e.g., two) RLC channels are similar. The WTRU can (e.g., firstly) determine whether a new ingress RLC channel is similar to an egress RLC channel. For example, the WTRU can determine whether multiple (e.g., two) RLC channels are similar based on the difference between one or more parameters in the RLC configuration of the multiple (e.g., two) RLC channels. For example, if the function of the difference between one or more parameters of the multiple (e.g., two) RLC channels is less than a configured threshold, the WTRU can determine that the multiple (e.g., two) RLC channels are similar. For example, if, conversely, the function of the difference between one or more parameters of the multiple RLC channels is greater than a configured threshold, the WTRU can determine that the multiple (e.g., two) RLC channels are not similar. For example, if multiple (e.g., two) RLC channels have the same priority and / or a PDB difference within a configured threshold, they can be determined to be similar. For example, if multiple (e.g., two) RLC channels have the same RLC mode, the same priority, and / or a PDB difference less than a configured threshold, they can be determined to be similar. For example, the WTRU can (e.g., alternatively) determine whether a new ingress RLC channel is similar to an existing egress RLC channel based on the similarity between the new RLC channel and one or more existing ingress RLC channels mapped to the egress RLC channel. The similarity between the new RLC channel and one or more existing ingress RLC channels can be determined, for example, by similar techniques described herein.

[0190] The WTRU can determine whether a new ingress RLC channel should be mapped to a similar existing egress RLC channel. In some examples, the WTRU can determine whether a new ingress RLC channel can be mapped to an existing egress RLC channel. If multiple (e.g., two) RLC channels are dissimilar, the WTRU can (e.g., firstly) determine that they are not mappable. For example, based on the PBR and priority of (e.g., all) ingress RLC channels (e.g., existing ingress RLC channels mapped to egress RLC channels and the new ingress RLC channel), the configuration PBR of the egress RLC channel, and / or the CBR of the resource pool, the WTRU can determine whether multiple (e.g., two) RLC channels are mappable. For example, the WTRU can map a new RLC channel to an existing RLC channel based on one or more of the following conditions: (e.g., the sum of the configuration PBRs of all) ingress RLC channels does not exceed a threshold; and / or (e.g., the sum of the valid PBRs of all) ingress RLC channels does not exceed the configuration PBR of the egress RLC channel. For example, the WTRU can determine the alpha_PBR of (e.g., each) ingress RLC channel based on the priority of the RLC channel and / or the CBR of the resource pool. The sum of the effective PBRs of (e.g., all) ingress RLC channels can be equal to (e.g., the PBRs of all) ingress RLC channels multiplied by the sum of the associated alpha_PBRs.

[0191] The WTRU can (e.g., otherwise) determine that a new ingress RLC channel may not be mapped to an existing RLC channel. For example, upon receiving data arriving from a new ingress RLC channel, the WTRU can map that data to the determined egress RLC channel. The WTRU can then perform data transmission based on the configuration of the egress RLC channel.

[0192] The WTRU can determine whether to modify the configuration of an existing egress RLC channel. For example, if a new ingress RLC channel is similar to an existing RLC channel, the WTRU can map the new ingress RLC channel to an existing RLC channel. For example, the WTRU can (e.g., then) update the PBR of an RLC channel using the procedures described herein. The WTRU can update one or more child nodes and parent nodes with respect to the updated existing egress RLC channel.

[0193] Figure 10 An example is shown of how WTRU determines whether to map a new ingress RLC channel to an existing egress RLC channel.

[0194] In some examples (e.g., such as) Figure 10As shown, a relay WTRU can have multiple (e.g., two) ingress RLC channels from source 1 and source 2 mapped to existing egress RLC channels. A new source WTRU can establish a new ingress RLC channel. A new source WTRU can send channel configuration to the relay WTRU. The WTRU can map (e.g., determine the mapping) the new ingress RLC channel to an existing egress RLC channel.

[0195] As described herein, a WTRU can establish an egress RLC channel to map to at least one ingress RLC channel. At least one ingress RLC channel can be associated with a first ingress RLC channel. A WTRU can be or may include a relay WTRU.

[0196] The WTRU can receive a second ingress RLC channel. In the example, the WTRU can receive the second ingress RLC channel from an existing parent node. The existing parent node can be associated with the source WTRU. In the example, the WTRU can receive the second ingress RLC channel from a new parent node. The new parent node can be associated with a new source WTRU.

[0197] The WTRU can determine whether to map a second ingress RLC channel to an egress RLC channel based on at least one of a first priority bit rate (PBR) associated with a first ingress RLC channel, a first priority information associated with the first ingress RLC channel, a second PBR associated with a second RLC channel, a second priority information associated with the second RLC channel, or a CBR associated with a resource pool. For example, the WTRU can determine whether to map a second ingress RLC channel to an egress RLC channel based on whether a condition is met. This condition may be, or may include, determining that the sum of the first PBR and the second PBR is less than a threshold, or determining that the sum of the first PBR and the second PBR is less than a configuration PBR associated with the egress RLC channel. Based on the determination that the condition is met, the WTRU can map the second ingress RLC channel to the egress RLC channel. Based on the determination that the condition is not met, the WTRU can map the second ingress RLC channel to another egress RLC channel (e.g., a second egress RLC channel).

[0198] The WTRU can receive at least one packet associated with the second ingress RLC channel. Based on the determination of mapping the second ingress RLC channel to the egress RLC channel, the WTRU can send at least one packet (e.g., from the second ingress RLC channel) to the egress RLC channel.

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

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

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

Claims

1. A wireless transmit / receive unit (WTRU), comprising: The processor is configured as follows: Receive first priority information and a first indication of the first priority bit rate (PBR) associated with the first ingress radio link control (RLC) channel; Receive second priority information associated with the second ingress RLC channel and a second indication of the second PBR; The third PBR is determined based on at least one of the first PBR, first priority information, second PBR, or second priority information, wherein the third PBR is associated with the egress RLC channel; as well as Send a third instruction, wherein the third instruction indicates the third PBR.

2. The WTRU according to claim 1, wherein, The WTRU includes a relay WTRU.

3. The WTRU according to claim 1, wherein, The processor is also configured to: Determine the Channel Ratio (CBR) associated with the resource pool.

4. The WTRU of claim 3, wherein the third PBR is further determined based on the CBR.

5. The WTRU of claim 1, wherein the first ingress RLC channel is associated with a first parent node, and the second ingress RLC channel is associated with a second parent node.

6. The WTRU of claim 1, wherein the first ingress RLC channel is associated with the parent node, and the second ingress RLC channel is associated with the parent node.

7. The WTRU according to claim 1, wherein, The processor is configured to: Map the first and second ingress RLC channels to the egress RLC channels.

8. The WTRU according to claim 1, wherein, The processor is also configured to: Identify the CBR associated with the resource pool; Based on at least one of the first PBR, first priority information, or CBR associated with the resource pool, determine the first valid CBR associated with the first ingress RLC channel; Based on at least one of the second PBR, second priority information, or CBR associated with the resource pool, determine the second valid CBR associated with the second ingress RLC channel; as well as Send a fourth indication to at least one of the parent node or child node, wherein the fourth indication indicates at least one of the first valid PBR or the second valid PBR.

9. The WTRU according to claim 1, wherein, The third instruction is sent to at least one of the parent node or child node.

10. A method performed by a wireless transmit / receive unit (WTRU), comprising: Receive first priority information and a first indication of the first priority bit rate (PBR) associated with the first ingress radio link control (RLC) channel; Receive second priority information associated with the second ingress RLC channel and a second indication of the second PBR; The third PBR is determined based on at least one of the first PBR, first priority information, second PBR, or second priority information, wherein the third PBR is associated with the egress RLC channel; as well as Send a third instruction, wherein the third instruction indicates the third PBR.

11. The method according to claim 10, wherein, The WTRU includes a relay WTRU.

12. The method according to claim 10, wherein, The method further includes: Determine the Channel Ratio (CBR) associated with the resource pool.

13. The method of claim 12, wherein the third PBR is further determined based on the CBR.

14. The method of claim 10, wherein the first ingress RLC channel is associated with a first parent node, and the second ingress RLC channel is associated with a second parent node.

15. The method of claim 10, wherein the first ingress RLC channel is associated with a parent node, and the second ingress RLC channel is associated with the parent node.

16. The method of claim 10, wherein the method comprises: Map the first and second ingress RLC channels to the egress RLC channels.

17. The method of claim 10, wherein the method comprises: Identify the CBR associated with the resource pool; Based on at least one of the first PBR, first priority information, or CBR associated with the resource pool, determine the first valid CBR associated with the first ingress RLC channel; Based on at least one of the second PBR, second priority information, or CBR associated with the resource pool, determine the second valid CBR associated with the second ingress RLC channel; as well as Send a fourth indication to at least one of the parent node or child node, wherein the fourth indication indicates at least one of the first valid PBR or the second valid PBR.

18. The method of claim 10, wherein the third instruction is sent to at least one of the parent node or child node.

Images