Methods, architectures, devices, and systems for Quality of Service (QoS) enforcement at the Media Access Control (MAC) layer

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 on September 29, 2021, which is incorporated herein by reference in its entirety.

[0002] The present disclosure relates to a method and apparatus for enforcing quality of service at a Media Access Control (MAC) layer. More specifically, the present disclosure relates to a method and apparatus for determining priorities of sidelink data transmission and uplink data transmission in a network.

Background Art

[0003] The 3GPP Release 17 study [1] on NR sidelink relay is planned to investigate the use of both WTRU-to-network relay and WTRU-to-WTRU relay (sidelink) based on PC5, with a particular focus on the reasons / objectives of the study item.

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

[0005] Further exploration of coverage extensions for sidelink-based communications is needed for WTRU-to-network coverage extensions. Uu coverage reachability is necessary for a WTRU to reach a server within a Packet Data Network (PDN) or to reach a counterpart WTRU when outside the network's vicinity. However, the Release 13 solution for WTRU-to-network relay is limited to EUTRA-based technology and therefore cannot be applied to NR-based systems for both NG-RAN and NR-based sidelink communications.

[0006] Further exploration of coverage extensions for sidelink-based communications is needed for further WTRU-to-WTRU coverage extensions. Currently, proximity reachability is limited to single-hop sidelink links via either EUTRA-based or NR-based sidelink technologies. However, this is insufficient in scenarios where Uu coverage is absent, given the limited single-hop sidelink coverage.

[0007] Overall, the NR framework should further enhance sidelink connectivity to support the expanded QoS requirements.

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

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

[0010] The study shall take into account further input from SA WGs, e.g., SA2 and SA3, for each of the above items (where applicable). It is assumed that WTRU-to-network relay and WTRU-to-WTRU relay use the same relay solution. Forward compatibility for multi-hop relay support in future releases must be considered. For Layer 2 WTRU-to-network relay, end-to-end PDCP and hop-by-hop Radio Link Control (RLC) architectures are adopted as starting points, as recommended, for example, in TR36.746. [Overview of the Initiative]

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

[0012] In one embodiment, the method includes determining the priority level of a second uplink logical channel, which may include determining one or more uplink logical channels associated with a 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 can correspond to the highest or lowest priority level among one or more uplink logical channels.

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

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

[0016] The method may include a step of determining whether uplink data transmission will overlap with sidelink data transmission.

[0017] The method may include a step of determining that the sidelink data transmission from the WTRU corresponds to a Layer 2 destination on 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] Sending either sidelink data or uplink data may include sending one of the two with 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 can be mapped from the WTRU's adaptive layer mapping to the sidelink logical channel associated with sidelink data transmission.

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

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

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

[0025] The WTRU may be further configured to determine a priority level of a second uplink logical channel, and determining the priority level of the second uplink logical channel may comprise determining one or more uplink logical channels associated with a 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 a sidelink threshold, the priority level of the second uplink logical channel may correspond to the maximum priority level among the one or more uplink logical channels.

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

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

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

[0031] The sidelink logical channel may be a highest priority sidelink logical channel in sidelink data transmission, or a lowest priority sidelink logical channel in sidelink data transmission.

[0032] Sending either sidelink data or uplink data may include sending one of the two with 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 can be mapped from the WTRU's adaptive layer mapping to the sidelink logical channel associated with sidelink data transmission.

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

[0036] A more detailed understanding can be obtained from the following detailed description, provided in conjunction with the drawings attached to this specification. The figures in such drawings, as well as the detailed description, are illustrative. Therefore, the figures and detailed description should not be considered limiting, and other equally effective embodiments are possible and likely. Furthermore, similar reference numerals ("ref") within the figures ("FIG") indicate similar elements. [Figure 1A] This is a system diagram illustrating a typical communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] This is a system diagram illustrating a typical wireless transmit / receive unit (WTRU) that may be used in a communication system illustrated in Figure 1A, according to one embodiment. [Figure 1C] This is a system diagram illustrating a typical radio access network (RAN) and a typical core network (CN) that can be used in a communication system illustrated in Figure 1A according to one embodiment. [Figure 1D]This is a system diagram illustrating further representative RANs and further representative CNs that may be used in the communication system illustrated in Figure 1A according to one embodiment. [Figure 2] This diagram shows the protocol stack for the user plane of a Layer 2 evolved WTRU versus network relay. [Figure 3] This figure shows the protocol stack for the control plane of a Layer 2 evolved WTRU versus network relay. [Figure 4] This diagram illustrates a specific drawback in the 3GPP Rel.16 network system related to channel prioritization for SL and UL channels. [Figure 5] This diagram illustrates a specific drawback in the 3GPP Rel.17 network system related to channel prioritization for SL and UL channels. [Figure 6] This flowchart illustrates a channel prioritization method for SL and UL according to one embodiment. [Figure 7] This flowchart illustrates an example of a method implemented in WTRU for determining whether to prioritize uplink or sidelink transmissions. [Modes for carrying out the invention]

[0037] The following detailed description includes numerous specific details to provide a complete understanding of the embodiments and / or examples disclosed herein. However, it will be understood that such embodiments and examples may be practiced without some or all of the specific details described herein. In other examples, well-known methods, procedures, components and circuits are not 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, those embodiments and other examples explicitly, implicitly, and / or essentially (collectively "provided") described, disclosed or otherwise provided herein.

[0038] An example network for implementing the embodiment. Figure 1A illustrates a typical 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, message transmission, and broadcast to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication 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 filtering OFDM, and filter bank multicarrier (FBMC).

[0039] As shown in Figure 1A, the communication system 100 may include radio transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, but it will be understood that the disclosed embodiments intend any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a radio environment. For example, WTRU102a, 102b, 102c, 102d, any of which may be referred to as “station” and / or “STA”, may include user equipment (UE), mobile stations, fixed subscriber units or mobile subscriber units, subscriber-based units, radio 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 devices, 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 on commercial and / or industrial wireless networks, etc. Any of WTRU102a, 102b, 102c, and 102d may be interchangeably referred to as UE.

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

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

[0042] Base stations 114a and 114b may communicate with one or more WTRUs 102a, 102b, 102c, and 102d via the air interface 116, which may be any suitable radio 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 described above, the communication system 100 may be a multiple access system and may use one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base stations 114a and WTRUs 102a, 102b, 102c in RAN 104 / 113 may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use wideband CDMA (WCDMA) to establish air interfaces 115 / 116 / 117. WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink Packet Access (HSDPA) and / or High-Speed ​​UL Packet Access (HSUPA).

[0044] In one embodiment, base stations 114a and WTRUs 102a, 102b, and 102c may implement radio technologies 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 WTRUs 102a, 102b, and 102c may implement radio technologies such as NR radio access, or they may use New Radio (NR) to establish the air interface 116.

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

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

[0048] The base station 114b in Figure 1A may be, for example, a wireless router, home Node B, home eNode B, or access point, and may utilize any suitable RAT to facilitate wireless connectivity in local areas such as offices, homes, vehicles, campuses, industrial facilities, aerial corridors (for use by drones), roads, etc. In one embodiment, the base station 114b and WTRU 102c, 102d may implement wireless technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and WTRU 102c, 102d may implement wireless technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base stations 114b and WTRUs 102c, 102d may establish picocells or femtocells using cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As shown in Figure 1A, base station 114b may have a direct connection to the internet 110. Therefore, base station 114b may not need to access the internet 110 via CN 106 / 115.

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

[0050] CN106 / 115 may also function as a gateway for WTRU102a, 102b, 102c, 102d to access PSTN108, the Internet 110, and / or other networks 112. PSTN108 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, which use common communication protocols such as the transmission control protocol (TCP), the user datagram protocol (UDP), and / or the Internet protocol (IP) of the TCP / IP Internet protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN104 / 113 or a different RAT.

[0051] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multiple mode functionality (for example, WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different radio networks via different radio links). For example, WTRU 102c shown in Figure 1A may be configured to communicate with a base station 114a that may use cellular-based radio technology and a base station 114b that may use IEEE 802 radio technology.

[0052] Figure 1B is a system diagram illustrating a typical WTRU102. As shown in Figure 1B, the WTRU102 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 supply 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be understood that the WTRU102 may include any partial combination of the aforementioned elements while maintaining consistency with one embodiment.

[0053] The processor 118 may be a general-purpose processor, a dedicated 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 functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120 which can be coupled to a transmit / receive element 122. Although Figure 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.

