Method and apparatus for physical sidelink control channel (PSCCH) design in new radio (NR)

Abstract

To disclose devices and methods for a PSCCH design in NR.SOLUTION: A source WTRU for sidelink communication may determine whether HARQ feedback is enabled. On a condition that HARQ feedback is enabled, the source WTRU may determine DM-RS density for a sidelink transmission on the basis of, HARQ parameters and association information. Further, the association information may include information regarding an association between configured DM-RS time densities and the HARQ parameters. The source WTRU may transmit the sidelink transmission with one or more DM-RSs at the determined DM-RS density. On a condition that HARQ feedback is disabled, the source WTRU may determine the DM-RS density on the basis of, a DM-RS density indicator field. The DM-RS density indicator field may be received by the source WTRU in associated SCI.SELECTED DRAWING: Figure 7

Description

Technical Field

[0001] Cross - reference to Related Applications This application claims the benefit of U.S. Provisional Patent Application No. 62 / 716,089, filed on Aug. 8, 2018, and U.S. Provisional Patent Application No. 62 / 804,992, filed on Feb. 13, 2019, the contents of which are incorporated herein by reference.

Background Art

[0002] In 3rd Generation Partnership Project (3GPP (R)) New Radio (NR) wireless communication, the Uu interface may be designed to support communication between a next - generation NodeB such as a gNodeB (gNB) and one or more user equipment (UE) or wireless transmit / receive units (WTRU). The NR design can support several services based on data transmission between the gNB and one or more WTRUs.

[0003] For wireless communication systems including those using an evolved packet core (EPC), a vehicle - to - everything (V2X) communication architecture has been developed. V2X communication may include vehicle - to - vehicle (V2V) communication, vehicle - to - pedestrian (V2P) communication, vehicle - to - infrastructure (V2I) communication, and vehicle - to - network (V2N) communication.

[0004] However, for device - to - device (D2D) or V2X communication, a WTRU - to - WTRU communication design such as communication through the PC5 interface has not been supported in NR. 3GPP Long Term Evolution (LTE) has supported WTRU - to - WTRU communication for public safety use cases, V2X use cases, or both, but LTE - based solutions may not be compatible in an NR network. Further, use cases such as platooning, extended sensors, advanced driving, and remote driving may be introduced.

SUMMARY OF THE INVENTION

[0005] Devices and methods for physical sidelink control channel (PSCCH) design in New Radio (NR) are disclosed. In an embodiment, a source wireless transmit / receive unit (WTRU) for sidelink communication may determine whether hybrid automatic repeat request (HARQ) feedback is enabled. Conditional on the HARQ feedback being enabled, the source WTRU may determine the demodulation reference signal (DM-RS) density for sidelink transmission based on HARQ parameters and associated information. Further, the associated information may include information regarding the association between the configured DM-RS time density and the HARQ parameters. Accordingly, the source WTRU may transmit a sidelink transmission having one or more DM-RSs at the determined DM-RS density.

[0006] In a further embodiment, conditional on the HARQ feedback being disabled, the source WTRU may determine the DM-RS density based on a DM-RS density indicator field. Moreover, the DM-RS density indicator field may be received by the source WTRU in the associated sidelink control information (SCI).

[0007] In another embodiment, the associated information may be received by the source WTRU. Further, the associated information may be received via a radio resource control (RRC) message. Additionally, the associated information may be received in the associated SCI. In a further embodiment, the associated information may be predefined.

[0008] In an additional embodiment, the HARQ parameters may include one or more of a redundancy version number, a new data indicator (NDI) bit toggle status, a HARQ retransmission count, or a HARQ process number. The HARQ parameters may be received in the associated SCI.

[0009] The following description, taken in conjunction with the accompanying drawings, in which like reference numerals in the drawings identify like elements, will provide a more detailed understanding.

Brief Description of the Drawings

[0010]

Figure 1A

Figure 1B

Figure 1C

Figure 1D

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Embodiments for Carrying Out the Invention

[0011] FIG. 1A is a diagram showing an exemplary communication system 100 that can implement one or more disclosed embodiments. The communication system 100 may be a multi-connection system that provides content such as voice, data, video, messaging, and broadcasting to a plurality of wireless users. The communication system 100 can enable a plurality of wireless users to access such content through sharing of system resources including wireless bandwidth. For example, the communication system 100 may utilize 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 DTS-S-OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, and filter bank multi-carrier (FBMC).

[0012] As shown in Figure 1A, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104 / 113, a CN 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, but it should be recognized that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, any of them may be referred to as a "station" and / or "STA", and the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and / or receive wireless signals and may be user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular telephones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain scenarios), home appliances, and devices operating on commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, 102d may also be interchangeably referred to as a UE.

[0013] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as CN 106, Internet 110, and / or other network 112. By way of example, base stations 114a, 114b may be a base transceiver station (BTS), NodeB, eNodeB, home NodeB, home eNodeB, gNB, NR NodeB, site controller, access point (AP), and wireless router, among others. Although base stations 114a, 114b are each represented as a single element, it will be understood that base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

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

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

[0016] More specifically, as described above, the communication system 100 may be a multi-connection system and may adopt one or more channel access methods such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA. For example, the base station 114a within RAN104 / 113 and the WTRUs 102a, 102b, 102c may establish the air interface 116 using wideband CDMA (WCDMA (registered trademark)) and may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA). 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).

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

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

[0019] In an embodiment, the base station 114a, and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a, and the WTRUs 102a, 102b, 102c may implement both LTE radio access and NR radio access using, for example, the dual connectivity (DC) principle. Accordingly, the air interface utilized by the WTRUs 102a, 102b, 102c is transmitted to / from multiple types of radio access technologies, and / or multiple types of base stations (e.g., eNBs and gNBs).

[0020] In other embodiments, the base station 114a, and the WTRUs 102a, 102b, 102c may implement wireless technologies such as IEEE802.11 (i.e., Wireless Fidelity (WiFi)), IEEE802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM) for mobile communications, High-Speed Data Rate for GSM Evolution (EDGE), and GSM EDGE (GERAN).

[0021] The base station 114b in Fig. 1A may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a localized area such as an office, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., used by a drone), and a roadway. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a wireless technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a wireless technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a pico cell or a femto cell. As shown in Fig. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106 in some cases.

[0022] RAN 104 / 113 may communicate with CN 106 / 115, and CN 106 / 115 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 WTRUs 102a, 102b, 102c, 102d. The data may have various quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements. CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid originating calls, Internet connectivity, video distribution, etc., and / or may perform high-level security functions such as user authentication. Although not shown in FIG. 1A, it will be understood that RAN 104 / 113 and / or CN 106 / 115 may communicate directly or indirectly with other RANs that utilize the same RAT or a different RAT than RAN 104 / 113. For example, in addition to being connected to RAN 104 / 113 which may be utilizing NR radio technology, CN 106 / 115 may also communicate with another RAN (not shown) that utilizes GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0023] CN106 / 115 may also serve as a gateway for the WTRU102a, 102b, 102c, 102d to access the PSTN108, the Internet 110, and / or other networks 112. The PSTN108 may include a circuit-switched telephone network that provides basic telephone service (POTS). The Internet 110 may include a worldwide 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) within the TCP / IP Internet protocol suite. The network 112 may include wired and / or wireless communication networks that are owned and / or operated by other service providers. For example, the network 112 may include another CN that is connected to one or more RANs that may utilize the same RAT or a different RAT as the RAN104 / 113.

[0024] Some or all of the WTRU102a, 102b, 102c, 102d within the communication system 100 may include multimode functionality (e.g., the WTRU102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). For example, the WTRU102c shown in FIG. 1A may be configured to communicate with a base station 114a that may employ cellular-based wireless technology and / or with a base station 114b that may utilize IEEE802 wireless technology.

[0025] Figure 1B is a system diagram showing an exemplary WTRU 102. As shown in Figure 1B, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and / or other peripheral devices 138. It will be understood that the WTRU 102 may include any sub-combination of the above elements while maintaining consistency with the embodiments.

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

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

[0028] In FIG. 1B, the transmitting / receiving element 122 is shown as a single element, but the WTRU 102 may include any number of transmitting / receiving elements 122. More specifically, the WTRU 102 may utilize MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmitting / receiving elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals on the air interface 116.

[0029] The transceiver 120 may be configured to modulate signals to be transmitted by the transmitting / receiving element 122 and demodulate signals received by the transmitting / receiving element 122. As mentioned above, the WTRU 102 may have a multimode function. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as, for example, NR and IEEE 802.11.

[0030] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker / microphone 124, keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit). The processor 118 may output user data to the speaker / microphone 124, keypad 126, and / or the display / touchpad 128. Additionally, the processor 118 may obtain information from and may 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), read only memory (ROM), hard disk, or any other type of memory storage device. The removable memory 132 may include, for example, a subscriber identity module (SIM) card, a memory stick, and a secure digital (SD) memory card. In other embodiments, the processor 118 may access information from and may 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).

[0031] The processor 118 may receive power from a power source 134 and may be configured to distribute power to and / or control power for other components within 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 cells (such as nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), a solar cell, and a fuel cell.

[0032] Processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or instead of, information from the GPS chipset 136, the WTRU 102 may receive location information on the air interface 116 from a base station (e.g., base stations 114a, 114b), and / or may determine its location based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 may obtain location information using any suitable positioning method while maintaining consistency with the embodiments.

[0033] Processor 118 may also be coupled to other peripheral devices 138, which may include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripheral devices 138 may include an accelerometer, an e-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, a Bluetooth® module, a Frequency Modulation (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and / or Augmented Reality (VR / AR) device, and an activity tracker, among others. The peripheral devices 138 may include one or more sensors, which may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

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

[0035] FIG. 1C is a system diagram illustrating RAN104 and CN106 according to an embodiment. As described above, RAN104 may employ E-UTRA radio technology to communicate with WTRU102a, 102b, 102c through air interface 116. RAN104 may also communicate with CN106.

[0036] RAN104 may include eNodeBs 160a, 160b, 160c, although it will be understood that RAN104 may include any number of eNodeBs while maintaining consistency with the embodiment. Each of eNodeBs 160a, 160b, 160c may include one or more transceivers for communicating with WTRU102a, 102b, 102c on air interface 116. In one embodiment, eNodeBs 160a, 160b, 160c may implement MIMO technology. Thus, eNodeB160a, for example, may transmit wireless signals to and / or receive wireless signals from WTRU102a using multiple antennas.

[0037] Each of eNodeBs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, and user scheduling in the UL and / or DL. As shown in Figure 1C, eNodeBs 160a, 160b, and 160c may communicate with each other over the X2 interface.

[0038] CN 106 shown in Figure 1C may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (or PGW) 166. Although each of the above elements is depicted as part of CN 106, it will be understood that any of these elements may be owned and / or operated by an entity different from the CN operator.

[0039] MME 162 may be connected to each of eNodeBs 160a, 160b, and 160c within RAN 104 via the S1 interface and may act as a control node. For example, MME 162 may be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, and selecting a particular serving gateway during the initial attach of WTRUs 102a, 102b, and 102c. MME 162 may provide control plane functions for exchanges between RAN 104 and other RANs (not shown) that utilize other radio technologies such as GSM and / or WCDMA.

[0040] SGW164 may be connected to each of eNodeBs 160a, 160b, and 160c within RAN104 via the S1 interface. SGW164 may generally route and transfer user data packets to / from WTRUs 102a, 102b, and 102c. SGW164 may perform other functions such as anchoring the user plane during an eNodeB handover, triggering paging when DL data is available to WTRUs 102a, 102b, and 102c, and managing and storing the contexts of WTRUs 102a, 102b, and 102c.

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

[0042] CN106 may facilitate communication with other networks. For example, CN106 may provide access to a circuit switched network, such as PSTN 108, to WTRUs 102a, 102b, and 102c to facilitate communication between WTRUs 102a, 102b, and 102c and conventional fixed line communication devices. For example, CN106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN106 and PSTN 108. Additionally, CN106 may provide access to other networks 112 to WTRUs 102a, 102b, and 102c, and other networks 112 may include other wired and / or wireless networks owned and / or operated by other service providers.

[0043] In FIGS. 1A through 1D, the WTRU is described as a wireless terminal, but in certain representative embodiments, it is contemplated that such a terminal may use (e.g., temporarily or permanently) a wired communication interface to a communication network.

[0044] In a representative embodiment, another network 112 may be a WLAN.

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

[0046] When using the operation of 802.11ac infrastructure mode or the operation of a similar mode, the AP may transmit beacons on a fixed channel such as the primary channel. The primary channel may have a fixed width (e.g., 20 megahertz bandwidth), or a width dynamically set via signaling. The primary channel may be the operating channel of the BSS and may be used by the STA to establish a connection with the AP. In a representative embodiment, for example, in an 802.11 system, Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) may be implemented. In the case of CSMA / CA, STAs including the AP (e.g., any STA) may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. Within a given BSS, at any given time, one STA (e.g., only one station) may transmit.

[0047] A High Throughput (HT) STA may use a 40 megahertz wide channel for communication, for example, by combining the primary 20 megahertz channel with adjacent or non - adjacent 20 megahertz channels to form a 40 megahertz wide channel.

