Simultaneous uplink and sidelink operations

Abstract

The invention relates to simultaneous uplink and sidelink operations, and discloses an apparatus that may be configured to determine whether to prioritize SL logical channel groups (LCGs) based on a sidelink (SL) prioritization threshold and the UL prioritization threshold under conditions where the UL prioritization threshold is configured. The apparatus may be configured to determine whether a prioritization value associated with the SL LCG is below the SL prioritization threshold. The apparatus may be configured to determine (e.g., at least) whether an uplink (UL) LCG has a prioritization value equal to or higher than the UL prioritization threshold. The apparatus may be configured to determine whether to prioritize an SL buffer status report (BSR) based on a size of the UL grant and the determination of whether to prioritize the SL LCG. The apparatus may be configured to report a buffer status based on the determination of whether to prioritize the SL BSR.

Description

[0001] This application is a divisional application of Chinese patent application No. 202080060215.6, entitled “Simultaneous uplink and sidelink operations”, filed on July 29, 2020. The contents of the parent application are incorporated herein by reference.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims the benefit of U.S. Provisional Application No. 62 / 880,919, filed on July 31, 2019, and U.S. Provisional Application No. 62 / 909,138, filed on October 1, 2019, the contents of which are incorporated herein by reference. Background Art

[0004] Mobile communications using wireless communications continue to evolve. The fifth generation of mobile communications may be referred to as 5G. Previous (eg, legacy) mobile communications may be, for example, fourth generation (4G) long term evolution (LTE). Summary of the invention

[0005] Systems, methods, and tools for simultaneous uplink and sidelink operations are described herein. A wireless transmit / receive unit (WTRU) may be configured to operate using an uplink (UL) and a sidelink (SL) simultaneously (e.g., for concurrent or simultaneous UL / SL operations). WTRU transmit and / or receive operations may be configured to account for simultaneous UL and SL operations. The WTRU may transmit over one or more UL resources and one or more SL resources during the same set of orthogonal frequency division multiplexing (OFDM) symbols or time slots, for example based on one or more prioritization rules. For example, the WTRU may discard a SL transmission or a UL transmission based on one or more prioritization rules.

[0006] In an example, a method may be implemented to perform simultaneous uplink and sidelink operations. The method may be implemented, for example, by an apparatus (e.g., a WTRU) that may include one or more processors configured to perform the method as computer-executable instructions that may be stored on a computer-readable medium or a computer program product that, when executed by the one or more processors, performs the method. The computer-readable medium or computer program product may include instructions that cause the one or more processors to perform the method by executing the instructions.

[0007] In an example, a WTRU may include a processor configured (e.g., programmed with executable instructions to implement a method) to: determine whether to prioritize a SL LCG based on a SL prioritization threshold and a UL prioritization threshold (e.g., conditional on a UL prioritization threshold being configured); determine whether a prioritization value associated with the SL LCG is lower than the SL prioritization threshold; determine whether (e.g., at least) a UL LCG has a prioritization value equal to or higher than the UL prioritization threshold (e.g., conditional on a UL prioritization threshold being configured); determine whether to prioritize a SL buffer status report (BSR) based on a size of a UL grant and a determination of whether to prioritize the SL LCG; and report a buffer status based on the determination of whether to prioritize the SL BSR. A configurable SL prioritization threshold may be used.

[0008] The SL LCG may include, for example, an LCG having logical channels, for example including SL data. The UL LCG may include an LCG having logical channels, for example including UL data. The determination of whether (at least) the UL LCG has a prioritization value equal to or higher than the UL prioritization threshold may include, for example, the determination of whether (e.g., each) UL LCG has a prioritization value equal to or higher than the UL prioritization threshold.

[0009] The SL BSR may be prioritized, for example, under the condition that the SL LCG is prioritized and under the condition that the size of the UL grant is insufficient for at least (e.g., all) prioritized SL LCGs if the SL BSR is not prioritized. The SL BSR (e.g., if prioritized) may take precedence over the UL BSR. The SL BSR may be prioritized and truncated. The prioritized and truncated SL BSR may include the prioritized SL LCG and another SL LCG if the other SL LCG is prioritized and the size of the UL grant is sufficient for the prioritized SL LCG and the other SL LCG. The SL BSR may be truncated, for example, when not prioritized. The truncated SL BSR may include, for example, a number of SL LCGs permitted by the size of the UL grant. The SL LCG may be prioritized, for example, in response to a determination that the prioritization value associated with the SL LCG is below the SL prioritization threshold and each UL LCG has a prioritization value equal to or above the UL prioritization threshold. The SL LCG may be prioritized, for example, in response to a determination that the prioritization value associated with the SL LCG is below the SL prioritization threshold and the UL prioritization threshold is not configured. The UL LCG may be prioritized, for example, in response to a determination that a prioritization value associated with the UL LCG is below a UL prioritization threshold or that each SL LCG has a prioritization value equal to or above a SL prioritization threshold. The UL BSR may be prioritized, for example, in response to a determination that the SL LCG is not prioritized or a determination that the size of the UL grant is sufficient for the SL BSR if the SL BSR is not prioritized. The prioritization value associated with the SL LCG may be determined, for example, using a priority value of the highest priority among one or more LCHs that include SL data and belong to the SL LCG. The prioritization value associated with the UL LCG may be determined, for example, using a priority value of the highest priority among one or more LCHs that include UL data and belong to the UL LCG. The prioritization value associated with the SL LCG, if lower, may indicate, for example, a higher priority associated with the SL LCG, and, if higher, may indicate, for example, a lower priority associated with the SL LCG. The prioritization value associated with the UL LCG, if lower, may indicate, for example, a higher priority associated with the UL LCG, and, if higher, may indicate, for example, a lower priority associated with the UL LCG.

[0010] In an example, the WTRU may include a processor configured (e.g., programmed with executable instructions to implement a method) to: determine that a SL priority threshold is configured; determine whether the LCG is to be included in the BSR based on the size of the UL grant, the priority associated with the LCG, the SL prioritization threshold, and the UL prioritization threshold (e.g., conditional on the UL prioritization threshold being configured); and determine whether the LCG is to be included in a buffer status report to report the buffer status.

[0011] The operation of concurrent or simultaneous UL / SL interfaces may include one or more procedures such as UL / SL prioritization, SL / SL prioritization, avoiding conflicts between different UL / SL transmissions, etc. For example, the WTRU may prioritize UL transmissions or SL transmissions. The conditions for prioritizing one link over another may be based on one or more of the following: presence of pending SL processes / grants, time until the packet delay budget (PDB) for a packet expires, channel busy rate / ratio (CBR), channel occupancy ratio (CR), path loss of SL and / or downlink (DL), transmission of SL or UL hybrid automatic repeat request (HARQ) feedback, presence / absence of data on the UL / SL synchronization channel (SCH), properties of SL synchronization transmissions, transmission of scheduling requests (SRs), transmission of buffer status reports (BSRs) (e.g., SL or UL), transmission of control messages including specific types depending on the WTRU state, redundancy versions (RVs) associated with HARQ-based transmissions, blind retransmissions versus HARQ-based retransmissions, unsuccessful / discarded transmissions of previous transmissions of the same transport block (TB), range requirements based on SL data (e.g., minimum cell rate (MCR)), resource allocation patterns associated with SL transmissions, etc.

[0012] Transmission prioritization may include, for example, one or more of the following: the WTRU may drop a scheduled transmission (e.g., a transmission with a lower priority); and / or the WTRU may reduce transmission power (e.g., associated with a lower priority transmission). The WTRU may notify the network (NW) that a transmission has been dropped.

[0013] The WTRU may compare the priorities of UL / SL logical channels. The WTRU may determine which transmission to prioritize, for example, based on the configured priorities of the logical channels associated with (e.g., each) transmission. The WTRU may compare the priorities of the (pre-)configured logical channels (e.g., SL or UL, as the case may be) multiplexed into (e.g., each) transmission. The logical channel (LCH) priority may be determined, for example, by one or more of the following: the WTRU may select the transmission (e.g., UL or SL) comprising the highest LCH priority; and / or the WTRU may compare the weighted sum of the LCH priorities.

[0014] The WTRU may offset the SL priority, for example, based on sidelink measurements or quality of service (QoS). The WTRU may consider SL-related measurements and / or SL QoS attributes (e.g., in addition to LCH priority), for example, to determine whether to prioritize UL or SL transmissions.

[0015] The WTRU may prioritize the UL or SL, for example, based on the configuration of thresholds (e.g., UL and SL). In an example, the WTRU may be configured with a SL threshold and / or a UL threshold. The SL threshold may be based on, for example, a LCH priority and / or a QoS parameter related to the SL. The UL threshold may be based on, for example, a LCH priority and / or a QoS parameter related to the UL. The WTRU may, for example, compare the UL priority or the SL priority with the corresponding threshold, for example, to determine the priority of the UL or SL. The WTRU may notify the network that one or more transmissions are discarded based on a condition. For example, if a condition in the UL and SL is met (e.g., the corresponding threshold is exceeded in both the UL and the SL), the WTRU may notify the network of the discarded transmission. The WTRU may trigger an SR based on a condition. For example, if the corresponding threshold is exceeded in the UL and the SL, the WTRU may trigger one or more SRs. The WTRU may prioritize the UL / SL based on the validity of the threshold. The WTRU may prioritize the UL or SL, for example, based on a selection of which threshold (e.g., UL or SL) is valid.

[0016] Prioritization of the UL BSR or SL BSR may be based on the priority of the LCG. The WTRU may prioritize between the UL BSR and the SL BSR based on the priority of the LCG associated with the UL BSR and the priority of the LCG associated with the SL BSR. The WTRU may determine whether to prioritize the UL BSR or the SL BSR based on the priority of the data reported in the corresponding BSR.

[0017] The WTRU may determine the type (e.g., prioritized or non-prioritized) / size of the SL BSR and / or UL BSR based on the relative priority in the corresponding BSR. The WTRU may determine the type / size of the SL BSR and / or UL BSR based on, for example, one or more of: the LCG to be reported in the SL BSR; the LCH to be reported in the UL BSR; the size of the grant used to transmit the BSR; and / or the presence of additional UL grants available that may satisfy latency requirements associated with the SL data. The additional UL grants may include configured grants.

[0018] The WTRU may, for example, perform transmissions on the UL and the SL on the same time resource (e.g., time slot). For example, the WTRU may be configured with conditions to perform transmissions on both the SL and the UL without dropping / prioritizing any SL / UL transmissions. For example, if these conditions are met, the WTRU may perform transmissions on both the UL and the SL. For example, if these conditions are not met, the WTRU may perform prioritization between the UL / SL. For example, if the SL transmission includes (e.g., only includes) a physical sidelink feedback channel (PSFCH), the WTRU may transmit both the UL and the SL.

[0019] The WTRU may modify the scheduled / authorized transmission format to allow transmissions on the UL and / or SL. The WTRU may change the scheduled or authorized transmission format, for example, to allow transmissions in the same time slot on the UL and SL. The transmission format change may include, for example, one or more of the following: changing the UL / SL modulation and coding scheme (MCS), performing truncation on the UL / SL transmission, and / or changing the TB size or transmission of alternative TBs. The WTRU may modify the scheduled / authorized transmission format for UL and SL transmissions in the same time slot. The WTRU may notify the network and / or peer WTRUs of transmissions on the UL and / or SL. The WTRU may notify the network and / or peer WTRUs of the expected format change. The WTRU may notify the network or peer WTRUs of transmissions in the same time slot on the UL and SL.

[0020] The WTRU may, for example, report the expected PSFCH transmission to the network. The WTRU may report the expected PSFCH transmission timing to the network. The WTRU may perform a resource selection procedure taking into account the configured SR resources.

[0021] The WTRU may change the UL split between the primary cell group (MCG) and the secondary cell group (SCG), for example, based on the SL traffic. The WTRU may change the split of UL transmissions between the MCG and the SCG based on the presence of SL traffic.

[0022] The WTRU may change the active SL control / scheduling cell group (CG). A WTRU configured in dual connectivity (DC) may receive SL schedules (e.g., Mode 1 schedules) from a cell group (e.g., one of the two cell groups). The WTRU may decode the SL schedules on (e.g., only) the CG associated with the active SL control / scheduling at a given time. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1A is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented.

[0024] Figure 1B It is shown that according to the embodiment, Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) for use within a communication system is shown.

[0025] Figure 1C is a diagram showing that according to the embodiment Figure 1A A system diagram of an exemplary radio access network (RAN) and an exemplary core network (CN) for use within a communication system is shown.

[0026] Figure 1D is a diagram showing that according to the embodiment Figure 1AA system diagram of another exemplary RAN and another exemplary CN for use within the communication system shown.

[0027] Figure 2 An example of establishing a secure layer 2 link on PC5 is shown.

[0028] Figure 3 An example of performing uplink and sidelink operations with prioritization is shown.

[0029] Figure 4 An example of performing uplink and sidelink operations with prioritization is shown. DETAILED DESCRIPTION

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

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

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

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

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

[0035] More specifically, as noted above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 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 (DL) Packet Access (HSDPA) and / or High Speed ​​UL Packet Access (HSUPA).

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

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

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

[0039] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio 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, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), GSM Enhanced Data Rates for Evolution (EDGE), GSM EDGE (GERAN), etc.

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

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

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

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

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

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

[0046] The transmit / receive element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via an 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 a transmitter / 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 RF and light signals. It should be appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0067] Very high throughput (VHT) STA can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz and / or 80MHz channels can be formed by combining continuous 20MHz channels. A 160MHz channel can be formed by combining 8 continuous 20MHz channels, or by combining two non-continuous 80MHz channels (this can be called 80+80 configuration). For the 80+80 configuration, after channel coding, the data can pass through a segment parser that can divide the data into two streams. Each stream can be processed by inverse fast Fourier transform (IFFT) and time domain processing separately. These streams can be mapped to two 80MHz channels, and data can be transmitted by transmitting STA. At the receiver of the receiving STA, the above-mentioned operation for the 80+80 configuration can be reversed, and the combined data can be sent to the medium access control (MAC).

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

[0069] WLAN systems that can support multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah include channels that can be designated as primary channels. 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 a STA (which supports the minimum bandwidth operating mode) from all STAs operating in the BSS. In the example of 802.11ah, for STAs (e.g., MTC-type devices) that support (e.g., only support) 1MHz mode, the primary channel may be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy, for example, because a STA (supporting only the 1MHz operating mode) is transmitting to the AP, the entire available frequency band may be considered busy even if most of the frequency bands remain idle and may be available.

[0070] In the United States, the available frequency band for 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.

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

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

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

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

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

[0076] Figure 1DThe CN 115 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possible data networks (DNs) 185a, 185b. Although each of the foregoing elements is depicted as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

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

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

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

