Method, architecture, apparatus, and system for quality of service (QOS) enforcement at the media access control (MAC) layer - Patents.com

Abstract

The present disclosure relates to methods and apparatus for quality of service (QoS) enforcement at the media access control (MAC) layer, and more particularly, to methods and apparatus for prioritizing sidelink and uplink data transmissions in a network.

Description

[Technical field]

[0001] (CROSS REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 249,682, filed September 29, 2021, which is incorporated herein by reference.

[0002] The present disclosure relates to a method and apparatus for enforcing quality of service at a Media Access Control (MAC) layer, and more particularly, to a method and apparatus for prioritizing sidelink and uplink data transmissions in a network. [Background technology]

[0003] The 3GPP Release 17 study on NR sidelink relay [1] will study the use of both WTRU-to-network relay and WTRU-to-WTRU relay (sidelink) based on PC5, and specifically focused on the reasons / objectives of the study item.

[0004] For Release 16, the first version of the NR sidelink is being developed, which is solely focused on supporting Vehicle to Anything (V2X) related road safety services. The design aims to provide support for broadcast, groupcast, and unicast communications in both out-of-coverage and in-network coverage scenarios. Additionally, for sidelink / network coverage extension and power efficiency improvement, sidelink-based relay functionality should be further studied to consider a wider range of applications and services.

[0005] Further exploration of coverage extension for sidelink-based communications is needed for WTRU-to-network coverage extension. Uu coverage reachability is necessary for a WTRU to reach a server in a Packet Data Network (PDN) or to reach a counterpart WTRU when it is out of the network vicinity. However, the Rel-13 solutions for WTRU-to-network relay are limited to EUTRA-based technologies and therefore cannot be applied to NR-based systems for both NG-RAN and NR-based sidelink communications.

[0006] Further exploration of coverage extension for sidelink-based communication is also needed for WTRU-to-WTRU coverage extension. Currently, proximity reachability is limited to a single-hop sidelink link, either via EUTRA-based sidelink technology or NR-based sidelink technology. However, it is not sufficient in scenarios where Uu coverage does not exist, considering the limited single-hop sidelink coverage.

[0007] Overall, in the NR framework, sidelink connectivity should be further extended to support enhanced QoS requirements.

[0008] The detailed objective of the aforementioned Rel17 Study Item [1] is to study single-hop NR sidelink relay as a research mechanism with minimal specification impact to support SA requirements for sidelink based WTRU-to-network relay, and WTRU-to-WTRU relay, focusing on any of the following aspects (where applicable) for Layer 3 relay and Layer 2 relay [RAN2]: relay (re)selection criteria and procedures, relay / remote WTRU authorization, QoS for relay function, service continuity, security of relay connections after SA3 has provided its conclusions, and user plane protocol stack and control plane procedures, e.g., impact on connection management of relay connections.

[0009] The specific objective of the aforementioned Rel17 research item [1] is to further investigate single-hop NR sidelink relay as a research mechanism to support higher layer operation of discovery models / procedures for sidelink relay, assuming no new physical layer channels / signals [RAN2].

[0010] The study shall take into account further input from the SA WGs, e.g., SA2 and SA3, for each of the above items (if applicable). WTRU-to-network relay and WTRU-to-WTRU relay are assumed to use the same relay solution. Forward compatibility for multi-hop relay support in future releases needs to be considered. For Layer 2 WTRU-to-network relay, end-to-end PDCP and hop-by-hop Radio Link Control (RLC) architecture will be adopted as a starting point, as recommended, e.g., in TR36.746. Summary of the Invention

[0011] In one embodiment, a method implemented in a Wireless Transmit / Receive Unit (WTRU) may include determining a first priority level of an uplink data transmission based on a priority level of a first uplink logical channel. The method may further include determining a second priority level of a sidelink data transmission based on a priority level of a second uplink logical channel, the second uplink logical channel corresponding to a sidelink logical channel associated with the sidelink data transmission. The method may further include transmitting one of the sidelink data transmission or the uplink data transmission based on a comparison between the first priority level and the second priority level.

[0012] In one embodiment, the method includes determining a priority level of a second uplink logical channel, where determining the priority level of the second uplink logical channel may include determining one or more uplink logical channels associated with the sidelink logical channel, and determining the priority level of the second uplink logical channel based on the determined one or more uplink logical channels.

[0013] The priority level of the second uplink logical channel may correspond to a maximum priority level or a minimum priority level among the one or more uplink logical channels.

[0014] In response to the priority level of the sidelink logical channel exceeding the sidelink threshold, the priority level of the second uplink logical channel may correspond to a maximum priority level among the one or more uplink logical channels.

[0015] In response to the priority level of the sidelink logical channel falling below the sidelink threshold, the priority level of the second uplink logical channel may correspond to a minimum priority level among the one or more uplink logical channels.

[0016] The method may include determining that an uplink data transmission will overlap with a sidelink data transmission.

[0017] The method may include determining that a sidelink data transmission from the WTRU corresponds to a Layer 2 destination of the remote WTRU.

[0018] The sidelink logical channel may be the highest priority sidelink logical channel for sidelink data transmission or the lowest priority sidelink logical channel for sidelink data transmission.

[0019] Transmitting one of the sidelink data transmission or the uplink data transmission may include transmitting the one having a higher priority level.

[0020] The comparison between the first priority level and the second priority level may be a direct comparison.

[0021] The second uplink logical channel may be mapped from an adaptation layer mapping of the WTRU to a sidelink logical channel associated with the sidelink data transmission.

[0022] The second uplink logical channel may include quality of service (QoS) requirements that map to a sidelink logical channel associated with the sidelink data transmission.

[0023] In one embodiment, a wireless transmit / receive unit (WTRU) may comprise a processor, a transceiver unit, and a storage unit and may be configured to determine a first priority level of an uplink data transmission based on a priority level of a first uplink logical channel. The WTRU may be further configured to determine a second priority level of a sidelink data transmission based on a priority level of a second uplink logical channel, the second uplink logical channel corresponding to a sidelink logical channel associated with the sidelink data transmission.

[0024] The WTRU may be further configured to transmit one of a sidelink data transmission or an uplink data transmission based on a comparison between the first priority level and the second priority level.

[0025] The WTRU may be further configured to determine a priority level of the second uplink logical channel, where determining the priority level of the second uplink logical channel may include determining one or more uplink logical channels associated with the sidelink logical channel and determining the priority level of the second uplink logical channel based on the determined one or more uplink logical channels.

[0026] The priority level of the second uplink logical channel may correspond to a maximum priority level or a minimum priority level among the one or more uplink logical channels.

[0027] In response to the priority level of the sidelink logical channel exceeding the sidelink threshold, the priority level of the second uplink logical channel may correspond to a maximum priority level among the one or more uplink logical channels.

[0028] In response to the priority level of the sidelink logical channel falling below the sidelink threshold, the priority level of the second uplink logical channel may correspond to a minimum priority level among the one or more uplink logical channels.

[0029] The WTRU may be configured to determine that an uplink data transmission will overlap with a sidelink data transmission.

[0030] The WTRU may be configured to determine that a sidelink data transmission from the WTRU corresponds to a Layer 2 destination of a remote WTRU.

[0031] The sidelink logical channel may be the highest priority sidelink logical channel for sidelink data transmission or the lowest priority sidelink logical channel for sidelink data transmission.

[0032] Transmitting one of the sidelink data transmission or the uplink data transmission may include transmitting the one having a higher priority level.

[0033] The comparison between the first priority level and the second priority level may be a direct comparison.

[0034] The second uplink logical channel may be mapped from an adaptation layer mapping of the WTRU to a sidelink logical channel associated with the sidelink data transmission.

[0035] The second uplink logical channel may include quality of service (QoS) requirements that map to a sidelink logical channel associated with the sidelink data transmission. [Brief description of the drawings]

[0036] A more detailed understanding may be had from the following detailed description, given by way of example in conjunction with the drawings that accompany this specification. Such drawing figures, like the detailed description, are illustrative. Thus, the figures and detailed description should not be considered as limiting, as other equally effective embodiments are possible and likely to be. Moreover, like reference numbers ("ref") within the drawings ("FIG") indicate like elements. [Figure 1A] 1 is a system diagram illustrating a representative communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] 1 is a system diagram illustrating a representative wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A, according to one embodiment. [Figure 1C] 1 is a system diagram illustrating an exemplary radio access network (RAN) and an exemplary core network (CN) that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 1D]1B is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Diagram 2] FIG. 1 illustrates a protocol stack for the user plane for Layer 2 evolved WTRU-to-network relay. [Diagram 3] FIG. 1 illustrates a protocol stack for a control plane for a Layer 2 evolved WTRU-to-network relay. [Figure 4] FIG. 1 illustrates a particular shortcoming in a 3GPP Rel. 16 network system relating to channel prioritization for SL and UL channels. [Diagram 5] FIG. 1 illustrates a particular shortcoming in a 3GPP Rel. 17 network system relating to channel prioritization for SL and UL channels. [Figure 6] 1 is a flow chart illustrating a channel prioritization method for SL and UL, according to one embodiment. [Figure 7] 11 is a flowchart illustrating an example of a method implemented in a WTRU for determining whether to prioritize uplink or sidelink transmissions. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0037] In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the embodiments and / or examples disclosed herein. It will be understood, however, that such embodiments and examples may be practiced without some or all of the specific details set forth herein. In other instances, well-known methods, procedures, components and circuits have not been described in detail so as not to obscure the following description. Furthermore, embodiments and examples not specifically described herein may be practiced in place of, or in combination with, the embodiments and other examples explicitly, implicitly and / or inherently described, disclosed or otherwise provided herein (collectively "provided").

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

[0039] 1A, communications 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, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and / or “STA,” may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, paging, mobile phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things devices, watches or other wearable, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., for remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain context), consumer electronics devices, devices operating in commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as a UE.

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

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

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

[0043] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as, for example, CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base stations 114a and the WTRUs 102a, 102b, 102c in the RAN 104 / 113 may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115 / 116 / 117 using wideband CDMA (WCDMA). WCDMA may include communications 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 ​​Uplink Packet Access (HSUPA).

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

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

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

[0047] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a wireless technology such as IEEE 802.11 (i.e., Wireless Fidelity, WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access, WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), or the like.

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