[0048] Very High Throughput (VHT) STAs can support channels with widths of 20 megahertz, 40 megahertz, 80 megahertz, and / or 160 megahertz. The 40 megahertz and / or 80 megahertz channels may be formed by combining consecutive 20 megahertz channels. The 160 megahertz channel may be formed by combining eight consecutive 20 megahertz channels, or may be formed by combining two non - consecutive 80 megahertz channels, which may be referred to as an 80 + 80 configuration. In the case of the 80 + 80 configuration, after channel encoding, the data may be passed through a segment parser that can split the data into two streams. For each stream separately, an Inverse Fast Fourier Transform (IFFT) process and a time - domain process may be performed. The streams may be mapped onto two 80 megahertz channels, and the data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80 + 80 configuration may be reversed, and the combined data may be transmitted to the Media Access Control (MAC).

[0049] Operation in sub - 1 - GHz modes is supported by 802.11af and 802.11ah. The channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5 - MHz, 10 - MHz, and 20 - MHz bandwidths in the TV white - space (TVWS) spectrum, and 802.11ah supports 1 - MHz, 2 - MHz, 4 - MHz, 8 - MHz, and 16 - MHz bandwidths using the non - TVWS spectrum. According to an exemplary embodiment, 802.11ah may support meter - type control / machine - type communication, such as MTC devices in a macro - coverage area. The MTC devices may have limited functionality including certain functions, for example, support for a certain bandwidth and / or limited bandwidth (e.g., only their support). The MTC devices may include a battery having a battery life above a threshold (e.g., to maintain a very long battery life).

[0050] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include channels that may be designated as primary channels. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs within a BSS. The bandwidth of the primary channel may be set and / or limited by the STA that supports the minimum bandwidth operating mode among all STAs operating within the BSS. In the example of 802.11ah, for an STA (e.g., an MTC type device) that supports the 1 megahertz mode (e.g., supports only that), the primary channel may be 1 megahertz wide even if the AP and other STAs within the BSS support 2 megahertz, 4 megahertz, 8 megahertz, 16 megahertz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) setting may depend on the status of the primary channel. For example, if the primary channel is busy because an STA (supporting only the 1 megahertz operating mode) is transmitting to an AP, the entire available frequency band may be considered busy even if most of the frequency band remains idle and available.

[0051] In the United States, the available frequency band that may be used by 802.11ah is from 902 megahertz to 928 megahertz. In Korea, the available frequency band is from 917.5 megahertz to 923.5 megahertz. In Japan, the available frequency band is from 916.5 megahertz to 927.5 megahertz. The total bandwidth available for 802.11ah is from 6 megahertz to 26 megahertz, depending on national regulations.

[0052] FIG. 1D is a system diagram illustrating RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 may communicate with WTRUs 102a, 102b, 102c over air interface 116 using NR radio technology. RAN 104 may also communicate with CN 106.

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

[0054] WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using transmissions associated with scalable numerology. For example, the OFDM symbol interval, and / or the OFDM subcarrier interval may vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., including various numbers of OFDM symbols and / or lasting for various lengths of absolute time).

[0055] gNBs 180a, 180b, and 180c may be configured to communicate with WTRUs 102a, 102b, and 102c in a stand-alone configuration and / or a non-stand-alone configuration. In a stand-alone configuration, WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c without accessing another RAN (such as eNodeBs 160a, 160b, and 160c, for example). In a stand-alone configuration, WTRUs 102a, 102b, and 102c may utilize one or more of gNBs 180a, 180b, and 180c as a mobility anchor point. In a stand-alone configuration, WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c using signals within an unlicensed band. In a non-stand-alone configuration, WTRUs 102a, 102b, and 102c may communicate with and / or connect to gNBs 180a, 180b, and 180c while also communicating with / connecting to another RAN such as eNodeBs 160a, 160b, and 160c. For example, WTRUs 102a, 102b, and 102c may implement the DC principle to communicate with one or more gNBs 180a, 180b, and 180c and one or more eNodeBs 160a, 160b, and 160c substantially simultaneously. In a non-stand-alone configuration, eNodeBs 160a, 160b, and 160c may serve as a mobility anchor for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c may be able to provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0056] Each of gNBs 180a, 180b, and 180c may be associated with a specific cell (not shown) and may be configured to handle wireless resource management decisions, handover decisions, user scheduling in UL and / or DL, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data to user plane functions (UPFs) 184a, 184b, and routing of control plane information to access and mobility management functions (AMFs) 182a, 182b. As shown in FIG. 1D, gNBs 180a, 180b, and 180c may communicate with each other over the Xn interface.

[0057] CN 106 shown in FIG. 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possibly data networks (DNs) 185a, 185b. Although each of the above elements is depicted as part of CN 106, it will be understood that any of these elements may be owned and / or operated by an entity different from the CN operator.

[0058] AMF 182a and 182b may be connected to one or more of gNBs 180a, 180b, and 180c in RAN 104 via the N2 interface and may serve as control nodes. For example, AMF 182a and 182b may authenticate users of WTRUs 102a, 102b, and 102c, support network slicing (e.g., handling different PDU sessions with different requirements), select specific SMFs 183a and 183b, manage the registration area, terminate NAS signaling, and perform mobility management, etc. Network slicing may be used by AMF 182a and 182b to customize the CN support for WTRUs 102a, 102b, and 102c based on the type of service utilized by WTRUs 102a, 102b, and 102c. For example, different network slices may be established for different use cases such as services that rely on ultra-reliable low-latency (URLLC) access, services that rely on high-speed large-capacity mobile broadband (eMBB) access, and / or services for machine type communication (MTC) access. AMF 162 may provide control plane functions for exchanges between RAN 104 and other RANs (not shown) that utilize other radio technologies such as non-3GPP access technologies like LTE, LTE-A, LTE-A Pro, and / or WiFi.

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

[0060] UPF184a and 184b may be connected to one or more of gNB180a, 180b, and 180c in RAN104 via the N3 interface, and they may provide access to a packet-switched network such as the Internet 110 to WTRU102a, 102b, and 102c to facilitate communication between WTRU102a, 102b, and 102c and IP-corresponding devices. UPF184a and 184b may perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-homing PDU sessions, processing user plane QoS, buffering downlink packets, and providing mobility anchoring.

[0061] CN106 can facilitate communication with other networks. For example, CN106 may include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN106 and the PSTN108. Additionally, CN106 may provide access to other networks 112 to the WTRUs 102a, 102b, 102c, where the other networks 112 may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to local data networks (DNs) 185a, 185b through the UPFs 184a, 184b via an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

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

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

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

[0065] In 3GPP NR wireless communication, the Uu interface may be designed to support communication between a gNB and one or more WTRUs. The NR design can support several services based on data transmission between a gNB and one or more WTRUs. For example, Release 15 in NR can support such services. However, for device-to-device (D2D) communication or vehicle-to-everything (V2X) communication, WTRU-to-WTRU communication such as communication through the PC5 interface has not been supported in NR.

[0066] 3GPP LTE has supported WTRU-to-WTRU communication for public safety use cases, V2X use cases, or both, but LTE-based solutions may not be compatible in an NR network. Therefore, a PC5 interface based on the NR frame structure and channels may be required. Furthermore, use cases such as platooning, extended sensors, advanced driving, and remote driving may be introduced, which may involve additional requirements for V2X communication.

[0067] LTE sidelink communication can be supported for D2D and V2X. The physical channels used for sidelink communication may include sidelink primary synchronization signal (SPSS), sidelink secondary synchronization signal (SSSS), physical sidelink broadcast channel (PSBCH), physical sidelink control channel (PSCCH), physical sidelink shared channel (PSSCH), and physical sidelink discovery channel (PSDCH).

[0068] In an embodiment, sidelink communication can support up to four modes. For example, sidelink communication may use modes 1 to 4. In an embodiment, modes 1 and 2 may be designed for D2D communication, which has delay tolerance, involves low mobility of devices in mutual sidelink communication, is power efficient, and may require reliable transmission. Mode 1 may be based on the scheduling of the eNB for sidelink transmission, and the resources for sidelink transmission may be scheduled by the eNB via a downlink control information (DCI) message. Mode 2 may be based on the autonomous resource selection of the WTRU within a resource pool. Mode 1 may be used when the WTRU is located under the coverage of the eNB for sidelink transmission so that the WTRU can receive control signals from the eNB. In an embodiment, mode 2 may be used for cases where one or more WTRUs are outside the coverage of the eNB for sidelink transmission, and mode 2 may also be used for cases within the coverage.

[0069] Compared with modes 1 and 2, modes 3 and 4 may be introduced for V2X communication to support high mobility of devices and low latency. According to an embodiment, in modes 1 and 3, the sidelink WTRU may receive a resource grant for sidelink transmission, and the resource grant may be monitored within a search space configured for the Uu interface.

[0070] For NR in a 5G radio system, new structures and designs may be adapted for the physical downlink shared channel (PDSCH) together with the physical downlink control channel (PDCCH). In addition, slot-based transmission and non-slot-based transmission, as well as different rates for monitoring the PDCCH, may be defined.

[0071] In 5G NR, a resource element group (REG) may be the minimum building block for the PDCCH. Each REG may be composed of 12 resource elements (REs) for one OFDM symbol in time and one resource block (RB) in frequency. In each REG, 9 REs may be used for control information, and 3 REs may be used for one or more demodulation reference signals (DM-RS). A plurality of adjacent REGs (2, 3, or 6) in time or frequency may form a REG bundle that can be used by the same precoder, and their DM-RS may be used together for channel estimation. Six REGs (in a format of 1, 2, or 3 bundles) may form one control channel element (CCE), which is the smallest possible size for the PDCCH. Each PDCCH may include one or more CCEs, e.g., 1, 2, 4, 8, or 16 CCEs, and the number of CCEs for the PDCCH may be referred to as its aggregation level (AL).

[0072] The mapping of the REG bundle may have two different modes: an interleaving mode and a non-interleaving mode. In the non-interleaving mapping, consecutive REG bundles adjacent in frequency may form CCEs, and CCEs adjacent in frequency may form PDCCHs. In the interleaving mapping, the REGs may be interleaved or replaced before being mapped to the CCEs, resulting in non-adjacent REG bundles in one CCE and non-adjacent CCEs in one PDCCH overall.

[0073] A control resource set (CORESET) may be composed of, for example, its frequency allocation, which may be like a chunk of 6 resource blocks (RBs), whether it is interleaved or not, a length in time that may be 1 to 3 OFDM symbols, the type of resource element group (REG) bundle, and the type of mapping from the REG bundle to control channel element (CCE). In each bandwidth part (BWP), there may be up to 3 CORESETs. In an embodiment, there may be 12 CORESETs in all 4 possible bandwidth parts.

[0074] Each wireless transmit / receive unit (WTRU) may be allocated a set of physical downlink control channel (PDCCH) candidates to be monitored during blind detection of the PDCCH, which may be referred to as a search space or a set of search spaces, for multiple aggregation levels. Each set of search spaces may be composed of its associated CORESET, the number of candidates having each aggregation level, and a monitoring occasion. The monitoring occasion may be determined by a monitoring period, a monitoring offset, and a monitoring pattern that may be in units of slots. For example, the monitoring pattern may include 14 bits corresponding to all possible patterns of symbols within a slot.

[0075] A slot format indicator (SFI) can provide, for example, an indication of the direction of one or more symbols within a slot or a set of slots, such as a dynamic indication. The direction may be at least one of uplink (UL), downlink (DL), or a flexible direction. The SFI may be provided in the PDCCH. For example, the symbol direction in a slot may be configured by higher layer signaling. The direction indicated in the SFI may override the direction configured by higher layer signaling.

[0076] For both downlink Uu and sidelink, an aspect of the reliability of the control channel is that the probability of blocking is low. Blocking may occur when the resources configured to schedule the PDCCH or PSCCH are not available. Increasing the resource pool can help reduce this blocking probability. However, for both Uu traffic and sidelink traffic, due to the stochastic nature of the traffic, there may be large variations in the resources immediately required for each of these two uses. Therefore, for example, allocating separate resources for each use and designing the system for the worst-case traffic for each use, due to very low average resource utilization, reduces the resource efficiency of the system. In an example, sidelink traffic may have a low average resource utilization with a very sufficient level of resources allocated for the worst-case traffic scenario. Similarly, Uu traffic may have a low average resource utilization with a high level of resources allocated. Also, in some cases, there may not be sufficient available resources for this type of separate design for the worst-case traffic for each channel under various use cases.

[0077] In some scenarios, limited PSCCH link adaptation may reduce the resource efficiency of the system. In LTE V2X, the PSCCH resources in the resource pool may be fixed to two RBs in a subframe. Additionally, its modulation order may also be fixed to quadrature phase shift keying (QPSK). The range of PSCCH transmission may be determined based on the number of RBs allocated for PSCCH transmission and the modulation and coding scheme (MCS) level used. Considering that NR V2X may require a wider range than that used in LTE for some V2X use cases, for example, 750 meters, the current fixed PSCCH link adaptation in LTE may not be appropriate for NR V2X.

[0078] In addition, LTE V2X may be designed for broadcast or groupcast transmission, so a fixed resource allocation targeting the worst-case scenario may be reasonable. However, since unicast transmission may also need to be supported, PSCCH link adaptation may be required for NR V2X.

[0079] In some scenarios, the limited resources for sidelink communication may reduce the resource efficiency of the system. In NR V2X, the sidelink control channel may be expected to carry control information, which varies greatly in terms of payload, reliability, latency, and communication range in supporting a wide range of extended V2X services. In addition, as described, sidelink control information may be expected to be transmitted as unicast, multicast, and broadcast, compared to LTE V2X which may be restricted to broadcast and groupcast. In the unicast case, the WTRU starting the transmission may need feedback from the receiving WTRU to achieve high reliability, resource efficiency, or both. Therefore, it may be desirable to have a method for efficiently multiplexing one or more sidelink control channels with one or more Uu control channels. There may also be a need for techniques to efficiently multiplex sidelink control channels transmitted in either direction in sidelink communication.