[0081] Given that Figures 1A to 1D as well as Figures 1A to 1D Corresponding to the description of the present invention, one or more or all of the functions described herein with reference to one or more of the following may be performed by one or more simulation devices (not shown): WTRU102a-d, base station 114a-b, evolved Node B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF182a-b, UPF184a-b, SMF 183a-b, DN 185a-b and / or any other device described herein. The simulation device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the simulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0082] The simulation device may be designed to implement one or more tests of other devices in a laboratory environment and / or an operator network environment. For example, the one or more simulation devices may perform one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network. The one or more simulation devices may perform one or more functions or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation device may be directly coupled to another device for testing purposes and / or may use over-the-air wireless communications to perform testing.

[0083] The one or more simulation devices may perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device may be used in a test scenario in a test lab and / or a non-deployed (e.g., testing) wired and / or wireless communication network to implement testing of one or more components. The one or more simulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuits (e.g., which may include one or more antennas) may be used by the simulation device to transmit and / or receive data.

[0084] Vehicular communication is a mode of communication in which WTRUs may communicate with each other (e.g., directly). Vehicle-to-everything (V2X) operations may include, for example, in-coverage scenarios where the WTRU may receive assistance from the network to start transmitting and / or receiving V2X messages. V2X operations may include, for example, out-of-coverage scenarios where the WTRU may start transmitting and / or receiving V2X messages using one or more pre-configured parameters.

[0085] V2X communication may be based on device-to-device (D2D) communication. V2X communication services may include one or more of the following types: vehicle-to-vehicle (V2V), where vehicle WTRUs may communicate directly with each other; vehicle-to-infrastructure (V2I), where vehicle WTRUs may communicate with roadside units (RSUs) / eNBs; vehicle-to-network (V2N), where vehicle WTRUs may communicate with a core network (CN); and / or vehicle-to-pedestrian (V2P), where vehicle WTRUs may communicate with WTRUs with special conditions (e.g., low battery capacity).

[0086] V2X resource allocation may be performed in different modes. Multiple (e.g., two) modes of operation in V2X communications may be used. The network may (e.g., in Mode 3) provide the WTRU with scheduling allocations for V2X sidelink transmissions. The WTRU may (e.g., in Mode 4) autonomously select resources from configured / preconfigured resource pools. V2X may use multiple categories of resource pools, including, for example: receive pools, which may be monitored for receiving V2X transmissions; and / or V2X transmit pools, which may be used by the WTRU to select one or more transmit resources (e.g., in Mode 4). A WTRU configured to be in Mode 3 may not use transmit pools.

[0087] The resource pool may be semi-statically signaled to the WTRU, for example, via radio resource control (RRC) signaling. The WTRU may (for example, in Mode 4) use sensing before selecting resources in the RRC configured transmission pool. V2X may support dynamic resource pool reconfiguration. The pool configuration may be carried, for example, via a system information block (SIB) and / or dedicated RRC signaling.

[0088] New Radio (NR) V2X access technology may support, for example, enhanced mobile broadband (eMBB) and / or ultra-high reliability and low latency communications (URLLC). Enhanced V2X (eV2X) communications (e.g., in NR systems) may be supported. For example, eV2X may support services for safety and non-safety scenarios (e.g., sensor sharing, autonomous driving, vehicle platooning, remote driving). Different eV2X services may have different performance levels. For example, some services may utilize 3ms latency.

[0089] V2X may support, for example, one or more of vehicle platooning, advanced driving, extended sensors, and / or remote driving.

[0090] Vehicle platooning may enable vehicles to dynamically form groups that travel together. Vehicles in a platoon may receive periodic information (e.g., data) from another vehicle (e.g., a lead vehicle) to perform platooning operations. This information may allow the distance between vehicles to be small (e.g., extremely small). For example, the gap distance between vehicles converted into time may be low (sub-second). Platooning applications may allow vehicles (e.g., a vehicle following behind another vehicle) to drive autonomously.

[0091] Advanced driving may enable semi-autonomous or fully autonomous driving. Longer inter-vehicle distances may be assumed. (E.g., each) vehicle and / or RSU may share data obtained from its local sensors with approaching vehicles, allowing vehicles to coordinate their trajectories or movements. (E.g., each) vehicle may share its driving intentions with approaching vehicles. Information sharing or other coordination may support, for example, safer driving, collision avoidance, and / or improved traffic efficiency.

[0092] Extended sensors enable the exchange of raw or processed data collected by local sensors or real-time video data from one or more vehicles, RSUs, pedestrian devices, V2X application servers, etc. Extended sensors can enhance the vehicle's perception of its environment beyond what the vehicle's sensors can detect, which can provide a more comprehensive view of the local situation.

[0093] Remote driving can enable a remote driver or V2X application to operate a remote vehicle, for example, for passengers who cannot drive themselves and / or remote vehicles located in dangerous environments. Driving can be based on cloud computing, for example, in situations where changes are limited and routes are predictable (e.g., public transportation). Cloud computing can be provided, for example, based on access to a cloud-based backend service platform.

[0094] One-to-one link establishment in D2D may be used to support a V2X side link. V2X may utilize broadcast communications (e.g., communications without establishing a link). V2X may utilize link establishment via a side link. Multiple (e.g., two) WTRUs may establish a one-to-one proximity service (ProSe) direct communication, for example, over a PC5 protocol layer (e.g., over a packet data convergence protocol (PDCP)). Signaling associated with a one-to-one link establishment may be described herein.

[0095] For example, one-to-one ProSe direct communication may be achieved by establishing a secure Layer 2 link over PC5 between multiple (e.g., two) WTRUs. A Layer 2 identifier (ID) that one (e.g., each) WTRU may use for unicast communication is included in a source Layer 2 ID field of (e.g., each) frame sent on the Layer 2 link and / or in a destination Layer 2 ID of (e.g., each) frame received on the Layer 2 link. The Layer 2 link for one-to-one ProSe direct communication may be identified, for example, by a combination of Layer 2 IDs of multiple (e.g., two) WTRUs. The WTRU may use the same Layer 2 ID for one-to-one ProSe direct communication in multiple Layer 2 links.

[0096] WTRUs participating in isolated (eg, non-relayed) one-to-one communications may negotiate an IP address allocation mechanism and / or may exchange link-local IPv6 addresses, such as during a link establishment procedure, using such addresses.

[0097] Figure 2 An example of establishing a secure layer 2 link on PC5 is shown. Figure 2As shown, a first WTRU (WTRU-1) may send a direct communication request message to a second WTRU (WTRU-2), which may trigger mutual authentication. The message may include user information (information). WTRU-2 may initiate a procedure for mutual authentication. Successful completion of the authentication procedure may complete the establishment of a secure layer 2 link on PC5. WTRU-2 may include the user information in response to WTRU-1.

[0098] The PC5 signaling protocol may support a “keep-alive” functionality that may be used to detect when the WTRU is not in ProSe communication range, for example, to perform an implicit Layer 2 link release.

[0099] The WTRU may be configured to perform link establishment for V2X (e.g., NR V2X). Procedures may be configured for and for establishing and / or maintaining a secure L2 link on PC5. Procedures may be enhanced and / or improved for V2X. V2X signaling may be defined (e.g., at the RRC layer). V2X link / group processing may be configured. In the example of V2X communications, not all WTRUs may support and / or use unicast communications. Link establishment may be supported by service announcements. For example, service announcements may be used to inform a peer of the presence of the WTRU and / or the capabilities of the WTRU for unicast communications (e.g., channels for operation, supported services, etc.).

[0100] A service announcement may be made available to one or more (e.g., all) WTRUs that may be interested in using a service. The announcement may be configured to be sent, for example, on a dedicated channel (e.g., similar to how Wireless Access in Vehicular Environment (WAVE) Service Announcements (WSA) may be handled), or piggybacked on periodic messages from supporting WTRUs.

[0101] The quality of service (QoS) of NR V2X may be determined. A QoS model may be used for NR V2X. QoS on PC5 may be supported by ProSe per-packet priority (PPPP). The application layer may be allowed to mark packets using PPPP. PPPP may indicate a QoS level. A packet delay budget (PDB) may be derived from PPPP. QoS requirements for NR V2X may be specified and / or configured. Performance indicators may be specified, for example, by one or more of the following parameters: payload (bytes); transmission rate (messages / second); maximum end-to-end delay (ms); reliability (%); data rate (Mbps); minimum required communication range (meters); etc.

[0102] A set (eg, the same set) of service requirements may be applicable to PC5-based V2X communications and Uu-based V2X communications. QoS characteristics may be represented, for example, by a quality indicator (eg, 5G Quality Indicator (5QI)).

[0103] A unified QoS model may be used for PC5 and Uu, (e.g., a model using 5QI for V2X communications over PC5) which may allow the application layer to provide consistent indications of QoS requirements regardless of the link used.

[0104] A 5GS V2X-enabled WTRU may handle multiple (e.g., three) different types of services (e.g., broadcast, multicast, and unicast).

[0105] The (e.g., same) QoS model used for Uu can be used for unicast type services. For example, (e.g., each) unicast link can be considered as a bearer and a QoS flow can be associated with the unicast link / bearer. One or more (e.g., all) QoS characteristics defined for 5QI (e.g., and additional parameters for data rate) can be applied to the QoS model / flow. The minimum communication range can be considered as an (e.g., additional) parameter (e.g., particularly for PC5 use). In the example, a similar configuration can be applied to multicast services. Multicast can be considered as a special case of unicast, e.g., with multiple defined service recipients.

[0106] Broadcast services may not have a bearer concept. (E.g., each) message may have different characteristics (e.g., depending on the broadcast application requirements). In an example, 5QI may be used similarly to PPPP / ProSe per-packet reliability (PPPR), e.g., to label each component. 5QI may (e.g., be capable of) representing one or more (e.g., all) characteristics that may be used for PC5 broadcast operations, such as one or more of latency, priority, reliability, etc. A set of V2X broadcast-specific 5QIs (i.e., VQIs) may be defined / configured for PC5 use.

[0107] In an example, PC5 QoS parameters may be negotiated when (e.g., during or at) establishing a one-to-one communication procedure. The one-to-one communication establishment procedure may be enhanced to support PC5 QoS parameter negotiation between multiple (e.g., two) WTRUs. For example, after the PC5 QoS parameter negotiation procedure, (e.g., the same) QoS may be used in both directions.

[0108] As mentioned earlier, Figure 2 An example of establishing a secure layer 2 link over PC5 is shown. WTRUs participating in a one-to-one communication may negotiate PC5 QoS parameters, for example, during a link establishment procedure. A first WTRU (WTRU-1) may send a direct communication request message to a second WTRU (WTRU-2), which may trigger mutual authentication. The message may include the requested PC5 QoS parameters. WTRU-2 may initiate a procedure for mutual authentication. WTRU-2 may include the accepted PC5 QoS parameters in a response message (e.g., to WTRU-1).

[0109] UL / SL prioritization may be supported in V2X. V2X devices may support simultaneous transmission of UL and SL, for example, in one or more of the following scenarios: UL TX and SL TX may use separate TX chains and / or separate power budgets; UL TX and SL TX may use separate TX chains while sharing a power budget; and / or UL TX and SL TX may share a TX chain and a power budget.

[0110] The simultaneous transmission of UL and SL may be subject to one or more rules (e.g., for various scenarios, such as when there are different carriers (e.g., scenarios where simultaneous TX on UL and SL may not be performed or modified), and when there is potential simultaneous TX on UL and SL on the same carrier). In the example of the same carrier (e.g., where simultaneous TX and RX cannot be used), for example, if the UL TX overlaps with the SL TX in the shared (or same) carrier frequency in the time domain, the WTRU may discard the UL TX or SL TX. For example, if the PPPP of the SL packet is higher than the (pre) configured PPPP value (e.g., the PPPP threshold), the WTRU may discard the UL TX. Otherwise, the WTRU may, for example, discard the SL TX. In the example of different carriers (e.g., where simultaneous TX and RX may occur (e.g., if the UL TX and SL TX use separate TX chains)), for example, if the UL TX overlaps with the SL TX of a different carrier frequency in the time domain, the WTRU may discard the UL TX or SL TX or reduce its power. For example, if the PPPP of the SL packet is above the (pre)configured PPPP threshold, the WTRU may drop the UL TX or reduce the UL TX power. Otherwise, the WTRU may, for example, drop the SL TX or reduce the SL TX power.

[0111] The above UL / SL prioritization rules (e.g., for LTE V2X) may be different from some implementations of V2X (e.g., NR V2X). Some V2X (e.g., NR V2X) implementations may have one or more of the following attributes: different QoS models; strict QoS for SL and / or UL; unicast transmission for SL; and / or simultaneous transmission in Mode 1 and Mode 2.

[0112] In some implementations of V2X (e.g., NR V2X), the V2X QoS model may be based on the PC5 quality indicator (PQI) (e.g., instead of PPPP, such as in LTE V2X). The QoS model may be, for example, flow-based QoS (e.g., similar to UL), instead of a per-packet based model (e.g., in LTE V2X). PC5 may be the WTRU-to-WTRU communication interface for V2X.

[0113] In some implementations of V2X (e.g., NR V2X), strict QoS may be applied for SL and / or UL. NR SL and / or NR Uu traffic may have strict QoS requirements (e.g., NR V2X may have stricter QoS requirements than LTE V2X). The impact of dropped packets may be more significant for some V2X traffic / services than for other V2X traffic / services.

[0114] In some implementations of V2X (e.g., NR V2X), unicast transmissions may be used in SL. Unicast transmissions may use HARQ and / or channel state information (CSI) feedback. Unicast SL transmissions may be discarded (e.g., as part of UL / SL prioritization). HARQ feedback may be carried in different SL physical layer (PHY) channels (e.g., physical sidelink feedback channel (PSFCH)). HARQ feedback carried in different SL PHY channels may affect how UL and / or SL transmissions are considered / prioritized, for example, when there is a conflict between UL and SL transmissions.

[0115] In some implementations of V2X (e.g., NR V2X), transmissions in Mode 1 and Mode 2 may occur simultaneously. V2X may support simultaneous transmissions in network (NW) scheduled and / or WTRU autonomous modes, which may create additional conflict scenarios for UL and SL transmissions (e.g., when UL and SL operations coexist on the same or different carriers).

[0116] The WTRU may be configured to operate with coexistence of UL and SL operations on the same or different carriers, for example, to support V2X communications.

[0117] UL / SL operations (eg, simultaneous UL / SL operations) may be based on one or more of: UL / SL prioritization, SL / SL prioritization, avoiding collisions between different UL / SL transmissions, etc.

[0118] UL / SL prioritization may be based on one or more of the following: conditions for prioritizing one link over another, deriving priority metrics for different links based on data characteristics, BSR procedures for UL and / or SL, etc.

[0119] UL / SL prioritization may be determined, for example, by the WTRU. The WTRU may (e.g., make a determination) to perform, for example, a UL transmission or a SL transmission at a given time instance (e.g., a time when UL and SL transmissions are scheduled simultaneously). The WTRU may (e.g., decide) to select a UL or SL transmission for a given time instance (e.g., a time slot). The WTRU may (e.g., decide) to select a UL or SL transmission, for example, based on one or more constraints at the WTRU. The constraints may include, for example, one or more of the following: a (e.g., single) TX chain shared between the UL and SL (e.g., where the transmissions may be on different carriers); UL and SL transmissions may be scheduled on the same carrier; and / or UL and / or SL transmissions may cause interference (e.g., if transmitted simultaneously).

