WO2020033628A1

WO2020033628A1 - Sidelink resource selection and control

Info

Publication number: WO2020033628A1
Application number: PCT/US2019/045628
Authority: WO
Inventors: Chunxuan Ye; Fengjun Xi; Kyle Jung-Lin Pan; Frank La Sita; Tuong Duc HOANG; Martino M. Freda; Tao Deng; Aata EL HAMSS; Benoit Pelletier
Original assignee: Idac Holdings, Inc
Priority date: 2018-08-08
Filing date: 2019-08-08
Publication date: 2020-02-13

Abstract

Implementations are disclosed for the coexistence of sidelink resources associated with a network and sidelink resources associated with a WTRU (e.g., a vehicle). The coexistence may be facilitated by communicating information associated with scheduled resources, e.g., time information. The information may facilitate scheduling that mitigates interference, for example interference that may occur if a network scheduled resource and a WTRU scheduled resource that overlap are used. Implementations for Uu to control a sidelink(s) are disclosed. For example, a WTRU may determine, based on one or more V2X applications, a sidelink RAT from a plurality of sidelink RATs. The plurality of sidelink RATs may comprise a LTE sidelink RAT and a NR sidelink RAT. The WTRU may determine a resource selection mode based on a quality of service (QoS) of a packet. The WTRU may then transmit, based on the resource selection mode, the packet via the sidelink RAT.

Description

SIDELINK RESOURCE SELECTION AND CONTROL

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 62/716,037, filed August 8,

2018, U.S. Provisional Application No. 62/736,261 , filed September 25, 2018, U.S. Provisional Application No. 62/736,563, filed September 26, 2018, and U.S. Provisional Application No. 62/841 ,011 , filed April 30,

2019, the contents of which are hereby incorporated herein by reference in their entirety.

BACKGROUND

[0002] Use cases for fifth generation (5G) wireless communication systems may include Enhanced Mobile Broadband (eMBB), Massive Machine Type Communications (mMTC) and Ultra Reliable and Low latency Communications (URLLC). 5G also may contemplate transportation scenarios, e.g., vehicle-to- everything (V2X) use cases. Different use cases may focus on different requirements such as higher data rate, higher spectrum efficiency, low power and higher energy efficiency, lower latency and higher reliability. A wide range of spectrum bands, e.g., from 700 MHz to 80 GHz, may be considered for a variety of deployment scenarios.

[0003] Vehicular communication (e.g., V2X) is a mode of communication whereby wireless

transmit/receive units (WTRUs) (e.g., vehicles) may communicate with each other, e.g., via sidelinks. Example scenarios for V2X operations may include: in-coverage scenario and out of coverage scenario. In an in-coverage scenario, WTRUs (e.g., vehicles) may receive assistance from the network to start transmitting and receiving V2X messages. In an out of coverage scenario, WTRUs (e.g., vehicles) may use some pre-configured parameters to start transmitting and receiving V2X messages. WTRUs (e.g., vehicles) may be equipped with New Radio (NR) and Long Term Evolution (LTE) radio access technologies (RATs). If the WTRU is under the in-coverage scenario, NR and LTE V2X may be controlled by NR and LTE Uu interfaces. Techniques may be disclosed herein for the case where a WTRU (e.g., vehicle) is equipped with two RATs (e.g., NR and LTE) that allow the NR Uu or LTE Uu to control both RATs. This may support basic safety services and advanced services offered by the NT V2X and LTE V2X. SUMMARY

[0004] Systems, methods, and instrumentalities are disclosed herein associated with the coexistence of sidelink resources associated with a network and sidelink resources associated with a WTRU (e.g., a vehicle). The coexistence may be facilitated by communicating information associated with scheduled resources, e.g., time information associated with scheduled resources. The information may facilitate scheduling that mitigates interference, for example interference that may occur if a network scheduled resource and a WTRU scheduled resource that overlap are used, e.g., on a same RAT or on different RATs.

[0005] A WTRU, such as a vehicle, may receive a configuration (e.g., from a network). The configuration may instruct the WTRU to report an overlapping resource associated with sidelink communication. For example, the WTRU may receive information indicating a time location of resource(s) associated with the network (e.g., a pool of network scheduled resources). The WTRU may determine if resource(s) scheduled for use by the WTRU overlap in time with the resource(s) associated with the network (e.g. the pool of network resources). If there is a time overlap between the resources, the WTRU may send a report to the network. The report may indicate the resource(s) scheduled by the WTRU that overlap with the network scheduled resource(s). The report may include one or more of the following: time information associated with the resource(s) scheduled by the WTRU or priority information associated with data that is associated with the resource(s) scheduled by the WTRU. The WTRU may send the report periodically and/or if a trigger condition occurs. A WTRU may send such report if (e.g., only if) the overlap occurs with resources which are actually scheduled by the NW, e.g., for the same WTRU.

[0006] Systems, methods, and instrumentalities are described herein for Uu to control a sidelink(s). For example, a WTRU may determine, based on one or more V2X applications, a sidelink RAT from a plurality of sidelink RATs. The plurality of sidelink RATs may comprise an LTE sidelink RAT and a NR sidelink RAT. The WTRU may determine a resource selection mode based on a quality of service (QoS) of a packet. The resource selection mode may indicate a resource allocation that includes a dynamic resource allocation, an activation/deactivation-based resource allocation, and a radio resource control (RRC)-configured resource allocation. The WTRU may transmit, based on the resource selection mode, the packet via the sidelink RAT. The WTRU may also determine, based on the one or more V2X applications, a second sidelink RAT from the plurality of sidelink RATs.

[0007] LTE sidelink and NR sidelink (e.g., for V2X) may support multiple modes. An LTE network- scheduled mode may be referred to as Mode 3. An LTE WTRU-scheduled mode may be referred to as Mode 4. An NR network-scheduled mode may be referred to as Mode 1 (e.g., NR Mode 1). An NR WTRU- scheduled mode may be referred to as Mode 2 (e.g., NR Mode 2). Mode 3 may refer to LTE Mode 3 herein. Mode 4 may refer to LTE Mode 4 herein. Mode 1 may refer to NR Mode 1 herein. Mode 2 may refer to NR Mode 2 herein.

[0008] Reliability based resource selection may be provided, e.g., for mode 4 WTRUs. The reliability based resource selection may use or consider one or more of the following: a reliability indication, a reliability value associated with data, or a number of repetitions that depends on ProSe per-packet reliability (PPPR).

[0009] Latency based resource selection may be provided, e.g., for mode 4 WTRUs. The latency based resource selection may use or consider one or more of the following: a latency indication, or a latency value associated with data. The reliability based resource selection and latency based resource selection may be performed and/or used separately or in combination.

[0010] In-device coexistence implementations may be provided, e.g., for mode 4 WTRUs. For example, to support cases where a single WTRU supports LTE sidelink and NR sidelink.

[0011] Resource pool ranking is provided, e.g., for mode 4 WTRU resource selection. For example, certain transmissions or retransmissions may be more protected.

[0012] In-device coexistence mechanism(s) may be provided, e.g., between NR SL and LTE SL. One or more of the following may apply: WTRU reporting in LTE mode 3 and/or NR mode 1 ; LTE mode 4 and/or NR mode 2 WTRU resource selection in dual connectivity; dynamic priority-based selection between NR SL RX and LTE SL TX; or channel adjustment for in-device coexistence

BRIEF DESCRIPTION OF THE DRAWINGS

[0013] FIG. 1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented;

[0014] FIG. 1 B is a system diagram illustrating an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1 A according to an embodiment;

[0015] FIG. 1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG. 1 A according to an embodiment;

[0016] FIG. 1 D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG. 1 A according to an embodiment;

[0017] FIG. 2 shows an exemplary mode 4 WTRU resource selection, e.g., based on reliability requirements. [0018] FIG. 3 shows an exemplary mode 4 WTRU resource selection, e.g., based on latency requirements.

[0019] FIG. 4 shows an example of determining the priority of an NR sidelink resource compared to an LTE sidelink resource.

[0020] FIG. 5 shows an example of determining the priority of an NR sidelink resource compared to an LTE sidelink resource.

[0021] FIG. 6 shows an example of determining the priority of an NR sidelink resource compared to an LTE sidelink resource;

[0022] FIG. 7 shows an example of determining the priority of an NR sidelink resource compared to an LTE sidelink resource.

[0023] FIG. 8 illustrates exemplary overlapping periodic resources between LTE SL and NR SL.

[0024] FIG. 9 illustrates exemplary NR type-1 resources and NR type-2 resources.

[0025] FIG. 10 is a diagram illustrating an example V2X communication system in which one or more disclosed embodiments may be implemented; and

[0026] FIG. 11 is a diagram illustrating an example set of reserved subframes by a WTRU to a network entity.

DETAILED DESCRIPTION

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

[0028] As shown in FIG. 1A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104/113, a ON 106/115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a "station” and/or a "STA”, may be configured to transmit and/or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a UE.

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

[0030] 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 wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a wireless service to a specific geographical area that may be relatively fixed or that may change over time. The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and/or receive signals in desired spatial directions.

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

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

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

[0034] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR Radio Access , which may establish the air interface 1 16 using New Radio (NR).

[0035] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by 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., a eNB and a gNB).

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

[0037] The base station 1 14b in FIG. 1 A may be a wireless router, Flome Node B, Flome eNode B, or access point, for example, and may utilize any suitable F AT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR etc.) to establish a picocell or femtocell. 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 be required to access the Internet 110 via the CN 106/115.

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

[0039] 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 the other networks 112. The PSTN 108 may include circuit- switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common

communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and/or the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 112 may include wired and/or wireless communications networks owned and/or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104/113 or a different RAT.

[0040] 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. 1 A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0041] FIG. 1 B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1 B, the WTRU 102 may include 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, among others. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0042] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. 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. 1 B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0043] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the 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 an embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and/or receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

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

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

[0046] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the 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, and the like. 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 a home computer (not shown).

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

[0048] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102.

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

[0049] 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 e-compass, a satellite transceiver, a digital camera (for photographs and/or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and/or Augmented Reality (VR/AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors, the sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and/or a humidity sensor.

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

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

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

[0053] 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, and the like. As shown in FIG. 1 C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0054] The CN 106 shown in FIG. 1 C 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 are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator.

[0055] 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 serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. 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.

[0056] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the 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 user planes during inter- eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

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

[0058] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may 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 the other networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.

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

[0060] In representative embodiments, the other network 112 may be a WLAN.

[0061] 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 an access or an interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic in to and/or out of the BSS. Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. The traffic between STAs within a BSS may be considered and/or referred to as peer-to- peer traffic. The peer-to-peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS may use an 802.11 e DLS or an 802.1 1z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an "ad- hoc” mode of communication.

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

[0063] High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

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

[0065] Sub 1 GHz modes of operation are supported by 802.1 1 af and 802.11 ah. The channel operating bandwidths, and carriers, are reduced in 802.1 1 af and 802.11 ah relative to those used in 802.11 h, and 802.1 1 ac. 802.1 1 af supports 5 MHz, 10 MHz and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11 ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non- TVWS spectrum. According to a representative embodiment, 802.11 ah may support Meter Type

Control/Machine-Type Communications, such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and/or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0066] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.11 h, 802.11 ac, 802.11 af, and 802.11ah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and/or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode.

In the example of 802.11 ah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and/or other channel bandwidth operating modes. Carrier sensing and/or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode), transmitting to the AP, the entire available frequency bands may be considered busy even though a majority of the frequency bands remains idle and may be available.

[0067] In the United States, the available frequency bands, which may be used by 802.11 ah, are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11 ah is 6 MHz to 26 MHz depending on the country code.

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

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

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

[0071] 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 the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration WTRUs 102a, 102b, 102c may communicate with/connect to gNBs 180a, 180b, 180c while also communicating with/connecting to another RAN such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In the non-standalone configuration, eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and/or throughput for servicing WTRUs 102a, 102b, 102c.

[0072] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, support of network slicing, dual connectivity, interworking between NR and E- UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1 D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

[0073] The CN 1 15 shown in FIG. 1 D 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 are depicted as part of the CN 1 15, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator. [0074] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 1 13 via an N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of NAS signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized 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 1 13 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and/or non-3GPP access technologies such as WiFi.

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

[0076] The UPF 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 1 10, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and the like.

[0077] The CN 115 may facilitate communications with other networks. For example, the CN 1 15 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 1 15 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to the other networks 1 12, which may include other wired and/or wireless networks that are owned and/or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to a local Data Network (DN) 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b. [0078] In view of Figures 1A-1 D, and the corresponding description of Figures 1A-1 D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and/or any other device(s) described herein, may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and/or to simulate network and/or WTRU functions.

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

[0080] The one or more emulation devices may perform the one or more, including all, functions while not being implemented/deployed as part of a wired and/or wireless communication network. For example, the emulation devices may be utilized in a testing scenario in a testing laboratory and/or a non-deployed (e.g., testing) wired and/or wireless communication network in order to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and/or wireless communications via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and/or receive data.

[0081] 3GPP deployment scenarios may include indoor hotsport, dense urban, rural, urban macro, high speed, etc. On top of these deployment scenarios, there may be use cases such as: Enhanced Mobile Broadband (eMBB), Massive Machine Type Communications (mMTC) and Ultra Reliable and Low Latency Communications (URLLC). Different use cases may focus on different requirements such as higher data rate, higher spectrum efficiency, low power and higher energy efficiency, lower latency and higher reliability.