[0080] According to an embodiment disclosed herein, PSCCH link adaptation may be associated with a coverage level for sidelink. The coverage level may correspond to, or be determined based on, at least one of a V2X operation mode, a radio resource control (RRC) connection state, and / or a downlink measurement level. In an embodiment, the V2X operation mode may be a scheduled mode or an autonomous mode. Further, the operation mode may be the operation mode of a WTRU. In an embodiment, the RRC connection state may be the connection state of a WTRU.

[0081] In the V2X operation mode, the scheduled mode may be an operation mode in which the gNB can schedule one or more resources for PSCCH transmission, PSSCH transmission, or both. As described herein, the scheduled mode may be used interchangeably with, and still be consistent with, mode-1, the gNB scheduled mode, and / or the mode in which the gNB can schedule sidelink resources for sidelink transmission between two WTRUs provided herein. The autonomous mode may be an operation mode in which the WTRU can autonomously determine one or more resources within the candidate resources for PSCCH transmission, PSSCH transmission, or both. The candidate resources may be preconfigured. As described herein, the autonomous mode may be used interchangeably with, and still be consistent with, mode-2, the WTRU scheduled mode, and / or the mode in which a WTRU (e.g., a sender WTRU, a source WTRU, and a WTRU having a source ID, etc.) can schedule sidelink resources for sidelink transmission to another WTRU (e.g., a receiver WTRU, a destination WTRU, and a WTRU having a destination ID, etc.) provided herein.

[0082] In an example of the RRC connection state, RRC connected, RRC inactive, and RRC idle may be considered as the first coverage, and the non-RRC state may be considered as the second coverage. In the example, the first coverage may be in-network coverage, and the second coverage may be out-of-network coverage.

[0083] In an embodiment, the downlink measurement level may be the reference signal received power (RSRP) measurement level of a measurement reference signal. For the downlink measurement level, the measurement reference signal may include one or more of a synchronization signal block (SSB), a channel state information reference signal (CSI-RS), a tracking reference signal (TRS), or a DM-RS.

[0084] The terms “coverage level,” “coverage,” “proximity,” “proximity level,” “distance,” “distance level,” “range,” “range level,” and “measurement quality” may be used interchangeably herein and may still be consistent with the provided examples and embodiments.

[0085] One or more physical shared control channel (PSCCH) resource units (PRUs) may be used for PSCCH transmission. In the examples provided herein, PSCCH link adaptation may be based on one or more PRUs. A PRU may be at least one of a resource block (RB), the number of symbols, a control channel element (CCE), a resource element group (REG), and / or a REG bundle that can be used for a physical downlink control channel (PDCCH), a physical uplink control channel (PUCCH) resource, a slot, and / or a subframe or radio frame, may be composed of at least one of them, and / or may be defined, determined, or identified based on at least one of them.

[0086] In an embodiment, an RB may include a set of subcarriers. In an embodiment, the set may include 12 subcarriers. Further, the subcarriers may be consecutive or adjacent. Moreover, the set of subcarriers may include the number of symbols that can be within a time period or time unit such as a slot, a subframe, or a radio frame.

[0087] The number of symbols may be determined based on at least one of the number of uplink symbols, the number of downlink symbols, and the number of adaptable symbols configured, determined, and / or indicated in a time period or time unit such as a slot. The number of symbols may be fixed, for example, to 14, may be configured via higher layer signaling, and / or may be the same as the number of symbols for a mini-slot when the mini-slot is used for sidelink transmission. Further, the term "mini-slot" may be used interchangeably with sub-slot, non-slot, and x-symbol slot, etc., and may still be consistent with the embodiments provided herein.

[0088] CCE, REG, or REG bundle may be used for PDCCH such that, for example, a subset of PDCCH resources can be used for sidelink transmission. In an embodiment, the subset of PDCCH resources may include CCE, REG, and / or REG bundle. Further, in an embodiment, sidelink transmission may be on PSCCH.

[0089] For a PUCCH resource, the number of RBs used for the PUCCH resource may be configured via higher layer signaling or may be determined based on a coverage level.

[0090] One or more link adaptation modes may be used for PSCCH transmission. The link adaptation mode may be determined based on a traffic type. One or more traffic types may be used. For example, three traffic types may be used. In one embodiment, broadcast, groupcast, and unicast traffic types may be used. Further, the WTRU may determine the link adaptation mode based on which traffic type is used.

[0091] A fixed link adaptation mode or a quasi-static link adaptation mode may be used, in which the number of PRUs may be predefined, configured, or indicated by the gNB. In an example, the fixed link adaptation mode or the quasi-static link adaptation mode may involve a fixed or quasi-static number of PRUs and / or a fixed MCS. A fixed link adaptation mode or a quasi-static link adaptation mode may be used for a traffic type. In an example, a link adaptation mode may be used for a first traffic type. In an example, the first traffic type may be a broadcast traffic type.

[0092] An adaptable link adaptation mode may be used, in which a set of PRU aggregation levels may be configured, determined, or indicated by the gNB, for example, and the WTRU may select a PRU aggregation level from the set for PSCCH transmission, for example. An adaptable link adaptation mode may be used for a traffic type. In an example, a link adaptation mode may be used for a second traffic type. The second traffic type may be a unicast traffic type and / or a groupcast traffic type. The first PRU aggregation level may correspond to a first number of PRUs, the second PRU aggregation level may correspond to a second number of PRUs, and so on. The first number of PRUs and the second number of PRUs may be different from each other, and one or more sets of PRU aggregation levels may be used.

[0093] In an embodiment, a subset of the PRU aggregation levels for PSCCH / PSSCH transmission may be determined based on at least one of the QoS of the packets to be transmitted on the PSSCH, the channel busy ratio (CBR) range, the number of RBs per subchannel, the number of subchannels selected for PSCCH / PSSCH transmission, and the minimum required communication range. Further, the WTRU may select a PRU aggregation level from the determined subset.

[0094] One or each traffic type may be associated with sidelink control information (SCI) for PSCCH transmission. A first SCI, e.g., an SCI format, may be used for broadcast traffic types and / or groupcast traffic types, and the first SCI may include a group destination ID. A second SCI may be used for unicast traffic types, and the second SCI may include a WTRU-ID which may be a transmitter WTRU-ID or a receiver WTRU-ID.

[0095] The coverage level or coverage range of the WTRU may be used. The WTRU may determine a resource or set of resources for the transmission of a control channel, such as the PSCCH, based on the coverage level or coverage range of the WTRU. In an embodiment, the range of the WTRU may be the distance to another WTRU or the intended recipient of the PSCCH. For example, more resources may be used for poorer coverage. In an embodiment, more resources may include a larger set of resources.

[0096] The first WTRU may be a transmitter WTRU, the second WTRU may be a receiver WTRU, or vice versa. Additionally, the terms "V2X communication", "vehicle-to-vehicle (V2V) communication", "D2D communication", "direct communication", "sidelink communication", "UE-to-UE communication", and "WTRU-to-WTRU communication" may be used interchangeably in the embodiments provided herein.

[0097] According to an embodiment, a set of PRUs may be configured by a gNB as a resource pool for PSCCH transmission. For example, a PSCCH resource pool and a subset of PRUs within the PSCCH resource pool may be used. For example, control information, such as an SCI, may be transmitted in a subset of PRUs within the PSCCH resource pool, and the subset of PRUs, such as the number of PRUs, may be determined by at least one of the WTRUs based on, for example, a measurement signal from the WTRU, such as location information, the distance, coverage level, or coverage range between two WTRUs, the RRC connection state, such as a connected state, an inactive state, an idle state, a V2X operation mode, such as a scheduled mode and an autonomous mode, and / or the coverage state, such as in-network coverage and out-of-network coverage.

[0098] According to an embodiment, for example, when the measurement of a signal from a WTRU is below a threshold, a first subset of PRUs or a first number of PRUs may be used. When the measurement is above the threshold, a second subset of PRUs or a second number of PRUs may be used. The first subset may be larger than the second subset. The measurement may be an RSRP measurement, a channel state information (CSI) measurement, or both. In an embodiment, the CSI may include one or more of a channel quality indicator (CQI), a precoding matrix indicator (PMI), or a rank indicator (RI). The signal may be a discovery signal from a first WTRU or a second WTRU. The first WTRU may measure a signal from the second WTRU and determine a subset of PRUs or a number of PRUs for PSCCH transmission. The first WTRU may transmit the PSCCH on the determined PRUs.

[0099] According to another embodiment, when the distance between a first WTRU and a second WTRU is less than a first threshold, a first subset of PRUs or a first number of PRUs may be used. Further, when the distance between the first WTRU and the second WTRU is longer than the first threshold, or longer than a first threshold value and less than a second threshold, a second subset of PRUs or a second number of PRUs may be used, and so on. The distance may be used interchangeably with range, coverage, or proximity and may still be consistent with the embodiments provided herein. The subset or number of PRUs that can be used for PSCCH based on the distance may be predetermined, preconfigured, configured, or indicated, for example, by a gNB.

[0100] In an embodiment, location information may be provided by a first WTRU to a second WTRU. In another embodiment, the location information may be provided by the second WTRU to the first WTRU. The location information may be transmitted in a discovery signal and optionally provided when available. Further, the location information may be exchanged between the first WTRU and the second WTRU. Also, the location information may be location information obtained from a GPS signal and / or a location reference signal. In an embodiment, the location information may be obtained from a Global Navigation Satellite System (GNSS).

[0101] In the scheduled mode, the gNB can provide, for example, distance information when the gNB schedules resources for PSCCH transmission.

[0102] The WTRU may determine the number of PRUs based on channel conditions, distance, and / or location information. The WTRU may determine a subset of the PRUs based on the determined number of PRUs. One or more subsets of the PRUs may be predefined or configured with respect to the number of PRUs that can be used for PSCCH transmission. One or more subsets of the PRUs may be mutually exclusive, may partially overlap, or may completely overlap. Based on the number of PRUs used or the determined number of PRUs, the transmitter WTRU and / or the receiver WTRU may have information from a configuration regarding, for example, which subset of the PRUs can be used. For a given number of PRUs, one or more subsets of the PRUs may be determined as candidates for PSCCH transmission. The transmitter WTRU may select one of the subsets of the PRUs for PSCCH transmission, and the receiver WTRU may attempt to decode one or more of the determined candidates. In an embodiment, the receiver WTRU may attempt to decode all of the determined candidates.

[0103] When location information is available, the number and / or subset of PRUs for PSCCH transmission and / or reception may be determined based on the distance between two WTRUs or based on the location information. Alternatively, the number and / or subset of PRUs may be determined based on the measurement of signals from at least one of the WTRUs.

[0104] Figure 2 is a diagram showing the PSCCH resource pool and the procedure for determining PSCCH resources for each range. In particular, Figure 2 shows the PSCCH resource pool configuration of an embodiment and the procedure of the WTRU for determining the PSCCH resources used to transmit the SCI from within the resource pool. As shown in the embodiment in Figure 2, the resource pool may correspond to a range, for example, the distance or proximity between two WTRUs. For example, the range may be between, for example, the WTRU transmitting the PSCCH and, for example, the WTRU receiving the PSCCH. Further, location information may be used to determine the range.

[0105] The measurement may be replaced with location information and still be consistent with the embodiments provided herein. The coverage level may be replaced with a range and still be consistent with the embodiments provided herein.

[0106] In the embodiment shown in Figure 2, the gNB may configure a PSCCH resource pool 210, the PSCCH resource pool 210 may include a set of PRUs, and the PRUs within the PSCCH resource pool may be divided into one or more range-specific PSCCH resource pools such that the WTRU can use the range-specific PSCCH resource pool having a corresponding range.

[0107] As an example, for instance, three range-specific PSCCH resource pools may be used, determined, or configured by the gNB. In the example shown in FIG. 2, the ranges may be labeled as Range 1, Range 2, and Range 3. The first range may be up to k1 meters, for example, k1 = 10, and may include one PRU per resource. Also, the second range may be up to k2 meters, for example, k2 = 50, and may include two PRUs per resource. Further, the third range may be k3 meters, for example, k3 = 100, and may include four PRUs per resource. Thus, the PSCCH resources may include one or more PRUs, and the same number of PRUs may be used or configured for the PSCCH resources within the same range-specific PSCCH resource pool. In an example, a longer distance range may use more PRUs than a shorter distance range. The term "range" may be used interchangeably with the minimum required communication range for a sidelink packet or service, and may still be consistent with the examples and embodiments provided herein.

[0108] The set of PRUs for each range-specific PSCCH resource pool may be mutually exclusive, partially overlapping, or fully overlapping. In the example shown in FIG. 2, the set of PRUs may be mutually exclusive.

[0109] One or more range-specific PSCCH resource pools may be located in different time resources and / or frequency resources. For a range-specific PSCCH resource pool, the subcarrier spacing may be independently configured, determined, or used. In an example, for each range-specific PSCCH resource pool, the subcarrier spacing may be independently configured, determined, or used. The subcarrier spacing may be different for the PSCCH resources based on the associated range.

