Method and apparatus for sidelink communication

Abstract

Methods and apparatus for sidelink (SL) communication are disclosed herein. A method performed by a wireless transmit / receive unit (WTRU) for SL communication may include determining to transmit sidelink control information (SCI) over a physical sidelink control channel (PSCCH). The method may also include selecting one or more sub-channels from a physical sidelink shared channel (PSSCH), and allocating time and frequency resources for the PSCCH in the one or more sub-channels. The method may also include allocating time and frequency resources within the PSCCH to transmit the SCI therein. The allocation of time and frequency resources may be based on at least one of an SCI format type, a Layer 1 (L1) identifier (ID), a priority, or a Quality of Service (QoS) requirement. The method may also include transmitting the SCI over the determined time and frequency resources.

Description

[0001] This application is a divisional application of the Chinese invention patent application with application date of February 21, 2020, application number 202080017233.6, and invention name “Method for NR SL multi-subchannel PSCCH transmission”.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims the benefit of U.S. Provisional Application No. 62 / 909,022, filed October 1, 2019, U.S. Provisional Application No. 62 / 886,505, filed August 14, 2019, and U.S. Provisional Application No. 62 / 809,317, filed February 22, 2019, the contents of which are incorporated herein by reference. Background Art

[0004] In the 3GPP standard for Long Term Evolution (LTE) wireless technology, the vehicle-to-everything (V2X) channel bandwidth may be partitioned into a set of subchannels, and the size of the subchannels may be configured by the network. For example, the size may be 4, 5, 6, 8, 9, 10, 12, 15, 16, 18, 20, 25, 30, 48, or 50 resource blocks (RBs). An LTE V2X wireless transmit / receive unit (WTRU) may apply one or more subchannels to transmit a physical sidelink shared channel (PSSCH) based on parameters including transport block (TB) size, subchannel configuration, and / or modulation and coding scheme (MCS). Due to the use of discrete Fourier transform-spread-orthogonal frequency division multiplexing (DFT-s-OFDM) in LTE, all subchannels used for one PSSCH must be contiguous.

[0005] The associated PSCCH is transmitted in the same subframe and is frequency division multiplexed (FDMed) with the PSSCH. The network can signal two configurations of PSSCH and one or more associated PSCCH transmissions. One is adjacent physical sidelink control channel (PSCCH) and PSSCH transmissions. The PSSCH and its associated PSCCH are transmitted in adjacent RBs, and in this case, the PSCCH is transmitted in the first two RBs of the subchannel with a lower index for the PSSCH. The other configuration is a non-adjacent arrangement of PSCCH and PSSCH transmissions. The PSSCH is transmitted in a subchannel and its associated PSCCH is transmitted in a separate pool located at one edge of the channel. It should be noted that the non-adjacent configured PSCCH occupies two RBs.

[0006] For NR V2X, cyclic prefix OFDM (CP-OFDM) is supported and, as a result, non-contiguous NR PSSCH frequency resource allocation may become feasible. NR PSSCH resource allocation is based on a set of multiplexing configurations between sub-channels and PSSCH and associated PSCCH. For NR V2X, both TDM and FDM configurations are currently under consideration. In one time division multiplexing (TDM) configuration, the PSCCH and the associated PSSCH are transmitted using non-overlapping time resources, and the frequency resources used by the two channels are the same or different. In another TDM configuration, a portion of the PSCCH and the associated PSSCH are transmitted using overlapping time resources in the non-overlapping frequency resources, but another portion of the associated PSSCH and / or another portion of the PSCCH are transmitted using non-overlapping time resources.

[0007] In LTE V2X, broadcast transmissions and periodic traffic patterns are supported, with transmission packet sizes varying between 50-300 bytes. However, NR V2X supports a set of advanced use cases with widely varying traffic patterns and associated QoS requirements. Certain NR V2X use cases have much larger packet sizes and lower latency than LTE requirements, for example, NR V2X packet sizes can be between 30,000 and 60,000 bytes, and latency can be as low as 3ms. In addition, in addition to broadcast transmissions, NR V2X adds support for unicast and multicast transmissions, which may require high reliability, and link adaptation of NR PSCCH becomes important. Therefore, in order to deliver the high capacity and reliability and low latency required for various types of NR V2X transmissions, certain aspects may be addressed by the NR PSCCH design. Summary of the invention

[0008] Disclosed herein are methods and apparatus for sidelink (SL) communications. A method for SL communications performed by a wireless transmit / receive unit (WTRU), the method may include determining to transmit sidelink control information (SCI) via a physical sidelink control channel (PSCCH). The method may further include selecting one or more subchannels from a physical sidelink shared channel (PSSCH) in which time and frequency resources are allocated for the PSCCH. The method may further include allocating time and frequency resources within the PSCCH to transmit the SCI therein. The allocation of time and frequency resources may be based on at least one of an SCI format type, a layer 1 (L1) identifier (ID), a priority, or a quality of service (QoS) requirement. The method may also include transmitting the SCI via the determined time and frequency resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The present invention may be understood in more detail from the following description given by way of example in conjunction with the accompanying drawings, in which like reference numerals represent like elements, and in which:

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

[0011] Figure 1B is a diagram showing that according to an embodiment, Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) used in a communication system is shown;

[0012] Figure 1C is a diagram showing that according to an embodiment, Figure 1A A system diagram of an example radio access network (RAN) and an example core network (CN) used within a communication system as shown in FIG.

[0013] Figure 1D is a diagram showing that according to an embodiment, Figure 1A A system diagram of another example RAN and another example CN used within the communication system shown in;

[0014] Figure 2 Provides an overview of multi-subchannel PSSCH transmission;

[0015] Figure 3 Describing determination of PSCCH resources by a WTRU based on one or more parameters;

[0016] Figure 4 is an example representation of conditions under which a WTRU may select one or more PSSCH subchannels (including PSCCH_1 and PSCCH_2 resources);

[0017] Figure 5 Various examples of PSCCH_1 and PSCCH_2 resource arrangements in contiguous and non-contiguous PSSCH subchannels are described; and

[0018] Figure 6 It is shown that the PSCCH resources are determined from the SL resources. DETAILED DESCRIPTION

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

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

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

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

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

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

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

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

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

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

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

[0030] The RAN 104 may be in communication with the CN 106, 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 different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform advanced security functions, such as user authentication. Although in Figure 1AAlthough not shown, it will be appreciated that the RAN 104 and / or CN 106 may be in direct or indirect communication with other RANs that employ the same RAT or a different RAT as the RAN 104. For example, in addition to being connected to the RAN 104, which may utilize NR radio technology, the CN 106 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

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

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

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

[0034] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal decoding, 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. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

[0036] Although the transmit / receive element 122 is Figure 1B Although depicted as a single element in the embodiment, 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.

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

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

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

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

[0041] The processor 118 may also be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, Module, FM radio unit, digital music player, media player, video game player module, Internet browser, virtual reality and / or augmented reality (VR / AR) device, activity tracker, etc. Peripheral device 138 may include one or more sensors. The sensor 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 posture sensor, a biometric sensor, a humidity sensor, etc.

[0042] The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., signals associated with specific subframes for UL (e.g., for transmission) and DL (e.g., for reception)) may be concurrent and / or simultaneous. A full-duplex radio may include an interference management unit that reduces and / or substantially eliminates self-interference by means of hardware (e.g., chokes) or by signal processing by a processor (e.g., a separate processor (not shown) or by the processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio for transmitting and receiving some or all signals (e.g., signals associated with specific subframes for UL (e.g., for transmission) or downlink (e.g., for reception)).

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

[0044] 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 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, for example, the eNode-B 160a may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

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

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

[0047] 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.

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

[0049] 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.

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

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

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

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

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

[0055] A high throughput (HT) STA may communicate using a 40 MHz wide channel, for example, by combining a primary 20 MHz channel with an adjacent or non-adjacent 20 MHz channel to form a 40 MHz wide channel.

[0056] Very high throughput (VHT) STA can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz and / or 80MHz channels can be formed by combining adjacent 20MHz channels. 160MHz channels can be formed by combining 8 consecutive 20MHz channels or by combining two discontinuous 80MHz channels, which can be referred to as 80+80 configuration. For 80+80 configuration, after channel coding, data can be transmitted and passed through a segment parser, which can divide the data into two streams. Each stream can be processed by inverse fast Fourier transform (IFFT) and time domain processing respectively. The stream can be mapped to two 80MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operation of the above 80+80 configuration can be reversed, and the combined data can be sent to the media medium control (MAC).

[0057] The operating mode below 1 GHz is supported by 802.11af and 802.11ah. The channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah relative to the channel operating bandwidth and carrier used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz and 20MHz bandwidths in the TV white space (TVWS) spectrum, while 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz and 16MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support instrument type control / machine type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, for example, including limited capabilities for support (e.g., only support) for certain and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain a very long battery life).

[0058] A WLAN system that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, includes a channel that can be designated as a primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by the STA among all STAs operating in the BSS (which supports the minimum bandwidth operating mode). In the example of 802.11ah, for STAs (e.g., MTC-type devices) that support (e.g., only support) 1MHz mode, the primary channel may be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy (e.g., due to a STA (which only supports the 1MHz operating mode) transmitting to the AP), all available bands may be considered busy, even if most of the available bands remain idle.

[0059] In the United States, the available frequency band that 802.11ah can use is from 902MHz to 928MHz. In South Korea, the available frequency band is from 917.5MHz to 923.5MHz. In Japan, the available frequency band is from 916.5MHz to 927.5MHz. Depending on the country code, the total bandwidth available for 802.11ah is 6MHz to 26MHz.

[0060] Figure 1D1 is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As described above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using NR radio technology. The RAN 104 may also be in communication with the CN 106.

[0061] The RAN 104 may include gNBs 180a, 180b, 180c, but it should be understood that the RAN 104 may include any number of gNBs while remaining consistent with the embodiment. Each of the gNBs 180a, 180b, 180c includes one or more transceivers for communicating with the WTRUs 102a, 102b, 102c via the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 180b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Therefore, the gNB 180a may, for example, use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a. In one embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit a plurality of component carriers (not shown) to the WTRU 102a. A subset of these component carriers may be on an unlicensed spectrum, while the remaining component carriers may be on a licensed spectrum. In one embodiment, the gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) technology. For example, the WTRU 102a may receive coordinated transmissions from the gNB 180a and the gNB 180b (and / or the gNB 180c).

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

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

[0064] 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, user scheduling in UL and / or DL, support network slicing, interworking between DC, NR and E-UTRA, route user plane data to a user plane function (UPF) 184a, 184b, route control plane information to an access and mobility management function (AMF) 182a, 182b, etc. Figure 1D As shown, gNBs 180a, 180b, and 180c may communicate with each other via an Xn interface.

[0065] Figure 1DThe CN 106 shown in FIG. 1 may include at least one of the AMFs 182a, 182b, at least one of the UPFs 184a, 184b, at least one of the session management functions (SMFs) 183a, 183b, and possible data networks (DNs) 185a, 185b. Although the aforementioned elements are depicted as part of the CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

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

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

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