[0049] The RAN 104 / 113 may communicate with the CN 106 / 115, which may be any type of network configured to provide voice, data, application, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have various quality of service (QoS) requirements, such as, for example, different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may communicate directly or indirectly with other RANs that use the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also communicate with another RAN (not shown) using GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0050] The CN 106 / 115 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network providing plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP), and / or the internet protocol (IP) of the TCP / IP Internet protocol suite. The networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may use the same RAT as the RANs 104 / 113 or a different RAT.

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

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

[0053] The 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. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120 that may be coupled to a transmit / receive element 122. Although FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

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

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

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

[0059] 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) regarding the current location of the WTRU 102. In addition to or in lieu of information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 116 and / or determine its location based on the timing of signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may obtain location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0060] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors, which may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0061] The WTRU 102 may include a full-duplex radio where transmission and reception of some or all of the signals associated with a particular subframe (e.g., for both the UL (e.g., for transmission) and the downlink (e.g., for reception) may be parallel and / or simultaneous. The full-duplex radio may include an interference management unit 139 to reduce and or substantially eliminate self-interference via either hardware (e.g., a choke) or signal processing via a processor (e.g., via a separate processor (not shown) or processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio for transmission and reception of some or all of the signals (e.g., associated with a particular subframe for either the UL (e.g., for transmission) or the downlink (e.g., for reception)).

[0062] 1C is a system diagram illustrating the RAN 104 and the CN 106 according to one embodiment. As mentioned above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using E-UTRA radio technology. The RAN 104 may also communicate with the CN 106.

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

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

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

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

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

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

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

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

[0071] In an exemplary embodiment, the other network 112 may be a WLAN.

[0072] A WLAN in infrastructure Basic Service Set (BSS) mode may have an access point (AP) of the BSS and one or more stations (STAs) associated with the AP. The AP may have access or interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic originating from outside the BSS to the STAs may arrive through the AP and be delivered to the STAs. Traffic originating from the STAs to destinations outside the BSS may be sent to the AP and transmitted to the respective destination. Traffic between STAs within the BSS may be transmitted, for example, through the AP, where the source STA may transmit traffic to the AP, which may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Homogeneous traffic may be transmitted in a direct link setup (DLS) between the source and destination STAs (e.g., directly between them). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may be referred to herein as an "ad-hoc" communication mode.

[0073] When using an 802.11ac infrastructure mode of operation or a similar mode of operation, an AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., a 20 MHz wide bandwidth) or a width that is dynamically set via signaling. The primary channel may be an operating channel of the BSS and may be used by STAs to establish a connection with the AP. In certain representative embodiments, for example, in an 802.11 system, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented. With CSMA / CA, STAs (e.g., all STAs), including the AP, may sense the primary channel. If the primary channel is sensed / detected and / or determined to be active by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0074] A High Throughput (HT) STA may use a 40 MHz wide channel for communication, which may be formed, for example, through a combination of a 20 MHz primary channel and adjacent or non-adjacent 20 MHz channels.

[0075] A Very High Throughput (VHT) STA may support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. The 40 MHz and / or 80 MHz wide channels may be formed by combining multiple contiguous 20 MHz channels. A 160 MHz channel may be formed by combining eight contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. In the case of the 80+80 configuration, after channel coding, the data may pass through a segment parser, which may split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing may be performed separately on each stream. The streams may be mapped to two 80 MHz channels, and the data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration may be reversed and the combined data may be sent to a Medium Access Control (MAC).

[0076] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support meter-type control / machine-type communication, such as MTC devices in macro coverage areas. MTC devices may have specific capabilities, including, for example, support for (e.g., support only for) specific and / or limited bandwidths. MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0077] WLAN systems that may support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that may be designated as a primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be configured and / or limited by the STAs among all STAs operating in the BSS that support the smallest bandwidth operating mode. In an 802.11ah embodiment, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only) the 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) settings may depend on the state of the primary channel. For example, if the primary channel is active due to a STA (that only supports the 1 MHz mode of operation) transmitting to the AP, the entire available frequency band may be considered active even though most of the frequency band may remain dormant and available.

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

[0079] 1D is a system diagram illustrating the RAN 113 and the CN 115 according to an embodiment. As mentioned above, the RAN 113 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using NR radio technology. The RAN 113 may also communicate with the CN 115.

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

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

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

[0083] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a, 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D, the gNBs 180a, 180b, 180c may communicate with each other via an Xn interface.

[0084] 1D 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 will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

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

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

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

[0089] 1A-1D and the corresponding description thereof, one or more or all of the functions described herein with respect to one or more of the WTRUs 102a-d, base stations 114a-b, eNodeBs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other devices described herein may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

[0090] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and / or an operator network environment. For example, one or more emulation devices may perform one or more or all functions while fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices in the communication network. One or more emulation devices may perform one or more or all functions while temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation devices may be directly coupled to another device for testing purposes and / or may use terrestrial wireless communication to perform the tests.

[0091] One or more emulation devices may perform one or more functions, including but not limited to, while not implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in test scenarios in a test lab and / or in an undeployed (e.g., test) wired and / or wireless communication network to implement testing of one or more components. One or more of the emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may include, for example, one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0092] WTRU vs. Network Relay Example in Rel-13 Relaying over ProSe for WTRU-to-network relay was introduced in Rel13 to extend network coverage to out-of-coverage WTRUs by using PC5 (D2D) between the out-of-coverage WTRU and the WTRU-to-network relay [2].

[0093] In detail, [2] states in section 23.10.4 that "ProSe WTRU-to-Network Relay provides a general L3 forwarding function that can relay any type of IP traffic between the remote WTRU and the network." One-to-one and one-to-many sidelink communication is used between the remote WTRU and the ProSe WTRU-to-Network Relay. Only one single carrier (i.e., Public Safety ProSe carrier) operation is supported for both the remote WTRU and the relay WTRU (i.e., Uu and PC5 should be the same carrier for the relay / remote WTRU). The remote WTRU may be authorized by higher layers to be in the coverage of the Public Safety ProSe carrier or out of coverage on any supported carrier including the Public Safety ProSe carrier for WTRU-to-Network Relay discovery, (re)selection, and communication. The ProSe WTRU-to-Network Relay is always in the coverage of the EUTRAN. The ProSe WTRU to network relay and remote WTRU perform sidelink communication and sidelink discovery, which are described in Sections 23.10 and 23.11, respectively.

[0094] 13 is an example of relay selection for WTRU-to-network relay. Relay selection / reselection for ProSe WTRU-to-network relay is based on a combination of AS layer quality measurements (RSRP) and higher layer criteria.

[0095] This is described in more detail in section 23.10.4 of the Stage 2 specification [2] as follows: The eNB controls whether the WTRU can operate as a ProSe WTRU-to-network relay. If the eNB broadcasts any information associated with ProSe WTRU-to-network relay operation, ProSe WTRU-to-network relay operation is supported in a cell. The eNB can provide either transmission resources for ProSe WTRU-to-network relay discovery using broadcast signaling for RRC_IDLE state and dedicated signaling for RRC_CONNECTED state, and reception resources for ProSe WTRU-to-network relay discovery using broadcast signaling. The eNB can broadcast minimum and / or maximum Uu link quality (RSRP) thresholds that the ProSe WTRU-to-network relay needs to respect before it can start the WTRU-to-network relay discovery procedure. In RRC_IDLE, when the eNB broadcasts the transmission resource pool, the WTRU can use the thresholds to autonomously start or stop the WTRU-to-network relay discovery procedure. In RRC_CONNECTED, the WTRU uses a threshold to determine whether the UE can indicate to the eNB that the WTRU is a relay WTRU and wants to initiate ProSe WTRU-to-network relay discovery.

[0096] If the eNB does not broadcast a transmission resource pool for ProSe-WTRU-to-Network Relay Discovery, the WTRU may initiate a request for ProSe-WTRU-to-Network Relay Discovery resources by dedicated signaling, respecting these broadcasted thresholds.

[0097] If the ProSe-WTRU-to-network relay is initiated by broadcast signaling, it can perform ProSe WTRU-to-network relay discovery when in RRC_IDLE state. If the ProSe WTRU-to-network relay is initiated by dedicated signaling, it can perform relay discovery as long as it is in RRC_CONNECTED state.

[0098] A ProSe WTRU-to-network relay that performs sidelink communication for ProSe WTRU-to-network relay operation needs to be in RRC_CONNECTED state. After receiving a Layer 2 link establishment request or a TMGI (Temporary Mobile Group Identity) monitoring request (higher layer message) from a remote WTRU, the ProSe WTRU-to-network relay indicates to the eNB that it is a ProSe WTRU-to-network relay and intends to perform ProSe WTRU-to-network relay sidelink communication. The eNB may provide resources for ProSe WTRU inter-network relay communication.

[0099] The remote WTRU may decide when to start monitoring for ProSe WTRU-to-network relay discovery. The remote WTRU may send a ProSe WTRU-to-network relay discovery request message while in RRC_IDLE or RRC_CONNECTED depending on the configuration of resources for ProSe WTRU-to-network relay discovery. The eNB may broadcast a threshold value, which is used by the remote UE to determine whether the remote WTRU can send a ProSe WTRU-to-network relay discovery request message to connect or communicate with the ProSe WTRU-to-network relay WTRU. The RRC_CONNECTED remote WTRU may use the broadcasted threshold value to determine whether the RRC_CONNECTED remote WTRU can indicate to the eNB that it is a remote WTRU and wishes to participate in ProSe UE-to-network relay discovery and / or communication. The eNB may provide transmission resources using broadcast or dedicated signaling and provide reception resources using broadcast signaling for ProSe WTRU inter-network relay operation. The remote WTRU stops ProSe WTRU-to-network relay discovery and communication resource usage when the RSRP exceeds the broadcasted threshold (note that the exact time of traffic switching from Uu to PC5 or vice versa is determined at higher layers).

[0100] The remote WTRU performs radio measurements on the PC5 interface and uses them together with the higher layer criteria for ProSe WTRU-to-network relay selection and reselection. A ProSe WTRU-to-network relay is considered suitable from the radio criteria point of view if its PC5 link quality exceeds a configured (preconfigured or provided by the eNB) threshold. The remote WTRU selects the ProSe WTRU-to-network relay that meets the higher layer criteria and has the best PC5 link quality among all suitable ProSe WTRU-to-network relays.

[0101] The remote WTRU triggers ProSe WTRU-to-network relay reselection when the PC5 signal strength of the current ProSe WTRU-to-network relay falls below a configured signal strength threshold. It receives a Layer 2 link release message (higher layer message) from the ProSe WTRU-to-network relay.