[0120] The WTRU may be configured to prioritize UL transmissions or SL transmissions. Prioritization of transmissions may involve the WTRU performing, for example, one or more of the following: dropping a scheduled transmission (e.g., a transmission with a lower priority); and / or reducing the transmission power of a transmission (e.g., for a transmission with a lower priority); etc. The WTRU may perform one or more of the following (e.g., if the WTRU drops one of the scheduled transmissions): maintaining the dropped transmission in a HARQ buffer and / or deferring the transmission (e.g., to the next scheduled transmission); dropping the transmission when the transmission was supposed to be performed, increasing the redundancy version (RV) associated with the transmission block, and / or performing a transmission of the next redundancy version for the transmission (e.g., at the scheduled time).

[0121] The WTRU may prioritize transmissions (e.g., UL or SL), for example, based on one or more conditions. The conditions for prioritizing a link (e.g., UL, SL) may be based on, for example, one or more (e.g., a combination) of the following: presence of pending SL processes / grants, time until expiration of a packet's PDB, channel busy ratio (CBR), channel occupancy ratio (CR), path loss for SL and / or DL, transmission of SL or UL HARQ feedback, presence / absence of data on a UL / SL synchronization channel (SCH), properties of SL synchronization transmissions, transmission of scheduling requests (SRs), transmissions including buffer status reports (BSRs) (e.g., SL or UL), transmissions including BSRs (e.g., SL or UL), transmissions including specific types of control messages (e.g., depending on the WTRU state), redundancy versions associated with HARQ-based transmissions, blind retransmissions versus HARQ-based retransmissions, unsuccessful / discarded transmissions of previous transmissions of the same transport block (TB), range requirements for SL data (e.g., minimum cell rate (MCR)), resource allocation patterns associated with SL transmissions, etc.

[0122] The conditions for link prioritization may include the presence of a pending SL process / grant. For example, the WTRU may prioritize the UL if there is another pending grant on the SL. The pending grant on the SL may satisfy the QoS requirements of the discarded SL packets.

[0123] The conditions for link prioritization may include the time until the PDB of the packet expires. For example, if the PDB of the packet and / or the remaining time between the SL grant and the PDB of the packet is below a certain value (e.g., a threshold), the WTRU may prioritize the UL. The threshold may depend on the channel busy rate / ratio (CBR) (e.g., the CBR of the secondary link).

[0124] The conditions for link prioritization may include CBR. For example, if the CBR is above a certain value (e.g., a threshold), UL transmissions may be prioritized to alleviate congestion of secondary link resources. For example, if the CBR is below a threshold, SL transmissions may be prioritized. The threshold may be configured, for example, by higher layer signaling. The threshold may be configured, for example, by a gNB or a WTRU.

[0125] The conditions for link prioritization may include the channel occupancy ratio (CR). For example, if the CR is above a certain value (eg, a threshold), which may indicate that the WTRU is using more SL resources than expected, the UL transmission may be prioritized.

[0126] The conditions for link prioritization may include the path loss of SL and / or DL. For example, if the DL path loss value is higher than the SL path loss, the SL transmission may be prioritized and / or the link for the secondary link may be preferred over the uplink. For example, if the DL path loss value is not higher than the SL path loss, the UL transmission may be prioritized. For example, a weighting factor may be used to compare the DL path loss and the SL path loss. For example, the DL path loss may be given by α·PL DL , and / or the SL path loss can be expressed by β·PL SL Denote where α may be a weighting factor for DL ​​path loss and β may be a weighting factor for SL path loss. The weighting factors may be configurable (eg, by the network).

[0127] Conditions for link prioritization may include transmission of SL or UL HARQ feedback. The WTRU may prioritize UL / SL transmissions, for example, if the transmission is used to send HARQ feedback. For example, if the SL transmission includes a transmission on the PSFCH, the WTRU may prioritize the SL transmission over the UL transmission. For example, if the UL transmission includes HARQ feedback on the uplink control information (UCI) and / or the physical uplink shared channel (PUSCH), the WTRU may prioritize the UL transmission over the SL transmission.

[0128] The WTRU may be configured, for example, to consider transmissions of UL and / or SL HARQ feedback as lower priority than other transmissions (eg, data). For example, if the SL transmission includes (eg, only includes) a PSFCH transmission, the WTRU may prioritize the UL transmission.

[0129] Prioritization of UL or SL HARQ feedback may depend on one or more (e.g., a combination) of attributes associated with the HARQ feedback. Attributes that may affect prioritization of UL or SL HARQ feedback may include, for example, one or more of the following: QoS of data associated with the HARQ feedback; redundancy version associated with the HARQ feedback; whether to report ACK / NACK; TB size; indication of the WTRU transmitting data; casting associated with the HARQ feedback, number of HARQ bits in the HARQ feedback transmission, etc.

[0130] Prioritization of UL or SL HARQ feedback may be based on the QoS of the data associated with the HARQ feedback. The WTRU may prioritize UL / SL HARQ transmissions, for example, based on the QoS of the data associated with the HARQ transmissions. The WTRU may compare the QoS metric associated with the data for which the HARQ is transmitted with the QoS metric of the data transmitted on another link. The QoS metric of the data transmitted on the other link may be similar to the QoS metric associated with the data for which the HARQ is transmitted. In an example, the WTRU may prioritize HARQ transmissions on the SL, for example, if the priority of the transmission for which the HARQ is transmitted (e.g., signaled in the SCI) is higher than the priority of the data transmission on the UL. The WTRU may compare the QoS metric associated with the data for which the HARQ is transmitted with a specific value (e.g., a threshold). The threshold may be (pre)configured. For example, if the priority of the transmission for which the HARQ is transmitted is higher than a threshold, the WTRU may prioritize the HARQ transmissions on the SL. For example, if the priority of the transmission for which the HARQ is transmitted (e.g., signaled in the SCI) is above a threshold, the WTRU may prioritize the HARQ transmission on the SL. The threshold may depend on the measured occupancy of the channel. The QoS metric may be related to the LCH priority associated with the acknowledged data. The WTRU may prioritize the HARQ transmission, for example, based on the priority of the LCH for which the data for the HARQ feedback is transmitted. For example, if the highest priority LCH for which the data for the HARQ feedback is transmitted is higher than the LCH priority of data on another link, the WTRU may prioritize the HARQ transmission. For example, if the highest priority LCH for which the data for the HARQ feedback is transmitted is higher than a threshold, the WTRU may prioritize the HARQ transmission. The threshold may include a (pre)configured threshold.

[0131] Prioritization of UL or SL HARQ feedback may be based on the redundancy version associated with the HARQ feedback. For example, the WTRU may prioritize UL / SL HARQ transmissions according to the redundancy version being transmitted. In an example, the WTRU may, for example, prioritize HARQ feedback transmissions associated with the last HARQ retransmission or the N last HARQ retransmissions over initial transmissions and / or early retransmissions. The value of N may be configurable (e.g., pre-configured). The value of N may depend on, for example, one or more of: measured CBR, measured CQI, WTRU speed, or other (e.g., similar) measurements of the quality of the link between WTRUs. The WTRU may assign a higher priority to (e.g., each) HARQ feedback associated with a larger redundancy version. For example, the WTRU may assign a higher priority to (e.g., each) HARQ feedback associated with a larger redundancy version when compared to UL transmissions. In an example, the HARQ feedback associated with the initial transmission may be at priority P1, the HARQ feedback associated with the first retransmission may be at priority P2, and so on, where P1 < P2 <... may inform the peer WTRU that it has correctly received the transmission.

[0132] Prioritization of UL or SL HARQ feedback may be based on whether an acknowledgement (ACK) / NACK is reported. The WTRU may prioritize UL / SL HARQ transmissions, for example, if the transmission is associated with the transmission of an ACK.

[0133] Prioritization of UL or SL HARQ feedback may be based on transport block (TB) size. For example, if the resource size of the transmission associated with the HARQ feedback is higher than a certain value (e.g., a (pre)-configured threshold), then the WTRU may prioritize UL / SL HARQ transmissions. For example, if the TB size of the transmission associated with the HARQ feedback is higher than a threshold (e.g., a (pre)-configured threshold), then the WTRU may prioritize UL / SL HARQ transmissions.

[0134] Prioritization of UL or SL HARQ feedback may be based on an indication of WTRU transmitted data. The WTRU may prioritize SL HARQ transmissions, for example, based on the presence or absence of an indication made by a peer WTRU. The WTRU may prioritize SL HARQ transmissions, for example, based on the presence or absence of an indication made by another entity (e.g., gNB, group leader). For example, if the WTRU performing the data transmission includes an indication, then the WTRU may prioritize HARQ feedback for SL transmissions. In an example, the indication may relate to the intention to reuse retransmission resources (e.g., of a peer WTRU).

[0135] Prioritization of UL or SL HARQ feedback may be based on the casting associated with the HARQ feedback. The WTRU may prioritize SL HARQ transmissions associated with one casting or casting type, while the WTRU may not prioritize SL HARQ transmissions associated with other castings or other casting types. For example, the WTRU may prioritize SL HARQ transmissions for unicast, but not for multicast. The WTRU may associate different priority levels for SL HARQ transmissions for unicast and SL HARQ transmissions for multicast. The WTRU may, for example, use one or more rules and / or conditions to determine whether to prioritize unicast HARQ feedback, and use one or more different rules and / or conditions to determine whether to prioritize multicast HARQ feedback. The one or more rules and / or conditions may be, for example, one or more rules and / or conditions described herein.

[0136] Prioritization of UL or SL HARQ feedback may be based on the number of HARQ bits in the HARQ feedback transmission. For example, if the number of HARQ bits in the HARQ transmission is greater than a certain value (e.g., a threshold), the WTRU may prioritize the SL HARQ transmission. The threshold may include a (pre)configured or predetermined threshold.

[0137] The WTRU may prioritize HARQ transmissions when one or more (e.g., a combination) of conditions (e.g., as described herein) are met. In an example, the WTRU may prioritize PSFCH transmissions over UL transmissions, for example, if an acknowledgement (ACK) is being transmitted and / or the resource size associated with the SL data transmission is greater than a threshold. The threshold may depend on, for example, a measured CBR. For example, if an ACK is being transmitted and / or a peer WTRU indicates (e.g., in an SCI associated with the data transmission) that it intends to reuse reserved retransmission resources, the WTRU may prioritize PSFCH transmissions over UL transmissions. For example, if an ACK is being transmitted and / or the QoS associated with the positively acknowledged data transmission is above a threshold (e.g., a (pre)configured threshold), the WTRU may prioritize PSFCH transmissions over UL transmissions. For example, if the HARQ feedback transmission corresponds to a retransmission, the WTRU may prioritize PSFCH transmissions over UL transmissions. In an example, the WTRU may, for example, prioritize PSFCH transmissions over UL transmissions, for example, if the HARQ feedback transmission corresponds to an Nth or greater retransmission and / or the priority associated with the transmission is higher than the priority associated with the UL data transmission.

[0138] Conditions for link prioritization may include the presence / absence of data on the UL / SL SCH. The WTRU may prioritize UL / SL transmissions, for example, based on the presence of data associated with the transmission. For example, if the UL transmission includes (e.g., only includes) PHY / L1 control signaling, the WTRU may prioritize / de-prioritize SL. The L1 signaling may include the transmission of CSI on the PUSCH without the UL SCH. For example, if the UL transmission includes (e.g., only includes) SRS transmissions, the WTRU may prioritize SL transmissions.

[0139] The conditions for link prioritization may include attributes of SL synchronization transmissions. The WTRU may prioritize SL synchronization signal (SLSS) transmissions, which may be associated with a specific type or attribute. For example, if the WTRU is configured as a group leader, the WTRU may prioritize the transmission of SLSS over UL transmissions. For example, if the WTRU is in an active unicast session, the WTRU may prioritize the transmission of SLSS over UL transmissions. SLSS may be used interchangeably with the sidelink synchronization signal block (SL-SSB), the sidelink synchronization signal, and the physical broadcast channel block (SL-SSB / PBCH). The WTRU may prioritize certain (e.g., selected) types of UL transmissions (e.g., URLLC) over SLSS transmissions. For example, the WTRU may be configured with a set of UL LCHs. This set of UL LCHs may take precedence over SLSS. For example, if the WTRU has not received an SLSS signal for a period of time (e.g., longer than X period of time), the SLSS may take precedence over UL transmissions. The time period X may be predetermined, preconfigured, configured, or indicated, for example, by the gNB.

[0140] The conditions for link prioritization may include transmission of an SR. The WTRU may prioritize an SR transmission over an SL transmission. An SR transmission may be triggered by the WTRU. For example, the WTRU may prioritize an UL transmission of an SR over (e.g., always over) an SL transmission. The WTRU may prioritize an SR transmission in the UL, for example, based on one or more (e.g., a combination) of the following attributes associated with the SR transmission: whether the SR is triggered by the arrival of UL data or SL data, the LCH associated with the SR configuration, the amount of time between SR resources, etc.

[0141] Specific implementations and / or features of the present invention may be described in terms of behaviors (e.g., actions) of a WTRU. In an example, these behaviors may be performed by an entity such as a NW node or other device, which may not include WTRU functionality. In some examples (e.g., certain use cases or certain time instances), the entity or other device may have behaviors similar to a WTRU. One or more examples herein may also apply to the entity or other device.

[0142] The WTRU may prioritize SR transmissions in the UL, for example, based on whether the SR is triggered by the arrival of UL data or SL data. Prioritization based on the presence of the SR may depend on whether the SR is configured for UL data or SL data. In an example, the WTRU may prioritize UL transmissions, for example, if the UL transmission includes an SR transmission associated with an SL transmission. For example, if the UL transmission includes an SR transmission associated with the UL transmission, the WTRU may not prioritize the UL transmission. For example, if the UL transmission includes an SR transmission associated with the UL transmission, the WTRU may prioritize the UL transmission. For example, if the UL transmission includes an SR transmission associated with the UL transmission, the WTRU may not prioritize the UL transmission. For example, if the UL transmission includes an SR transmission associated with the SL transmission, the WTRU may not prioritize the UL transmission. For example, if the UL transmission includes an SR transmission associated with the SL transmission, the WTRU may prioritize the UL transmission.

[0143] The WTRU may prioritize SR transmissions in the UL, for example, based on the LCH associated with the SR configuration. The WTRU may prioritize UL transmissions when the SR is transmitted, for example, based on the LCH and / or QoS attributes configured for the triggered SR. For example, if the WTRU transmits a SR associated with a logical channel configured with a priority, the WTRU may prioritize UL transmissions. For example, if the WTRU transmits a SR associated with a logical channel configured with a priority greater than a (pre-)configured value, the WTRU may prioritize UL transmissions. For example, if the WTRU transmits a SR associated with a logical channel configured with a priority greater than a (pre-)configured value, the WTRU may prioritize UL transmissions.