[0070] Given that Figures 1A-1D and Figures 1A-1D In accordance with the corresponding description of the present invention, one or more or all of the functions described herein with respect to one or more of the following items may be performed by one or more simulation devices (not shown): WTRU 102a-d, base station 114a-b, eNodeB 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 (one or more) described herein. These simulation devices may be one or more devices configured to simulate one or more or all of the functions described herein. For example, the simulation device may be used to test other devices and / or simulate network and / or WTRU functions.

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

[0072] One or more simulation devices can perform one or more functions (including all functions) without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test lab and / or in a test scenario in which a wired and / or wireless communication network is not deployed (e.g., testing) to implement testing of one or more components. One or more simulation devices can be test devices. The simulation device can transmit and / or receive data using direct RF coupling and / or via RF circuits (e.g., which can include one or more antennas) and / or wireless communications.

[0073] In LTE V2X, broadcast transmissions and periodic traffic modes are supported, where the transmission packet size varies between 50-300 bytes. However, NR V2X supports a set of advanced use cases with widely different traffic modes and associated quality of service (QoS) requirements. Certain NR V2X use cases may employ much larger packet sizes and require lower latency than LTE scenarios. For example, the NR V2X packet size can be between 30,000 and 60,000 bytes, and the latency can be as low as 3ms. In addition, in addition to broadcast transmissions, NR V2X adds support for unicast and multicast transmissions that may require high reliability, and link adaptation of NR PSCCH transmissions may become important. Therefore, in order to deliver high capacity and reliability as well as the low latency required for various types of NR V2X transmissions, the NR PSCCH design may address certain aspects of the existing LTE V2X design and the proposed NR V2X design.

[0074] For example, LTE specifies a fixed number of PSCCH time resources. LTE PSCCH resource allocation always uses one subframe (14 symbols) and two RBs for PSSCH transmission, and does not (for example) vary depending on the transmission type or QoS parameters. Such a fixed amount of PSCCH resources may not be able to meet the range of NR V2X QoS requirements and achieve high resource utilization efficiency. NR PSCCH design may need to provide flexible NR PSCCH resource configuration, and through this configuration, the total PSCCH resources can vary in the frequency domain (e.g., the number of RBs) and the time domain (e.g., the number of symbols occupied in one time slot). In addition, LTE specifies a fixed PSCCH frequency resource layout.

[0075] LTE PSCCH frequency resources may be placed at the first two RBs of the subchannel with the lowest subchannel index allocated for the associated PSSCH transmission. With this allocation, the PSCCH cannot exploit channel frequency diversity as the LTE and NR air interface (Uu) PDCCH do. Due to the potentially large TB sizes, NR PSSCH transmissions may occupy a large amount of frequency resources, and by using cyclic prefix orthogonal frequency division multiplexing (CP-OFDM) in NR V2X, the allocated PSSCH frequencies may be non-contiguous. Thus, NR V2X transmissions may have a high degree of frequency diversity for PSCCH (especially for large TB transmissions).

[0076] The proposed NR PSCCH and PSSCH designs may require high signaling overhead due to the use of time division multiplexing for PSCCH and / or PSSCH transmissions. When PSSCH transmissions occupy non-contiguous frequency resources (e.g., non-contiguous sub-channel groups), the TDM configuration currently discussed for NR V2X PSCCH / PSSCH multiplexing may require the use of PSCCH transmissions for each different set of PSSCH frequency resources. This may increase the control channel overhead, especially when the PSSCH transmission frequency resource allocation is segmented.

[0077] This document describes solutions for PSCCH resource determination. Specifically, for sidelink (SL) transmission, one or more SL resource pools may be used, configured, or determined. A resource pool may be a set of subchannels for sidelink transmission. The term "resource pool" may be used interchangeably with "pool," "resource set," "sidelink resource pool," or "SL resource pool." When determining a sidelink resource pool, one or more solutions may be applied.

[0078] For example, in some solutions, a set of subchannels may be determined, defined, or used in a sidelink bandwidth part (BWP), where the number of subchannels used for the SL BWP may be determined based on one or more parameters. These parameters may include the frequency band of the SL BWP (e.g., the number of RBs used for the SL BWP and / or the parameter configuration used), the parameter configuration (e.g., the subcarrier spacing), or the number of reserved resources (e.g., resource blocks (RBs) and / or symbols). The reserved RBs and / or symbols may be a number of RBs that fall within the SL BWP but are not used for sidelink link transmissions. The reserved resources (RBs or symbols) may be referred to as rate matching resources.

[0079] In some solutions, one or more resource pools may be configured, and the resource pool may include one or more subchannels. The associated subchannels for the resource may be determined based on one or more parameters. Such parameters may include the number of configured resource pools. In one scenario, multiple subchannels of a resource pool may be evenly distributed between multiple configured resource pools. For example, such a subchannel distribution may be expressed as N_subpool=floor(N_sub / N_pool), where N_subpool represents the number of subchannels per pool, N_subpool represents the number of subchannels within the SL BWP, and N_pool represents the number of pools configured for the SL BWP. The associated subchannels for the resource may be determined by a higher layer configuration. For example, for each resource pool configuration, the gNB may configure a set of subchannels associated with the pool.

[0080] In one solution, one or more resource pools may be configured for the SL BWP, and one or more attributes may be configured for each resource pool. One configuration attribute for a resource pool may be a subchannel configuration. The configuration may include, for example, a set of subchannels, or a PSCCH and PSSCH multiplexing scheme. For example, one or more PSCCH and PSSCH multiplexing schemes may be used, and the multiplexing scheme used or to be used may be indicated in the configuration. The PSCCH and PSSCH multiplexing schemes configured for each of the one or more resource pools may include, but are not limited to, time domain and / or frequency domain multiplexing. The configuration attributes for each resource pool may include one or more quality of service (QoS) thresholds. For example, if the QoS of the sidelink transmission is lower than the QoS threshold associated with the resource pool, the source WTRU may not use or be allowed to use the resource pool. If the QoS of the sidelink transmission is not lower than the QoS threshold, the source WTRU may use the resource pool to transmit PSCCH or PSSCH transmissions. The QoS parameters may include PPPP (priority), PPPR (reliability), and / or range, and the thresholds may be configured separately for each QoS parameter. In one example, if any one QoS parameter does not exceed the threshold, the source WTRU may not be allowed to use the resource pool.

[0081] The configuration attributes for each resource pool may include one or more service types, such as unicast, groupcast, or broadcast, and the service type may be determined based on one or more of the RNTI used to scramble the CRC of the SCI for the PSCCH, the SCI format, or the content of the SCI. The configuration attributes for each resource pool may include one or more demodulation reference signal (DM-RS) configurations for one or more PSCCH, PSSCH, and / or PSFCH transmissions, which may include type 1 mapping or type 2 mapping, DM-RS time and / or frequency density; or the configuration attributes for each resource pool may include the maximum Doppler frequency supported.

[0082] A maximum Doppler frequency D_max may be configured, and if the maximum Doppler frequency for a link (e.g., the relative Doppler frequency of the two WTRUs) is above this maximum value, the source WTRU may not use or may not be allowed to use the resource pool. In some embodiments, the maximum Doppler frequency limit or restriction may only be used for unicast traffic.

[0083] The configuration attributes for each resource pool may include a configuration to enable or disable HARQ feedback. Alternatively, one or more physical sidelink feedback channels (PSFCH) may be present in a resource pool or in a time slot. The configuration attributes for each resource pool may specify the mode of the resource pool. For example, if the subchannels within a resource pool are configured with continuous RBs, the resource pool may be configured for localized mode. If the subchannels within a resource pool are configured with non-contiguous RBs, the resource pool may be configured for distributed mode. The configuration attributes for each resource pool may specify whether the resource pool is a transmitter pool or a resource pool, that is, whether the resource pool is used for sidelink transmission or reception.

[0084] In the solution described herein, the WTRU may determine one or more SL resources for PSCCH transmission. The subchannels through which PSCCH transmission may be performed may be defined, determined, configured or used based on one or more of a set of continuous RBs (or non-continuous) in a frequency within a carrier and / or bandwidth part (BWP) or a set of continuous or non-continuous symbols within a time slot, where the symbols may be DFT-s-OFDM or CP-OFDM symbols.

[0085] A subchannel through which PSCCH transmission may be performed may be defined, determined, configured, or used based on an associated DM-RS configuration such as a type 1 DM-RS mapping or a type 2 DM-RS mapping, and based on the associated DM-RS configuration, the density of the DM-RS in frequency and / or time may be different.

[0086] A subchannel through which PSCCH transmission may be performed may be defined, determined, configured, or used based on a scrambling sequence for DM-RS (eg, for PSCCH, PSSCH, and / or PSFCH transmission), and the scrambling sequence may be initialized based on a subchannel index.

[0087] A solution for determining subchannels for PSCCH transmission is described herein. Figure 2 An overview of a multi-subchannel PSSCH transmission is provided. The WTRU may determine a set of SL resources to apply in one SL time resource, such as a time slot for a PSSCH transmission within one SLTB, in which one SL TB is transmitted. The selected SL resources may be contiguous or non-contiguous, such as Figure 2 In the continuous PSSCH shown at 220, multiple continuous subchannels may be used. In the non-continuous PSSCH shown at 210, the subchannels may be distributed in a SL resource pool 230, which may be defined with a specific bandwidth. The WTRU may determine such a set of SL resources based on the resource availability determined during the sensing process.

[0088] In the PSSCH subchannels, i.e., in the subchannels determined for PSSCH transmission, the WTRU may determine one or more PSSCH subchannel sets from which PSCCH resources for associated PSCCH transmissions are included. For example, subchannel 231 may define a frequency resource within the PSSCH over which the PSCCH transmission is sent. The SL resource pool may additionally include defined SL time resources 232. The subchannel determination may include, for example, one PSSCH subchannel for one associated PSCCH, which may be used for a primary SCI transmission; a set of PSSCH subchannels for one associated PSCCH, which may be used for a primary SCI transmission; one PSSCH subchannel for two associated PSCCHs (PSCCH_1 and PSCCH_2), which may be used for a two-level SCI transmission; or a set of PSSCH subchannels for two associated PSCCHs (PSCCH_1 and PSCCH_2), which may be used for a two-level SCI transmission. In the latter case, the WTRU may determine the subchannels to use for PSCCH_1 and PSCCH_2 based on different rules or parameters.

[0089] These parameters may include, for example, the SCI format type carried in the PSCCH (e.g., unicast SCI, multicast SCI, or broadcast SCI), the SCI containing WTRU common information (e.g., the first SCI in a two-stage SCI transmission), or the SCI containing WTRU specific information (e.g., the second SCI in a two-stage SCI transmission).

[0090] The parameters may include SL BWP configuration; PHY ID, which may be a source ID, destination ID or HARQ process ID configured by higher layers; link ID, group ID or service ID, any of which may provide a link index that the WTRU can use to distinguish between multiple established unicast, multicast and broadcast transmissions, or a service ID that the WTRU can use to distinguish between the broadcast transmission service it has subscribed to; associated SL transmission QoS parameters, such as priority, reliability or latency and range; subchannel conditions, which may be based in whole or in part on SL feedback information (CQI / PMI / RI), WTRU positioning information, WTRU mobility information, Doppler estimation, channel reciprocity, LOS detection, or any combination thereof; or a beamforming configuration, such as a spatial domain transmit filtering configuration for PSCCH resources in frequency range 2 (FR2) operation.