[0082] Use cases may include transportation scenarios, for example vehicle-to-everything (V2X) use cases, e.g., 3GPP V2X use cases. In V2X standardization process, several use cases may include several groups, for example four use case groups may be: vehicle platooning, extended sensors, advanced driving and remote driving. Different use case groups may have different latency, reliability and/or data rate requirements. Example requirements (e.g., tightest requirements) are illustrated in Table 1. Table 1

[0083] A use case within each use case group may have different latency, reliability and/or data rate requirements. For example, the "lower degree of automation” in the video sharing scenario of the extended sensors use case group may have a latency requirement of 50 ms, a reliability requirement of 90% and a data rate requirement of 10 Mbps. While, for example, a "Higher degree of automation” in sensor information sharing between WTRUs supporting V2X application may have a latency requirement of 3 ms, a reliability requirement of 99.999% and a data rate requirement of 25 Mbps.

[0084] V2X transmission modes may be used, e.g., 3GPP transmission modes. For example, a vehicle may be in a first transmission mode, e.g., transmission mode 3 (e.g., mode 3 user) or may be in transmission mode 4 (e.g., mode 4 user). A mode 3 user (e.g., device, vehicle, etc.) may use (e.g., directly use) the resources allocated by a base station for sidelink (SL) communication among vehicles or between vehicle and a pedestrian (e.g., LTE network-scheduled mode). A mode 4 user (e.g., device, vehicle, etc.) may obtain a list of candidate resources allocated by a base station, and may select a resource among the candidate resources for its SL communication (e.g., LTE WTRU-scheduled mode). In NR V2X, the mode 1 user may be similar to the mode 3 user in LTE V2X (e.g., network-scheduled mode). In NR V2X the mode 2 user may be similar to the mode 4 user in LTE V2X (e.g., WTRU-scheduled mode). "User” or "WTRU” may refer to a vehicle (user). Mode 4 may be a mode/configuration indicated to the WTRU, e.g., by a network device via an IE. Mode 4 may be a configuration associated with the WTRU selecting transmission resource(s).

[0085] Control information may be used for V2X. For example, DCI Format 5A and/or SCI format 1 may be used.

[0086] The DCI format 5A (e.g., LTE) may be used for the scheduling of PSCCH, and may include several SCI format 1 fields used for the scheduling of PSSCH. The payload of DCI format 5A may include one or more of the following: carrier indicator (e.g., 3 bits); lowest index of the subchannel allocation to the initial transmission (e.g., flog₂₍Ar_s¾ _channei) bits); SCI format 1 fields, such as frequency resource location of initial transmission and retransmission and/or time gap between initial transmission and retransmission; or SL index (e.g., 2 bits), where, in examples, this field is present for (e.g., only for) cases with TDD operation with uplink-downlink configuration 0-6.

[0087] When the format 5A CRC is scrambled with SL-SPS-V-RNTI, one or more of the following fields may be present: SL SPS configuration index (e.g., 3 bits); or activation/release indication (e.g., 1 bit).

[0088] If the number of information bits in format 5A that are mapped onto a given search space is less than the payload size of format 0 that are mapped onto the same search space, zeros may be appended to format 5A until the payload size equals that of format 0 including padding bits appended to format 0. If the format 5A CRC is scrambled by SL-V-RNTI and if the number of information bits in format 5A that are mapped onto a given search space is less than the payload size of format 5A with CRC scrambled by SL- SPS-V-RNTI that are mapped onto the same search space and format 0 is not defined on the same search space, zeros may be appended to format 5A until the payload size equals that of format 5A with CRC scrambled by SL-SPS-V-RNTI.

[0089] SCI format 1 (e.g., LTE) may be used for the scheduling of PSSCH. The payload of SCI format 1 may include one or more of the following: priority (e.g., 3 bits); resource reservation (e.g., 4 bits); frequency resource location of initial transmission and retransmission (e.g., flog₂(Ar_s¾_chamiel(Ar_s¾_{cliamiel -}i- i)/2)] ); time gap between initial transmission and retransmission (e.g., 4 bits); modulation and coding scheme (e.g., 5 bits); retransmission index (e.g., 1 bit); or reserved information bits may be added until the size of SCI format 1 is equal to 32 bits, reserved bits may be set to zero.

[0090] In mode 4 (e.g., LTE mode 4), a WTRU may select resource(s). V2X resource selection of mode 4 may include one or more of the following.