[0102] Example of WTRU to network relay for wearable device. In Release 14, research on WTRU-to-network relay for commercial use cases tailored to wearables and IoT devices was conducted in the RAN [3]. Such research did not result in any specifications, but technical reports (TRs) provided some preferred solutions for such relays. In contrast to ProSe WTRU-to-network relay, which uses an L3 (IP layer) relay approach, the WTRU-to-network relay for wearables is expected to be an L2 relay based on the protocol stacks shown in Figures 2 and 3, where Figure 2 shows the protocol stack for the user plan and Figure 3 shows the protocol stack for the control plane for Layer 2 evolved WTRU-to-network relay (PC5).

[0103] Example of connection establishment for unicast links in NR V2X. The relay solution in previous releases of the LTE specification was based on a one-to-one communication link established at higher layers (ProSe layer) between two WTRUs (remote WTRU and WTRU-to-network relay). Such a connection was transparent to the AS (Access Stratum) layer, and connection management signaling and procedures performed at higher layers were carried by the AS layer data channel. Therefore, the AS layer may not be aware of such a one-to-one connection.

[0104] In NR V2X (Rel16), the AS layer supports the view of unicast links between two WTRUs. Such unicast links are initiated by higher layers (as in a ProSe one-to-one connection). However, the AS layer is informed of the existence of such unicast links and of any data transmitted in a unicast manner between peer WTRUs. With such knowledge, the AS layer can support HARQ feedback, CQI feedback, and unicast-specific power control schemes.

[0105] Unicast links at the AS layer are supported via PC5-RRC connections. In [4], PC5-RRC connections are defined as follows: A PC5-RRC connection is a logical connection between a pair of source and destination Layer 2 identities within an AS. One PC5-RRC connection corresponds to one PC5 unicast link [xx]. PC5-RRC signaling can be initiated after its corresponding PC5 unicast link is established as specified in Section 5.X.9. A PC5-RRC connection and corresponding sidelink SRBs and sidelink DRBs are released when the PC5 unicast link is released as indicated by higher layers. For each unicast PC5-RRC connection, one sidelink SRB is used to send PC5-S messages before PC5-S security is established. One sidelink SRB is used to send PC5-S messages to establish PC5-S security. One sidelink SRB is used to send PC5-S messages after PC5-S security is established and protected. One sidelink SRB is used to transmit PC5-RRC signaling, which is protected and sent only after PC5-S security is established.

[0106] PC5-RRC signaling includes a sidelink configuration message (RRCReconfigurationSidelink) in which one WTRU configures RX-related parameters of each SLRB (Sidelink Radio Bearer) in a peer WTRU. Such a reconfiguration message may configure parameters of each protocol in the L2 stack (SDAP, PDCP, etc.). The receiving WTRU may confirm or reject such a configuration depending on whether it can support the configuration proposed by the peer WTRU.

[0107] Comparison of logical channel priorities is an operation often performed by the WTRU, for example, when performing LCP (Logical Channel Prioritization) for UL transmissions. In the Sidelink (SL) case, in addition to LCP, the WTRU also performs a priority comparison to determine whether to prioritize UL or SL transmissions when both transmissions cannot be performed simultaneously. Following considerations in Rel16 NR V2X, it was agreed that UL and SL traffic cannot be directly compared by directly comparing the configured UL and SL priorities. Instead, the comparison of UL and SL priorities (to determine whether to transmit UL or SL when grants conflict) is performed using separate UL and SL priorities. For example, the mapping from PQI to SL priority may not follow the same rules as the mapping from 5QI (5G QoS Identifier) ​​to Uu priority. Also, the range of SL priorities (1-8) does not match the range of Uu priorities (1-16).

[0108] In the case of WTRU to network relay, the SL transmission can be either a normal SL transmission (initiated by the SL service at the relay WTRU itself) or it can be relayed Uu traffic. In such a case, the prioritization between UL and SL transmissions when the SL transmission consists of Uu traffic should be reconsidered, assuming that such Uu traffic can be associated with Uu priority on the Uu link. Similarly, the comparison of SL traffic over SL (e.g., for operations such as SL destination selection in LCP) and relayed Uu traffic over SL may need to be reconsidered, taking into account that Uu traffic priority may not be well represented by SL LCH (logical channel) priority. Figures 4 and 5 illustrate the nature of the problem in Rel. 16 and Rel. 17, respectively.

[0109] Furthermore, a SL WTRU in Mode 1 will trigger a SL BSR (Buffer Status Report) to inform the network of the buffer status associated with the sidelink transmission. In case of WTRU-to-network relay in Mode 1, the SL transmission may correspond to relayed Uu traffic received from the gNB. So, the SL BSR may not always be needed. The same is true for multi-hop relay or WTRU-to-WTRU relay, in that there may be situations where reporting a BSR to the network may be redundant and not necessarily necessary. Therefore, to take these cases into account, the SL BSR triggering and calculation procedure should be revisited to avoid unnecessary scheduling / granting of UL resources (e.g., due to a redundant SL BSR being triggered related to relayed Uu data).

[0110] Furthermore, in the case of WTRU to network relay, end-to-end Uu QoS parameters such as Packet Data Budget (PDB), Packet Error Rate (PER), etc. need to be partitioned by the gNB so that these parameters can be applied over each of the SL and Uu links. While it would be possible to have a static partition, the conditions for SL and Uu may change dynamically, and therefore it is beneficial to update the partition as the radio quality and congestion conditions in both links change. However, if the network had to update the partition using RRC signaling (and send such signaling to both the remote and relay WTRUs) every time conditions changed, it would cause significant signaling overhead. Additionally, responses by the network may not be timely as conditions in both links may change very quickly.

[0111] Enhancements to QoS enforcement. In the following description, methods for prioritization between SL and UL data or traffic are disclosed in the context of a relay. In such description, SL and UL data or transmissions refer to transmissions made by a WTRU over SL and Uu links, respectively. In contrast, SL or UL traffic refers to whether the service associated with the transmission is an SL service or a UL service. Specifically, a WTRU may make an SL transmission of Uu traffic in the context of a SL WTRU-to-network relay. The following solution then refers to such transmissions as Uu traffic sent over SL, or SL data including Uu traffic.

[0112] Examples of actions / behaviors that can be affected by prioritization rules. The methods for traffic prioritization described herein can be used to determine the mechanism or result of any of the following actions in the WTRU. The action can consist of SL destination selection during the LCP. In particular, the WTRU can use such prioritization rules to select the SL destination L2 ID for transmission in the SL grant.

[0113] Another operation may consist of LCH selection during the LCP. In particular, the WTRU may use such prioritization rules to select an SL LCH to be multiplexed within an SL grant. In particular, the WTRU may use such prioritization rules to select between a MAC CE or an LCH when multiplexing data into an SL grant.

[0114] Another operation may consist of prioritization between the SL BSR and the Uu BSR when including both in the UL grant.

[0115] Another operation may consist of prioritizing between UL and SL grants. Specifically, the WTRU may use such prioritization rules to determine whether to prioritize between UL and SL grants, e.g., if the WTRU can only transmit one of the grants and has to give up the other grants.

[0116] Another operation may consist of determining whether to trigger an indication / transmission to the network, including but not limited to, a Scheduling Request (SR), BSR, assistance information, etc. For example, the WTRU may trigger an SR when data arrives for a logical channel whose priority exceeds the priority of any pending data at the WTRU. Such priority determination or comparison may use any of the rules described herein.

[0117] Another operation may consist of determining whether to trigger Mode 2 resource and / or carrier (re)selection. For example, the WTRU may determine whether Mode 2 resource and / or carrier (re)selection is triggered depending on the outcome of the prioritization decision / rule.

[0118] Another operation may consist of determining properties associated with the Mode 2 resource selection. For example, the WTRU may use the results of any prioritization decisions / rules described herein to determine values ​​for sensing parameters (e.g., occupancy thresholds, percentage of available resources that indicate successful sensing, parameters defining the number of resources to be sensed before resource selection, etc.) and which sensing mechanisms to apply (e.g., using partial sensing, full sensing, random selection).

[0119] Another operation may consist of determining a resource pool to be used for the transmission. For example, the WTRU may select a resource pool for the transmission according to any of the prioritization rules herein.

[0120] An example of a method for deriving a priority value for a SL transmission carrying relayed Uu data. For comparison of priorities (e.g., between SL and SL or between UL and SL) for the operations described herein, the WTRU may need to derive a priority value associated with the SL transmission that contains the relayed data. Any of the following embodiments for deriving a priority may be considered as part of the techniques that require determining a priority associated with the SL transmission carrying the relayed data.

[0121] 13 is an example of deriving priority for SL transmissions including relayed traffic based on adaptive layer mapping. An adaptation layer is introduced for SL relay, and such adaptation layer is configured (by the network) with a mapping between Uu LCHs and SL LCHs. In one embodiment, the WTRU can derive a priority based on a mapping of Uu LCH priority to a SL LCH associated with the transmission. Specifically, the WTRU can determine the SL LCH included in the transmission and can obtain the associated Uu LCH, which can be mapped to the SL LCH. The WTRU can then use the priority derived from one of the Uu LCHs.

[0122] The WTRU may first determine one or more SL LCHs to be included in the SL transmission.

[0123] In one group of embodiments, the WTRU may first determine a single SL RLC channel associated with the transmission. The single SL RLC channel may be the highest SL priority SL RLC channel whose data is multiplexed in the SL transmission. Alternatively, the single SL RLC channel may be the lowest priority SL priority SL RLC channel whose data is multiplexed in the SL transmission. Alternatively, the single SL RLC channel may be one of the SL RLC channels multiplexed into the SL transmission, whose priority may be a median, average, mean, etc. operation of a set of SL priorities associated with the SL RLC channels whose data is multiplexed into the grant. Without loss of generality, other factors described herein may be used to select between options within this group (e.g., selecting one SL RLC channel over another SL RLC channel depending on other factors described herein). In such a group of embodiments, the priority of the SL transmission may be derived from the priority of the Uu RLC channel that is mapped to this single SL RLC channel.

[0124] In another group of embodiments, the WTRU may determine multiple SL RLC channels for consideration. The multiple SL RLC channels may be all of the SL RLC channels whose data was included in the SL transmission. The multiple SL RLC channels may include the highest priority SL RLC channel whose data was included in the SL transmission. Alternately, the multiple SL RLC channels may include the lowest priority SL RLC channel whose data was included in the SL transmission. Alternately, the multiple SL RLC channels may include all SL RLC channels with SL priority above / below a configured threshold whose data was included in the SL transmission. In such group of embodiments, the priority of the SL transmission may be derived from the priority of the Uu RLC channel that is / may be mapped to these multiple SL RLC channels.

