Simultaneous uplink and sidelink operation

Abstract

To provide systems, methods, and instrumentalities for simultaneous uplink and sidelink operation.SOLUTION: An apparatus determines a scheduling request (SR) is triggered and transmits the SR, which is a higher priority than SL data. For an uplink (UL) SR, the SR takes priority over the SL data at least based on prioritization associated with an UL logical channel (LCH) that triggers the SR and an UL prioritization threshold. For a sidelilnk (SL) SR, the SR takes priority over the SL data at least based on that prioritization associated with the SR is a higher priority over prioritization associated with a media access control protocol data unit (MAC PDU) associated with the SL data.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Patent Application No. 62 / 880,919, filed July 31, 2019, and U.S. Provisional Patent Application No. 62 / 909,138, filed October 1, 2019, the contents of which are incorporated herein by reference. [Background technology]

[0002] Mobile communications using wireless communications continue to evolve. The fifth generation of mobile communications may be referred to as 5G. Previous (e.g., conventional) generations of mobile communications may be, for example, fourth generation (4G) long term evolution (LTE). Summary of the Invention

[0003] Systems, methods, and means for simultaneous uplink and sidelink operation 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 parallel or simultaneous UL / SL operation). The transmit and / or receive operation of the WTRU may be configured to consist of simultaneous UL and SL operation. 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 slots, for example, based on one or more prioritization rules. The WTRU may drop an SL transmission or an UL transmission, for example, in response to one or more prioritization rules.

[0004] In an embodiment, a method for performing simultaneous uplink and sidelink operation may be implemented. The method may be implemented, for example, by an apparatus (e.g., a WTRU) that may include one or more processors configured to execute the method as computer-executable instructions, which 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, when executed, cause the one or more processors to perform the method.

[0005] In an embodiment, the WTRU may include a processor configured (e.g., programmed with executable instructions to implement a method) to: determine whether to prioritize an SL LCG based on an SL prioritization threshold and a UL prioritization threshold (e.g., provided that an UL prioritization threshold is configured); determine whether a prioritization value associated with the SL LCG is lower than the SL prioritization threshold; determine (e.g., at least) whether the UL LCG has a prioritization value greater than or equal to the UL prioritization threshold (e.g., provided that an UL prioritization threshold is configured); determine whether to prioritize an SL buffer status reporting (BSR) based on the size of the UL grant and the determination of whether to prioritize the SL LCG; and report buffer status based on the determination of whether to prioritize the SL BSR. The SL prioritization threshold may be configured.

[0006] The SL LCG may include, for example, an LCG having a logical channel including SL data. The UL LCG may include, for example, an LCG having a logical channel including UL data. Determining (e.g., at least) whether an UL LCG has a prioritization value that is greater than or equal to the UL prioritization threshold may include, for example, determining whether (e.g., each) UL LCG has a prioritization value that is greater than or equal to the UL prioritization threshold.

[0007] The SL BSR may be prioritized, for example, under the condition that the SL LCG is prioritized and, if the SL BSR is not prioritized, under the condition that the UL grant size is insufficient for at least (e.g., all) prioritized SL LCGs. The SL BSR may be prioritized over the UL BSR (e.g., if prioritized). The SL BSR may be prioritized and shortened. A prioritized and shortened SL BSR may include a prioritized SL LCG and another SL LCG if another SL LCG is prioritized and the UL grant size is sufficient for the prioritized SL LCG and the other SL LCG. The SL BSR may be unprioritized but shortened, for example. A shortened SL BSR may include, for example, as many SL LCGs as allowed by the UL grant size. The SL LCGs may be prioritized, for example, in response to a determination that the prioritization values ​​associated with the SL LCGs are lower than the SL prioritization threshold and each UL LCG has a prioritization value equal to or greater than the UL prioritization threshold. An SL LCG may be prioritized, for example, in response to a determination that a prioritization value associated with the SL LCG is lower than an SL prioritization threshold and a UL prioritization threshold is not configured. An UL LCG may be prioritized, for example, in response to a determination that a prioritization value associated with the UL LCG is lower than an UL prioritization threshold or that each SL LCG has a prioritization value equal to or greater than an SL prioritization threshold. An UL BSR may be prioritized, for example, in response to a determination that the SL LCG is not prioritized or, if the SL BSR is not prioritized, that the UL grant size is sufficient for the SL BSR. A prioritization value associated with an SL LCG may be determined, for example, using the highest priority value of one or more LCHs that contain SL data and belong to the SL LCG. A prioritization value associated with a UL LCG may be determined, for example, using the highest priority value of one or more LCHs that contain UL data and belong to the UL LCG.A prioritization value associated with an SL LCG may be lower, e.g., indicating a higher priority associated with the SL LCG, or higher, e.g., indicating a lower priority associated with the SL LCG. A prioritization value associated with an UL LCG may be lower, e.g., indicating a higher priority associated with the UL LCG, or higher, e.g., indicating a lower priority associated with the UL LCG.

[0008] In an embodiment, the WTRU may include a processor configured (e.g., programmed with executable instructions to implement a method) to determine that an SL priority threshold is configured, determine whether an LCG will 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., provided that an UL prioritization threshold is configured), and report a buffer status based on the determination that the LCG will be included in the buffer status report.

[0009] Operation of parallel or simultaneous UL / SL interfaces may include one or more procedures such as UL / SL prioritization, SL / SL prioritization, collision avoidance 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 include the presence of pending SL processes / grant, time until packet delay budget (PDB) expiration for a packet, channel busy rate / ratio (CBR), channel occupancy ratio (CR), SL and / or downlink (DL) path loss, SL or UL hybrid automatic repeat request (HARQ) feedback transmission, presence / absence of data on the UL / SL synchronization channel (SCH), characteristics of SL synchronization transmission, scheduling request (SR) transmission, transmission containing a buffer status report (BSR) (e.g., SL or UL), transmission containing a specific type of control message depending on the state of the WTRU, redundancy version (RV) associated with HARQ-based transmission, blind vs. HARQ-based retransmission, blind vs. HARQ-based retransmission, transmission of the same transport block (SCH), and so on. The SL transmission may be based on one or more of the following: unsuccessful / dropped transmission of a previous transmission of the SL block (TB), based on the range requirement of the SL data (e.g., minimum cell rate (MCR)), the resource allocation mode associated with the SL transmission, and / or the like.

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

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

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

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

[0014] The 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.

[0015] 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 within 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 meet the latency requirements associated with the SL data. The additional UL grants may include configured grants.

[0016] The WTRU may, for example, transmit on UL and SL in the same time resource (e.g., slot). For example, the WTRU may be configured with the condition to transmit on SL and UL without dropping / prioritizing any of the SL / UL transmissions. The WTRU may, for example, transmit on both UL and SL if a condition is met, or may, for example, prioritize between UL / SL if a condition is not met. The WTRU may transmit UL and SL, for example, if the SL transmission includes (eg, only) a physical sidelink feedback channel (PSFCH).

[0017] The WTRU may modify the planned / granted transmission format to enable transmission on the UL and / or SL. The WTRU may change the planned or granted transmission format to enable transmission on the UL and SL, for example, in the same slot. Changing the transmission format may include, for example, one or more of changing the UL / SL modulation and coding scheme (MCS), performing puncturing on the UL / SL transmission, and / or changing the TB size or transmission of an alternate TB. The WTRU may modify the planned / granted transmission format for UL and SL transmissions in the same slot. The WTRU may inform the network and / or peer WTRUs of transmissions on UL and / or SL. The WTRU may inform the network and / or peer WTRUs of expected format changes. The WTRU may inform the network or peer WTRUs of transmissions on UL and SL in the same slot.

[0018] 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, and the WTRU may perform a resource selection procedure taking into account the configured SR resources.

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

[0020] The WTRU may change the active SL control / scheduling cell group (CG). A WTRU configured with dual connectivity (DC) may receive SL scheduling (e.g., Mode 1 scheduling) from (e.g., one of two cell groups). The WTRU may decode SL scheduling on (e.g., only) the CG associated with the active SL control / scheduling at a given time. [Brief explanation of the drawings]

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

[0022] [Figure 1B]1B is a system diagram illustrating an exemplary wireless transmit / receive unit (WTRU) that may be used within the communications system shown in FIG. 1A, according to one embodiment.

[0023] [Figure 1C] 1B is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system shown in FIG. 1A, according to one embodiment.

[0024] [Figure 1D] 1B is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communication system shown in FIG. 1A, according to one embodiment.

[0025] [Figure 2] An example of establishing a secure Layer 2 link via PC5 is shown.

[0026] [Figure 3] 1 illustrates an example of performing uplink and sidelink operations with prioritization.

[0027] [Figure 4] 1 illustrates an example of performing uplink and sidelink operations with prioritization. DETAILED DESCRIPTION OF THE INVENTION

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

[0029] 1A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RANs 104 / 113, CNs 106 / 115, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and / or “STA,” may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain situations), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as a UE.

[0030] The communications system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communications 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 eNodeB, a Home Node B, a Home eNodeB, a gNB, an NRNodeB, a site controller, an access point (AP), a wireless router, etc. Although the base stations 114a, 114b are each illustrated as a single element, it will be understood that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

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

[0032] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over the 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).

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

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

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

[0036] 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 both LTE radio access and NR radio access, e.g., using a dual connectivity (DC) principle. Thus, the air interface utilized 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).

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

[0038] 1A 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 localized area, such as a business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by a drone), a roadway, or other location. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may establish a picocell or a femtocell using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 through the CN 106 / 115.

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

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

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

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

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

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

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

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

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

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

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

[0050] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, etc. The peripheral device 138 may include one or more sensors, which may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, a direction 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.

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

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

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

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

[0055] 1C 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 illustrated as part of the CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0056] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may act 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 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.

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

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

[0059] 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 landline communication devices. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0060] Although the WTRU is depicted in FIGS. 1A-1D as a wireless terminal, it is contemplated that in certain representative embodiments, such a terminal may use a wired communication interface (e.g., temporary or permanent) with the communication network.

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

[0062] A WLAN in infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access to or interface with a Distribution System (DS) or another type of wired / wireless network that carries traffic within and / or outside the BSS. Traffic originating from outside the BSS to a STA may arrive through the AP and be delivered to the STA. Traffic originating from a STA to a destination outside the BSS may be sent to the AP for delivery to the respective destination. Traffic between STAs within the BSS may be sent through the AP; for example, a 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 peer-to-peer traffic. Peer-to-peer traffic may be sent (e.g., directly) between a source STA and a destination STA using a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and STAs within or using an IBSS (e.g., all of the STAs) may communicate directly with each other. IBSS mode communication may sometimes be referred to herein as "ad hoc" mode communication.

[0063] When using the 802.11ac infrastructure mode of operation or a similar mode of operation, an AP may transmit beacons 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 the operating channel of the BSS and may be used by STAs to establish a connection with the AP. In one representative embodiment, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. With CSMA / CA, STAs (e.g., all STAs), including the AP, may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time within a given BSS.

[0064] High Throughput (HT) STAs may use 40 MHz wide channels for communication, for example, by combining a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

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

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

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

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

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

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

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

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