[0091] In some solutions, the WTRU may select a PSSCH subchannel in which the PSCCH resources are included based on the SCI format type.

[0092] To schedule a broadcast SCI transmission or an SCI transmission containing WTRU common information, the WTRU may select the PSSCH subchannel with the lowest subchannel index among contiguous and non-contiguous PSSCH transmissions. In another solution, the WTRU may select a PSSCH subchannel from the center of the frequency resource of the PSSCH transmission over which to transmit such SCI.

[0093] From the resource pool, the WTRU may select a first subchannel set for PSSCH transmission, and the WTRU may select a second subchannel set for PSCCH transmission. The PSCCH transmission may be associated with the PSSCH transmission and may include, for example, scheduling information for the PSSCH. The second subchannel set may be a subset of the first subchannel set. One or more characteristics may apply to one or both of the first or second subchannel sets. The second subchannel set may be the subchannels with the lowest or highest subchannel index, and the subchannel index may be determined based on an increasing or decreasing order of the subchannels in the frequency domain. The second subchannel set may be determined based on one or more system parameters, including but not limited to a time slot number, a subframe number, a physical cell ID, a carrier ID, or a radio frame number such as an SFN. The second subchannel set may be determined based on the number of subchannels selected, determined, used, or scheduled for the first subchannel set.

[0094] In another solution, one or more PSCCHs may be used to transmit scheduling information for PSSCH transmissions. The WTRU may select a first set of subchannels to transmit scheduling information for PSSCH transmissions, and the WTRU may determine a second set of subchannels for one or more PSCCH transmissions associated with the scheduled PSSCH. The WTRU may make such a determination based on one or more criteria as disclosed herein.

[0095] For example, the subchannel used for the first PSCCH may be referred to as PSCCH-1, which may be determined based on one or more common parameters for the WTRU group. The one or more common parameters may include, but are not limited to, a subchannel ID, or a first subchannel ID when multiple subchannels are scheduled or used for PSSCH transmissions; a set ID of the first set of subchannels, where one or more set IDs may be used to schedule transmissions over a PSSCH having one or more subchannels; or a timeslot number or a subframe number.

[0096] In some embodiments, the subchannels for the first PSCCH may be transmitted in predetermined frequency locations, which may be, for example, a set of RBs starting from a first RB within a first set of subchannels.

[0097] In some embodiments, the subchannel used for the second PSCCH may be referred to as PSCCH-2, which may be determined based on one or more WTRU-specific parameters. Such WTRU-specific parameters may include, but are not limited to, link identification, source WTRU or destination WTRU ID; service type; QoS parameters, range parameters, and DM-RS configuration for PSSCH transmission.

[0098] The link identifier may be determined as a function of the source ID and the destination ID. Hereinafter, the term "source ID" may be used interchangeably with the terms "transmitter ID", "TX ID" and / or "source WTRU ID". In addition, the term "destination ID" may be used interchangeably with the terms "receiver ID", "Rx-ID" and / or "destination WTRU ID". In some embodiments, if the source ID and the destination ID have the same length, the function to determine the link identifier may be an XOR operation of the source ID and the destination ID. In some embodiments, the link identifier may be a combination of the source ID and the destination ID. In some embodiments, the link identifier may be assigned by the gNB based on the source ID and the destination ID. For example, a number may be assigned to the link between the source ID and the destination ID.

[0099] The service type can be determined based on the RNTI associated with the SCI. For example, a unicast service can use a first RNTI (e.g., U-RNTI), which can be scrambled using the cyclic redundancy code (CRC) of the SCI. A multicast service can use a second RNTI (e.g., G-RNTI), which can be scrambled using the CRC of the SCI. A broadcast service can use a third RNTI (e.g., B-RNTI), which can be scrambled using the CRC of the SCI. In some embodiments, the service type can be determined based on one or more SCI formats. In this case, the first SCI format can be used for unicast services, the second SCI format can be used for multicast services, and the third SCI format can be used for broadcast services.

[0100] For the above solution, if a single PSCCH transmission is used to schedule a PSSCH transmission, the PSCCH transmission may be the first PSCCH transmission or the second PSCCH transmission, but may still be consistent with the embodiments disclosed herein.

[0101] In the solution disclosed herein, the WTRU may select a PSSCH subchannel in which the PSCCH resources are included based on the SL BWP configuration. The WTRU may determine the PSCCH resources based on one or more parameters as described above, such as Figure 3As shown in the example in . At 301, the WTRU may begin subchannel selection for PSCCH_1 and PSCCH_2 resources. As shown at 310, the WTRU may determine whether one or more QoS parameters (e.g., priority PPPP or range PPPR) exceed a configured threshold. If so, then at 311, the WTRU may select each PSSCH subchannel in which PSCCH_1 and PSCCH_2 resources are included, substantially as described above. If the QoS parameters do not exceed the preconfigured threshold, then at 320 the WTRU may determine whether the SCI to be transmitted is a broadcast SCI. If so, then at 321, the WTRU may select a subchannel with a lower index. If the SCI to be transmitted is not a broadcast SCI (i.e., the SCI will be unicast or multicast), then at 330, the WTRU may determine whether the PSSCH subchannel selected from it is a continuous subchannel. If so, then at 340, the WTRU further evaluates whether the total PSSCH bandwidth is less than the threshold. If yes, the WTRU may select a PSSCH subchannel based on at least one of the PHY ID or the link ID, as shown at 331. If the subchannels of the PSSCH are not contiguous, or the total PSSCH BW meets or exceeds the threshold, then at 332, the WTRU may select the PSSCH subchannel with the best channel condition based on CSI feedback or reciprocity.

[0102] A WTRU may be configured with at least one sidelink BWP and one or more air interface (Uu) BWPs. The at least one sidelink BWP may be used for sidelink transmissions and the one or more Uu BWPs may be used for Uu transmissions.

[0103] In some embodiments where one or more SL BWPs are configured, a first SL BWP may be used for sidelink transmissions when the WTRU is in coverage or performing a sidelink transmission in coverage, and a second SL BWP may be used for sidelink transmissions when the WTRU is out of coverage or performing a sidelink transmission out of coverage. In other embodiments, the SL BWP may be used for both sidelink transmissions in coverage and sidelink transmissions out of coverage.

[0104] In some embodiments, one or more SL BWP types may be used. For example, a first SL BWP type may be used for in-coverage link transmissions, while a second SL BWP type may be used for out-coverage link transmissions. In some cases, the DM-RS type (e.g., type 1 DM-RS mapping or type 2 DM-RS mapping) or subchannel configuration (e.g., local or distributed subchannels) may be determined based on the SL BWP type. In some embodiments, the SL BWP may overlap completely or partially with one or more UuBWPs. The SL BWP may be configured within a default BWP, or coextensive with the default BWP, and the default BWP may include an SSB for the UU.

[0105] In one solution, when the WTRU is configured with a SL BWP that overlaps with the Uu BWP, the WTRU may select one or more PSSCH subchannels that are not located in the Uu BWP. One or more of the following cases may apply. In one case, when the SL BWP partially overlaps with the Uu BWP, which may be the default BWP, the SL resources overlapping with the Uu BWP and the SL resources that do not overlap with the Uu BWP may be used or processed differently. For example, the SL resources overlapping with the Uu BWP may be referred to as first SL resources, and the SL resources that do not overlap with the Uu BWP may be referred to as second SL resources. The SL resources may be subchannels or resource pools. The first SL resources and the second SL resources may be associated with separate QoS limits or thresholds. For example, the first SL resource may be associated with a first QoS threshold, and the second SL resource may be associated with a second QoS threshold. The QoS threshold may be a minimum required QoS parameter value that specifies, for example, that the sidelink transmission should be above a given value in order to use the associated SL resources. In some embodiments, the first QoS limit may be higher than the second QoS limit. Thus, a WTRU or node configured to perform sidelink transmissions with varying priorities may use a first SL resource when the associated QoS parameter is above a threshold. Otherwise, a second SL resource may be used for sidelink transmissions.

[0106] In some embodiments, the first SL resource and the second SL resource can be associated with a use case, such as an in-coverage or out-of-coverage scenario. For example, the first SL resource can be used for sidelink transmission within the coverage area, while the second SL resource can be used for sidelink transmission outside the coverage area. Use cases may include, but are not limited to, vehicle platooning, advanced driving, extended sensors, or remote driving, and each use case may have different required values, such as latency, reliability, or data rate values.

[0107] In some cases, the first SL resource or the second SL resource may be used based on at least one of the following factors: WTRU speed or relative speed; area ID for the source WTRU; QoS parameters; whether the sidelink transmission is in-coverage transmission or out-of-coverage transmission; or PSCCH or PSSCH.

[0108] In another solution, when the SL BWP overlaps with the Uu BWP, the SL resources overlapping with one or more Uu physical channels can be considered as reserved resources for use. For example, SL resources overlapping with SSBs for Uu (e.g., Uu-SSBs) can be reserved or considered as invalid sidelink resources. Uu physical channels can include SSBs; PDCCH common search spaces; or group common PDCCHs. The SL BWP can overlap with the UL BWP completely or partially.

[0109] In the solution described herein, the WTRU may select one or more PSSCH subchannels in which PSCCH resources are included based on QoS parameters associated with the PSSCH. A subchannel may be the smallest sidelink resource unit for PSSCH transmission. One or more subchannels may be used for PSSCH transmission. One or more of the following configurations may be applied.

[0110] For example, each subchannel may include an associated PSCCH resource, and the associated PSCCH may be located within a PSSCH frequency resource.The associated PSCCH resources in each subchannel may be preconfigured or predetermined, for example, to be the first N RBs or the first M symbols in the subchannel.

[0111] In another example, when multiple subchannels are used for PSSCH transmission, the associated PSCCH transmission may be transmitted via a subset of the subchannels used for PSSCH transmission. In some cases, the subset of subchannels may be the same set of subchannels used for PSSCH transmission.

[0112] In some cases, the subset of subchannels may be smaller than the subchannel used for PSSCH transmission. In another example, the PSCCH resources in a PSSCH subchannel may be referred to as a PSCCH resource unit (RU). The PSCCH may be configured with an aggregation level (AL), which may, for example, specify the number of control channel elements (CCEs) allocated for the PSCCH. For example, if a single PSCCH RU is used, the PSCCH AL may be 1, or if N PSCCH RUs are used, the PSCCH AL may have a value of N. In some embodiments, if M subchannels are used for PSSCH transmission, up to M PSCCH aggregation levels may be used.

[0113] In one solution, when a QoS parameter associated with a TB exceeds a configured or preconfigured threshold, the WTRU may select a PSSCH subchannel to include PSCCH resources. The QoS parameter may be, for example, a reliability indication in PPPR, a priority or range indicated in PPPP. In one example, the WTRU may transmit one or more repetitions of the associated PSCCH in each selected subchannel.