[0144] The WTRU may prioritize SR transmissions in the UL, for example, based on the amount of time between SR resources. The WTRU may prioritize UL transmissions when SRs are transmitted, for example, based on the amount of time between SR resources configured at the WTRU (e.g., in combination with the QoS attributes of the data triggering the SR). In an example, the WTRU may prioritize UL transmissions including SL SRs, for example, if the next SL SR resource that may be transmitted to the network (e.g., which may be associated with the SL data that triggered the SR) may not be transmitted to the network within the next N time slots, where N may depend on the QoS attributes of the SL data that triggered the SR (e.g., latency, reliability), then the WTRU may prioritize UL transmissions including SL SRs.

[0145] Conditions for link prioritization may include transmissions including a BSR (e.g., SL or UL). For example, if the UL transmission includes a SL BSR or a UL BSR, the WTRU may prioritize the UL. For example, if the UL transmission includes a type of SL BSR (e.g., a specific type), the WTRU may prioritize the UL. The type of SL BSR may include, for example, (e.g., only) a non-filled BSR. For example, if the UL transmission includes a SL or UL BSR, the WTRU may prioritize the UL. For example, if the UL transmission includes a SL or UL BSR, the WTRU may prioritize the UL, for example, if the reported LCH priority may satisfy one or more conditions. These conditions may include, for example, one or more of the following: the highest priority LCH reported in the BSR may be higher than the SL transmission priority; and / or the highest priority LCH reported in the BSR may be higher than the (e.g., (pre) configured or selected) offset of the SL transmission priority.

[0146] Conditions for link prioritization may include transmissions with a class (e.g., a specific type) of control messages, for example, depending on the WTRU state. For example, if the transmission includes a (e.g., a specific type) of medium access control (MAC) control element (CE) or RRC message, the WTRU may prioritize the UL or SL. For example, if the SL / UL includes a SL / UL MAC CE or a SL / UL RRC message, the WTRU may prioritize the SL / UL. The MAC CE / RRC may be associated with functions such as one or more of the following: SL / UL power control, SL / UL CSI measurement, SL / UL radio link monitoring (RLM) / line link failure (RLF), SL resource allocation, SL / UL configuration, and / or SL / UL measurement reporting. In an example, the WTRU may prioritize the SL / UL for MAC CE / radio resource control (RRC) messages, for example, based on the state of the WTRU. Transmissions may be used to avoid a state and / or to exit a state. In an example, the WTRU may prioritize SL RRC messages, for example, during the SL link establishment phase; prioritize SL RRC messages, for example, if the WTRU has an active SL unicast link; prioritize UL control messages, for example, if the WTRU experiences a beam failure; prioritize SL RRC / MAC CE, for example, if the WTRU requires or uses a different configuration for SL HARQ feedback resources; prioritize UL RRC messages, for example, if the UL RRC message reports an MCG / SCG failure message; prioritize UL indications (e.g., via RRC messages) when SL RLF is detected, for example.

[0147] The conditions for link prioritization may include a redundancy version (RV) associated with a HARQ-based transmission. The WTRU may associate different priority levels with (e.g., a specific) redundancy version associated with a HARQ-based transmission, or may prioritize the UL or SL based on the redundancy version. In an example, the WTRU may prioritize retransmissions over initial transmissions. For example, if the SL includes HARQ retransmissions with RV>N, the WTRU may prioritize the SL. N may be (pre)configured. The WTRU may prioritize the L or UL, for example, based on a comparison of the SL and UL RVs. For example, if the SL RV is greater than the UL RV, the WTRU may prioritize the SL. For example, when performing a comparison of UL / SL priorities, the WTRU may, for example, add an offset to the priority based on a redundancy version or a retransmission number. For example, when performing a comparison of UL / SL priorities based on an LCH priority or any priority-based metric, the WTRU may add an offset to the priority (e.g., associated with the LCH priority or any priority-based metric) based on a redundancy version or a retransmission number. The offset may be (pre)configured for (eg, each) redundancy version and / or retransmission number. The offset may be a (eg, predefined) function of the redundancy version and / or retransmission number.

[0148] The conditions for link prioritization may include blind retransmissions versus HARQ-based retransmissions. For example, the WTRU may prioritize retransmissions on the SL differently depending on whether the retransmission is a HARQ feedback-based retransmission or a blind retransmission. For example, when a SL retransmission is generated due to receiving a feedback-based indication such as a non-acknowledgement (NACK), the WTRU may prioritize the SL retransmission over the UL (re)transmission. For example, if the retransmission is associated with a blind retransmission, the WTRU may not prioritize the SL retransmission.

[0149] Conditions for link prioritization may include an unsuccessful / discarded transmission of a previous transmission of the (e.g., same) TB. For example, if a previous (re)transmission on the SL / UL was unsuccessful (e.g., due to a discarded transmission), the WTRU may prioritize a retransmission on the SL / UL over a (re)transmission on the UL / SL. For example, if a previous transmission on the SL of the same TB was discarded because the UL was prioritized, the WTRU may prioritize a retransmission on the SL over a transmission on the UL. The WTRU may, for example, prioritize retransmissions on the SL such that at least N SL transmissions of the (e.g., same) TB can be performed (e.g., without being discarded due to prioritization of the UL).

[0150] The conditions for link prioritization may include a range requirement (e.g., MCR) for SL data. For example, the WTRU may prioritize the UL if the SL transmission is associated with a transmission and / or feedback that exceeds the MCR. For example, the WTRU may prioritize the UL transmission if the SL transmission includes one or more of the following: data transmission, SL HARQ feedback, CQI feedback, RS transmission, etc. The associated data may have an MCR. The MCR may be less than the distance between peer WTRUs.

[0151] The conditions for link prioritization may include a resource allocation pattern that may be associated with the SL transmission. For example, the WTRU may prioritize transmissions on the SL (e.g., relative to the UL) based on the resource allocation pattern associated with the SL transmission. For example, the WTRU may prioritize SL transmissions associated with forward scheduled (e.g., reserved) resources (e.g., while not prioritizing SL transmissions for which forward booking (reserved) is not performed). The WTRU may prioritize SL transmissions for which LBT is performed (e.g., while not prioritizing SL transmissions for which LBT is not performed).

[0152] Different priority levels may be used. Different priority levels may be associated with different conditions. The WTRU may determine the priority levels associated with different transmissions, for example, based on one or more (e.g., combinations thereof) of the conditions (e.g., as described herein). For example, the WTRU may determine any finite number of priority levels (e.g., P1, P2, P3 ...). The WTRU may associate a priority level with (e.g., each) transmission. The transmission may be defined by any condition (e.g., as described herein), for example, where P1>P2>P3, etc. The WTRU may associate a priority level for data (e.g., data only) transmission, for example, based on the methods described herein. For example, the WTRU may be configured with a priority level for non-data-based transmissions (e.g., as described herein), for example, based on a (pre) configuration. The WTRU may compare the priorities of data-based transmissions and non-data-based transmissions, for example, based on the priority level assigned to (e.g., each) transmission. For example, the WTRU may determine the priority level associated with a UL transmission or a SL transmission (e.g., including data transmission and non-data transmission) as the priority level associated with the highest priority transmission. For example, a prioritization value associated with the SL LCG is determined using the prioritization value of the highest priority in one or more LCHs that include SL data and belong to the SL LCG. A prioritization value associated with the UL LCG is determined using the prioritization value of the highest priority in one or more LCHs that include UL data and belong to the UL LCG. For example, the WTRU may prioritize the UL or the SL, depending on which has a higher (e.g., highest) derived priority level. The SL LCG may include a logical channel that includes SL data. The UL LCG may include a logical channel that includes UL data.

[0153] Different rules may be used, for example, depending on which condition(s) are met. For example, if and / or when a first condition or combination of conditions is met, the WTRU may use a prioritized first condition or rule. For example, if and / or when a second condition or combination of conditions is met, the WTRU may use a prioritized second rule. The rules and / or conditions used may be one or more rules and / or conditions (e.g., combinations thereof) described herein. In an example, the WTRU may prioritize UL transmissions, for example, if the UL includes a non-filled BSR. For example, if the UL includes a non-filled BSR such that the highest priority LCH reported in the BSR is higher than the priority of any LCH associated with SL data, the WTRU may prioritize UL transmissions. For example, if the condition is not met (e.g., the BSR does not include an LCH with a higher priority than an LCH associated with the SL), the WTRU may prioritize between SL and UL transmissions based on a comparison of UL / SL logical channels (e.g., as described herein). For example, if any transmission is associated with a retransmission, the WTRU may determine whether to prioritize UL transmissions or SL transmissions (e.g., by comparing the RVs associated with the transmissions). For example, if the transmission is not associated with a retransmission and / or if the SL and UL transmissions are associated with an initial transmission, the WTRU may prioritize the UL or SL based on a comparison of the UL priority and the SL LCH priority.

[0154] A tiebreaker or hierarchical priority rule may be used to determine the priority. For example, if the UL and SL have or are defined to have equal priority, the WTRU may define (e.g., create, select and / or configure) a rule for prioritizing the UL versus the SL. The WTRU may (e.g., if the UL and SL have equal priority) perform one or more of the following: transmit on the UL (e.g., always transmit); transmit on the SL (e.g., always transmit); transmit on the UL or SL, for example, depending on which direction has the largest amount of data transmitted; transmit on the UL, for example, if a previous collision resulted in a transmission on the SL (or vice versa); and / or transmit on the UL / SL, for example, if the previous timeslot was a UL / SL transmission.

[0155] The WTRU may notify the network (NW) that the UL transmission has been dropped. In an example, the WTRU may notify the network to follow the decision to prioritize the SL transmission. The WTRU may notify the network of a transmission in the same timeslot (e.g., multiplexed in the same timeslot as the SL transmission, e.g., using one or more of the methods described herein). The WTRU may notify the network at a time after the UL transmission has been dropped. The WTRU may send the indication using, for example, one or more of: a dedicated UCI transmission, an SR transmission, a BSR transmission, a dedicated MAC CE, etc.

[0156] The WTRU may send the indication using a dedicated UCI transmission. The WTRU may send the indication using (e.g., reserved) physical random access channel (PRACH) resources. Contention-based or contention-free PRACH resources may be reserved. The WTRU may send the indication via the reserved PRACH resources. In an example, contention-based or contention-free PRACH resources may be reserved, and the WTRU may send the indication via the reserved PRACH resources, for example, when an event occurs. An example of the event may include, for example, a UL transmission being dropped due to a SL transmission. (e.g., reserved) physical uplink control channel (PUCCH) resources may be used by the WTRU (e.g., in addition to and / or alternatively) to send the indication.

[0157] The WTRU may use an SR transmission to send an indication. For example, the WTRU may trigger an SR after a decision to prioritize SL transmissions. The WTRU may use a dedicated SR configuration, for example, to indicate that a UL transmission has been dropped. The WTRU may trigger an SR associated with the same parameters as a UL grant. For example, a UL grant may be dropped to signal a dropped UL transmission. The WTRU may trigger an SR on the same timeslot and / or a timeslot related to a UL grant.

[0158] The WTRU may send the indication using a BSR transmission. The WTRU may trigger a BSR transmission, for example, after a decision to prioritize SL transmission.

[0159] The WTRU may use a dedicated MAC CE to send the indication. For example, the WTRU may transmit a dedicated MAC CE. The MAC CE may indicate the timing of the UL transmission dropped by the WTRU.

[0160] The WTRU may inform the network that the WTRU prioritizes SL transmissions under certain conditions (e.g., based on certain conditions). These conditions may include, for example, one or more of the following: the WTRU is (pre)configured to provide an indication; the UL transmission may be associated with data (e.g., data including a (pre)configured LCH or LCH priority); the DL cell quality may be above / below a threshold; the gNB may have an increased PDCCH aggregation level, for example, to request retransmissions of discarded UL transmissions. For example, a first UL grant may be discarded due to SL prioritization. The first UL grant may be received using a PDCCH with aggregation level x1. The gNB may, for example, send a second UL grant for the same transport block after the first UL grant is discarded. For example, if the second UL grant is received using a PDCCH with aggregation level x2, and if x2>x1, the WTRU may send an indication. The WTRU may (e.g., alternatively) send an indication, for example, if x2-x1>threshold.

[0161] Priority metrics for different links may be derived based on data characteristics. The WTRU may compare the priorities of UL / SL logical channels. In an example, the WTRU may determine which transmission to prioritize, for example, based on the configured priorities of the logical channels associated with (e.g., each) transmission. The WTRU may compare the priorities of the (pre)configured logical channels multiplexed into (e.g., each) transmission. The (pre)configured logical channel may be a sublink or an uplink, for example, as appropriate. The WTRU may prioritize transmissions with higher (e.g., highest) LCH priorities. The LCH priority may be determined, for example, by one or more of the following: the WTRU may select a UL or SL transmission that includes a relatively high (e.g., highest) LCH priority; and / or the WTRU may compare a weighted sum of LCH priorities. The WTRU may select a UL or SL transmission with a relatively high (e.g., highest) calculated priority. The calculated priority of a transmission may be a function (e.g., a sum or a weighted sum) of the priorities of the (e.g., each) logical channel multiplexed into the transmission. For example, the WTRU may calculate a weighted average of the priorities of some (e.g., each) logical channels multiplexed into a transmission and / or may compare the weighted average of the UL transmission with the weighted average of the SL transmission. The WTRU may prioritize the transmission with the highest calculated priority. The weighting may be based on the data size. For example, the WTRU may weight the size of the data included for (e.g., each) logical channel. The weighting may be based on meeting a prioritized bit rate (PBR). For example, the WTRU may weight the priority by a prioritized bit rate (e.g., determined during a logical channel prioritization (LCP) procedure for each logical channel). In an example, a logical channel may be given a larger weight, for example, if the data included in the transmission is used to meet the PBR for performing the LCP procedure. For example, if the logical channel mainly includes data (e.g., data used mainly during step 3 of the LCP), the logical channel may be given a smaller weight. For example, in step 3 of the LCP, the WTRU may include data such as the amount available in the buffer into the grant (e.g., even if the data exceeds the prioritized bit rate). The WTRU may include as much data as is available in the buffer into the grant by starting with the highest priority logical channel and then moving to the second highest priority logical channel, etc., e.g., until the grant is filled. The WTRU may (e.g., alternatively) prioritize transmissions that include a large (e.g., maximum) amount or percentage of data to satisfy the PBR.

[0162] For example, the WTRU may perform a weighted averaging of LCHs (eg, only LCHs having a priority above a (pre-)configured threshold), eg, as described herein.

[0163] The WTRU may count the number of logical channels (e.g., having a priority above a (pre-)configured threshold). The WTRU may select the transmission with the largest (e.g., largest) number of logical channels (e.g., having a priority above a (pre-)configured threshold).