[0054] The transmit / receive element 122 may be configured to transmit a signal to or receive a signal from a base station (e.g., base station 114a) via 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, for example, IR, UV, or visible light signals. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF signals and optical signals. It will be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of radio signals.

[0055] Although the transmit / receive element 122 is depicted as a single element in Figure 1B, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may utilize 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 radio signals via the air interface 116.

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

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

[0058] The processor 118 may receive power from the power supply 134, but may also be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 may be any suitable device for supplying power to the WTRU 102. For example, the power supply 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), a solar cell, a fuel cell, 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) about the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may determine its location by receiving location information from base stations (e.g., base stations 114a, 114b) via the air interface 116 and / or based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 may acquire location information by any preferred location determination method while maintaining consistency with one embodiment.

[0060] The processor 118 may be further connected to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, 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 peripheral device 138 may include one or more sensors, one or more of which may be a gyroscope, accelerometer, Hall effect sensor, magnetometer, compass sensor, proximity sensor, temperature sensor, time sensor, geolocation sensor, altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor, and / or humidity sensor.

[0061] WTRU102 may include a full-duplex radio in which the transmission and reception of some or all of the signals associated with specific subframes for both UL (e.g., for transmission) and downlink (e.g., for reception) may be in parallel and / or simultaneous. The full-duplex radio may include an interference management unit 139 for reducing and / or substantially eliminating self-interference via either hardware (e.g., chokes) or signal processing via a processor (e.g., via a separate processor (not shown) or processor 118). In one embodiment, WTRU102 may include a half-duplex radio for the transmission and reception of any of the signals (e.g., associated with specific subframes for either UL (e.g., for transmission) or downlink (e.g., for reception)).

[0062] Figure 1C is a system diagram illustrating RAN104 and CN106 according to one embodiment. As described above, RAN104 may communicate with WTRU102a, 102b, and 102c via the air interface 116 using E-UTRA wireless technology. RAN104 may also communicate with CN106.

[0063] RAN104 may include eNode-B160a, 160b, and 160c, but it will be understood that RAN104 may include any number of eNode-B while maintaining consistency with one embodiment. Each of eNode-B160a, 160b, and 160c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, eNode-B160a, 160b, and 160c may implement MIMO technology. Thus, eNode-B160a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU102a.

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

[0065] The CN106 shown in Figure 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 aforementioned elements is depicted as part of CN106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0066] MME162 can be connected to each of the eNode-B162a, 162b, and 162c in RAN104 via the S1 interface and can function as a control node. For example, MME162 may perform roles such as authenticating users of WTRU102a, 102b, and 102c, activating / deactivating bearers, and selecting gateways for specific services during the initial attachment of WTRU102a, 102b, and 102c. MME162 may also provide control plane functions for exchange between RAN104 and other RANs (not shown) using GSM and / or other radio technologies such as WCDMA.

[0067] SGW164 may be connected to each of the eNodeB160a, 160b, and 160c in RAN104 via the S1 interface. SGW164 may generally route and forward user data packets to and from WTRU102a, 102b, and 102c. SGW164 may also perform other functions, such as anchoring the user plane during eNode B handovers, triggering paging when DL data is available to WTRU102a, 102b, and 102c, and managing and remembering the context of WTRU102a, 102b, and 102c.

[0068] SGW164 may be connected to PGW166, which may provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices.

[0069] CN106 can facilitate communication with other networks. For example, CN106 may provide WTRU102a, 102b, and 102c with access to a circuit-switched network such as PSTN108 to facilitate communication between WTRU102a, 102b, and 102c and conventional terrestrial line communication devices. For example, CN106 may include, or communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that functions as an interface between CN106 and PSTN108. In addition, CN106 may provide WTRU102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0070] Although the WTRU is described as a wireless terminal in Figures 1A to 1D, in certain representative embodiments, such a terminal is intended to be able to use a wired communication interface with a communication network (for example, temporarily or permanently).

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

[0072] A WLAN in Infrastructure Basic Service Set (BSS) mode may have access points (APs) of the BSS and one or more stations (STAs) associated with the APs. The APs may have access to or interfaces with other types of wired / wireless networks that carry traffic entering and / or leaving the Distribution System (DS) or BSS. Traffic originating outside the BSS and destined for the STAs may reach and be delivered to the STAs via the APs. Traffic originating from the STAs and destined for destinations outside the BSS may be sent to the APs and then delivered to their respective destinations. Traffic between STAs within the BSS may be transmitted, for example, via the APs; a source STA may send traffic to the APs, and the APs may deliver the traffic to the destination STAs. Traffic between STAs within the BSS may be considered and / or referred to as same-layer traffic. Same-layer traffic may be transmitted between a source STA and a destination STA (for example, directly between them) via a direct link setup (DLS). In certain representative embodiments, the DLS may be an 802.11e DLS or an 802.11z tunneled DLS (TDLS). A WLAN using independent BSS (IBSS) mode may not have APs, and STAs within or using IBSS (e.g., all STAs) may communicate directly with one another. The IBSS mode of communication may be referred to herein as an "ad-hoc" communication mode.

[0073] When using the 802.11ac infrastructure operating mode or a similar operating mode, an AP may transmit beacons on a fixed channel, such as a primary channel. The primary channel may be of a fixed width (e.g., a 20 MHz bandwidth) or a width dynamically set via signaling. The primary channel may be the operating channel of the BSS and may be used by the STA to establish a connection with the AP. In certain typical embodiments, for example, in an 802.11 system, carrier-sensing multiple access (CSMA / CA) with collision avoidance may be implemented. In the case of CSMA / CA, the STA, including the AP (e.g., all STAs), may sense the primary channel. If the primary channel is sensed / detected and / or determined to be operational by a particular STA, that 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, via 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 channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. The 40 MHz and / or 80 MHz channels may be formed by combining multiple consecutive 20 MHz channels. A 160 MHz channel may be formed by combining eight consecutive 20 MHz channels, or by combining two non-consecutive 80 MHz channels, which may be referred to as an 80+80 configuration. In the case of an 80+80 configuration, after channel coding, the data may pass through a segment parser that can split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing may be performed separately for each stream. The streams may be mapped to two 80 MHz channels, and the data may be transmitted by a transmission STA. In the receiving STA, the operation described above for an 80+80 configuration may be reversed, and the combined data may be sent to Medium Access Control (MAC).

[0076] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports bandwidths of 5 MHz, 10 MHz, and 20 MHz in the TV White Space (TVWS) spectrum, while 802.11ah supports bandwidths of 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz using the non-TVWS spectrum. According to a typical embodiment, 802.11ah may support meter-type control / machine-type communications, such as MTC devices within a macro-notification range area. MTC devices may have specific features, including support for specific and / or limited bandwidths (e.g., support only for those bandwidths). MTC devices may include batteries with battery life exceeding a threshold (e.g., to maintain very long battery life).

[0077] A WLAN system capable of supporting multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah includes a channel that can be designated as the primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by an STA from among all STAs operating in a BSS that support the minimum bandwidth operating mode. In an 802.11ah embodiment, the primary channel may be 1 MHz wide for an STA (e.g., an MTC type device) that supports (e.g., only) the 1 MHz mode, even if other STAs in the AP and 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 operational due to an STA (which only supports 1MHz operating mode) transmitting to the AP, the entire available frequency band may be considered operational, even though a large portion of the frequency band remains idle and could potentially be available.

[0078] In the United States, the available frequency band that can be used with 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] Figure 1D is a system diagram illustrating RAN113 and CN115 according to an embodiment. As described above, RAN113 may communicate with WTRU102a, 102b, and 102c via air interface 116 using NR radio technology. RAN113 may also communicate with CN115.

[0080] RAN113 may include gNB180a, 180b, and 180c, but it will be understood that RAN113 may include any number of gNBs while maintaining consistency with the embodiment. Each of gNB180a, 180b, and 180c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, gNB180a, 180b, and 180c may implement MIMO technology. For example, gNB180a and 180b may use beamforming to transmit and / or receive signals to and from gNB180a, 180b, and 180c. Thus, gNB180a may, for example, use multiple antennas to transmit and / or receive radio signals from WTRU102a. In one embodiment, gNB180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB180a may transmit multiple component carriers to WTRU102a (not shown). A subset of these component carriers may be on the unauthorized spectrum, and the remaining component carriers may be on the authorized spectrum. In one embodiment, gNB180a, 180b, and 180c may implement coordinated multi-point (CoMP) technology. For example, WTRU102a may receive coordinated transmissions from gNB180a and gNB180b (and / or gNB180c).