[0114] In some embodiments, the WTRU may select all subchannels of the PSSCH to include PSCCH resources. In other solutions, the WTRU may determine a subset of PSSCH subchannels based on one or more factors. For example, the WTRU may determine a subset of PSSCH subchannels to include PSCCH resources based on the QoS of the sidelink transmission, such as PSSCH or one or more separate TBs. In this case, the QoS may be one or more QoS parameters, such as PPPP, PPPR, or range. If the QoS of the sidelink transmission is below a threshold, the WTRU may use the first PSSCH subchannel in the PSSCH subchannel for the associated PSCCH transmission. If the QoS of the sidelink transmission is above a threshold, the WTRU may repeatedly transmit PSCCH transmissions through a subset of PSSCH subchannels, i.e., one or more SCIs. The subset may include all PSSCH subchannels. In another example, the WTRU may determine a subset of PSSCH subchannels to include PSCCH resources based on the sidelink coverage level.

[0115] In the solutions described herein, the WTRU may select one or more PSSCH subchannels in which the PSCCH resources are included based on the physical layer (PHY) ID. In one such solution, the WTRU may select a PSSCH subchannel for the associated PSCCH based on one or more identifiers for unicast transmissions. The identification of a unicast transmission may include one or more identifiers, such as a source ID, a destination ID, a combination of a source ID and a destination ID, a HARQ process number, a redundancy version, or an NDI switching state.

[0116] In some solutions, the WTRU may select a PSSCH subchannel based on the source ID and the total number of PSSCH subchannels in the application resource pool, the index of which is equal to the result of an arithmetic operation, (e.g., a modulo operation). In another solution, if two PSCCHs are used for PSSCH scheduling, the PSSCH subchannel determinations for the first PSCCH and the second PSCCH may be different. The first PSCCH may carry a first SCI, which may include a first portion of the PSSCH scheduling information. The second PSCCH may carry a second SCI, which may include a second portion of the PSSCH scheduling information. The first SCI may have a first SCI format, such as SCI format-1, and the second SCI may have a second SCI format, such as SCI format-2. The first SCI may include information to facilitate the reception of the second SCI, or the first SCI may indicate the presence of the second SCI.

[0117] The first PSCCH (PSCCH-1) may be located within a predetermined set of subchannels, and the subchannels used for the second PSCCH (PSCCH-2) may be indicated in the first PSCCH, or derived from the first PSCCH, or derived from information transmitted via the first PSCCH.

[0118] One or more PSSCH subchannels for the first PSCCH may be located at a predetermined position within the PSSCH subchannel. For example, a first PSSCH subchannel having a low subchannel index in a PSSCH subchannel may be used for the first PSCCH transmission. One or more PSSCH subchannels for the second PSCCH (PSCCH-2) may be indicated in the first PSCCH, or derived from the first PSCCH, or derived from information transmitted via the first PSCCH.

[0119] The first PSCCH (PSCCH-1) may be located within a predetermined set of subchannels, and the subchannel for the second PSCCH (PSCCH-2) may be determined based on one or more of the above identifiers. By selecting the subchannel for the second PSCCH based on the identifier, interference for the control channel may be randomized.

[0120] In another solution, the WTRU may select a PSSCH subchannel whose index is equal to the result of an arithmetic operation (e.g., a modulo operation) based on the source ID and / or HARQ process ID and the total number of subchannels (e.g., scheduled PSSCH subchannels) in the applied resource pool for TB retransmission. The total number of subchannels may be equal to the total number of scheduled PSSCH subchannels. In another case, the PSSCH subchannel within the PSSCH subchannels scheduled for the associated PSCCH may be determined based on the source ID or the HARQ process ID.

[0121] As described herein, the WTRU may select one or more PSSCH subchannels, in which the PSCCH resources are included, based on the link ID.

[0122] The WTRU may be configured with a group ID for group transmissions, a link ID for unicast / multicast transmissions, a service ID for broadcast transmissions, or any combination of the foregoing IDs. In one solution, the WTRU may select a PSSCH subchannel based on one or more of the link ID, group ID, or service ID and the total number of subchannels in the applied resource pool, the index of which is equal to the result of an arithmetic operation (e.g., a modulo operation).

[0123] As described herein, the WTRU may select one or more PSSCH subchannels in which to include PSCCH resources based on subchannel-specific channel conditions. For example, the WTRU may obtain channel conditions for the PSSCH subchannels based on one or both of subchannel CSI feedback or channel reciprocity. In one solution, the WTRU may select the PSSCH subchannel with the highest CQI value to include the PSCCH resources, or randomly select among PSSCH subchannels whose CQI values ​​may be above a configured or preconfigured threshold. In another solution, the WTRU may select the PSSCH subchannel over which the WTRU obtains the highest signal quality measured in a received PSCCH or PSSCH transmission.

[0124] As described herein, the SCI indication of PSSCH subchannel information may be used by the WTRU to identify the subchannel used for PSSCH transmission. For example, the WTRU may indicate multiple consecutive PSSCH subchannels for TB transmission. For example, when the PSCCH resource is located in the PSSCH subchannel with the lowest subchannel index, the WTRU may identify all PSSCH subchannels based on this information. The WTRU may indicate the index of each PSSCH subchannel used for TB transmission, such as PSSCH transmission using non-contiguous subchannels.

[0125] The WTRU may indicate a bitmap of length equal to the total number of subchannels in the resource pool to which it applies. The WTRU may set the bits in the bitmap corresponding to the PSSCH subchannels used for TB transmission.

[0126] A solution for determining the association between resources for a first PSCCH transmission, PSSCH_1, and resources for a second PSCCH transmission, PSSCH_2, is described herein. In some embodiments, the WTRU may use different rules for each PSCCH to select a subchannel in which resources for PSCCH_1 and PSCCH_2 are included. For example, in a two-level SCI transmission, the WTRU may select a PSSCH subchannel (which includes PSCCH resources for PSCCH_1), and another subchannel (which includes resources for PSCCH_2) based on different rules as described above. The WTRU may transmit the SCI for all SL WTRUs in PSCCH_1, so the WTRU may select the PSSCH subchannel with the lowest subchannel index. This may reduce the degree of decoding required to detect PSCCH_1, since the WTRU may decode the PSCCH in all subchannels by following the ascending order of the subchannel indexes. The WTRU may transmit WTRU specific information in PSCCH_2, which may be associated with one or both of the PHY ID or the link ID; therefore, the WTRU may select a PSSCH subchannel for the PSCCH_2 resources based on one or both of the PHY ID or the link ID. For TB transmissions with either or both of the high PPPR value or range, the WTRU may determine to select a single PSSCH subchannel, which includes both PSCCH_1 and PSCCH_2 resources. In this case, in the PSCCH_1 transmission, no further subchannel information for PSCCH_2 is required.

[0127] Figure 4An example representation of conditions under which a WTRU may select one or more PSSCH subchannels, including PSCCH_1 and PSCCH_2 resources, is provided. As shown at 401, the WTRU may begin subchannel selection for PSCCH_1 and PSCCH_2 resources. As shown at 410, the WTRU may determine whether one or more QoS parameters (e.g., priority PPPP or range PPPR) exceed a configured threshold. If so, at 411, the WTRU may select each subchannel in which PSCCH_1 and PSCCH_2 resources are included, substantially as described above. If the QoS parameters do not exceed the preconfigured threshold, at 420, the WTRU may determine which PSSCH subchannel to allocate PSCCH_1. If so, at 421, the WTRU may select a subchannel with a lower index for PSCCH_1. If the WTRU determines to allocate a PSSCH subchannel for PSCCH_2, the WTRU may further determine at 430 whether the PSSCH subchannels selected therefrom are contiguous subchannels. If yes, then at 440, the WTRU further evaluates whether the total PSSCH bandwidth is less than a threshold. If yes, then the WTRU further evaluates whether a PHY ID or a link ID is available. If yes, then the WTRU selects a PSSCH subchannel based on at least one or both of the PHY ID or the link ID as shown at 431. If the subchannels of the PSSCH are not contiguous, or the total PSSCH BW meets or exceeds the threshold, or the PHY ID or the link ID is not available, then at 432, the WTRU may select a PSSCH subchannel with the best channel condition based on CSI feedback or reciprocity for PSCCH_2.

[0128] PSCCH_1 and PSCCH_2 resources can be located in the same or different PSSCH subchannels, such as Figure 5 As shown in the example in . In addition to the PSSCH subchannel allocation information, the WTRU may include in PSCCH_1 the information required to identify the PSCCH_2 resources. It should be noted that in a SL link, the receiving WTRU may not have the information required to decipher how the transmitting WTRU selected the PSCCH_1 and PSCCH_2 resources.

[0129] Figure 5Various examples of PSCCH_1 and PSCCH_2 resource arrangements in contiguous and non-contiguous PSSCH subchannels are described. As shown in 510, 520, 530 and 540, PSCCH_1 and PSCCH_2 may be placed in contiguous PSSCH subchannels, while 550, 560, 570 and 580 describe the arrangement of PSCCH_1 and PSCCH_2 in non-contiguous channels. 510, 530 and 550 generally describe that PSCCH_1 and PSCCH_2 may be co-located in the same subchannel, 510 and 550 show that both are included in all available subchannels, and 530 shows that both are included in subchannels with low indexes. As shown in 520 and 560, PSCCH_1 may only be located in the lowest subchannel determined by the subchannel index, while PSCCH_2 is included in each remaining subchannel.

[0130] In some solutions, the WTRU may explicitly indicate in PSCCH_1 the PSCCH subchannels in which the PSCCH_2 resources may be located. For example, the WTRU may use the bitmap field in PSCCH_1 and set the bit to a value corresponding to the PSSCH subchannel that includes the PSCCH_2 resources.

[0131] In some solutions, the WTRU may include information in PSCCH_1 that may indicate how the PSCCH_2 resources are determined. In some examples, the WTRU may include a bit field in PSCCH_1, and each code point may correspond to a configured or preconfigured PSSCH subchannel determination for PSCCH_2. In some examples, the WTRU may be configured or preconfigured with a 3-bit field, and each code point may indicate information as shown in Table 1 below, which summarizes examples of values ​​for the 3-bit field of the SCI carried in PSCCH_1. Note that in this example, more than three code points may be used when additional PSCCH_2 resource determination rules are introduced.

[0132] Table 1: Example resource configuration for PSCCH_2 as indicated in the SCI.

[0133]

[0134] Embodiments involving information required for a WTRU to determine PSCCH_2 decoding are described herein. In some embodiments, a WTRU may be configured or preconfigured with a set of SCI formats, types, or sizes for PSCCH_2. Each PSCCH_2SCI format, type, or size may have a different number of total SCI payload information bits, different bit fields in the SCI payload, and different information may be transmitted in each bit field. The PSCCH_2SCI format, type, or size may be configured or preconfigured to be applicable to one or more characteristics. Such characteristics may include a PSSCH transmission type. For example, the total number of SCI bits for unicast PSCCH_2SCI and multicast PSCCH_2SCI may be different. In another example, the total number of SCI bits for unicast PSCCH_2SCI and multicast PSCCH_2SCI may be the same, but the bit fields may be different. In some cases, a unicast or multicast indication bit may be used, and zero padding may be applied in certain bit fields to ensure the same total number of SCI bits.

[0135] The above characteristics may include QoS parameters for the TB transmitted in the associated PSSCH. For example, the WTRU may be configured with a compact PSCCH_2SCI format, type, or size for high reliability TB transmission. In addition, a unicast or multicast PSCCH_2SCI associated with a PSSCH transmission with a minimum communication range (MCR) requirement may include a bit field in the SCI that may be used to convey the MCS value.