[0110] For a range-specific PSCCH resource pool, the DM-RS density may be configured, determined, or predefined. In an embodiment, for each range-specific PSCCH resource pool, the DM-RS density may be configured, determined, or predefined. A higher DM-RS density may be used for a range-specific PSCCH resource pool targeting a larger range. For example, a DM-RS density of two symbols may be used for a first range, e.g., a PSCCH resource pool associated with up to k1 meters, a DM-RS density of three symbols may be used for a second range, e.g., a PSCCH resource pool associated with up to k2 meters, and a DM-RS density of four symbols may be used for a third range, e.g., a PSCCH resource pool associated with up to k3 meters.

[0111] In the embodiment shown in FIG. 2, the WTRU may determine a range, e.g., distance or proximity, based on, for example, location information received during a setup procedure between WTRUs (220). From the location information of the receiving WTRU, the transmitting WTRU may determine the range between WTRUs. For example, when location information is not available, measurements of signals from one of the WTRUs may be used to determine the range.

[0112] The WTRU may select an associated PSCCH resource pool based on the determined range (230). For example, the WTRU may determine a range-specific PSCCH resource pool within a configured resource pool based on the determined range. The determined range may be known between two WTRUs for direct communication. One of the two WTRUs may receive the location information of the other WTRU and may determine the range. The determined range information may then be signaled to the other WTRU. The location information of the two WTRUs may be exchanged for range determination, and both WTRUs may use the same location information for range determination. Zone information of the two WTRUs, such as a zone ID, may be exchanged for range determination, and as a result, zone information such as a zone ID can be determined based on the location information of the WTRU and parameters configured by the upper layer, such as a zone size. The PSCCH resource pool may include one or more PSCCH resources, and each PSCCH resource may be used for PSCCH and its associated PSSCH transmission.

[0113] The WTRU may determine a PSCCH resource within a PSCCH resource pool, such as a range-specific PSCCH resource pool, based on rules (250), and the PSCCH resource pool may include, for example, one or more PSCCH resources for a corresponding range. In an embodiment, the rules may be pre-defined rules. Further, the rules may be accompanied by a UE-ID or a WTRU-ID.

[0114] The WTRU-ID may be implicitly used by the WTRU, for example, to determine PSCCH resources within a PSCCH resource pool. The WTRU-ID may be an ID configured by the gNB for direct communication. For example, the WTRU-ID may be a sidelink radio network temporary identifier (SL-RNTI) that can be configured for a particular operating mode, such as V2X mode 3 and / or V2X mode 4. The WTRU-ID may include one or more most significant bits (MSBs) or least significant bits (LSBs) of the international mobile subscriber identity (IMSI) of the WTRU. For example, when all WTRUs for direct communication are within the same serving cell, the WTRU-ID may be a cell-RNTI (C-RNTI), and / or the WTRU-ID information may be known to both WTRUs. For example, in the scheduled mode, the gNB may provide WTRU-ID information to the WTRU involved in direct communication.

[0115] To determine PSCCH resources within a PSCCH resource pool, a Doppler frequency, such as the relative speed with respect to the WTRU, may be used. The relative speed may be determined based on the time / frequency density of the DM-RS or phase tracking reference signal (PTRS) for PSCCH transmission and / or PSSCH transmission. If a higher density is used, the relative speed may be considered higher.

[0116] To determine PSCCH resources within a PSCCH resource pool, the energy level detected during a given time window within each PSCCH resource may be used. The WTRU may perform detecting the PSCCH resource during the time window, and the PSCCH resource that may have the minimum energy level may be determined as the PSCCH resource for SCI transmission.

[0117] Random selection may be used to determine the PSCCH resources within the PSCCH resource pool. The range may be used interchangeably with the Doppler frequency, speed, mobility level, or relative speed between two WTRUs and may still be consistent with the embodiments provided herein. Further, the WTRU may transmit an SCI message on the selected PSCCH resource (270).

[0118] In an embodiment, the coverage report may be based on the PSCCH PRUs. For example, the WTRU may report its coverage level or distance level based on the number of PRUs used to successfully decode the SCI message. For example, the SCI message may be transmitted by N PRUs and the SCI may be decodable by a subset of the N PRUs. The WTRU may attempt to decode the SCI message by a subset of the N PRUs and if the WTRU successfully decodes the SCI message by a subset of the N PRUs, the WTRU may report, indicate, or transmit the number of PRUs within the subset.

[0119] In addition to this embodiment, one or more subset numbers may be configured or may be pre-configured. For example, when N PRUs are used, the subset number may include one or more of N / 16, N / 8, N / 4, and N / 2. Each subset number may be associated with a subset ID. For example, subset ID = 0 may be associated with N / 16, subset ID = 1 may be associated with N / 8, and so on. The N PRUs may be the maximum PSCCH aggregation level. In an embodiment, the aggregation level may be, for example, the CCE aggregation level and the PRU aggregation level. Further, the aggregation level may be within a set of aggregation levels. Also, a subset of the N PRUs may be another aggregation level that can also be within the set of aggregation levels. For example, a PSCCH aggregation level set AL-{n1,n2,n3,n4} may be configured, determined, or used such that AL-n4 can be the maximum aggregation level. The WTRU may attempt to decode all aggregation levels and may indicate, report, or feedback the minimum aggregation level at which the WTRU can successfully decode the associated SCI message. The WTRU may determine whether it succeeds in decoding the associated SCI based on a cyclic redundancy check (CRC) of the SCI. The N PRUs may be the maximum number of repetitions of PSCCH transmission. In an embodiment, the repetition may involve, for example, the number of symbols used, the number of retransmissions, and the number of transmissions. The PSCCH may be transmitted N times. Further, the PSCCH may be transmitted N times if the WTRU succeeds in decoding the associated SCI message with a subset of repetitions. A parameter Ns may be used to indicate the coverage level or distance between two WTRUs. In an embodiment, Ns may be less than N.

[0120] Alternatively or in addition, the WTRU may report its coverage level or distance level based on the time difference between a reference timing and the timing at which the destination WTRU received a signal from the transmitting WTRU. The reference timing may be based on the Uu signal from the gNB. For example, a WTRU within coverage may determine the reference timing based on a Uu synchronization signal from the gNB, such as an SS / PBCH block, or a CSI-RS, such as a tracking reference signal. Alternatively or in addition, the reference timing may be based on GNSS. Alternatively or in addition, the reference timing may be based on a sidelink synchronization signal transmitted from a local manager, where the local manager may be a WTRU capable of scheduling sidelink resources for sidelink transmissions with other WTRUs.

[0121] For PSCCH transmission, one or more CORESETs, and the associated search space(s) of the one or more CORESETs may be used. In an embodiment, for PSCCH transmission, the associated search space for each of the one or more CORESETs may be used.

[0122] According to an embodiment, one configured CORESET or each configured CORESET for the sidelink may be associated with a subset of physical resource blocks (PRBs) within the active BWP. The subset of PRBs may be used for PSCCH transmission and / or PSSCH scheduling. For example, the WTRU may transmit an SCI in the CORESET to schedule a PSSCH associated with the CORESET. The terms "PRB" and "RB" may be used interchangeably and may still be consistent with the examples and embodiments provided herein.

[0123] One or more CORESETs for PSCCH transmission may be transmitted or monitored in resources configured as uplink, for example, by SFI and / or by upper layer signaling. Alternatively or in addition, a subset of PRBs may be part of the CORESET configuration.

[0124] Alternatively or in addition, a subset of PRBs may be determined implicitly. For example, to improve resource utilization and avoid collisions from multiple CORESETs, the same set of PRBs configured for the CORESET for PSCCH may be used. CORESET and PSSCH may be multiplexed in the time domain within the same set of PRBs, for example, in the same slot or different slots. The subset of PRBs may be a function of the PRB configuration for the associated CORESET for PSCCH. For example, for PSSCH transmission, the PRBs for the CORESET and its adjacent N PRBs may be used.

[0125] Alternatively or in addition, a subset of PRBs may be determined based on, for example, at least one of the slot number, subframe number, and frame number of the PSCCH transmission.

[0126] Alternatively or in addition, a subset of PRBs may be determined based on the slot format, for example, based on the slot format of the slot in which PSCCH is transmitted. The slot format may include, for example, the number of downlink symbols, the number of uplink symbols, and the number of adaptable symbols.

[0127] Alternatively or in addition, a subset of PRBs may be determined based on, for example, the number of available REs for sidelink within the slot or symbol in which the PSCCH is transmitted. REs allocated for a particular direction, for example, DL, may not be counted as available REs. REs for PDSCH muting or Physical Uplink Shared Channel (PUSCH) muting, or for PDSCH rate matching or PUSCH rate matching may not be counted as available REs. REs for broadcast transmissions, for example, SSB, CORESET#0, may not be counted as available REs, and / or REs for periodic transmissions, for example, periodic CSI-RS, TRS, may not be counted as available REs.

[0128] Figure 3 is a diagram showing an example of a CORESET configuration based on sidelink type. According to the example, as in the example shown in FIG. 300, one CORESET or each CORESET configured for sidelink may be used, configured, or associated with a sidelink type, for example, a first sidelink type, a second sidelink type, or a third sidelink type. Further sidelink types may also be configured. In the example, the first sidelink type may be a type 1 sidelink, and the CORESET for this sidelink type may be associated with two RBs 310. Further, the second sidelink type may be a type 2 sidelink, and the CORESET for this sidelink type may be associated with one RB 320. Moreover, the third sidelink type may be a type 3 sidelink, and the CORESET for this sidelink type may be associated with four RBs 330.

[0129] The sidelink type may be determined based on one or more of coverage level, relative speed, or DM-RS configuration. In an embodiment, the coverage level may include one or more of range, proximity, distance, and measurement level. Further, the relative speed may be associated with a Doppler frequency. Also, the DM-RS configuration may be a DM-RS configuration for PSSCH transmission. In an embodiment, the DM-RS configuration may be a 1 symbol front-loaded DM-RS and N additional DM-RSs (plural available). In another embodiment, the DM-RS configuration may be a 2 symbol front-loaded DM-RS and M additional DM-RSs (plural available). In a further embodiment, the DM-RS configuration may be a DM-RS position within a slot.

[0130] Alternatively or in addition, the sidelink type may be determined based on a use case that can be determined, for example, based on whether the destination ID is a group ID for groupcast or broadcast, or for example, based on whether the destination ID is a WTRU-ID for unicast.

[0131] Alternatively or in addition, the sidelink type may be determined based on a sensing scheme. For example, one or more sensing schemes may be used. The first sensing scheme may be based on a first time window, during which the WTRU may need to perform sensing to determine PSCCH resources within a CORESET. In another embodiment, the second sensing scheme may be based on a second time window, and the first time window and the second time window may be predefined, predetermined, or configured by the gNB.

[0132] Alternatively or in addition, the sidelink type may be determined based on the sidelink operation mode. Further, in an embodiment, the sidelink operation mode may be a scheduled mode or an autonomous mode.

[0133] One CORESET or each CORESET may be associated with a set or subset of PRBs for PSSCH transmission, or may be configured for a set or subset of PRBs for PSSCH transmission, and the set or subset of PRBs may be determined based on the sidelink type associated with the CORESET. For example, the same set of PRBs configured for a CORESET for PSCCH may be used for a related PSSCH transmission, may be multiplexed in the time domain for a first sidelink type, and the configured set of PRBs may be used for a related PSSCH transmission for a second sidelink type. In an embodiment, the PRBs may be multiplexed in the time domain in different sets of symbols within a slot or in different slots. Further, in an embodiment, the configured set may be a separately configured set.

[0134] One or more CORESETs may be configured for sidelink transmission, and one CORESET or each CORESET may be configured by a time offset between the last symbol of the CORESET and the first symbol of the PSSCH. In an embodiment, the CORESET configuration may be provided to the WTRU. In another embodiment, the CORESET configuration may be known to the WTRU. A WTRU, e.g., a transmitting WTRU, may determine and / or use one of the configured CORESETs, for example, to indicate a related time offset for PSSCH transmission to another WTRU, e.g., a receiving WTRU.

[0135] As an example, the first CORESET may be configured with a time offset of n + k1, and the second CORESET may be configured with a time offset of n + k2. The configuration may be provided to the first WTRU and the second WTRU and / or may be known to the first WTRU and the second WTRU. The first WTRU, e.g., the transmitting WTRU, may transmit the PSCCH in the first CORESET. The second WTRU, e.g., the receiving WTRU, may receive the PSSCH at the timing of n + k1. When the SCI includes a time offset indication, the time offset configured by the upper layer may be invalidated by the indicated time offset from the SCI.

[0136] Alternatively, according to an example, an SCI type may be used to determine a time offset value for PSSCH transmission / reception. For example, one or more SCI types may be used, determined, or defined and then transmitted / received. Then, based on the one or more transmitted / received SCI types, a time offset for the PSSCH may be determined.

[0137] The SCI type may be determined based on the SCI format for the sidelink operation mode. The first SCI format, e.g., SCI format 0, may be used for the first sidelink operation mode, e.g., the gNB scheduled mode. Further, the second SCI format, e.g., SCI format 1, may be used for the second sidelink operation mode, e.g., WTRU autonomous resource selection.

[0138] The SCI type may be determined based on the SCI format used for a specific Uu resource. For example, a first SCI format, e.g., SCI format 0, may be used for PSCCH transmission and / or PSSCH transmission in an uplink resource and / or an adaptable resource configured for the Uu interface. Further, a second SCI format, e.g., SCI format 1, may be used for PSCCH transmission and / or PSSCH transmission in a downlink resource configured for the Uu interface.