[0073] 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 UL and / or DL ​​users, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a, 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D , the gNBs 180a, 180b, 180c may communicate with each other over an Xn interface.

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

[0075] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, managing registration areas, terminating NAS signaling, mobility management, etc. Network slicing may be used by the AMF 182a, 182b to customize CN support for the WTRUs 102a, 102b, 102c based on the type of service utilized by the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, and / or the like. 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 like WiFi.

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

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

[0078] The CN 115 may facilitate communication with other networks. For example, the CN 115 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108. Additionally, 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 through the UPFs 184a, 184b via an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

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

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

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

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

[0083] 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), in which WTRUs in vehicles may communicate directly with each other; vehicle-to-infrastructure (V2I), in which WTRUs in vehicles may communicate with a roadside unit (RSU) / eNB; vehicle-to-network (V2N), in which WTRUs in vehicles may communicate with a core network (CN); and / or vehicle-to-pedestrian (V2P), in which WTRUs in vehicles may communicate with a WTRU in special conditions (e.g., low battery capacity).

[0084] V2X resource allocation may be performed in different modes. Multiple (e.g., two) modes of operation for V2X communication may be used. The network may grant a WTRU a scheduling assignment for V2X sidelink transmissions (e.g., in Mode 3). The WTRU may autonomously select resources from a configured / pre-configured resource pool (e.g., in Mode 4). V2X may use multiple categories of resource pools, including, for example, a receive pool that may be monitored to receive V2X transmissions and / or a V2X transmit pool that may be used by the WTRU to select one or more transmit resources (e.g., in Mode 4). The transmit pool may not be used by a WTRU configured in Mode 3.

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

[0086] New Radio (NR) V2X access technologies may support, for example, enhanced Mobile Broadband (eMBB) and / or ultra-high reliability and low latency communications (URLLC). Enhanced V2X (eV2X) communications may be supported (e.g., in NR systems). 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 3 ms latency.

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

[0088] Vehicle platooning may enable vehicles to dynamically form groups that travel together. Vehicles in the platoon may receive periodic information (e.g., data) from another vehicle (e.g., a lead vehicle) to continue platooning. This information may allow the distance between vehicles to be small (e.g., very small). For example, the gap distance between vehicles converted to time may be low (less than 1 second). Platooning applications may enable vehicles (e.g., another vehicle following a vehicle) to be driven autonomously.

[0089] Advanced driving may enable semi- or fully automated driving. Longer inter-vehicle distances may be envisioned. Vehicles (e.g., each) and / or RSUs may share data obtained from their local sensors with nearby vehicles, allowing the vehicles to adjust their trajectories or maneuvers. Vehicles (e.g., each) may share their driving intentions with nearby vehicles. Information sharing or other adjustments may support, for example, safer driving, collision avoidance, and / or improved traffic efficiency.

[0090] The extended sensors may enable the exchange of raw or processed data collected through local sensors or live video data between one or more vehicles, RSUs, pedestrian devices, V2X application servers, and / or the like. The extended sensors may enhance the awareness that vehicles have of their environment beyond what any vehicle sensor can detect, thereby providing a more holistic view of the local situation.

[0091] Remote driving may enable a remote driver or V2X application to operate remote vehicles, for example, for passengers who cannot drive themselves and / or remote vehicles located in hazardous environments. Driving may be based on cloud computing, for example, with limited variability and predictable routes (e.g., public transportation). Cloud computing may be provided, for example, based on access to a cloud-based backend service platform.

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

[0093] One-to-one ProSe direct communication may be realized, for example, by establishing a secure Layer 2 link between multiple (e.g., two) WTRUs via PC5. (E.g., each) WTRU may have a Layer 2 identifier (ID) for unicast communication that is included in the source Layer 2 ID field of (e.g., all) frames transmitted on the Layer 2 link and / or included in the destination Layer 2 ID of (e.g., all) frames 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 the Layer 2 IDs of the multiple (e.g., two) WTRUs. A WTRU may be involved in multiple Layer 2s for one-to-one ProSe direct communication using the same Layer 2 ID.

[0094] WTRUs involved in decoupled (eg, non-relayed) point-to-point communication may negotiate an IP address allocation mechanism and / or exchange link-local IPv6 addresses, for example, if used during the link establishment procedure.

[0095] 2 shows an example of establishing a secure Layer 2 link via PC5. As shown in FIG. 2, 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. Upon successful completion of the authentication procedure, the establishment of a secure Layer 2 link via PC5 may be completed. WTRU-2 may include the user information in its response to WTRU-1.

[0096] The PC5 signaling protocol may support a keep-alive function that may be used to detect when a WTRU is not in ProSe communication range, for example, to proceed with an implicit Layer 2 link release.

[0097] The WTRU may be configured to perform link establishment for V2X (e.g., NRV2X). Procedures may be configured and utilized for establishing and / or maintaining a secure L2 link via PC5. Procedures may be enhanced and / or adapted for V2X. V2X signaling may be defined (e.g., at the RRC layer). V2X link / group handling may be configured. In the example of V2X communication, not all WTRUs may support and / or use unicast communication. Link establishment may be supported by service announcements. For example, service announcements may be used to inform peers of the WTRU's presence and / or capabilities for unicast communication (e.g., operating channels, and / or supported services, and / or the like).

[0098] The service announcement may be accessible to one or more (e.g., all) WTRUs that may be interested in using the service. The announcement may be configured, for example, to be sent over a dedicated channel (e.g., similar to how wireless access in vehicular environment (WAVE) service advertisements (WSA) may be handled) or may be configured to be piggybacked on periodic messages from supporting WTRUs.

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

[0100] A set of service requirements (e.g., the same set) may be applied to PC5-based V2X communication and Uu-based V2X communication. The QoS characteristics may be expressed, for example, using a quality indicator (e.g., a 5G quality indicator (5QI)).

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

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

[0103] The (e.g., same) QoS model used for Uu may be used for unicast-type traffic. For example, (e.g., each) unicast link may be treated as a bearer, and a QoS flow may be associated with the unicast link / bearer. One or more (e.g., all) QoS characteristics (and, e.g., additional data rate parameters) defined for 5QI may be applied to the QoS model / flow. Minimum communication range may be treated as a (e.g., additional) parameter (e.g., specifically for PC5 usage). In an embodiment, a similar configuration may be applied to multicast traffic. Multicast may be treated as a special case of unicast, e.g., with multiple defined receivers of the traffic.

[0104] Broadcast traffic may not have a bearer concept. (E.g., each) message may have different characteristics (e.g., according to broadcast application requirements). In one example, a 5QI may be used similar to PPPP / ProSe Per-Packet Reliability (PPPR), e.g., to be tagged with each packet. The 5QI may (e.g., can) represent one or more (e.g., all) characteristics that may be used for PC5 broadcast operation, such as one or more of latency, priority, reliability, etc. A group of V2X broadcast-specific 5QIs (i.e., VQIs) may be defined / configured for PC5 use.

[0105] In one example, PC5 QoS parameters may be negotiated when (e.g., at the time of or during) the establishment of 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. The (e.g., same) QoS may be used in both directions, for example, after the PC5 QoS parameter negotiation procedure.

[0106] As mentioned above, Figure 2 shows an example of establishing a secure Layer 2 link over PC5. WTRUs involved in one-to-one communication may negotiate PC5 QoS parameters, for example, during the 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 the procedure for mutual authentication. WTRU-2 may include the allowed PC5 QoS parameters in a response message (e.g., to WTRU-1).

[0107] UL / SL prioritization may be supported in V2X. A V2X device may support simultaneous UL and SL transmissions in one or more of the following scenarios: the UL TX and SL TX may use separate TX chains and / or separate power budgets; the UL TX and SL TX may use separate TX chains while sharing power budget; and / or the UL TX and SL TX may share TX chains and power budget.

[0108] Simultaneous UL and SL transmissions may be subject to one or more rules for various scenarios (e.g., when different carriers are present (e.g., when simultaneous TX on UL and SL cannot be implemented or modified)) and when there is potential simultaneous TX on UL and SL on the same carrier. In a same carrier example (e.g., when simultaneous TX and RX cannot be used), the WTRU may, for example, drop the UL TX or SL TX if it overlaps in the time domain with the SL TX on a shared (or same) carrier frequency. The WTRU may, for example, drop the UL TX if the PPPP of the SL packet exceeds a (pre-)configured PPPP value (e.g., a PPPP threshold). The WTRU may, for example, drop the SL TX otherwise. In a different carrier example (e.g., when simultaneous TX and RX are possible (e.g., when UL TX and SL TX use separate TX chains)), the WTRU may, for example, drop or reduce the power of the UL TX or SL TX if it overlaps in the time domain with the SL TX on a different carrier frequency. The WTRU may, for example, drop the UL TX or reduce the UL TX power if the PPPP of the SL packet exceeds a (pre-)configured PPPP threshold. The WTRU may, for example, drop the SL TX or reduce the SL TX power otherwise.

[0109] The aforementioned UL / SL prioritization rules (e.g., for LTE V2X) may differ in some implementations of V2X (e.g., NR V2X), which may have one or more of the following characteristics: different QoS models, strict QoS for SL and / or UL, unicast transmission of SL, and / or simultaneous transmission in Mode 1 and Mode 2.

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

[0111] In some implementations of V2X (e.g., NR V2X), strict QoS may be applied to the 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 pronounced for some V2X traffic / services than for other V2X traffic / services.

[0112] In some implementations of V2X (e.g., NR V2X), unicast transmissions may be used for SL. Unicast transmissions may use HARQ and / or channel state information (CSI) feedback. Unicast SL transmissions may be dropped (e.g., as part of UL / SL prioritization). HARQ feedback may be carried on a different SL physical layer (PHY) channel (e.g., the Physical Sidelink Feedback Channel (PSFCH)). HARQ feedback carried on a different SL PHY channel may affect how UL and / or SL transmissions are viewed or prioritized, for example, when there is a collision of UL and SL transmissions.

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

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

[0115] UL / SL operation (e.g., simultaneous UL / SL operation) may be based on one or more of UL / SL prioritization, SL / SL prioritization, collision avoidance between different UL / SL transmissions, and / or the like.

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

[0117] The UL / SL prioritization may be determined, for example, by the WTRU. The WTRU may, for example, perform (e.g., make a determination to perform) an UL transmission or an SL transmission at a given time instance (e.g., a time when UL and SL transmissions are scheduled simultaneously). The WTRU may select (e.g., decide to select) an UL or SL transmission for a given time instance (e.g., slot). The WTRU may, for example, select (e.g., decide to select) an UL or SL transmission based on one or more restrictions on the WTRU. The restrictions may include, for example, one or more of: a shared (e.g., single) TX chain between UL and SL (e.g., when 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., when transmitted simultaneously).

[0118] The WTRU may be configured to prioritize UL or SL transmissions. Prioritizing transmissions may include, for example, the WTRU dropping a scheduled transmission (e.g., a transmission with a lower priority) and / or reducing the transmit power (e.g., for a transmission with a lower priority), and / or the like. The WTRU may (e.g., if the WTRU drops one of the scheduled transmissions) one or more of: keeping the dropped transmission in a HARQ buffer and / or delaying the transmission (e.g., to the next scheduled transmission); dropping the transmission and increasing the redundancy version (RV) associated with the transport block assuming the transmission was performed; and / or performing a transmission of the next redundancy version for the transmission (e.g., at the scheduled time).