[0136] The above characteristics may include the activity of the HARQ process, for example, whether HARQ feedback is enabled or disabled. For example, a unicast PSCCH_2SCI format, type or size associated with a PSSCH transmission with HARQ disabled may not include a bit field for HARQ process ID, RV or NDI. A unicast PSSCH_2SCI format, type or size associated with a PSSCH transmission with HARQ enabled may also include a bit field for resource reservation for HARQ retransmissions.

[0137] The above characteristics may include the activity of CSI reporting, for example, whether CSI reporting is enabled or disabled. For example, a unicast PSCCH_2SCI format, type, or size associated with a PSSCH transmission with CSI disabled may not include a bit field related to CSI request information or CSI reporting resource reservation information. In another example, a unicast PSCCH_2SCI format, type, or size associated with a PSSCH transmission including multiplexed CSI reporting bits may include a new bit field to indicate the presence of decoded CSI bits in the PSSCH resource.

[0138] The above features may include a group HARQ scheme designed to indicate NACK-only feedback or ACK / NACK feedback. For example, a group HARQ transmission scheme indicating ACK / NACK feedback may include an additional SCI bit field for ACK and NACK transmission resource reservation.

[0139] In some embodiments, the WTRU may be configured or preconfigured with a PSCCH_2SCI format, type or size for unicast transmission with HARQ and CSI enabled. In another example, the PSCCH_2SCI format, type or size may be configured or preconfigured for unicast transmission with HARQ and CSI disabled.

[0140] In some embodiments, the WTRU may select a PSCCH_2SCI format, type, or size from a configured or preconfigured set based on the resource allocation for the PSCCH_1SCI transmission, and the WTRU may decode the PSCCH_2 transmission using the PSCCH_2SCI format, type, or size. For example, the WTRU may be configured or preconfigured with dedicated resource allocations, such as a resource pool or a set of subchannels or subcarriers in a resource pool for unicast transmissions. The WTRU may therefore decode the PSCCH_2SCI according to the unicast PSCCH_2SCI format, type, or size in these configured or preconfigured resources. Similarly, the WTRU may be configured or preconfigured with such dedicated resource allocations for multicast transmissions, and the WTRU may decode the PSCCH_2SCI according to the multicast PSCCH_2SCI format, type, or size in these resources.

[0141] In another solution, the WTRU may select and decode the PSCCH_2SCI format, type or size from a configured or preconfigured set based on the information decoded from the PSCCH_1SCI. The decoded information may include, for example, a link identifier. The link identifier may be determined based on the WTRU source ID and the WTRU destination ID. In another example, the link identifier may be exchanged in higher layer signaling during the link establishment process. The decoded information may include a WTRU L1 source ID and an L1 destination ID. Such a WTRU L1 ID may be based on a WTRU ID assigned by a higher layer and carried in the L1 signaling. The decoded information may include QoS parameters for a TB transmitted in an associated PSSCH. For example, the WTRU may indicate priority, latency, reliability, and minimum communication range information associated with a TB transmitted in an associated PSCCH_1SCI transmission. Such QoS parameters may be based on PQI / 5QI information indicated by a higher layer. The decoded information may include frequency domain resource allocation for scheduling the PSSCH. The decoding information may include an explicit indication of the PSCCH_2SCI format, type or size in the PSCCH_1SCI.

[0142] Identification information such as link identification, WTRU L1 source and destination ID information may be explicitly indicated in the PSSCH_1SCI bit field or applied through CRC scrambling. In some solutions, the WTRU may be configured or pre-configured with an association between identification information and unicast or multicast transmission. The WTRU may determine whether to decode the PSCCH_2SCI according to the unicast or multicast PSCCH_2SCI format, type or size based on the link identification, L1 source ID or destination ID. In another solution, the WTRU may determine the SCI format, type or size based on the explicit indication carried in the PSCCH_1SCI. For example, when the SCI format, type or size bit field of the PSCCH_1SCI indicates a unicast or multicast transmission, the WTRU may determine to continue decoding the PSCCH_2SCI.

[0143] In some embodiments, the L1 WTRU source ID and destination ID may be derived based on the 24-bit L2 WTRU ID, for example using the 8 or 16 least significant bits (LSBs) of the L2 WTRU ID. This shortened version of the WTRU ID may cause conflicts, for example, between two WTRU L2 WTRU IDs with the same 8 or 16 LSBs. In some solutions, the L1 WTRU ID (e.g., destination ID) may be the same as the L2 WTRU ID and is explicitly carried in the PSCCH_1 SCI. This may increase the L1 signaling overhead.

[0144] In one solution, the WTRU ID (e.g., L1 destination ID) may be carried in both the PSCCH_1SCI and the PSCCH_2SCI. For example, 8 bits of the WTRU destination ID may be explicitly indicated in the PSCCH_1SCI, and the remaining portion (16 bits) of the WTRU destination ID may be explicitly or implicitly indicated in the PSCCH_2SCI. The implicit indication may be conveyed, for example, via scrambling the PSCCH_2SCI based on or using a CRC. The implicit indication may be conveyed via the allocation of PSCCH_2SCI RBs, such as a starting RB index or a DMRS configuration or sequence based on the remaining 16 bits of the WTRU destination ID. Thus, the WTRU may decode the PSCCH_1SCI and the PSCCH_2SCI for broadcast, groupcast, or unicast transmissions. One advantage may be minimizing erroneous SCI decoding due to collisions of the L1 WTRU ID when the L1 WTRU ID is part of the L2WTRU ID.

[0145] In some solutions, the WTRU ID (e.g., L1 source ID) may be carried in the PSCCH_2SCI for unicast and multicast transmissions. To avoid WTRU ID collisions while keeping L1 signaling overhead low, the WTRU may implicitly indicate the 16 LSBs of the L2 WTRU ID by CRC scrambling the PSCCH_2SCI, configuring the DMRS (e.g., sequence), or allocating one or more frequencies (e.g., starting RBs) to the PSCCH_2SCI based on the 16-bit LSBs. The remaining 8 bits may be carried explicitly in the bit field of the PSCCH_2SCI.

[0146] In another solution, the WTRU may be configured or pre-configured with an association between identification information or QoS parameters and one or more transmission characteristics. For example, the unicast identification information may indicate whether HARQ feedback and retransmission are enabled or disabled for the associated PSSCH transmission. In another example, the unicast identification information may indicate whether CSI reporting may be enabled for the associated PSSCH transmission. In another example, the group identification information may indicate whether only NACK-based or ACK / NACK-based HARQ transmission may be applied to the associated PSSCH transmission.

[0147] In some solutions, the WTRU may include two different identification information for the same unicast link in the PSCCH_1SCI; one may indicate that HARQ feedback and retransmission are enabled, while the other may indicate that HARQ feedback and retransmission are disabled. Therefore, the WTRU may determine whether to decode the PSCCH_2SCI according to the configured or preconfigured unicast PSCCH_2SCI format, type, or size based on the link identification, L1 source ID, or destination ID decoded from the PSCCH_1SCI when HARQ is enabled or disabled. Using the same method, the WTRU may determine whether to decode the PSCCH_2 according to the configured or preconfigured unicast PSCCH_2SCI format, type, or size based on the link identification, L1 source ID, or destination ID decoded from the PSCCH_1SCI when CSI reporting is enabled or disabled.

[0148] In another example, when a QoS metric such as priority, reliability, latency, or range is decoded from the PSCCH_1SCI and exceeds a configured or preconfigured threshold, the WTRU may decode PSCCH_2 according to the configured or preconfigured unicast PSCCH_2SCI format, type, or size with HARQ enabled. The QoS information in the PSCCH_1SCI may implicitly indicate whether HARQ feedback or retransmission is enabled or disabled for the associated TB transmission. Utilizing the same association between the QoS information in the PSCCH_1SCI and the CSI reporting enable / disable feature, the WTRU may determine whether to decode PSCCH_2 according to the configured or preconfigured unicast PSCCH_2SCI format, type, or size with CSI reporting enabled or disabled based on the QoS information decoded from the PSCCH_1SCI.

[0149] In another example, when the PSSCH frequency resource is decoded from the PSCCH1 SCI, the PSCCH2 SCI format, type, or size may be determined accordingly. For example, if the PSSCH occupies more than one subchannel, the SCI format, type, or size associated with the larger size may be selected. For multicast transmissions, the WTRU may determine whether to decode the group PSCCH_2 SCI based on the multicast SCI format, type, or size based on the link identification, L1 source ID, destination ID, or QoS information decoded from the multicast PSCCH_1 SCI transmission in the case where HARQ uses the NACK-only or ACK / NACK options.

[0150] This document describes a solution for determining a PSCCH_2SCI transmission configuration. In order to decode the PSCCH_2SCI according to a determined PSCCH_2SCI format, type, or size, the WTRU may determine the PSCCH_2SCI transmission configuration. The transmission configuration may include resource element allocations for the PSCCH_2SCI transmission, such as symbols, PRBs, and subcarriers occupied by the PSCCH_2SCI transmission. The transmission configuration may include a transmission format for the PSCCH_2SCI transmission, such as a decoding rate, aggregation level, and repetition scheme. The transmission configuration may include a multi-antenna transmission scheme for the PSCCH_2SCI transmission, such as the number of antenna ports applied or a pre-decoding configuration. The WTRU may determine the PSCCH_2SCI transmission resource element allocation based on at least one of the determined PSCCH_2 format, type, or size, or based on the resource reservation of the associated PSSCH decoded from the PSCCH_1SCI.

[0151] In some solutions, the WTRU may receive PSCCH2SCI information in the resources allocated for its associated PSSCH. For example, the PSCCH_2SCI bits may be encoded and multiplexed with the relevant PSSCH bits in a subchannel that is scheduled for the PSSCH in a PSCCH_1SCI transmission. In another example, the WTRU may transmit the encoded PSCCH_2SCI bits in the MAC CE in the associated PSSCH. In this case, the WTRU may determine the PSCCH_2SCI resource element allocation based on the resources reserved for the associated PSSCH in the PSCCH_1SCI.

[0152] It may be advantageous that the bits of the determined PSCCH_2SCI format, type or size are encoded with sufficient decoding gain to ensure PSCCH_2SCI decoding performance. This may be because, for example, the transmission may be "one-shot" without any HARQ retransmissions, and the PSCCH_2SCI format, type or size may have a different number of total bits and bit fields, which may also require different levels of protection to avoid adversely affecting channel conditions and path loss.

[0153] Thus, in the determined resource element allocation, the WTRU may further determine the number of resource elements, the location of these resource elements, and the coding rate of the determined PSCCH_2 format, type, or size based on one or more factors. These factors may include the PSCCH_2 format, type, or size; the modulation and coding scheme (MCS) of the associated PSSCH; QoS parameters related to the associated PSSCH; the DMRS configuration of the associated PSSCH; antenna port configuration; WTRU identification information, such as link identification, WTRU L1 source ID, or WTRU L1 destination ID; the aggregation level of the PSCCH_1SCI; or the PSSCH MCS or coding rate.