[0081] WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using transmissions associated with an expandable numerology. For example, OFDM symbol intervals and / or OFDM subcarrier intervals may vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of varying or expandable lengths (e.g., containing varying numbers of OFDM symbols and / or having varying absolute time durations).

[0082] gNB180a, 180b, and 180c may be configured to communicate with WTRU102a, 102b, and 102c in standalone and / or non-standalone configurations. In a standalone configuration, WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c without accessing other RANs (e.g., e-node-B160a, 160b, and 160c). In a standalone configuration, WTRU102a, 102b, and 102c may use one or more of gNB180a, 180b, and 180c as mobility anchor points. In a standalone configuration, WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using signals in unauthorized bands. In a non-standalone configuration, WTRU102a, 102b, and 102c can communicate with and connect to gNB180a, 180b, and 180c, while also communicating with and connecting to other RANs such as eNode-B160a, 160b, and 160c. For example, WTRU102a, 102b, and 102c can implement DC principles for substantially simultaneous communication with one or more gNB180a, 180b, and 180c and one or more eNode-B160a, 160b, and 160c. In a non-standalone configuration, eNode-B160a, 160b, and 160c can function as mobility anchors for WTRU102a, 102b, and 102c, while gNB180a, 180b, and 180c can provide additional coverage and / or throughput to service WTRU102a, 102b, and 102c.

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

[0084] The CN115 shown in Figure 1D may include at least one AMF182a, 182b, at least one UPF184a, 184b, at least one Session Management Function (SMF)183a, 183b, and optionally a Data Network (DN)185a, 185b. Although each of the aforementioned elements is depicted as part of the CN115, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0085] AMF182a and 182b may be connected via the N2 interface to one or more gNB180a, 180b, and 180c in RAN113 and may function as control nodes. For example, AMF182a and 182b may perform roles such as authenticating users of WTRU102a, 102b, and 102c, supporting network slices (e.g., handling different PDU sessions with different requirements), selecting specific SMF183a and 183b, managing registration areas, terminating non-accessible layer (NAS) signaling, and mobility management. Network slices may be used by AMF182a and 182b to customize CN support for WTRU102a, 102b, and 102c based on the type of service utilizing WTRU102a, 102b, and 102c. For example, different network slices may be established for different use cases, such as services that rely on ultra-reliable low latency (URLLC) access, services that rely on enhanced massive mobile broadband (eMBB) access, and services for machine type communication (MTC) access. The AMF162 may provide control plane functions for exchange between the RAN113 and other RANs (not shown) using other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or WiFi.

[0086] SMF183a and 183b may be connected to AMF182a and 182b in CN115 via the N11 interface. SMF183a and 183b may also be connected to UPF184a and 184b in CN115 via the N4 interface. SMF183a and 183b may select and control UPF184a and 184b and configure routing of traffic through UPF184a and 184b. SMF183a and 183b may perform other functions such as managing and assigning UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types may be IP-based, non-IP-based, Ethernet-based, etc.

[0087] UPF184a and 184b may be connected via the N3 interface to one or more of the gNB180a, 180b, and 180c in RAN113, thereby providing WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices. UPF184 and 184b may perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multiple home PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

[0088] CN115 may facilitate communication with other networks. For example, CN115 may include, or communicate with, an IP gateway (e.g., an IP Multiplex Media Subsystem (IMS) server) that functions as an interface between CN115 and PSTN108. In addition, CN115 may provide WTRU102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRU102a, 102b, 102c may be connected to local data networks (DN) 185a, 185b via UPF184a, 184b through an N3 interface to UPF184a, 184b, and an N6 interface between UPF184a, 184b and DN185a, 185b.

[0089] In view of Figures 1A to 1D and their corresponding descriptions, one or more of the functions described herein with respect to one or more of the WTRU102a to d, base stations 114a to b, e-nodes B160a to c, MME162, SGW164, PGW166, gNB180a to c, AMF182a to b, UPF184a to b, SMF183a to b, DN185a to 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 of the functions described herein. For example, emulation devices may be used to test other devices and / or simulate network and / or WTRU functions.

[0090] Emulation devices may be designed to implement one or more tests of other devices in a laboratory and / or 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 network to test other devices in a communications 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 network. Emulation devices may be directly coupled to another device for testing purposes and / or may perform tests using terrestrial radio communication.

[0091] One or more emulation devices may perform one or more functions, including all of the above, while not implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device may be used in a test laboratory test scenario, and / or in a wired and / or wireless communication network that is not deployed (e.g., for testing purposes), to implement testing of one or more components. One or more emulation devices may also be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation device to transmit and / or receive data.

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

[0093] More specifically, [2] states in Section 23.10.4 that "The ProSe WTRU-to-Network Relay provides a general L3 forwarding function that can relay any type of IP traffic between a 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 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 the higher layer and may reside within the coverage of the public safety ProSe carrier, or outside the coverage on any supporting 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 within the coverage of EUTRAN. ProSe WTRU-to-network relay and remote WTRU perform sidelink communication and sidelink discovery, as described in Sections 23.10 and 23.11, respectively.

[0094] An example of relay selection for WTRU versus network relay. Relay selection / re-selection for ProSe WTRU versus network relays is based on a combination of AS Layer Quality Measurement (RSRP) and higher-layer criteria.

[0095] This is described in more detail in section 23.10.4 of the Stage 2 specification, as follows [2]: The eNB controls whether a WTRU can operate as a ProSe WTRU to Network Relay. ProSe WTRU to Network Relay operation is supported within a cell if the eNB broadcasts any information associated with ProSe WTRU to Network Relay operation. The eNB may provide either transmit resources for ProSe WTRU to Network Relay discovery using broadcast signaling for the RRC_IDLE state and dedicated signaling for the RRC_CONNECTED state, or receive resources for ProSe WTRU to Network Relay discovery using broadcast signaling. The eNB may broadcast minimum and / or maximum Uu Link Quality (RSRP) thresholds that a ProSe WTRU to Network Relay must respect before it can initiate a WTRU to Network Relay discovery procedure. In RRC_IDLE, when the eNB broadcasts the transmit resource pool, the WTRU can use the thresholds to autonomously initiate or terminate 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 vs. Network Relay Discovery.

[0096] If the eNB does not broadcast a transmit resource pool for ProSe-WTRU versus network relay discovery, the WTRU can respect these broadcasted thresholds and initiate a request for ProSe-WTRU versus network relay discovery resources through dedicated signaling.

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

[0098] A ProSe WTRU to network relay performing sidelink communication for ProSe WTRU to network relay operation must be in the RRC_CONNECTED state. After receiving a Layer 2 link establishment request or a TMGI (Temporary Mobile Group Identity) monitoring request (upper 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 then provide resources for ProSe WTRU inter-network relay communication.

[0099] A remote WTRU can decide when to begin monitoring for ProSe WTRU versus network relay discovery. Depending on the configuration of resources for ProSe WTRU versus network relay discovery, a remote WTRU can send a ProSe WTRU versus network relay discovery request message while in RRC_IDLE or RRC_CONNECTED state. The eNB can broadcast a threshold that is used by the remote UE to determine whether the remote WTRU can send a ProSe WTRU versus network relay discovery request message to connect or communicate with the ProSe WTRU versus network relay WTRU. An RRC_CONNECTED remote WTRU can use the broadcasted threshold to determine whether it can indicate to the eNB that it is a remote WTRU and wishes to participate in ProSe UE versus network relay discovery and / or communication. The eNB can provide transmit resources for ProSe WTRU inter-network relay operation using broadcast or dedicated signaling, and provide receive resources using broadcast signaling. The remote WTRU will stop using ProSe WTRU-to-Network Relay Discovery and communication resources 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 the higher layer).