[0125] The WTRU may then determine a Uu RLC channel that may be mapped (eg, in an adaptation layer configuration / mapping) to one or more of the SL RLC channels described above.

[0126] In one group of embodiments, the WTRU may select a single Uu RLC channel based on priority and use the priority configured for that Uu RLC channel. The WTRU may select the Uu RLC channel with the highest priority, lowest priority, median / average priority, etc. The WTRU may use other factors described herein to determine which Uu RLC channel to use to derive the priority.

[0127] In another group of embodiments, the WTRU may calculate a priority from the priorities of one or more selected Uu RLC channel priorities. The WTRU may calculate an average priority value. The WTRU may select one Uu RLC channel and derive its priority by adding a value of a transformation, an offset, to the priority, as described further herein.

[0128] An example of deriving priority for SL transmissions including relayed traffic based on the mapped Uu QoS flows. In another solution, the WTRU may derive the priority based on information about Uu QoS flows / requirements that may be carried by / mapped to the SL LCH. Specifically, the WTRU may receive information (e.g., in an adaptation layer header) that can be used to derive the priority based on the end-to-end QoS flows or bearers that are included in the transmission or that are mapped to the RLC channels that are included in the transmission. o In one solution, the WTRU may receive the Uu bearer ID in the adaptation layer header. The WTRU may be further configured with a mapping of the Uu bearer ID to an equivalent Uu priority (e.g., in dedicated RRC signaling). The priority may correspond to an equivalent non-relayed priority. The WTRU may use the equivalent Uu priority as the SL transmission priority for comparison (e.g., for UL / SL prioritization or SL / SL comparison, as described herein). o In another solution, the WTRU may receive the QoS Flow ID in the adaptation layer header. The WTRU may be further configured with a mapping of the QoS Flow ID to an equivalent Uu priority (e.g., in dedicated RRC signaling).

[0129] 13 is an example of deriving priority for a SL transmission that includes relayed traffic based on QoS information in the transmission.

[0130] In another embodiment, the WTRU may derive the priority based on QoS information included with the SL transmission (e.g., in an adaptation layer header). In another solution, the WTRU may receive a QoS requirement (such as 5QI). The WTRU may derive the equivalent Uu priority based on a configured mapping (similar to the previous solution). Alternatively, the WTRU may derive the equivalent mapping based on a similar mapping of PQI to LCH priority configured for another bearer at the WTRU (e.g., a non-relayed Uu bearer).

[0131] Example of comparison between SL and SL transmission An example of a comparison between SL traffic that can use a method other than direct priority ordering. Prioritization between logical channels is typically done by comparing LCH priorities. In one mechanism, the WTRU may use a different method than direct priority value comparison when performing any of the above operations / actions. Such a different method may be applied to comparisons between any of the following data / LCHs: when comparing data to be relayed with data that is not relayed, when comparing SL transmissions carrying Uu traffic versus SL traffic, when comparing data to be relayed with different total hop counts, and when comparing data to be relayed with different number of hops remaining to its destination.

[0132] The method for comparison between these data and / or LCHs can use any of the following techniques: applying an offset, increase, decrease, or compensation in priority based on a factor; comparing the priority of each data / LCH against different thresholds; and using direct comparison.

[0133] More specifically, the application of an offset, increase, decrease, or compensation in priority may be based on factors such as the number of hops. For example, the WTRU may apply an offset or compensation to the priority of data when the number of hops or the number of remaining hops for that data is above a configured threshold, or may apply an offset specific to the difference in the number of remaining hops between the data being compared. For example, the WTRU may make a direct comparison of offsets when the number of remaining hops for the data being compared is the same or within a configured threshold, or may make a differential comparison (which may use methods described herein).

[0134] More specifically, the application of an offset, increase, decrease, or compensation in priority may further be based on factors such as CBR (Channel Busy Ratio). For example, the WTRU may apply an offset to the priority of the data (i.e., increase the priority) if the CBR is above a threshold, and may not increase the priority otherwise. Such a priority increase may further be applied, for example, when comparing two destinations / LCHs with unequal hop counts.

[0135] According to an embodiment involving a comparison of each data / LCH priority with different thresholds, the WTRU may be configured with different thresholds (e.g., one applied to Uu traffic and one applied to SL traffic). For example, when performing LCP, the WTRU may first select UL / SL traffic based on conditions related to whether UL traffic is above a first threshold and / or whether SL traffic is below a second threshold. If the conditions for prioritization based on these thresholds are not met, the WTRU may make a direct comparison. For example, the WTRU may prioritize UL traffic if the UL traffic priority is above a threshold. If the UL traffic priority is below a threshold, the WTRU may still prioritize UL traffic if the SL traffic is below another threshold. If neither of these conditions are met, the WTRU may directly compare priorities when determining which destination or logical channel to select during LCP, or may prioritize one of the two (e.g., UL traffic) by default, or may prioritize traffic with more hops.

[0136] According to an embodiment that includes using direct comparison, when comparing two SL LCHs, if both LCHs carry SL traffic, the WTRU may use direct priority comparison. If only one of the two LCHs carries Uu traffic, the WTRU may use one of the methods described herein for comparison between SL and Uu traffic. If both SL LCHs carry Uu traffic, the WTRU may use one of the methods described herein for comparison between Uu and Uu traffic relayed over SL.

[0137] Example comparison between SL traffic and Uu traffic relayed over SL. When prioritizing between SL traffic and Uu traffic over SL, the WTRU may use any of the following information, or possibly a combination of the following information associated with the SL traffic or the Uu traffic, or both, to determine which one to prioritize:

[0138] The SL priority associated with a SL RLC channel carrying either SL traffic or Uu traffic. The Uu priority of a Uu RLC channel mapped to a SL RLC channel carrying Uu traffic.

[0139] A priority offset applied to the SL RLC channel priority when the SL RLC channel contains relayed data. Such an offset may be further configured based on other factors herein such as number of hops, number of remaining hops, SL CBR, etc.

[0140] The total number of hops associated with SL traffic and / or Uu traffic.

[0141] The remaining number of hops associated with SL traffic and / or Uu traffic.

[0142] A metric associated with the QoS or remaining QoS may possibly be provided by the adaptation layer along with each PDU or statically for a set of PDUs. For example, such a metric may be a remaining lifetime associated with the PDU, representing the amount of time until the PDU exceeds its latency budget, or in other examples, any of the configured thresholds described above in the embodiments herein in relation to priority may be configured for each range of remaining lifetime associated with the PDU.

[0143] Any of the configured thresholds described in the solutions related to SL channel measurements (e.g., CBR, RSRP, CSI, etc.), e.g., priority, may be configured for each CBR, RSRP, CSI, etc.

[0144] Regardless of whether the prioritization is performed by a remote WTRU or a relay WTRU, for example, the WTRU may be configured with different conditions, rules, or parameters for a remote WTRU as compared to a relayed WTRU.

[0145] Regardless of whether the prioritization involves UL Uu data or DL ​​Uu data, for example, the WTRU may be configured with different conditions, rules, or parameters for UL Uu data as compared to DL Uu data.

[0146] Example of SL destination selection during LCP procedure. The following exemplary embodiments describe SL destination selection during an LCP procedure. However, the decision criteria can be used for any other prioritization decision described herein. In addition, the following exemplary embodiments can be used in combination for prioritization. Specifically, for example, the WTRU can use a first example when a certain condition is met and can use another example when the condition is not met. Alternatively, the WTRU can use a first example to select between destination IDs and a second example when selecting between LCHs transmitted to the same destination ID.

[0147] In one example, the WTRU may be configured with a Uu priority threshold for prioritizing Uu traffic. If the Uu priority of at least one Uu RLC channel mapped by the adaptation layer to a SL RLC channel includes Uu traffic above the configured Uu priority threshold, with one of the SL RLC channels having available data to transmit to the SL destination (and exceeding the prioritized bit rate, i.e., bj>0), the WTRU may select the SL destination with Uu traffic over the SL destination with SL traffic. Otherwise, the WTRU may determine whether to select the SL destination with SL traffic or the SL destination with Uu traffic based on other embodiments described herein.

[0148] In another example, the WTRU may be configured with a SL priority threshold for prioritizing Uu traffic. For example, the WTRU may select an SL destination with SL traffic over an SL destination with Uu traffic if one of the SL RLC channels with SL traffic available to transmit (and exceeding a prioritized bit rate) contains data above the SL priority threshold.

[0149] In another example, the WTRU may be configured with a SL RLC priority offset. The WTRU may apply such an offset when comparing the priority of SL RLC channels carrying Uu traffic and SL traffic. When selecting a destination for an LCP, the WTRU may select the destination with the highest priority LCH that has available data after the priority offset is applied to all SL RLC channels carrying Uu traffic.

[0150] In another example, the WTRU may be configured with a threshold remaining lifetime, and if the actual remaining lifetime associated with a PDU, or data in a PDU, falls below the threshold, the WTRU may prioritize destinations associated with such PDU.

[0151] In another example, the WTRU may be configured with a CBR threshold, and if the measured CBR is above the threshold, the WTRU may use a first rule to prioritize between SL destinations with Uu traffic and SL destinations with SL traffic, and if the CBR is below the threshold, the WTRU may use a second rule.

[0152] In another example, potentially applicable when other criteria are equal / not met, the WTRU may prioritize relayed traffic over unassociated traffic, specifically, it may select SL destinations with Uu traffic over SL destinations with SL traffic.

[0153] Further example considerations when a SL destination / LCH can include both SL and Uu traffic. The SL destinations and / or LCHs can include Uu traffic relayed over the sidelink as well as SL traffic, which can be included in the destinations that have data available within the LCH or for different LCHs (LCHs that contain SL traffic and LCHs that contain Uu traffic).

[0154] In such a scenario, the WTRU may be configured with rules to select between SL destinations that include only SL traffic, only Uu traffic, and SL destinations that include both SL and Uu traffic. Such rules may be applicable to destinations that are permitted to transmit only SL traffic, only Uu traffic, and / or both. Alternatively or additionally, similar rules may be applied to destinations that are permitted to transmit both, but between destinations that have only SL traffic available for transmission (or exceeding the PBR), destinations that have only Uu traffic available for transmission (or exceeding the PBR), and destinations that have both SL and Uu traffic available for transmission (or exceeding the PBR).

[0155] In all of these scenarios, one of the following embodiments can be implemented.