[0154] In one example, the WTRU may determine the PSCCH_2SCI transmission aggregation level or coding rate based on the WTRU TX-RX distance derived from the WTRU identification information. The WTRU may associate geographic location information with its identification information and update the information periodically. The WTRU may be configured or pre-configured with a set of coding rates, and each coding rate may be associated with a WTRU TX-RX distance value. Therefore, the WTRU may select the aggregation level or coding rate of the PSCCH_2SCI based on the WTRU identification information.

[0155] In addition, the WTRU may determine a decoding rate for the PSCCH_2 SCI based on the PSCCH_2 format, type or size selected for PSCCH_2 SCI decoding. For example, the WTRU may be configured or preconfigured with a set of decoding rates, where each decoding rate is associated with a configured or preconfigured PSCCH_2 format, type or size.

[0156] The WTRU may determine the MCS or coding rate for the PSCCH_2SCI based on the DMRS configuration indicated in the PSCCH_1SCI. The DMRS configuration, e.g., sequence, length and / or density in time and frequency, may be associated with the MCS or coding rate index for the preconfigured PSCCH_2SCI transmission.

[0157] The WTRU may determine the PSCCH_2SCI MCS or coding rate based on the PSSCH MCS information indicated in the PSCCH_1SCI. The WTRU may apply the determined aggregation level or coding rate and the MCS information of the associated PSSCH to decode the PSCCH_2SCI transmission.

[0158] In another solution, the MCS or coding rate of the PSCCH_2SCI can be explicitly indicated in the PSCCH_1SCI, and the MSC information of the associated PSSCH can be indicated in the PSCCH_2SCI. For example, the PSSCH MCS information can be an absolute MCS index or can indicate an offset or increment of the difference between the PSCCH_2SCI MCS and the PSSCH MCS. This can reduce the L1 signaling required in the PSCCH_2SCI.

[0159] In another solution, the WTRU may determine the location of the PSCCH_2SCI resource elements based on the DMRS density and the location within the associated PSSCH. In addition, the WTRU may determine the location of each bit field in the identified PSCCH_2 format, type or size relative to the DMRS resources. For example, HARQ-related bit fields of the PSSCH_2SCI format, type or size (with enabled HARQ), including L1 source ID, HARQ process ID, new data indicator (NDI) or redundancy version (RV), may be transmitted immediately following the DMRS resources in both the time domain and the frequency domain to provide robustness in the decoding performance of these bit fields.

[0160] In another solution, the WTRU may be configured or pre-configured with a rule set to allocate the coded PSCCH_2SCI bits to different frequencies for different frequency hopping instances based on the QoS information received in the PSCCH_1SCI. For each PSCCH_2SCI format, type or size, the WTRU may determine which coded bits may be distributed in the frequency hopping instance. In another example, the PSCCH_2SCI bits may be repeated in each frequency hopping instance. This may enable the PSCCH_2SCI transmission to apply frequency selective gain.

[0161] The WTRU may determine to decode the PSCCH_2SCI transmission based on the layer mapping and precoding information indicated in the PSCCH_1SCI. For example, the PSCCH_1SCI may indicate how many layers may be applied to the PSCCH_2SCI transmission. In another solution, the WTRU may perform blind detection on the multi-antenna configuration based on the DMRS configuration in the PSCCH_1SCI transmission. The WTRU may attempt to decode the PSCCH_2 transmission using the DMRS configuration for all configured or preconfigured antenna configurations, and evaluate the CRC result at each configured or preconfigured antenna configuration. The CRC check may be performed only on the antenna configuration actually used for the PSCCH_2 transmission.

[0162] Therefore, the WTRU may search for the SCI carried in PSCCH_1 in each subchannel starting from the PSCCH with the lowest subchannel index in the SL resource pool. When the WTRU decodes the PSCCH_1 transmission, the WTRU may obtain the PSSCH subchannel allocation information and determine which PSSCH subchannel or subchannels contain one or more PSCCH_2 resources based on the explicit or implicit indications discussed above. The WTRU may apply the PSCCH_2 resource information to locate and decode the PSCCH_2 transmission and rate match the PSSCH data.

[0163] Disclosed herein is a solution for determining whether to use primary and secondary SCI transmissions. This determination may be made by a WTRU. The WTRU may determine whether to use primary or secondary SCI transmissions for broadcast transmissions based on QoS range requirements. In one solution, when range parameters are not associated with a TB, the WTRU may use primary SCI transmissions, i.e., perform one PSCCH transmission. The WTRU may use secondary SCI transmissions, i.e., perform two PSCCH transmissions, and carry range-based parameters (e.g., minimum communication range requirements and location information of the TX WTRU) in the PSCCH_2SCI. The RX WTRU may determine the TX-RX distance based on the WTRU location information and compare it with the minimum communication range requirement.

[0164] A solution is described herein for a WTRU to determine PSCCH resources within SL resources. PSCCH resources may be located within a subchannel, and a subchannel may be the smallest resource unit for sidelink transmission. The WTRU may perform one step or a combination of steps. For example, the WTRU may determine one or more subchannels for sidelink transmission and then select a PSCCH location within the determined one or more subchannels. The WTRU may sense one or more subchannels and select a subset of the subchannels that may be considered empty or available for sidelink transmission.

[0165] In some solutions, the WTRU may determine one or more PSCCH resources in a selected subchannel, and the selected subchannel may be used for at least PSCCH and PSSCH transmissions. The PSCCH time or frequency location within the selected subchannel may be determined based on one or more parameters. Such parameters may include, for example, link identification, source ID, destination ID, service ID; QoS parameters for the sidelink transmission; parameters indicating whether the WTRU is in coverage or out of coverage.

[0166] Whether the WTRU uses local resources (e.g., continuous RBs) for PSCCH or the WTRU uses distributed resources (e.g., non-continuous RBs) for PSCCH can be determined based on one or more factors. These factors may include the total number of RBs of the selected subchannel, where the selected subchannel may be continuous or non-continuous. For example, the total number of RBs of the selected subchannel may be less than a threshold, and local resources may be used for PSCCH. Otherwise, distributed resources may be used for PSCCH. The resources that the WTRU uses for PSCCH may also be determined based on the DM-RS density. For example, if the DM-RS time density is lower than a threshold (e.g., 2 symbols), local resources may be used for PSCCH. Otherwise, distributed resources may be used for PSCCH. The resources that the WTRU uses for PSCCH may also be determined based on the type of service used. For example, when the sidelink transmission is for broadcast or multicast services, distributed resources may be used for PSCCH; when the sidelink transmission is for unicast services, local resources may be used for PSCCH. The resources that the WTRU uses for PSCCH may also be determined based on QoS parameters.

[0167] In some solutions, the location of the PSCCH resource within the selected subchannel may be determined based on the number of symbols, such as OFDM symbols or DFT-s-OFDM symbols available for sidelink transmission.

[0168] Figure 6The determination of PSCCH resources from within the SL resources is shown. The WTRU may be configured with a SL resource pool 650, which may consist of SL time and frequency resources, e.g. Figure 6 The time slots and subchannels shown. The SL resource pool may include PSSCH resources shown by 610, 620, 630 and 640, each of which describes an example of a subchannel carrying PSCCH resources on a single time slot. The WTRU may perform transmissions over a PSSCH using one or a group of SL resources in one SL time resource 652, which may be, for example, a time slot. The frequency dimension (i.e., subchannel) of the SL resource is shown by way of example at 651. The WTRU may determine a set of PSCCH resources for transmission of an associated PSCCH in one or more SL resources. The PSCCH resources within the SL resource may be configured with any of the following parameters: a starting RB, which may be an index of the first RB of the PSCCH resource; a bandwidth, which may be a number of consecutive RBs of the PSCCH resource; a starting symbol, which may be an index of the first symbol of the PSCCH resource; a duration or length, which may be a number of consecutive symbols of the PSCCH resource; or a PSCCH resource allocation pattern, which may include localized and distributed patterns. The WTRU may determine a PSCCH resource in a localized PSCCH resource allocation pattern. The WTRU may determine multiple PSCCH resources in one SL resource in a distributed PSCCH resource allocation mode.

[0169] like Figure 6 As shown, time slot 610 describes an example of PSCCH resource allocation within a PSSCH resource in a distributed mode, while time slots 620, 630, and 640 describe examples of PSCCH resource allocation in a localized mode according to the transmission type. Time slot 610 describes resource allocation within a PSSCH resource for broadcast PSCCH transmissions. Time slot 620 describes, for example, the allocation of PSCCH resources within a PSSCH channel for broadcast transmissions. Time slot 630 describes, for example, the allocation of PSCCH resources within a PSSCH subchannel for multicast PSCCH transmissions. Time slot 640 describes, for example, the allocation of PSCCH resources within a PSSCH subchannel for unicast transmissions.

[0170] Embodiments involving WTRU determination of PSCCH resources are described herein. The WTRU may determine one or more PSCCH resources and their parameters based on, for example, the SCI format type carried in the PSCCH, such as unicast SCI, multicast SCI, broadcast SCI, SCI containing WTRU common information (e.g., the first SCI in a level 2 SCI transmission), and SCI containing WTRU specific information (e.g., the second SCI in a level 2 SCI transmission). The WTRU may determine one or more PSCCH resources and their parameters based on associated SL transmission QoS parameters (e.g., priority, reliability, latency, or range). The WTRU may determine one or more PSCCH resources and their parameters based on the SL resource configuration (e.g., subchannel size and slot duration). The WTRU may determine one or more PSCCH resources and their parameters based on a PHY ID, such as a source ID, destination ID, HARQ process ID configured by a higher layer for each applicable SL transmission. The WTRU may determine one or more PSCCH resources and their parameters based on a link ID, such as a link identifier and / or link index that the WTRU may use to maintain and distinguish multiple established unicast, multicast, and broadcast transmissions. The WTRU may determine one or more PSCCH resources and their parameters based on channel conditions, such as SL feedback information (CQI / PMI / RI), WTRU positioning information, WTRU mobility information, Doppler estimation, channel reciprocity, or LOS detection. The WTRU may determine one or more PSCCH resources and their parameters based on a beamforming configuration, such as a spatial domain transmit filter configuration for PSCCH resources in FR2 operation.

[0171] In some solutions, the WTRU may determine the PSCCH starting RB based on the SCI format type carried in the PSCCH. For example, the WTRU may be configured or preconfigured with an offset relative to the starting RB of the subchannel in terms of the number of RBs for each SCI format. In another example, the WTRU may be configured or preconfigured with an absolute RB index for each SCI format. In another solution, the WTRU may determine the PSCCH starting RB based on the SCI format type and subchannel size carried in the PSCCH. The WTRU may be configured or preconfigured with an offset and a predefined subchannel size for each SCI format.

[0172] Therefore, if Figure 2As shown, the WTRU may perform PSCCH transmissions associated with unicast, multicast, and broadcast transmissions in different RBs in one subchannel, as previously introduced and described in the above paragraphs. Using one PSCCH resource, the WTRU may transmit an SCI (e.g., a first SCI) containing WTRU common information in a two-stage SCI transmission in a different RB than the second SCI. In some cases, the WTRU may transmit the first SCI and the second SCI at different symbols within one PSCCH resource.

[0173] The WTRU may determine the PSCCH resource starting symbol, duration and / or length based on the configured QoS latency requirements. For example, the WTRU may determine a PSCCH resource at the beginning of a timeslot for a TB associated with a low latency indicated in a packet delay budget (PDB), which may be below a configured or preconfigured threshold.