[0119] The WTRU may, for example, prioritize transmissions (eg, UL or SL) based on one or more conditions. The conditions of the prioritized link (e.g., UL, SL) may be based on one or more (e.g., combinations thereof), such as, for example, the presence of pending SL processes / grants, time until the packet's PDB expires, the channel busy ratio (CBR), the channel occupancy ratio (CR), the SL and / or DL ​​path loss, the transmission of SL or UL HARQ feedback, the presence / absence of data on the UL / SL synchronization channel (SCH), the characteristics of the SL synchronization transmission, the transmission of a scheduling request (SR), the transmission containing a buffer status report (BSR) (e.g., SL or UL), the transmission containing a BSR (e.g., SL or UL), (e.g., depending on the state of the WTRU), the transmission containing a particular type of control message, the redundancy version associated with the HARQ-based transmission, blind vs. HARQ-based retransmission, blind vs. HARQ-based retransmission, unsuccessful / dropped transmission of a previous transmission of the same transport block (TB), the range requirement of the SL data (e.g., Minimum Cell Rate (MCR)), the resource allocation mode associated with the SL transmission, and / or the like.

[0120] The conditions for link prioritization may include the presence of a pending SL process / grant. The WTRU may prioritize the UL, for example, if there is another pending grant in the SL. The pending grant in the SL may satisfy the QoS requirements of the SL packet being dropped.

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

[0122] The link prioritization criteria may include CBR. UL transmissions may be prioritized, for example, if the CBR is higher than a certain value (e.g., a threshold) to reduce congestion of sidelink resources. SL transmissions may be highly prioritized, for example, if the CBR is lower than a threshold. The threshold may be configured, for example, by higher layer signaling. The threshold may be configured, for example, by the gNB or the WTRU.

[0123] The link prioritization criteria may include channel occupancy (CR). UL transmissions may be prioritized, for example, if the CR is higher than a certain value (e.g., a threshold), which may indicate that the WTRU is using more SL resources than expected.

[0124] The link prioritization criteria may include SL and / or DL ​​pathloss. SL transmissions may be prioritized and / or the link for the sidelink may be better than the uplink, e.g., if the DL pathloss value is higher than the SL pathloss. UL transmissions may be prioritized, e.g., if the DL pathloss value is less than or equal to the SL pathloss. A weighting factor may be used, e.g., to compare the DL pathloss and the SL pathloss. For example, the DL path loss is α·PL DL and / or the SL path loss can be expressed as β PL SL 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 configured (e.g., by the network).

[0125] The link prioritization criteria may include transmission of SL or UL HARQ feedback. The WTRU may prioritize UL / SL transmissions, for example, if the transmission is for transmitting HARQ feedback. The WTRU may prioritize SL transmissions over UL transmissions, for example, if the SL transmissions include transmissions on the PSFCH. The WTRU may prioritize UL transmissions over SL transmissions, for example, if the UL transmissions include uplink control information (UCI) and / or HARQ feedback for the physical uplink shared channel (PUSCH).

[0126] The WTRU may be configured, for example, to consider transmission of UL and / or SL HARQ feedback as lower priority than other transmissions (e.g., data). The WTRU may prioritize UL transmissions, for example, when the SL transmissions include (e.g., only) PSFCH transmissions.

[0127] The prioritization of UL or SL HARQ feedback may depend on one or more (eg, a combination of) characteristics associated with the HARQ feedback. Characteristics that may affect the prioritization of UL or SL HARQ feedback may include, for example, one or more of the following: the QoS of the data associated with the HARQ feedback, the redundancy version associated with the HARQ feedback, whether an ACK / NACK is reported, the TB size, an indication in the WTRU transmitted data, the cast associated with the HARQ feedback, the number of HARQ bits in the HARQ feedback transmission, and / or the like.

[0128] The prioritization of UL or SL HARQ feedback may be based on the QoS of the data associated with the HARQ feedback. The WTRU may, for example, prioritize UL / SL HARQ transmissions depending on the QoS of the data associated with the HARQ transmission. The WTRU may compare a QoS metric associated with the data on which the HARQ is being transmitted with a QoS metric of 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 on which the HARQ is being transmitted. In an embodiment, the WTRU may, for example, prioritize a HARQ transmission on the SL if the priority of the transmission on which the HARQ is being 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 on which the HARQ is being transmitted with a value (e.g., a threshold). The threshold may be (pre-)configured. The WTRU may, for example, prioritize a HARQ transmission on the SL if the priority of the transmission on which the HARQ is being transmitted exceeds a threshold. The WTRU may prioritize a HARQ transmission on the SL, for example, if the priority of the transmission for which the HARQ is being transmitted (e.g., signaled in the SCI) exceeds a threshold. The threshold may depend on the measured occupancy of the channel. The QoS metric may be related to the LCH priority associated with the recognized data. The WTRU may prioritize a HARQ transmission, for example, based on the priority of the LCH for the data for which the HARQ feedback is being transmitted. The WTRU may prioritize a HARQ transmission, for example, if the highest priority LCH for the data for which the HARQ feedback is being transmitted is higher than the LCH priority of data on another link. The WTRU may prioritize a HARQ transmission, for example, if the highest priority LCH for the data for which the HARQ feedback is being transmitted is higher than a threshold. The threshold may include a (pre-)configured threshold.

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

[0130] The 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 an ACK transmission.

[0131] The prioritization of UL or SL HARQ feedback may be based on transport block (TB) size. The WTRU may prioritize UL / SL HARQ transmissions, for example, if the resource size of the transmission associated with the HARQ feedback exceeds a certain value (e.g., a (pre-)configured threshold). The WTRU may prioritize UL / SL HARQ transmissions, for example, if the TB size of the transmission associated with the HARQ feedback exceeds a threshold (e.g., a (pre-)configured threshold).

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

[0133] The prioritization of UL or SL HARQ feedback may be based on the CAST associated with the HARQ feedback. The WTRU may prioritize SL HARQ transmissions associated with a CAST or CAST type, but the WTRU may not prioritize SL HARQ transmissions associated with other CASTs or other types of CASTs. For example, the WTRU may prioritize SL HARQ transmissions for unicast but not for groupcast. The WTRU may associate different priority levels for SL HARQ transmissions for unicast versus groupcast. The WTRU may use, for example, one or more rules and / or conditions for determining whether to prioritize unicast HARQ feedback and one or more different rules and / or conditions for determining whether to prioritize groupcast HARQ feedback. The one or more rules and / or conditions may, for example, be one or more of the rules and / or conditions described herein.

[0134] The prioritization of UL or SL HARQ feedback may be based on the number of HARQ bits in the HARQ feedback transmission. The WTRU may, for example, prioritize SL HARQ transmissions if the number of HARQ bits in the HARQ transmission is greater than a certain value (e.g., a threshold). The threshold may include a (pre-)configured or pre-determined threshold.

[0135] 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 embodiment, the WTRU may prioritize PSFCH transmissions over UL transmissions, for example, if an acknowledgement (ACK) has been transmitted and / or if the resource size associated with the SL data transmission is greater than a threshold. The threshold may depend, for example, on the measured CBR. The WTRU may prioritize PSFCH transmissions over UL transmissions, for example, if an ACK has been transmitted and / or if a peer WTRU has indicated (e.g., in an SCI associated with a data transmission) that it intends to reuse reserved retransmission resources. The WTRU may prioritize a PSFCH transmission over an UL transmission, for example, if an ACK has been transmitted and / or if the QoS associated with the acknowledged data transmission exceeds a threshold (e.g., a (pre-)configured threshold). The WTRU may prioritize a PSFCH transmission over an UL transmission, for example, if the HARQ feedback transmission corresponds to a retransmission. In an embodiment, the WTRU may prioritize a PSFCH transmission over an UL transmission, for example, if the HARQ feedback transmission corresponds to an Nth or greater retransmission and / or if the priority associated with the transmission is higher than the priority associated with the UL data transmission.

[0136] The link prioritization conditions 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. The WTRU may prioritize / deprioritize SL, for example, if the UL transmission includes (e.g., only) PHY / L1 control signaling. L1 signaling may include transmission of CSI on the PUSCH without the UL SCH. The WTRU may prioritize SL transmissions, for example, if the UL transmission includes (eg, only) an SRS transmission.

[0137] The link prioritization criteria may include characteristics of SL synchronization transmissions. The WTRU may prioritize SL synchronization signal (SLSS) transmissions, which may be associated with a particular type or characteristics. The WTRU may prioritize SLSS transmissions over UL transmissions, for example, if the WTRU is configured as a group leader. The WTRU may prioritize SLSS transmission over UL transmission, for example, when the WTRU is in an active unicast session. SLSS may be used interchangeably with sidelink synchronization signal block (SL-SSB), sidelink synchronization signal, and a physical broadcasting channel block (SL-SSB / PBCH). The WTRU may prioritize a (e.g., selected) type of UL transmission (e.g., URLLC) over SLSS transmission. For example, the WTRU may be configured with a set of UL LCHs. The set of UL LCHs may be prioritized over SLSS. SLSS may be prioritized over UL transmission, for example, if the WTRU has not received an SLSS signal for a certain period of time (e.g., longer than X period). Period X may be pre-determined, pre-configured, configured, or indicated, for example, by the gNB.

[0138] The link prioritization criteria may include SR transmission. The WTRU may prioritize SR transmission over SL transmission. The SR transmission may be triggered by the WTRU. For example, the WTRU may prioritize (e.g., always prioritize) UL transmission of SR over SL transmission. The WTRU may prioritize SR transmission in the UL based on one or more (e.g., a combination of) characteristics associated with the SR transmission, such as whether the SR is triggered due to arrival of UL or SL data, an LCH associated with the SR configuration, the amount of time between SR resources, and / or the like.

[0139] Implementations and / or features herein may be described in terms of the behavior (e.g., operation) of a WTRU. In embodiments, the behavior may be performed by an entity such as a NW node or other device that may not include WTRU functionality. In some examples (e.g., in certain use cases or certain time instances), the entity or other device may behave like a WTRU. One or more examples herein may be equally applicable to the entity or other device.

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

[0141] The WTRU may prioritize SR transmissions on the UL, for example, based on the LCH associated with the SR configuration. The WTRU may prioritize UL transmissions when transmitting SRs, for example, based on the QoS characteristics configured for the LCH and / or the triggered SR. The WTRU may prioritize UL transmissions, for example, if the WTRU transmits an SR associated with a logical channel configured with a priority. The WTRU may prioritize UL transmissions, for example, if the WTRU transmits an 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 SR is associated with a logical channel configured with a priority greater than the priority of a conflicting SL transmission.