[0164] The WTRU may offset the SL priority, for example, based on sidelink measurements or QoS. In an example that may be used in conjunction with other examples (e.g., as described herein), the WTRU may consider SL-related measurements and / or SL QoS attributes (e.g., in addition to LCH priority) to determine whether to prioritize UL or SL transmissions. Offsetting SL priority and considering SL-related measurements and / or SL QoS attributes may be implemented, for example, because the implementation of QoS for the SL may be based on factors controlled and / or observed at the WTRU (e.g., resource selection compared to packet delay budget (PDB), channel busy ratio (CBR), etc.), which may or may not be known to the gNB, and a direct comparison of the NW configured SL and UL LCH priorities may or may not be sufficient.

[0165] For example, in a specific implementation that considers other factors (e.g., in addition to logical channel priorities), an offset to the calculated priority (e.g., as described herein) may be included. For example, the WTRU may calculate an offset that may be applied to the SL priority metric. The WTRU may compare the resulting UL and SL priorities (e.g., after applying the offset) to determine which transmission (e.g., UL / SL) is prioritized. The WTRU may calculate the offset, for example, based on one or more (e.g., a combination) of: measured channel occupancy; a PDB or remaining PDB associated with a sidelink transmission; and / or the presence of another SL process / grant at the WTRU that may be used to transmit the discarded SL transmission.

[0166] The WTRU may calculate an offset based on measured channel occupancy. The WTRU may be configured with different offsets to apply to SL priority, for example, based on measured channel occupancy. The measured channel occupancy may be determined by one or more of the CBR, the number of occupied resources determined by sensing, etc. The WTRU may apply different offsets for higher CBRs, for example, to prioritize SL transmissions. For example, the WTRU may apply a larger offset for higher CBRs to prioritize SL transmissions.

[0167] The WTRU may calculate an offset based on a PDB or a remaining PDB associated with a sidelink transmission. For example, the WTRU may apply an offset related to a delay requirement associated with a packet and / or SL logical channel. For example, the WTRU may apply an offset related to a remaining delay budget. The remaining delay budget may include the time between a transmission and a delay budget associated with a packet and / or logical channel.

[0168] The WTRU may calculate an offset based on the presence of another SL procedure / grant at the WTRU that may be used to transmit the discarded SL transmission. For example, the WTRU may apply an offset related to the presence of another SL grant / procedure at the WTRU. The offset may satisfy the latency requirements of the SL transmission under consideration. The WTRU may be configured with an offset such that the UL gains an advantage, for example, if the additional SL grant satisfies the latency requirements associated with the SL transmission.

[0169] The WTRU may compare the SL transmission priority with the priority signaled in the UL grant. In an example, the UL grant priority may be provided to the WTRU to be used in the UL / SL prioritization decision. For example, the priority may be provided to the WTRU in the UL grant. The WTRU may compare the derived priority level (e.g., as determined herein) of the SL transmission with the UL grant priority. The WTRU may prioritize the UL or SL, for example, based on which transmission has a higher (e.g., highest) priority.

[0170] The WTRU may prioritize the UL or SL, for example, based on the configuration of the thresholds. In an example, the WTRU may prioritize the UL or SL based on the configuration of the UL and SL thresholds.

[0171] In an example, the WTRU may be configured with a SL threshold and / or a UL threshold. The SL threshold may be, for example, based on a LCH priority and / or a QoS parameter related to the SL. The UL threshold may be, for example, based on a LCH priority and / or a QoS parameter related to the UL.

[0172] The WTRU may compare the UL priority or the SL priority with the corresponding threshold. In an example, the WTRU may compare the UL priority with the configured UL threshold. The WTRU may compare the SL priority with the configured SL threshold. The WTRU may make a determination, for example, based on which of the SL or UL transmissions is below the corresponding threshold. The WTRU may make a determination based on which of the SL or UL transmissions is above the corresponding threshold.

[0173] The WTRU may prioritize UL transmissions. For example, if the UL transmissions are above the UL threshold and the SL transmissions are below the SL threshold, the WTRU may prioritize the UL transmissions.

[0174] The WTRU may prioritize SL transmissions. For example, if the SL transmission is above the SL threshold and the UL transmission is below the UL threshold, the WTRU may prioritize the SL transmission.

[0175] The WTRU may prioritize UL transmissions or SL transmissions. In an example, the WTRU may prioritize UL transmissions, for example, if the UL transmissions and the SL transmissions are below corresponding thresholds. For example, if the UL transmissions and the SL transmissions are below corresponding thresholds, the WTRU may prioritize the SL transmissions. The decision may be (pre)configured, or may be determined, for example, based on any other rule (e.g., as may be defined herein, such as if the CBR is above a threshold, the WTRU may prioritize the UL). In an example, the WTRU may prioritize UL transmissions, for example, if the UL transmissions and the SL transmissions are above corresponding thresholds. For example, if the UL transmissions and the SL transmissions are above corresponding thresholds, the WTRU may prioritize the SL transmissions. The decision may be (pre)configured, or may be determined, for example, based on any other rule (e.g., as may be defined herein, such as if the CBR is above a threshold, the WTRU may prioritize the UL).

[0176] The WTRU may notify the network of a dropped transmission based on a condition. In an example, the WTRU may notify the network of a dropped transmission, for example, based on a condition exceeding a corresponding threshold in both UL and SL. The condition may be associated with a data priority relative to a threshold. The WTRU may notify the network that it is dropping one of the transmissions, for example, under some condition associated with a data priority relative to (e.g., each) threshold. In an example, the WTRU may select a UL transmission and notify the network that the SL transmission is dropped, for example, if the priority of the UL transmission is above a threshold and the priority of the SL transmission is above a threshold. For example, if the priority of the UL transmission is above a threshold and the priority of the SL transmission is above a threshold, the WTRU may select the SL transmission and notify the network that the UL transmission is dropped.

[0177] The WTRU may trigger an SR based on a condition. In an example, the WTRU may trigger one or more SRs, for example, based on a condition exceeding corresponding thresholds in both the UL and the SL. The condition may be associated with a data priority relative to a threshold. For example, the WTRU may request additional resources by, for example, triggering an SR under some condition associated with a data priority relative to (e.g., each) threshold. In an example, the WTRU may trigger an UL SR, for example, if the WTRU chooses to prioritize SL transmissions and the UL transmission has a priority above a threshold. For example, if the WTRU chooses to prioritize UL transmissions and the SL transmission has a priority above a threshold, the WTRU may trigger an SL SR.

[0178] The WTRU may perform resource reselection. For example, if the SL is dropped, for example due to prioritization rules, the WTRU may perform resource reselection.

[0179] The WTRU may determine which link to prioritize (e.g., UL or SL) based on multiple thresholds (SL prioritization threshold and / or UL prioritization threshold). The SL prioritization threshold may be used in the condition that the SL prioritization threshold is configured. The UL prioritization threshold may be used in the condition that the UL prioritization threshold is configured. For example, there may be a hierarchical priority rule where, for example, the WTRU evaluates a first criterion (e.g., whether the prioritization value associated with the SL LCG is lower than the SL prioritization threshold, such as Figure 3 304), then evaluating a second criterion (eg, whether at least the UL LCG has a prioritization value equal to or higher than a UL prioritization threshold, such as Figure 3 306, and whether a UL prioritization threshold is configured), and then evaluate a third criterion (e.g., the size of the UL grant and the determination of whether to prioritize the SL LCG), etc. For example, the WTRU may prioritize the UL or SL based on which criterion(s) are met. The hierarchical criteria may have an order or ranking. In the example, if the first tier criteria are met, the WTRU may not need to check the second tier criteria, the third tier criteria, etc.

[0180] In an example, the WTRU may determine which link (e.g., UL or SL) to prioritize, for example, based on whether the priority of the transmission on the first link is higher than a first threshold. For example, if the condition is not met (e.g., the transmission of the first link is not higher than the first threshold), the WTRU may determine which link to prioritize based on a comparison of the priority of the second link with the second threshold. The first threshold may be a threshold related to QoS or priority, for example, associated with the transmission of the first link. The first threshold related to QoS or priority may include, for example, one or more of PPPP, PPPR, LCH priority, 5QI, PQI, etc. The second threshold may be a threshold related to QoS or priority, for example, associated with the transmission of the second link. The second threshold related to QoS or priority may include, for example, PPPP, PPPR, LCH priority, 5QI, PQI, etc. The first threshold and the second threshold may be based on different QoS or priority-related parameters. For example, the UL may use LCH priority and the SL may use PPPP. The WTRU's determination of the first link priority and the second link priority may be based on different QoS or priority-related parameters. For example, the UL may use LCH priority and the SL may use PPPP.

[0181] The threshold may not be configured. The WTRU may be configured to determine which link to prioritize based on another configured threshold. In an example, the WTRU may be configured to determine which link to prioritize based on a second threshold, for example, (e.g., only when) the first threshold is not configured at the WTRU. The WTRU may assume, for example, based on the RAT of the link that the threshold associated with the link is not configured. For example, if the WTRU assumes that the first threshold is not configured based on the RAT of the link, the WTRU may determine the link to prioritize based on the second threshold. The WTRU's transmission may include, for example, one or more of a data transmission, a control transmission, a WTRU assistance transmission, a WTRU feedback transmission, etc. The control transmission, the WTRU assistance transmission and / or the WTRU feedback transmission may include, for example, one or more of a MAC CE, a SR, a PUCCH, a PSFCH, etc. In an example associated with the WTRU's data transmission, the WTRU may determine the priority of the transmission based on the priority of the data (e.g., the highest priority LCH multiplexed into the MAC PDU). In an example associated with WTRU assistance, the WTRU may, for example, associate the priority of the transmission with the associated data transmission as described herein.

[0182] The WTRU may determine prioritization related to data for a first RAT UL and a first RAT SL. The first RAT may include a NR. In an example, the WTRU may be configured with a UL LCH threshold and a SL LCH threshold. The WTRU may compare the UL transmission with the UL LCH threshold. For example, if the highest priority LCH multiplexed into the UL MAC PDU has a higher priority than the UL LCH threshold, the WTRU may prioritize the UL over the SL. For example, if the highest priority LCH multiplexed into the UL MAC PDU does not have a higher priority than the UL LCH threshold, the WTRU may check the transmission priority. The WTRU may compare the SL transmission with the SL LCH threshold. For example, if the highest priority SL LCH multiplexed into the SL PDU has a higher priority than the SL LCH threshold, the WTRU may prioritize the SL over the UL. For example, if the prioritization value associated with the SL LCG is lower than the SL prioritization threshold and each UL LCG has a prioritization value equal to or higher than the UL prioritization threshold, the WTRU may prioritize the SL LCG (e.g., prioritize it over the UL LCG). The prioritization value associated with the SL LCG may be represented by the prioritization value of the highest priority LCH of the SL LCG. For example, if the highest priority SL LCH multiplexed into the SL PDU does not have a higher priority than the SL LCH threshold, the WTRU may prioritize the UL over the SL. If the prioritization value associated with at least one (e.g., each) SL LCG is equal to or higher than the SL prioritization threshold, the WTRU may prioritize the UL LCG (e.g., prioritize it over the SL LCG). The WTRU may prioritize the SL LCG in response to a determination that the prioritization value associated with the SLLCG is lower than the SL prioritization threshold and the UL prioritization threshold is not configured.

[0183] A WTRU may determine a prioritization involving a UL BSR / SR for a first RAT UL and a first RAT SL. The WTRU may determine the priority of the UL BSR / SR, for example, based on the priority associated with the LCH reported in the BSR. The WTRU may determine the priority of the UL BSR / SR (relative to a configured UL threshold), for example, based on the highest priority LCH reported in the BSR, and may apply one or more rules (e.g., as provided herein). The WTRU may determine the priority of the UL BSR / SR, for example, based on the LCH that triggered the SR. The WTRU may determine the priority of the UL BSR / SR (e.g., relative to a configured UL threshold), for example, based on the highest priority LCH that triggered the SR, and may apply one or more rules (e.g., as provided herein). For example, if the highest priority UL LCH reported in the UL BSR (e.g., or for which the WTRU triggered the SR) has a higher priority than the UL LCH threshold, the WTRU may prioritize the UL transmission. For example, if the highest priority LCH multiplexed into the UL MAC PDU has a higher priority than the UL LCH threshold, the WTRU may prioritize the UL over the SL. For example, if the highest priority LCH multiplexed into the UL MAC PDU does not have a higher priority than the UL LCH threshold, the WTRU may check the transmission priority. For example, if the highest priority SL LCH multiplexed into the SL PDU has a higher priority than the SL LCH threshold, the WTRU may prioritize SL over UL; otherwise the WTRU may prioritize UL over SL.

[0184] The WTRU may determine a prioritization involving SL SR / BSR for a first RAT UL and a first RAT SL. The WTRU may determine the priority of the SL BSR / SR, for example, based on the priority of the LCH reported in the BSR. The WTRU may determine the priority of the SL BSR / SR, for example, based on the highest priority LCH reported in the BSR, and may compare the priority with the SL data priority in the SL transmission (for example, instead of comparing the priority with a threshold). The WTRU may determine the priority of the SL BSR / SR, for example, based on the LCH that triggered the SR. The WTRU may determine the priority of the SL BSR / SR, for example, based on the highest priority LCH that triggered the SR, and may compare the priority with the SL data priority in the SL transmission. The priorities may be associated with the same link (for example, prioritization with a threshold may not be used). For example, if the highest priority SLLCH reported in the SL BSR (for example, or the WTRU triggered the SL SR for it) has a higher priority than the highest priority SL LCH threshold multiplexed into the SL MAC PDU, the WTRU may prioritize the UL transmission; otherwise the WTRU may prioritize the SL transmission. One or more examples herein may be applicable to NR / LTE UL / SL prioritization and LTE / NR UL / SL prioritization.

[0185] The WTRU may determine prioritization related to data for a first RAT UL and a second RAT SL. The second RAT may include LTE. For example, the UL may be in NR and the SL may be in LTE. The WTRU may determine prioritization related to data for a first RAT UL and a second RAT SL (e.g., or second RAT UL / first RAT SL), for example, based on an LCH threshold and / or a PPPP threshold. In an example, the WTRU may be configured with a UL LCH threshold and a SL PPPP threshold. The WTRU may compare the UL transmission with the UL LCH threshold. For example, if the highest priority LCH multiplexed into the UL MAC PDU has a higher priority than the UL LCH threshold, the WTRU may prioritize the UL over the SL. For example, if the highest priority LCH multiplexed into the UL MAC PDU does not have a higher priority than the UL LCH threshold, the WTRU may check the SL transmission priority. For example, if the highest priority SL PPPP multiplexed into the SL PDU has a higher priority than the SL PPPP threshold, the WTRU may prioritize the SL over the UL; otherwise the WTRU may prioritize the UL over the SL.