[0174] The WTRU may determine the PSCCH resource bandwidth, duration and / or length based on the configured QoS reliability requirements. For example, the WTRU may determine the number of RBs and symbols of the PSCCH resources used for the TB based on the PPPR or the minimum communication range. The WTRU may be configured or pre-configured with a mapping between the PSCCH resource size, each PPPR and the minimum communication range value. In another solution, the WTRU may determine such a PSCCH resource size based on the available channel conditions specific to the subchannel. For example, the WTRU may be configured or pre-configured with a mapping between the PSCCH resource size and the SL CQI value.

[0175] The WTRU may determine the PSCCH resource starting symbol, duration and / or length based on a configured or preconfigured PHY ID. For example, the WTRU may determine the starting RB index by performing a modular operation using the source ID or destination ID and the number of total RBs in the subchannel. In another example, the WTRU may determine the starting RB index of the PSCCH resource associated with the retransmission based on the source ID and / or HARQ process ID. In another solution, the WTRU may be configured to have a unique link ID for each established unicast transmission, and the WTRU may determine the PSCCH resource starting symbol, duration and / or length based on the link ID.

[0176] The WTRU may determine the PSCCH resource allocation mode based on the size of the subchannel configured for the SL resources. For example, the WTRU may determine to enter a distributed PSCCH resource allocation mode for a subchannel configuration for a number of PRBs, where the number of PRBs may be greater than a configured or preconfigured threshold. Figure 5As shown, as previously introduced and described in the paragraph, in a distributed PSCCH resource allocation mode, the WTRU may transmit PSCCH in a set of PSCCH resources within one SL resource. For example, each PSCCH resource may have the same size in time and frequency and may be evenly distributed within the subchannel bandwidth. The distributed mode may provide frequency diversity to the PSCCH transmission when the bandwidth of the subchannel is greater than the channel coherence bandwidth.

[0177] In some solutions, the WTRU may determine the PSCCH resource allocation mode based on the beamforming configuration used for the PSCCH transmission. For example, the WTRU may determine to enter a localized PSCCH resource allocation mode for transmission using a narrow beam. Narrow beam transmissions may experience reduced delay spread and therefore may have a large coherence bandwidth. Therefore, there may be no frequency diversity to explore.

[0178] A solution for determining L1 priority for a WTRU is described herein. The WTRU may be configured or pre-configured with a 5QI for each supported V2X service. A set of such 5QI values ​​may be pre-specified, and each QI value may have a one-to-one mapping to a predefined combination of QoS parameters. Such QoS parameters may include: resource type (e.g., guaranteed bit rate (GBR), delay critical GBR, or non-GBR); priority level; packet delay budget; packet error rate; averaging window, e.g., for GBR and / or delay critical GBR resource types only; maximum data burst size, e.g., for delay critical GBR resource types only. In addition, the WTRU may be configured or pre-configured with a minimum communication range (MCR) requirement for each V2X service.

[0179] The L1 priority may be determined based on the 5QI and MCR requirements of the TB and indicated in the SCI associated with the PSSCH transmission of the TB. The L1 priority may be a numeric indicator. The numeric indicator may be one of the following or any combination thereof: an index the same as the 5QI; an index based on a configured or preconfigured mapped 5QI value; an index based on a configured or preconfigured mapped 5QI value and MCR requirements; an index to one or a subset of QoS parameters based on a configured or preconfigured mapped 5QI; an index to one or a subset of QoS parameters based on a configured or preconfigured mapped 5QI and MCR requirements; or an index to a dynamically configured priority level.

[0180] In some solutions, the L1 priority may be the same as the 5QI, or the WTRU may indicate a 5QI value as the L1 priority via the SCI. The L1 priority value may be the same as the configured or pre-configured 5QI value and may correspond to a pre-specified 5QI QoS parameter, as shown in the example manner in Table 2 below.

[0181] Table 2: L1 priority equivalent to 5QI In some solutions, the WTRU may indicate a 5QI value as the L1 priority in the SCI. The L1 priority value may be based on a configured or pre-configured mapping to a 5QI value and may correspond to a pre-specified 5QI QoS parameter, as shown in the example manner in Table 3 below. The 5QI value may be assigned or pre-assigned with a large value, and remapping to a small 5QI value may save L1 signaling overhead.

[0182] Table 3: L1 priority mapped to 5QI values

[0183]

[0184]

[0063] In some solutions, the L1 priority may be indexed to the 5QI index and the MCR requirement based on a configured or preconfigured mapping. The WTRU may indicate both the 5QI and the MCR requirement in the L1 priority. For example, the L1 priority may be the full set of 5QI parameters and the index of the MCR requirement, as shown in the example in Table 4 below. One advantage of including the MCR in the L1 priority may be to implicitly indicate the MCR requirement via SCI decoding.

[0185] Table 4: L1 priority indexed to 5QI index and MCR requirement

[0186]

[0187] In some solutions, the L1 priority may be indexed to one or a subset of 5QI parameters. As shown in the example in Table 5 below, the WTRU may be configured or preconfigured with an L1 priority as an index to one of the 5QI parameters based on a configured or preconfigured mapping, which QI parameter may include a default priority level, a packet delay budget, or a packet error rate. In some cases, the WTRU may be configured or preconfigured with an L1 priority as an index to a subset of 5QI parameters based on a configured or preconfigured mapping. For example, the L1 priority may be an index to one or a combination of resource type, default priority level, packet delay budget, and packet error rate as shown below. In another example, the L1 priority may be an index to a combination of resource type, default priority level, and packet error rate.

[0188] Table 5: L1 priority indexed into 5QI parameter subset

[0189]

[0190] In some solutions, L1 priority may be indexed to one or a subset of 5QI parameters and MCR requirements. For example, the WTRU may be configured or preconfigured with L1 priority as an index to one or more of 5QI parameters and MCR requirements based on a configured or preconfigured mapping. The 5QI parameter may be, for example, a default priority level, a packet delay budget, or a packet error rate.

[0191] In some solutions, the WTRU may be configured or preconfigured with L1 priority as an index to a subset of 5QI parameters and MCR requirements based on a configured or preconfigured mapping. For example, the L1 priority may be an index to one or a combination of resource type, default priority, packet delay budget, packet error rate, or MCR requirement, as shown in the example manner in Table 6 below. In another example, the L1 priority may be an index to one or a combination of resource type, default priority level, packet error rate, or MCR requirement.

[0192] Table 6: L1 priorities indexed to subset of 5QI parameters and MCR requirements

[0193]

[0194] In some solutions, the L1 priority may be indexed to a dynamically configured priority level. For example, when the priority level is not included in the configuration of the 5QI or the preconfigured default priority level, the WTRU may be dynamically configured with the priority level of the TB. In this case, the WTRU may use the L1 priority as an index to the dynamically configured priority level. In order to differentiate the L1 priority based on the 5QI and the dynamically configured priority level, the L1 priority indexed to the applied dynamic priority level may use a specified or pre-specified offset so that the value of the L1 priority may be within the range of indications dedicated to the dynamic priority level.

[0195] In some solutions, the RSRP threshold may be determined based on the L1 priority during the sensing process. The WTRU may calculate the RSRP threshold for SL resource exclusion based on one or a combination of the pre-configuration or QoS parameters of the TB using one or more QoS parameters indicated by the L1 priority decoded during sensing.

[0196] For example, the WTRU may be configured or preconfigured to use the priority indicated by the L1 priority indication for RSRP threshold calculation. In another example, the WTRU may be configured or preconfigured to use the packet error rate parameter. The WTRU may calculate the RSRP threshold using such QoS parameter indicated by the L1 priority decoded during the sensing process and the same QoS parameter of its own TB.

[0197] In some cases, the WTRU may be configured or preconfigured to use multiple QoS parameters corresponding to the L1 priority. For example, the WTRU may be configured or preconfigured to calculate the RSRP threshold using the priority and the packet error rate indicated by the decoded L1 priority. In another case, the WTRU may be configured or preconfigured to calculate the RSRP threshold based on one or a combination of priority, packet error rate, or packet delay budget.

[0198] The WTRU may be configured or pre-configured with an RSRP threshold calculation function. Additionally, the calculation function may be based on a resource type parameter of L1 priority (such as delay critical GBR) and may have different functionality for non-GBR resource types. One purpose may be, for example, to allow a TB serving a V2X service with delay critical GBR to have a higher probability of acquiring resources in Mode 2 operation. When multiple QoS parameters are applied in the RSRP threshold calculation, the function may include different weight coefficients for each applied QoS parameter.

[0199] In some solutions, the WTRU may determine which QoS parameter or parameters indicated by the decoded L1 priority to use for RSRP threshold calculation based on the corresponding QoS parameters of its own TB. For example, when the WTRU's own TB has high reliability (e.g., when the required packet error rate is below a pre-configured threshold), the WTRU may determine to use the indicated packet error rate parameter in the RSRP calculation. In another example, when the WTRU's own TB has low latency (e.g., when its packet delay budget is below a pre-configured threshold), the WTRU may determine to use the packet delay budget parameter. In another example, when the WTRU's own TB has a high priority (e.g., when its priority is above a pre-configured threshold), the WTRU may determine to use the priority parameter.

[0200] In some solutions, the WTRU may use multiple QoS parameters with a weighting function, such as applying the highest weight to the most important QoS parameter of its own TB in the RSRP threshold calculation. For example, when the WTRU's own TB has high reliability or low latency, the WTRU may apply the highest weight to the packet error rate or packet delay budget, respectively. This may allow other QoS parameters indicated by the L1 priority to be taken into account.

[0201] In some solutions, the WTRU may determine the MCR requirement for the TB based on the decoded L1 priority. The WTRU may also determine the WTRU TX-RX distance based on TX location information, such as geographic information and / or area ID, each of which may be transmitted in the SCI. When the TX-RX distance is greater than the MCR requirement, the WTRU may disable HARQ feedback and / or CSI reporting.

[0202] In some solutions, one or both of the TX / TX or TX / RX prioritization may be based on L1 priority. The WTRU may prioritize transmissions between multiple simultaneous transmissions or between simultaneous transmissions and receptions based on the L1 priority associated with each transmission and reception. In one solution, the WTRU may prioritize the transmission or reception associated with the highest priority TB indicated by the L1 priority.

[0203] In some solutions, the WTRU may apply multiple QoS parameters indicated by the L1 priority associated with transmission or reception during TX / TX and / or TX / RX prioritization based on one or more of the pre-configured or QoS parameters of the TB.

[0204] In some solutions, the WTRU may be configured or preconfigured to use a default priority level parameter indicated by the L1 priority to determine the PSFCH on which to perform transmissions when simultaneous PSFCH transmissions occur in the same timeslot. In another solution, the WTRU may be configured or preconfigured to use a packet delay budget parameter indicated by the L1 priority.