[0139] The SCI type may be determined based on the traffic type of the associated PSCCH. For example, a first SCI type may be used for broadcast transmission and / or groupcast transmission, and a second SCI type may be used for unicast transmission. As a result, when the SCI is used for broadcast or groupcast, the SCI may include a group - destination ID. Alternatively or in addition, when the SCI is used for unicast, the SCI may include a WTRU - ID, e.g., a transmitting WTRU identity and / or a receiving WTRU identity.

[0140] The terms "SCI type" and "sidelink type" may be used interchangeably and still be consistent with the examples and embodiments provided herein.

[0141] According to an example, the gNB may activate / deactivate one or more CORESETs configured for the sidelink. For example, for a CORESET for a first sidelink type (e.g., gNB scheduled mode), the gNB may activate the associated CORESET. The activation information may be within the resource grant for sidelink transmission. In an example, the first sidelink type may be for a CORESET associated with two RB310.

[0142] Resource grants for sidelink transmissions may be monitored at least in the group common PDCCH, the group common search space, and / or the WTRU-specific search space.

[0143] One or more group common search spaces may be configured for grants for sidelink transmissions. Each group common search space may be associated with a sidelink type. The group common search space may be search space #0. The group common search space may be a search space configured for DCI by an SL-RNTI.

[0144] Regarding the WTRU-specific search space, when the WTRU monitors DCI for a sidelink resource grant, if the sidelink transmission is for broadcast traffic or groupcast traffic, the WTRU may monitor the group common search space. If the sidelink transmission is for unicast traffic, the WTRU may monitor the WTRU-specific search space. A dedicated WTRU-specific search space by a C-RNTI or a configured scheduling-RNTI (CS-RNTI) may be configured for the sidelink resource grant.

[0145] A time gap may be used between the reception of the gNB's activation signal for one or more CORESETs or search spaces for sidelink and the start time of the active window for the CORESET or search space. The time gap may be determined based on at least one of the sidelink type, the waveform used for the sidelink transmission, the subcarrier spacing, or the capabilities of the WTRU.

[0146] An activated CORESET or search space may remain active until the WTRU receives a deactivation signal. The WTRU may monitor the CORESET or search space while they are active or being activated.

[0147] An activated CORESET or search space for sidelink may be autonomously deactivated when there is no sidelink data to transmit. Thus, the WTRU may not need to monitor the active CORESET or search space when it has finished receiving sidelink data (e.g., all sidelink data).

[0148] The first WTRU may signal to the second WTRU an indication that the transmission of the first WTRU has been completed and / or that the second WTRU may not need to monitor an activated CORESET or search space for sidelink for at least some period of time. In an example, the first WTRU may be a transmitting WTRU and the second WTRU may be a receiving WTRU.

[0149] Furthermore, an activation signal for monitoring one or more CORESETs or search spaces for sidelink communication may be indicated by the gNB, and a deactivation signal for monitoring an activated CORESET or search space may be indicated by a WTRU such as a first WTRU within a group of WTRUs. In an example, the first WTRU may be a transmitting WTRU.

[0150] An activated CORESET (or search space) may remain active until a timer expires. The timer value may be predefined or configured and may be indicated in the control information where the activation signal is transmitted or received. If the WTRU is unable to finish its sidelink transmission before the timer expires, the WTRU may request a timer extension.

[0151] An activated CORESET or search space may be active while the counter is running or may remain active. The counter may be updated at each PSCCH monitoring occasion, which may be a slot or subslot in which a set of PSCCH candidates is monitored. In an embodiment, the counter may be updated by incrementing or decrementing. The counter may be reset to, for example, zero or another starting value when the WTRU receives an activation signal or indication, for example, from the gNB. The counter may stop when it reaches, for example, a stopping value or threshold that can be a maximum for incrementing the counter or, for example, a stopping value or threshold that can be a minimum for decrementing the counter. The stopping value or threshold may be configured for sidelink resources, may be predefined, or may be indicated in a grant.

[0152] The terms "CORESET" and "search space" may be used interchangeably and may still be consistent with one or more of the embodiments provided herein. Additionally, the terms "CORESET" and "PSCCH resource set" may be used interchangeably and may still be consistent with the embodiments provided herein. A search space may include one or more PSCCH candidates at a PSCCH monitoring occasion. A search space for sidelink may be associated with a CORESET configured for sidelink transmission. One or more search spaces may be configured for sidelink transmission and may be associated with the same CORESET or different CORESETS.

[0153] According to an embodiment, unused CEs may be identified. One or more PRU sets may be used for PSCCH blind decoding, and a PRU set includes one or more RBs.

[0154] FIG. 4 is a diagram showing an example of a plurality of Physical Shared Control Channel (PSCCH) resource unit (PRU) sets for PSCCH blind decoding. In the example shown in FIG. 400, the PRUs 410 may be numbered from 1 to 16. The PRU set - 1 may include PRU1 and PRU2. Also, the PRU set - 2 may include PRUs 1 to 4. Further, the PRU set - 3 may include PRUs 1 to 8, and the PRU set - 4 may include PRUs 1 to 16.

[0155] The set of PRUs for which the Physical Shared Semi - Persistent Scheduling Channel (PSSCH) can be scheduled may be located within the PSSCH frequency resources. For example, the PSCCH associated with the PSSCH may be located within the frequency resources for the associated PSSCH. A subset of the PRUs may be used for the PSCCH, and the remaining Control Channel Elements (CCEs) within the PSSCH frequency resources may be used for other signal transmissions. The subset of CCEs may be referred to as the CCE aggregation level. For example, the other signals may include at least one of a part of the associated PSSCH, an Automatic Gain Control (AGC) training signal, a reference signal, such as a Demodulation Reference Signal (DM - RS) or a Channel State Information - Reference Signal (CSI - RS), and / or a Hybrid Automatic Repeat reQuest - Acknowledgement (HARQ - ACK) signal, such as a Physical Sidelink Feedback Channel (PSFCH). The set of CCEs may be predefined or pre - configured.

[0156] According to an embodiment, the number of PRU(s) used for PSCCH transmission may be indicated in the SCI, and unused PRUs may be used for the associated PSSCH transmission. For example, the SCI may include information related to the number of PRUs used for SCI transmission. A bit field in the SCI may indicate the number of PRUs used for SCI transmission. This bit field may be referred to as at least one of the starting RB of the PSCCH transmission, the ending RB of the PSCCH transmission, or the number of RBs used for PSCCH transmission. Alternatively or in addition, the scrambling id and / or the scrambling mask for the CRC used for SCI transmission may indicate the number of PRUs used. One or more identities may be used to scramble the CRC of the SCI, and as a result, each identity can be associated with the number of PRUs. Further, the MCS level of the associated PSSCH may be used to determine the number of PRUs used for PSCCH transmission. For example, if a lower MCS level is used for the associated PSSCH, a larger number of PRUs may be used for PSCCH transmission, and if a higher MCS level is used for the associated PSSCH, a smaller number of PRUs may be used for PSCCH transmission. For example, for N1 < MCS level <= N2, the WTRU may determine that a first number of PRUs may be used for the PSCCH, and for N2 < MCS level <= N3, the WTRU may determine that a second number of PRUs may be used for the PSCCH, and so on. An SCI format or an SCI format indicator may be used to determine the number of PRUs used for PSCCH transmission.

[0157] According to an embodiment, for sidelink transmission, two types of waveforms may be used. For example, the first type of waveform may be OFDM for sidelink transmission, and the second type of waveform may be DFT-s-OFDM for sidelink transmission. A WTRU, e.g., a transmitting WTRU, may determine the waveform for PSCCH transmission and / or PSSCH transmission based on at least one of the range or coverage for sidelink transmission, the MCS level determined for the PSSCH, the repetition level determined for the PSCCH, PSSCH, or both, the number of retransmissions for the PSSCH, the transmission power level, e.g., the offset level from the maximum transmission power, MIMO related scheduling parameters, e.g., the transmission rank, the number of RBs scheduled for sidelink transmission, the relative speed with respect to the sidelink channel, the DM-RS density, the sidelink channel, the SCI format, and / or the subcarrier spacing.

[0158] For the WTRU to determine the waveform based on the transmission power level, e.g., if the transmission power level is within a certain range from the peak transmission power, e.g., Pc,max, the WTRU may use the second type of waveform for sidelink transmission. Otherwise, the WTRU may use the first type of waveform for sidelink transmission.

[0159] For the WTRU to determine the waveform based on the number of RBs scheduled for sidelink transmission, in an embodiment, if the number of scheduled RBs is less than a threshold, the WTRU may use the first type of waveform for sidelink transmission. Otherwise, the WTRU may use the second type of waveform for sidelink transmission.

[0160] For the WTRU to determine the waveform based on the relative speed with respect to the sidelink channel, for example, when the relative speed is higher than a threshold, the WTRU may use a second type of waveform for sidelink transmission. Otherwise, a first type of waveform may be used for sidelink transmission. In an embodiment, the relative speed may be the relative speed of devices that are each sidelink communicating with each other. The relative speed may be determined based on the DM-RS density. For example, a higher DM-RS density may be considered preferably used when the communicating WTRUs are at a higher relative speed.

[0161] In an embodiment where the WTRU determines the waveform based on the DM-RS density, one or more DM-RS densities may be used for the PSCCH and / or PSSCH. The DM-RS density may, for example, at least mean the number of symbols in the slot used for the DM-RS, or at least correspond to the number of symbols. For example, the first type of waveform may be used for a density with a maximum number of DM-RS symbols, for example, a density having two DM-RS symbols, and the second type of waveform may be used for a density with a number of DM-RS symbols greater than, for example, two DM-RS symbols.

[0162] For the WTRU to determine the waveform based on a sidelink channel, for example, the first sidelink physical channel, for example, the PSCCH may be based on a first type of waveform, for example, DFT-s-OFDM, and the second sidelink physical channel, for example, the PSSCH may be based on a second type of waveform, for example, OFDM. Alternatively, the first sidelink physical channel may be based on the first type of waveform, and the waveform for the second sidelink physical channel may be indicated from the first sidelink physical channel.

[0163] For a WTRU to determine a waveform based on an SCI format, for example, a first waveform may be used when transmission or reception of a sidelink channel is associated with a first SCI format, and a second waveform may be used when transmission or reception of a sidelink channel is associated with a second SCI format. In an example, the first SCI format may be format 0. In a further example, the second SCI format may be format 1.

[0164] In a PSCCH resource pool, a first subset of PSCCH resources may be reserved for a first type of waveform, and a second subset of PSCCH resources, e.g., the remainder of the PSCCH resources, may be reserved for a second type of waveform. A WTRU, e.g., a transmitting WTRU, may determine the PSCCH resources for transmission based on the waveform that the WTRU determines or intends to use for sidelink transmission. Further, the gNB may provide configuration information messages regarding which PSCCH resource(s) are associated with which type of waveform. PSCCH resources for different types of waveforms may be multiplexed in time.

[0165] In a similar example, in a PSCCH - PSSCH resource pool, a first subset of PSSCH resources may be reserved for a first type of waveform, and a second subset of PSSCH resources, e.g., the remainder of the PSSCH resources, may be reserved for a second type of waveform. A WTRU, e.g., a transmitting WTRU, may determine the PSSCH resources for transmission based on the waveform that the WTRU determines or intends to use for sidelink transmission. Moreover, the gNB may provide configuration information regarding which PSSCH resource(s) are associated with which type of waveform. PSSCH resources for different types of waveforms may be multiplexed in time.

[0166] According to an embodiment, the control channel may be shared between Uu and PC5. As a general matter, to improve efficiency in using resources, the approach may be to share resources between the Uu link and PC5. According to an embodiment, the approach may be to share a portion of the downlink resources for the sidelink (PC5).

[0167] An embodiment of sharing resources between Uu and PC5 may be implemented by using a portion of the resources allocated for PSCCH and PDCCH. To facilitate sharing resources between PDCCH and PSCCH, the same PDCCH structure or a similar structure may be used for PSCCH.

[0168] According to this embodiment, at least one of PSCCH, PSCCH resource, PSCCH candidate, or PSCCH decoding candidate may be composed of one or more CCEs, and the CCE may be constructed based on the NR PDCCH of the CCE.

[0169] The set of resources allocated for the sidelink control channel, which may also be referred to as the sidelink control channel resource pool, may be configured as one CORESET or as part of a PDCCH CORESET. The selection from among the PSCCH candidates within the resource pool may be performed autonomously by the WTRU using a mechanism such as semi-persistent scheduling (SPS) along with channel measurements, or alternatively, the selection may be performed by the gNB through, for example, a quasi-static configuration, dynamic scheduling, or a combination of both, such as a dynamic adaptation of the configured allocation.

[0170] The size of the PSCCH may be configurable by the gNB, fixed for all cases, dependent on the SCI format, or selected by the transmitting WTRU. The size of the PSCCH may be measured by the number of CCEs forming the PSCCH or PSCCH candidate.

[0171] As used hereinafter, PSCCH, PSCCH candidates, PSCCH decoding candidates, PSCCH blind decoding candidates, and PSCCH resources may be used interchangeably and may still be consistent with the embodiments provided herein. Additionally, sidelink transmitting WTRU, transmitting WTRU, transmitting machine WTRU, sidelink Tx WTRU, Tx WTRU, and the first WTRU may be used interchangeably and may still be consistent with the embodiments provided herein. Sidelink receiving WTRU, receiving WTRU, sidelink Rx WTRU, Rx WTRU, recipient WTRU, and the second WTRU may be used interchangeably and may still be consistent with the embodiments provided herein.