[0186] The WTRU may determine prioritization related to data for a second RAT UL and a first RAT SL. For example, the UL may be in LTE and the SL may be in NR. In some examples, the WTRU may be configured with (e.g., only configured with) a SL LCH threshold. The WTRU may identify that the WTRU does not (e.g., does not need to) use the UL LCH threshold based on the RAT associated with the UL (e.g., LTE). The WTRU may check the SL transmission priority. For example, if the highest priority SL LCH multiplexed into the SL PDU has a higher priority than the SL LCH threshold, the WTRU may prioritize the SL over the UL; otherwise the WTRU may prioritize the UL over the SL.

[0187] The WTRU may determine prioritization related to UL SR / BSR for a first RAT UL and a second RAT SL. The WTRU may determine prioritization related to UL SR / BSR for a first RAT UL and a second RAT SL, for example, based on an LCH threshold and / or a PPPP threshold. In some examples, the WTRU may be configured with a UL LCH threshold and a SL PPPP threshold. The WTRU may compare the UL transmission to the UL LCH threshold. For example, if the highest priority LCH reported in the UL BSR (e.g., or the LCH that triggered the UL SR) has a higher priority than the UL LCH threshold, the WTRU may prioritize the UL over the SL. For example, if the highest priority LCH reported in the UL BSR (e.g., or the LCH that triggered the UL SR) does not have a higher priority than the UL LCH threshold, for example, as indicated by a prioritization value equal to or higher than the UL LCH threshold, the WTRU may check the SL transmission priority. For example, if the highest priority SL PPPP multiplexed into the SLPDU has a higher priority than the SL PPPP threshold, the WTRU may prioritize the SL over the UL; otherwise the WTRU may prioritize the UL over the SL.

[0188] One or more of the examples herein may be combined, for example, depending on which condition or transmission type is checked first, or which example is applicable due to the presence or absence of data and / or BSR in the UL.

[0189] The WTRU may prioritize the UL or SL, for example, based on the validity of a threshold. A WTRU may prioritize the UL or SL, for example, based on a selection of which threshold (e.g., UL or SL) is valid. The WTRU may use a comparison of the priority of the link (e.g., SL or UL) with the corresponding threshold. The determination of the link may be based on, for example, one or more of the following factors: CBR, CR, path loss of UL and / or SL, etc. The determination of the link may be based on CBR. For example, the WTRU may use a comparison of UL or SL, for example, depending on whether the CBR is above / below a threshold. For example, if the CBR is above a threshold, the WTRU may use a comparison of UL. For example, if the CBR is below a threshold, the WTRU may use a comparison of SL. The determination of the link may be based on CR. For example, the WTRU may use a comparison of UL or SL, for example, depending on whether the CR is above / below a threshold. For example, if the CR is above a threshold, the WTRU may use a comparison of UL. For example, if the CR is below a threshold, the WTRU may use a comparison of SL. The determination of the link may be based on CR. The WTRU may use a comparison of the UL or SL, for example, depending on the measured path loss of the UL or SL. For example, if the path loss of the UL is above a threshold, the WTRU may prioritize the UL. For example, if the path loss of the SL is above a threshold, the WTRU may prioritize the SL. One or more other factors (e.g., as described herein) may be used to select which threshold to utilize.

[0190] One or more examples herein may be used in association with a BSR for the UL and / or SL. The buffer status may be reported based on a determination of whether to prioritize the SL BSR. The prioritization of the UL BSR or the SL BSR may be based on a priority of an LCG. The WTRU may prioritize between a UL BSR and a SL BSR, for example, based on a priority of an LCG associated with the UL BSR and a priority of an LCG associated with the SL BSR. For example, Figure 3 As shown, in 302, a determination may be made whether to prioritize the SL LCG based on the SL prioritization threshold and the UL prioritization threshold under the condition that the UL prioritization threshold is configured. In 304, a determination may be made whether a prioritization value associated with the SL LCG is lower than the SL prioritization threshold. In 306, a determination may be made whether at least the UL LCG has a prioritization value equal to or higher than the UL prioritization threshold under the condition that the UL prioritization threshold is configured. In 308, the determination of whether to prioritize the SL LCG (or the UL LCG) may be used to determine whether to prioritize the SL BSR (or the UL BSR).

[0191] The WTRU may determine whether to prioritize the UL BSR or the SL BSR, for example, based on the priority of the data reported in the BSR. The WTRU may determine whether to include the UL BSR or the SL BSR first in the LCP procedure, for example, based on the priority of the data reported in the corresponding BSR.

[0192] The WTRU may determine whether to prioritize the UL BSR or the SL BSR, for example, based on the high (e.g., highest) priority LCG. The prioritization value associated with the LCG may be determined based on the prioritization value of the highest priority LCH of the LCG. For example, if the highest priority LCG of the UL is higher than the highest priority LCG of the SL, the WTRU may prioritize the UL BSR. For example, if the highest priority LCG of the SL is higher than the highest priority LCG of the UL, the WTRU may prioritize the SL BSR. The WTRU may be (pre)configured with which link(s) to prioritize. The behavior (e.g., logic) for which link to prioritize may be predetermined. The WTRU may be configured with the link to prioritize (e.g., UL or SL), or the behavior of which link to prioritize may be predetermined, for example, if the highest priority LCG of the SL and UL is the same LCG.

[0193] The WTRU may determine whether to prioritize the UL BSR or the SL BSR, for example, based on an equivalent mapping. The equivalent mapping may indicate a relationship between one or more aspects of the SL transmission and one or more aspects of the UL transmission. In an example, the WTRU may be configured with an equivalent mapping between the SL LCG and the UL LCG. For example, the equivalent mapping may include SL LCG 2=UL LCG 4, etc. The WTRU may be configured with an equivalent mapping between the SL LCH and the UL LCH. The equivalent mapping may be (pre) configured (for example, by RRC signaling). The WTRU may, for example, use an equivalent mapping to determine a higher priority between the SL and the UL based on a higher priority between the LCGs, thereby performing prioritization (for example, as described herein). The WTRU may, for example, use an equivalent mapping to determine a higher priority between the SL and the UL based on a higher priority between the LCHs, thereby performing prioritization (for example, as described herein).

[0194] The WTRU may determine whether to prioritize the UL BSR or the SL BSR, for example, based on a relatively low priority LCG. In an example, the WTRU may prioritize the UL BSR, for example, if the lowest priority LCG of the UL is higher than the lower priority LCG of the SL. For example, if the lowest priority LCG of the SL is higher than the lower priority LCG of the UL, the WTRU may prioritize the SL BSR. In an example, the WTRU may select a link (e.g., SL or UL) that does not have the lowest priority LCG. The WTRU may be (pre)configured to select a link (e.g., similar to one or more examples herein). For example, if the SL and UL links have the same priority for the lowest LCG, the WTRU may be configured to select a link. The WTRU may be configured with equivalent mappings between LCGs of different links.

[0195] The WTRU may determine whether to prioritize the UL BSR or the SL BSR, for example, based on a weighted sum of the priorities of some LCGs to be reported in the corresponding BSR. In an example, the WTRU may calculate a weighted sum of the priorities of (e.g., all) LCGs to be reported in the corresponding BSR. The LCGs may include LCGs with data to be reported in the corresponding BSR. For example, the WTRU may prioritize the SL or UL based on the BSR with the highest weighted priority between the UL and SL BSRs.

[0196] The WTRU may be configured with thresholds that may be used to determine whether to prioritize the SL BSR or the UL BSR. The SL BSR (if prioritized) takes precedence over the UL BSR. In an example, the WTRU may be configured with one or more thresholds associated with the SL and / or UL (e.g., Figure 4 402 and Figure 3 302). For example, the WTRU may be configured with a threshold for the SL LCG. For example, if the SL BSR includes data associated with an LCG that is higher (e.g., priority) than the LCG threshold of the SL, the WTRU may prioritize the SL LCG over the UL LCG. The WTRU may be configured with a threshold for the UL LCG. For example, if the UL BSR includes data associated with an LCG that is higher (e.g., priority) than the LCG threshold of the UL, the WTRU may prioritize the UL LCG over the SL LCG. The WTRU may be configured with a threshold for the UL LCG and a threshold for the SL LCG. For example, if the UL BSR includes data associated with an LCG that is higher (e.g., priority) than the LCG threshold of the UL, the WTRU may prioritize the UL LCG over the SL LCG. Figure 3 304), and the UL BSR does not include data with a priority higher than the UL prioritization threshold (e.g., indicated by a prioritization value equal to or higher than the UL prioritization threshold, such as Figure 3 306 of ), the SL BSR may be prioritized. For example, the WTRU may determine whether each UL LCG has a prioritization value equal to or higher than a UL prioritization threshold, and determine whether to prioritize the SLLCG (or UL LCG) based on whether each UL LCG has a prioritization value equal to or higher than the UL prioritization threshold. The determination of whether to prioritize the SL BSR is based on whether to prioritize the SL LCG. The WTRU may be configured to prioritize the BSR, or another determination rule (e.g., as described herein) may be used, for example, if the SL BSR and the ULBSR include data above their respective thresholds.

[0197] One or more examples herein may be used in combination to determine whether to prioritize a SL BSR or a UL BSR. In an example, the WTRU may be configured to prioritize based on a first rule (e.g., based on an example described herein), and if the first rule does not result in a selection, the WTRU may be configured to prioritize based on a second rule (e.g., based on another example described herein).