[0205] The WTRU may compare each QoS parameter indicated by the L1 priority in a configured or preconfigured order to determine the priority order. In one solution, when the L1 priority includes a default priority level, a packet delay budget, and a packet error rate, the WTRU may be configured or preconfigured to prioritize transmissions in the order of packet delay budget, packet error rate, and default priority level. For example, when the WTRU performs multiple PSFCH transmissions in a time slot, the WTRU may first determine to perform the PSFCH transmission associated with the TB with the lowest packet delay budget. When the default delay budgets of the TBs are equal, the WTRU may perform the transmission through the PSFCH associated with the TB with the lowest packet error rate. When the packet error rates of the TBs are also equal, the WTRU may perform the transmission through the PSFCH associated with the TB with the highest default priority. In another example, the WTRU may follow the same priority to determine which TB to transmit first. In some solutions, the WTRU may be configured or preconfigured with a function based on all QoS parameters indicated by the L1 priority to calculate the priority value. The WTRU may prioritize the transmission or reception with the highest priority order value.

[0206] In some solutions, when the WTRU prioritizes transmission or reception between NR and LTE V2X transmissions, the WTRU may apply one or more QoS parameters indicated by the L1 priority associated with the NR TB. For example, the WTRU may use a default priority level parameter indicated by the L1 priority to compare with the LTE PPPP value to prioritize the transmission or reception.

[0207] This document describes a process by which a WTRU may receive control information. For one or more configured or preconfigured SL BWPs, the WTRU may determine a set of periodic time domain SL resources (e.g., time slots). In each time slot, the WTRU may attempt to receive control information including SCI and HARQ ACK / NACK feedback for the transmission. The WTRU may determine a set of control information resources in a time slot and attempt to receive control information associated with each control information resource.

[0208] In some solutions, the WTRU may receive a preemption indication that instructs the WTRU to, for example, stop or temporarily suspend transmission or reception. The WTRU may be configured or preconfigured with a dedicated set of preemption indication resources, such as a dedicated resource pool or a dedicated subchannel or PRB set, in which to receive the preemption indication. In another solution, the WTRU may determine the preemption indication reception resources in a timeslot based on the resources reserved for the PSSCH transmission that may be preempted. For example, the preemption indication resources may be in the same subchannel as the subchannel of the PSCCH_1SCI transmission associated with the PSSCH transmission to be preempted. In addition, the PRB index of the subchannel may be based on the WTRU identification information.

[0209] When, for example, the WTRU has a persistent resource reservation for a PSSCH transmission, and the WTRU determines that the reserved PSSCH transmission may be subject to preemption, the WTRU may monitor and receive a preemption indication in the determined preemption indication resource in the timeslot. For example, the priority of the PSSCH transmission may be lower than a configured or preconfigured threshold. In another example, the time gap between the timeslot and the reserved PSSCH transmission timeslot may be greater than a preconfigured threshold. The WTRU may therefore attempt to decode a configured or preconfigured PSCCH_1SCI format, type or size that is specific to the preemption indication in the preemption indication resource of the timeslot.

[0210] Solutions for determining resources through which a PSFCH transmission is received are described herein. In some solutions, the WTRU may determine the PSFCH reception resources (e.g., including one or more indices of symbols, subchannels, or PRBs) in a time slot based on a subchannel index, a WTRU ID, or a QoS parameter of an associated PSSCH transmission. Based on the PSFCH time slot configuration of a resource pool, for example, 1 PSFCH time slot for each of 1, 2, or 4 time slots, the WTRU may determine whether a PSFCH transmission is expected in the time slot with the aid of the time slot number. The WTRU may determine the subchannel and one or more PRB indices of the PSFCH based on the subchannel and PRB allocation of the associated PSCCH_1SCI and / or PSCCH_2SCI transmission resource allocation. In some cases, the WTRU may determine that the PSFCH subchannel is the same as the subchannel used for the associated PSCCH_2SCI transmission. In other cases, the WTRU may determine the PSFCH PRB to be used based on the PSCCH_2SCI transmission PRB allocation and / or the WTRU ID.

[0211] In some solutions, the WTRU may monitor and receive PSFCH transmissions in a determined PSFCH resource in a timeslot under one or more conditions. For example, one condition may be when the WTRU has performed a HARQ-enabled PSSCH transmission. Another condition may be when a PSFCH transmission associated with a PSSCH transmission occurs in a timeslot according to the HARQ timeline.

[0212] In some solutions, the WTRU may attempt to decode a configured or preconfigured PSFCH format or type in the PSFCH reception resources of a timeslot.

[0213] Solutions for determining resources for HARQ retransmissions are described herein. For example, if the WTRU indicates a reception failure of an initial transmission, a HARQ retransmission may be performed. In some solutions, the WTRU may determine the HARQ retransmission resources in a timeslot based on HARQ retransmission resource reservation information received in the PSSCH_2SCI of the initial transmission of the same TB. The WTRU may determine to receive a HARQ retransmission when the timeslot is aligned with the scheduled HARQ retransmission timing information.

[0214] When, for example, the WTRU receives an initial transmission of a HARQ-enabled TB, the WTRU may monitor and receive HARQ retransmissions in the time slot. The HARQ retransmissions may occur in the time slot according to the HARQ retransmission resource reservation received in the initial transmission. The WTRU may attempt to decode a PSCCH, PSCCH_1 or PSCCH_2 SCI format, type or size that is the same as the format, type or size of the initial transmission of the same TB.

[0215] Disclosed herein is a solution for resource determination for semi-persistent (SP) based TBs when HARQ feedback and retransmissions are enabled. When HARQ feedback or retransmissions are enabled based on SP resource reservations, the WTRU may determine the resources in the timeslot for SP based TBs. When HARQ is enabled, the WTRU may determine that one or more resources for SP based TBs are the same as one or more resources used by a PSSCH transmission including SP based resource reservation information. When the WTRU receives a PSSCH transmission containing SP based resource reservations, the WTRU may monitor and receive SP based TBs in the timeslot. Based on the SP based resource reservation received in the PSSCH transmission, a PSSCH transmission of another TB may occur in the timeslot. The WTRU may attempt to decode a PSCCH, PSCCH_1 or PSCCH_2 SCI format, type or size of the same format, type or size as the last received SP based TB.

[0216] Disclosed herein is a solution for resource determination for semi-persistent (SP) based TBs when HARQ feedback and retransmissions are disabled. A WTRU may determine resources for SP based TBs when HARQ feedback and retransmissions are disabled. The WTRU may receive such transmissions in the same manner as described above. However, the WTRU may prioritize attempts to decode SCIs among SP based TBs for which HARQ is enabled. One benefit may be that the WTRU may ensure that all TBs that require HARQ feedback transmissions are received first and that unnecessary HARQ retransmissions do not occur due to HARQ DTX.

[0217] A solution for determining resources for high priority control information is described herein. The WTRU may determine resources for general control information, which may include all subchannels, PRBs, subcarriers in a time slot. The WTRU does not expect any pre-scheduled transmissions in the time slot, but may expect transmissions of TBs with QoS requirements exceeding a configured or pre-configured threshold. For example, a set of subchannels, PRBs, or subcarriers with the lowest index in a resource pool may be configured or pre-configured for low latency TB transmissions, which may require the WTRU to detect such transmissions as early as possible.

[0218] Embodiments related to common control information resources are disclosed herein. A WTRU may determine one or more common control information resources that may include all subchannels, PRBs, or subcarriers in a time slot in which the WTRU does not expect any pre-scheduled transmissions but may expect transmissions of TBs with QoS requirements below a configured or pre-configured threshold. The WTRU may perform blind detection of SCI in the common receive resources.

[0219] Solutions for prioritization of SCI decoding by WTRU USCI are described herein. In some solutions, the WTRU may be configured or preconfigured to detect the SCI format, type or size in each identified control information resource discussed above. Due to WTRU processing capabilities, SL BWP bandwidth, and NR V2X QoS requirements (e.g., latency), there may be limitations on how much control information a WTRU can decode in a given timeslot. Therefore, the WTRU may be configured or preconfigured to prioritize SCI decoding based on the type of control information resource.

[0220] In some solutions, the WTRU may be configured or preconfigured to prioritize control information decoding based on the control information resource type. For example, the WTRU may be configured or preconfigured to first receive control information that the WTRU may expect in a time slot. Therefore, before processing high priority control information resources and general control information resources, the WTRU may attempt to decode control information in PSFCH reception resources, HARQ retransmission resources, resources for receiving SP-based TBs with HARQ enabled, preemption indication resources, or resources for receiving SP-based TBs with HARQ disabled. In another solution, the WTRU may be configured or preconfigured to prioritize all control information related to the HARQ mechanism. In addition, the WTRU may be configured or preconfigured to prioritize preemption indication resources and attempt to decode the preemption indication first.

[0221] In another solution, the WTRU may be configured or preconfigured to attempt to decode the control information based on the QoS parameters of the TBs associated with the identified control information resources. For example, when the priority of the TBs associated with the PSFCH is higher than the priority of the TBs associated with the HARQ retransmissions, the WTRU may attempt to decode the PSFCH in the PSFCH reception resources before decoding the transmissions on the HARQ retransmission resources. In addition, the WTRU may be configured or preconfigured to apply prioritization based on the type of control information resources and the QoS requirements associated with each control information.

[0222] Although the features and elements are described above in specific combinations, it will be understood by those skilled in the art that each feature or element can be used alone or in any combination with other features and elements. In addition, the methods described herein can be implemented in a computer program, software, or firmware that is incorporated into a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor associated with the software can be used to implement a radio frequency transceiver used in a WTRU, a terminal, a base station, an RNC, or any host computer.

Claims

1. A method for sidelink communication performed by a wireless transmit / receive unit (WTRU), the method comprising: receiving a plurality of resources via a physical sidelink control channel (PSCCH) during a time slot; determining that the plurality of resources during the time slot are control information resources; as well as A control information resource type associated with the control information resource is determined.

2. The method according to claim 1, further comprising: The priority of the control information resource type is determined based on a configuration associating a priority with the control resource information type.

3. The method according to any of claims 1-2, further comprising: The PSCCH is decoded according to the determined priority of the control information resource type.

4. The method according to any of claims 2-3, wherein: The control information resource type is one of the following: a physical sidelink feedback channel (PSFCH) reception resource; a HARQ retransmission resource; Semi-persistent (SP) transport block (TB) transmission using HARQ-enabled resources (SP-based TB); preemption indication resources; or SP-based TB transmission using HARQ-disabled resources.

5. The method according to any one of claims 2 to 4, wherein: The configuring of associating a priority with the control resource information type prioritizes all HARQ mechanisms over all other control information resource types.

6. The method according to any one of claims 2 to 5, wherein: The configuring of associating a priority with the control resource information type prioritizes the preemption indication resource over all other control information resource types.

7. The method according to any one of claims 3 to 6, wherein: Determining the priority of the control information resource type is further based on a quality of service (QoS) parameter of a transport block (TB) associated with the control information resource type.

8. The method according to claim 7, wherein: The QoS parameter of the TB associated with the control information resource type is associated with a first priority, and the control information resource type is associated with a second priority.

9. The method of claim 8, further comprising determining the priority of the control information resource type based on the first priority.

10. A wireless transmit / receive unit (WTRU), the WTRU comprising: a transceiver configured to receive a plurality of resources via a physical sidelink control channel (PSCCH) during a time slot; as well as The processor circuit is configured to: determining that the plurality of resources during the time slot are control information resources; and A control information resource type associated with the control information resource is determined.

Images