[0156] In one embodiment, the WTRU may be configured to prioritize destinations based on acceptable or available traffic types. For example, a destination that has both channel types (Uu and SL) available may be prioritized over a destination that has only one channel type. Such may apply when the same priority is determined for two destinations, where the two destinations have priorities within a certain range of each other.

[0157] In one embodiment, both SL priority (e.g., direct comparison) or Uu priority (e.g., threshold-based comparison) may be used, and if either comparison results in a preference for a destination that supports relayed traffic, the WTRU may select a destination that supports relayed traffic, otherwise a non-relayed destination may be selected.

[0158] In one embodiment, either Uu priority (e.g., direct comparison) or SL priority (e.g., threshold-based comparison) may be used, and if the comparison results in a preference for a destination that supports relayed traffic, the WTRU may select the destination that supports relayed traffic, otherwise it may select a destination that supports both traffic.

[0159] Example of Uu traffic compared to Uu traffic, both relayed over SL. The WTRU can select between two different Uu traffic relayed over SL. For such selection / prioritization between SL transmissions, the WTRU can use any of the following: direct comparison of SL LCH priorities, comparison of Uu RLC channels mapped to SL RLC channels by the adaptation layer, and remaining and / or total number of hops used for relaying.

[0160] For example, in the case of a direct comparison of SL LCH priority, the WTRU may make a comparison of two (or more) SL destinations, both carrying Uu traffic, by a direct comparison of only the SL RLC channel priority. In some embodiments, this scheme may be employed in only a subset of cases. For example, such a direct comparison may be made only if the remaining number of hops to the destination for Uu traffic is the same.

[0161] For example, in the case of a comparison of Uu RLC channels mapped to SL RLC channels by an adaptation layer, the WTRU may compare the priorities of the highest priority Uu RLC LCHs mapped to the SL RLC channels LCHs being compared and may select the destination that maximizes the Uu RLC LCH priority. In another example, the WTRU may compare the priorities of the lowest priority Uu RLC LCHs mapped to the SL RLC channels LCHs being compared and may select the destination that maximizes the Uu RLC channel LCH priority. In yet another example, the WTRU may compare the priorities of the average priority Uu RLC LCHs mapped to the SL RLC channels LCHs being compared and may select the destination that maximizes the average priority. In a further example, the WTRU may compare the priorities of the highest priority Uu RLC LCHs mapped to the SL RLC channels LCHs being compared and that contributed to the data available in the buffer in the SL RLC channels and may select the destination that maximizes the Uu RLC LCH priority. In yet a further example, the WTRU may use Uu RLC channel priority comparison instead of SL RLC channel priority comparison if the number of different Uu RLC channel priorities mapped to the SL RLC channel is above / below a threshold, and SL RLC channel priority comparison otherwise. In some embodiments, this scheme may be employed only in a subset of cases. For example, such a direct comparison may only be made if the remaining number of hops to the destination for Uu traffic is the same.

[0162] Exemplary embodiments. In an example embodiment, the WTRU may increase the priority associated with the SL transmission with a larger number of remaining hops when the CBR is above a threshold. Specifically, the WTRU may use the methods described herein to derive the priority of the SL transmission associated with the relayed Uu traffic. When comparing the priority of two different SL transmissions (whether the SL transmission includes a Uu transmission or not), the WTRU may take into account the number of remaining hops in the transmission. If the CBR is above a threshold, the WTRU may prioritize the transmission associated with a larger number of hops. For example, when the CBR is above a threshold, the WTRU may provide a priority offset (e.g., increase the priority by some value) when comparing SL transmissions with different numbers of hops. Alternatively, in the case of equal priority, the WTRU may prioritize the transmission with a larger number of hops remaining when the CBR is above a threshold. Alternatively, the WTRU may apply a priority offset to the transmission, where such priority offset is configured based on the remaining number of hops and may be applied only when the CBR is above a threshold.

[0163] Example of SL transmission compared to UL transmission. A direct comparison applies when the SL data is relayed UL traffic. In one embodiment, in a comparison between SL and UL (e.g., for purposes of UL / SL prioritization applied in legacy systems), the WTRU may first determine whether the SL data is relaying UL traffic. If the WTRU is not relaying UL traffic over the SL data, the WTRU may use the SL / UL comparison rules from legacy operation (i.e., comparison based on separate UL and SL thresholds). Specifically, the WTRU prioritized UL traffic if (a) the priority of the UL traffic was above a first threshold, or (b) both UL traffic was below a first threshold and the SL traffic was below a second threshold. In contrast, if the SL data carries Uu traffic, the WTRU may directly compare the priority of the UL data with the Uu priority associated with the SL data.

[0164] Specifically, the Uu priority of the SL traffic may be derived by any of the methods described herein in the previous sections. For example, such priority may be derived by the priority of the Uu RLC channel mapped to the highest priority SL LCH (among the priorities included in the SL transmission) in the adaptation layer. Specifically, the WTRU may derive a priority of the Uu traffic (associated with SL data) to be used for comparison with the UL transmission as any of the following examples:

[0165] As an example, the Uu priority may be the highest priority Uu RLC channel that is mapped in the adaptation layer configuration to the SL RLC channel it is being compared to.

[0166] As another example, the Uu priority may be the lowest priority Uu RLC channel that is mapped in the adaptation layer configuration to the SL RLC channel it is being compared to.

[0167] As another example, the Uu priority may be the average Uu RLC channel priority of the Uu RLC channels that are mapped, in the adaptation layer configuration, to the SL RLC channel they are being compared to.

[0168] In the above example, the Uu priority selected for use in the comparison may be the highest priority mapped to the Uu RLC channel in some embodiments, and the lowest priority in other embodiments. Which priority level is selected may depend on any one or more of the highest / lowest priority value, the CBR of the SL data, the number of hops or remaining hops of the relayed data, a time to live parameter associated with the relayed data, the relationship between Uu priority and SL priority, parameters in the LCH configuration, etc.

[0169] For example, the WTRU may use the highest priority as the Uu priority if the highest priority is above a threshold, otherwise it may use the lowest priority.

[0170] In another example, the WTRU may use the highest priority as the Uu priority if the number of hops is greater than a threshold, and may use the lowest priority otherwise.

[0171] In yet another example, the WTRU may use the highest priority as the Uu priority if the time-to-live of any / all data associated with the relayed data is below a threshold, and may use the lowest priority otherwise.

[0172] In a further example, the WTRU may use the highest priority as the Uu priority if the SL priority is above a configured threshold associated with the highest / lowest Uu priority mapped to the SL LCH, otherwise it may use the lowest Uu priority.

[0173] In yet a further example, the WTRU may use the highest priority as the Uu priority if the SL RLC channel is configured with instructions to use the highest priority, otherwise it may use the lowest priority.

[0174] In another embodiment related to the above, the WTRU may further determine whether / how direct comparison is used using measurements over SL and / or Uu. For example, the WTRU may use direct comparison for some values ​​of CBR (e.g., CBR below a threshold). If the CBR is above a threshold, the WTRU may use a different priority (or apply an offset to the priority) for the relayed data and / or may not use direct priority comparison, but rather compare using configured SL RLC priority and Uu RLC priority values ​​using a comparison based on a different threshold.

[0175] Exemplary embodiments. In an example embodiment, the SL relay WTRU may determine whether to prioritize UL or SL transmissions based on whether the SL transmission is relayed Uu traffic, and if so, may compare the UL priority with either the highest or lowest priority Uu RLC channel mapped to the SL RLC channel in the adaptation layer. Specifically, the SL relay WTRU may determine that it cannot transmit SL and UL simultaneously. Such a WTRU may transmit either SL or UL depending on whether SL or UL is prioritized. If the SL transmission corresponds to an L2 destination of a remote WTRU receiving SL traffic, or if the SL transmission includes an LCH associated with Uu traffic relayed to the remote WTRU, the relay WTRU may derive a priority (different from the SL RLC channel priority) to compare with the Uu traffic priority. In such a case, the SL transmission priority may be determined as the priority level of either the highest or lowest priority Uu RLC channel mapped by the adaptation layer to the maximum SL RLC channel priority included in the SL transmission. If the SL RLC channel priority is above a threshold, the maximum value is used. If the SL RLC channel priority is less than or equal to the threshold, the minimum value is used.

[0176] 6 is a flow chart illustrating such an embodiment. At 602, the relay WTRU simultaneously receives UL and SL transmissions that require prioritization to determine which transmission to transmit. At 604, the relay WTRU determines whether the SL transmission corresponds to an L2 destination of the remote WTRU. If not, flow proceeds to step 606, where the relay WTRU prioritizes the UL transmission if either (a) the priority of the UL transmission is greater than a first UL threshold or (b) the priority of the UL transmission is less than or equal to the first threshold and the priority of the SL transmission is less than a second SL threshold.

[0177] On the other hand, if in step 604 it is determined that the SL transmission corresponds to an L2 destination of a remote WTRU, flow proceeds to step 608. In step 608, the relay WTRU determines the highest priority SL LCH for the SL transmission.

[0178] Next, in step 610, the relay WTRU determines the Uu LCH mapped to this SL LCH from the adaptation layer mapping.

[0179] Next, in step 612, the relay WTRU determines whether the SL LCH priority is above another threshold. If it is above the threshold, flow proceeds to step 614, where the relay WTRU compares the priority level of the Uu LCH mapped to the highest priority with the UL priority determined in step 610. If it is not above the threshold, flow proceeds instead to step 616, where the relay WTRU compares the priority level of the Uu LCH mapped to the lowest priority with the UL priority.

[0180] Finally, flow proceeds from either step 614 or step 616 to step 618, where the relay WTRU selects one of the UL and SL transmissions that had a higher assigned priority in the comparison step (614 or 616).

[0181] 13 is an example of a method for transmitting a BSR in a relay scenario. The WTRU decides whether to report a SL / Uu BSR. In a relay scenario, transmission of an SL / Uu BSR may be unnecessary since the network can know the WTRU's buffer status from such knowledge from the previous link. The WTRU may determine whether to report an SL / Uu BSR based on any one or combination of the following factors. Determining whether to report an SL / Uu BSR may include determining any of the following conditions: whether the SL / Uu BSR is triggered in the WTRU, which logical channels trigger / do not trigger the SL / Uu BSR, whether data received from the LCH should be included in the SL / Uu BSR, how much data (e.g., portion, percentage) should be included in the SL / Uu BSR, and which ingress RLC channels mapped to the same egress RLC channel should contribute to the data reported to the SL / Uu BSR.