[0172] According to an embodiment, the WTRU may determine the size of the PSCCH based on the SCI format or may limit the size of the PSCCH to the smallest subset. For example, all of the PSCCH(s) associated with SCI format 1 may have the size of 4 CCEs. In another embodiment, SCI format 1 may be associated with an aggregation level of {4,8}, and SCI format 2 may be associated with an aggregation level of {8,16}.

[0173] According to another embodiment, PSCCH candidates within an assigned resource pool may have different sizes or aggregation levels, and the sidelink transmitting WTRU may determine which aggregation level will be used based on channel measurements and link adaptation to achieve a target SNR.

[0174] According to another embodiment, the WTRU may select an aggregation level based on measurements of traffic from other WTRUs and criteria for best collision avoidance. When the WTRU selects a PSCCH aggregation level, a coding rate may be selected based on the number of available resource elements in the PSCCH, along with the SCI size and rate matching.

[0175] The CCEs of the PSCCH may be consecutive and / or adjacent in frequency within the configured CORESET. According to another embodiment, the logical indexes of the CCEs of the PSCCH may be consecutive, but their physical positions may not be adjacent. The selection between adjacent or non-adjacent CCEs for the PSCCH may be implicitly configured by the selection of a non-interleaved mapping or an interleaved mapping of the REG bundles to the CCEs in the CORESET.

[0176] According to another embodiment, for PSCCH transmission, a configured set or subset of PDCCH candidates may be allowed, permitted, or used. For example, a subset of PDCCH candidates within a search space may be shared between the PDCCH and the PSCCH, and the DCI size and the SCI size may be adjusted. In the subset of PDCCH candidates, the WTRU may monitor a DCI having a C-RNTI and an SCI having an SL-RNTI. If one of the DCI and the SCI has a larger payload size, other control information may be zero-padded. The transmitting WTRU may receive information related to a subset of the PDCCH candidates of the receiving WTRU for sidelink transmission.

[0177] The PSCCH resources may be configured through the CORESET and the resource pool. In an embodiment, the resource pool for the PSCCH may be configured quasi-statically, dynamically scheduled, or assigned by a mix of the two approaches for all sidelink users in the cell, for their groups, or for each of them.

[0178] According to an embodiment, a pool of resources for a sidelink control channel may be configured as a common search space associated with one of the CORESETs already configured for the Uu downlink control channel, e.g., the PDCCH. The search space configuration for the sidelink resource pool may include monitoring opportunities, the number and size (or aggregation level) of PSCCH candidates, and the associated SCI format(s). In an embodiment, the monitoring opportunities may include monitoring periodicity, monitoring offset, and the monitoring pattern within a slot. In another solution, some of those parameters may be implicitly identified from other configured parameters. For example, the size of the PSCCH candidates may be implicitly obtained based on the SCI format configured for the PSCCH resource pool. For example, if the configured SCI format is format 1, an aggregation level of 4 may be obtained.

[0179] According to another embodiment, a part of the configured CORESET for PSCCH may be allocated by frequency allocation. This frequency allocation for PSCCH may be performed during the configuration of the CORESET. According to this embodiment, the CORESET may be composed of two sets of frequency allocations. In this case, the first set may indicate resources for the Uu downlink control channel, and the second set may indicate a resource pool for the sidelink control channel. The first set and the second set may be disjointed or overlapping. In one embodiment, the second set may be a subset of the first set. In the case of overlapping between the two sets, the gNodeB may dynamically indicate the availability or otherwise of those overlapping resources by means such as the group common PDCCH transmitted in CORESET0. The availability of those overlapping resources may be accompanied by, for example, the absence of Uu downlink control, and the otherwise may be accompanied by, for example, the presence of Uu downlink control. In another variation of this embodiment, the CORESET may be composed of two ranges of CCEs although by one frequency allocation. In a further embodiment, one range of CCEs may be associated with the PDCCH, and another range of CCEs may be associated with the PSCCH. In this way, the size of the PSCCH candidate may be a fixed value L or a set of fixed values {L i}(based on the SCI format). Also, each PSCCH candidate may be associated with L i non-overlapping consecutive CCEs within the resource pool. For example, if CCE1, …, 16 in the configured CORESET are associated with the PSCCH and the set of PSCCH sizes is {4,8}, the PSCCH candidates may be {1,2,3,4}, {5,6,7,8}, {9,10,11,12}, {13,14,15,16}, {1,2,3,4,5,6,7,8}, {9,10,11,12,13,14,15,16}.

[0180] Figure 5 is a flowchart showing an example of a WTRU procedure for transmitting PSCCH based on a resource pool configuration. As shown in flowchart 500, the WTRU procedure may include the case of autonomous PSCCH scheduling. In an example, the WTRU may start the procedure (505) and may receive a CORESET configuration including a CCE range for the PSCCH and a related SCI format (510). The WTRU may then determine whether the received related SCI format is SCI format 1 (520).

[0181] If the WTRU determines that it has received SCI format 1, the WTRU may then identify PSCCH candidates based on the CCE range and the AL for SCI format 1 (525). The WTRU may then select a PSCCH candidate based on measurements (535). In an example, the WTRU may select a PSCCH candidate that is best for minimizing the possibility of collision. Further, the WTRU may transmit the PSCCH with a coding rate based on SCI format 1 (545).

[0182] If the WTRU determines that it has not received SCI format 1, the WTRU may then select a PSCCH size based on channel measurements and link adaptation (530). Further, the WTRU may then identify PSCCH candidates based on the CCE range and the selected PSCCH size (540). Also, the WTRU may select a PSCCH candidate based on measurements (550). In an example, the WTRU may select a PSCCH candidate that is best for minimizing the possibility of collision. Further, the WTRU may transmit the PSCCH with a coding rate based on the SCI size and the selected PSCCH size (560).

[0183] In an embodiment, the resource subset determination may be based on the WTRU-ID. According to an embodiment, in order to support unicast and multicast applications for sidelink, one approach is to utilize the WTRU-ID and / or group ID. In cases where the WTRU-ID, group ID, or both are defined for the sidelink WTRU and all neighboring WTRUs know such IDs, they may be used to make the unicast sidelink and multicast sidelink more efficient.

[0184] According to an embodiment, a solution for making unicast sidelink communication and multicast sidelink communication more efficient may be to link the WTRU-ID and / or group ID to a subset of the resource pool for the PSCCH instead of the entire resource pool of the PSCCH. According to this embodiment, the active subset of the PSCCH resource pool for unicast or multicast may be determined (as a function) according to the WTRU-ID or group ID of the receiver WTRU. This function may be predefined, pre-defined, or quasi-statically configured by the gNB, or may be a specific function based on some parameter configured by the gNB. In this solution, the transmitter WTRU may use a subset of the resource pool based on the intended receiver(s) or receiving WTRU(s) for scheduling the PSCCH, and the receiving WTRU(s) may use a subset of the resource pool for blind detection of the PSCCH instead of the entire resource pool. Hereinafter, the WTRU-ID, C-RNTI, CS-RNTI, IMSI, System Architecture Evolution (SAE) temporary mobile subscriber identifier (s-TMSI), and any RNTI assigned or configured for the WTRU may be used interchangeably and may still be consistent with the embodiments provided herein. The group ID may be an RNTI assigned or configured for a group of WTRUs.

[0185] According to an embodiment, the function indicating the active subset associated with the WTRU-ID or group ID may be a hash function indicating the start of a PSCCH candidate. This hash function may be a hash function as a function of the RNTI defined for the Uu PDCCH in NR or LTE.

[0186] According to another embodiment, the function indicating the active subset associated with the WTRU-ID or group ID may be a many-to-one function based on a parity operation or a modulo operation. For example, the entire resource pool may be partitioned into two subsets, and the active subset associated with the WTRU-ID or group ID may be the first subset or the second subset, regardless of whether they are odd or even, respectively. As used herein, the WTRU-ID may be used interchangeably with a group ID, a source ID, a transmitter ID, a destination ID, a receiver ID, and / or a groupcast ID, and may still be consistent with the embodiments provided herein.

[0187] In an embodiment, the PSCCH design may be based on the NR PUCCH. According to an embodiment, the WTRU may transmit or receive an SCI on a PUCCH resource within a dedicated pool of PUCCH resources for sidelink communication. The PUCCH resource set for sidelink transmission may be provided by higher layer signaling. The WTRU may also be provided with the maximum number of SCI bits that the WTRU can use to transmit on a PUCCH resource in a PUCCH resource set by a higher layer. In the context of the embodiments provided herein, the SCI may include control scheduling information transmitted by the transmitting WTRU or feedback control information transmitted by the receiving WTRU. The feedback control information may include HARQ-ACK, CSI, etc. Also, the PSCCH may be interchangeably used as a physical channel that carries the SCI in either direction. For example, there may be two-way communication between two WTRUs. Based on the principle of this design, a unified design for the sidelink control channel that will be used to carry sidelink control information in either communication direction may be provided.

[0188] According to an embodiment, the WTRU may share PUCCH resources between sidelink communication and Uu communication. The WTRU may be configured by one or more sets of PUCCH resources by a higher layer for both sidelink communication and Uu communication.

[0189] The WTRU may, for example, determine PUCCH resources for sidelink communication for the PSCCH. As a result, the WTRU can determine whether to use the PUCCH resources configured for Uu communication for sidelink transmission based on whether the WTRU is within or outside the coverage of the gNB coverage. For example, when the WTRU is outside the gNB coverage, the WTRU may select any PUCCH resource from among the PUCCH resource sets configured for Uu communication for sidelink communication. When the WTRU is within the gNB coverage, the WTRU may only have access to a subset of the PUCCH resource set or a list of PUCCH resource indices within the PUCCH resource set for sidelink communication. The list of available PUCCH resource indices or indices of PUCCH resource sets (if multiple) for sidelink communication may be configured by a higher layer.

[0190] If the WTRU is not transmitting on the configured PUCCH resources for Uu communication in a given slot and the WTRU is transmitting an SCI, in an example, the WTRU may transmit the SCI on the PUCCH resources configured for Uu communication.

[0191] The WTRU may determine whether to use PUCCH resources for sidelink transmissions depending on its timing synchronization or the accuracy of the synchronization mechanism available at the WTRU. The synchronization mechanisms available at the WTRU may include sidelink synchronization signals, Uu synchronization signals, and GNSS, among others. As an example, if the WTRU determines that the synchronization accuracy does not meet the V2X use case requirements such as a specific timing threshold and may cause interference to other UL transmissions, the WTRU may refrain from using the PUCCH resources configured for Uu communication for sidelink communication. If the WTRU performs sidelink synchronization exclusively based on sidelink synchronization signals, GNSS, or both, the WTRU may refrain from using the PUCCH resources configured for Uu communication. Further, if the WTRU synchronizes based on the synchronization signals received from the gNB, the WTRU may use the PUCCH resources configured for Uu communication for sidelink communication.

[0192] The WTRU may determine whether to use PUCCH resources for sidelink transmission or Uu transmission based on several priority rules. For example, if the WTRU needs to transmit an SCI to the gNB on a PUCCH resource that is predicted to be used for HARQ-ACK / scheduling request (SR) and periodic / aperiodic CSI, or if the WTRU determines that the PUCCH resource to be used for the SCI overlaps with the PUCCH resource that is to be used for UCI transmission, the WTRU may drop the SCI or UCI based on a pre-specified priority criterion. For example, if the WTRU is predicted to transmit HARQ-ACK / SR to the serving gNB on the PUCCH, the WTRU may drop the SCI and include only the HARQ-ACK / SR in the PUCCH. Thus, in an embodiment, the PUCCH resource may be used for Uu communication. If the WTRU is predicted to transmit periodic / aperiodic CSI to the serving gNB on the PUCCH, the WTRU may drop the periodic / aperiodic CSI report(s) and transmit only the SCI on the PUCCH. Thus, in an embodiment, the PUCCH resource may be used for sidelink communication.

[0193] Among the uplink control channel formats supported for Uu communication in NR, the WTRU may use a PUCCH resource configured for a particular threshold for sidelink communication, e.g., a PUCCH format that supports a payload larger than 2 bits, e.g., PUCCH format 2, PUCCH format 3, or PUCCH format 4.

[0194] The WTRU may use a subset of PUCCH formats configured for Uu communication based on the associated waveform of the PUCCH format, the length of the PUCCH in terms of the number of symbols in a slot, the PUCCH bandwidth in terms of the number of RBs, or the user multiplexing ability of the PUCCH format. As an example, the WTRU may use only PUCCH resources associated with a short PUCCH format having one or two symbols for sidelink transmission, e.g., for the PSCCH. The WTRU may use only PUCCH resources associated with a long PUCCH format having four or more symbols for sidelink transmission, e.g., for the PSCCH. Also, the WTRU may use only PUCCH resources associated with a PUCCH format based on an OFDM waveform for sidelink transmission. Further, the WTRU may use only PUCCH resources associated with a PUCCH format based on a DFT-s-OFDM waveform for sidelink transmission. Additionally, the WTRU may use only PUCCH resources associated with a PUCCH format that can support user multiplexing on the same time-frequency resource for sidelink transmission.

[0195] The WTRU may be configured by a higher layer with two PSCCH resource sets, one for transmission of the PSCCH and one for reception of the PSCCH. The PSCCH resource sets may partially or fully overlap to maximize resource utilization.