[0100] The remote WTRU performs radio measurements on the PC5 interface and uses them, along with higher-layer criteria, for ProSe WTRU-to-network relay selection and reselection. A ProSe WTRU-to-network relay is considered suitable from a radio criterion standpoint if its PC5 link quality exceeds a configured (pre-configured 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 a ProSe WTRU-to-network relay reselection when the current PC5 signal strength of the ProSe WTRU-to-network relay falls below the configured signal strength threshold. It receives a Layer 2 link release message (upper layer message) from the ProSe WTRU-to-network relay.

[0102] An example of WTRU-to-network relay for wearable devices. In Release 14, research on WTRU-to-Network relays for commercial use cases tailored to wearable and IoT devices was conducted in RAN [3]. While such research did not result in any specifications, a technical report (TR) provided several preferred solutions for such relays. In contrast to ProSe WTRU-to-Network relays using L3 (IP layer) relay techniques, WTRU-to-Network relays for wearable devices are expected to be L2 relays 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 a Layer 2 evolved WTRU-to-Network relay (PC5).

[0103] An example of establishing a connection for a unicast link in NR V2X. In previous releases of the LTE specification, the relay solution was based on a one-to-one communication link established at the upper layer (ProSe layer) between two WTRUs (remote WTRU and WTRU-to-network relay). Such a connection was transparent to the AS (Access Layer) layer, and connection management signaling and procedures performed at the upper layer 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 a unicast link between two WTRUs. Such a unicast link is initiated by the upper layer (as in a ProSe one-to-one connection). However, the AS layer is notified of the existence of such a unicast link 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 power control schemes specific to unicast.

[0105] Unicast links at the AS layer are supported via PC5-RRC connections. [4] A PC5-RRC connection is defined as follows: A PC5-RRC connection is a logical connection between a pair of source Layer 2 IDs and a destination Layer 2 ID within an AS. One PC5-RRC connection corresponds to one PC5 unicast link.[xx] PC5-RRC signaling may be initiated after the establishment of its corresponding PC5 unicast link, as specified in Section 5.X.9. The PC5-RRC connection and its corresponding sidelink SRB and sidelink DRB are released when the PC5 unicast link is released as indicated by the upper layer. 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 has been established and secured. One sidelink SRB is used to transmit PC5-RRC signaling, which is protected and sent only after PC5-S security has been established.

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

[0107] The comparison of logical channel priorities is an operation frequently performed by the WTRU, for example, when performing LCP (Logical Channel Prioritization) for UL transmissions. In the case of sidelinks (SLs), in addition to LCP, the WTRU also performs a priority comparison to determine whether to prioritize UL transmissions or SL transmissions when both transmissions cannot be performed simultaneously. Following the 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 are in conflict) is performed using separate UL and SL priorities. For example, the mapping from PQI to SL priority does not have to follow the same rules as the mapping from 5QI (5G QoS identifier) ​​to Uu priority. Also, the range of SL priority (1-8) does not coincide with the range of Uu priority (1-16).

[0108] In the case of WTRU-to-network relay, an SL transmission can be either a normal SL transmission (initiated by the SL service in the relay WTRU itself) or relayed Uu traffic. In such cases, the prioritization between UL transmissions 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 between SL traffic over the SL (for example, for operations such as SL destination selection in LCP) and relayed Uu traffic over the SL may need to be reconsidered, taking into account that Uu traffic priority may not be adequately represented by SL LCH (logical channel) priority. Figures 4 and 5 illustrate the nature of the issues in Rel. 16 and Rel. 17, respectively.

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

[0110] Furthermore, in the case of WTRU versus network relay, end-to-end Uu QoS parameters such as Packet Data Budget (PDB) and Packet Error Rate (PER) need to be partitioned by the gNB so that these parameters can be applied across both the SL and Uu links. While it may be possible to have a static partition, the conditions for the SL and Uu can change dynamically, and therefore it is beneficial to update the partition when radio quality and congestion conditions change on both links. However, if the network needs to update the partition using RRC signaling every time conditions change (and send such signaling to both the remote WTRU and the relay WTRU), it will incur significant signaling overhead. Additionally, the network's response may not be timely because conditions on both links can change very rapidly.

[0111] Enhanced QoS enforcement. In the following description, a method for prioritizing between SL and UL data or traffic is disclosed in the context of relay. In such description, SL and UL data or transmission refers 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 can perform SL transmissions of Uu traffic in the context of SL WTRU-to-network relay. In that case, the following solution refers to such transmissions as Uu traffic transmitted over SL, or SL data containing Uu traffic.

[0112] Examples of operations / behaviors that may be affected by prioritization rules. The traffic prioritization methods described herein can be used to determine any mechanism or outcome of the following operations in a WTRU. The operation may consist of SL destination selection in an LCP. Specifically, a WTRU may use such prioritization rules to select an SL destination L2 ID for transmissions within an SL grant.

[0113] Another operation can consist of LCH selection during LCP. Specifically, the WTRU can use such prioritization rules to select SL LCHs to be multiplexed within the SL grant. Specifically, the WTRU can use such prioritization rules to select between MAC CEs and LCHs when multiplexing data into the SL grant.

[0114] Another approach may involve prioritizing between SL BSRs and Uu BSRs when both are included in a UL grant.

[0115] Another operation could involve prioritizing between UL grants and SL grants. Specifically, a WTRU could use such prioritization rules to determine whether to prioritize between UL grants and SL grants, for example, if the WTRU can only send one of the grants and must abandon the others.

[0116] Another operation may consist of determining whether to trigger instructions / transmissions to the network, including but not limited to SRs (Scheduling Requests), BSRs (Broadcasting Service Requests), and support information. For example, a WTRU may trigger an SR when data arrives on a logical channel whose priority exceeds the priority of any waiting data in the WTRU. Such priority determination or comparison may be performed using any of the rules described herein.

[0117] Another action could involve determining whether to trigger a mode 2 resource and / or carrier (re)selection. For example, the WTRU could determine whether a mode 2 resource and / or carrier (re)selection is triggered depending on the outcome of a prioritization decision / rule.

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

[0119] Another operation may involve determining which resource pool should be used for transmission. For example, a WTRU may select a resource pool for transmission according to one of the prioritization rules described herein.

[0120] An example of a method for deriving priority values ​​for SL transmissions that carry relayed Uu data. For comparison of priorities for the operations described herein (e.g., between SLs and SLs, or between ULs and SLs), the WTRU may need to derive a priority value associated with an SL transmission containing relayed data. Any of the following embodiments for deriving priorities can be considered as part of a technique that requires determining the priority associated with an SL transmission carrying relayed data.

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

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

[0123] In one group of embodiments, the WTRU can 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 into which the data is multiplexed in the SL transmission. Alternatively, the single SL RLC channel may be the lowest priority SL priority SL RLC channel into which the data is multiplexed in the SL transmission. Alternatively, the single SL RLC channel may be one of the SL RLC channels multiplexed for the SL transmission, whose priority may be the middle, average, or intermediate of the set of SL priorities associated with the SL RLC channels having the data multiplexed in the grant. Without loss of generality, a selection can be made among the choices within this group using other factors described herein (e.g., selecting one SL RLC channel for another depending on other factors described herein). In such a group of embodiments, the priority of the SL transmission can be derived from the priority of the Uu RLC channel mapped to this single SL RLC channel.

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

[0125] Next, the WTRU can determine which Uu RLC channels can be mapped to one or more of the above SL RLC channels (for example, in adaptive layer configuration / mapping).

[0126] In one embodiment, 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 a Uu RLC channel having the highest priority, lowest priority, middle / average priority, etc. The WTRU may use other factors described herein to determine which Uu RLC channel should be used to derive the priority.

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

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

[0129] An example of deriving priority for SL transmissions, including relayed traffic, based on QoS information during transmission.

[0130] In another embodiment, the WTRU can derive priorities based on QoS information included with the SL transmission (e.g., in the adaptive layer header). In another solution, the WTRU can receive QoS requirements (e.g., 5QI). The WTRU can derive equivalent Uu priorities based on a configured mapping (similar to the previous solution). Alternatively, the WTRU can derive equivalent mappings based on a similar mapping of PQIs to LCH priorities configured for another bearer in the WTRU (e.g., a non-relayed Uu bearer).

[0131] Example of comparing SL and SL transmission An example of comparing SL traffic using a method other than direct priority ranking. Prioritization between logical channels is generally performed by comparing LCH priorities. In one mechanism, a WTRU can use a method other than direct priority value comparison when performing any of the above operations / operations. Such a different method can be applied to comparisons between any of the following data / LCHs: when comparing data to be relayed with data not to be 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 hop counts remaining to their destination.

[0132] Methods for comparing these data and / or LCHs may be one of the following techniques: applying an offset, increase, decrease, or compensation in the priority based on a coefficient; comparing the priority of each data / LCH against different thresholds; and using direct comparison.

[0133] More specifically, the application of offsets, increases, decreases, or compensations in priority may be based on factors such as hop count. For example, WTRU may apply an offset or compensation to the priority of data when the hop count of that data or the remaining hop count exceeds a configured threshold, or it may apply an offset specific to the difference in the remaining hop count between the data being compared. For example, WTRU may perform a direct comparison of offsets when the remaining hop counts for the data being compared are the same or within a configured threshold, or it may perform a different comparison (using the methods described herein).