[0182] Examples based on LCH configuration and / or L2 ID. In one embodiment, the WTRU may be configured with a subset of LCHs for which a BSR (SL or UL) should be reported, and another subset of LCHs for which a BSR should not be reported. Similarly, the WTRU may be configured with L2 destination IDs for which a SL BSR should or should not be reported. For example, an SL relay WTRU may report SL BSRs for SL logical channels / L2 destination IDs carrying SL traffic, but may not report SL BSRs for SL logical channels / L2 destination IDs carrying Uu traffic (i.e., DL relayed traffic). In another example, an SL relay WTRU may be configured with SL logical channels for which SL BSRs are or are not reported / triggered (e.g., in a network-provided LCH configuration). For example, an SL relay WTRU may be configured to report / trigger SL BSRs only for SL LCHs / destination IDs of RLC bearers that do not have an adaptation layer associated with the SL LCHs / destination IDs of the RLC bearers (i.e., for WTRU-to-network relay).

[0183] Example based on cell id / coverage / allocation mode of previous hop. In one embodiment, the relay WTRU may decide whether to report / trigger a SL BSR based on the cell ID and / or allocation mode associated with the previous hop WTRU, possibly compared to the relay WTRU's own cell ID and / or allocation mode. Specifically, for example, the first WTRU (relay or remote) may transmit to the second WTRU (relay) the cell ID of the cell to which it is connected, and / or the WTRU's SL allocation mode (mode 1 or mode 2). Alternatively, the first WTRU may transmit to the second WTRU cell the cell ID of the cell to which it is connected only when it is configured to operate in mode 1 with that cell, and may not transmit any cell ID when it is configured to operate in mode 2 or is out of coverage (OOC). Such information may be transmitted, for example, via MAC CE, SCI, or PC5-RRC messages. A second (relay) WTRU (operating in Mode 1 SL transmission or relaying received data to the network over Uu) may determine whether to trigger a SL / Uu BSR when relaying data from the first WTRU based on the cell ID received from the first WTRU and the cell ID of the cell to which the second WTRU is connected. Specifically, if the second WTRU is connected to the same cell from which it received data from the first WTRU, it may not report a BSR, but if connected to a different cell, it may report a BSR. The "same cell" may consist of, for example, the same cell ID or an equivalent cell ID configured by the network.

[0184] In a related embodiment applicable to a multi-hop (more than two hops) scenario, the first WTRU in the above embodiment may transmit cell ID information and / or allocation mode for multiple / all hops along the path between the source and destination WTRU / gNB. Specifically, the first WTRU may transmit its own cell ID and / or allocation mode, and an appended WTRU cell ID and / or allocation mode. The second WTRU may transmit the same information received from the first WTRU, as well as its own cell ID and / or allocation mode, to the third WTRU, and so on. Whether a particular WTRU should report / trigger a BSR for data to be transmitted / relayed by that WTRU may further depend on the information received from the previous WTRU. For example, a WTRU may report / trigger a (SL or UL) BSR for the LCH according to any of the following conditions: at least one of the previous hop WTRUs has a cell ID that does not match the WTRU's cell ID, at least one of the previous hop WTRUs has Mode 2 as its resource allocation mode, all previous hop WTRUs have a cell ID different from the WTRU's cell ID, and all previous hop WTRUs have Mode 2 as their resource allocation mode.

[0185] Without loss of generality, the previous hop may be a gNB, where the cell ID in such case is the actual cell ID of the gNB. Specifically, the relay WTRU may not report / trigger a BSR for the LCH if the previous hop is a gNB and the cell ID of the gNB is the same as the cell ID to which the WTRU is connected.

[0186] An example based on whether the LCH carries relayed or non-relayed data. In one embodiment, the decision of whether to activate / trigger a BSR may depend on whether the LCH carried relayed or non-relayed data. Specifically, the WTRU may report a BSR if the LCH carries non-relayed data (i.e., data received at the WTRU from a higher layer and not data received from another WTRU).

[0187] 13 is an example based on ingress LCH to egress LCH mapping in the adaptation layer of the WTRU. In one embodiment, the decision of whether to trigger / report a BSR may depend on specific rules related to the ingress LCH to egress LCH mapping at the WTRU and / or at the WTRU in the previous hop (in case of a multi-hop scenario).

[0188] For example, the WTRU may trigger / report a BSR for an egress LCH if there is more than one egress LCH mapped to the egress LCH. Further conditions described herein may also be used to make such a decision based on any / all of the egress LCHs mapped to the egress LCH.

[0189] In another example, the WTRU may trigger / report a BSR for an egress LCH if any / all of the ingress LCHs mapped to that egress LCH are mapped only to that single egress LCH.

[0190] Any combination (and / or) of the above conditions may also be used to determine whether to trigger / report a BSR. For example, the WTRU may / may not trigger / report a BSR as long as the LCH simultaneously meets multiple conditions, otherwise the WTRU may / may not trigger / report a BSR.

[0191] In one embodiment, the WTRU may report an amount of data that has been dropped / removed from one or more LCHs. Such a report may be made to the gNB, e.g., to inform the gNB that the WTRU has dropped / removed an amount of data and that the gNB may (as a result) schedule a lesser amount of data than was initially known by the gNB. Alternatively, the WTRU may report the amount of data that has been dropped / removed from one or more LCHs to a peer WTRU (e.g., a next-hop WTRU), so that the peer WTRU may use this information in its own calculation of the BSR and / or in its own generation of such reports to the network.

[0192] In one example, the WTRU may report (e.g., via a MAC CE) the amount of data discarded by the WTRU per logical channel or group of logical channels. Such reporting may be triggered by the WTRU when it deletes one or more PDUs (e.g., due to not meeting latency requirements). Alternatively, such reporting may be triggered when the WTRU deletes a certain amount (e.g., a percentage) of data, possibly over a period of time. For example, such reporting may be triggered by the WTRU when the amount of data deleted by the WTRU over a configured period of time exceeds a configured threshold. Alternatively, such reporting may be triggered only when the WTRU deletes data for a particular logical channel or group of logical channels. For example, each LCH may be configured to enable / disable reporting on deleted data when data is deleted by the WTRU for that LCH.

[0193] 13 is an example of a method for SL transmission parameter selection. PDB selection by relay / remote WTRU. In one embodiment, a relay WTRU or a remote WTRU may be configured (e.g., by the network) with multiple values ​​of the PDB associated with a single RLC channel and / or QoS flow. The WTRU may be further configured with an association between the PDB and factors for PDB selection, as described below. The WTRU may select one of the configured values ​​of the PDB (e.g., to determine the value of T2 in resource selection) based on any of the following associated factors: network indication, number of retransmissions required, SL measurements by the relay / remote WTRU, Uu quality / RSRP measurements, and flow control messages.