[0196] According to an embodiment, the WTRU may determine the PSCCH format, PSCCH resources, number of symbols within a slot, and set of RBs for PSCCH transmission based on a category of requirements to support an extended V2X scenario that includes parameters. The V2X scenario may include, for example, platooning, advanced driving, extended sensors, and remote driving. The parameters may include, for example, the payload of the SCI, maximum end-to-end latency, reliability, and / or minimum required V2X communication range. In an embodiment, the payload of the SCI may be provided in units of the number of uncoded or coded bits. Further, the maximum end-to-end latency may include, for example, the time from the transmission of the SCI by the transmitting WTRU to the time when the SCI is accurately detected at the receiving WTRU. Also, the reliability may include, for example, an SCI block error rate in the range from 10% to 0.001%. Additionally, the minimum required V2X communication range may include, for example, 50 meters for short-range communication and up to 1000 meters for long-range communication.

[0197] According to an embodiment, the WTRU may use a short PSCCH format having one or two OFDM symbols for V2X applications that include short-range communication, such as sharing sensor information between WTRUs and / or for low-latency applications. The low-latency applications may include, for example, emergency trajectory alignment between WTRUs to support advanced driving.

[0198] According to another embodiment, the WTRU may use a long PSCCH format having four or more OFDM symbols for V2X applications including long-range communication, such as sharing video between WTRUs to support extended sensors and / or for high-reliability applications. High-reliability applications may include, for example, information exchange between a WTRU supporting a V2X application for supporting remote driving and a V2X application server.

[0199] In an embodiment, the WTRU may perform sidelink control channel format / resource determination based on the SCI format. By way of example, the WTRU may determine a PSCCH format and corresponding PSCCH resources or resource pool according to the SCI format. For example, if the SCI format can be defined for short payload, low latency, or short-range sidelink communication, the WTRU may use a short PSCCH format. Further, if the SCI format is defined for large payload, high-reliability, or long-range sidelink communication, the WTRU may use a long PSCCH format.

[0200] In a further embodiment, an adaptive scrambler initializing parameter may be used for the PSCCH. According to an embodiment, the WTRU may estimate different initialization parameters, e.g., c_init, for a scrambling sequence generator for scrambling a PSCCH payload adapted to a PSSCH transmission mode. In an embodiment, the PSSCH transmission mode may be unicast, groupcast, or broadcast. In an embodiment, the WTRU may determine an initialization parameter, e.g., c_init, such that it is in one or more of the following steps. For example, if the PSSCH is for unicast, the initialization parameter, e.g., c_init, may be a function of the WTRU-ID or RNTI. Further, in an embodiment, n_RNTI = C_RNTI. Also, if the PSSCH is for broadcast, the initialization parameter, e.g., c_init, may not be a function of the WTRU-ID or RNTI. For example, n_RNTI = 0, or no scrambling may be performed at all. If the PSSCH is for multicast, the initialization parameter, e.g., c_init, may be a function of the group ID, e.g., group RNTI.

[0201] In an embodiment, the PSCCH design may be based on the PUSCH. A PUSCH may be used for sidelink transmission, e.g., for the PSCCH or PSSCH. The PUSCH may have a variable DM-RS density based on a higher layer configuration, where the DM-RS density may be the number of DM-RS symbols used for PUSCH transmission or PSSCH transmission, or may include the number of DM-RS symbols used for PUSCH transmission or PSSCH transmission. The DM-RS density may be the number of REs used for DM-RS transmission within the PSCCH resource or PSSCH resource, or may include the number of REs used for DM-RS transmission within the PSCCH resource or PSSCH resource.

[0202] One or more DM-RS densities may be used, may be determined, or may be configured, and each DM-RS density may be associated with the number of symbols used for the DM-RS within a slot. The position of the DM-RS may be determined based on the available symbols, the start symbol of the sidelink transmission, the slot structure, and / or the number of DM-RS symbols. In an embodiment, the available symbols may be OFDM symbols, DFT-s-OFDM symbols, etc. Further, the available symbols may be for sidelink transmission within a slot. In an embodiment, the sidelink transmission may be PSCCH and / or PSSCH. Further, in an embodiment, the slot structure may include the number of downlink symbols, the number of adaptable symbols, and the number of uplink symbols. Moreover, the number of DM-RS symbols may be the number of DM-RS symbols for sidelink transmission.

[0203] FIG. 6 is a diagram showing an embodiment of DM-RS type and density. As shown in the embodiment in FIG. 600, one or more DM-RS types may be used, may be determined, or may be configured. As an example, the DM-RS type may be determined based on the time position of the DM-RS symbol. Further, the DM-RS density may be considered as the number of DM-RS symbols within a slot. For example, one DM-RS density may mean that the slot has one DM-RS symbol, two DM-RS densities may mean that the slot has two DM-RS symbols, three DM-RS densities may mean that the slot has three DM-RS symbols, four DM-RS densities may mean that the slot has four DM-RS symbols, and so on. Moreover, the DM-RS density may be used interchangeably with the PTRS density and may still be consistent with the examples and embodiments provided herein.

[0204] In an embodiment, Type-1 DM-RS may include at least two DM-RS symbols located in consecutive OFDM symbols. For example, slot 620 may include DM-RS symbol 623 and DM-RS symbol 624 as consecutive OFDM symbols. Each of the other symbols in slot 620 may be a PSCCH symbol, a PSSCH symbol, or both, and the same type or mixture of those other symbols may be used within the same slot. For example, symbol 628 may be a PSCCH symbol, and symbol 629 may be a PSSCH symbol. In another embodiment, symbol 628 may be a PSSCH symbol, and symbol 629 may be a PSCCH symbol. In a further embodiment, both symbol 628 and symbol 629 may be PSCCH symbols. In an additional embodiment, both symbol 628 and symbol 629 may be PSSCH symbols. Since DM-RS symbol 623 and DM-RS symbol 624 are consecutive OFDM symbols, slot 620 may be considered to include Type-1 DM-RS. Further, since slot 620 includes two DM-RS symbols, slot 620 may be considered to have two (2) densities.

[0205] Furthermore, slot 630 may include DM-RS symbol 633 and DM-RS symbol 634 as consecutive OFDM symbols, and may include DM-RS symbol 638 and DM-RS symbol 639 as consecutive OFDM symbols. As described above, each of the other symbols in slot 630 may be a PSCCH symbol and / or a PSSCH symbol. Since DM-RS symbol 633 and DM-RS symbol 634 are consecutive OFDM symbols, and DM-RS symbol 638 and DM-RS symbol 639 are consecutive OFDM symbols, slot 630 may be considered to include Type-1 DM-RS. Further, since slot 630 has four DM-RS symbols, slot 630 may be considered to have four (4) densities.

[0206] In addition, Type-2 DM-RS may be based on distributed DM-RS symbols. Further, Type-2 DM-RS does not necessarily need to include consecutive DM-RS symbols. For example, slot 640 may include DM-RS symbol 641. Each of the other symbols within slot 640 may be a PSCCH symbol, a PSSCH symbol, or both. If the next slot transmitted in time is a slot of the same type and density, another DM-RS symbol may then be transmitted after 13 other symbols have been transmitted. Since the DM-RS symbols are transmitted at the same time position for each slot of the same type and density, the DM-RS symbols may be considered to be distributed. Further, since slot 640 has one DM-RS symbol, slot 640 may be considered to have one (1) density.

[0207] Further, slot 650 may include DM-RS symbol 653 and DM-RS symbol 659. Each of the other symbols within slot 650 may be a PSCCH symbol and / or a PSSCH symbol. In an embodiment, 8 symbols may separate DM-RS symbol 653 and DM-RS symbol 659. Also, 2 symbols may separate the start of the slot and DM-RS symbol 653, and 2 symbols may separate the end of the slot and DM-RS symbol 659. As a result, the DM-RS symbols within slot 650 may be considered to be distributed. Further, since slot 650 has two DM-RS symbols, slot 650 may be considered to have two (2) densities.

[0208] In addition, slot 660 may include DM-RS symbol 663, DM-RS symbol 668, and DM-RS symbol 669. Each of the other symbols within slot 660 may be a PSCCH symbol and / or a PSSCH symbol. The distance between the DM-RS symbols is spread over either three other symbols or four other symbols. For example, four other symbols separate DM-RS symbol 663 and DM-RS symbol 668. Also, three other symbols separate DM-RS symbol 668 and DM-RS symbol 669. Moreover, four other symbols separate DM-RS symbol 669 and the next DM-RS symbol in the next slot of the same type and density. Thus, the next DM-RS symbol appears at symbol position 3 in the next slot. As a result, the DM-RS symbols within slot 660 may be considered to be spread out. Further, since slot 660 has three DM-RS symbols, slot 660 may be considered to have three (3) densities.

[0209] Moreover, slot 670 may include DM-RS symbol 673, DM-RS symbol 674, DM-RS symbol 678, and DM-RS symbol 679. Each of the other symbols within slot 670 may be a PSCCH symbol or a PSSCH symbol. The distance between the DM-RS symbols is spread over two other symbols. For example, two other symbols separate DM-RS symbol 673 and DM-RS symbol 674, two other symbols separate DM-RS symbol 674 and DM-RS symbol 678, and two other symbols separate DM-RS symbol 678 and DM-RS symbol 679. Also, two symbols separate the start of the slot and DM-RS symbol 673, and two symbols separate the end of the slot and DM-RS symbol 679. As a result, the DM-RS symbols within slot 670 may be considered to be spread out. Further, since slot 670 has four DM-RS symbols, slot 670 may be considered to have four (4) densities.

[0210] According to an embodiment, the DM-RS density for PSCCH transmission and / or PSSCH transmission may be indicated from the grant for sidelink transmission. For example, the gNB may transmit a grant for resources for sidelink transmission, and the DM-RS density for sidelink transmission may be indicated in the grant. The grant may be in a DCI message that can be monitored by the WTRU within the PDCCH search space. Alternatively, the grant may be signaled via higher layer signaling, e.g., via RRC signaling and / or via MAC control element (CE). The grant may be able to provide one or more sidelink resources within a resource pool and / or may be able to provide a group ID or a WTRU-ID.

[0211] According to another embodiment, the DM-RS density for PSCCH / PSSCH transmission may be determined based on at least one of the range or coverage for sidelink transmission, the repetition level determined for PSCCH transmission, PSSCH transmission, or both, the number of retransmissions of the PSSCH or the number of HARQ-ACKs, the transmission power level, the number of RBs or subchannels scheduled for sidelink transmission, QoS, the CBR of the resource pool, the relative speed with respect to the sidelink channel, the SCI format, the subcarrier spacing, the sidelink resource position within the resource pool, e.g., in time, frequency, or both, and / or the number of symbols used for PSCCH transmission or PSSCH transmission. In an embodiment, the range may refer to the minimum required communication range of the sidelink packet to be transmitted. In a further embodiment, the coverage may refer to whether the device is within or outside the coverage. The number of retransmissions for the PSSCH may be utilized such that a first DM-RS density can be used for a first PSSCH transmission and a second DM-RS density can be used for a second PSSCH transmission. The transmission power level may include an offset level from the maximum transmission power. In a further embodiment, if the transmission power level is within a certain range from the peak transmission power, e.g., Pc,max, the WTRU may use a first DM-RS density for PSCCH transmission or PSSCH transmission. Otherwise, the WTRU may use a second DM-RS density for PSCCH transmission or PSSCH transmission. In an embodiment, the SCI format may be associated with sidelink channel transmission or sidelink channel reception. In a further embodiment, a first DM-RS density may be used when the transmission or reception of the sidelink channel is associated with a first SCI format, e.g., format 0, and a second DM-RS density may be used when the transmission or reception of the sidelink channel is associated with a second SCI format, e.g., format 1.In another embodiment, the first DM-RS density may be used when the CBR is higher than a threshold, the second DM-RS density may be used when the CBR is below the threshold, and the threshold may be determined based on at least one of QoS, coverage, number of retransmissions, and transmission power level.

[0212] According to another embodiment, a first WTRU, e.g., a receiving WTRU, may request a DM-RS density for a subsequent sidelink transmission, e.g., a PSCCH or a PSSCH. In an embodiment, the WTRU may request a preferred DM-RS density. The request may be made to a gNB, or a second WTRU, e.g., a transmitting WTRU. The gNB or the second WTRU may acknowledge the request, e.g., indicate to the first WTRU a DM-RS density, e.g., a new DM-RS density or an updated DM-RS density, and / or may change the DM-RS density for transmission, e.g., based on the received request.

[0213] Embodiments of DM-RS density adaptation without CSI are disclosed herein. The source WTRU may or may not have CSI for a sidelink channel or subchannel between the source WTRU and the destination WTRU. In cases where the source WTRU may not have CSI even when the destination WTRU reports a negative acknowledgment (NACK), errors may occur due to the lack of DM-RS density resulting in poor channel estimation, and simple retransmission may not recover the incorrect transmission.

[0214] According to an embodiment, the DM-RS density for a sidelink transmission for unicast traffic, e.g., a PSCCH transmission, a PSSCH transmission, or both, may be determined based on the number of retransmissions or the redundancy version number, and the destination WTRU may be able to indicate HARQ-ACK and / or HARQ-NACK to the source WTRU. In an embodiment, the destination WTRU may be a receiving WTRU, and the source WTRU may be a transmitting WTRU.

[0215] One or more DM-RS densities, DM-RS types, or both may be used, and each DM-RS density and / or type may be associated with a retransmission count or a redundancy version number. The retransmission count or the redundancy version number may be counted by the source WTRU(s) and the destination WTRU(s). The destination WTRU or the receiving WTRU may determine the DM-RS density for sidelink channel reception based on the counted retransmission count or redundancy version number.