[0134] More specifically, the application of offsets, increases, decreases, or compensations in priority can also be based on factors such as the Channel Busy Ratio (CBR). For example, a WTRU may have its priority increased (i.e., its priority increased) if the CBR exceeds a threshold, and not otherwise. Such priority increases can be applied, for example, when comparing two destinations / LCHs with unequal hop counts.

[0135] According to one embodiment, which includes prioritizing each data / LCH and comparing it with different thresholds, the WTRU can be configured with different thresholds (e.g., one applicable to Uu traffic and another to SL traffic). For example, when performing LCP, the WTRU can first select UL / SL traffic based on conditions relating to whether UL traffic exceeds a first threshold and / or whether SL traffic falls below a second threshold. If the conditions for prioritizing based on these thresholds are not met, the WTRU can perform a direct comparison. For example, the WTRU can prioritize UL traffic if its UL traffic priority exceeds a threshold. If its UL traffic priority falls below a threshold, the WTRU can still prioritize UL traffic if SL traffic falls below another threshold. If none of these conditions are met, the WTRU can directly compare priorities when determining which destination or logical channel to select during LCP, or it can prioritize one of the two (e.g., UL traffic) by default, or it can prioritize traffic with more hops.

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

[0137] An example of a comparison between SL traffic and Uu traffic relayed through SL. When prioritizing between SL traffic and Uu traffic via SL, the WTRU may use any of the following information, or, in some cases, a combination of the following information associated with SL traffic, Uu traffic, or both, to determine which should take precedence.

[0138] The SL priority associated with an SL RLC channel carrying either SL traffic or Uu traffic. The Uu priority of a Uu RLC channel mapped to an 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 specified herein, such as the number of hops, the number of remaining hops, and the SL CBR.

[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] Metrics associated with QoS or remaining QoS are provided by the adaptive layer, possibly statically, with each PDU or for a set of PDUs. For example, such a metric may be the remaining lifetime associated with a PDU, representing the amount of time until the PDU exceeds its latency budget, or, in other examples, one of the thresholds configured in the embodiments herein in relation to priority may be configured for each range of the remaining lifetime associated with a PDU.

[0143] Measurements of SL channels (e.g., CBR, RSRP, CSI, etc.), for example, any of the configured thresholds described in a priority-related solution, may be configured for each CBR, RSRP, CSI, etc.

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

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

[0146] Example of SL destination selection during LCP procedure. The following typical embodiments illustrate SL destination selection in the LCP procedure. However, the decision criteria can be used for any other prioritization decisions described herein. In addition, several typical embodiments below can be used in combination for prioritization. Specifically, for example, a WTRU may use the first example when certain conditions are met, and another example when those conditions are not met. Alternatively, a WTRU may use the first example to select between destination IDs, and the second example when selecting between LCHs sent to the same destination ID.

[0147] In one example, a 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 to an SL RLC channel by the adaptive layer includes one of the SL RLC channels that has data available to send Uu traffic above the configured Uu priority threshold to an SL destination (and exceeds the preferred bitrate, i.e., bj>0), the WTRU may select an SL destination with Uu traffic over that SL destination with SL traffic. Otherwise, the WTRU may decide whether to select an SL destination with SL traffic or an SL destination with Uu traffic based on other embodiments described herein.

[0148] In another example, a WTRU may be configured with an SL priority threshold to prioritize Uu traffic. For instance, a WTRU might choose an SL destination with SL traffic over an SL destination with Uu traffic if one of the SL RLC channels with available SL traffic (and exceeding a preferred bitrate) contains data exceeding the SL priority threshold.

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

[0150] In another example, a WTRU may be constructed using a threshold remaining life time. If the actual remaining life time associated with a PDU, or the data in a PDU, falls below the threshold, the WTRU may prioritize the destination associated with such a PDU.

[0151] In another example, a WTRU could be configured using a CBR threshold. If the measured CBR is above the threshold, the WTRU can use a first rule to prioritize SL destinations with Uu traffic over SL destinations with SL traffic; if the CBR is below the threshold, the WTRU can use a second rule.

[0152] Another potentially applicable example when other criteria are equal / not met is that a WTRU can prioritize relayed traffic over unrelated traffic. Specifically, it can choose an SL destination with Uu traffic over an SL destination with SL traffic.

[0153] Examples of further considerations when an SL destination / LCH can contain both SL traffic and Uu traffic. SL destinations and / or LCHs may include Uu traffic relayed via sidelinks and SL traffic. This traffic may be included in destinations with data available within an LCH or for different LCHs (an LCH containing SL traffic and an LCH containing Uu traffic).

[0154] In such scenarios, the WTRU may be configured with rules for selecting between SL destinations containing only SL traffic, SL destinations containing only Uu traffic, and SL destinations containing both SL and Uu traffic. Such rules may be applicable to destinations permitted to transmit only SL traffic, destinations permitted to transmit only Uu traffic, and / or destinations permitted to transmit both. Alternatively or additionally, similar rules may be applicable to destinations permitted to transmit both, but these rules apply between destinations that have only SL traffic available for transmission (or exceed the PBR), destinations that have only Uu traffic available for transmission (or exceed the PBR), and destinations that have both SL and Uu traffic available for transmission (or exceed the PBR).

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

[0156] In one embodiment, the WTRU can be configured to prioritize destinations based on acceptable or available traffic types. For example, a destination having both available channel types (Uu and SL) may be preferred over a destination having only one channel type. Such a thing may apply when the same priority is determined for two destinations, in which case the two destinations have a priority within a certain range relative to each other.

[0157] In one embodiment, both SL priority (e.g., direct comparison) or Uu priority (e.g., threshold-based comparison) can be used, and if either comparison results in a preference for destinations that support relayed traffic, the WTRU can 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) can be used, and if the comparison results in a preference for destinations that support relayed traffic, the WTRU can select the destination that supports relayed traffic. Otherwise, it can select a destination that supports both types of traffic.

[0159] An example comparing two Uu traffics, both of which are relayed via SL. A WTRU can be selected between two different Uu traffics relayed via an SL. For selection / prioritization between such SL transmissions, the WTRU can use any of the following: a direct comparison of SL LCH priorities, a comparison of Uu RLC channels mapped to SL RLC channels by an adaptive layer, and the remaining and / or total number of hops to be used for relaying.

[0160] For example, in the case of a direct comparison of SL LCH priorities, the WTRU can compare two (or more) SL destinations, both of which carry Uu traffic by a direct comparison of only SL RLC channel priorities. In some embodiments, this method can be employed only in subset cases. For example, such a direct comparison can only be performed if the number of remaining hops to the destination is the same for the Uu traffic.

[0161] For example, in the case of comparing Uu RLC channels mapped to SL RLC channels by an adaptive layer, the WTRU can compare the priority of the highest-priority Uu RLC LCH mapped to the SL RLC channel LCH being compared and select the destination that maximizes the Uu RLC LCH priority. In another example, the WTRU can compare the priority of the lowest-priority Uu RLC LCH mapped to the SL RLC channel LCH being compared and select the destination that maximizes the Uu RLC channel LCH priority. In yet another example, the WTRU can compare the priority of the average-priority Uu RLC LCH mapped to the SL RLC channel LCH being compared and select the destination that maximizes the average priority. In yet another example, the WTRU can compare the priority of the highest-priority Uu RLC LCH mapped to the SL RLC channel LCH being compared and that contributed to the data available in the buffer in the SL RLC channel and select the destination that maximizes the Uu RLC LCH priority. In 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 an SL RLC channel is above / below a threshold, and otherwise use SL RLC channel priority comparison. In some embodiments, this approach may be adopted only for a subset of cases. For example, such a direct comparison may only be possible if the number of remaining hops to the destination for Uu traffic is the same.

[0162] Exemplary embodiment. In an exemplary embodiment, a WTRU may increase the priority associated with an SL transmission having more remaining hops when the CBR is above a threshold. Specifically, a WTRU may derive the priority of an SL transmission associated with relayed Uu traffic using the method described herein. When comparing the priorities of two different SL transmissions (whether the SL transmissions contain Uu transmissions or not), the WTRU may take into account the number of remaining hops in the transmission. When the CBR is above a threshold, the WTRU may prioritize the transmission associated with more 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 remaining hops when the CBR is above a threshold. Alternatively, the WTRU may apply a priority offset to a transmission, where such a priority offset is based on the number of remaining hops and can only be applied when the CBR is above a threshold.

[0163] An example comparing SL transmission and UL transmission. Direct comparison is applicable when SL data is relayed UL traffic. In one embodiment, in a comparison between SL and UL (for example, for the purpose of UL / SL prioritization applied in legacy systems), the WTRU can first determine whether the SL data is relaying UL traffic. If the WTRU is not relaying UL traffic over the SL data, the WTRU can 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 traffics were below the first threshold and the SL traffic was below the second threshold. Conversely, if the SL data carries Uu traffic, the WTRU can directly compare the priority of the UL data with the Uu priority associated with the SL data.