[0091] As requested by higher layers in sub-frame n, the WTRU may determine a set of resources to report to higher layers for PSSCH transmission, which may be based on one or more of the following parameters received from a higher layer: L_subCH the number of sub-channels to be used for PSSCH transmission in a sub-frame; P_rsVp-Tx· the resource reservation interval; prio_TX the priority in SCI format 1 ; or C_rese(: the number of sub-frames in one set of resources for transmission opportunities of PSSCH.

[0092] A candidate single-subframe resource for PSSCH transmission R_{X y} may be a set of L_subC^ contiguous sub-channels with starting sub-channel index x in subframe ty^L, where ty^L is within the time interval [n + T₁, n + T₂], where T₁ < 4 and T_2min(prio_TX ) is provided by higher layers for prio_TX or 20 £ T₂ £ 100. The total number of the candidate single-subframe resources is M_totai.

[0093] WTRU may monitor sub-frames

^excePt when its own transmissions occur, where

= n if sub-frame n belongs to the allowed sub-frame pool for sidelink transmission, or

is the first sub-frame after n belonging to the allowed sub-frame pool for sidelink transmission.

[0094] The parameter Th_{a b} may be set to the value indicated by the i-th entry of higher layer parameter "SL-ThresPSSCH-RSRP-list”, where i = a * 8 + b + 1.

[0095] The set S_A may be initialized to the union of the candidate single-subframe resources (e.g., all the candidate single-subframe resources). The set S_B may be initialized to an empty set.

[0096] The WTRU may exclude any candidate single-subframe resource R_{x y} from S_A, if, for example: the WTRU does not monitor sub-frame t|^L (e.g., as above); and/or there is an integer j, such that y +

00, k is a value in the higher layer parameter "restrictResourceReservationPeriod”, and q = 1

with Q =

[0097] The WTRU may exclude a candidate single-subframe resource R_{x y} from S^, if, for example: the WTRU receives an SCI format 1 in sub-frame

and the "Resource reservation” field and "Priority” field in SCI format 1 are P_rsvp-RX and prio_RX ; PSSCH-RSRP measurement according to the received SCI format 1 is higher than Th_{pri0 pri0} \ and/or there in an integer y, such that y +j * Pr_sv_p-t_c = m +

Pstep * Prsvp—Rx * wherey

[0098] If the remaining candidate resource(s) in S_A is smaller than 0.2M_tota then one or more of the following may be repeated: the set S_A may be initialized to the union of the candidate single-subframe resources (e.g., all the candidate single-subframe resources); or the set S_B may be initialized to an empty set. This may be repeated with h_{a b} increased, e.g., by 3 dB.

[0099] For each remaining candidate resource in S_A, the metric E_xy may be the linear average of the sensed RSSI measured in sub-channels x + k for k = 0, ... , L_subCH— 1 in the monitored sub-frames, e.g., sub-frames

[0100] The WTRU may move the candidate single-subframe resource R_{x y} with the smallest metric E_{X V} from S_A to S_B until the cardinality of S_B is greater than or equal to 0.2 M_total. The set S_B may be reported to a higher layer.

[0101] In the above mode 4 WTRU resource selection, the priority of the data may be considered in terms of the parameters prio_TX and prio_RX. This priority level may be related to the latency requirement of the data.

[0102] In sidelink (e.g., LTE Release 15), the carrier aggregation may be up to 8 carrier frequencies. These frequencies (e.g., one, some, or all) may be used to support a single service or different services. The actual number of carriers may be restricted by hardware limitations. For example, a WTRU may have fewer number of TX RF chains than the number of configured TX carriers, or the TX chain switching time may be too large to tune the RF for neighbor sub-frames, or a WTRU cannot fulfill the RF requirements due to PSD imbalance, etc.

[0103] For a mode 4 WTRU (e.g., LTE mode 4), the resource selection may be implemented per-carrier, e.g., independently. If the WTRU is limited to transmitting on the selected sub-frame, a selected resource may be dropped. The carrier resource selection order may be according to the ascending value of ProSe Per-Packet. Priority (PPPP). If the WTRU performs the resource selection for a certain carrier, a sub-frame (e.g., any sub-frame) of that carrier may be excluded from the reported candidate resource set if using that sub-frame exceeds its TX capability limitation under the given resource reservation in the other carriers.

[0104] An LTE mode 4 WTRU resource selection with different reliability and latency requirements may be provided. There are various use cases defined for NR V2X. These use cases may be categorized to 4 use case groups. Some of the use cases may require high reliability while other use cases may require low reliability. A data packet within each use case may have a different reliability requirement than another data packet within this same use case.

[0105] The data reliability and latency requirements may not be considered in the resource selection of mode 4 WTRU in LTE V2X. The resource selected by a mode 4 WTRU may collide with resources of other V2X transmissions, which may lead to data transmissions unreliability. Data reliability requirements may be considered in the resource selection for a mode 4 WTRU.

[0106] Prioritized selection of NR/LTE sidelink transmissions may be provided. A single WTRU may support LTE sidelink transmissions and NR sidelink transmissions. It is possible that the WTRU has limited TX capability. The possible reasons include the limited number of available RF chains, RF chain switching time, RF requirements, etc. The WTRU may not be able to transmit the LTE sidelink and NR sidelink simultaneously or close to simultaneously. For a mode 4 WTRU, the resource selection may be done for LTE sidelink and NR sidelink independently. The WTRU may find that the selected resource for LTE sidelink transmissions and NR sidelink transmissions may lead to a time domain conflict on the Tx, which may not be supported by the WTRU's TX capability. The WTRU may have to give up one of the two transmissions and the selected resources. Implementation(s) may be provided associated with which sidelink resources and transmissions may be discarded.

[0107] Half-duplex constraints may be addressed. A vehicle could be deployed with LTE V2X and NR V2X communication modules. The simultaneous usage of LTE sidelink and NR sidelink may be supported in a single vehicle, which is in the dual connectivity mode. It is possible that a LTE V2X sidelink channel and a NR V2X sidelink channel may be in the same band (e.g., ITS band of 5.9 GHz). In such a case, the adjacent channel leakage ratio (ACLR) may be large so that the transmissions on one RAT may impact the reception on the other RAT, e.g., the half-duplex constraints may cause some problems for in-device coexistence. Coordinated LTE V2X sidelink and NR V2X sidelink mechanisms, signaling, etc. may be provided, e.g., to support the dual connectivity WTRU.

[0108] Reliability based resource selection for mode 4 WTRUs may be provided. Some data may require more reliable delivery than other data. The resource selection collision for mode 4 WTRU may impact the reliable delivery of the data. Data reliability requirements may be considered in resource selection, e.g., to reduce the chance of resource selection collision of data with higher reliability requirements. One or more implementations herein may support resource selection based on data reliability requirements.

[0109] Although a single sub-frame may be used as a basis in the following discussions on mode 4 WTRU resource selection, implementations herein are not restricted to a single sub-frame. For example, a slot or sub-slot could be applied. A sub-slot may be a mini-slot or a non-slot or a symbol-based time resource as a unit of resource in time domain, e.g., to support more refined granularity and NR V2X flexible sidelink frame structure (e.g., slot-based and non-slot/symbol-based SL frame structure) for NR V2X low latency and flexible scheduling/transmission requirements.

[0110] A reliability indication may be used. In LTE V2X sidelink transmissions, the priority of data may be indicated in SCI, e.g., as the 3-bit field of "Priority.” A parameter ProSe Per-Packet Reliability (PPPR) may be defined in a higher layer, e.g., indicating the reliability requirement of the data. Note that PPPR may have a value range, e.g., of 1 to 8, where a higher value may represent a lower reliability requirement for that message. This PPPR parameter may have an impact on the mode 4 WTRU resource selection. It may be included in the SCI as a field of "Reliability.” This field may be a number of bits, e.g., 1 bit, 2 bits or 3 bits. Table 2 provides examples for a 1-bit field.

Table 2

Table 3 provides examples for a 2-bit field.

Table 3

The reliability requirement values in the above may depend on the actual reliability from different use cases.

[0111] We may use“re/" to indicate the reliability field value. The larger“rel" value implies the higher reliability requirement of the data.

[0112] Resource selection based on reliability may be provided. The resource selection may include using the inputs of the reliability value of the data. One or more of the following may apply.

[0113] The WTRU may (e.g., as requested by higher layers in sub-frame n) determine a set of resources to report to a higher layer for PSSCH transmissions, which may be based on one or more of the following parameters, which in examples may be received from a higher layer: L_subCH the number of sub channels to be used for PSSCH transmission in a sub-frame; P_rsVp-Tx· the resource reservation interval; prio_TX\ the priority in SCI format 1 ; rel_TX the reliability in SCI format 1 ; or C_rese(: the number of sub- frames in one set of resource for transmission opportunities of PSSCH.

[0114] A candidate slot (or sub-slot with contiguous or non-contiguous symbols, or TTI) resource for PSSCH transmission R_{x y} may be a set of L_subCH contiguous sub-channels with starting sub-channel index x in subframe t_y ^L, where t_y ^L may be within the time interval [n + T₁, n + T₂\, where T₁ £ and T2mm(_.P^rio _Tx_> ^rehx) ^maY provided by higher layers for prio_TX rel_TX or 20 £ T₂ £ 100. The total number of the candidate single-subframe resources may be M_totai.

[0115] The higher the reliability requirements of the data (e.g., "Reliability” field of SCI or rel_TX has a larger value), the larger the value of T_2min(prio_TX, rel_TX) may be at a given prio_TX. The lower the reliability requirements of the data (e.g., rel_TX has a smaller value), the smaller the value of

T_2min(p^rio_TX, rel_TX) may be at a given prio_TX. For a larger value of rel_TX, a larger

T_2min(p^ri°_Tx, re x) ^maY result in a larger set of candidate single-subframe resources, which may lead to less chance of collisions, as well as a larger coded bit size, and a more reliable transmission.

[0116] The WTRU may monitor sub-frames

^excePt when its own transmissions occur, where

is the first sub-frame after n belonging to the allowed sub-frame pool for sidelink transmission. The integer value of A may be dependent on the reliability requirement rel_TX, e.g., instead of a constant value.

[0117] A larger value of rel_TX may correspond to a larger value of A, and a smaller value of rel_TX may correspond to a smaller value of A. For a larger value of rel_TX, a larger A may result in a longer time spectrum sensing, which may ensure a lesser chance of collision and a more reliable transmission.

[0118] The parameter Th_{a b}(rel_TX) may be set to the value indicated by the i-th field in high layer parameter“SL— ThresPSSCH— RSRP— Reli— List" at the given rel_TX value, where i = a * 8 + b + 1.

[0119] A larger value of rel_TX may lead to a smaller value of Th_{a b}(rel_TX) and a smaller value of rel_TX may lead to a larger value of Th_{a b}(rel_TX). In other words, Th_{a b}(rel_{TX 1} ) > Th_{a b}(rel_{TX 2}), if ^reWx_,i £ ^reWx,2 F°^r a larger value of rel_TX, a smaller Th_{a b} may impose a loose criterion to exclude a candidate resource. This may result in a smaller set of candidate resources with lower interference level. The data transmission may be more reliable.

[0120] The higher layer parameter“SL— ThresPSSCH— RSRP— Reli— List" may be defined in the "SL-CommTxPoolSensingConfig” IE, as an illustration, with the following example:

[0121] The parameter Th_{a b} (rel_TX ) may depend on (e.g., only on) the reliability level of the data to be transmitted by the current vehicle. In examples, this parameter Th_{a b} (rel_TX, rel_RX) may depend on the reliability level of the data from other vehicles. A similar scheme as above may be applied.

[0122] The set S_A may be initialized to the union of the candidate single-subframe resources (e.g., all the candidate single-subframe resources). The set S_B may be initialized to an empty set.

[0123] The WTRU may exclude a candidate single-subframe resource R_{x y} from S_A, for example if one or more of the following: the WTRU does not monitor sub-frame t|^L in the above, e.g., associated with the monitoring of sub-frames

such that y +

a value in the higher layer parameter "restrictResourceReservationPeriod”, and q = 1

with Q = may be a function of C_resei and rel_TX.

Cr_esei = 10*SL_RESOURCE_RESELECTION_COUNTER, where

"SL_RESOURCE_RESLECTION_COUNTER” may be a high layer parameter. The constant 10 may be used for the case that the same resource may be still maintained after the counter reaches 0. A larger value of rel_TX may lead to a larger value of C_r'_esel. This may reduce the chance of sub-frame conflict between the transmissions of data with a higher reliability requirement and other data for half-duplex transmissions. For example, we may set C_r'_esel = C_resei * rel_TX.

[0124] In examples, the WTRU may exclude a candidate single-subframe resource R_{x y} from S_A, if one or more of the following: the WTRU receives an SCI format 1 in sub-frame t^, and the "Resource reservation” field and "Priority” field in SCI format 1 are P_rsvp-RX and prio_RX\ a PSSCH-RSRP measurement according to the received SCI format 1 is higher than Th_{pri0 pri0} rel_TX) in the above, e.g., associated with the monitoring of sub-frames '^{n an} integer

j_> such that

with Q = C_Pesel may be a function of C_resei and rel_TX. A larger value of rel_TX

may lead to a larger value of C_r'_esel. This may reduce the chance of sub-frame conflict between the transmissions of data with higher reliability requirement and data transmissions from other vehicles. For example, we could set C_r'_esel = C_resei * rel_TX. C_r'_esel ; C_r'_esel may be a function of C_reseU rel_TX and prio_TX. A higher priority data may lead to a smaller value of C_r'_esel. This may increase the chance of a candidate resource being selected, and may increase the chance that the current message is transmitted promptly. [0125] In examples, the WTRU may exclude candidate single-subframe resource R_{x y} from S^, if one or more of the following: the WTRU receives an SCI format 1 in sub-frame t^, and the "Resource reservation” field, "Priority” field and "Reliability” field in SCI format 1 are P_rsVp-Rx , prio_RX and rel_RX\ a PSSCH-RSRP measurement according to the received SCI format 1 is higher than

Th_{pri0TX Pri0RX}(rel_TX, rel_RX) in the above, e.g., associated with the monitoring of sub-frames ^tn^-_A-p_step’ ¹h'-_A·r_5(br+n - > ^Ih'- ’ ^{or there is an} integer;, such that y + ; * P;_svp.TX = m + P_step * Prsvp-Rx * R, where ; C_resel may

have the same or similar definition as above.

[0126] If the remaining candidate resources in S_A is smaller than B_t M_tota then we may repeat the feature where the set S_A may be initialized to the union of the candidate single-subframe resources (e.g., all the candidate single-subframe resources), and, the set S_B may be initialized to an empty set, where Th_{a b} may be increased, e.g., by 3 dB. The value B_t may depend on rel_TX. A larger value of rel_TX may lead to a smaller value of B_t . This may enhance the quality of the candidate resources in the remaining S_A, in terms of the interference level of the candidate resources.

[0127] For each remaining candidate resource in S_A, the metric E_{x y} may be the linear average of the sensed RSSI measured in sub-channels x + k for k = 0, ... , L_subCH— 1 in the monitored sub-frames in the above, e.g., associated with the monitoring of sub-frames

[0128] The WTRU may move the candidate single-subframe resource R_{x y} with the smallest metric E_{x y} from S_A to S_B until the cardinality of S_B is greater than or equal to B₂ M_totai. The set S_B may be reported to higher layers.

[0129] The value B₂ may depend on rel_TX. A larger value of rel_TX may lead to a smaller value of B₂. This may enhance the quality of the candidate resources in the remaining S_B, in terms of the interference level of the candidate resources.

[0130] FIG. 2 shows an exemplary mode 4 WTRU resource selection, e.g., based on the given reliability requirements.

[0131] A number of repetitions may depend on ProSe Per-Packet Reliability (PPPR). In NR V2X, the number of retransmissions may be more than 1 , e.g., to increase the reliability level of PSSCH transmissions. A resource allocation scheme may be provided for NR PSSCH (re)transmissions.

[0132] The usage of more than 1 retransmission may be associated with the ProSe Per-Packet Reliability (PPPR). PPPR may have a value range of 1 to 8, where a higher value may represent a lower reliability requirement for that message. Depending on the PPPR values, a WTRU may determine the number of retransmissions. The number of retransmissions may decrease with the increase of PPPR values. For example, the number of retransmissions may be 0 if thre 1 < PPPR < 8; the number of retransmissions may be 1 if thre 2 < PPPR < thre 1; the number of retransmissions may be 2 if 1 < PPPR < thre 2. The selection of the number of retransmissions may be associated with ProSe Per- Packet Priority (PPPP), and may be jointly associated with PPPR. The number of retransmissions may increase for higher priority packets.

[0133] Latency based resource selection for mode 4 WTRUs may be provided. This may include providing a latency indication and/or a resource selection based on latency.

[0134] The latency requirement of the data may not be considered in the resource selection discussed above. Some data may require lower latency delivery than other data. The resource selection collision for mode 4 WTRU may impact the low latency delivery of the data. Data latency requirements may be considered in the resource selection, e.g., to reduce the resource selection collision chance for data with lower latency requirements. Implementations herein may support resource selection based on data latency requirements.

[0135] A latency indication may be provided. The data latency requirements may be included in the SCI, e.g., as a field of "latency.” This field may be a number of bits, e.g., 1 bit, 2 bits or 3 bits. Table 4 provides an example for a 1-bit field.

Table 4

Table 5 provides examples for a 2-bit field.

Table 5

Table 6 provides examples for a 3-bit field.

Table 6

[0136] The latency requirement values in the above tables may depend on the actual latency from different use cases,

[0137] In the follow discussions, we shall use“lat" to indicate the latency field value. A larger“lat" value implies a larger latency requirement of the data.

[0138] Resource selection based on latency may be provided. For example, resource selection may be determined taking into account the inputs of the latency value of the data. One or more of the following may apply.

[0139] As requested by higher layers in sub-frame n, the WTRU may determine the set of resources to report to higher layers for PSSCH transmission, e.g., based on one or more of the following parameters received from higher layers: L_subCH the number of sub-channels to be used for PSSCH transmission in a sub-frame; P_rsvp-Tx· the resource reservation interval; prio_TX\ the priority in SCI format 1 ; lat_TX\ the data latency requirements in SCI format 1 ; or C_rese(: the number of sub-frames in one set of resource for transmission opportunities of PSSCH.

[0140] A candidate single-subframe resource for PSSCH transmission R_{X y} may be a set of L_subC^ contiguous sub-channels with starting sub-channel index x in subframe ty^L, where ty^L may be within the time interval

may be provided by higher layers for prio_TX lat_TX, or 20 £ T₂ < 100. The total number of the candidate single-subframe resources may be M_totai.

[0141] The lower the latency requirements of the data (e.g., "Latency” field of SCI or lat_TX has a smaller value), the smaller the value of T_2min(prio_TX, lat_TX ) at a given prio_TX. The higher latency requirements of the data (e.g., lat_TX has a larger value), the larger the value of T_2min(prio_TX, lat_TX) at a given prio_TX.

[0142] The WTRU may monitor sub-frames

^excePt when its own transmissions occur, where

is the first sub-frame after n belonging to the allowed sub-frame pool for sidelink transmission. Instead of a constant value, the integer value of A may be dependent on the latency requirement lat_TX.

[0143] A larger value of lat_TX may correspond to a larger value of A, and a smaller value of lat_TX may correspond to a smaller value of A. For a larger value of lat_TX, a larger A may result in a longer time spectrum sensing, which may be unnecessary for lower latency transmissions.

[0144] The parameter Th_{a b}(lat_TX) may be set to the value indicated by the i-th field in high layer parameter“SL— ThresPSSCH— RSRP— Latency— List" at the given lat_TX value, where i = a * 8 + b + l.

[0145] A smaller value of lat_TX may correspond to a smaller value of Th_{a b}{lat_TX) and a larger value of lat_TX may correspond to a larger value of Th_{a b}(lat_TX). In other words, Th_{a b}(lat_{TX 1}) ³

Th_{a b}{lat_{TX 2} ), if l_{TX 1} ³ lat_{TX 2}. For a smaller value of lat_TX, a smaller Th_{a b} may impose a criterion to exclude a candidate resource. This may result in a smaller set of candidate resources with lower interference level, and, the reliable data transmission may occur within the time limit. [0146] The higher layer parameter“SL— ThresPSSCH— RSRP— Latency— List" may be defined in the "SL-CommTxPoolSensingConfig” IE, e.g., with the following example:

[0147] The parameter Th_{a b}{lat_TX ) may depend on (e.g., only on) the latency level of the data to be transmitted by the current vehicle. In examples, this parameter Th_{a b}(lat_TX, lat_RX ) may depend on the reliability level of the data from other vehicles. A similar scheme as above may be applied.

[0148] The set S_A may be initialized to the union of the candidate single-subframe resources (e.g., all the candidate single-subframe resources). The set S_B may be initialized to an empty set.

[0149] WTRU may exclude a candidate single-subframe resource R_{x y} from S_A, if one or more of the following: the WTRU does not monitor sub-frame t|^L as above, e.g., as described above for the WTRU monitoring sub-frames

such that y +

with Q = function of C_resei and rel_TX.

Cresei = 10^*SL_RESOURCE_RESELECTION_COUNTER, where

"SL_RESOURCE_RESLECTION_COUNTER” may be a higher layer parameter. The constant 10 may be used for the case that the same resource is still maintained after the counter reaches 0. A smaller value of lat_TX may be associated with a smaller value of C_resel. For example, we may set C_resel = C_resel * lat_TX. For low latency data transmissions, it may not be necessary to consider the future resource reservation conflict with its other (high latency) data transmissions.

[0150] In examples, the WTRU may exclude a candidate single-subframe resource R_{x y} from S_A, if one or more of the following: the WTRU receives an SCI format 1 in sub-frame t^ , and the "Resource reservation” field and "Priority” field in SCI format 1 are P_rsvp-RX and prio_RX, a PSSCH-RSRP measurement according to the received SCI format 1 is higher than Th_{pri0Tx pri0RX}(lat_TX), e.g., as described above for the WTRU monitoring sub-frames '^{n an}

integer j, such that

1, ... , Q with Q = min ( 1,— -— ). C^._esel may be a function of C_resel and lat_TX e.g., as described

V Prsvp-RX/

above for when the WTRU may exclude a candidate single-subframe resource R_{x y} from S_A.

[0151] In examples, the WTRU may exclude a candidate single-subframe resource R_{x y} from S_A, if one or more of the following: the WTRU receives an SCI format 1 in sub-frame t^ , and the "Resource reservation” field, "Priority” field and "Reliability” field in SCI format 1 are P_rSv_p-Rx_< P^rio _Rx and rel_RX, a PSSCH-RSRP measurement according to the received SCI format 1 is higher than

Th_Pri_{0TX P}ri_0RX(.lat_Tx, lat_RX), e.g., as described above for the WTRU monitoring sub-frames

^-_A-Pstep+v -’ F-n ^{there in an} integer;, such that y +j * R_T'_5nr-t_C =™ + P_step * may

have the same or similar definition as above.

[0152] If the remaining candidate resources in S_A is smaller than B_t M_tota then the features where set 5^ may be initialized to the union of the candidate single-subframe resources (e.g., all the candidate single-subframe resources), and, the set S_B may be initialized to an empty set, may be repeated with Th_{a b} increased, e.g., by 3 dB.

[0153] The value B_t may depend on lat_TX. A smaller value of lat_TX may be associated with a smaller value of B_t. This may enhance the quality of the candidate resources in the remaining S_A, in terms of the interference level of the candidate resources.

[0154] For each remaining candidate resource in S_A, the metric E_{x y} may be the linear average of the sensed RSSI measured in sub-channels x + k for k = 0, ... , L_subCH— 1 in the monitored sub-frames, e.g., as described above for the WTRU monitoring sub-frames

[0155] The WTRU may move the candidate single-subframe resource R_{x y} with the smallest metric E_{x y} from S_A to S_B until the cardinality of S_B is greater than or equal to B₂ M_totai. The set S_B may be reported to higher layers.

[0156] The value B₂ may depend on lat_TX. A smaller value of lat_TX may lead to a smaller value of B₂. This may enhance the quality of the candidate resources in the remaining S_B, in terms of the interference level of the candidate resources.

[0157] Examples may be provided related to reliability or latency. Implementations may use reliability and latency, e.g., simultaneously.

[0158] FIG. 3 shows an exemplary mode 4 WTRU resource selection, e.g., based on the given latency requirements. [0159] In-device coexistence implementations, e.g., for a mode 4 WTRU, may be provided herein. It is possible that a single WTRU supports LTE sidelink and NR sidelink. The LTE sidelink may not have the co channel as the NR sidelink. The LTE sidelink and NR sidelink may support two different services. Due to the TX capability limitation, a WTRU may not be able to transmit on the LTE sidelink and NR sidelink simultaneously. A resource selection to accommodate the simultaneous LTE sidelink, e.g., using one or more of the features described herein, may be described herein, e.g., for a mode 4 WTRU.

[0160] The LTE carrier resource selection may be based on PPPP. In NR sidelink, the reliability and the latency values of the packet may be introduced/used. One or more of the following may be provided, e.g., which may balance the reliability and latency requirements of NR sidelink data with the LTE sidelink data. The following features may be suitable for coordinated resource selection for NR sidelink transmissions or LTE sidelink transmissions, and, similar approaches may be used for NR sidelink receptions or LTE sidelink receptions, e.g., on a conditiion the data QoS requirements for the reception data are known. This may not be restricted to LTE mode 4 user or NR mode 2 user. One or more of the following may apply.

[0161] In examples, the NR sidelink resource selection may follow that as for LTE carrier resource selection. NR sidelink channel may be treated as an additional carrier, e.g., on top of LTE carriers. The WTRU supporting both NR sidelink and LTE sidelink may perform the per-carrier independent resource selection, and the WTRU may drop transmission in a sub-frame based on the PPPP value of the data.

[0162] In examples, the NR sidelink resource selection may (e.g., also) consider the latency requirements of the NR sidelink data, together with the PPPP of the NR sidelink data.

[0163] The PPPP may be considered first and the latency of the NR sidelink resource may be considered second. If the NR sidelink data has a smaller value of PPPP than the LTE sidelink data (e.g.,

NR sidelink data has higher priority than LTE sidelink data), then the NR sidelink resource may be selected before LTE sidelink resource. Otherwise, the LTE sidelink resource may be selected before LTE sidelink resource. If the PPPP value of NR sidelink data is equal to the PPPP value of LTE sidelink data, then the WTRU may check the latency value lat_TX of the NR sidelink data. If this value is less than a threshold lat_thres, then the NR sidelink resource may be selected before LTE sidelink resource. If the lat_TX value is larger than or equal to a threshold lat_{t res}, then the LTE sidelink resource may be selected before NR sidelink resource. The threshold lat_thres may be a single configurable value, be a constant, or be dependent on the PPPP value. For example, if the PPPP value of NR sidelink data and LTE sidelink data is equal to 3, then the lat_thres may be set as a first value, for example 50 ms. If the PPPP value of NR sidelink data and LTE sidelink data is equal to 4, then the lat_thres may be set as a second value, for example 100 ms. FIG. 4 shows an example of determining the priority of a NR sidelink resource compared to an LTE sidelink resource (e.g., PPPP first, latency second). [0164] The latency of a NR sidelink resource may be considered first and the PPPP may be considered second. If the NR sidelink data has lat_TX smaller than a first threshold lat_{thres l}, then the NR sidelink resource may be selected before the LTE sidelink resource, e.g., no matter what the PPPP value of the data. If the NR sidelink data has lat_TX larger than a second threshold lat_{thres 2}, then the LTE sidelink resource may be selected before the NR sidelink resource, e.g., no matter what the PPPP value of the data. If the NR sidelink data has lat_TX between the two thresholds, e.g., lat_{thres l} < lat_TX < lat_thr_es, 2 _> then the PPPP value of the NR sidelink data may be compared with the PPPP value of the LTE sidelink data. The data with lower PPPP value has the priority of obtaining the resources. If the PPPP values are a tie, then it may be up to WTRU's implementation to determine the sidelink resources. FIG. 5 shows an example of determining the priority of NR sidelink resource over LTE sidelink resource (e.g., latency first, PPPP second).

[0165] The NR sidelink resource selection may (e.g., also) consider the reliability requirements of the NR sidelink data, together with the PPPP of the NR sidelink data. In examples, the PPPP is considered first and the reliability of the NR sidelink resource is considered second. If the NR sidelink data has a smaller value of PPPP than the LTE sidelink data (e.g., NR sidelink data has higher priority than LTE sidelink data), then the NR sidelink resource may be selected before LTE sidelink resource. Otherwise, the LTE sidelink resource may be selected before LTE sidelink resource. If the PPPP value of NR sidelink data is equal to the PPPP value of LTE sidelink data, then the WTRU may check the reliability value rel_TX of the NR sidelink data. If this value is larger than a threshold rel_thres , then the NR sidelink resource may be selected before the LTE sidelink resource. If the rel_TX value is smaller than or equal to a threshold rel_thr_{es >} then the LTE sidelink resource may be selected before NR sidelink resource. The threshold rel_thr_es may be a single configurable value, be a constant, or be dependent on the PPPP value. For example, if the PPPP value of the NR sidelink data and LTE sidelink data is equal to a first value, e.g., 3, then the reZ_tftres is set as a first reliability value, for example 99.99%. If the PPPP value of both NR sidelink data and LTE sidelink data is equal to a second value, e.g., 4, then the rel_thres is set as a second reliability value, say 99%. FIG. 6 shows an example of determining the priority of NR sidelink resource over LTE sidelink resource (e.g., PPPP first, reliability second).

[0166] The reliability of an NR sidelink resource may be considered first and the PPPP may be considered second. If the NR sidelink data has rel_TX smaller than a first threshold rel_{threS l} , then the LTE sidelink resource may be selected before the NR sidelink resource, e.g., no matter what the PPPP value of the data. If the NR sidelink data has lat_TX larger than a second threshold /aZ _{res 2}, then the NR sidelink resource may be selected before the LTE sidelink resource, e.g., no matter what the PPPP value of the data. If the NR sidelink data has rel_TX between the two thresholds, e.g., rel_{threS l} £ rel_TX < rel_thr_es,2 _> then the PPPP value of the NR sidelink data may be compared with the PPPP value of the LTE sidelink data. The data with lower PPPP value may have the priority of obtaining the resources. If the PPPP values are a tie, then it may be up to WTRU's implementation to determine the sidelink resources. FIG. 7 shows an example of determining the priority of NR sidelink resource over LTE sidelink resource (e.g., reliability first, PPPP second).

[0167] In the above, determining the priority of an NR sidelink resource and LTE sidelink resource may be determined based on PPPP, NR data reliability, and NR data latency.

[0168] Resource pool ranking in mode 4 WTRU resource selection may be provided. In the above discussions, the sidelink transmissions may be in broadcast mode. For NR V2X, unicast or multicast sidelink transmissions may be used. The retransmissions in the unicast NR V2X sidelink case may need to be more protected than the initial transmission, e.g., to ensure the prompt delivery of the data within a certain duration.

[0169] Some NR V2X use cases may have lower latency and/or higher reliable requirements than other NR V2X use cases. The data transmissions of the former NR V2X use cases may need to be more protected than other use cases.

[0170] For mode 4 WTRUs, the protection of the V2X data transmissions may be in terms of the smaller probability of collisions during resource selection. One or more implementations described herein may statistically reduce the collision probability in resource selection, for those retransmitted data or those data with lower latency and/or higher reliable requirements.

[0171] The candidate resources may be partitioned, e.g., into 2 sets. The partition may be in terms of the frequency of sub-channels, e.g., sub-channels with lower frequency belong to the first set of resources and sub-channels with higher frequency belong to the second set of resources. Other partitionings are also possible. The first set of resources may be targeted for the initial transmissions or data with relaxed latency and reliability requirements, while the second set of resources may be targeted for the retransmissions or data with tight latency and reliability requirements.

[0172] The second set may include more resources than the first set (e.g., to have more protection of the retransmissions or the data with tight latency and reliability requirements). The first set may be denoted as S-L and the second set as S₂. Suppose the number of resources in

is | S- and the number of resources in S₂ is |S₂ |. It is possible that |S₂ | > IS^ .

[0173] Each mode 4 WTRU may be assigned specific probabilities of selecting resources within

and S₂. The two sets of resources may be shared among n WTRUs. The probability of the i-th WTRU selecting a resource in S_t may be denoted as

_t and the probability of the i-th WTRU selecting a resource in S₂ may be denoted as p_{i 2}. It may be that p_{i 1} + p_{i 2} = 1. If each WTRU uses a single resource each time, then the average number of used resources in set may be åf p_{t l} , and the average number of used resources in set S₂ may be å p_{i 2} . The set S₂ may be considered more relaxed than S_t, e.g., if -^-²— >

[0174] For the data in the initial transmission, the probability of using resources in S_t may be larger than that for the data in the retransmissions. Let p_iA and p_i' _x be the probabilities of selecting a resource from S-L in initial transmission and retransmission, respectively. Let p_{i 2} = 1— p_{t l} and p_i' ₂ = 1— p'_iA be the probabilities of selecting a resource from S₂ in initial transmission and retransmission, respectively. Then, we may have p[ ₂ > p_{i 2}.

[0175] For the data with relaxed latency and reliability requirements, the probability of using resources in S-L may be larger than that for the data with tight latency and reliability requirements. Let p_{t l} be the probability of selecting a resource from

for the data with relaxed latency and reliability requirements. Let P_{j 1} be the probability of selecting a resource from S_t for the data with tight latency and reliability requirements. Then, we may have p_{t l} > p_jA.

[0176] This scheme may affect resource selection described above, e.g., in relation to the WTRU moving the candidate single-subframe resource R_{x y} with the smallest metric E_xy from S_A to S_B until the cardinality of S_B is greater than or equal to B₂ M_ίoίaί . B₂ M_totai resources may be selected from S_A based on their linear averaged sensed RSSI. It may not be considered whether the selected resources belong to or S₂. It may be ensured (e.g., alternately) that a certain percentage {p_{t l} or p_{i 2}) of the selected resources are in S_t or S₂. The probability p_iA or p_{i 2} may depend on the data reliability or latency requirements.

[0177] The value of p_{t l} or p_{i 2} may be signaled, e.g., since the sum of these two values is equal to 1. The value of p_i' _t or p_i' ₂ could be signaled, e.g., similarly. Each WTRU may be configured with two probabilities, one for initial transmission and one for retransmission. In examples, these two values may be p_iA and r[ _c. These values may be small for some WTRUs with tight latency requirements. These two values may be signaled in DCI, or may be signaled in RRC messages.

[0178] If a mode 4 WTRU receives these parameters, it may start to select a resource to use. It may (e.g., first) select which resource set to use between

and S₂. This may depend on the configured probability p_iA for the initial transmission or may depend on the configured probability p[ _t for the retransmissions. If the resource set is determined, it may select the resource from this set. [0179] Mechanism(s) may be provided for NR SL coexistence with LTE SL. One or more of the following may apply: WTRU reporting in LTE Mode 3 and/or NR Mode 1 ; LTE Mode 4 and/or NR Mode 2 WTRU resource selection in dual connectivity; dynamic priority-based selection between NR SL RX and LTE SL TX; or channel adjustment for in-device coexistence.

[0180] Mechanisms for WTRU reporting in LTE Mode 3 and/or NR Mode 1 may be provided. For a WTRU in dual connectivity mode where the LTE V2X sidelink and NR V2X sidelink occupy channels in the same band, the half-duplex constraints may hinder/disable the simultaneous transmission on one RAT and reception on another RAT.

[0181] If the WTRU is a LTE mode 3 user and/or a NR mode 1 user, then a gNB or eNB may coordinate on the resource allocation for the WTRU. There may be some information the WTRU reports to the gNB or eNB to facilitate the coordination between the gNB and eNB. In the initialization stage, WTRU may report one or more of the following to the gNB and/or eNB, etc.: dual connectivity mode and sidelink transmission mode information; LTE/NR SL resource pool configuration; NR SL subcarrier spacing, waveform, SA/data multiplexing scheme; synchronization sources for LTE sidelink and NR sidelink; or time difference between LTE synchronization source and NR synchronization source.

[0182] Dual connectivity mode and sidelink transmission mode information may be reported. A WTRU may report to a gNB/eNB that it is in dual connectivity mode and in LTE SL TX mode 3/NR SL TX mode 1 , e.g.,to trigger gNB/eNB coordinated scheduling.

[0183] An LTE/NR SL resource pool configuration may be reported to gNB/eNB. The gNB may consider the frequency and time resource locations of the LTE SL resource pool for its scheduling of NR SL transmissions. The eNB may consider the frequency and time resource locations of the NR SL resource pool for its scheduling of LTE SL transmissions.

[0184] An NR SL subcarrier spacing, waveform, and/or SA/data multiplexing scheme may be reported to the network, e.g., eNB. The NR V2X sidelink may support different numerologies, e.g., 15, 30, 60 kHz subcarrier spacing, e.g., in Frequency Range 1 (FR1). This may determine the time duration of each resource unit for data transmissions. The numerology information may be used by eNB's for coordinated scheduling of LTE SL transmissions and NR SL transmissions. The NR V2X sidelink may support CP- OFDM and DFT-s-OFDM. The latter may have lower PAPR and may be used in a link-budget limited scenario. This waveform information may allow the eNB to coordinate the transmit power on LTE SL or NR SL. The NR V2X sidelink may support TDM and FDM multiplexed SA and data. The former multiplexing scheme may provide a flexible link budget for control channel transmissions. This multiplexing information may allow an eNB to coordinate the transmit power on LTE SL or NR SL. [0185] Synchronization sources for LTE sidelink and NR sidelink may be reported. LTE SL may use eNB, GNSS, and/or LTE WTRU as its synchronization source(s), and NR SL may use gNB, eNB, GNSS, LTE WTRU, and/or NR WTRU as its synchronization source(s). For an LTE mode 3 WTRU, the synchronization source(s) may include eNB and/or GNSS. For NR mode 1 WTRU, the synchronization source(s) may include gNB and/or GNSS. When a WTRU is in a dual connectivity mode, the WTRU may configure a common synchronization source. For example, the WTRU may switch the synchronization source from eNB to GNSS for its LTE SL transmissions and/or switch the synchronization source from gNB to GNSS for its NR SL transmissions.

[0186] A time difference between an LTE synchronization source and NR synchronization source may be reported. In case LTE SL and NR SL use different synchronization sources, the WTRU may calculate the time difference between the two synchronization sources. The report of this time difference may allow the gNB and eNB to schedule their respective SL resources.

[0187] For a NR mode 1 WTRU in dual connectivity mode, the WTRU may report (e.g., further report) LTE SL resource reservation (e.g., periodic resource reservation) to the network, e.g., gNB. The information on the reserved LTE SL periodic resource(s), e.g., (periodic resource(s)) may allow the gNB to select the corresponding NR SL resources to avoid or minimize the time-wise overlapping with the LTE SL periodic resources (e.g., as disclosed herein). For NR SL SPS resources, the periodicity may be selected such that the time-wise overlapping is minimized. The gNB's resource allocation for a mode 1 WTRU may take into account (e.g., to avoid or minimize the time-wise overlapping) the time difference between NR and LTE sidelink synchronization resources, the numerology, waveform, and/or SA/data multiplexing scheme.

In case of overlapped SPS resources between NR SL and LTE SL, the gNB may provide the priority of SL resource usage, e.g., LTE SL resource is always used, NR SL resource is always used, LTE SL resource and NR SL resource are interlaced (see FIG. 8) , etc. FIG. 8 illustrates exemplary overlapping periodic resources between LTE SL and NR SL. A resource priority indication may be provided via DCI, or could be semi-statically configured via RRC signaling.

[0188] When a WTRU receives a new periodic reservation from a gNB, it may apply the configured priority or it may apply the DCI indicated priority to select the proper resources for its sidelink transmissions (e.g., non-overlapping resource(s)).

[0189] During the dual connectivity mode and the WTRU is a LTE mode 3 WTRU, the WTRU may report (e.g., further report) NR SL periodic resource reservation to an eNB. And the WTRU may perform the one or more of the above features.

[0190] An LTE Mode 4 and/or NR Mode 2 WTRU resource selection in dual connectivity may be performed. For a WTRU in dual connectivity mode where the LTE V2X sidelink and NR V2X sidelink occupy channels in the same band, the half-duplex constraints may hinder/disable simultaneous transmission on one RAT and reception on the other RAT.

[0191] Resource exclusion due to past cross-RAT transmissions may be provided. If a WTRU is an NR mode 2 user, the WTRU may perform autonomous resource selection, e.g., from the RRC (pre-)configured NR SL resource pool.

[0192] Suppose the NR mode 2 WTRU applies the similar resource selection procedure as in LTE. One or more features described above for LTE V2X Mode 4 UE resource selection may be applied to NR mode 2, e.g., with modifications, e.g., on the resource unit from sub-frame to slot.

[0193] If the WTRU is in dual connectivity mode and made LTE SL transmission(s), due to half-duplex constraints, the WTRU may be unable to monitor the adjacent NR sidelink channels at the time slots for LTE sidelink transmissions. This may affect its resource selection for NR sidelink transmissions. The corresponding infeasible resources in NR mode 2 WTRU's resource selection may be excluded. The periodic expansion of the time (e.g., sub-frames) for past LTE SL transmissions may be excluded from the candidate resources for NR SL resource selection. The following exemplary mechanism (e.g., additional mechanism) for the NR mode 2 WTRU may be used, e.g., if it is in the dual connectivity mode.

[0194] The WTRU may exclude candidate slot resource R_{x y} from S_A, if: the WTRU does not monitor slot due to the LTE SL transmissions; and/or there is an integer j, such that y + j * P_rsv_p-Tx = z + Pstep * k * q, where j = 0, ... , C_resel— 1, k is any value in the higher layer parameter

[0195] A similar resource exclusion may be applied to LTE mode 4 WTRU.

[0196] Resource exclusion due to future cross-RAT resource reservation may be provided. Herein, the impact of past sidelink transmissions on one RAT to the resource selection on the other RAT was discussed.

[0197] In LTE V2X, periodic resource reservation resulting from SPS scheduling or WTRU autonomous selection may be supported. It may be assumed the similar periodic resource reservation mechanism is supported in NR V2X. The reserved resources in one RAT may be considered in the resource selection associated with the other RAT. The periodic resource reservation for LTE SL (or NR SL) may be considered in each resource selection of a NR mode 2 WTRU (or of a LTE mode 4 WTRU). The corresponding infeasible resources in NR mode 2 WTRU's resource selection may be excluded.The resources of time overlapping with the reserved LTE SL transmissions may be excluded from the candidate resources for NR SL resource selection. We may have the feature (e.g., additional feature) for the NR mode 2 WTRU as described above (e.g., candidate slot resource exclusion), e.g., if it is in the dual connectivity mode. This may be considered as a dynamic resource exclusion.

[0198] The resource exclusion may be performed in a semi-static way. Suppose the WTRU has made some periodic resource reservation on LTE SL. This may exclude the reception of the corresponding resources for NR SL. The resource pool for NR SL may be modified accordingly. For example, the bitmap in the IE of SubframeBitmapSL or SlotBitmapSL may be modified by flipping 1 to 0 on the subframes or slots which are not available for reception, e.g., due to the transmissions of the other RAT. A similar resource exclusion may be applied to LTE mode 4 WTRU.

[0199] Different resource types in NR resource selection(s) may be used. Due to the different numerologies used in NR SL and LTE SL, the duration of each LTE SL resource may be an integer multiple of the duration of each NR SL resource. Since the NR SL and LTE SL may not be orthogonally aligned in time (e.g., synchronization source time difference), the time duration of certain NR SL resources may overlap the time durations of two LTE SL resources, while the time duration of other NR SL resources may overlap the time duration of a single LTE SL resource. The former NR SL resources may be called type-1 resources, and the latter NR SL resources may be called type-2 resources. This is illustrated in FIG. 9. FIG. 9 illustrates exemplary NR type-1 resources and NR type-2 resources. In the NR mode 2 WTRU sidelink resource selection, the type-1 resources may be selected with lower priority than the type-2 resources. This may be because the transmissions on NR type-1 resources may affect the reception or monitoring over two LTE SL resource durations, e.g., with more impacts on LTE SL resource selections.

[0200] The prioritized operations on NR type-1 resources or NR type-2 resources may be in a physical layer. When the physical layer reports the sensing results to the MAC layer, it may filter out the type-1 resources from the candidate list. The prioritized operations on NR type-1 resources or NR type-2 resource may be in the MAC layer. When the MAC receives the candidate resources from the physical layer, it may select a type-2 resource, e.g., if it has the same RSSI condition as a type-1 resource.

[0201] Dynamic priority-based selection between NR SL RX and LTE SL TX may be performed. The TDM based SA/data multiplexing may be applied in NR SL. The SA may be sent out a few slots before the SL data transmission. A dual connectivity mode WTRU may receive the NR SA information (e.g., first), and detect the QoS parameters (e.g., priority, latency, reliability) of the SL data. If it has LTE SL data to transmit at the same time as the NR SL data reception, it may compare the priority of the LTE SL TX data with the priority of the NR SL RX data. Based on their priority level, the WTRU may decide whether to perform LTE SL TX or perform NR SL RX at the overlapped time. In case LTE SL TX is determined, the power of the LTE SL TX may be determined , e.g., to reduce the interference to the NR SL RX. [0202] When NR SL data needs to be transmitted, the WTRU may compare the data QoS parameters with the expected LTE SL reception, and may adjust the power of the NR SL TX, e.g., to reduce the interference to the LTE SL RX.

[0203] Channel adjustment for in-device coexistence may be performed. Suppose an example dual connectivity WTRU with several carriers on LTE SL or on NR SL. A pair of carriers (e.g., only a pair of carriers), e.g., LTE SL carrier (say, LTE carrier 1) and NR SL carrier (say, NR carrier 1), may occupy adjacent channels in the same band. Other LTE SL carriers and NR SL carriers may be far apart. A WTRU may assign high latency, low reliability, and/or low priority data to be transmitted on LTE carrier 1 or NR carrier 1. The WTRU may assign low latency, high reliability, and/or high priority data to be transmitted on other LTE SL carriers or NR SL carriers.

[0204] A dual connectivity WTRU may initialize with a single carrier for LTE SL and a single carrier for NR SL. The LTE SL carrier and the NR SL carrier may occupy adjacent channels in the same band. Due to the half-duplex constraints, the communication of NR SL or LTE SL may be affected . The WTRU may report this condition to the gNB and/or eNB, to switch the NR SL channel or the LTE SL channel, e.g., so that they are far apart. The reporting metrics from the WTRU to gNB or eNB may include one or more of the following: CBR, CR, collision occasions or percentage, average data rates for NR SL or LTE SL, communication range of NR SL or LTE SL (e.g., which may affect the transmission power), data flow reliabilities or latency requirements, or data priority, etc. The gNB or eNB may coordinate to switch the carrier's channel for the dual connectivity WTRU.

[0205] Vehicular communication is a mode of communication whereby WTRUs can communicate with each other, e.g., via sidelinks. Example scenarios for V2X operations may include: in-coverage scenario and out of coverage scenario. In an in-coverage scenario, WTRUs (e.g., vehicles) may receive assistance from the network to start transmitting and receiving V2X messages. In an out of coverage scenario,

WTRUs (e.g., vehicles) may use some pre-con figured parameters to start transmitting and receiving V2X messages.

[0206] V2X communication services may comprise different types, such as for example: Vehicle to Vehicle (V2V), Vehicle to infrastructure (V2I), Vehicle to Network (V2N), and Vehicle to Pedestrian (V2P).

In V2V vehicular WTRUs may communicate with each other directly. In V2I vehicular WTRUs may communicate with roadside units (RSUs)/eNBs. In V2N, vehicular WTRUs may communicate with core network. In V2P, vehicular WTRUs may communicate with WTRUs that may have special conditions (e.g., low battery capacity).

[0207] LTE V2X may include types of resource allocation modes for V2V communication, for example, network-scheduled mode and WTRU-scheduled mode. In a network-scheduled mode, the network may give the WTRU a scheduling assignment for V2X sidelink transmission. The LTE network-scheduled mode may be referred to as Mode 3. In a WTRU-scheduled mode, the WTRU may autonomously select the resources from a configured/pre-configured resource pool. The LTE WTRU-scheduled mode may be referred to as Mode 4.

[0208] LTE V2X may include types of resource allocation in Mode 3, e.g., dynamic resource allocation and semi-persistent resource allocation. In dynamic resource allocation, the WTRU may receive scheduling information for sidelink transmission by downlink control information (DCI) format 5A cyclic redundancy check (CRC) scrambled by sidelink-vehicle-radio network identifier (SL-V-RNTI). In semi-persistent resource allocation, the WTRU may receive configuration of multiple semi-persistent scheduling (SPS) indices , where each index may have different periodicity and timing offset. The WTRU may receive activation/deactivation of an SPS index by DCI format 5A CRC scrambled by SL-SPS-V-RNTI.

[0209] NR V2X may support multiple use cases such as vehicle platooning, advanced driving, extended sensors, remote driving, or the like. NR V2X may support multiple modes. An NR network-scheduled mode may be referred to as Mode 1 (e.g., NR Mode 1). An NR WTRU-scheduled mode may be referred to as Mode 2 (e.g., NR Mode 2).

[0210] Vehicles platooning may enable the vehicles to dynamically form a group travelling together. The vehicles in the platoon may receive periodic data from the leading vehicle, e.g., in order to carry on platoon operations. This information may allow the distance between vehicles to become extremely small. For example, the gap distance translated to time can be very low (e.g., sub second). Platooning applications may allow the vehicles following to be autonomously driven.

[0211] Advanced driving may enable semi-automated or fully-automated driving. Longer inter-vehicle distance may be assumed. Each vehicle and/or RSU may share data obtained from its local sensors with vehicles in proximity, e.g., allowing vehicles to coordinate their trajectories or maneuvers. Each vehicle may share its driving intention with vehicles in proximity. One or more of traveling ease, collision avoidance, or improved traffic efficiency may be provided.

[0212] Extended sensors may enable the exchange of raw or processed data gathered through local sensors or live video data among vehicles, RSUs, devices of pedestrians, V2X application servers, or the like. The vehicles may enhance the perception of their environment beyond what their own sensors can detect and have a more holistic view of the local situation.

[0213] Remote driving may enable a remote driver or a V2X application to operate a remote vehicle for those passengers who cannot drive themselves or a remote vehicle located in dangerous environments.

For a case where variation is limited and routes are predictable, such as public transportation, driving based on cloud computing may be used. Access to cloud-based back-end service platform may be considered for this use case group.

[0214] The QoS requirements for NR V2X may be specified with one or more of the following parameters: payload size (e.g., Bytes); transmission rate (e.g., message/sec); maximum end-to-end latency (e.g., ms); reliability (e.g., %); data rate (e.g., Mbps); or minimum required communication range (e.g., meters).

[0215] These QoS characteristics may be represented with an indicator, e.g., a 5G QoS indicator (5QI) for example as used in NR. In V2X, the 5QI may be renamed VQI and may account for one or more QoS parameters related to V2X.

[0216] For a unicast case, PC5 QoS parameters may be negotiated, e.g., at the establishment of a one- to-one communication implementation. The one-to-one communication establishment may be enhanced to support PC5 QoS parameters negotiation, e.g., between two WTRUs. After the PC5 QoS parameters negotiation, the same QoS may be used in both directions.

[0217] Implementations associated with NR and LTE RAT coexistence (e.g., NR and LTE RAT in the same device) are described herein. NR V2X may support advanced services and/or services offered by LTE V2X. A vehicle may be equipped with NR and LTE RATs, e.g., to support basic safety services offered by LTE V2X and advanced services offered by NR V2X.

[0218] If the WTRU is under network coverage, NR and LTE V2X may be expected to be controlled by LTE Uu or NR Uu. In examples, in an initial deployment of NR V2X, NR Uu may be sporadic and LTE Uu may be widely spread. In examples, to aid performance of NR V2X, enabling LTE Uu to control the NR V2X may be implemented. In examples, given that a WTRU may be equipped with two RATs (e.g., NR RAT and LTE RAT), allowing LTE Uu or NR Uu to control both RATs may be needed, e.g., to support the deployment of the NR V2X system.

[0219] A WTRU may be under different coverage scenarios, for example: (1) the WTRU is under coverage of both LTE Uu and NR Uu; (2) the WTRU is under coverage of LTE Uu; and (3) the WTRU is under coverage of NR Uu.

[0220] In each scenario, a WTRU may select to be served by different BS(s) and/or use different transmission modes. Certain services may be provided by NR sidelink or LTE sidelink. In examples, since a given RAT may not support V2X communication in another RAT a WTRU may need to select serving BS(s) and resource selection mode for NR and LTE sidelink transmission.

[0221] In a gNB-controlled NR sidelink examples, the WTRU may be dynamically or semi-statically scheduled time-frequency resource(s) by the network and some transmission parameters (e.g., TB size,

MCS, etc.) may be determined by the WTRU. This type of scheduling may be motivated in the case that the network wants to give some flexibility for the WTRU because the NW may not have complete information about the characteristics of the sidelink channel (e.g., path loss) and it may be too expensive to send it via uplink transmissions.The WTRU may need to figure out or determine transmission parameter(s), format(s), and/or configuration(s) for the time-frequency resource allocated by the network.

[0222] In case where LTE and NR sidelinks coexist in the same device, intra-band coexistence may have issues such as half-duplex, in band emission (IBE), out of band emission (OBE), and/or

intermodulation. One or more implementations described herein may be associated with enabling LTE and NR sidelinks to coexist (e.g., in device coexistence) in the same band.

[0223] Various scenarios that support service across different sidelink RATs are described herein. For example, models (e.g., model 1 , model 2, and model 3) may represent example scenarios that support service across different sidelink RATs. In model 1 , safety applications may be provided in LTE RAT and advanced applications may be provided in NR RAT. In model 2, the applications, for example, safety and advanced, may be provided in NR RAT. In model 3, LTE RAT may provide safety applications and NR RAT may provide safety and advanced applications. Each of the above models may be applied to

implementation(s) described herein, where a decision to perform behavior (e.g. prioritization) associated with a specific service (e.g. safety vs advanced) may be inherently associated with the decision to perform that same behavior to the associated RAT (e.g. LTE vs NR).

[0224] A WTRU may be configured (e.g., via upper layers/higher layers) to operate using one of the above models. For example, the application layer may indicate to the AS layer the applicability of one of the following models in the WTRU.

[0225] Various scenarios where a BS supports different services are described herein. With respect to a NR cell, a BS may support NR sidelink carrier(s) and LTE sidelink carrier(s).ln this example, the BS may support network-scheduled LTE sidelink carrier(s) and/or support WTRU-scheduled LTE sidelink carrier(s). The BS may be limited to supporting NR sidelink carrier(s). With respect to an LTE cell, a BS may support LTE sidelink carrier(s) and NR sidelink carrier(s).ln this example, the BS may support network-scheduled NR sidelink carrier(s) and/or support WTRU-scheduled NR sidelink carrier(s). The BS may be limited to supporting LTE sidelink carrier(s). In examples such as one or more of the below implementations, an NR/LTE cell may refer to a cell that uses the NR/LTE RAT and/or it may refer to a cell that supports sidelink operation using NR/LTE (e.g. it broadcasts resources needed for NR/LTE SL operation, or it allows for scheduling of NR/LTE sidelink).

[0226] A WTRU may receive the service information of each cell in an SIB.

[0227] For example, the WTRU may determine to receive the information of the services supported by the cell in an SIB. By decoding the SIB from one cell, the WTRU may implicitly or explicitly determine whether a cell transmitting the SIB is an LTE cell or an NR cell. If the WTRU determines that the cell is a NR cell, the WTRU may further determine: (1) whether the cell supports LTE sidelink carrier(s); and/or (2) if the cell supports LTE sidelink carrier(s), whether the cell supports WTRU-scheduled mode and/or network- scheduled mode. If the WTRU determines that the cell is an LTE cell, the WTRU may further determine: (1) whether the cell supports NR sidelink carrier(s); and/or (2) if the cell supports NR sidelink carrier(s), whether the cell supports WTRU-scheduled mode and/or network-scheduled mode.

[0228] A WTRU may perform cell (re)selection based on its V2X application, RAT Modeling, and/or services provided in each cell.

[0229] The WTRU may be configured to prioritize a cell based one or more of: (1) whether the cell supports both advanced and safety services (e.g. using model 1 , whether the cell supports both NR and LTE); (2) whether the cell supports safety services (e.g. using model 1 , whether the cell supports LTE); (3) whether the cell supports advanced services (e.g. using model 1 , whether the cell supports NR); (4) whether the cell is an NR cell; (5) whether the cell is an LTE cell; (6) whether the cell supports network- scheduled resource allocation mode in both RATs; (7) whether the cell supports network-scheduled resource allocation mode in one RAT and WTRU-scheduled resource allocation mode in another RAT; or (8) whether the cell supports network scheduled and WTRU autonomous resource allocation. For the cell supporting network scheduled and WTRU autonomous resource allocation, NW scheduled may be limited to dynamic scheduling (e.g. not based on configured grants).

[0230] A WTRU may use a combination of the above conditions. For example, a WTRU may prioritize cells for cell (re)selection according to a first condition, and in the case there are multiple cells that satisfy a first condition, may use a second condition to further prioritize. A WTRU may prioritize cells for cell (re)selection according to a first condition, and in the case there are no cells that satisfy a first condition, may use a second condition to prioritize.

[0231] A WTRU may perform cell selection based on its V2X applications and/or RAT modeling.

[0232] The WTRU may be configured for model 1 RAT selection. The WTRU may be configured to prioritize LTE cells. This approach may provide the possibility of supporting safety applications in many vehicles. If the WTRU is under coverage of NR and LTE cells that can support V2X applications, the WTRU may determine/be configured to connect to both NR and LTE cells to perform dual connectivity, e.g., where an NR cell may provide advanced applications and an LTE cell may provide safety applications. In examples, the WTRU may determine that the WTRU wants to perform V2X application in dual connectivity by sending two messages (e.g.SidelinkUEInformation messages) to two cells. In examples, the WTRU may support the network in configuring its dual connectivity by informing the network (e.g., using capability signaling, or in sidelinkUEInformation) of the supported model, or that the WTRU cannot support both safety and sidelink in the same RAT.

[0233] The WTRU may be configured according to model 2 or model 3 RAT selection. The WTRU may be configured to prioritize an NR cell and the NR cell connected to the WTRU may provide the WTRU safety and advanced applications. Alternatively or additionally, regardless of the RAT selection model, the WTRU may be configured to prioritize NR cells based on the location of the WTRU. For example, in an area where advanced services is feasible and basic safety service is not necessary, the WTRU may be configured to prioritize NR cells to perform the advanced services. The WTRU may receive the indication of service from NR or LTE cells via signal information block (SIB).

[0234] A WTRU may perform cell selection based on its V2X applications and the services provided in each cell.

[0235] The WTRU may be configured to prioritize a cell based on the type of services the cell supports. The WTRU may determine the services supported in each cell based on its configured RAT modelling and/or services information in the SIB of each cell. The WTRU may be configured to prioritize the cell supporting both advanced and safety services. If configured with mode 1 , the WTRU may prioritize a cell supporting LTE SL and NR SL. The WTRU may be configured to prioritize NR or LTE cells if it detects multiple cells supporting both types of services. The WTRU may be configured to prioritize the cell supporting safety services. Alternatively or additionally, the WTRU may be configured to prioritize the cell supporting advanced services.

[0236] Resource selection mode configuration is described herein.

[0237] If a WTRU is under network coverage, the WTRU may be configured to have one or more of the following resource allocation modes: dynamic resource allocation; activation/deactivation based resource allocation (e.g., semi-persistent scheduling allocation or NR grant free type-2); or RRC (pre-)configured resource allocation (e.g., configured NR grant type-1 , WTRU autonomous selection of resource(s) from resources configured by RRC).

[0238] A WTRU may determine the supported QoS of each resource selection mode.

[0239] The WTRU may determine the supported QoS of each resource selection mode based on one or a combination of scheduling request (SR) configuration, buffer status report (BSR) configuration, time instant density of the configured resource (e.g., how many configured transmission instants per period), the bandwidth of the configured resource, channel busy ratio (CBR) of the configured resource, or the like.

[0240] A WTRU may determine the supported QoS of dynamic resource allocation mode. [0241] The WTRU may determine the supported priority and/or latency of the dynamic resource allocation mode based on SR and/or BSR configuration. The WTRU may determine the supported latency of the QoS based on the periodicity of the configured SR. The WTRU may determine that the supported latency of the dynamic resource selection mode is larger than the periodicity of the configured SR, e.g., since the WTRU may need to send BSR and receive sidelink grant before transmission of a packet.

Alternatively or additionally, the WTRU may be configured to send periodic sidelink BSR. The WTRU may determine that the supported latency of the dynamic resource selection is similar to the periodicity of the sidelink BSR.

[0242] A WTRU may determine the supported QoS of activation/deactivation and/or RRC (pre-) configured resource allocation mode.

[0243] The WTRU may determine the supported priority, latency, and/or data rate of an RRC (pre- )configured and/or activation/deactivation based resource allocation mode based on its (pre-)configured transmission resources. The WTRU may determine each of the QoS parameters by one or more of the following.

[0244] The WTRU may determine the supported latency and/or priority of the activation/deactivation and/or RRC (pre-)configured resource allocation mode based on the periodicity and/or average time distance of the configured resources. For example, the WTRU may determine that the supported latency of the resource allocation mode is smaller than or equal to the periodicity of the configured resources. The WTRU may determine that the average supported latency of the resource selection mode is smaller than or equal to the average time distance of the configured resources.

[0245] The WTRU may determine the supported data rate and / or reliability of the resource allocation mode based on CBR, bandwidth, and/or time instant density of the configured resources. The WTRU may measure CBR of the configured resources to determine the number of users sharing the same configured resource. The WTRU may be configured to determine the supported data rate of a configured resource as a function of CBR, bandwidth, and time instant density of the configured resource.

[0246] The WTRU may determine the supported reliability of the resource allocation mode based on one or combination of CBR, bandwidth and time instant density of the configured resources, the structure of the configured resource (e.g., number of transmission opportunities for one TB within a resource section window), or the like.

[0247] If CBR in one configured resource is zero and the WTRU has configured three transmission opportunities within a resource selection window, the WTRU may determine that the configured resource is dedicated to itself and may be able to perform three transmissions for one TB.The WTRU may determine that supported reliability of the resource selection mode as high. The WTRU may be configured with two transmission opportunities within a resource selection window. If the CBR measure in the configured resource is 0.5, the WTRU may determine the supported reliability of the resource selection mode as low.

[0248] A WTRU may determine the resource selection mode based on the QoS of the packet and the supported QoS of the resource selection mode.

[0249] The WTRU may determine the resource selection mode based on QoS of the packet and the supported QoS of the resource selection mode. The WTRU may determine one resource selection mode to satisfy the QoS requirement of a certain application/packet/MAC PDU. The WTRU may be configured to determine the resource allocation mode in an order until it can find a suitable resource allocation mode to satisfy the QoS requirement of the application/packet/MAC PDU.

[0250] If the WTRU has traffic in the buffer for transmission, the WTRU may determine to use a configured grant of an activated SPS resource if the configured resource satisfies QoS requirement. If the QoS requirement of the traffic is not guaranteed, the WTRU may perform an RRC (pre-)configured resource allocation mode. The WTRU may perform dynamic resource allocation mode if the QoS of the traffic is not satisfied by the RRC (pre-)configured resource allocation mode.

[0251] FIG. 10 is a diagram illustrating an example V2X communication system in which one or more disclosed embodiments may be implemented.

[0252] Implementations for Uu to control sidelink Mode 1 , such as where WTRU determines transmission parameters may be disclosed. A WTRU may determine a beam sweeping pattern and/or number of retransmissions for one TB based on the size and structure of the grant.

[0253] A WTRU may determine the number of retransmissions and/or resource size for each transmission based on the size and structure of the grant and/or beam sweeping pattern. The WTRU may be configured to perform at least N transmissions for one TB for an omnidirectional beamforming pattern. If the scheduled grant is suitable for more than N transmissions, the WTRU may increase the number of retransmissions, e.g., to improve the reliability of a TB or the WTRU may increase the resource size to each of N transmissions to fit the scheduled grant.

[0254] The WTRU may determine a beam sweeping pattern based on the size and structure of the grant. The WTRU may be configured with a set of beam-sweeping patterns (e.g., one omnidirectional beam pattern, two large beams sweeping pattern, four beams sweeping pattern, etc.) The WTRU may determine a beam sweep pattern based on the size of the scheduled grant. For example, the WTRU may determine to use one omnidirectional beam pattern if the WTRU is scheduled with one resource for transmission. Alternatively or additionally, the WTRU may determine to sweep to use a four beam sweeping pattern if it is scheduled with at least four resources for transmissions and the fourth resource may still satisfy latency requirement of the TB.

[0255] A WTRU may determine the number of physical sidelink control channel (PSCCH) transmissions and/or size of resource for each PSCCH based on size and structure of the grant.

[0256] Depending on the structure and size of the grant, the WTRU may determine to transmit multiple sidelink control information (SCI) in the same or different time instants for a certain packet. This approach may be motivated to reduce the effect of the half-duplex issue, e.g., since the WTRU may have multiple opportunities to decode an SCI of one PSSCH transmission. The WTRU may determine to transmit multiple PSSCHs or multiple PSCCH of a MAC PDU depending on the size and structure of the scheduled grant. In examples, the WTRU may be scheduled with different non-contiguous resources in the time domain;each PSSCH transmission may not be feasible in each resource. The WTRU may determine to transmit multiple SCI for one PSSCH transmission, e.g., to increase the reliability of the PSSCH transmission and/or reduce the half-duplex issue.

[0257] The WTRU may be configured with multiple resource sizes of a PSCCH transmission, e.g., to adapt with different range and/or reliability requirement. The WTRU may increase the resource size of a PSCCH transmission based on the size and structure of the scheduled grant. This approach may be motivated to support the range and/or reliability requirement of PSCCH transmission, e.g., since the increase of the resource size of PSCCH transmission may increase its range and/or reliability.

[0258] Implementations associated with a WTRU to indicate HARQ retransmission to a gNB and implementations for HARQ retransmission may be disclosed.

[0259] A WTRU transmits an SR to the gNB to indicate the necessity of retransmission. A WTRU may be configured to associate the data in the HARQ buffer with a logical channel. The logical channel associated with the HARQ buffer may be configured with one or multiple SR configurations. Based on the status of the HARQ buffer, the WTRU may trigger SR transmission to notify the necessary of

retransmission to the gNB.

[0260] A WTRU may use SR information bits to indicate the property of the data for HARQ

retransmission for unicast and/or groupcast transmissions. The WTRU may be configured to implicitly indicate the one or any combination of the following information: amount of resources required for retransmission; number of TBs required for retransmission; packet size required for retransmission; and/or, QoS associated with the TBs.

[0261] The WTRU may indicate such information by using one or any combination of the following: information bits in SR; selected resource in one or multiple SR configurations; and/or, SR transmission bits over multiple SR resources. In examples, the WTRU may perform SR transmission over two consecutive resources to indicate the property of the data for HARQ retransmission. If the data has high priority, the WTRU may transmit 11 in two consecutive resources, if the data has low priority, the WTRU may transmit 10 in two consecutive resources.

[0262] A WTRU may modify the QoS of the data in the HARQ buffer. The WTRU may be configured to modify the QoS parameter (e.g., priority or latency) of the data required for retransmission in the HARQ buffer by considering the delay budget and priority of the initial transmission. For example, the WTRU may increase the priority of the TB and reduce the latency of the TB in the HARQ buffer. The amount of the priority increase may be (pre-)configured and the amount of the reduction in the latency may depend on the time the WTRU receives feedback from the receiver WTRU.

[0263] A WTRU may transmit a BSR to the gNB to indicate the necessity of retransmission(s). The WTRU may be configured to associate the data in the HARQ buffer with a logical channel and such logical channel may be configured to associate with a logical channel group. The logical channel associated with the HARQ buffer may be associated with a priority, which may be determined based on one or any combination of the following: whether it is associated with a (pre-)configured priority; whether it is associated with the highest priority after QoS modification; and/or, whether it is associated with the highest priority of its corresponding initial data. Then the WTRU may perform BSR when it is scheduled an uplink grant. The BSR may include information of the HARQ buffer to notify the network the necessary of retransmission.

[0264] A WTRU may perform prioritization between HARQ retransmission and other transmission(s).

The WTRU may perform prioritization between HARQ retransmission and other transmission(s) based on the modified QoS of the TB in HARQ buffer for retransmission and the highest priority of the MAC SDU in the MAC buffer before MAC PDU assembling. If the modified priority of the TB in HARQ is higher than that of the highest priority MAC SDU in the MAC buffer, the WTRU may perform HARQ retransmission.

Otherwise, if the highest priority of a MAC SDU is higher than the modified priority of the TB, then the WTRU may perform MAC assembly and transmit the MAC PDU. If they have the same priority, the WTRU may compare the modified latency of the TB at HARQ buffer and the latency of the MAC SDU with the highest priority. The WTRU may prioritize the transmission with lower latency. The WTRU may indicate the modified QoS information in the HARQ buffer to MAC layer, e.g., to support the packet prioritization.

[0265] Implementations for in-device coexistence are described herein. In examples, in order for one RAT to avoid the transmission resource of another RAT, a WTRU may report information about service(s) and/or radio activities in one RAT to support the BS in scheduling in another RAT. [0266] The WTRU may report information about the service(s) and/or radio activities of one or multiple resource pools/carriers/BWPs in one RAT to the BS, e.g., to support the BS in scheduling

transmission/reception resource (s) of the WTRU in another RAT.

[0267] The set of pools/carriers/BWPs to be reported may be selected based on the potential in-device coexistence conflict that transmission in these resource pools/carriers/BWPs in one RAT may create to another RAT. In examples, the WTRU may report the radio activities of the carriers of one RAT which are in the same band with at least one carrier in the other RAT.

[0268] The information about the service(s) and/or radio activities in one RAT may include one or any combination of the time instant (e.g., slot, subframe, etc.) selected by the WTRU and/or scheduled by the BS, the time-frequency resources selected by the WTRU and/or scheduled by the BS, and QoS information of the ongoing service(s) in one RAT such as voice quality indicator (VQI), priority, reliability, minimum distance, and/or data rate requirement.

[0269] A WTRU may report information about the set of selected resource(s) in the WTRU-scheduled mode to the network.

[0270] A WTRU may have two sidelink RATs where one RAT is operating on a network-scheduled mode and the other RAT is operating on a WTRU-scheduled mode. The WTRU may report the information about the set of selected resource(s) in the WTRU-scheduled mode to the network. The information about the set of selected resource(s) may include one or any combination of the time instant (e.g., time slot, subframe, etc.) of the selected resource(s), the frequency of the selected resource(s), packet delay budget (PDB), priority, and/or reliability of the data associated with the selected resource.

[0271] This approach may support the network to avoid scheduling the time resource in one RAT overlapping with the selected resource in another RAT.

[0272] In examples, a WTRU may have an NR sidelink RAT operating in the network-scheduled mode and an LTE sidelink RAT operating in the WTRU-scheduled mode. Alternatively or additionally, the WTRU may have an LTE sidelink RAT operating in the network-scheduled mode and an NR sidelink RAT operating in the WTRU-scheduled mode. The WTRU may report information about the set of selected resource(s), which may be determined based on the output of the dynamic or semi-persistent resource selection procedures, to the BS. The dynamic resource selection procedure may be used to select transmission resource in one transmission window. The semi-persistent resource selection procedure may be used to select the resource in one transmission window and reserve resources for future transmissions. FIG. 11 is a diagram illustrating an example set of reserved subframes, e.g., in LTE PC5 reported by a WTRU to gNB. As illustrated in FIG. 11 , the WTRU may have an NR RAT working in network-scheduled mode and LTE RAT working in WTRU-scheduled mode. The WTRU may report the set of reserved subframes in LTE sidelink carrier to the gNB, e.g., to support the gNB in scheduling transmission in NR sidelink carriers that overlap.

[0273] In examples, a WTRU, such as a vehicle, may receive a configuration (e.g., from a network). The configuration may instruct the WTRU to report an overlapping resource associated with sidelink communication. For example, the WTRU may receive information indicating a time location of resource(s) associated with the network (e.g., a pool of network scheduled resources). The WTRU may determine if resource(s) scheduled for use by the WTRU overlap in time with the resource(s) associated with the network (e.g. the pool of network resources). If there is a time overlap between the resources, the WTRU may send a report to the network. The report may indicate the resource(s) scheduled by the WTRU that overlap with the network scheduled resource(s). The report may include one or more of the following: time information associated with the resource(s) scheduled by the WTRU or priority information associated with data that is associated with the resource(s) scheduled by the WTRU. The WTRU may send the report periodically and/or if a trigger condition occurs. A WTRU may send such report if (e.g., only if) the overlap occurs with resources which are actually scheduled by the NW, e.g., for the same WTRU. The gNB may schedule transmission in NR sidelink accordingly.

[0274] A WTRU may report information about the set of scheduled resource(s) in one RAT to the network.

[0275] A WTRU may have two RATs operating in the network-scheduled mode. Each RAT may be scheduled by a different BS. The WTRU may report information about the set of scheduled resource(s) in one RAT to the BS serving another RAT. The scheduled resource may be used for uplink or sidelink transmission. This approach may support one BS in avoiding the time resource scheduled by another BS.

[0276] For example, a WTRU may have two RATs in which NR sidelink and NR Uu are scheduled by a gNB whereas LTE sidelink and LTE Uu are scheduled by an eNB. The WTRU may report the set of scheduled resource(s) in LTE sidelink and LTE Uu to the gNB, e.g., to support the gNB in scheduling the transmission and/or reception resource for NR sidelink and NR Uu.

[0277] The timing when the WTRU performs reporting is described herein.

[0278] The WTRU may be configured to report information about the set of scheduled/reserved resource(s) in one RAT periodically. The WTRU may perform event-trigger reporting, e.g., when one or any combination of the following events occur: (1) the WTRU has data to transmit in one RAT; (2) the WTRU performs resource (re)selection in one RAT; (3) the WTRU receives sidelink or uplink grant(s); (4) the WTRU needs to send a scheduling request; (5) the WTRU needs to send a BSR; or (6) the WTRU changes its transmit resource pool and/or changes the zone ID.

[0279] A WTRU may perform event-triggered report when it performs resource selection. [0280] The WTRU may be triggered to report information about the set of selected resource(s) when the WTRU has data to transmit in UL or sidelink. Alternatively or additionally, the WTRU may be triggered to report information about the set of selected resource(s) in one RAT when the WTRU needs to send a SR and/or BSR. This approach may be motivated to support the network in having the updated information of the occupied resource when the network needs to perform scheduling.

[0281] A WTRU may perform event-trigger reporting when its receives grant(s) from a BS.

[0282] The WTRU may perform event-triggered reporting when it receives uplink and/or sidelink grant(s) from a BS. This approach may be motivated to support the scenarios in which two sidelink RATs are operating in network-scheduled mode. If the WTRU receives sidelink or uplink grant(s) scheduled by one BS, the WTRU may report information about the set of scheduled resource(s) to another BS, e.g., to support the BS in scheduling the sidelink and/or uplink grant(s) in its serving RAT.

[0283] A WTRU may perform event-trigger reporting when the network need to schedule the resources for it.

[0284] The WTRU may be triggered to report the information about the set of selected resource(s) when the WTRU performs a resource selection procedure. This approach may be motivated to help the network in having early information of the resource selected by the WTRU after the WTRU performs resource (re)selection.lt may help the network to prepare the unoccupied time resource for transmissions of network- scheduled RAT in advanced.

[0285] Types of messages to send the report are described herein.

[0286] The WTRU may send the report, which may include information about the set of

selected/scheduled resource(s), in a MAC CE. The MAC CE may be sent along with the sidelink BSR CE or in a different message. This example may be motivated in the case that the WTRU is triggered to report when it needs to send SR or BSR. When information about the set of selected/scheduled resource(s) in one RAT is sent along with sidelink BSR, the BS may have radio activity knowledge in one RAT on time to schedule sidelink or uplink resource in another RAT.

[0287] The WTRU may send the report, which may include information about the set of

selected/scheduled resource(s), in RRC messaging. This RRC message may be sent as one type of measurement report message. Alternatively or additionally, it may be a message similar to

WTRUAssistantlnformation (or UEAssistantlnformation), which may be defined to support the BS in scheduling. This approach may be motivated in the scenarios that the WTRU perform periodic reporting since RRC reporting may help the WTRU to report more information to the network.

[0288] Information in the report is described herein. [0289] The WTRU may report one or any combination of the following information about the set of selected/scheduled resource(s) within a reporting window: (1) the set of available time-frequency instant or time instant (e.g., time slot, subframe, etc.), within a resource pool/carrier/BWP, which may be not scheduled by the gNB or not selected by the WTRU; or (2) the set of scheduled/selected time-frequency instant or time instants within a resource pool/carrier/BWP, which may be scheduled by the gNB and/or selected the WTRU.

[0290] The reporting window may be configured by the network. Alternatively or additionally, it may be determined by the WTRU based on one or any combination of the QoS of the data in the buffer such as priority, latency, and/or reliability, the scheduled grant for reporting, or the like.

[0291] The WTRU may be configured to report time-frequency resource(s) (e.g., all time-frequency resource(s)) selected by the WTRU and/or scheduled by the BS in a resource pool/carrier/BWP. This approach may help the network having the full information of the transmission resource in one RAT to perform scheduling in another RAT. This approach may result in signaling overhead.

[0292] The WTRU may report the set of the time resource (e.g., time slot, subframe, etc.) selected by the WTRU and/or scheduled by the network. Alternatively or additionally, the WTRU may be configured with different sets of transmit resource pools in two RATs. The WTRU may be configured to report information about the set of selected/scheduled resource(s) in the overlapping time instants between two sets of transmit resource pool in two RATs. This approach may be motivated to reduce the reporting overhead since the frequency dimension of the selected/scheduled resource(s) may not be considered in the reporting.

[0293] A WTRU may consider the selected/scheduled resource of one RAT to perform resource selection in another RAT.

[0294] If the WTRU performs resource selection in one RAT, it may consider the selected/scheduled resource(s) in another RAT. When the WTRU performs resource selection in one or multiple resource pools/carrier/BWP in one RAT, it may consider the set of time instances (e.g., time slot, subframe, etc.) as unavailable/occupied if these time instants are overlapping with the time instant selected/scheduled by another RAT.

[0295] A WTRU may postpone resource selection in one RAT to prioritize resource selection or scheduling in another RAT.

[0296] When the WTRU needs to perform resource selection in two RATs simultaneously, the WTRU may postpone the resource selection procedure in one RAT until it has information of the resource selection in another RAT. The WTRU may determine the RAT to prioritize based on one or any combination of QoS parameters (e.g., priority, latency, reliability, of the data in each RAT), the bandwidth of carrier/BWP in each RAT, number of configured time instants (e.g., time slot, subframe, etc.) in the resource pool of each RAT, radio activities of the resource pool/carrier/BWP (e.g., CBR, in each RAT), type of RAT (e.g., NR sidelink vs. LTE sidelink), type of transmission (e.g., unicast/groupcast vs. broadcast), or the like.

[0297] The WTRU may determine to prioritize the resource selection of one RAT based on the priority and/or latency requirement of the data required for resource selection in each RAT. For example, the WTRU may postpone resource selection of one RAT if the data in its buffer has higher latency requirement and/or lower priority than the data in another RAT.

[0298] If the data in two RATs have the same or similar priority and/or latency requirement, the WTRU may prioritize the resource selection procedure in one RAT based on the bandwidth of carrier/BWP or radio activities of the resource pool/carrier/BWP in each RAT.

[0299] The WTRU may be configured to prioritize resource selection of LTE sidelink, e.g., since when used for safety application may be more prioritized than the advanced application. Alternatively or additionally, the WTRU may be configured to prioritize the resource selection of NR sidelink since the advanced application in NR sidelink may require more stringent QoS requirement.

[0300] A WTRU may postpone resource selection procedure in one RAT to prioritize a network scheduling in another RAT.

[0301] The WTRU may postpone its WTRU-scheduled resource selection to prioritize a network scheduling in another RAT. If the WTRU needs to perform WTRU-scheduled resource selection, it may postpone the selection until it receives the information about the resource scheduled by the network in another RAT. The WTRU may be configured to postpone its WTRU-scheduled resource selection based on one or any combination of the following: (1) the WTRU has data to transmit in another RAT; or (2) the WTRU sends SR/BSR in another RAT but has not received a sidelink grant.

[0302] Packet prioritization among two RATs are described herein. A WTRU may perform MAC PDU transmission and/or reception prioritization among the two RATs.

[0303] The WTRU may perform transmission and/or reception prioritization among two RATs when concurrent transmission and/or reception in two RATs are not allowed. The WTRU may perform transmission and/or reception prioritization by doing one or combination of the following: (1) the WTRU may drop one or multiple MAC PDUs; (2) the WTRU may reduce transmit power of one or multiple MAC PDUs; or (3) the WTRU may perform resource (re)selection of one or multiple MAC PDUs.

[0304] The WTRU may perform transmission and/or reception prioritization based on one or any combination of QoS parameters (e.g., priority, latency, reliability) of the data in each RAT, bandwidth of carrier/BWP in each RAT, number of configured time instants (e.g., time slot, subframe, etc.) in the resource pool of each RAT, radio activities of the resource pool/carrier/BWP (e.g., CBR) in each RAT, type of RAT (e.g., NR sidelink vs. LTE sidelink), type of link (e.g., NR UL, NR sidelink, LTE UL, LTE sidelink), type of scheduling mode (e.g., WTRU-scheduled vs. network-schedule), type of transmission (e.g., unicast/groupcast vs. broadcast, periodic vs. aperiodic), type of transmission (e.g., initial transmission vs. retransmission), size of the MAC PDU, or the like.

[0305] A WTRU may determine priority and latency requirement of a MAC PDU.

[0306] A WTRU may determine priority and latency of a unicast/groupcast MAC PDU.

[0307] The WTRU may be configured to determine the priority and latency requirement of the MAC PDU based on its associated radio bearer or logical channel. The WTRU may be configured with a set of priority and a latency requirement range for each radio bearer or logical channel. The priority and latency requirement of a MAC PDU may be determined as the highest priority and lowest latency value, respectively, of the configured set of priorities and latency requirement range.

[0308] A WTRU may determine priority and latency of a broadcast MAC PDU.

[0309] The WTRU may be configured to determine the priority and latency requirement of the MAC PDU based on the VQI value of the packet. The WTRU may be configured to associate one VQI value to a set of priority and a range of latency requirement range. The priority and latency requirement of the MAC PDU may be determined as the highest priority and lowest latency value, respectively.

[0310] A WTRU may determine priority and latency requirement of an LTE MAC PDU.

[0311] The WTRU may be configured to associate one or multiple prose per packet priority (PPPP) values to a range of latency requirement values. The latency requirement of a MAC PDU may be determined as the lowest value of the latency requirement range.

[0312] A WTRU may prioritize between LTE sidelink and NR sidelink.

[0313] The WTRU may be configured to prioritize between LTE sidelink and NR sidelink. The WTRU may perform packet prioritization which may include one or more of the following.

[0314] The WTRU may be configured to prioritize the MAC PDU with a lower latency requirement. If two MAC PDUs have similar latency requirements, the WTRU may be configured to prioritize the MAC PDU with higher priority. This approach may be motivated to prioritize transmission of the packet with more stringent latency requirement since if the WTRU deprioritizes the more stringent MAC PDU, the WTRU may not be able to find a suitable resource when it performs resource (re)selection procedure for the MAC PDU.

[0315] The WTRU may be configured to prioritize the MAC PDU with higher priority. If two MAC PDUs have the same priority, the WTRU may be configured to prioritize the packet with lower latency requirement value. This approach may be suitable for the case that the WTRU drop a packet or reduce transmission in the nonprioritized packet.

[0316] The WTRU may be configured to prioritize the MAC PDU with higher priority if the radio activities exceed a threshold. For example, if CBR in at least one resource pool/carrier/BWP of one RAT is greater than a threshold prioritize the MAC PDU with higher priority. Prioritize the MAC PDU with lower priority if the radio activities (e.g., CBR in both two resource pools/carriers/BWPs of two RATs) is smaller than a threshold. This approach may be motivated to guarantee that the WTRU can reselect another resource for higher priority packet.

[0317] The WTRU may be configured to map between a range of priority and latency values to a PPPP, which may have a similar meaning as PPPP in LTE V2X. The WTRU may be further configured to prioritize the packet with lower PPPP value.

[0318] The WTRU may be configured to prioritize the initial transmission of a MAC PDU over a retransmission. This approach may be motivated in the scenario that the WTRU may satisfy QoS requirement in the first transmission.

[0319] Embodiments that may reduce the half-duplex issue when transmitting in different RATs are described herein. A WTRU may adjust transmission parameters of one RAT based on radio activity of another RAT.

[0320] The WTRU may adjust transmission parameters of packets in one RAT such as the number of retransmissions, MCS, or the like, based on radio activities such as (channel occupancy ratio) CR and/or

CBR of one or multiple resource pools/carriers/BWPs in another RAT. This approach may be motivated to reduce the half-duplex issue. Based on CR of the WTRU in one resource pool/carrier/BWP, the WTRU may determine the reception capability of the surrounding WTRUs due to the half-duplex issue. The WTRU may determine to increase the number of retransmissions to reduce the half-duplex issue.

[0321] If the WTRU performs CBR measurement in one RAT, the WTRU may determine the time instant

(e.g., time slot, subframe, etc.) having transmission(s) in a set of carriers in another RAT as busy. The

WTRU may further adjust transmission parameters of the RAT based its measured CBR.

[0322] The WTRU may apply different priority in accessing different carrier/BWP.

[0323] The WTRU may apply different priority in accessing different resource pool/carrier/BWP, e.g., to avoid in-device coexistence (IDC) issue. Similar to LTE V2x, the WTRU may be (pre)configured to access a carrier/BWP if CBR of the carrier/BWP is smaller than a threshold CBR-PPPP, which may depend on the priority of the MAC PDU. The WTRU may further reduce the threshold CBR-PPPP to an amount d if the selection of the carrier/BWP may result in the IDC issue.The value of d applied for a carrier/BWP may depend on the frequency distance between this carrier/BWP and the closet carrier/BWP in another RAT. [0324] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate 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 incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, 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.

[0325] Although the features and elements may be described herein in particular combinations, each feature or element may be used alone, without the other features and elements, and/or in various combinations with or without other features and elements. Although the features and elements described herein may consider New Radio (NR), 5G or LTE, LTE-A protocols, such features and elements described herein may not be restricted to such scenarios and are applicable to other systems/wireless systems.

Claims

CLAIMS What is Claimed:

1. A wireless transmit/receive unit (WTRU), comprising:

a memory; and

a processor, the WTRU being configured at least in part to:

receive a configuration that configures the WTRU to report an overlapping resource associated with sidelink communication;

if the WTRU is configured to operate with a network scheduled resource for sidelink

communication and a resource scheduled by the WTRU for sidelink communication, determine if there is a time overlap between the network scheduled resource and the resource scheduled by the WTRU; and

if there is the time overlap between the network scheduled resource and the resource scheduled by the WTRU, send a report to a network entity that indicates the resource scheduled by the WTRU that overlaps with the network scheduled resource, wherein the report comprises time information associated with the resource scheduled by the WTRU and priority information associated with data that is associated with the resource scheduled by the WTRU.

2. The WTRU of claim 1 , wherein the WTRU is configured to send the report according to at least one of the following: if an event occurs or periodically.

3. The WTRU of claim 2, wherein the event occurs if the WTRU performs reselection of the resource scheduled by the WTRU.

4. The WTRU of claim 2, wherein the WTRU reports the resource scheduled by the WTRU if there is a time overlap between an active network scheduled resource and the WTRU scheduled resource.

5. The WTRU of claim 2, wherein the event occurs if the WTRU needs to send at least one of a scheduling request (SR) or a buffer status report (BSR).

6. The WTRU of claim 3, wherein the report is sent in a medium access control (MAC) control element (CE).

7. The WTRU of claim 1 , wherein the network scheduled resource and WTRU scheduled resource may be associated with a same radio access technology or a different radio access technology.

8. A method, comprising:

receiving a configuration that configures the WTRU to report an overlapping resource associated with sidelink communication;

communication and a resource scheduled by the WTRU for sidelink communication, determining if there is a time overlap between the network scheduled resource and the resource scheduled by the WTRU; and

if there is the time overlap between the network scheduled resource and the resource scheduled by the WTRU, sending a report to a network entity that indicates the resource scheduled by the WTRU that overlaps with the network scheduled resource, wherein the report comprises time information associated with the resource scheduled by the WTRU and priority information associated with data that is associated with the resource scheduled by the WTRU.

9. The method of claim 8, wherein the WTRU is configured to send the report according to at least one of the following: if an event occurs or periodically.

10. The method of claim 9, wherein the event occurs if the WTRU performs reselection of the resource scheduled by the WTRU.

11 . The method of claim 9, wherein the WTRU reports the resource scheduled by the WTRU if there is a time overlap between an active network scheduled resource and the WTRU scheduled resource.

12. The method of claim 9, wherein the event occurs if the WTRU needs to send at least one of a scheduling request (SR) or a buffer status report (BSR).

13. The method of claim 10, wherein the report is sent in a medium access control (MAC) control element (CE).

14. The method of claim 8, wherein the network scheduled resource and WTRU scheduled resource may be associated with a same radio access technology or a different radio access technology.