[0216] Figure 7 is a diagram showing an example of DM-RS density determination based on a redundancy version number. In the example shown in Figure 700, the source WTRU 720 may transmit one or more transmissions to the destination WTRU 780. The transmission may be a type-2 DM-RS transmission. In the example, the type-2 DM-RS transmission may be otherwise described herein. For example, the source WTRU 720 may prepare a type-2 DM-RS transmission 730 with one (1) DM-RS density. Thus, the source WTRU 720 may transmit a first transmission 738 to the destination WTRU 780 at a DM-RS density of one and a redundancy version number of zero (0). The destination WTRU 780 may not succeed in receiving the first transmission 738, and as a result, may transmit a NACK 742 to the source WTRU 720. As a result, the source WTRU 720 may prepare a type-2 DM-RS retransmission 740 to the destination WTRU 780 and may increment the redundancy version number to 2 (two). Based on the increased redundancy version number, the source WTRU 720 may also determine an increased DM-RS density. Thus, based on a redundancy version number of 2, the source WTRU 720 may determine an increased DM-RS density of 2 (two) for the retransmission 740. In this way, the source WTRU 720 may transmit the retransmission 740 as a second transmission 748 to the destination WTRU 780 at a DM-RS density of 2 and a redundancy version number of 2.

[0217] Furthermore, the destination WTRU 780 may fail to receive the second transmission 748, and as a result, may send another NACK 752 to the source WTRU 720. Thus, the source WTRU 720 may prepare for a further type-2 DM-RS retransmission 750 to the destination WTRU 780 and may further increment the redundancy version number to 3(3). Further, based on the redundancy version number of 3, the source WTRU 720 may determine an increased DM-RS density of 4(4). Thus, the source WTRU 720 may send a further retransmission 750 as a third transmission 758 to the destination WTRU 780 at a DM-RS density of 4 and a redundancy version number of 3.

[0218] In an embodiment, the destination WTRU 780 may then successfully receive the third transmission 758. In another embodiment, the destination WTRU 780 may then fail to receive the third transmission 758 and may further cooperate with the source WTRU 720 to continue the processes described above. The processes described above may continue until the destination WTRU 780 successfully receives a transmission from the source WTRU 720, or until a timer expires, or until another event such as a control signal is received by the destination WTRU 780 occurs.

[0219] One or more DM-RS densities, DM-RS types, or both may be used, configured, or pre-configured, and each DM-RS density, DM-RS type, or both may be associated with a redundancy version number. The association between the DM-RS density and the redundancy version number may be predefined, pre-configured, or configured. The association between the DM-RS density and the redundancy version number may be configured or determined based on a resource pool, a resource pool ID, or a resource ID within a resource pool.

[0220] FIG. 8 is a flowchart showing an example of DM-RS density determination based on one or more HARQ parameters. In the example shown in flowchart 800, the WTRU may determine whether HARQ feedback is enabled (830). In an example, the WTRU may be the source WTRU. In another example, the WTRU may be the transmitting WTRU. Further, conditioned on HARQ feedback being enabled, the WTRU may determine the DM-RS density for sidelink transmission based on the HARQ parameters and associated information (850). The WTRU may then transmit the sidelink transmission with one or more DM-RSs at the determined DM-RS density (870).

[0221] FIG. 9 is a flowchart showing an example of DM-RS density determination based on one or more HARQ parameters. In the example shown in flowchart 900, the WTRU may determine whether HARQ feedback is enabled (930). In an example, it may be the source WTRU. In another example, the WTRU may be the transmitting WTRU. Further, conditioned on HARQ feedback being disabled, the WTRU may determine the DM-RS density for sidelink transmission based on the DM-RS density indicator field (950). The WTRU may then transmit the sidelink transmission with one or more DM-RSs at the determined DM-RS density (970).

[0222] In an example, the WTRU may be composed of, or pre-configured with, one or more DM-RS time densities for sidelink transmission. In a further example, the DM-RS density indicator field may be received by the WTRU in the associated SCI. Also, in an example, the associated information may be predefined.

[0223] Also, in an embodiment, the association information may include information regarding the association between the configured DM-RS time density and the HARQ parameters. In a further embodiment, the association information may be received by the WTRU. In an embodiment, the association information may be received via an RRC message. In another embodiment, the association information may be received in the associated SCI. Further, in an embodiment, the association information may be an indication. In a further embodiment, the association information may be an index.

[0224] In an additional embodiment, the HARQ parameters may include one or more of a redundancy version number, a new data indicator (NDI) bit toggle state, a HARQ retransmission count, or a HARQ process number. Further, the HARQ parameters may be received in the associated SCI.

[0225] In a further embodiment, the WTRU may transmit a sidelink transmission to a destination WTRU. In another embodiment, the WTRU may transmit a sidelink transmission to a receiving WTRU. In an additional embodiment, the sidelink transmission may be a PSCCH. Further, in an embodiment, the sidelink transmission may be a PSSCH.

[0226] When CSI feedback is disabled, the DM-RS density may be determined based on the retransmission count, the redundancy version number, or both. When CSI feedback is enabled, the DM-RS density may be indicated based on at least one of, for example, a DM-RS density indication field in the associated SCI, the MCS level of the associated PSSCH, QoS, and traffic type.

[0227] The DM-RS density may be determined based on a new data indicator (NDI) state, a HARQ process number, or both. For example, for a given HARQ process number, if the NDI bit is toggled from an initial transmission, a first DM-RS density may be used. In an embodiment, the NDI bit may be toggled from 1 to 0, or from 0 to 1. If the NDI bit is not toggled from the initial transmission, a second DM-RS density may be used.

[0228] The DM-RS density may be determined based on HARQ-related parameters, which may include at least one of a redundancy version number, an NDI bit toggle state, and a HARQ process ID.

[0229] According to an embodiment, the DM-RS density for sidelink transmissions, such as PSCCH transmissions, PSSCH transmissions, or both, may be determined based on a resource ID or a resource pool ID. One or more resource pools may be used, and each resource pool may include one or more subchannels. Each subchannel may be associated with a resource ID.

[0230] For each subchannel or resource pool, a DM-RS density may be configured. The WTRU may determine the DM-RS density based on a resource ID, a resource pool ID, or both, which may be associated with the sidelink transmission. The transmitting WTRU may select a subchannel, a resource pool, or both based on the required DM-RS density. For example, the transmitting WTRU may measure, infer, or determine channel conditions, such as Doppler frequency, as well as signal-to-interference ratio and signal-to-noise ratio (SINR), etc. of the sidelink channel between the transmitting WTRU and the receiving WTRU, and may determine the DM-RS density based on the channel conditions. The transmitting WTRU may then select a subchannel, a resource pool, or both based on the determined DM-RS density. The receiving WTRU may monitor a subchannel, a PSCCH, and / or a resource pool, which may be associated with the minimum DM-RS density required to receive the sidelink transmission based on the channel conditions of the sidelink between the transmitting WTRU and the receiving WTRU. As previously mentioned, in an embodiment, the receiving WTRU may be a receiving WTRU, and the transmitting WTRU may be a transmitting WTRU.

[0231] According to an embodiment, the DM-RS density may be indicated in the relevant SCI such that a DM-RS density indication field can exist in the SCI based on the SCI format, sidelink traffic type, QoS, resource ID, and / or resource pool ID. In an embodiment, the sidelink traffic type may be broadcast, groupcast, or unicast. In a further embodiment, the QoS may include priority, reliability, or both. One or more SCI formats may be used, and a DM-RS density indicator field may exist for a subset of the SCI formats. In an embodiment, the SCI format may be an SCI format for unicast traffic.

[0232] Based on the RNTI associated with the SCI, a DM-RS density indication field may be present in the SCI. For example, for a first type of RNTI, such as a unicast RNTI, a DM-RS density indication field may be present, and for a second type of RNTI, such as a broadcast RNTI, a DM-RS density indication may not be present.

[0233] Based on range parameters that can be used to indicate requirements for latency, reliability, and data rate for groupcast transmission, a DM-RS density indication field may be present in the SCI.

[0234] Based on whether HARQ feedback is enabled or disabled, a DM-RS density indication field may be present in the SCI. For example, when HARQ feedback is enabled, a DM-RS density indication field may be present in the associated SCI. In a further embodiment, when HARQ feedback is disabled, a DM-RS density indication field may be present in the associated SCI. Otherwise, a DM-RS density indication field may not be present. In an embodiment, when HARQ feedback is disabled, the DM-RS density may be determined based on the upper layer configuration for the sidelink BWP.

[0235] According to an embodiment, when HARQ feedback or indication for sidelink transmission is enabled, the DM-RS density may be determined based on the redundancy version indication for sidelink transmission. When HARQ feedback or indication to the transmitting WTRU is disabled, the DM-RS density may be indicated in the DM-RS density indication field in the DCI. According to this embodiment, when HARQ feedback is enabled, the DM-RS density field may not be present and / or when HARQ feedback is enabled, the DM-RS density may be determined based on the redundancy version. Otherwise, the DM-RS density is determined based on another mechanism described elsewhere herein. In an embodiment, the other mechanism may include one or more of a DM-RS density indication field, an RNTI, a range parameter, upper layer signaling, and a traffic type, etc.

[0236] According to an embodiment, multiple stage SCIs may be used such that a first SCI can provide decoding information for a second SCI and the second SCI can include scheduling information for the associated PSSCH. The first SCI may include DM-RS density information for the associated PSSCH.

[0237] Although features and elements have been described above in a particular combination, one of ordinary skill in the art will recognize that each feature or element may be used alone or in any combination with other features and elements. Additionally, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electrical signals (transmitted through wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, magnetic media such as read only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, 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 may be used to implement a radio frequency transceiver for use in a TRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method for use in a first wireless transmit / receive unit (WTRU), comprising: receiving configuration information regarding one or more range-specific physical side link control channel (PSCCH) resource pools, each range-specific PSSCH resource pool including one or more PSCCH resources; determining a range between the first WTRU and a second WTRU; determining a range-specific PSSCH resource pool among the one or more range-specific PSSCH resource pools based on the range; determining a PSCCH resource within the determined range-specific PSSCH resource pool; and transmitting control information to the second WTRU on the determined PSCCH resource. A method comprising the above.

2. The method of Claim 1, wherein the one or more PSCCH resources are one or more PSCCH resource units (PRUs).

3. The method of Claim 1, wherein the range is determined based on reception of location information from the second WTRU.

4. The method of Claim 3, wherein the location information is received during a setup procedure with the second WTRU.

5. The method of Claim 3, wherein the range is further based on higher layer configuration parameters received by the first WTRU.

6. The method of Claim 1, wherein the range is based on measurement by the first WTRU of a signal from the second WTRU.

7. The method of Claim 1, wherein the PSSCH resource is determined based on a WTRU identifier (WTRU-ID).

8. The method of Claim 7, wherein the WTRU-ID is one or more of a side link radio network temporary identifier (SL-RNTI), one or more most significant bits (MSB) of the international mobile subscriber identity (IMSI) of the WTRU, one or more least significant bits (LSB) of the IMSI of the WTRU, a cell-RNTI (C-RNTI), a configured scheduling-RNTI (CS-RNTI), a system architecture evolution (SAE) temporary mobile subscriber identifier (s-TMSI), a group ID, a source ID, a transmitter ID, or a groupcast ID.

9. The method of Claim 7, wherein the WTRU-ID is configured by a base station.

10. The method according to claim 9, wherein the configuration information regarding the one or more range-specific PSCH resource pools is received from the base station.

11. A first wireless transmit / receive unit (WTRU) comprising: a transceiver; a processor operably coupled to the transceiver, wherein the transceiver is configured to receive configuration information regarding one or more range-specific physical sidelink control channel (PSCH) resource pools, each range-specific PSSCH resource pool including one or more PSCH resources; wherein the processor is configured to determine a range between the first WTRU and a second WTRU; wherein the processor is configured to determine, based on the range, a range-specific PSCH resource pool among the one or more range-specific PSSCH resource pools; wherein the processor is configured to determine a PSCH resource within the determined range-specific PSCH resource pool; wherein the transceiver and the processor are configured to transmit control information to the second WTRU on the determined PSCH resource. A first WTRU.

12. The first WTRU according to claim 11, wherein the one or more PSCH resources are one or more PSCH resource units (PRUs).

13. The first WTRU according to claim 11, wherein the range is determined based on reception of location information from the second WTRU.

14. The first WTRU according to claim 13, wherein the location information is received during a setup procedure with the second WTRU.

15. The first WTRU according to claim 13, wherein the range is further based on higher layer configuration parameters received by the first WTRU.

16. The first WTRU according to claim 11, wherein the range is based on measurements by the first WTRU of a signal from the second WTRU.

17. The first WTRU according to claim 11, wherein the PSSCH resource is determined based on a WTRU identifier (WTRU-ID).

18. The first WTRU of claim 17, wherein the WTRU-ID is one or more of a sidelink radio network temporary identifier (SL-RNTI), one or more most significant bits (MSBs) of the international mobile subscriber identity (IMSI) of the WTRU, one or more least significant bits (LSBs) of the IMSI of the WTRU, a cell-RNTI (C-RNTI), a configured scheduling-RNTI (CS-RNTI), a system architecture evolution (SAE) temporary mobile subscriber identifier (s-TMSI), a group ID, a source ID, a transmitter ID, or a groupcast ID.

19. The first WTRU of claim 17, wherein the WTRU-ID is configured by a base station.

20. The first WTRU of claim 19, wherein the configuration information regarding the one or more range-specific PSCCH resource pools is received from the base station.

Images