[0164] Specifically, the Uu priority of SL traffic can be derived by any of the methods described herein in previous sections. For example, such priority can 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 adaptive layer. Specifically, the WTRU can derive the priority of Uu traffic (associated with SL data) used for comparison with UL transmissions, as in any of the following examples.

[0165] For example, the Uu priority may be the highest priority Uu RLC channel mapped in the adaptive 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 mapped in the adaptive 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 mapped to the SL RLC channels being compared in the adaptive layer configuration.

[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 following: the highest / lowest priority values, the CBR of the SL data, the number of hops or remaining hops of the relayed data, the lifetime parameter associated with the relayed data, the relationship between the Uu priority and the SL priority, and parameters in the LCH configuration.

[0169] For example, WTRU can use the highest priority as the Uu priority if the highest priority exceeds the threshold, and otherwise use the lowest priority.

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

[0171] In yet another example, WTRU can use the highest priority as the Uu priority if the lifespan of any / all data associated with the relayed data falls below a threshold, and the lowest priority otherwise.

[0172] In a further example, WTRU can use the highest priority as the Uu priority if the SL priority exceeds the configured threshold associated with the highest / lowest Uu priorities mapped to the SL LCH, and otherwise use the lowest Uu priority.

[0173] In a further example, if the WTRU consists of instructions for the SL RLC channel to use the highest priority, then the highest priority can be used as the Uu priority; otherwise, the lowest priority can be used.

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

[0175] Exemplary embodiment. In an exemplary embodiment, an SL relay WTRU can determine whether to prioritize a UL transmission or an SL transmission based on whether the SL transmission is relayed Uu traffic, and if so, can compare the UL priority with either the highest-priority Uu RLC channel or the lowest-priority Uu RLC channel mapped to the SL RLC channel in the adaptive layer. Specifically, the SL relay WTRU can determine that it cannot transmit both SL and UL simultaneously. Such a WTRU can then transmit either an SL or a UL depending on whether SL or UL is preferred. If the SL transmission corresponds to an L2 destination of a remote WTRU receiving the SL traffic, or if the SL transmission includes an LCH associated with Uu traffic relayed to the remote WTRU, the relay WTRU can derive a priority (different from the SL RLC channel priority) for comparison with the Uu traffic priority. In such cases, the SL transmission priority may be determined as the priority level of either the highest-priority or lowest-priority Uu RLC channel mapped by the adaptive layer to the maximum SL RLC channel priority included in the SL transmission. If the SL RLC channel priority exceeds a threshold, the maximum value is used. If the SL RLC channel priority is below the threshold, the minimum value is used.

[0176] Figure 6 is a flowchart illustrating such an embodiment. In step 602, the relay WTRU simultaneously receives UL and SL transmissions that require prioritization and decides which transmission to send. In step 604, the relay WTRU decides whether the SL transmission corresponds to an L2 destination of the remote WTRU. If not, the flow proceeds to step 606, where the relay WTRU prioritizes the UL transmission if (a) the priority of the UL transmission is greater than the 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 the second SL threshold.

[0177] In response to this, if it is determined in step 604 that the SL transmission corresponds to the L2 destination of the remote WTRU, the 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 adaptive layer mapping.

[0179] Next, in step 612, the relay WTRU determines whether the SL LCH priority exceeds another threshold. If it does, the 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 does not exceed the threshold, the flow instead proceeds 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, the 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 priority assigned in the comparison step (614 or 616).

[0181] An example of a method for transmitting a BSR in a relay scenario. WTRU will decide whether or not to report SL / Uu BSR. In relay scenarios, the transmission of an SL / Uu BSR may be unnecessary because the network can recognize the WTRU's buffer status from such knowledge from previous links. The WTRU may decide whether to report an SL / Uu BSR based on one or a combination of the following factors: Deciding whether to report an SL / Uu BSR may involve deciding one of the following conditions: whether an SL / Uu BSR is triggered in the WTRU, which logical channels trigger / do not trigger an SL / Uu BSR, whether data received from the LCH should be included in the SL / Uu BSR, how much data (e.g., a portion, a percentage) should be included in the SL / Uu BSR, and which ingress RLC channels mapped to the same exit RLC channel should contribute to the data reported in the SL / Uu BSR.

[0182] Examples based on LCH configuration and / or L2 ID. In one embodiment, a 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, a WTRU may be configured with L2 destination IDs for which an SL BSR should or should not be reported. For example, an SL relay WTRU may report an SL BSR for an SL logical channel / L2 destination ID carrying SL traffic, but may not report an SL BSR for an SL logical channel / L2 destination ID carrying Uu traffic (i.e., DL relayed traffic). In another example, an SL relay WTRU may be configured with SL logical channels for which an SL BSR is reported / triggered or not reported / triggered (e.g., in an LCH configuration provided by the network). For example, an SL relay WTRU may be configured to report / trigger an SL BSR only for SL LCH / destination IDs of RLC bearers that do not have an adaptive layer associated with the RLC bearer's SL LCH / destination ID (i.e., for WTRU-to-network relay).

[0183] An example based on the previous hop's cell ID / coverage / assignment mode. In one embodiment, a relay WTRU may, in some cases, determine whether to report / trigger an SL BSR based on the cell ID and / or assignment mode associated with a previous hop WTRU, compared to the cell ID and / or assignment mode of the relay WTRU itself. Specifically, for example, a first WTRU (relay or remote) may transmit to a second WTRU (relay) the cell ID of the cell to which it is connected, and / or the WTRU's SL assignment 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 if it is configured to operate in mode 1 with that cell, and may not transmit any cell ID if 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 via a Uu) can determine whether to trigger an 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 to which it received data from the first WTRU, the second WTRU may not report a BSR, but if it is connected to a different cell, the second WTRU may report a BSR. "Same cell" could be, for example, the same cell ID or equivalent cell ID configured by the network.

[0184] In relevant embodiments applicable to multi-hop (more than two-hop) scenarios, the first WTRU in the above embodiments can transmit cell ID information and / or assignment modes for multiple / all hops along the path between the source and destination WTRU / gNB. Specifically, the first WTRU can transmit its own cell ID and / or assignment mode, as well as any accompanying WTRU cell ID and / or assignment mode. A second WTRU can transmit the same information received from the first WTRU, as well as its own cell ID and / or assignment mode, to a 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 information received from previous WTRUs. For example, a WTRU may report / trigger a (SL or UL)BSR for an LCH according to any of the following conditions: at least one of the previous hop WTRUs having a cell ID that does not match the cell ID of that WTRU; at least one of the previous hop WTRUs having mode 2 as its resource allocation mode; all of the previous hop WTRUs having a cell ID different from the cell ID of that WTRU; and all of the previous hop WTRUs having 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 a case is the actual cell ID of the gNB. Specifically, a 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 is carrying relayed or non-relayed data. Specifically, a WTRU may report a BSR if the LCH is carrying non-relayed data (i.e., data received by the WTRU from a higher layer and not from another WTRU).

[0187] An example based on mapping from inlet LCH to outlet LCH in the WTRU's adaptive layer. In one embodiment, the decision of whether or not to trigger / report a BSR may depend on specific rules relating to the mapping from the inlet LCH to the outlet LCH in the WTRU and / or previous hops (in the case of a multi-hop scenario).

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

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

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

[0191] In one embodiment, a WTRU can report the amount of data discarded / deleted from one or more LCHs. Such a report may be made to a gNB, for example, to inform the gNB that a certain amount of data has been discarded / deleted and that the gNB can (consequently) schedule less data than the amount initially known to the gNB. Alternatively, a WTRU can report the amount of data discarded / deleted from one or more LCHs to a peer WTRU (e.g., the next hop WTRU), and the peer WTRU can then use this information in its own calculation of the BSR and / or in its own generation of such a report to the network.

[0192] For example, a WTRU can report (e.g., via MAC CE) the amount of data discarded by the WTRU for each 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 failing to meet latency requirements). Alternatively, such reporting may be triggered when the WTRU deletes a specific amount (e.g., a percentage) of data, possibly over a certain period. For example, such reporting may be triggered by the WTRU when the amount of data deleted by the WTRU over a configured period 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] An example of a method for selecting SL transmission parameters. PDB selection via relay / remote WTRU. In one embodiment, a relay WTRU or remote WTRU can be configured (e.g., by the network) using multiple values ​​of a PDB associated with a single RLC channel and / or QoS flow. The WTRU can be further configured using associations between the PDB and factors for PDB selection, as described below. The WTRU can 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 instructions, the number of retransmissions required, SL measurements by the relay / remote WTRU, Uu quality / RSRP measurements, and flow control messages.