[0194] In the case of a network-indicated cause, in one embodiment, a relay WTRU or a remote WTRU may receive an indication of the PDB to be used on the SL RLC channel (e.g., in a DCI associated with a DCI type, MAC CE, adaptation layer header, or the like. For example, the relay WTRU may select a PDB based on the DCI type used to schedule DL transmissions for a Uu RLC channel that is mapped to a corresponding SL RLC channel for which the PDB selection is applicable.

[0195] For the factor of number of required retransmissions, in one embodiment, the relay WTRU or remote WTRU may select the PDB based on the number of retransmissions required at the WTRU (either on Uu or on the sidelink) to successfully receive the PDU on that link. The number of retransmissions may possibly include the average number of retransmissions required for successful reception at the WTRU associated with data that can be mapped to an RLC channel for which PDB selection is required. Alternatively, the number of retransmissions may be a value associated with the last reception of a PDU on a channel that can be mapped to an RLC channel for which PDB selection is required.

[0196] In the case of SL measurements by the relay / remote WTRU (either measured by the relay / remote WTRU itself or indicated to the relay / remote WTRU by a peer WTRU), in one embodiment, the relay or remote WTRU may be configured with a mapping of SL measurements to PDB selections and may select a PDB based on the determined measurements. Such measurements may include any of the following: CBR measurements measured at the WTRU itself, CBR measurements provided by the peer WTRU (e.g., in a discovery message or dedicated PC5 RRC), SL RSRP measurements made at the WTRU itself, SL RSRP measurements received from the peer WTRU, SL CQI measurements made at the WTRU itself, and SL CQI measurements that may be received from the peer WTRU.

[0197] For Uu quality / RSRP measurement factors, in one embodiment, the relay WTRU may determine the PDB to be used on the SL based on the Uu quality measured at the relay WTRU. Such measurements may be, for example, measurements of CQI, RSRP, etc. associated with the Uu link at the relay WTRU. In another embodiment, the relay WTRU may provide Uu quality measurements or measurement indications to the remote WTRU. The remote WTRU may determine the PDB to be used on the SL based on the received measurements or measurement indications.

[0198] In the case of flow control message causes, in one embodiment, the remote WTRU may determine the PDB based on receipt of one or more flow control messages from the relay WTRU indicating the load / delay in relaying at the relay WTRU. In one example, the remote WTRU may select a first PDB when no flow control message is received and possibly a second PDB upon receipt of flow control within a configured time frame. In another example, the remote WTRU may select a PDB associated with the load of a particular RLC channel included in a flow control message from the relay WTRU. In another example, the remote WTRU may select a PDB associated with the number of flow control messages received over a configured time frame. In a particular embodiment, only those flow control messages for which the load associated with a particular RLC channel is above a threshold may be counted.

[0199] While the above discussion focuses on determining the SL portion of a PDB for resource selection purposes, the same techniques can be used to determine the Uu portion of a PDB (e.g., to discard data beyond the PDB on Uu).

[0200] 13 is an example of a method for meeting packet error rate. 13 is an example of a WTRU selecting a reliability parameter from a configured PER value. In one embodiment, the WTRU may receive a packet error rate (PER) value or similar reliability value associated with a transmission, an LCH, a destination, etc. Such values ​​may be applicable, for example, to a transmission over the sidelink, intended for a relay. The WTRU may receive such values ​​as part of the SL LCH configuration from the gNB. The WTRU may further receive such values ​​as QoS information included in the actual transmission (e.g., from the gNB for a WTRU-to-network relay). This may be included in an adaptation layer header or similar protocol header. Such may also be included in the control channel (e.g., in a DCI associated with a DL transmission, or in a SCI associated with a sidelink transmission).

[0201] The WTRU may select a reliability factor associated with a transmission based on the PER value of the transmission and apply such reliability factor to the transmission having such PER value. Possible reliability factors may indicate any of the following information: whether duplication on SL, possibly associated with a different SL carrier, should be performed, and whether HARQ-enabled or HARQ-disabled transmissions should be transmitted on the SL. In addition, the reliability factors may include any of the following: maximum / minimum number of SL carriers that can be used for resource selection and / or duplication of a transmission, maximum / minimum number of SL retransmissions that are allowable for data, sensing type that the WTRU is allowed to use, resource pool that the WTRU is allowed to select, and allowable partial sensing parameters that can be used for a transmission associated with such PER. Other reliability factors are not excluded.

[0202] For example, a sensing type (e.g., random selection vs. sensing-based resource selection) may be configured with an acceptable PER or range of PER values. For example, a resource pool may be configured with an acceptable PER or range of PER values. For example, a WTRU may be configured with a set of partial sensing parameters or restrictions for a given PER value or range of values.

[0203] The WTRU may receive, for example, a dedicated RRC signaling or SIB (System Information Block) or configuration of an acceptable reliability factor for a given PER or range of PERs. Alternatively, the acceptable reliability factor may be predefined per PER value or range of PER values.

[0204] In one embodiment, an LCH configured with a PER value (or range) may be used as part of the LCP restrictions for transmission. Specifically, the WTRU may select only LCHs whose PER is within a range to include data in a grant (e.g., an SL grant), where such a range may be configured by the network.

[0205] In one example, a Mode 1 WTRU may be configured with an acceptable PER range for a particular grant (e.g., in the DCI or RRC for the configured grant). The WTRU may only include LCHs whose configured PER falls within the PER range for the particular grant when it performs an LCP for that grant. The PER range may be given explicitly or may be derived by the WTRU as a range above / below / around a PER value indicated by the network (e.g., in the DCI).

[0206] In another example, the WTRU may select a first logical channel (e.g., SL LCH) for inclusion in the grant. Following such selection, the WTRU may limit the selection of additional logical channels to a range determined by the first selected logical channel. Such range may be (pre-)configured with a size (PER value) around the selected PER value / range of the initially selected logical channel.

[0207] Referring to FIG. 7, a method 700 implemented in a WTRU may include step 710 of determining a first priority level of an uplink data transmission based on a priority level of a first uplink logical channel to determine whether to prioritize an uplink transmission or a sidelink transmission.

[0208] The method may include determining 720 a second priority level of the sidelink data transmission based on a priority level of a second uplink logical channel, where the second uplink logical channel corresponds to a sidelink logical channel associated with the sidelink data transmission. The second uplink logical channel may be mapped from an adaptation layer mapping of the WTRU to a sidelink logical channel associated with the sidelink data transmission. Determining the priority level of the second uplink logical channel may include determining one or more uplink logical channels associated with the sidelink logical channel and determining a priority level of the second uplink logical channel based on the determined one or more uplink logical channels.

[0209] The method may comprise transmitting 730 one of a sidelink data transmission or an uplink data transmission based on a comparison between the first priority level and the second priority level. The comparison may be a direct comparison.

[0210] Although the features and elements are described above in certain combinations, one skilled in the art will understand that each feature or element may be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware embodied in a computer-readable medium for execution by a computer or processor. Examples of non-transitory computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in the WTRU 102, a WTRU, a terminal, a base station, an RNC, or any host computer.

[0211] Furthermore, in the above-described embodiments, processing platforms, computing systems, controllers, and other devices including processors are described. These devices may include at least one central processing unit ("Central Processing Unit (CPU") and memory. In accordance with the practices of those skilled in the art of computer programming, references to operations and symbolic representations of operations or instructions may be performed by various CPUs and memories. Such operations and operations or instructions may be referred to as being "executed," "computer executed," or "CPU executed."

[0212] Those skilled in the art will appreciate that the operations and symbolically represented operations or instructions include the manipulation of electrical signals by the CPU. The electrical system represents data bits that may cause a resulting transformation or reduction of the electrical signals, and maintains the data bits in memory locations of the memory system, thereby reconfiguring or otherwise altering the operation of the CPU and the processing of other signals. The memory locations in which the data bits are maintained are physical locations that have particular electrical, magnetic, optical, or organic properties that correspond to or represent the data bits. It should be appreciated that the exemplary embodiments are not limited to the platforms or CPUs mentioned above, and that other platforms and CPUs may support the methods provided.

[0213] The data bits may also be maintained on a computer readable medium, including magnetic disks, optical disks, and any other volatile (e.g., random access memory ("RAM")) or non-volatile (e.g., read only memory ("ROM")) mass storage system readable by a CPU. The computer readable medium may include computer readable medium that resides exclusively on a processing system, or that is distributed, cooperative, or interconnected among multiple interconnected processing systems that may be local or remote to a processing system. It will be appreciated that representative embodiments are not limited to the memories described above, and that other platforms and memories may support the methods described.

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

[0215] There is little distinction between hardware and software implementations of aspects of the system. The use of hardware or software is generally (though not always, in certain circumstances the choice between hardware and software may be significant) a design choice that implies a cost vs. efficiency tradeoff. There may be a variety of vehicles (e.g., hardware, software, and / or firmware) in which the processes and / or systems and / or other techniques described herein may be effective, and the preferred vehicle may vary depending on the context in which the processes and / or systems and / or other techniques are deployed. For example, if an implementer determines that speed and accuracy are paramount, the implementer may select a primarily hardware and / or firmware vehicle. If flexibility is paramount, the implementer may select a primarily software implementation. Alternatively, the implementer may select some combination of hardware, software, and / or firmware.

[0216] The foregoing detailed description has illustrated various embodiments of devices and / or processes through the use of block diagrams, flow charts, and / or examples. To the extent that such block diagrams, flow charts, and / or examples include one or more functions and / or operations, those skilled in the art will appreciate that each function and / or operation in such block diagrams, flow charts, or examples may be individually and / or collectively implemented by a wide variety of hardware, software, firmware, or substantially any combination thereof. Suitable processors include, by way of example, general purpose processors, special purpose processors, conventional processors, digital signal processors (DSPs), multiple microprocessors, one or more microprocessors associated with a DSP core, controllers, microcontrollers, application specific integrated circuits (ASICs), application specific standard products (ASSPs), field programmable gate array (FPGA) circuits, any other type of integrated circuit (IC), and / or state machines.

[0217] Although features and elements are provided above in specific combinations, one skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. The present disclosure is not limited in terms of the specific embodiments described in this application, which are intended as illustrations of various aspects. As will be apparent to those skilled in the art, many modifications and variations may be made without departing from the spirit and scope of the present invention. No element, operation, or instruction used in the description of this application should be construed as critical or essential to the invention unless expressly set forth as such. In addition to those enumerated herein, functionally equivalent methods and apparatuses within the scope of the present disclosure will be apparent to those skilled in the art from the foregoing description. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure is to be limited only by the terms of the appended claims, along with the full scope of equivalents to which such claims are entitled. It is to be understood that the present disclosure is not limited to any particular method or system.

[0218] It should also be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, when referred to herein, "station" and its abbreviation "STA", "user equipment" and its abbreviation "UE" may mean (i) a wireless transmit and / or receive unit (WTRU) such as the described infrastructure, (ii) any of several embodiments of a WTRU such as the described infrastructure, (iii) a wireless enabled and / or wired enabled (e.g., tethered) device configured with some or all of the structure and functionality of a WTRU such as the described infrastructure, among others, (iii) a wireless enabled and / or wired enabled device configured with less than all of the structure and functionality of a WTRU such as the described infrastructure, or (iv) others. Details of an exemplary WTRU that may be representative of any WTRU enumerated herein are provided below with respect to Figures 1A-1E.

[0219] In certain representative embodiments, some portions of the subject matter described herein may be implemented via application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integrated formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein may be equivalently implemented in whole or in part in an integrated circuit as one or more computer programs running on one or more computers (e.g., one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., one or more programs running on one or more microprocessors), as firmware, or as substantially any combination thereof, and that designing circuitry and / or writing software and / or firmware code is within the skill of those skilled in the art in light of this disclosure. In addition, those skilled in the art will recognize that the mechanisms of the subject matter described herein may be distributed as program products in various forms, and that representative embodiments of the subject matter described herein apply regardless of the particular type of signal-bearing medium used to actually effect the distribution. Examples of signal bearing media include, but are not limited to, recordable type media such as floppy disks, hard disk drives, CDs, DVDs, digital tape, computer memory, and transmission type media such as digital and / or analog communications media (e.g., fiber optic cables, wave guides, wired communications links, wireless communications links, etc.).

[0220] The subject matter described herein may in some cases depict different components that are included within or connected to different other components. It should be understood that such depicted architectures are merely examples, and that in fact many other architectures that achieve the same functionality may be implemented. Conceptually, any arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality may be achieved. Thus, any two components combined herein to achieve a particular functionality may be viewed as being "associated with" one another such that the desired functionality is achieved, regardless of the architecture or intermediate components. Similarly, any two components so associated may be considered to be "operably connected" or "operably coupled" to one another to achieve the desired functionality, and any two components that can be associated in this way may be considered to be "operably couplable" to one another to achieve the desired functionality. Examples of operably coupleable include, but are not limited to, physically matable and / or physically interacting components, and / or wirelessly interactable and / or wirelessly interacting components, and / or logically interacting and / or logically interacting components.

[0221] With respect to the use of substantially any plural and / or singular term herein, those of skill in the art may convert from plural to singular and / or from singular to plural as appropriate to the context and / or application. For purposes of clarity, various singular / plural permutations may be expressly set forth herein.

[0222] In general, those skilled in the art will understand that the terms used in this specification, and particularly in the appended claims (e.g., the body of the appended claims), are generally intended as "open" terms (e.g., the term "including" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," and the term "includes" should be interpreted as "includes but is not limited to"). Furthermore, those skilled in the art will understand that where a specific number of recitations of an introduced claim are intended, such intention is expressly set forth in the claim, and in the absence of such recitation, no such intention exists. For example, where only one item is intended, the term "single" or similar language may be used. To aid in understanding, the following appended claims and / or the description herein may include the use of the introductory phrases "at least one" and "one or more" to introduce the recitation of the claims. However, the use of such phrases should not be construed as meaning that the introduction of a claim recitation with the indefinite article "a" or "an" limits any particular claim that includes such an introduced claim recitation to embodiments that include only one such recitation, even if the same claim contains the introductory phrase "one or more" or "at least one)" and an indefinite article such as "a" or "an" (e.g., "a" and / or "an" should be construed to mean "at least one" or "one or more)." The same applies to the use of definite articles used to introduce claim recitations.In addition, even if a particular number of recitations in an introduced claim is explicitly recited, those of skill in the art will recognize that such recitation should be interpreted to mean at least the recitation number (e.g., the simple recitation "two recitations" without other qualifiers means at least two recitations, or more than two recitations). Furthermore, when a term similar to "such as at least one of A, B, and C" is used, such a structure is generally intended as a person of skill in the art would understand the term (e.g., "a system having at least one of A, B, and C" includes, but is not limited to, a system having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together). When a notation similar to "such as at least one of A, B, or C" is used, such structure is generally intended as the skilled artisan would understand the notation (e.g., "a system having at least one of A, B, or C" includes, but is not limited to, systems having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together). Those skilled in the art will further appreciate that virtually any disjunctive word and / or phrase presenting two or more alternative terms, whether in the specification, claims, or drawings, should be understood to contemplate the possibility of including one of the terms, either of the terms, or both terms. For example, the phrase "A or B" should be understood to include the possibilities of "A" or "B" or "A and B." Additionally, as used herein, the term "any of" followed by a list of items and / or a list of categories of items is intended to include "any of," "any combination of," "any more than," and / or "any combination of more than" the items and / or categories of items, individually or in combination with other items and / or other categories of items.Further, as used herein, the term "set" or "group" is intended to include any number of items, including zero. Additionally, as used herein, the term "number" is intended to include any number, including zero.

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