[0198] The WTRU may determine the type (e.g., prioritized or non-prioritized) and / or size of the SL BSR and / or UL BSR. The WTRU may determine the type and / or size of the SL BSR and / or UL BSR, for example, based on the relative priorities in the corresponding BSRs. The WTRU may determine the type and / or size of the SL BSR and / or UL BSR, for example, based on one or more of the following (e.g., Figure 3 302 or Figure 4 404): LCG to be reported in the SL BSR (e.g., Figure 3 308 of FIG. 10 ); the LCH to be reported in the UL BSR; the size of the grant for transmitting the BSR (eg, as Figure 3 and / or the presence of an available additional UL grant (eg, which may satisfy a latency requirement associated with the SL data). The additional UL grant may include a configured grant.

[0199] The WTRU may be configured to prioritize a BSR (e.g., a SL BSR), for example, using a combination of conditions and / or rules (e.g., as disclosed herein). The SL BSR may be prioritized, for example, because the SL LCG is prioritized and because if the SL BSR is not prioritized, the size of the UL grant used to transmit the BSR may not be sufficient for the prioritized SL LCG.

[0200] The WTRU may be configured to determine whether to send a shortened or truncated BSR. The WTRU may truncate or shorten the SL BSR and / or the UL BSR. The WTRU may be configured to send a relatively short BSR format. The WTRU may not send a relatively long BSR format. In an example, the WTRU may send (e.g., only send) a buffer status associated with the highest priority LCG. Figure 3 As shown in 310, the buffer status may be reported based on a determination of whether to prioritize the SL BSR. The WTRU may be configured to send a shortened or truncated BSR format. For example, the WTRU may use a shortened or truncated BSR to send (e.g., only send) the buffer status associated with a subset of LCGs. The buffer status associated with the subset of LCGs may, for example, start with the highest priority and may have a priority order from high to low. In an example, when the size of the UL grant is sufficient for a first SL LCG (e.g., prioritized) and a second SL LCG (e.g., prioritized), the prioritized and truncated SL BSR may include the first SL LCG and the second SL LCG. As Figure 4 As shown in 406 of , the buffer status may be reported based on the determination of whether to include the LCG in the buffer status report. The determination of whether to include the LCG in the buffer status report may be based on the size of the UL grant, the priority associated with the LCG, the SL prioritization threshold, and the UL prioritization threshold if the UL prioritization threshold is configured, such as Figure 4 404. If the size of the UL grant is sufficient for (e.g., all) prioritized SL LCGs, the buffer status report may include the UL LCGs, e.g., in addition to the prioritized SL LCGs. The size of the UL grant may be sufficient for the SL BSR (e.g., prioritized) and some UL LCGs associated with the UL BSR. The buffer status report may include the SL BSR (e.g., prioritized) and some UL LCGs associated with the UL BSR.

[0201] The WTRU may determine whether to send a shortened or truncated BSR, for example, based on whether the grant is large enough and / or whether there are additional UL grants. The WTRU may determine (e.g., first) whether to send a shortened or truncated BSR for the SL and / or UL, for example, based on the grant size and / or the presence / absence of additional UL grants. For example, if the grant is large enough, the WTRU may utilize a non-truncated BSR for the SL BSR and / or the UL BSR. The WTRU may utilize a non-truncated BSR for both the SL BSR and the UL BSR, for example, if the UL grant is large enough to include the non-truncated SL BSR and the non-truncated UL BSR (e.g., and other MAC CEs with higher priority than the SL BSR and / or the UL BSR). If the SL BSR is not prioritized, the size of the UL grant used to transmit the BSR may be insufficient for at least one (e.g., all) prioritized SL LCGs. For example, if the size of the UL grant is insufficient, the WTRU may (e.g., make a determination to) send a shortened or truncated BSR for the SL and / or UL. The WTRU may truncate the SL BSR (e.g., not prioritized), and the truncated BSR may include as many SL LCGs as the size of the UL grant allows (e.g., even if not prioritized). For example, the truncated SL BSR may include a first SL LCG (e.g., not prioritized) and a second SL LCG (e.g., not prioritized), for example, if the size of the UL grant is sufficient for the first SL LCG and the second SL LCG. For example, if the grant is not sufficient to include the untruncated SL BSR and the untruncated UL BSR, the WTRU may assume that it is going to send a shortened or truncated BSR for the SL and / or UL. For example, if the grant is not sufficient to send the untruncated UL BSR and the untruncated SL BSR, and any (e.g., zero or more) additional grants configured at the WTRU do not meet the timing requirements associated with the buffered data to be reported with the SL BSR, the WTRU may (e.g., assume that it is going to) send a shortened or truncated BSR for the SL and / or UL.

[0202] The WTRU may be configured to determine which BSR to shorten or truncate. The WTRU may determine which of the SL BSR and / or UL BSR to truncate / shorten and / or how to truncate / shorten the SL BSR and / or UL BSR (e.g., if a truncated version of the BSR is used). In an example, the WTRU may truncate / shorten a BSR that is triggered later in time. The WTRU may determine whether to send a shortened BSR or a truncated long BSR, for example, based on the amount of data in the grant (e.g., the size of the UL grant). For example, if the number of bits in the grant is insufficient (e.g., not enough), the WTRU may include a short BSR for the link with the BSR that is triggered later. The WTRU may include a short BSR for the link with the BSR that is triggered later, for example, if the number of bits remaining in the grant (e.g., after including the BSR for the link that is triggered earlier in time (in addition to other higher priority MAC CEs)) is sufficient to include (e.g., only include) the short BSR. Otherwise, for example, the WTRU may include as many LCGs as there is space in the truncated / shortened BSR.

[0203] The WTRU may truncate / shorten the BSR based on the priority of the LCH / LCG and / or the configured LCH / LCG threshold. In an example, the WTRU may (e.g., decide to) truncate the UL and / or SL BSR, for example, to send the buffer status associated with the highest priority logical channel. The WTRU may (e.g., decide to) truncate the UL and / or SL BSR, for example, to send the buffer status associated with the LCH / LCG above the LCH / LCG threshold. In an example, the WTRU may (e.g., decide to) truncate the SL BSR or the UL BSR and send (e.g., only send) the buffer status of the LCH / LCG in the SL / UL BSR that is above the configured LCH / LCG threshold. The WTRU may (e.g., decide to) perform truncation, for example, using a prioritized link. For example, if a BSR is prioritized relative to other BSRs, the WTRU may (e.g., decide to) perform truncation (e.g., based on the configured LCG / LCH threshold). For example, the WTRU may (e.g., decide to) perform truncation (e.g., based on a configured LCG / LCH threshold) if (e.g., only if) the SL BSR is prioritized over the UL BSR. For example, the WTRU may (e.g., decide to) perform truncation (e.g., based on a configured LCG / LCH threshold) if (e.g., only if) the UL BSR is prioritized over the SL BSR. The WTRU may (e.g., decide to) perform truncation for a link (e.g., only one link). For example, if the SL is prioritized (e.g., but not when the UL is prioritized), the WTRU may perform truncation (e.g., based on a configured LCG / LCH threshold). The WTRU may, for example (e.g., only) based on the remaining size of the UL grant for a non-prioritized BSR (e.g., UL or SL).

[0204] The WTRU may send a shortened or truncated SL BSR, for example, to include as many SL LCGs in the SL BSR. The WTRU may, for example, send a shortened or truncated UL BSR, for example, to include as many UL LCGs in the UL BSR. The WTRU may send a shortened or truncated SL BSR and a shortened or truncated UL BSR, for example, to include as many SL or UL LCGs in the SL and UL BSR as allowed based on the grant size. The WTRU may be configured to include the highest priority LCG in the SL and UL BSR, for example, to include LCGs in order of priority from high to low (e.g., considered across both UL and SL).

[0205] For example, if the corresponding BSR includes the highest priority LCG, the WTRU may truncate / shorten the BSR for the UL or SL. For example, if the corresponding BSR includes the highest priority LCG (e.g., across both SL and UL) and the remaining LCGs have a lower priority than any LCG to be sent in the SL BSR, the WTRU may truncate / shorten the BSR for the UL. For example, if the corresponding BSR includes the highest priority LCG (e.g., across both SL and UL) and the remaining LCGs have a lower priority than any LCG to be sent in the UL BSR, the WTRU may shorten the BSR for the SL.

[0206] The WTRU may send a short BSR for the SL and may truncate the SL BSR, for example, based on various conditions. The WTRU may (e.g., always) send a short BSR for the SL and may truncate the SL BSR, for example, as determined by the buffer status (e.g., in order of priority from high to low) including the LCG.

[0207] The WTRU may send a short BSR for both the SL and the UL. In an example, the WTRU may (eg, always) send a short BSR for both the SL and the UL.

[0208] The WTRU may send an untruncated BSR in one link and a truncated / short BSR in another link. In an example, the WTRU may send an untruncated BSR in the SL and a truncated / short BSR in the UL. The WTRU may select the link (e.g., SL or UL) on which to send the untruncated BSR, for example, based on the priority of the LCGs to be reported in the SL and the UL. For example, the link (UL or SL) with the lowest priority LCG to be reported may be truncated / shortened.

[0209] The WTRU may be configured to perform prioritization (e.g., SL / SL prioritization) between multiple (e.g., potential) SL transmissions. The WTRU may be configured to (e.g., attempt to) avoid collisions between different UL / SL transmissions (e.g., using various methods). For example, the WTRU may be configured to (e.g., attempt to) avoid collisions between different UL / SL transmissions, for example, using a method of multiplexing UL and SL transmissions.

[0210] The WTRU may perform transmissions in the same resource (e.g., time slot) on the UL and SL. In an example, the WTRU may be configured with conditions for performing transmissions on the SL and the UL (e.g., not dropping and / or not prioritizing SL / UL transmissions). For example, if the conditions are met, the WTRU may perform transmissions on the UL and the SL. For example, if the conditions are not met, the WTRU may perform prioritization between the UL / SL (e.g., as described herein). For example, if the SL transmission includes (e.g., only includes) a PSFCH transmission, the WTRU may transmit the UL and the SL. For example, if the UL transmission includes (e.g., only includes) an SR transmission, the WTRU may transmit the UL and the SL. For example, if the UL transmission includes (e.g., only includes) an SRS transmission, the WTRU may transmit the UL and the SL.

[0211] Various conditions for transmissions on the UL and SL may be used. For example, the WTRU may be configured with conditions that allow the WTRU to transmit on the UL and SL in the same time slot / TTI. The conditions for transmitting signals on the UL and SL on the same resource (e.g., time slot) may include, for example, one or more of the following: at least one symbol may overlap for UL and SL transmissions in the resource; some (e.g., all) symbols of the UL transmission may overlap with the SL transmission; and / or symbols of the UL transmission may not overlap with the SL transmission.

[0212] The conditions may include or involve, for example, one or more (e.g., a combination) of the following: NW indication, type of UL / SL transmission, duration (time) of transmission on UL or SL, QoS / priority associated with the transmission, carrier distance between UL and SL transmissions, frequency gap between UL and SL transmissions, transmission power, power control scheme, etc.

[0213] These conditions may be related to a network indication. The WTRU may receive an indication (e.g., from the network) indicating whether the WTRU may perform transmissions on the UL and SL in the same time slot. The indication may be provided, for example, via RRC configuration or in an UL grant. The indication may be explicit (e.g., a bit in an UL grant from the network). The indication may be implicit. For example, for certain values ​​of modulation and coding scheme (MCS) (e.g., configured by the network in an UL grant), the WTRU may (e.g., be allowed to) perform transmissions on the UL and SL in the same time slot.

[0214] These conditions may be related to the type of UL / SL transmission. For certain (e.g., selected) types or combinations of UL and / or SL transmissions, UL / SL transmissions in the same time slot may be allowed. For other (e.g., unselected) types of UL / SL transmissions, UL / SL transmissions in the same time slot may not be allowed. The transmission type may be related to one or more of the physical, transport, or logical channels associated with the UL / SL transmission. For example, if the SL transmission is associated with a PSFCH (and only with the PSFCH) transmission, the WTRU may be allowed to transmit in the same time slot in the UL and SL. For example, if the SL transmission is associated with the PSFCH and / or the UL transmission is a PUSCH, the WTRU may be allowed to transmit in the same time slot in the UL and SL. For example, if the SL transmission is associated with the PSFCH only and / or the UL transmission is a PUSCH only (e.g., no PUCCH transmission), the WTRU may be allowed to transmit in the same time slot in the UL and SL. For example, the WTRU may be allowed to transmit in the same timeslot in the UL and the SL (e.g., only if) the UL transmission is associated with a certain set of logical channels (e.g., selected, designated, or configured). The WTRU may be allowed to transmit in the same timeslot in the UL and the SL (e.g., only if) the UL transmission is not associated with a certain set of logical channels (e.g., configured by the network).

[0215] These conditions may be related to the duration (time) of the transmission on the UL or SL. For example, if the UL / SL transmission duration is limited in time, UL / SL transmissions in the same time slot may be allowed (e.g., and may occur). For example, if the combination of UL / SL transmission durations is limited in time, UL / SL transmissions in the same time slot may be allowed (e.g., and may occur). For example, if the SL transmission (e.g., PSFCH) is limited to (e.g., at most) N symbols, the WTRU may transmit on the UL and SL. N may depend on the properties of the UL data (e.g., as described herein). For example, if the SL transmission (e.g., PSFCH) is limited to (e.g., at most) N symbols and / or the UL transmission is limited to (e.g., at most) M symbols, the WTRU may transmit on the UL and SL. M may depend on the properties of the SL data.

[0216] These conditions may be related to the QoS / priority associated with the transmission. The WTRU may, for example, perform transmissions in the same timeslot on the UL and SL based on the QoS and / or priority associated with the UL and / or SL transmissions. For example, if a PSFCH transmission on the SL is associated with a data transmission of a certain QoS and / or priority, the WTRU may perform transmissions in the same timeslot on the UL and SL. For example, if the UL transmission is associated with eMBB, the WTRU may perform transmissions in the same timeslot in the UL and SL. For example, if the UL transmission includes a logical channel (LCH) with a priority below / above a certain threshold, the WTRU may perform transmissions in the same timeslot in the UL and SL.

[0217] These conditions may be related to the carrier distance between the UL and SL transmissions. The WTRU may perform transmissions in the same timeslot on the UL and SL, for example, based on whether the UL and SL transmissions are on the same or different carriers and / or based on the distance between the carriers in the UL and SL. These conditions may be combined with other conditions (e.g., as described herein). For example, if the PSFCH is less than N timeslots, and if the PSFCH is less than M timeslots, the WTRU may perform transmissions in the same timeslot on the UL and SL. For example, if the PSFCH is less than N timeslots for the same carrier between the UL and SL, and if the PSFCH is less than M timeslots for different carriers between the UL and SL, the WTRU may perform transmissions in the same timeslot on the UL and SL.

[0218] These conditions may be related to the frequency gap between the UL and SL transmissions. The WTRU may perform transmissions in the same time slot on the UL and SL, for example, depending on whether the frequency resources of the UL and SL transmissions have a gap (e.g., greater than X RBs). For example, the gap may be a frequency gap based on resource blocks. The X RBs may be predetermined, configured, or indicated (e.g., in downlink control information (DCI)).

[0219] These conditions may be related to transmit power. The WTRU may perform transmissions in the same timeslot on the UL and SL, for example, depending on whether the WTRU reaches a certain transmit power (e.g., a maximum transmit power). The maximum transmit power may include one or more of Pc,max, Pc,max,pssch, etc. For example, if a transmission (e.g., UL and SL) will reach (e.g., or exceed) the maximum transmit power, the WTRU may not perform UL and SL transmissions in the same timeslot. For example, if the UL and SL transmissions may not reach the maximum transmit power, the WTRU may perform transmissions in the same timeslot on the UL and SL. For example, a condition may be applied such that the total transmission of the SL and UL may not reach the maximum transmit power of the WTRU.

[0220] These conditions may be related to the power control scheme. The WTRU may perform transmissions in the same time slot on the UL and SL, for example, depending on the power control scheme (e.g., for sidelink transmissions). The WTRU may be configured to use one or more power control schemes for the sidelink. In an example, a first power control scheme may use Pc,max, where the WTRU may transmit signals on the SL using Pc,max power. A second power control scheme may be based on path loss, where the transmission power may be determined, for example, based on (e.g., according to) path loss (e.g., DL path loss and / or SL path loss). For example, if the power control scheme for the SL is based on the first power control scheme, the WTRU may not perform UL and SL transmissions in the same time slot. For example, if the power control scheme for the SL is based on the second power control scheme, the WTRU may perform UL and SL transmissions in the same time slot. In an example, the WTRU may not perform UL and SL transmissions in the same time slot, for example, if the WTRU uses the first power control scheme (e.g., Pc,max).

[0221] The WTRU may modify a planned / authorized transmission format to allow transmission on the UL and / or SL. The WTRU may change a planned or authorized transmission format, for example, to allow transmission in the same time slot on the UL and SL. The planned transmission format may be selected by the WTRU for the SL, for example. The authorized transmission format may be authorized by the network for the UL, for example. The change in the transmission format may include, for example, one or more of the following: a change in the UL / SL MCS, performing truncation on the UL / SL transmission, a change in the TB size and / or the transmission of an alternative TB. For example, the WTRU may have a UL grant from the network. The WTRU may receive a SL transmission associated with a SL unicast. For example, the SL unicast may use a PSFCH transmission in the same time slot as the UL transmission. The WTRU may perform truncation of the UL transmission, for example, when it is determined that the WTRU can transmit on both the UL and the SL (e.g., PSFCH) at the same time. The WTRU may be configured with an amount of truncation to be performed. The amount of truncation to be performed may be based on, for example, the number of symbols required / selected for the PSFCH. The WTRU may select the MCS for the initial transmission on the SL. For example, if the SL retransmission collides with a UL transmission on the same timeslot, the WTRU may change / modify the MCS for the retransmission on the SL. For example, if the SL retransmission collides with a UL transmission on the same timeslot and the WTRU decides to transmit the SL and UL in the same timeslot, the WTRU may change / modify the MCS for the retransmission on the SL.

[0222] The WTRU may notify the network and / or peer WTRUs of transmissions on the UL and / or SL. The WTRU may notify the NW and / or peer WTRUs of changes in the expected format. The WTRU may notify the network or peer WTRUs of transmissions in the same time slot on the UL and SL. The indication may include (e.g., may indicate) one or more of the following: the SL and UL may be transmitted in the same time slot; and / or different SL / UL formats selected by the WTRU (e.g., to ensure transmission of the UL and SL in the same time slot). The indication may include one or more of truncation levels, different MCSs, different TB sizes, etc. The WTRU may provide the indication, for example, using (e.g., explicit) signaling. In an example, the WTRU may include an indication to the network in the uplink control information (UCI). The WTRU may include an indication to the peer WTRU in the sidelink control information (SCI). The WTRU may provide the indication implicitly. The WTRU may scramble the demodulation reference signal (DMRS) differently, for example, depending on whether the WTRU transmits in the same timeslot in the UL and SL and / or depending on different (e.g., selected) transmission formats of the UL / SL. The WTRU may use different orthogonal cover codes (OCCs) for the DMRS, for example, depending on whether the WTRU transmits in the same timeslot in the UL and SL and / or depending on different (e.g., selected) transmission formats of the UL / SL.

[0223] The WTRU may, for example, report to the network the expected PSFCH transmission. The WTRU may report to the network the expected PSFCH transmission timing. For example, if an UL grant conflicts with a PSFCH transmission, the network may use the report to correctly configure the UL grant parameters. The network may use the report to schedule the UL grant while avoiding PSFCH transmissions. For example, if an UL grant conflicts with a PSFCH transmission and / or in order for the network to schedule the UL grant while avoiding PSFCH transmissions, the network may use the report to correctly configure the UL grant parameters. In an example, the WTRU may provide PSFCH resource timing associated with a scheduled (e.g., periodic) transmission by another (e.g., peer) WTRU, for example, after the periodic resources are reserved by the peer WTRU. The WTRU may provide a set of periodic PSFCH resources to the network (e.g., these resources may correspond to HARQ feedback resources for scheduled transmissions of the peer WTRU). The WTRU may provide a set of periodic PSFCH resources to the network, for example, after a transmission by another WTRU associated with a periodic transmission with HARQ feedback enabled. The WTRU may notify the network of a change in PSFCH resources, for example, when the periodicity / offset / resources (e.g., subchannels) associated with a periodic transmission changes. The WTRU may report a different set of PSFCH resources and / or indicate a change in a set (e.g., a current set) of PSFCH resources, for example, if one or more of the following applies: the WTRU detects a change in one or more of the periodicity, offset, or resources of another WTRU's periodic transmission (e.g., associated with a particular sidelink process); the WTRU receives an indication from another WTRU that the other WTRU may change the periodicity / offset / resources associated with the periodic transmission; and / or the WTRU may receive a change in the HARQ configuration (e.g., from another WTRU or gNB).

[0224] In an example, when the WTRU may provide an indication of the timing of the PSFCH transmission, for example, after receiving the SL transmission without reservation. The WTRU may provide the indication (e.g., together with the ACK / NACK indication) to the network (e.g., for Mode 1). For example, the WTRU may implicitly / explicitly indicate the PSFCH timing to the network using the ACK / NACK indication. The WTRU may implicitly / explicitly indicate the PSFCH timing to the network, for example, using one or more of the following: signaling timing (e.g., in an ACK / NACK indication), or relative timing of the ACK / NACK indication from the PSFCH transmission, or one or more of the received data timing; signaling data priority and / or QoS (e.g., in an ACK / NACK indication) (e.g., or any additional information used by the network to determine the PSSCH to PSFCH timing distance), for example, if the WTRU signals the received data timing; selecting resources for the ACK / NACK indication provided to the network (e.g., (pre)configured or predetermined resources, e.g., based on the PSFCH timing and / or the received data timing to be signaled). The WTRU may, for example, provide an indication in dedicated UCI information that may be used to indicate such information (e.g., for Mode 2). The dedicated UCI information may be configured, for example, to implicitly / explicitly indicate the PSFCH and / or received data timing (e.g., as described herein).

[0225] The WTRU may report the expected PSFCH transmission timing to the network, for example, in one or more of an RRC message, a MAC CE, and / or UCI (e.g., a combination thereof). In an example, the WTRU may be configured with resources in the UCI for signaling a relative offset (e.g., from a transmission of the UCI) for the planned PSFCH transmission timing and / or the received data timing. The WTRU may trigger the transmission of an SL BSR (or similar MAC CE), for example, upon receiving a transmission by another WTRU. The WTRU may report the timing of the corresponding PSFCH, for example, in an SL BSR or MAC CE. For example, if another WTRU initiates a periodic or reserved transmission, the WTRU may send a SidelinkUEAssistance RRC message (e.g., or a similar RRC message) to the network. The WTRU may report (e.g., of the WTRU) the PSFCH timing associated with a periodic transmission of another WTRU.

[0226] For example, the WTRU may be configured to (e.g., attempt to) avoid conflicts between different UL / SL transmissions, for example, using one or more methods involving resource selection decisions. The WTRU may perform a resource selection procedure (e.g., taking into account configured SR resources). For example, the WTRU may take into account the time / frequency location of the configured SR resources (e.g., SL or UL SR resources) in the resource selection procedure, which may avoid or reduce the possibility of conflicts between SR transmissions on UL transmissions. For example, for mode 2 resource selection, the WTRU may exclude (e.g., the WTRU's) configured SR resources (e.g., or a subset of the WTRU's configured SR resources) from the set of available resources. The WTRU may assist in the selection of resources that do not conflict with the configured SR resources (e.g., or a subset of its configured SR resources) (e.g., in mode 2 resource selection). For example, the WTRU may assign a higher weight to the selection of resources that do not conflict with SR resources.

[0227] The WTRU may (e.g., while excluding SR resources and / or helping non-SR resources) perform operations (e.g., only) on SR resources that may be associated with, for example, SL or UL, SR resources associated with a (e.g., specific) QoS, etc. The WTRU may (e.g., only) perform operations on SR resources that are associated with SL or UL. For example, the WTRU may exclude only SR resources for SL or UL. The WTRU may perform operations (e.g., only) on SR resources that may be associated with a certain (e.g., specific, selected, configured, indicated) QoS. The WTRU may exclude SL SR resources that may be associated with a logical channel, for example, where the QoS is higher than the QoS of data that the WTRU may transmit on the selected sidelink resources. The WTRU may exclude SL SR resources that may be associated with a logical channel, for example, where the QoS is higher than one or more (pre-)configured values.

[0228] For example, the WTRU may be configured to (e.g., attempt to) avoid conflicts, for example, using one or more methods involving the use of multi-RAT dual connectivity (MR-DC). The WTRU may, for example, change the UL split between the primary cell group (MCG) and the secondary cell group (SCG) based on the SL traffic. In an example, the WTRU may, for example, change the WTRU's split of UL transmissions between the MCG and the SCG based on the presence of SL traffic. The WTRU may be configured with one or more split DRBs between the MCG and the SCG. The WTRU may change the relative amount of traffic sent via the MCG or SCG used for (e.g., splitting) the DRB based on the presence of SL traffic. The WTRU may, for example, (e.g., decide to) change the amount of traffic between the MCG and the SCG based on one or more of the following: QoS associated with the SL traffic, QoS associated with the UL traffic, congestion on the SL, WTRU capability limitations, etc.

[0229] The WTRU may (e.g., decide to) change the amount of traffic between the MCG and the SCG, for example, based on the QoS associated with the SL traffic. The WTRU may change the UL split between the MCG and the SCG for the SL traffic. For example, the WTRU may (e.g., only) change the UL split between the MCG and the SCG for the SL traffic associated with a specific QoS and / or a specific LCH. For example, the WTRU may change the UL split between the MCG and the SCG if (e.g., only if) the WTRU has data associated with the QoS and / or the LCH.

[0230] The WTRU may, for example, decide to change (e.g., decide to) change the amount of traffic between the MCG and the SCG based on the QoS associated with the UL traffic. For example, the WTRU may change the UL split between the MCG and the SCG (e.g., only) for split DRBs configured with a specific QoS. The WTRU may change the UL split between the MCG and the SCG (e.g., only) for certain DBRs or LCHs. The WTRU may be configured (e.g., per DRB / LCH) to, for example, indicate whether to change the UL split of traffic from the presence of SL traffic.

[0231] The WTRU may (eg, decide to) change the amount of traffic between the MCG and the SCG based on the congestion on the SL. For example, the WTRU may (eg, be allowed to) change the UL split between the MCG and the SCG.

[0232] The WTRU may (e.g., decide) to change the amount of traffic between the MCG and SCG based on WTRU capability limitations. In the example of capability limitations, the WTRU may not be able to transmit on both the UL MCG / UL SCG and SL simultaneously on a carrier configured for the UL MCG / SCG and SL.

[0233] The WTRU may change the UL split between the MCG and the SCG, for example, when one or more of the following trigger conditions occur: the WTRU may receive SL data associated with one or more LCHs; the amount of SL data (for example, associated with one or more LCHs) may be higher than a threshold; and so on.

[0234] The WTRU may (e.g., upon the occurrence of one or more trigger conditions, such as described herein) perform one or more of the following to change the UL split between the MCG and the SCG. The WTRU may (e.g., based on a trigger event) change the primary path of the UL split bearer from one CG to another CG (e.g., for a period of time, or until a different threshold occurs). In an example, the WTRU may change the primary path to a CG that does not conflict with the TX chain performing the SL data transmission. The WTRU may (e.g., based on a trigger condition) perform a transmission for a specific bearer (e.g., only on one CG), for a period of time, or until a different trigger condition occurs. The WTRU may change the usage percentage of the primary path (e.g., ulDataSplitThreshold), for example, relative to a network configured amount. The WTRU may change the usage percentage by a certain amount, for example, relative to the amount of SL data in its buffer. The WTRU may change the usage percentage by a certain amount, for example, relative to the QoS and / or LCH of the data in the SL buffer. The WTRU may change the usage percentage by a certain amount relative to the QoS and / or LCH associated with the UL bearer itself.

[0235] The WTRU may change the active SL control / scheduling CG. A WTRU configured in DC may receive a SL schedule (e.g., mode 1 schedule) from one of a plurality of (e.g., two) cell groups. The WTRU may decode the SL schedule at a given time (e.g., only) on the CG associated with the active SL control / scheduling. In an example, the WTRU may change the active SL control / scheduling cell group (CG) from the MCG or SCG, and vice versa. The WTRU may receive (e.g., explicit) signaling from the network to change the CG associated with the monitored SL schedule. The WTRU may receive signaling in one or more of the following: an RRC configuration message, a MAC CE, a DCI message, and the like. The DCI message may be a dedicated DCI message for changing the active scheduling CG. The DCI message may be a SL DCI for scheduling SL (e.g., similar to DCI 5A). The SL DCI may include a field (e.g., a dedicated field) for indicating a change in the DCI. For example, in the case of multiple connections, the signaling (or signaling message) may indicate which CG to change to for the active SL scheduling CG.

[0236] In an example, the WTRU may determine (e.g., implicitly) an active scheduling CG based on one or more of the following: Uu bearer configuration; QoS and / or LCG configuration associated with the bearer configuration. The WTRU may determine that the CG associated with active SL monitoring is, for example, a CG in which URLLC bearers (e.g., MCG bearers or SCG bearers) are not configured. The WTRU may determine that the CG associated with active SL monitoring is, for example, a CG whose bearers are associated with one or more of the following: relatively low (e.g., lowest) QoS, relatively small / large (e.g., minimum / maximum) allowed transmission duration, relatively small / large (e.g., minimum / maximum) configured authorization periodicity, etc. The WTRU may change the active SL scheduling CG, for example, based on a trigger condition related to UL discontinuous reception (DRX). For example, if the WTRU enters DRX on a first CG, the WTRU may move the active scheduling CG to another CG.

[0237] Figure 3 An example of performing uplink and secondary link operations using prioritization is shown. Examples and other examples disclosed herein may be based on Figure 3 300. The execution of uplink and sidelink (e.g., concurrent) operations may include one or more of 302 to 310 (e.g., as described herein). In 302, a determination may be made whether to prioritize a SL LCG based on a SL prioritization threshold and the UL prioritization threshold if a UL prioritization threshold is configured. In 304, a determination may be made whether a prioritization value associated with the SL LCG is lower than the SL prioritization threshold. In 306, a determination may be made whether at least the UL LCG has a prioritization value equal to or higher than the UL prioritization threshold if a UL prioritization threshold is configured. In 308, a determination may be made whether to prioritize a SL BSR based on a size of the UL grant and a determination whether to prioritize the SL LCG. In 310, a buffer status may be reported based on the determination whether to prioritize the SL BSR.

[0238] Figure 4 An example of performing uplink and secondary link operations using prioritization is shown. Examples and other examples disclosed herein may be based on Figure 4 400. The execution of uplink and sidelink (e.g., concurrent) operations may include 402 to 406. In 402, a determination may be made that a sidelink (SL) priority threshold is configured. In 404, a determination may be made whether the LCG is to be included in the BSR based on the size of the UL grant, the priority associated with the LCG, the SL prioritization threshold, and the UL prioritization threshold if the UL prioritization threshold is configured. In 406, a buffer status may be reported based on the determination whether the LCG is to be included in the buffer status report.

[0239] Although features and elements are described above in specific combinations, it will be understood by those of ordinary skill in the art that each feature or element may be used alone or in any combination with other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of 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 built-in hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and digital versatile disks (DVDs)). A processor associated with software may be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A wireless transmit / receive unit (WTRU), the WTRU comprising: A processor configured to: Determining that a secondary link (SL) buffer status report (BSR) has been triggered; Determining that an uplink (UL) BSR has been triggered; determining that a SL logical channel group (LCG) is prioritized, the determination being based on a SL prioritization threshold, a UL prioritization threshold, a first value of a highest priority of one or more SL LCHs belonging to the SL LCG, and a second value of a highest priority of one or more UL LCHs belonging to the UL LCG, wherein the first value is less than the SL prioritization threshold, and wherein the second value is equal to or greater than the UL prioritization threshold; Receive UL authorization; determining, based on the size of the UL grant and the determination that at least the SL BSR has been triggered, that the SL BSR is to take precedence over the UL BSR for logical channel prioritization (LCP) associated with a transmission, wherein the SL BSR indicates a buffer status of a prioritized SL LCG; and Based on the UL grant, the transmission is sent, wherein the transmission includes the SL BSR.