[0194] In the case of network instruction factors, in one embodiment, a relay WTRU or remote WTRU may receive instructions for the PDB to be used on the SL RLC channel (e.g., in the DCI type, MAC CE, adaptive layer header, or DCI associated with the same). For example, a relay WTRU may select a PDB based on the DCI type used to schedule DL transmissions for a Uu RLC channel that maps to a corresponding SL RLC channel to which PDB selection is applicable.

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

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

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

[0198] In the case of flow control message factors, in one embodiment, a remote WTRU can determine a PDB based on the reception of one or more flow control messages from a relay WTRU that indicate load / delay when relaying to a relay WTRU. In one example, the remote WTRU may select a first PDB when no flow control messages have been received, and possibly a second PDB when flow control is received within a configured time frame. In another example, the remote WTRU may select a PDB associated with the load of a particular RLC channel contained in a flow control message from a relay WTRU. In yet 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 in which the load associated with a particular RLC channel exceeds a threshold may be counted.

[0199] The above explanation focuses on determining the SL portion of a PDB for resource selection purposes, but the same technique can be used to determine the Uu portion of a PDB (for example, to discard data beyond the Uu portion of the PDB).

[0200] An example of a method to meet the packet error rate requirement. An example of WTRU that selects reliability parameters from configured PER values. In one embodiment, the WTRU may receive a packet error rate (PER) value or similar reliability value associated with the transmit, LCH, destination, etc. Such a value may be applicable, for example, to a sidelink transmit intended for relaying. The WTRU may receive such a value from the gNB as part of the SL LCH configuration. The WTRU may further receive such a value (for example, from the gNB for WTRU to network relay) as QoS information included in the actual transmit. This may be included in the adaptive layer header or a similar protocol header. Such information may also be included within the control channel (for example, within the DCI associated with a DL transmit, or within the SCI associated with a sidelink transmit).

[0201] The WTRU may select reliability factors associated with a transmission based on the transmission's PER value and apply such reliability factors to transmissions with such PER values. Possible reliability factors may indicate either of the following: whether replication should be performed on the SL, and whether a HARQ-enabled or HARQ-invalid transmission should be transmitted on the SL, in some cases associated with different SL carriers. In addition, reliability factors may include any of the following: the maximum / minimum number of SL carriers that can be used for resource selection and / or replication of a transmission; the maximum / minimum number of SL retransmissions that are acceptable for data; the sensing type that the WTRU is allowed to use; the resource pool that the WTRU is allowed to select; and the acceptable partial sensing parameters that can be used for transmissions associated with such PERs. Other reliability factors are not excluded.

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

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

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

[0205] For example, a Mode 1 WTRU can be configured using an acceptable PER range for a particular grant (e.g., in a DCI or RRC for a configured grant). The WTRU can only include LCHs where the configured PER falls within the PER range for that particular grant when performing an LCP on that grant. The PER range may be explicitly given or may be derived by the WTRU as an upper / lower / around range of the PER value indicated by the network (e.g., in a DCI).

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

[0207] Referring to Figure 7, the method 700 implemented in the WTRU may include a step 710 of determining a first priority level for uplink data transmission based on the priority level of a first uplink logical channel in order to determine whether uplink transmission or sidelink transmission should be prioritized.

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

[0209] This method may include step 730 of transmitting either sidelink data or uplink data based on a comparison between a first priority level and a second priority level. The comparison may be a direct comparison.

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

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

[0212] Those skilled in the art will understand that operations and symbolically represented arithmetic or instructions involve the manipulation of electrical signals by the CPU. The electrical system represents data bits that can cause a resulting transformation or reduction of electrical signals, and maintains these data bits in memory locations in the memory system, thereby reconfiguring or otherwise altering the CPU's operations and other signal processing. The memory locations where the data bits are maintained are physical locations having specific electrical, magnetic, optical, or organic properties that correspond to or represent the data bits. It should be understood that exemplary embodiments are not limited to the platforms or CPUs described above, and other platforms and CPUs may support the methods provided.

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

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

[0215] There is little distinction between hardware and software implementations of a system configuration. The use of hardware or software is generally a design choice involving a cost-effectiveness trade-off (though not always, in certain situations the choice between hardware and software can be significant). Various vehicles (e.g., hardware, software, and / or firmware) may exist in which the processes and / or systems and / or other technologies 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 technologies are deployed. For example, if the implementer determines that speed and accuracy are paramount, the implementer may primarily choose hardware and / or firmware vehicles. If flexibility is paramount, the implementer may primarily choose software implementations. Alternatively, the implementer may choose any combination of hardware, software, and / or firmware.

[0216] The detailed description above illustrates various embodiments of devices and / or processes through the use of block diagrams, flowcharts, and / or examples. Those skilled in the art will understand that, insofar as such block diagrams, flowcharts, and / or examples include one or more functions and / or operations, each function and / or operation in such block diagrams, flowcharts, or examples may be implemented individually and / or collectively by a wide range of hardware, software, firmware, or substantially any combination thereof. Suitable processors include, by example, general-purpose processors, dedicated 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] While the features and elements are provided above in specific combinations, those skilled in the art will understand that each feature or element can be used individually or in any combination with other features and elements. This disclosure is not limited in terms of the specific embodiments described herein, which are intended to be illustrative 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 invention. No element, operation, or instruction used in this application should be construed as important or essential to the invention unless expressly presented as such. In addition to those enumerated herein, functionally equivalent methods and apparatus within the scope of this 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. This disclosure is limited only by the terms of the appended claims, and together with the full scope of the equivalents to which such claims are entitled. It should be understood that this disclosure is not limited to any particular method or system.

[0218] It should also be understood that the terms used herein are for the purpose of describing only specific embodiments and are not intended to limit them. Where used herein, and referred to herein, “Station” and its abbreviation “STA,” “User Equipment” and its abbreviation “UE” may mean (i) a radio transmit and / or receive unit (WTRU) such as the infrastructure described herein, (ii) any of several embodiments of a WTRU such as the infrastructure described herein, (iii) a radio-enabled and / or wired (e.g., tetherable) device configured to have some or all of the structure and functions of a WTRU such as the infrastructure described herein, (iii) a radio-enabled and / or wired device configured to have less than all of the structure and functions of a WTRU such as the infrastructure described herein, or (iv) other. Details of exemplary WTRUs that may represent any WTRU enumerated herein are provided below with respect to Figures 1A to 1E.

[0219] In certain representative embodiments, some parts 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, it will be recognized by those skilled in the art that some aspects of the embodiments disclosed herein can be equivalently implemented in an integrated circuit as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or substantially any combination thereof, and that designing circuits and / or writing software and / or firmware code is within the scope of the art of those skilled in the art in light of this disclosure. In addition, it will be understood by those skilled in the art that the mechanisms of the subject matter described herein can be distributed as various forms of program products, and that the representative embodiments of the subject matter described herein are applicable regardless of the particular type of signal transmission medium used to actually carry out the distribution. Examples of signal transmission media include, but are not limited to, recordable media such as floppy disks, hard disk drives, CDs, DVDs, digital tapes, and computer memory, as well as transmitting media such as digital communication media and / or analog communication media (e.g., optical fiber cables, waveguides, wired communication links, wireless communication links, etc.).

[0220] The subject matter described herein may, in some cases, represent different components that are contained within or connected to other different components. It should be understood that such depicted architectures are merely examples, and in practice, many other architectures can be implemented to achieve the same function. Conceptually, any arrangement of components to achieve the same function is effectively “associated” in such a way that the desired function can be achieved. Therefore, any two components combined herein to achieve a particular function, regardless of architecture or intermediate components, can be seen as “associated with” each other in such a way that the desired function can be achieved. Similarly, any two components thus associated may be considered “operably connected” or “operably coupled” to each other in order to achieve the desired function, and any two components that can be associated in such a way may be considered “operably coupleable” to each other in order to achieve the desired function. Specific examples of components that can be operably coupled include, but are not limited to, components that are physically matable and / or physically interactable, and / or wirelessly interactable and / or wirelessly interactable, and / or logically interactable and / or logically interactable.

[0221] With regard to the use of substantially any plural and / or singular terms herein, a person skilled in the art may convert from plural to singular and / or singular to plural as appropriate to the context and / or use. Various singular / plural rearrangements may be explicitly described herein for clarity.