[0142] The WTRU may prioritize SR transmissions in the UL based on, for example, the amount of time between SR resources. The WTRU may prioritize UL transmissions when transmitting an SR based on, for example, the amount of time between SR resources configured at the WTRU (e.g., in combination with the QoS characteristics of the data that triggers the SR). In an embodiment, the WTRU may prioritize a UL transmission including an SL SR if, for example, the next SL SR resource cannot be transmitted within several slots. The WTRU may prioritize a UL transmission including an SL SR if, for example, the next SL SR resource that can be transmitted to the network (e.g., which may be associated with the SL data that triggered the SR) cannot be transmitted to the network within the next N slots, where N may depend on the QoS characteristics (e.g., latency, reliability) of the SL data that triggered the SR.

[0143] The conditions for link prioritization may include a transmission that includes a BSR (e.g., SL or UL). The WTRU may prioritize the UL, for example, if the UL transmission includes an SL BSR or an 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 type of SL BSR may include, for example, a non-padding BSR (e.g., only). The WTRU may prioritize the UL, for example, if the UL transmission includes an SL or UL BSR. The WTRU may prioritize the UL, for example, if the UL transmission includes an SL or UL BSR, for example, if the reported LCH priority may meet one or more conditions. The conditions may include, for example, one or more of: 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 a (e.g., pre-)configured or selected) offset from the SL transmission priority.

[0144] The link prioritization criteria may include, for example, transmissions having a type (e.g., a particular type) of control message depending on the WTRU state. The WTRU may prioritize UL or SL, for example, if the transmission includes a medium access control (MAC) control element (CE) or an RRC message (e.g., of a particular type). The WTRU may prioritize SL / UL, for example, if the transmission includes an SL / UL MAC CE or SL / UL RRC message. The MAC CE / RRC may be associated with, for example, one or more functions of SL / UL power control, SL / UL CSI measurements, SL / UL radio link monitoring (RLM) / radio link failure (RLF), SL resource allocation, SL / UL configuration, and / or SL / UL measurement reporting. In an embodiment, the WTRU may prioritize SL / UL for MAC CE / radio resource control (RRC) messages depending on, for example, the WTRU state. The transmission may be used to avoid and / or transition out of a state. In an embodiment, the WTRU may prioritize SL RRC messages, for example, during the SL link establishment phase, e.g., if the WTRU has an active SL unicast link, may prioritize SL RRC messages, for example, if the WTRU experiences a beam failure, may prioritize UL control messages, for example, if the WTRU is required or uses a different configuration for SL HARQ feedback resources, may prioritize SL RRC / MAC CEs, for example, if the WTRU reports an MCG / SCG failure message, may prioritize UL RRC messages, for example, if reporting an MCG / SCG failure message, may prioritize a UL indication (e.g., by an RRC message), for example, when detecting an SL RLF.

[0145] The link prioritization criteria may include the redundancy version (RV) associated with the HARQ-based transmission. The WTRU may associate different priority levels with (e.g., specific) redundancy versions associated with the HARQ-based transmission, or may prioritize the UL or SL based on (e.g., specific) redundancy versions associated with the HARQ-based transmission. In an embodiment, the WTRU may prioritize retransmissions over the initial transmission. For example, the WTRU may prioritize the SL if the SL includes HARQ retransmissions with RV>N, where N may be (pre-)configured. The WTRU may prioritize the SL or UL based on, for example, a comparison between the SL and the UL RV. The WTRU may prioritize the SL if, for example, the SL RV is greater than the UL RV. The WTRU may add an offset to the priority based on, for example, the redundancy version or retransmission number when performing the UL / SL priority comparison. For example, when the WTRU performs a UL / SL priority comparison based on the LCH priority or any priority-based metric, it may add an offset to the priority based on the redundancy version or retransmission number (e.g., associated with the LCH priority or any priority-based metric). The offset may be (pre-)configured for (e.g., each) redundancy version and / or retransmission number. The offset may also be a (e.g., pre-defined) function of the redundancy version and / or retransmission number.

[0146] Link prioritization criteria may include blind versus HARQ-based retransmissions. The WTRU may prioritize retransmissions in SL differently depending on, for example, whether the retransmission is a HARQ feedback-based retransmission or a blind retransmission. The WTRU may prioritize SL retransmissions over UL (re)transmissions, for example, when the SL retransmission is generated as a result of receiving a feedback-based indication such as a not acknowledged (NACK). The WTRU may not prioritize SL retransmissions, for example, if the retransmission is associated with a blind retransmission.

[0147] The link prioritization criteria may include unsuccessful / dropped transmissions of previous transmissions of (e.g., the same) TB. The WTRU may prioritize retransmissions in SL / UL over (re)transmissions in UL / SL, for example, if a previous (re)transmission in SL / UL failed (e.g., due to a dropped transmission). The WTRU may prioritize retransmissions in SL over transmissions in UL, for example, if a previous transmission in SL of the same TB was dropped because the UL was prioritized. The WTRU may prioritize retransmissions in SL, for example, to allow at least N SL transmissions of (e.g., the same) TB to be performed (e.g., without being dropped due to UL prioritization).

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

[0149] The link prioritization criteria may include a resource allocation mode that may be associated with the SL transmission. The WTRU may, for example, prioritize transmissions on the SL (e.g., relative to the UL) depending on the resource allocation mode associated with the SL transmission. For example, the WTRU may prioritize SL transmissions associated with resources reserved for the future (e.g., reserved) (e.g., not prioritize the SL transmission if no future reservation was performed). The WTRU may prioritize SL transmissions for which LBT was performed (e.g., not prioritize the SL transmission if LBT was not performed).

[0150] Different priority levels may be used. Different priority levels may be associated with different conditions. The WTRU may determine the priority level associated with different transmissions based on, for example, one or more (e.g., combinations of) conditions (e.g., 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), e.g., where P1>P2>P3. The WTRU may associate a priority level with a data (e.g., data-only) transmission, for example, based on the approaches described herein. The WTRU may be configured with a priority level for non-database transmissions (e.g., as described herein), for example, based on (pre-)configuration. The WTRU may compare the priority of database transmissions with non-database transmissions, for example, based on the priority level assigned to (e.g., each) transmission. The WTRU may determine the priority level associated with an UL transmission or an SL transmission (e.g., including data transmission and non-data transmission), e.g., as the priority level associated with the highest priority transmission. For example, the prioritization value associated with an SL LCG is determined using the highest priority prioritization value among one or more LCHs that contain SL data and belong to the SL LCG. The prioritization value associated with an UL LCG is determined using the highest priority prioritization value among one or more LCHs that contain UL data and belong to the UL LCG. The WTRU may prioritize UL or SL, for example, according to which has the higher (e.g., highest) derived priority level. The SL LCG may include logical channels that contain SL data. The UL LCG may include logical channels that contain UL data.

[0151] Different rules may be used, for example, depending on which conditions are met. The WTRU may use a first condition or rule for prioritization, for example, if and / or when a first condition or combination of conditions is met. The WTRU may use a second rule for prioritization, for example, if and / or when a second condition or combination of conditions is met. The rules and / or conditions used may be one or more (e.g., combinations of) the rules and / or conditions described herein. In an embodiment, the WTRU may prioritize an UL transmission, for example, if the UL includes a non-padded BSR. The AWTRU may prioritize an UL transmission, for example, if the UL includes a non-padded BSR where the highest priority LCH reported in the BSR is higher than the priority of any LCH associated with SL data. The WTRU may prioritize between SL and UL transmissions based on a comparison of the UL / SL logical channels (e.g., as described herein), for example, if a condition is not met (e.g., the BSR does not include an LCH of higher priority than the LCH associated with the SL). The WTRU may determine whether to prioritize a UL transmission versus an SL transmission (e.g., by comparing the RVs associated with the transmissions), for example, if either of the transmissions is associated with a retransmission. The WTRU may prioritize UL or SL based on a comparison of UL vs. SL LCH priority, 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.

[0152] A tiebreaker or hierarchical priority rule may be used to determine the priority. The WTRU may define (e.g., create, select, and / or configure) a rule for prioritizing UL versus SL, e.g., when UL and SL have or are defined to have equal priority. The WTRU may, e.g., transmit on UL (e.g., always transmit), transmit on SL (e.g., always transmit), transmit on UL or SL depending, e.g., on which direction the most data is being transmitted, e.g., transmit on UL if a previous collision resulted in a transmission on SL or vice versa, and / or transmit on UL / SL if, e.g., the previous slot was a UL / SL transmission (e.g., when UL and SL have equal priority).

[0153] The WTRU may notify the network (NW) that the UL transmission has been dropped. In an embodiment, the WTRU may notify the network after deciding to prioritize the SL transmission. The WTRU may notify the network of a transmission in the same slot (e.g., multiplexed in the same slot as the SL transmission, e.g., using one or more approaches described herein). The WTRU may notify the network at a time after the UL transmission is dropped. The WTRU may send an indication using, for example, one or more of a dedicated UCI transmission, an SR transmission, a BSR transmission, a dedicated MAC CE, and / or the like.

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

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

[0156] The WTRU may transmit the indication using a BSR transmission. The WTRU may trigger a BSR transmission, for example, after deciding to prioritize the SL transmission.

[0157] The WTRU may send an indication using a dedicated MAC CE. For example, the WTRU may send a dedicated MAC CE. The MAC CE may indicate the timing of the UL transmission that was dropped by the WTRU.

[0158] The WTRU may notify the network that the WTRU prioritizes SL transmissions under (e.g., based on) certain conditions. The conditions may include, for example, one or more of: the WTRU may be (pre-)configured to provide an indication; the UL transmission may be associated with data (e.g., including data of a (pre-)configured LCH or LCH priority); the DL cell quality may exceed / below a threshold; and the gNB may increase the PDCCH aggregation level, for example, to request a retransmission of the dropped UL transmission. For example, due to SL prioritization, a first UL grant may be dropped. The first UL grant may be received on a PDCCH with aggregation level x1. The gNB may, for example, transmit a second UL grant for the same transport block after dropping the first UL grant. The WTRU may send an indication, for example, if the second UL grant is received on a PDCCH with aggregation level x2 and x2>x1. The WTRU may (eg, alternatively) send an indication if, for example, x2-x1>a threshold value.

[0159] 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 embodiment, the WTRU may determine which transmission to prioritize based on, for example, the configured priority of the logical channel associated with (e.g., each) transmission. The WTRU may compare the priorities of (pre-)configured logical channels multiplexed into (e.g., each) transmission. The (pre-)configured logical channel may be, for example, the sidelink or uplink, as needed. The WTRU may prioritize the transmission with the higher (e.g., highest) LCH priority. The LCH priority may be determined, for example, by one or more of: the WTRU selecting an UL or SL transmission with a relatively high (e.g., highest) LCH priority and / or the WTRU comparing a weighted sum of the LCH priorities. The WTRU may select the UL or SL transmission with a relatively high (e.g., highest) calculated priority. The calculated priority for a transmission may be a function of the priority (e.g., sum or weighted sum) of the (e.g., each) logical channel multiplexed into that transmission. For example, the WTRU may calculate a weighted average of the priorities of several (e.g., each) of the logical channels multiplexed in the transmission and / or compare the weighted average of the UL transmissions with the weighted average of the SL transmissions. The WTRU may prioritize the transmission with the calculated highest priority. The weighting may be based on data size. For example, the WTRU may weight the priority with 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 with the prioritized bit rate (e.g., determined during a logical channel prioritization (LCP) procedure for each logical channel). In an embodiment, a logical channel may be given a higher weight, e.g., if the data included in the transmission is used to meet a PBR for the execution of an LCP procedure. A logical channel may be given a lower weight, e.g., if it contains primarily data (e.g., data used primarily during step 3 of LCP).For example, in step 3 of the LCP, the WTRU may include in the grant as much data as is available in the buffer (e.g., even if the data exceeds the prioritized bit rate). The WTRU may include in the grant as much data as is available in the buffer, starting with the highest priority logical channel and, e.g., by moving to the next highest priority logical channel until the grant is filled. The WTRU may (e.g., alternatively) prioritize transmissions that include a large (e.g., largest) amount or percentage of data to satisfy the PBR.