2. The WTRU of claim 1 , wherein: Prioritizing the SL BSR over the UL BSR includes assigning a first priority level to the SL BSR for the LCP associated with the transmission and assigning a second priority level to the UL BSR, and wherein the first priority level is higher than the second priority level.

3. The WTRU of claim 1 , wherein: Each of the one or more UL LCHs contains SL data, and each of the one or more UL LCHs contains UL data.

4. The WTRU of claim 1 , wherein: The one or more SL LCHs belong to a SL LCG which is the prioritized SLLCG, the one or more UL LCHs belong to a UL LCG having data available for the transmission, and the determination that the SL LCG is prioritized is based on each priority value associated with the one UL LCG being equal to or greater than the UL prioritization threshold.

5. The WTRU of claim 1 , wherein: The determination that the SL LCG is prioritized is further based on the determination that the UL BSR has been triggered, and wherein the UL BSR indicates a buffer status of the UL LCG.

6. The WTRU of claim 1 , wherein: The processor is further configured to determine that each SL LCG having SL data available for the transmission is prioritized, and the SL BSR indicates a respective buffer status of each prioritized SL LCG.

7. The WTRU of claim 1 , wherein: The UL grant is insufficient to include in the transmission the UL BSR and a respective buffer status of each SL LCG having SL data available for the transmission.

8. The WTRU of claim 1 , wherein: The processor is further configured to: determining that the UL prioritization threshold and the SL prioritization threshold are configured; determining, based on a number of bits associated with the UL grant, that the UL grant is insufficient to include in the transmission the UL BSR and a corresponding buffer status of each SL LCG having data available for the transmission; in an LCP procedure for the transmission, assigning a first priority level to the SL BSR indicating the buffer status of the prioritized SL LCG; In the LCP procedure for the transmission, assigning a second priority level to the UL BSR, wherein the first priority level is higher than the second priority level; and The UL BSR is included in the transmission, wherein the SL BSR further indicates a buffer status of non-prioritized SL LCGs allowed by the number of bits associated with the UL grant.

9. A method performed by a wireless transmit / receive unit (WTRU), the method comprising: Determining that a secondary link (SL) buffer status report (BSR) has been triggered; Determining that an uplink (UL) BSR has been triggered; determining that a SL logical channel group (LCG) is prioritized, the determination based on a SL prioritization threshold, a UL prioritization threshold, a first value of a highest priority of one or more SL LCHs belonging to the SLLCG, and a second value of a highest priority of one or more UL LCHs belonging to the UL LCG, wherein the first value is less than the SL prioritization threshold, and wherein the second value is equal to or greater than the UL prioritization threshold; Receive UL authorization; determining, based on the size of the UL grant and the determination that at least the SL BSR has been triggered, that the SL BSR is to take precedence over the UL BSR for logical channel prioritization (LCP) associated with a transmission, wherein the SL BSR indicates a buffer status of a prioritized SL LCG; and Based on the UL grant, the transmission is sent, wherein the transmission includes the SL BSR.

10. The method according to claim 9, wherein: Prioritizing the SL BSR over the UL BSR includes assigning a first priority level to the SL BSR for the LCP associated with the transmission and assigning a second priority level to the UL BSR, and wherein the first priority level is higher than the second priority level.

Images