[0224] As will be appreciated by those skilled in the art, for all purposes, including in terms of providing a written description, all ranges disclosed herein also encompass any possible subranges and combinations of subranges thereof. Any recited range can be readily recognized as fully descriptive and allowing the same range to be broken down into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each range discussed herein may be readily broken down into a lower third, a middle third, an upper third, etc. As will also be appreciated by those skilled in the art, all words such as "up to," "at least," "greater than," "less than" and the like refer to ranges that include the recited numbers and that can be further broken down into subranges as discussed above. Finally, as will be appreciated by those skilled in the art, a range includes each individual element. Thus, for example, a group having 1 to 3 cells refers to a group having 1, 2, or 3 cells. Similarly, a group having 1 to 5 cells refers to groups having 1, 2, 3, 4, or 5 cells, and so on.

[0225] Moreover, the claims should not be read as limited to the provided order or to the provided elements unless specifically so stated. In addition, the use of the term "means for" in any claim is intended to invoke 35 U.S.C. ...

[0226] Although the invention is illustrated and described herein with reference to specific embodiments, the invention is not intended to be limited to the details shown. Rather, various modifications in the details can be made within the scope of the claims and their equivalents and without departing from the invention.

[0227] Throughout this disclosure, those skilled in the art will appreciate that certain representative embodiments may be used in the alternative or in combination with other representative embodiments.

[0228] Although the features and elements are described above in certain combinations, one skilled in the art will understand that each feature or element may be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware embodied in a computer-readable medium for execution by a computer or processor. Examples of non-transitory computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor associated with software may be used to implement a radio frequency transceiver for use in a UE, a WTRU, a terminal, a base station, an RNC, or any host computer.

[0229] Furthermore, in the above-described embodiments, processing platforms, computing systems, controllers, and other devices including processors are described. These devices may include at least one central processing unit ("CPU") and memory. In accordance with the practices of those skilled in the art of computer programming, references to operations and symbolic representations of operations or instructions may be performed by various CPUs and memories. Such operations and operations or instructions may be referred to as being "executed," "computer executed," or "CPU executed."

[0230] Those skilled in the art will appreciate that the operations and symbolically represented operations or instructions include the manipulation of electrical signals by the CPU. The electrical system represents data bits that may cause a resulting transformation or reduction of the electrical signals, and maintains the data bits in memory locations of the memory system, thereby reconfiguring or otherwise altering the operation of the CPU and the processing of other signals. The memory locations in which the data bits are maintained are physical locations that have particular electrical, magnetic, optical, or organic properties that correspond to or represent the data bits.

[0231] The data bits may also be maintained on a computer readable medium, including magnetic disks, optical disks, and any other volatile (e.g., random access memory ("RAM")) or non-volatile (e.g., read only memory ("ROM")) mass storage system readable by a CPU. The computer readable medium may include computer readable medium that resides exclusively on a processing system, or that is distributed, cooperative, or interconnected among multiple interconnected processing systems, which may be local or remote to a processing system. It will be appreciated that representative embodiments are not limited to the memories described above, and that other platforms and memories may support the methods described.

[0232] No element, act, or instruction used in the description of this application should be construed as critical or essential to the invention unless expressly described as such. Additionally, as used herein, the article "a" is intended to include one or more items. Where only one item is intended, the term "one" or similar language may be used. Additionally, as used herein, the term "any of," followed by a list of items and / or a list of categories of items, is intended to include "any of," "any combination of," "any more than," and / or "any more than" of the items and / or categories of items, individually or in combination with other items and / or categories of items. Additionally, as used herein, the term "set" is intended to include any number of items, including zero. Additionally, as used herein, the term "number" is intended to include any number, including zero.

[0233] Moreover, the claims should not be read as limited to the described order or to the provided elements unless specifically so stated. In addition, the use of the term "means for" in any claim is intended to invoke 35 U.S.C. 112, paragraph 6, and no claim without the word "means for" is so intended.

[0234] Suitable processors include, by way of example, 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), an application specific standard product (ASSP), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), and / or a state machine.

[0235] A processor in association with software may be used to implement a radio frequency transceiver for use in a wireless transmit / receive unit (WTRU), user equipment (UE), terminal, base station, mobility management entity (MME) or evolved packet core (EPC), or any host computer. The WTRU may be used in conjunction with other components, such as, for example, a software defined radio (SDR), and other hardware and / or software implemented modules, such as a camera, a video camera module, a video phone, a speaker phone, a vibration device, a speaker, a microphone, a television transceiver, a hands-free headset, a keyboard, a Bluetooth module, a frequency modulation (FM) radio unit, a near field communication (NFC) module, a liquid crystal display (LCD) display unit, an organic light emitting diode (OLED) display unit, a digital music player, a media player, a video game player module, an Internet browser, and / or a wireless local area network (WLAN) or an ultra wide band (UWB) module.

[0236] Although the present invention has been described with respect to a communications system, it is contemplated that the system may be implemented in software on a microprocessor / general purpose computer (not shown). In particular embodiments, one or more of the functions of the various components may be implemented in software controlling a general purpose computer.

[0237] In addition, although the invention is illustrated and described herein with reference to specific embodiments, the invention is not intended to be limited to the details shown, but rather, various modifications can be made in the details within the scope of the claims and their equivalents and without departing from the invention.

[0238] References The following references may have been mentioned above and are incorporated by reference herein in their entireties: [1]RP-193253-New SID:Study on NR sidelink relay [2]3GPP TS 36.300-TSGRAN E-UTRA and E-UTRAN Overall Description Stage 2(V15.4.0) [3]3GPP TR 36.746-Study on Further enhancements to LTE D2D,UE to network relays for IoT and Wearables(V15.1.1) [4]3GPP TS 38.300-NR and NG-RAN Overall Description Stage 2(V16.1.1)

Claims

1. 1. A method implemented in a wireless transmit / receive unit (WTRU), comprising: determining a first priority level for the uplink data transmission based on the priority level of the first uplink logical channel; determining one or more uplink logical channels mapped to the sidelink logical channels; determining a second priority level for a second uplink logical channel based on the determined one or more uplink logical channels; determining a third priority level for a sidelink data transmission based on the second priority level of the second uplink logical channel, the second uplink logical channel corresponding to the sidelink logical channel associated with the sidelink data transmission; transmitting one of the sidelink data transmission or the uplink data transmission based on a comparison between the first priority level and the third priority level. A method for providing the above.

2. 2. The method of claim 1, wherein the second priority level of the second uplink logical channel corresponds to a highest or lowest priority level among the one or more uplink logical channels.

3. determining that the uplink data transmission will overlap with the sidelink data transmission. The method of claim 1 or 2, comprising:

4. determining that the sidelink data transmission from the WTRU corresponds to a Layer 2 destination of a remote WTRU. The method of claim 1 or 2, comprising:

5. 3. The method according to claim 1, wherein the sidelink logical channel is (1) a highest priority sidelink logical channel for the sidelink data transmission, or (2) a lowest priority sidelink logical channel for the sidelink data transmission.

6. 3. The method of claim 1, wherein the transmitting step of one of the sidelink data transmission or the uplink data transmission comprises transmitting the one having a higher priority level.

7. 3. The method of claim 1, wherein the second uplink logical channel maps from an adaptation layer mapping of the WTRU to the sidelink logical channel associated with the sidelink data transmission.

8. 3. The method of claim 1, wherein the second uplink logical channel comprises Quality of Service (QoS) requirements that map to the sidelink logical channel associated with the sidelink data transmission.

9. A wireless transmit / receive unit (WTRU) comprising: a processor; a transceiver unit; and a storage unit; determining a first priority level for the uplink data transmission based on the priority level of the first uplink logical channel; determining one or more uplink logical channels mapped to the sidelink logical channels; determining a second priority level for a second uplink logical channel based on the determined one or more uplink logical channels; determining a third priority level for a sidelink data transmission based on the second priority level of the second uplink logical channel, the second uplink logical channel corresponding to the sidelink logical channel associated with the sidelink data transmission; transmitting one of the sidelink data transmission or the uplink data transmission based on a comparison between the first priority level and the third priority level. The WTRU is configured to:

10. The WTRU of claim 9 , wherein the second priority level of the second uplink logical channel corresponds to a highest or lowest priority level among the one or more uplink logical channels.

11. 11. The WTRU of claim 9 or 10, configured to determine that the uplink data transmission will overlap with the sidelink data transmission.

12. 11. The WTRU of claim 9, wherein the sidelink logical channel is (1) a highest priority sidelink logical channel for the sidelink data transmission, or (2) a lowest priority sidelink logical channel for the sidelink data transmission.

13. 11. The WTRU of claim 9 or 10, wherein transmitting one of the sidelink data transmission or the uplink data transmission comprises transmitting the one with a higher priority level.

14. The WTRU of claim 9 or 10, wherein the second uplink logical channel maps from an adaptation layer mapping of the WTRU to the sidelink logical channel associated with the sidelink data transmission.

15. 11. The WTRU of claim 9 or 10, wherein the second uplink logical channel includes a quality of service (QoS) requirement that maps to the sidelink logical channel associated with the sidelink data transmission.

Images