[0160] The WTRU may, for example, perform a weighted average of the LCHs (eg, only those LCHs with priority above a (pre-)configured threshold), as described herein.

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

[0162] The WTRU may offset the SL priority based on, for example, sidelink measurements or QoS. In one example, which may be used in conjunction with other embodiments (e.g., as described herein), the WTRU may consider SL-related measurements and / or SL QoS characteristics (e.g., in addition to LCH priority) to determine whether to prioritize UL or SL transmissions. For example, because the realization of QoS for 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 because a direct comparison of NW-configured SL and UL LCH priorities may or may not be sufficient, offsetting the SL priority and considering SL-related measurements and / or SL QoS characteristics may be implemented.

[0163] An offset to the calculated priority (e.g., as described herein) may be included, for example, in implementations that consider other factors (e.g., besides logical channel priority). 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 an offset) to determine which transmission (e.g., UL / SL) to prioritize. The WTRU may calculate the offset based on, for example, one or more (e.g., a combination of) the measured channel occupancy, the PDB associated with the sidelink transmission or the remaining PDB, and / or the presence of another SL process / grant at the WTRU that may be used to transmit the dropped SL transmission.

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

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

[0166] The WTRU may calculate an offset based on the presence of another SL process / grant at the WTRU that may be used to transmit the dropped SL transmission. For example, the WTRU may apply an offset related to the presence of another SL grant / process at the WTRU. The offset may meet the latency requirements of the SL transmission in question. The WTRU may be configured with an offset such that, for example, if the additional SL grant meets the latency requirements associated with the SL transmission, the UL is preferred.

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

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

[0169] In an embodiment, the WTRU may be configured with an SL threshold and / or an UL threshold. The SL threshold may be, for example, in terms of LCH priority and / or or QoS parameters associated with the SL. The UL threshold may be, for example, in terms of LCH priority and / or QoS parameters associated with the UL.

[0170] The WTRU may compare the UL priority or SL priority to a corresponding threshold. In one example, the WTRU may compare the UL priority to a configured UL threshold. The WTRU may compare the SL priority to a configured SL threshold. The WTRU may make a determination based on, for example, whether the SL or UL transmission is below the corresponding threshold. The WTRU may make a determination based on whether the SL or UL transmission is above the corresponding threshold.

[0171] The WTRU may prioritize the UL transmission, for example, if the UL transmission is above the UL threshold and the SL transmission is below the SL threshold.

[0172] The WTRU may prioritize the SL transmission. The WTRU may prioritize the SL transmission, for example, if the SL transmission is above the SL threshold and the UL transmission is below the UL threshold.

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

[0174] The WTRU may notify the network of a dropped transmission based on a condition. In one example, the WTRU may notify the network of a dropped transmission based on a condition, e.g., exceeding both the UL and SL thresholds. The condition may be associated with a priority of the data with respect to a threshold. The WTRU may notify the network to drop one of the transmissions for some condition associated with a priority of the data with respect to (e.g., each) threshold. In an embodiment, the WTRU may select a UL transmission and notify the network that the SL transmission will be dropped, e.g., if the priority of the UL transmission exceeds a threshold and the priority of the SL transmission exceeds a threshold. The WTRU may select a SL transmission and notify the network that the UL transmission will be dropped, e.g., if the priority of the UL transmission exceeds a threshold and the priority of the SL transmission exceeds a threshold.

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

[0176] The WTRU may perform resource reselection. The WTRU may perform resource reselection, for example, if an SL is dropped, for example, according to a prioritization rule.

[0177] 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 under the condition that the SL prioritization threshold is configured. The UL prioritization threshold may be used under the condition that the UL prioritization threshold is configured. For example, a tiered priority rule may exist where the WTRU evaluates a first criterion (e.g., whether a prioritization value associated with an SL LCG is lower than the SL prioritization threshold, as shown at 304 in FIG. 3), then evaluates a second criterion (e.g., whether at least an UL LCG has a prioritization value that is greater than or equal to the UL prioritization threshold, as shown at 306 in FIG. 3, and whether an UL prioritization threshold is configured), then evaluates a third criterion (e.g., the size of the UL grant and a determination of whether to prioritize the SL LCG), etc. The WTRU may prioritize UL or SL, for example, depending on which criterion is met. The tiering criteria may have an order or priority. In one example, if the first tier criterion is met, the WTRU may not need to check the second, third tier criterion, and so on.

[0178] In one example, the WTRU may determine which link to prioritize (e.g., UL or SL) based on, for example, whether the priority of a transmission on a first link exceeds a first threshold. The WTRU may determine which link to prioritize based on, for example, a comparison of the priority of a second link to a second threshold if the condition is not met (e.g., the transmission on the first link is of a priority less than or equal to the first threshold). The first threshold may be, for example, a QoS-related or priority-related threshold associated with the transmission of the first link. The QoS-related or priority-related first threshold may include, for example, one or more of PPPP, PPPR, LCH priority, 5QI, PQI, and / or the like. The second threshold may be, for example, a QoS-related or priority-related threshold associated with the transmission of the second link. The QoS-related or priority-related second threshold may include, for example, PPPP, PPPR, LCH priority, 5QI, PQI, and / or the like. The first and second thresholds 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 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.

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

[0180] The WTRU may determine prioritization associated with first RAT UL and first RAT SL data. The first RAT may include NR. In one example, the WTRU may be configured with a UL LCH threshold and a SL LCH threshold. The WTRU may compare UL transmissions to the UL LCH threshold. The WTRU may prioritize UL over SL if, for example, the highest priority LCH multiplexed into the UL MAC PDU is higher priority than the UL LCH threshold. The WTRU may verify transmission priority if, for example, the highest priority LCH multiplexed into the UL MAC PDU is not higher priority than the UL LCH threshold. The WTRU may compare SL transmissions to the SL LCH threshold. The WTRU may prioritize SL over UL if, for example, the highest priority SL LCH multiplexed into the SL PDU is higher priority than the SL LCH threshold. For example, the WTRU may prioritize an SL LCG (e.g., over an UL LCG) 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 greater than the UL prioritization threshold. The prioritization value associated with the SL LCG may be indicated by the prioritization value of the SL LCG's highest priority LCH. The WTRU may prioritize UL over SL, for example, if the highest priority SL LCH multiplexed into the SL PDU is of a priority equal to or less than the SL LCH threshold. The WTRU may prioritize an UL LCG (e.g., over an SL LCG) if the prioritization value associated with at least one (e.g., each) SL LCG is equal to or greater than the SL prioritization threshold. The WTRU may prioritize an SL LCG in response to determining that the prioritization value associated with the SL LCG is lower than the SL prioritization threshold and the UL prioritization threshold is not configured.

[0181] The WTRU may determine a prioritization including 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 based on, for example, a priority associated with an LCH reported in the BSR. The WTRU may determine the priority of the UL BSR / SR based on, for example, a highest priority LCH reported in the BSR (relative to a configured UL threshold) and may apply one or more rules (e.g., as provided herein). The WTRU may determine the priority of the UL BSR / SR based on, for example, an LCH that triggers an SR. The WTRU may determine the priority of the UL BSR / SR based on, for example, a highest priority LCH that triggered an SR (e.g., relative to a configured UL threshold) and may apply one or more rules (e.g., as provided herein). The WTRU may prioritize an UL transmission if, for example, the highest priority UL LCH reported in the UL BSR (e.g., or for which the WTRU triggered an SR) is a higher priority than the UL LCH threshold. The WTRU may prioritize UL over SL, for example, if the highest priority LCH multiplexed into the UL MAC PDU is of higher priority than the UL LCH threshold. The WTRU may check transmission priority, for example, if the highest priority LCH multiplexed into the UL MAC PDU is of a priority equal to or less than the UL LCH threshold. The WTRU may prioritize SL over UL, for example, if the highest priority SL LCH multiplexed into the SL PDU is of higher priority than the SL LCH threshold; otherwise, the WTRU may prioritize UL over SL.

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

[0183] The WTRU may determine a prioritization associated with data of 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 a prioritization associated with data of the first RAT UL and the second RAT SL (e.g., or second RAT UL / first RAT SL) based on, for example, an LCH threshold and / or a PPPP threshold. In an embodiment, the WTRU may be configured with a UL LCH threshold and a SL PPPP threshold. The WTRU may compare UL transmissions with the UL LCH threshold. The WTRU may prioritize UL over SL, for example, if the highest priority LCH multiplexed into the UL MAC PDU is of a higher priority than the UL LCH threshold. The WTRU may confirm SL transmission priority, for example, if the highest priority LCH multiplexed into the UL MAC PDU is of a priority equal to or less than the UL LCH threshold. The WTRU may prioritize SL over UL, for example, if the highest priority SL PPPP multiplexed into the SL PDU is of higher priority than the SL PPPP threshold; otherwise, the WTRU may prioritize UL over SL.