[0222] In general, it will be understood by those skilled in the art that the terms used herein, and in particular in the appended claims (e.g., the body of the appended claims), are generally intended to be “open” terms (for example, 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, if a particular number of descriptions of introduced claims are intended, such intent is explicitly stated in the claims, and if such statement is not present, such intent is not present, it will be understood by those skilled in the art. For example, if only one item is intended, the term “single” or similar wording may be used. For the sake of understanding, the following appended claims and / or descriptions of this specification may include the use of the introductory phrases “at least one” and “one or more” to introduce the details of the claims. However, the use of such phrases should not be interpreted as meaning that the introduction of a claim description with the indefinite article "a" or "an" limits any particular claim containing such introduced description to embodiments containing only one such description, 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" (for example, "a" and / or "an" should be interpreted as meaning "at least one" or "one or more"). The same applies to the use of definite articles used to introduce a claim description.In addition, even if a specific number of claims introduced is explicitly stated, it will be recognized by those skilled in the art that such statements should be interpreted as meaning at least the stated number (for example, the simple statement “two recitations” without other modifiers means at least two statements, or two or more statements). Furthermore, when a notation similar to “at least one of A, B, and C, etc.” is used, such a structure is generally intended to mean what those skilled in the art would understand (for example, “a system having at least one of A, B, and C” includes, but is not limited to, systems having A only, B only, C only, A and B together, A and C together, B and C together, and / or A, B, and C together). Where expressions similar to "at least one of A, B, or C" are used, such structures are generally intended to mean what a person skilled in the art would understand (for example, "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). It will further be understood by a person skilled in the art that substantially any disjunct words and / or phrases presenting two or more alternative terms in the specification, claims, or drawings should be understood as intending to include the possibility of including one of the terms, either of the terms, or both of the terms. For example, the phrase "A or B" should be understood to include the possibilities of "A" or "B" or "A and B". Furthermore, 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 multiple of,” and / or “any multiple combinations of,” items and / or categories of items, individually or in combination with other items and / or categories of other items.Furthermore, as used herein, the terms “set” or “group” are 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, if any feature or aspect of the present disclosure is described in terms of the Markush group, a person skilled in the art will recognize that the present disclosure is also described in terms of any individual component or subgroup of components of the Markush group.

[0224] As will be understood by those skilled in the art, for all purposes, including providing written descriptions, all scopes disclosed herein also encompass any possible sub-scopes and combinations of sub-scopes. Any enumerated scope can be readily recognized as fully explaining and enabling that the same scope can be broken down into at least equal 1 / 2, 1 / 3, 1 / 4, 1 / 5, 1 / 10, etc. In non-limiting embodiments, each scope considered herein may readily be broken down into a lower third, a middle third, an upper third, etc. Also, as will be understood by those skilled in the art, all words such as “up to,” “at least,” “greater than,” and “less than” include the number mentioned and mean a scope that can be further broken down into sub-scopes as considered above. Finally, as will be understood by those skilled in the art, a scope 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 a group having 1, 2, 3, 4, or 5 cells, and so on.

[0225] Furthermore, claims should not be read as being limited to the order or elements provided unless specifically stated so. In addition, the use of the term “means for” in any claim is intended to appeal to Section 112, paragraph 6 of the U.S. Patent Act or the means-plus-function claim format, and no claim without the term “means for” is intended to appeal to that purpose.

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

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

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

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

[0230] Those skilled in the art will understand that operations and symbolically represented arithmetic or instructions involve the manipulation of electrical signals by the CPU. The electrical system represents data bits that can cause a resulting transformation or reduction of electrical signals, and maintains these data bits in memory locations of the memory system, thereby reconfiguring or otherwise altering the CPU's operations and other signal processing. The memory locations where the data bits are maintained are physical locations having specific electrical, magnetic, optical, or organic properties that correspond to or represent the data bits.

[0231] Data bits may also be maintained on computer-readable media, including magnetic disks, optical disks, and any other volatile (e.g., Random Access Memory ("RAM")) or CPU-readable non-volatile (e.g., Read-Only Memory ("ROM")) mass storage systems. The computer-readable media may include cooperative or interconnected computer-readable media distributed among multiple interconnected processing systems, which may reside exclusively on a processing system or be local or remote to the processing system. It will be understood that representative embodiments are not limited to the memory described above, and other platforms and memories may support the methods described.

[0232] Any element, action, or instruction used in the description of this application should not be construed as important or essential to the invention unless expressly stated otherwise. In addition, as used herein, the article "a" is intended to include one or more items. If only one item is intended, the term "one" or similar word may be used. Furthermore, as used herein, the term "any of" followed by a list of multiple items and / or a list of categories of multiple items is intended to include "any of", "any combination of", "any number of", and / or "any number of combinations of", items and / or categories of items, individually or in combination with other items and / or categories of other items. Furthermore, as used herein, the term "set" is intended to include any number of items, including zero. Furthermore, as used herein, the term "number" is intended to include any number, including zero.

[0233] Furthermore, unless otherwise specifically stated, claims should not be read as being limited to the order in which they are described or to the elements provided. In addition, the use of the term “means” in any claim is intended to appeal under Section 112, paragraph 6 of the U.S. Patent Act, and no claim that does not contain the word “means” is intended to appeal under that purpose.

[0234] Suitable processors include, for example, general-purpose processors, dedicated 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.

[0235] A radio frequency transceiver may be implemented using a software-related processor for use in a radio 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 hardware and / or software-implemented modules, including, for example, software-defined radio (SDR), as well as cameras, video camera modules, video phones, speakerphones, vibration devices, speakers, microphones, television transceivers, hands-free headsets, keyboards, Bluetooth® modules, frequency modulation (FM) radio units, near-field communication (NFC) modules, liquid crystal display (LCD) display units, organic light-emitting diode (OLED) display units, digital music players, media players, video game player modules, internet browsers, and / or wireless local area network (WLAN) or ultra-wideband (UWB) modules.

[0236] Although the present invention has been described in relation to a communication system, it is intended that the system may be implemented in software on a microprocessor / general-purpose computer (not shown). In certain embodiments, one or more functions of various components may be implemented in software that controls the general-purpose computer.

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

[0238] References The following references may be mentioned above and are incorporated fully herein by reference. [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. A method implemented in a wireless transmission / reception unit (WTRU), A step of determining a first priority level for uplink data transmission based on the priority level of the first uplink logical channel, The steps include determining one or more uplink logical channels mapped to a sidelink logical channel, The steps include determining a second priority level for a second uplink logical channel based on one or more determined uplink logical channels, A step of determining a third priority level for sidelink data transmission based on the second priority level of the second uplink logical channel, wherein the second uplink logical channel corresponds to the sidelink logical channel associated with the sidelink data transmission. A step of transmitting either 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 this.

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

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

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

5. The method according to claim 1 or 2, wherein the side link logical channel is (1) the highest priority side link logical channel in the side link data transmission, or (2) the lowest priority side link logical channel in the side link data transmission.

6. The method according to claim 1 or 2, wherein the transmitting step of one of the sidelink data transmission or the uplink data transmission includes transmitting the one having a higher priority level.

7. The method according to claim 1 or 2, wherein the second uplink logic channel is mapped from the adaptive layer mapping of the WTRU to the sidelink logic channel associated with the sidelink data transmission.

8. The method according to claim 1 or 2, wherein the second uplink logical channel includes 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 memory unit, Based on the priority level of the first uplink logical channel, the first priority level for uplink data transmission is determined. Determine one or more uplink logical channels mapped to a sidelink logical channel. Based on one or more determined uplink logical channels, a second priority level for a second uplink logical channel is determined. Based on the second priority level of the second uplink logical channel, a third priority level for sidelink data transmission is determined, wherein the second uplink logical channel corresponds to the sidelink logical channel associated with the sidelink data transmission. Based on the comparison between the first priority level and the third priority level, one of the sidelink data transmission or the uplink data transmission is transmitted. A well-structured WTRU.

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

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

12. The WTRU according to claim 9 or 10, wherein the sidelink logical channel is (1) the highest priority sidelink logical channel in the sidelink data transmission, or (2) the lowest priority sidelink logical channel in the sidelink data transmission.

13. The WTRU according to claim 9 or 10, wherein transmitting one of the sidelink data transmissions or the uplink data transmissions includes transmitting the one having a higher priority level.

14. The WTRU according to claim 9 or 10, wherein the second uplink logic channel is mapped from the adaptive layer mapping of the WTRU to the sidelink logic channel associated with the sidelink data transmission.

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

Images