[0184] The WTRU may determine a prioritization associated with second RAT UL and first RAT SL data. 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) an SL LCH threshold. The WTRU may recognize that the WTRU does not use (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, the WTRU may prioritize SL over UL if the highest priority SL LCH multiplexed into the SL PDU is higher priority than the SL LCH threshold; otherwise, the WTRU may prioritize UL over SL.

[0185] The WTRU may determine a prioritization associated with the UL SR / BSR of the first RAT UL and the second RAT SL. The WTRU may determine the prioritization associated with the UL SR / BSR of the first RAT UL and the second RAT SL based on, for example, 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 UL transmissions to the UL LCH threshold. The WTRU may prioritize UL over SL, for example, if the highest priority LCH reported in the UL BSR (e.g., or that triggered the UL SR) has a higher priority than the UL LCH threshold. The WTRU may confirm SL transmission priority, for example, as indicated by a prioritization value equal to or greater than the UL LCH threshold, if the highest priority LCH reported in the UL BSR (e.g., or that triggered the UL SR) does not have a higher priority than the UL LCH threshold. The WTRU may prioritize SL over UL, for example, if the highest priority SL PPPP multiplexed into the SL PDU is of higher priority than the SL PPPP threshold; otherwise, the WTRU may prioritize UL over SL.

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

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

[0188] One or more examples herein may be used in connection with BSRs for UL and / or SL. Buffer status may be reported based on a determination of whether to prioritize the SL BLR. 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, for example, based on the priority of the LCG associated with the UL BSR and the priority of the LCG associated with the SL BSR. For example, as shown in FIG. 3, at 302, a determination may be made whether to prioritize the SL LCG based on the UL prioritization threshold, provided that the SL prioritization threshold and the UL prioritization threshold are configured. At 304, a determination may be made whether a prioritization value associated with the SL LCG is lower than the SL prioritization threshold. At 306, a determination may be made to determine whether at least the UL LCG has a prioritization value that is greater than or equal to the UL prioritization threshold, provided that the UL prioritization threshold is configured. At 308, the determination of whether to prioritize the SL LCG (or UL LCG) may be used to determine whether to prioritize the SL BSR (or UL BSR).

[0189] The WTRU may determine whether to prioritize the UL BSR or the SL BSR based on, for example, 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 based on, for example, the priority of the data reported in the corresponding BSR.

[0190] The WTRU may determine whether to prioritize the UL BSR or the SL BSR based on, for example, the higher (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. The WTRU may prioritize the UL BSR, for example, if the highest priority LCG for the UL is higher than the highest priority LCG for the SL. The WTRU may prioritize the SL BSR, for example, if the highest priority LCG for the SL is higher than the highest priority LCG for the UL. The WTRU may be (pre-)configured with which links to prioritize. The behavior (e.g., logic) of which links to prioritize may be pre-determined. The WTRU may be (pre-)configured with which links to prioritize (e.g., UL or SL) or the behavior of which links to prioritize may be pre-determined, for example, if the highest priority LCGs for the SL and UL are the same LCG.

[0191] The WTRU may determine whether to prioritize the UL BSR or the SL BSR based on, for example, an equivalence mapping. The equivalence 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 embodiment, the WTRU may be configured with an equivalence mapping between the SL LCG and the UL LCG. For example, the equivalence mapping may include SL LCG2 = UL LCG4, etc. The WTRU may be configured with an equivalence mapping between the SL LCH and the UL LCH. The equivalence mapping may be (pre-)configured (e.g., by RRC signaling). The WTRU may perform prioritization (e.g., as described herein) by using the equivalence mapping to determine a higher priority between the SL and the UL based on, for example, a higher priority between the LCGs. The WTRU may perform prioritization (e.g., as described herein) by using the equivalence mapping to determine a higher priority between the SL and the UL based on, for example, a higher priority between the LCHs.

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

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

[0194] The WTRU may be configured with thresholds that can be used to determine whether to prioritize the SL BSR or the UL BSR. If prioritized, the SL BSR is prioritized over the UL BSR. In one example, the WTRU may be configured with one or more thresholds associated with the SL and / or UL (e.g., as shown at 402 in FIG. 4 and 302 in FIG. 3). For example, the WTRU may be configured with a threshold for the SL LCG. The WTRU may prioritize the SL LCG over the UL LCG, for example, if the SL BSR contains data associated with an LCG that is higher (e.g., of a higher priority) than the SL LCG threshold. The WTRU may be configured with a threshold for the UL LCG. The WTRU may prioritize the UL LCG over the SL LCG, for example, if the UL BSR contains data associated with an LCG that is higher (e.g., of a higher priority) than the UL LCG threshold. The WTRU may be configured with a threshold for the UL LCG and a threshold for the SL LCG. The UL BSR may be prioritized, for example, if the UL BSR contains data associated with an LCG that is higher in priority than the UL prioritization threshold, and the SL BSR does not contain data that is higher in priority than the SL LCG threshold. The reverse scenario for the SL may result in the SL being prioritized. The SL BSR may be prioritized, for example, if the SL BSR contains data associated with an LCG that is higher in priority than the SL LCG threshold (e.g., as shown at 304 in FIG. 3 ) and the UL BSR does not contain data that is higher in priority than the UL prioritization threshold (e.g., as shown at 306 in FIG. 3 ). For example, the WTRU may determine whether each UL LCG has a prioritization value that is greater than or equal to the UL prioritization threshold, and determine whether to prioritize the SL LCG (or UL LCG) based on whether each UL LCG has a prioritization value that is greater than or equal to 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 (pre-)configured to prioritize the BSRs, or may use another decision rule (e.g., as described herein), for example, if the SL BSR and the UL BSR contain data that exceed their respective thresholds.

[0195] One or more examples herein may be used in combination to determine whether to prioritize the SL BSR or the UL BSR. In one example, the WTRU may be configured to prioritize according to a first rule (e.g., based on one 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., according to another example described herein).

[0196] 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 based on, for example, relative priorities within the corresponding BSRs. The WTRU may determine the type and / or 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 (e.g., as shown at 302 in FIG. 3 or 404 in FIG. 4), the LCH to be reported in the UL BSR (e.g., as shown at 308 in FIG. 3), the size of the grant used to transmit the BSR (e.g., as shown at 308 in FIG. 3), and / or the presence of additional UL grants available (e.g., that may satisfy latency requirements associated with SL data). The additional UL grants may include configured grants.

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

[0198] The WTRU may be configured to determine whether to transmit a shortened or truncated BSR. The WTRU may shorten or shorten the SL BSR and / or the UL BSR. The WTRU may be configured to transmit a relatively short BSR format. The WTRU may not transmit a relatively long BSR format. In one example, the WTRU may transmit buffer status associated with (e.g., only) the highest priority LCG. As shown at 310 in FIG. 3, the buffer status may be reported based on a determination of whether to prioritize the SL BSR. The WTRU may be configured to transmit a shortened or truncated BSR format. For example, the WTRU may transmit buffer status associated with (e.g., only) a subset of LCGs using a shortened or truncated BSR. The buffer status associated with the subset of LCGs may, for example, start with the highest priority and may have decreasing priority order. In one example, the prioritized and shortened SL BSR may include a (e.g., prioritized) first SL LCG and a (e.g., prioritized) second SL LCG when the UL grant size is sufficient for the first and second SL LCGs. As shown in 406 of FIG. 4, the buffer status may be reported based on a determination of whether to include an LCG in the buffer status report. Whether to include an LCG in the buffer status report may be determined based on the size of the UL grant, the priority associated with the LCG, the SL prioritization threshold, and, if the UL prioritization threshold is configured as shown in 404 of FIG. 4, the UL prioritization threshold. If the size of the UL grant is sufficient for (e.g., all) prioritized SL LCGs, the buffer status report may include, for example, UL LCGs in addition to the prioritized SL LCGs. The size of the UL grant may be sufficient for (e.g., prioritized) SL BSRs and several UL LCGs associated with UL BSRs. The buffer status report may include several UL LCGs associated with (e.g., prioritized) SL BSRs and UL BSRs.

[0199] The WTRU may determine whether to transmit a shortened or shortened BSR based on, for example, whether the grant is large enough and / or whether additional UL grants are present. The WTRU may (e.g., initially) determine whether to transmit a shortened or shortened BSR for the SL and / or UL based on, for example, the grant size and / or the presence / absence of additional UL grants. The WTRU may utilize a non-shortened BSR for the SL BSR and / or UL BSR, for example, if the grant is large enough. The WTRU may utilize a non-shortened BSR for the SL BSR and / or UL BSR, for example, if the UL grant is large enough to include a non-shortened SL BSR and a non-shortened UL BSR (e.g., and other MAC CEs with higher priority than the SL BSR and / or UL BSR). The size of the UL grant used to transmit the BSR may be insufficient for at least one (e.g., all) prioritized SL LCG if the SL BSR is not prioritized. The WTRU may transmit (e.g., make a decision to transmit) shortened or shortened BSRs for the SL and / or UL, for example, if the size of the UL grant is insufficient. The WTRU may shorten the SL BSR (e.g., not prioritized), and the shortened BSR may include as many SL LCGs as allowed by the size of the UL grant (e.g., even if not prioritized). For example, the shortened 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. The WTRU may assume to transmit shortened or shortened BSRs for the SL and / or UL, for example, if the grant is not large enough to include the unshortened SL BSR and the unshortened UL BSR.The WTRU may transmit (e.g., assume to transmit) shortened or abbreviated BSRs for SL and / or UL, for example, if the grant is not large enough to transmit an unshortened UL BSR and an unshortened SL BSR, and if any additional grants (e.g., zero or more) configured in the WTRU do not meet the timing requirements associated with the buffered data to be reported by the SL BSR.

[0200] The WTRU may be configured to determine which BSRs to shorten or shorten. The WTRU may determine which SL BSRs and / or UL BSRs to shorten / shorten and / or how to shorten / shorten the SL BSRs and / or UL BSRs (e.g., if BSR shortening is used). In an embodiment, the WTRU may shorten / shorten a BSR that is triggered later. The WTRU may determine whether to send a shortened BSR or a shortened long BSR depending on, for example, the amount of data in the grant (e.g., the size of the UL grant). The WTRU may include a short BSR for a link with a BSR if, for example, the number of bits in the grant is insufficient (e.g., not enough). The WTRU may include a short BSR for a link with a later-triggered BSR if the number of bits remaining in the grant (e.g., after including the BSR for the earlier-triggered link (in addition to other higher priority MAC CEs)) is large enough to include a short BSR (e.g., only this one). The WTRU may include as many LCGs as possible, e.g., because there would otherwise be space in the shortened / shortened BSR.

[0201] The WTRU may shorten / shorten a BSR based on the priority of the LCH / LCG and / or a configured LCH / LCG threshold. In an embodiment, the WTRU may shorten (e.g., decide to shorten) the UL and / or SL BSR, for example, to transmit buffer status associated with the highest priority logical channel. The WTRU may shorten (e.g., decide to shorten) the UL and / or SL BSR, for example, to transmit buffer status associated with an LCH / LCG that exceeds an LCH / LCG threshold. In an embodiment, the WTRU may shorten (e.g., decide to shorten) the SL BSR or the UL BSR and transmit (e.g., decide to transmit) buffer status of (e.g., only) the LCH / LCG of the SL / UL BSR that exceeds a configured LCH / LCG threshold. The WTRU may perform (e.g., decide to perform) the shortening using, for example, prioritized links. The WTRU may perform (e.g., decide to perform) the shortening if, for example, the BSR is prioritized relative to other BSRs (e.g., based on a configured LCG / LCH threshold). The WTRU may implement (e.g., decide to implement) shortening (e.g., based on a configured LCG / LCH threshold), for example, if (e.g., only if) the SL BSR is prioritized over the UL BSR. The WTRU may implement (e.g., decide to implement) shortening (e.g., based on a configured LCG / LCH threshold), for example, if (e.g., only if) the UL BSR is prioritized over the SL BSR. The WTRU may implement (e.g., decide to implement) shortening for a link (e.g., only one link). The WTRU may implement shortening (e.g., based on a configured LCG / LCH threshold), for example, if the SL is prioritized (e.g., except when the UL is prioritized). The WTRU may shorten a BSR based, for example, on the remaining size of the UL grant for a non-prioritized BSR (e.g., UL or SL).

[0202] The WTRU may transmit a shortened or truncated SL BSR, e.g., to include as many SL LCGs as possible in the SL BSR. The WTRU may transmit a shortened or truncated UL BSR, e.g., to include as many UL LCGs as possible in the UL BSR. The WTRU may transmit a shortened or truncated SL BSR and a shortened or truncated UL BSR, e.g., to include as many SL or UL LCGs as possible in the SL and UL BSRs allowed based on the grant size. The WTRU may be configured to include the highest priority LCG in its SL and UL BSRs, for example, to include the LCGs in order of decreasing priority (eg, considered across both UL and SL).

[0203] The WTRU may shorten / shorten a BSR for the UL or SL, for example, if the corresponding BSR includes the highest priority LCG. The WTRU may shorten / shorten a 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 lower priority than any LCGs that would be transmitted in the SL BSR. The WTRU may shorten a BSR for the SL, for example, if the corresponding BSR includes the highest priority LCG (e.g., across both SL and UL) and the remaining LCGs have lower priority than any LCGs that would be transmitted in the UL BSR.

[0204] The WTRU may, for example, transmit a short BSR for the SL based on various conditions and may shorten the SL BSR. The WTRU may (e.g., always) transmit a short BSR for the SL and shorten the SL BSR, for example, as determined by including the buffer status of the LCG (e.g., in order of highest priority).

[0205] The WTRU may transmit a short BSR for the SL and the UL. In one example, the WTRU may transmit a short BSR for the SL and the UL (e.g., always).

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

[0207] The WTRU may be configured to perform prioritization among multiple (e.g., potential) SL transmissions (e.g., SL / SL prioritization). The WTRU may be configured to avoid (e.g., attempt to avoid) collisions between different UL / SL transmissions (e.g., using various approaches). The WTRU may be configured to avoid (e.g., attempt to avoid) collisions between different UL / SL transmissions, for example, using an approach that multiplexes UL and SL transmissions.

[0208] A WTRU may transmit on UL and SL on the same resource (e.g., slot). In one example, a WTRU may be configured with a condition for transmitting on SL and UL (e.g., without dropping and / or prioritizing SL / UL transmissions). The WTRU may transmit on UL and SL, for example, if the condition is met. The WTRU may prioritize between UL / S (e.g., as described herein), for example, if the condition is not met. The WTRU may transmit UL and SL, for example, if the SL transmission includes (e.g., only) a PSF CH transmission. The WTRU may transmit UL and SL, for example, if the UL transmission includes (e.g., only) an SR transmission. The WTRU may transmit UL and SL, for example, if the UL transmission includes (e.g., only) an SRS transmission.

[0209] Various conditions for transmission 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 within the same slot / TTI. The conditions for transmitting signals on the UL and SL within the same resource (e.g., slot) may include, for example, one or more of: at least one symbol may overlap for UL and SL transmission within the resource; some (e.g., all) symbols of the UL transmission may overlap with the SL transmission; and / or no symbols of the UL transmission may overlap with the SL transmission.

[0210] The conditions may include or relate to, for example, one or more (e.g., combinations thereof) of NW indication, type of UL / SL transmission, duration (time) of transmission on either UL or SL, QoS / priority associated with the transmission, carrier distance between UL and SL transmission, frequency gap between UL and SL transmission, transmit power, power control scheme, and / or the like.

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

[0212] The condition may be related to the type of UL / SL transmission. UL / SL transmission in the same slot may allow UL and / or SL transmission of a certain (e.g., selected) type, or a combination of UL and / or SL transmission. UL / SL transmission in the same slot may not allow UL / SL transmission of another (e.g., unselected) type. The type of transmission may be related to one or more of a physical channel, a transport channel, or a logical channel associated with the UL / SL transmission. The WTRU may allow transmission in the same slot in UL and SL, for example, if the SL transmission is associated with a PSFCH (e.g., PSFCH only) transmission. The WTRU may allow transmission in the same slot in UL and SL, for example, if the SL transmission is associated with a PSFCH and / or if the UL transmission is a PUSCH. For example, the WTRU may allow transmission in the same slot in UL and SL if the SL transmission is associated with a PSFCH only and / or if the UL transmission is a PUSCH only (without a PUCCH transmission). The WTRU may, for example, allow an UL transmission to be transmitted in the same slot in the UL and SL if (e.g., if and only if) the UL transmission is associated with a certain (e.g., selected, indicated, or configured) set of logical channels. The WTRU may, for example, allow an UL transmission to be transmitted in the same slot in the UL and SL if (e.g., if and only if) the UL transmission is not associated with a certain (e.g., network-configured) set of logical channels.

[0213] The condition may be related to the duration (time) of transmission on the UL or SL. UL / SL transmissions in the same slot may be possible (e.g., may occur), for example, if the UL / SL transmission durations are limited in time. UL / SL transmissions in the same slot may be possible (e.g., may occur), for example, if a combination of UL / SL transmission durations is limited in time. A WTRU may transmit on both the UL and SL if, for example, the SL transmission (e.g., PSFCH) is limited to (e.g., a maximum of) N symbols. N may depend on the characteristics of the UL data (e.g., as described herein). A WTRU may transmit on both the UL and SL if, for example, the SL transmission (e.g., PSFCH) is limited to (e.g., a maximum of) N symbols and / or the UL transmission is limited to (e.g., a maximum of) M symbols. M may depend on the characteristics of the SL data.

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

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

[0216] The condition may be related to the frequency gap between the UL and SL transmissions. The WTRU may transmit in the same slot on the UL and SL, for example, depending on whether the frequency resources for the UL and SL transmissions have a gap (e.g., larger than X RBs). The gap may be, for example, a frequency gap in terms of resource blocks. X RBs may be pre-determined, configured, or indicated (e.g., in downlink control information (DCI)).

[0217] The condition may be related to transmit power. The WTRU may, for example, transmit in the same slot on the UL and SL depending on whether the WTRU has reached 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, and / or the like. The WTRU may, for example, not transmit UL and SL transmissions in the same slot if the transmissions (e.g., of the UL and SL) reach (e.g., or exceed) the maximum transmit power. The WTRU may, for example, transmit in the same slot on the UL and SL if the UL and SL transmissions cannot reach the maximum transmit power. The condition may apply, for example, such that the total SL and UL transmissions cannot reach the maximum transmit power of the WTRU.

[0218] The condition may be related to a power control scheme. The WTRU may, for example, transmit in the same slot on the UL and SL depending on the power control scheme (e.g., used for sidelink transmission). The WTRU may be configured to use one or more power control schemes for the sidelink. In an embodiment, a first power control scheme may use Pc,max, and the WTRU may transmit a signal on the SL using Pc,max power. The second power control scheme may be based on pathloss, and the transmit power may be determined based on (e.g., as a function of) the pathloss (e.g., DL pathloss and / or SL pathloss). The WTRU may not, for example, perform UL and SL transmissions in the same slot if the SL power control scheme is based on the first power control scheme. The WTRU may, for example, perform UL and SL transmissions in the same slot if the SL power control scheme is based on the second power control scheme. In an embodiment, the WTRU may not, for example, perform UL and SL transmissions in the same slot if the WTRU uses a first power control scheme (e.g., Pc,max).

[0219] The WTRU may modify the planned / granted transmission format to enable transmission on the UL and / or SL. The WTRU may change the planned or granted transmission format to, for example, enable transmission on the UL and SL in the same slot. The planned transmission format may be selected by the WTRU for the SL, for example. The granted transmission format may be granted by the network for the UL, for example. Changing the transmission format may include, for example, one or more of: changing the UL / SL MCS, performing puncturing on the UL / SL transmission, changing the TB size, and / or transmitting an alternate TB. For example, the WTRU may be provided with an UL grant from the network. The WTRU may receive an SL transmission associated with an SL unicast. For example, the SL unicast may use a PSFCH transmission in the same slot as the UL transmission. The WTRU may perform puncturing of the UL transmission, for example, upon determining that the WTRU can transmit simultaneously on the UL and SL (e.g., PSFCH). The WTRU may be configured with the amount of puncturing to be performed. The amount of puncturing to be performed may be based, for example, on the required / selected number of symbols for the PSFCH. The WTRU may select an MCS for the initial transmission in the SL. The WTRU may change / modify the MCS for a retransmission in the SL, for example, if the SL retransmission collides with a UL transmission in the same slot. The WTRU may change / modify the MCS for a retransmission in the SL, for example, if the SL retransmission collides with a UL transmission in the same slot and the WTRU decides to transmit SL and UL in the same slot.

[0220] The WTRU may inform the network and / or peer WTRUs about transmissions on UL and / or SL. The WTRU may inform the NW and / or peer WTRUs of expected format changes. The WTRU may inform the network or peer WTRUs about transmissions on UL and SL in the same slot. The indication may include (e.g., indicate), for example, that SL and UL may be transmitted in the same slot and / or one or more of different SL / UL formats selected by the WTRU (e.g., to ensure UL and SL transmissions in the same slot). The indication may include one or more of a puncture level, a different MCS, a different TB size, and / or the like. The WTRU may provide the indication, for example, using (e.g., explicit) signaling. In one example, the WTRU may include an indication to the network in uplink control information (UCI). The WTRU may include an indication to a peer WTRU in sidelink control information (SCI). The WTRU may provide the indication implicitly. The WTRU may, for example, scramble a demodulation reference signal (DMRS) differently depending on whether the WTRU transmits on the UL and SL of the same slot and / or depending on different (e.g., selected) transmission formats for the UL / SL. The WTRU may, for example, use different orthogonal cover codes (OCCs) for the DMRS depending on whether the WTRU transmits on the UL and SL of the same slot and / or depending on different (e.g., selected) transmission formats for the UL / SL.

[0221] The WTRU may, for example, report expected PSFCH transmissions to the network. The WTRU may report expected PSFCH transmission timing to the network. The report may be used by the network to appropriately configure UL grant parameters, for example, if an UL grant collides with a PSFCH transmission. The report may be used by the network to schedule an UL grant while avoiding a PSFCH transmission. The report may be used by the network to appropriately configure UL grant parameters, for example, if an UL grant collides with a PSFCH transmission and / or for the network to schedule an UL grant while avoiding a PSFCH transmission. In one example, a WTRU may provide PSFCH resource timing associated with a planned (e.g., periodic) transmission by another (e.g., peer) WTRU, for example, following reservation of periodic resources by the peer WTRU. The WTRU may provide the network with a set of periodic PSFCH resources (which may correspond, for example, to HARQ feedback resources for the peer WTRU's planned transmission). The WTRU may provide the network with a periodic set of PSFCH resources, e.g., following another WTRU's transmission associated with a HARQ feedback enabled periodic transmission. The WTRU may notify the network of a change in PSFCH resources, e.g., upon a change in the periodicity / offset / resources (e.g., subchannels) associated with the periodic transmission. The WTRU may report a different set of PSFCH resources and / or report a different set of PSFCH resources (e.g., the current set) if, for example, the WTRU detects a change in one or more of the periodicity, offset, or resources of another WTRU's periodic transmissions (e.g., associated with a particular sidelink process), the WTRU receives an indication from another WTRU that the other WTRU may change its periodicity / offset / resources associated with its periodic transmissions, and / or the WTRU may receive a change in its HARQ configuration (e.g., from another WTRU or a gNB).

[0222] In one example, the WTRU may provide an indication of the timing of the PSFCH transmission, e.g., after receiving an SL transmission without a reservation. The WTRU may provide the indication (e.g., for Mode 1) to the network (e.g., with an ACK / NACK indication). For example, the WTRU may implicitly / explicitly indicate the PSFCH timing to the network with the ACK / NACK indication. The WTRU may implicitly / explicitly indicate the PSFCH timing to the network, e.g., using one or more of: signaling (e.g., in the ACK / NACK indication) the timing, the relative timing from the ACK / NACK indication of the PSFCH transmission, or the received data timing; signaling (e.g., in the ACK / NACK indication) the data priority and / or QoS (e.g., or any additional information used by the network to determine the timing distance from the PSFCH to the PSFCH), e.g., if the WTRU signals the received data timing; e.g., selecting resources for the ACK / NACK indication to the network (e.g., (pre)configured or pre-determined) 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 (e.g., for Mode 2) that may be used to indicate such information. The dedicated UCI information may, for example, be configured to explicitly / implicitly indicate the PSFCH and / or the received data timing (e.g., as described herein).

[0223] The WTRU may report the expected PSFCH transmission timing to the network, for example, in one or more (e.g., a combination of) an RRC message, a MAC CE, and / or a UCI. In one example, the WTRU may be configured with UCI resources for signaling a relative offset (e.g., from a UCI transmission) for the planned PSFCH transmission timing and / or 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 the SL BSR or MAC CE. The WTRU may send a sidelink UE assistance RRC message (e.g., or a similar RRC message) to the network, for example, when another WTRU initiates a periodic or reserved transmission. The WTRU may report the PSFCH timing (e.g., of the WTRU) associated with the periodic transmission of another WTRU.

[0224] The WTRU may be configured to avoid (e.g., attempt to avoid) collisions between different UL / SL transmissions using one or more approaches, including, for example, a resource selection decision. The WTRU may perform a resource selection procedure (e.g., taking into account configured SR resources). For example, the WTRU may consider the time / frequency location of the configured SR resources (e.g., SL or UL SR resources) in the resource selection procedure, thereby avoiding or reducing the possibility of collisions between UL SR transmissions and SL transmissions. The WTRU may, for example, 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 for Mode 2 resource selection. The WTRU may prioritize (e.g., in Mode 2 resource selection) the selection of resources that do not collide with the configured SR resources (e.g., or a subset of the configured SR resources). For example, the WTRU may assign a higher weight to the selection of resources that do not collide with SR resources.

[0225] The WTRU may implement a behavior (e.g., excluding SR resources and / or preferring non-SR resources) for (e.g., only for) SR resources that may be associated with, for example, SL or UL, SR resources associated with a (e.g., specific) QoS, and / or the like. The WTRU may implement a behavior for (e.g., only for) SR resources associated with an SL or UL. For example, the WTRU may exclude SR resources for only the SL or UL. The WTRU may implement a behavior for (e.g., only for) SR resources that may be associated with a (e.g., specific, selected, configured, indicated) QoS. The WTRU may, for example, exclude SL SR resources that may be associated with a logical channel whose QoS is higher than the QoS of data that the WTRU may transmit on the selected sidelink resource. The WTRU may, for example, exclude SL SR resources that may be associated with a logical channel whose QoS is higher than one or more (pre-)configured values.

[0226] The WTRU may be configured to avoid (e.g., attempt to avoid) collisions using one or more approaches, including, for example, the use of multi-RAT dual connectivity (MR-DC). The WTRU may change the UL split between a master cell group (MCG) and a secondary cell group (SCG), for example, based on SL traffic. In one example, the WTRU may change the WTRU's split of UL transmissions between the MCG and SCG, for example, based on the presence of SL traffic. The WTRU may be configured with one or more split DRBs between the MCG and SCG. The WTRU may change the relative amount of traffic transmitted via the MCG or SCG for the (e.g., split) DRBs based on the presence of SL traffic. The WTRU may change (e.g., decide to change) the amount of traffic between the MCG and SCG based on, for example, one or more of the QoS associated with the SL traffic, the QoS associated with the UL traffic, congestion in the SL, WTRU capability limitations, and / or the like.

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

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

[0229] The WTRU may change (e.g., decide to change) the amount of traffic between the MCG and SCG based on congestion in the SL. For example, the WTRU may change (e.g., allow to change) the UL split between the MCG and SCG.

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

[0231] The WTRU may change the UL split between the MCG and SCG upon the occurrence of one or more of the following triggers: the WTRU may receive SL data associated with one or more LCHs; the amount of SL data (e.g., associated with one or more LCHs) may exceed a threshold; and / or the like.

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

[0233] The WTRU may change the active SL control / scheduling CG. A WTRU configured with a DC may receive SL scheduling (e.g., Mode 1 scheduling) from one of multiple (e.g., two) cell groups. The WTRU may decode SL scheduling (e.g., only) on the CG associated with the active SL control / scheduling at a given time. In one example, the WTRU may change the active SL control / scheduling cell group (CG) from the MCG or SCG, or vice versa. The WTRU may receive signaling (e.g., explicit) from the network to change the CG associated with monitoring SL scheduling. The WTRU may receive the signaling in one or more of an RRC configuration message, a MAC CE, a DCI message, and / or 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 (e.g., similar to DCI 5A) used to schedule SL. The SL DCI may include a field (e.g., a dedicated field) to indicate the DCI change. The signaling (or signaling message) may indicate which CG to change to for the active SL scheduling CG, for example in case of multi-connectivity.

[0234] In one example, the WTRU may (e.g., implicitly) determine the active scheduling CG based on, for example, one or more of the Uu bearer configuration, the QoS associated with the bearer configuration, and / or the LCG configuration. The WTRU may determine the CG associated with the active SL monitoring to be, for example, a CG for which no URLLC bearer (e.g., an MCG bearer or an SCG bearer) is configured. The WTRU may determine the CG associated with the active SL monitoring to be, for example, a CG for which the bearer is associated with one or more of a relatively low (e.g., lowest) QoS, a relatively small / large (e.g., minimum / maximum) allowed transmission duration, a relatively small / large (e.g., minimum / maximum) configured grant periodicity, etc. The WTRU may change the scheduled CG of the active SL based on, for example, a trigger related to UL discontinuous reception (DRX). The WTRU may move the scheduled active CG to another CG, for example, if the WTRU enters DRX on the first CG.

[0235] FIG. 3 shows an example of implementing uplink and sidelink operations with prioritization. Embodiments and other embodiments disclosed herein may operate according to embodiment 300 shown in FIG. 3. Performance of uplink and sidelink (e.g., simultaneous) operation may include one or more of 302-310 (e.g., as described herein). At 302, a determination may be made whether to prioritize an SL LCG based on an UL prioritization threshold, provided that an SL prioritization threshold and an UL prioritization threshold are configured. At 304, a determination may be made whether a prioritization value associated with an SL LCG is lower than the SL prioritization threshold. At 306, a determination may be made to determine whether at least an UL LCG has a prioritization value that is greater than or equal to the UL prioritization threshold, provided that an UL prioritization threshold is configured. At 308, a determination may be made whether to prioritize an SL BSR based on the size of the UL grant and the determination whether to prioritize an SL LCG. At 310, a buffer status may be reported based on the determination whether to prioritize an SL BSR.

[0236] FIG. 4 shows an example of implementing uplink and sidelink operations with prioritization. Embodiments and other embodiments disclosed herein may operate according to embodiment 400 shown in FIG. 4. Performance of uplink and sidelink (e.g., simultaneous) operation may include steps 402-406. At 402, a determination may be made that a sidelink (SL) priority threshold is configured. At 404, a determination may be made as to whether an LCG will be included in the BSR based on the size of the UL grant, the priority associated with the LCG, the SL prioritization threshold, and, provided the UL prioritization threshold is configured, the UL prioritization threshold. At 406, buffer status may be reported based on the determination as to whether the LCG will be included in the buffer status report.

[0237] While features and elements are described above in particular combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware embodied in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) 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 internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. 1. A wireless transmit / receive unit (WTRU), comprising: determining that a scheduling request (SR) is triggered, In the case of an uplink (UL) SR, the SR is prioritized over SL data based at least on a priority associated with a UL logical channel (LCH) that triggers the SR and a UL prioritization threshold; In the case of a sidelink (SL) SR, the SR is prioritized over the SL data based at least on a priority associated with the SR being higher than a priority associated with a medium access control protocol data unit (MAC PDU) associated with the SL data. And, transmitting the SR, the SR having priority over the SL data; 10. A WTRU comprising: a processor configured to execute:

2. 10. The WTRU of claim 1, wherein, in the case of the SL SR, the processor is further configured to determine a priority associated with the SR based on a highest priority among one or more SL LCHs that trigger the SR.

3. 10. The WTRU of claim 1, wherein, in the case of the UL SR, the processor is further configured to determine a priority associated with the SR based on a highest priority among one or more UL LCHs that trigger the SR.

4. 2. The WTRU of claim 1, wherein the processor is further configured to determine that the SR and SL data cannot be transmitted simultaneously, and in the case of the SL SR, prioritizing the SR over the SL data is further based on determining that the SR and SL data cannot be transmitted simultaneously.

5. 2. The WTRU of claim 1, wherein the processor is further configured to determine that resources associated with the SR and resources associated with the SL data overlap, and in the case of the SL SR, prioritizing the SR over the SL data is further based on determining that resources associated with the SR and resources associated with the SL data overlap.

6. The WTRU of claim 1 , wherein the processor is further configured to determine that a SL LCH triggers a SL Buffer Status Report (BSR) and the SL SR.

7. The WTRU of claim 1 , wherein the processor is further configured to determine that the UL LCH that triggers the SR includes UL data.

8. The processor: receiving an UL grant; determining whether to prioritize an SL Buffer Status Report (BSR) over an UL BSR based on the size of the UL grant; The WTRU of claim 1 further configured to perform:

9. The WTRU of claim 8 , wherein the processor is further configured to determine whether to shorten the SL BSR based on a size of the UL grant.

10. determining that a scheduling request (SR) is triggered, In the case of an uplink (UL) SR, the SR is prioritized over SL data based at least on a priority associated with a UL logical channel (LCH) that triggers the SR and a UL prioritization threshold; In the case of a sidelink (SL) SR, the SR is prioritized over the SL data based at least on a priority associated with the SR being higher than a priority associated with a medium access control protocol data unit (MAC PDU) associated with the SL data. And, transmitting the SR, the SR having priority over the SL data; A method comprising:

11. 11. The method of claim 10, wherein in the case of the SL SR, the method further comprises determining a priority associated with the SR based on a highest priority among one or more SL LCHs that trigger the SR.

12. 11. The method of claim 10, wherein in the case of the UL SR, the method further comprises determining a priority associated with the SR based on a highest priority among one or more UL LCHs that trigger the SR.

13. 11. The method of claim 10, further comprising determining that the SR and SL data cannot be transmitted simultaneously, and in the case of the SL SR, prioritizing the SR over the SL data is further based on determining that the SR and SL data cannot be transmitted simultaneously.

14. 11. The method of claim 10, wherein the method further includes determining that resources associated with the SR and resources associated with the SL data overlap, and wherein in the case of the SL SR, prioritizing the SR over the SL data is further based on determining that resources associated with the SR and resources associated with the SL data overlap.

15. The method of claim 10 , further comprising determining that a SL LCH triggers a SL Buffer Status Report (BSR) and the SL SR.

Images