CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. provisional patent application no. 62/716,831 , filed August 9, 2018, which is incorporated herein by reference in its entirety.

BACKGROUND

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

SUMMARY

[0003] Systems, methods, and instrumentalities may be provided associated with v2x

synchronization. Synchronization reference (SyncRef) wireless transmit/receive unit (WTRU) selection implementations may be provided. A WTRU may receive one or more sidelink synchronization signals (SLSSs) (e.g., a first SLSS from a first WTRU and a second SLSS from a second WTRU). The first SLSS may include a first coverage indicator and the second SLSS ay include a second coverage indicator. The first coverage indicator may indicate whether the first WTRU is associated with a platoon. The second coverage indicator may indicate whether the second WTRU is associated with a platoon. An M sequence (e.g., in the SLSS) may include the coverage indicator (e.g., the first coverage indicator and/or the second coverage indicator). For example, a first M sequence may be used to indicate a platoon leader, a second M sequence may be used to indicate a WTRU in-coverage by the platoon leader, and a third M sequence may be used to indicate a WTRU out-of-coverage by the platoon leader. The first SLSS may be a primary sidelink synchronization signal (PSSS), a secondary sidelink synchronization signal (SSSS), or a physical sidelink broadcast channel (PSBCH). [0004] The WTRU may determine, based on the first and second SLSSs, a priority for each of the first and second WTRUs. WTRUs that are in a platoon {e.g., platoon members) may have a higher priority than WTRUs that are not in a platoon (e.g., not platoon members). The WTRU may determine a priority order. For example, the priority order may be pre-defined and/or pre-configured. The priority order may include a first priority assigned to a platoon leader, a second priority assigned to a WTRU in-coverage by the platoon leader, and a third priority assigned to a WTRU out-of-coverage by the platoon leader. The first priority may be higher than the second or third priorities. The second priority may be higher than the third priority.

[0005] The WTRU may select a SyncRef WTRU from the first and second WTRUs. For example, the WTRU may select the SyncRef WTRU according to the priority order. The selected SyncRef WTRU may have a highest priority in the priority order of the first and second WTRUs. The WTRU may synchronize with the selected SyncRef WTRU. The WTRU may be configured to reselect the SyncRef WTRU. The WTRU may reselect the SyncRef WTRU when the WTRU joins another platoon. The WTRU may reselect the SyncRef WTRU when a sidelink reference signal received power (S-RSRP) associated with the selected SyncRef WTRU is less than a S-RSRP associated with a third WTRU. The WTRU may reselect the SyncRef WTRU when a S-RSRP associated with the third WTRU is greater than a threshold and/or the third WTRU has a higher priority (e.g., in the priority order) than the selected SyncRef WTRU.

BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

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

[0010] FIG. 2 shows an example of the communications between the WTRU and eNB for V2X sidelink transmissions;

[0011] FIG. 3 illustrates implementations for enhanced SS/PSBCH block for V2X Sidelink, e.g., for NR;

[0012] FIG. 4 illustrates an exemplary SyncRef WTRU selection;

[0013] FIG. 5 illustrates an exemplary coverage indicator status; [0014] FIG. 6 illustrates exemplary features associated with SyncRef WTRU selection;

[0015] FIG. 7 illustrates exemplary features associated with SyncRef WTRU selection.

[0016] FIG. 8 illustrates exemplary features associated with SyncRef WTRU selection.

[0017] FIG. 9 illustrates an example of PBCH soft combining, e.g., using circularly shifted data;

[0018] FIG. 10 illustrates an example associated with joining a vehicle platoon.

DETAILED DESCRIPTION

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

[0020] As shown in FIG. 1 A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104/113, a ON 106/115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a "station” and/or a "STA”, may be configured to transmit and/or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a UE. [0021] The communications systems 100 may also include a base station 114a and/or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106/115, the Internet 110, and/or the other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a gNB, a NR NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

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

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

[0024] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104/113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115/116/117 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink (DL) Packet Access (HSDPA) and/or High-Speed UL Packet Access (HSUPA). [0025] In an embodiment, the base station 1 14a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A) and/or LTE-Advanced Pro (LTE-A Pro).

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

[0027] In an embodiment, the base station 1 14a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and/or transmissions sent to/from multiple types of base stations {e.g., an eNB and a gNB).

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

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

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

[0031] The CN 106/115 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or the other networks 112. The PSTN 108 may include circuit- switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common

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

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

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

[0034] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (1C), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. 1 B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

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

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

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

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

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

[0041] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and/or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and/or Augmented Reality (VR/AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors, the sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and/or a humidity sensor.

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

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

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

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

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

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

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

102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

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

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

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

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

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

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

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

[0057] Sub 1 GHz modes of operation are supported by 802.11 af and 802.11 ah. The channel operating bandwidths, and carriers, are reduced in 802.11 af and 802.11 ah relative to those used in 802.11 h, and 802.11 ac. 802.11 af supports 5 MHz, 10 MHz and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11 ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11 ah may support Meter Type Control/Machine-Type Communications, such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and/or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

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

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

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

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

[0062] The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the OFDM symbol spacing and/or OFDM subcarrier spacing may vary for different transmissions, different cells, and/or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing varying number of OFDM symbols and/or lasting varying lengths of absolute time). [0063] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and/or a non-standalone configuration. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration WTRUs 102a, 102b, 102c may communicate with/connect to gNBs 180a, 180b, 180c while also communicating with/connecting to another RAN such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In the non-standalone configuration, eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and/or throughput for servicing WTRUs 102a, 102b, 102c.

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

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

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

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

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

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

[0070] In view of Figures 1 A-1 D, and the corresponding description of Figures 1 A-1 D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b,

DN 185a-b, and/or any other device(s) described herein, may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and/or to simulate network and/or WTRU functions.

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

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

[0073] As the carrier frequency increases, the severe path loss may become a limitation, e.g., to guarantee a sufficient coverage area. Transmission in millimetre wave systems may suffer from non-line-of- sight losses, e.g., diffraction loss, penetration loss, oxygen absorption loss, foliage loss, etc. During initial access, the base station and WTRU may need to overcome these high path losses and discover each other. Utilizing dozens or even hundreds of antenna elements to generated beam formed signal may be an effective way to compensate for the severe path loss, e.g., by providing significant beam forming gain. Beamforming techniques may include digital, analogue, and/or hybrid beamforming.

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

Table 1

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

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

[0077] In examples (e.g., LTE), when a UE is camped on a cell, it may receive SIB21 , which may include a V2X sidelink communication configuration. The SIB21 may include the IE of

SL-V2X-ConfigCommon with components of one or more of the following: v2x-CommRxPool, v2x-CommTxPoolNormalCommon, v2-CommTxPoolExceptional, v2x-lnterFreqlnfoList, etc.

v2x-lnterFreqlnfoList may be a list of up to 7 neighboring frequencies for V2X sidelink communication.

[0078] The vehicle WTRU may inform the eNB that it is (not) interested to receive V2X sidelink communication or to request assignment or release of transmission resources for V2X sidelink communication. The WTRU and eNB may exchange messages for RRCConnectionReconfiguration, which may include the IE of SL-V2X-ConfigDedicated with components of one or more of: commTxResources, v2x-lnterFreqlnfoList, etc.

[0079] FIG. 2 shows an example of the communications between the WTRU and eNB for V2X sidelink transmissions.

[0080] In NR V2X, Uu-based sidelink resource allocation/reconfiguration may be used to identify enhancements of LTE Uu and NR Uu, e.g., to control NR sidelink from the cellular network, and to identify enhancements of NR Uu, e.g., to control LTE sidelink from the cellular network. [0081] When a WTRU is connected to the eNB, it may have the cell timing. If the WTRU is not in coverage of the eNB, it may use GNSS for the timing synchronization. If the WTRU cannot find timing from either, it may rely on sidelink WTRUs for timing information. GNSS satellites have atomic oscillators providing a stable and accurate time reference. A GNSS receiver may track signals from multiple satellites and retrieve a local time reference with absolute error less than 1us for Global Positioning System (GPS) receivers. For coordinated multi-point transmission proved that the residual error using GPS can be even around 10ns. GNSS may be also used for frequency synchronization, e.g., by phase-locking the local oscillator to the incoming signal and stabilizing the carrier frequency. As modern vehicles may be equipped with a GNSS receiver, such implementation may be considered.

[0082] If Synchronization is received from SLSS from other sidelink users, the WTRU may use PSSS/SSSS, which may be a part of the Sidelink SS to obtain timing information. Synch-Threshold may be received in RRC (e.g., v2x-SyncConfig and SL-V2X-Preconfiguration). Sidelink Synchronization Signals may be one or more of the following signals: the Primary Sidelink Synchronization Signal (PSSS), the Secondary Sidelink Synchronization Signal (SSSS), Physical Sidelink Broadcast channel (PS-BCH) or demodulation reference symbols (DMRS) for demodulating the PSBCH. PSSS and SSSS may be transmitted in adjacent time slots in the same subframe. Sidelink-ID (SID) may be split into two sets. SIDs in the range of {0, 1 , ...,167) may be reserved for‘in-coverage’ WTRUs and SIDs in the range of {168, 169, ... ,335} may be used for‘out-of-coverage’ WTRUs. The subframes used as radio resources to transmit SLSS and PBSCH may be configured by higher layers.

[0083] NR V2X requirements may be different from LTE V2X. To support higher bandwidth, reliability, and/or higher density of vehicles and users for NR V2X services, existing LTE SLSS may not be sufficient. The capacity of the sidelink may need to be enhanced. LTE V2X may not be a beam-centric design.

Modification or enhancement for the side-link synchronization signals may be needed for NR V2X. Different handling for the synchronization timing reference, coverage and/or platoon operation may be needed, e.g., due to NR use cases. Modification to NR Synchronization may be required in order to apply NR synchronization for NR V2X.

[0084] Transmission implementations associated with the sidelink synchronization signals may need to be defined. In LTE V2X there may be three sources defined for synchronization reference:

G N S S(d i rect/i n d i rect) , LTE-eNB (direct/indirect), and remaining WTRUs. This may not cover the cases where the WTRU is in coverage of NR gNB but does not have GNSS and/or LTE-eNB coverage.

Implementations may be required for WTRUs to select SyncRef. In-Coverage and Out-Of-Coverage implementations may be defined. If time information of SFN, slot (or sub-frame) is included in PSBCH, the soft combining at the receiver may not be straightforward. Transmitted signal may be modified to support soft combining.

[0085] Vehicle platooning may be a use case for NR V2X. Synchronization or access implementations to join a platoon or leave a platoon may need to established and corresponding signaling.

[0086] Implementations associated with transmission of sidelink synchronization signals may be provided. This may include SL-SS block transmission and/or SL-SS/PSBCH block transmission.

[0087] SL-SS Block Transmission may be provided. Sidelink-synchronization signal block (SL-SSB) may be used for sidelink synchronization and may be transmitted, e.g., as described herein. The SL-SSB may be transmitted depending on a measurement e.g. , RSRP measurement. SL-SSB transmission parameters e.g. , periodicity, duration, etc., may be configured or may be dependent on the vehicle or WTRU measurements. Association for SL-SSB transmission and an SL-SSB transmission threshold may be used. Mlti-level thresholds triggered SL-SSB transmission may be considered. For example, multi-level thresholds may be used to trigger the SL-SSB transmission. SL-SSB transmission periodicity and/or duration may be associated with SL-SSB transmission thresholds. RSRP may be used for measurement. Different SL-SSB transmission parameters may be associated with different SL-SSB transmission thresholds. Different SL-SSB periodicity/duration may be associated with different RSRP thresholds. For example, SL-SSB periodicity/duration A may be associated with RSRP threshold 1 , SL-SSB

periodicity/duration B may be associated with RSRP threshold 2, and so on. A WTRU may perform the measurement, e.g., using RSRP. If RSRP is greater than one threshold, then the WTRU may be triggered to transmit SL-SSB, e.g., using a transmission periodicity A1 and/or duration A2. If RSRP is greater than another threshold, then the WTRU may be triggered to transmit SL-SSB using a transmission periodicity B1 and/or duration B2, and so on. SL-SSB transmission periodicity and/or duration may be a function of measurement threshold {e.g., RSRP threshold), measurement (e.g., RSRP measurement) or the like. SL- SSB transmission other than periodicity and/or duration (e.g., offset, window size, etc) may be dependent on, associated with, or as a function of measurement or measurement threshold such as RSRP or RSRP threshold(s). RSRP threshold(s) may be configured in RRC, RMSI, OSI or indicated in L1/2 control signalling.

[0088] In examples, on-demand SL-SSB transmission may be used. The vehicle or WTRU may request SL-SSB transmission based on needs. The vehicle or WTRU may request SL-SSB transmission, e.g., with different SL-SSB periodicities, duration, types, offset, and so on. If the vehicle or WTRU requests SL-SSB transmission, the vehicle or WTRU may send a request via a control channel or random access channel, e.g., PSCCH, RACH message 1 , preamble, or the like. PSCCH may carry an explicit SL-SSB transmission indication, which may indicate different SL-SSB transmission periodicities, duration, types, offset, and so on. PSCCH may be partitioned into different groups. Each PSCCH group may implicitly indicate different SL-SSB transmission periodicities, duration, types, offset, and so on. A different PSCCH group or partition may be associated with different SL-SSB transmission such as periodicities, duration, types, offset, and so on. Combination of an explicit SL-SSB transmission indication and PSCCH group partition may be used to indicate different SL-SSB transmission periodicities, duration, types, offset, and so on. RACH message 1 or preamble may be partitioned into different groups and each RACH message 1 or preamble group may implicitly indicate different SL-SSB transmission periodicities, duration, types, offset, and so on. A different RACH message 1 partition or preamble group or partition may be associated with different SL-SSB transmission such as periodicities, duration, types, offset, and so on. An explicit SL-SSB transmission indication may be included in the first step of a 2-step RACH or the third step {e.g., RACH message 3) of a 4-step RACH.

[0089] SL-SSB may be in the form of SS block (SSB) and SSB group (SSBG). If number of SSBs is less than a threshold, SL-SSB may be in the form of SS block (SSB) (e.g., only in the form of SS block (SSB)). An indication for SSB and/or SSBG may be provided. Sidelink remaining minimum system information (SL-RMSI) or sidelink other system information (SL-OSI) may be provided to indicate the actually transmitted SSBs and/or SSBGs. An indication using bitmap and/or group bitmap may be employed. Indication for actually transmitted SSB and/or SSBG may be carried in SL-SSB or PSBCH.

[0090] SL-RMSI or SL-OSI may be used to indicate the bandwidth part (BWP) information. For example, SL-RMSI or SL-OSI may indicate which BWP(s) may be used for SL-SSB transmission. The WTRU may select (e.g., randomly) which BWP(s) among the configured BWPs may be used for SL-SSB transmission. Bandwidth part (BWP) information may be indicated in SL-SSB or PSBCH. SL-RMSI, SL- OSI, SLSS and/or PSBCH may be used to indicate the carrier aggregation (CA) information. For example, SL-RMSI or SL-OSI may be used to indicate which component carrier (CC(s)) may be used for SL-SSB transmission. The WTRU may select (e.g., randomly) which CC(s) among the configured CCs may be used for SL-SSB transmission.

[0091] Different SL-SSBs may be used. One SL-SSB type may include PSSS, SSSS and/or PSBCH while another SL-SSB type may include PSSS and SSSS, e.g., without PSBCH. Different types of SL-SSB may be configured or indicated for transmission. Different types of SL-SSB may be triggered for transmission. For example, different types of SL-SSBs may be triggered based on measurement threshold e.g., RSRP threshold for transmission. Different types of SL-SSB may be requested by the vehicle or WTRU for transmission.

[0092] SL-SS/PSBCH block transmission may be provided. NR SS/PBCH block implementation may be robust and may support single shot detection of PSS/SSS and PBCH, e.g., at -6dB receive SNR. The outdoor environment for V2X may make it more challenging to achieve similar performance. Vehicle blockage effect may degrade the received signal strength. SS/PSBCH block may be used for enhanced V2X Sidelink. A long format for SS/PSBCH block may be introduced for NR V2X. Two long formats may be considered: a long sequence based long format e.g., longer than NR (L = 127) sequence and a repetition based long format e.g., repetition of short sequence. Use of SS/PSBCH long format may improve performance of detection for SS/PSBCH block such as detection of PSSS and SSSS. It may reduce the coding rate of PSBCH, which may result in improved detection performance.

[0093] FIG. 3 illustrates implementations for enhanced SS/PSBCH block examples 300 for V2X Sidelink, e.g., for NR.‘A’ may occupy 20 PRB, where 127 length PSSS and 127 length SSSS may occupy 12 PRB and PSBCH may occupy 48 PRBs wrapped around the SSS. For‘B', length 255 for PSSS (or higher SCS with length 127 sequence) may be used, which may occupy 24 PRBs. SSSS implementation may be similar to‘A.’ PSBCH may occupy more 48 RBs in two symbol and 8 or more {e.g. up to 16 PRB) in the symbol of SSSS. In‘C,’ there may be increased PRB allocation for PSSS and SSSS, which both may have length 255 sequence (or higher SCS with length 127sequence), and PSBCH may occupy 48 PRB. In ¹ D,' repetition based 20 PRB implementation may be used. 12 PRB PSSS and SSSS may be repeated in two OFDM symbols. PSBCH may be wrapped around SSSS, which may occupy 48RBs in 2 symbols and 16RBs in the SSSS symbol.

[0094] These SS/PSBCH block may be used for beam-centric systems, e.g., to support beam sweeping, and transmitted as a synchronization burst in the same, different, or all directions. PSBCH in each SS/PSBCH block may include its own SFN and slot timing information (e.g., implicitly or explicitly). PSSS and SSSS implementations, e.g., to increase the capacity of Sidelink for NR, may be provided below.

[0095] SyncRef WTRU selection implementations may be provided. A priority-based SyncRef WTRU selection may be used. For example, a WTRU may select a SyncRef WTRU based on a priority (e.g., a priority order). The selected SyncRef WTRU may have a highest priority (e.g., in the priority order) of a plurality of potential WTRUs. A joint priority and measurement based SyncRef selection may be used, e.g., for SyncRef selection or SyncRef WTRU selection. A joint priority-measurement-coexistence based SyncRef selection or SyncRef WTRU selection may be used. In LTE-V2X systems, three different sources may be used as SyncRef: GNSS(direct/indirect), LTE-eNB (direct/indirect), and remaining WTRU. In NR, there may be more synch sources. For example, a NR-gNB, a platoon leader, and the WTRUs in coverage of those (e.g., indirect source for platoon) may be selected as a SyncRef WTRU.

[0096] Different priorities may be considered for SyncRef selection. A priority order may include the different priorities. As an example, for synchronization or SyncRef selection, platoon leader may have higher priority than other members of platoon. Members of platoon may have higher priority than other WTRUs who are not part of platoon. The priority order may include a plurality of priorities {e.g., a first priority, a second priority, a third priority, etc.). For example, the first priority may be assigned to a platoon leader, the second priority may be assigned to a WTRU in coverage by the platoon leader, and a third priority may be assigned to a WTRU out of coverage by the platoon leader. The first priority may be higher (e.g., in the priority order) than the second or third priorities. The second priority may be higher (e.g., in the priority order) than the third priority. SyncRef selection may be based on one or more priority rules, for example, in NR V2X.

[0097] There may be a priority level PO, e.g., a priority for cellular coverage. The priority level PO may include various conditions of a WTRU in cellular coverage e.g. InCoverage-LTE, InCoverage-NR, or both. InCoverage for LTE may imply that a RSRP (e.g., for the DMRS for PBCH) in LTE are above a configured threshold for LTE (e.g., syncTxThreshIC, in SIB-21 if LTE Uu) for this purpose. A threshold (e.g., such as syncTxThreshIC-NR) may be configured and/or indicated for NR (e.g., in RMSI, OSI or RRC). This threshold may be selected based on implementations associated with SLSS for NR.

[0098] SyncRef selection may be based on received power of SSB and a predefined or configured threshold. For example, a WTRU may select a SyncRef WTRU based on a SSB-power when the received power of SSB exceeds the configured threshold. SyncRef selection may be based on a DMRS power. For example, a WTRU may select a SyncRef WTRU based on a DMRS power. SyncRef selection may be based on a combination of a SSB power and a DMRS power. For example, a WTRU may select a SyncRef WTRU based on a combination of a SSB power and a DMRS power. SyncRef selection may be based on joint SSB-DMRS power measurement and threshold. For example, a WTRU may select a SyncRef WTRU based on a level of RSRP (Reference Signal Received power). For example, a WTRU with a higher RSRP as measured between WTRUs or between gNB/eNB and WTRU (e.g., normalized for reference power) may be selected as a SyncRef or SyncRef WTRU.

[0099] Implementations may be based on an LTE-threshold and a NR-threshold. The LTE-threshold and NR-threshold may be the same or different. Priority may be assigned or predetermined between LTE and NR. For example, LTE may be assigned or predetermined with higher priority than NR. Stated differently, an LTE WTRU may be assigned a first priority and a NR WTRU may be assigned a second priority. In examples, the first priority may be higher in a priority order than the second priority. In the case when the WTRU is in coverage of a LTE-eNB and a NR-gNB, the LTE-eNB may be selected as the source, e.g., as long as RSRP is above a certain threshold. In this case, SyncRef selection may be based on priority assigned to LTE and NR, and in examples may not depend purely on the best RSRP. For example, LTE-V2X may include one or more basic safety messages. The one or more LTE-V2X basic safety messages may have a higher priority than other messages in NR. An LTE WTRU may be assigned a higher priority than a NR WTRU, for example, based on the priorities of the messages. If RSRP is within a certain range, LTE may be selected. For example, an LTE eNB may be selected as a source if RSRP is within a predefined range. If RSRP is out of the range, NR may be selected. For example, a NR gNB may be selected as a source if RSRP is out of a predefined range. If the difference of RSRP between LTE and NR is within a certain range, LTE may be selected. If the difference of RSRP between LTE and NR is not within a certain range, NR may be selected. Implementations may be based on in coverage status. If the WTRU is in coverage of LTE-eNB and not in coverage of NR-gNB or if the WTRU is in coverage of NR- gNB and not in coverage of LTE-eNB (or NR-SA), the in-coverage cellular source may have higher or highest priority. For example, an in-coverage WTRU may have a higher priority than a not-in-coverage WTRU.

[0100] In the use case of platooning, the same rules may or may not apply. A platoon leader may have a higher priority than a cellular WTRU. For example, a platoon leader may have the highest priority and may be selected as SyncRef WTRU. An RRC configuration or system information {e.g., RMSI, OSI) update may be used to set these priorities. In examples, for other cases, if the WTRU does not detect a LTE-eNB or a NR-gNB on frequencies (pre-)configured, e.g., by RRC, which may potentially include LTE- eNB or NR -gNB used as sync reference, one or more of the following priority rules may be used: P1 : GNSS; P2: the following WTRUs may be considered at the same / similar priority: WTRUs directly synchronized to GNSS and WTRUs synchronized (e.g., directly) to LTE-eNB or NR-gNB; P3: the following WTRUs may be considered at the same/ similar priority: WTRUs indirectly synchronized to GNSS and WTRUs indirectly synchronized to LTE-eNB or NR-gNB; P4: The remaining WTRUs (e.g., without known SyncRef); P5: WTRU synchronized (e.g., directly) to (and may obtain its timing reference from) Platoon Leader; P6: WTRU indirectly synchronized to (and may obtain its timing reference from Platoon Leader.

The priority order between P1 , P2, P5, P6 may be (pre-)configured or indicated. For example, in a platooning case a priority order of P5>P6>P1 >P2 may be considered/used.

[0101] For selection of SyncRef WTRU, one or more of the following may be used by a WTRU. If a WTRU is synchronized with SLSS of a platoon, the WTRU may select a SyncRef WTRU according to a first priority order. If a WTRU is not trying to synchronize with a platoon and it is not in coverage for a NR-gNB or a LTE-eNB the WTRU may determine a second priority order.

[0102] If a WTRU is synchronized with SLSS of platoon, the WTRU may select a SyncRef WTRU according to a priority order. The priority order may include two or more priorities (e.g., priority groups). A first priority group, Group 0a may be assigned if the S-RSRP coming from the platoon leader (e.g., S- RSRP-PL) is higher than a threshold (e.g., PlatoonSelTh) WTRU received in MIB-SL or RMSI or OSI (e.g., over Uu interface). When Group Oa is assigned, a WTRU may select the platoon leader as SyncRef WTRU. The WTRU may indicate that SyncRef is "direct” when transmitting SLSS. A second priority group, Group Ob may be assigned if S-RSRP of the platoon leader is lower than a threshold, but another SLSS from another platoon follower (S-RSRP-PF) is higher than threshold. When Group Ob is assigned, a WTRU may select an indirect SLSS leader as SyncRef WTRU. The WTRU may indicate that SyncRef is "indirect” when transmitting SLSS. S-RSRP may be based on DMRS for PSBCH and/or SSSS (and/or PSSS).

[0103] A WTRU may check {e.g., first check) the priority configuration for P1/P2, for example, if the WTRU is not trying to synchronize with a platoon and it is not in coverage for NR-gNB or LTE-eNB. If Priority for P1 (e.g., GNSS) is higher (e.g., assuming WTRU is capable), the WTRU may synchronize and obtain direct frame number (DFN), e.g., using GNSS. If the Priority for P2 is higher, the WTRU may search for (e.g., try to find) SLSS from Group 1 (e.g., as described herein) before the GNSS. Among the SLSS(s) exceeding the threshold (e.g., selectionTh) configured, WTRU may select a SyncRef WTRU according to following priority order. The priority order may include a plurality of priorities (e.g., Group 1 , Group 2, and/or Group 3). Group 1 may include one or more WTRUs of which inCoverage, included in the MIB-SL received from the one or more WTRUs, is set to TRUE (e.g., starting with the WTRU with the highest S- RSRP result) In Group 1 , NR or LTE inCoverage priority may be ordered as configured, or NR and LTE may have equal priority and may be selected based on S-RSRP. Group 2 may include one or more WTRUs whose SLI is part of the set defined for in coverage (e.g., starting with the WTRU with the highest S-RSRP measurement) In Group 2, NR or LTE SLSS priority may be configured, or NR and LTE may have equal priority and may be selected based on S-RSRP. Group 3 may include one or more other WTRUs (e.g., starting with the WTRU with the highest S-RSRP measurement). S-RSRP may be based on DMRS for PSBCH and/or PSSS/SSSS.

[0104] FIG. 4 illustrates an exemplary SyncRef WTRU selection 400. For different synchronization sources, different thresholds may be used, which may depend on the synchronization signal type/solution and context of usage.

[0105] At 402, a WTRU may determine to join (e.g., look to join) a platoon. At 404, the WTRU may receive an SLSS from a platoon leader and a RSRP from the platoon leader (e.g., S-RSRP-PL) may be greater than a predefined threshold (e.g., platoonSelTh). At 406, the WTRU may select the platoon leader as SyncRef WTRU and/or the WTRU may indicate that the WTRU receives SyncRef from the platoon leader. For example, the WTRU may select the platoon leader as SyncRef WTRU based on the RSRP.

[0106] At 408, the WTRU may receive an SLSS from a platoon follower and a RSRP from the platoon follower (e.g., S-RSRP-PF) may be greater than a predefined threshold (e.g., platoonSelTh). At 410, the WTRU may select the platoon follower as SyncRef WTRU and/or the WTRU may indicate that the WTRU receives SyncRef from the platoon follower. For example, the WTRU may select the platoon follower as SyncRef WTRU based on the RSRP.

[0107] If a WTRU is not looking to join a platoon, the WTRU may determine, at 412, whether the WTRU has coverage from an eNB and/or a gNB. If the WTRU has coverage from eNB and/or gNB, the WTRU may prioritize, at 414, eNB over gNB and/or determine whether RSRP is greater than a predefined, indicated, and/or configured threshold {e.g., syncTxThreshIC). If RSRP is greater than the predefined, indicated, and/or configured threshold, the WTRU may select, at 416, the LTE-eNB as SyncRef, for example, according to priority and/or RSRP. The WTRU may indicate a SyncRef or SyncRef WTRU in SLSS. If RSRP is not greater than the predefined, indicated, and/or configured threshold, the WTRU may determine, at 418, whether an eNB RSRP is greater than a gNB RSRP (e.g., normalized). If the eNB RSRP is greater than the gNB RSRP, the WTRU may select, at 416 the LTE-eNB. If the eNB RSRP is not greater than the gNB RSRP, the WTRU may select, at 420, the NR gNB as SyncRef, for example, according to priority order and/or the RSRPs.

[0108] Similarly, a WTRU may prioritize a gNB over an eNB and one or more of the methods described herein may be used. A WTRU may prioritize gNB/eNB over a global navigation satellite system (GNSS), for example, based on an indication and/or a configuration for priority of sync sources. A WTRU may determine whether RSRP is greater than a predefined, indicated, and/or a configured threshold. If RSRP is greater than the predefined, indicated, and/or configured threshold, the WTRU may select gNB/eNB as SyncRef, for example, according to priority and/or RSRP. The WTRU may indicate a SyncRef or SyncRef WTRU in SLSS. If RSRP is not greater than the predefined, indicated, and/or configured threshold, the WTRU may determine whether a GNSS RSRP is greater than a predefined, indicated, and/or configured threshold. If the GNSS RSRP is greater than the a predefined, indicated, and/or configured threshold, the WTRU may select the GNSS as a SyncRef. If the GNSS RSRP is not greater than the predefined, indicated, and/or configured threshold, the WTRU may select another WTRU that is not covered by gNB/eNB and GNSS as a SyncRef WTRU, for example, according to priority order and/or the RSRPs.

[0109] A WTRU may determine whether a gNB/eNB RSRP is greater than a predefined, indicated, and/or configured threshold. If the gNB/eNB RSRP is greater than the predefined, indicated, and/or configured threshold, the WTRU may select the gNB/eNB as SyncRef, for example, according to priority and/or RSRP. If the gNB/eNB RSRP is not greater than the predefined, indicated, and/or configured threshold, the WTRU may determine whether RSRP of an WTRU that is directly covered by a gNB/eNB is greater than a predefined, indicated, and/or configured threshold. If the RSRP is greater than the predefined, indicated, and/or configured threshold, the WTRU may select the WTRU that is directly covered by a gNB/eNB as a SyncRef. If the RSRP is not greater than the predefined, indicated, and/or configured threshold, the WTRU may select another WTRU that is not directly covered by a gNB/eNB as a SyncRef, for example, if the RSRP of the other WTRU is greater than the predefined, indicated, and/or configured threshold. If the RSRP of the other WTRU is not greater than the predefined, indicated, and/or configured threshold, the WTRU may determine whether a GNSS RSRP is greater than a predefined, indicated, and/or configured threshold. If the GNSS RSRP is greater than the predefined, indicated, and/or configured threshold, the WTRU may select the GNSS as SyncRef, for example, according to priority and/or RSRP. If the GNSS RSRP is not greater than the predefined, indicated, and/or configured threshold, the WTRU may determine whether an RSRP of a WTRU that is directly covered by a GNSS is greater than a predefined, indicated, and/or configured threshold. If the RSRP is greater than a predefined, indicated, and/or configured threshold, the WTRU may select the WTRU that is directly covered by the GNSS as a SyncRef. If the RSRP is not greater than the predefined, indicated, and/or configured threshold, the WTRU may select another WTRU that is not directly covered by the GNSS as a SyncRef, for example, if the RSRP of the other WTRU is greater than the predefined, indicated, and/or configured threshold. If the RSRP is not greater than the predefined, indicated, and/or configured threshold, the WTRU may select another WTRU that is not covered by gNB/eNB or GNSS as SyncRef WTRU, for example, according to priority order and/or the RSRPs. If a WTRU does not have coverage from an eNB and/or gNB, the WTRU may determine, at 422, whether GNSS is available. If GNSS is available, the WTRU may select, at 424, GNSS as SyncRef. The WTRU may indicate that GNSS has been selected as SyncRef. If GNSS is not available, the WTRU may find, at 426, a SLSS. The WTRU may determine, at 428, whether the SLSS is in coverage and/or whether S-RSRP is greater than a predefined threshold {e.g., selectionTh). At 430, the WTRU may select a SLSS with the highest RSRP as SyncRef, for example, if the SLSS is in coverage and/or the S-RSRP is greater than the predefined threshold. The WTRU may determine, at 432, whether the SLSS is in coverage and/or whether S-RSRP is greater than a predefined threshold (e.g., selectionTh). At 434, the WTRU may select a SLSS with the highest RSRP as SyncRef, for example, if the SLSS is in coverage and/or the S-RSRP is greater than the predefined threshold.

[0110] If the SLSS is from another (e.g., any other) WTRU, the WTRU may determine at 436, whether S-RSRP is greater than a predefined threshold (e.g., selectionTh). At 438, if the S-RSRP is greater than the predefined threshold, the WTRU may select SLSS, from one of the other WTRUs, with the highest RSRP as SyncRef. The WTRU may indicate an indirect SyncRef WTRU.

[0111] A WTRU may reselect its SyncRef WTRU using the SyncRef WTRU selection 400. For Reselection of SyncRef: the WTRU may reselect its SyncRef WTRU according to the above, e.g., if one or more of the following conditions occur; if WTRU wants to join a platoon; if the S-RSRP of the SLSS of the current SyncRef WTRU plus reselectionThresholdl is less than the S-RSRP of the strongest candidate SyncRef WTRU and the candidate SyncRef WTRU belongs to the same group as the current SyncRef WTRU (NR or LTE); if the S-RSRP of the SLSS of the candidate SyncRef WTRU exceeds the reselectionThreshold2 and the candidate SyncRef WTRU belongs to a group of higher priority than the current SyncRef WTRU (in examples, a timer may be used to periodically check of SLSS from higher priority SyncRef UE is available. Value for this timer may be configured by RRC/System information); if the S-RSRP of the SLSS of the current SyncRef WTRU is less than the minimumThreshold.

[0112] Multiple thresholds may be used, for example, to select a SyncRef WTRU. The multiple thresholds may include platoonSelectionThreshold, selectionThreshold, minimumThreshold,

reselectionThresholdl , and/or reselectionThreshold2. The multiple thresholds may be configured in or derived from System information {e.g., such as MIB-SL).

[0113] Implementations for SyncRef WTRU selection for vehicle platoon may be provided. A WTRU in a platoon may select a SyncRef WTRU. The WTRU may search for one or more SLSSs. The WTRU may receive one or more SLSSs (e.g., a first SLSS from a first WTRU and a second SLSS from a second WTRU). The first SLSS may include a first coverage indicator and the second SLSS ay include a second coverage indicator. The first coverage indicator may indicate whether the first WTRU is associated with a platoon. The second coverage indicator may indicate whether the second WTRU is associated with a platoon. An M sequence (e.g., in the SLSS) may include the coverage indicator (e.g., the first coverage indicator and/or the second coverage indicator). For example, a first M sequence may be used to indicate a platoon leader, a second M sequence may be used to indicate a WTRU in-coverage by the platoon leader, and a third M sequence may be used to indicate a WTRU out-of-coverage by the platoon leader. The first SLSS may be a PSSS, a SSSS, or a PSBCH.

[0114] The WTRU may determine, based on the first and second SLSSs, a priority for each of the first and second WTRUs. WTRUs that are in a platoon (e.g., platoon members) may have a higher priority than WTRUs that are not in a platoon (e.g., not platoon members). The WTRU may determine a priority order. For example, the priority order may be pre-defined and/or pre-configured. The priority order may include a first priority assigned to a platoon leader, a second priority assigned to a WTRU in-coverage by the platoon leader, and a third priority assigned to a WTRU out-of-coverage by the platoon leader. The first priority may be higher than the second or third priorities. The second priority may be higher than the third priority.

[0115] The WTRU may select a SyncRef WTRU from the first and second WTRUs. For example, the WTRU may select the SyncRef WTRU according to the priority order. The selected SyncRef WTRU may have a highest priority in the priority order of the first and second WTRUs. The WTRU may synchronize with the selected SyncRef WTRU. The WTRU may be configured to reselect the SyncRef WTRU. The WTRU may reselect the SyncRef WTRU when the WTRU joins another platoon. The WTRU may reselect the SyncRef WTRU when a sidelink reference signal received power (S-RSRP) associated with the selected SyncRef WTRU is less than a S-RSRP associated with a third WTRU. The WTRU may reselect the SyncRef WTRU when a S-RSRP associated with the third WTRU is greater than a threshold and/or the third WTRU has a higher priority {e.g., in the priority order) than the selected SyncRef WTRU.

[0116] In examples, a Priority of Network (e.g., gNB) may be higher than Platoon for SyncRef Selection. One or more of the following may be performed, e.g., in such a case. A WTRU may search for a cell (e.g., a strong cell). A strong cell may be a cell with a RSRP above a pre-defined threshold. If the WTRU finds a strong cell, the WTRU may synchronize with the strong cell and may set a device

InCoverage Indicator = TRUE, e.g., for any SLSS transmission. The network may be able to control further platoon operations (e.g., any further platoon operations). If the WTRU does not find a strong cell and wants to join a platoon one or more of the following may apply: the WTRU may search for SLSSs till it finds a SLSS with Platoon indicator = TRUE; if a SLSS is found, the WTRU may verify the type of SLSS (e.g., if platoon-type is used); if type of the platoon is acceptable one or more of the following may apply: the WTRU may use the found SLSS as a SyncRef WTRU, the WTRU may identify a leader Indicator and if the Leader indicator = true, the WTRU may be in coverage of Platoon leader, or, if the leader indicator = false, the WTRU may not be in-coverage of platoon leader, but the WTRU may be in-coverage of a platoon follower; or, if the WTRU does not want to join a platoon, the WTRU may follow an implementation (e.g., similar to LTE) which may involve, GNSS, SLSS from in coverage / out of coverage devices, and/or other WTRUs.

[0117] FIG. 6 illustrates exemplary features associated with an example SyncRef WTRU selection 500. A WTRU may find, at 502, a cell (e.g., a strong cell as defined herein). The WTRU may be in coverage of an eNB and/or a gNB. The strong cell may be in coverage. The WTRU may determine to synchronize with the strong cell. For example, the WTRU may select the strong cell as the SyncRef WTRU. The WTRU may set an in-coverage indicator to true. The WTRU may determine, at 504, whether to join a platoon. If the WTRU determines to join a platoon, the WTRU may receive, at 506, an SLSS (e.g., a strong SLSS). A strong SLSS may be an SLSS with a RSRP above a pre-defined, indicated, and/or configured threshold. For example, strong SLSS may be received from a strong cell. The strong SLSS may include a coverage indicator (e.g., a platoon indicator that is set to true). For example, the coverage indicator may indicate whether a WTRU is associated with a platoon. An M sequence (e.g., in the SLSS) may include the coverage indicator. For example, a first M sequence may be used to indicate a platoon leader, a second M sequence may be used to indicate a WTRU in-coverage by the platoon leader, and a third M sequence may be used to indicate a WTRU out-of-coverage by the platoon leader. At 508, the WTRU may determine a platoon type associated with the strong SLSS. For example, the WTRU may determine if the platoon type is the same as the type that the WTRU wants to join. If the platoon type is the type that the WTRU wants to join, the WTRU may determine, at 510, if the platoon has a leader {e.g., platoon leader-indicator set to true). At 510, the leader-indicator may be set to true and the strong SLSS may be in-coverage of the platoon leader. The WTRU may use the strong SLSS as SyncRef WTRU (e.g., platoon-controlled). If the platoon type is not the type that the WTRU wants to join, the WTRU may search again and/or use the next received SLSS. At 512, the leader-indicator may be set to false and the strong SLSS may be out-of-coverage of the platoon leader. The WTRU may use the strong SLSS as SyncRef WTRU (e.g., platoon-controlled).

[0118] If the WTRU does not want to join a platoon, the WTRU may find, at 514, an SLSS from an in coverage device(s). The WTRU that does not want to join a platoon may be out of coverage of an eNB and/or a gNB. When the WTRU finds an SLSS from an in-coverage device, the WTRU may select the SLSS as SyncRef WTRU and/or the WTRU may set in-coverage indicator to false. When the WTRU does not find an SLSS from an in-coverage device, the WTRU may find, at 516, an SLSS from an out-of- coverage device with an in-coverage SyncRef WTRU. When the WTRU finds an SLSS from an out-of- coverage device with an in-coverage SyncRef WTRU, the WTRU may select the SLSS as SyncRef WTRU and/or the WTRU may set in-coverage indicator to false. When the WTRU does not find an SLSS from an out-of-coverage device, the WTRU may find, at 518, any SLSS. When the WTRU finds the any SLSS from, the WTRU may select this SLSS as SyncRef WTRU and/or the WTRU may set in-coverage indicator to true. When the WTRU does not find any SLSS, the WTRU may not select a SyncRef WTRU.

[0119] In implementations, the priority of a platoon may be higher than the network for SyncRef WTRU selection. In this case, one or more of the following may be used. A WTRU may search for SLSSs until it finds an SLSS with a Platoon indicator = TRUE. If SLSS is found, the WTRU may verify the type of SLSS (e.g., if platoon-type is used). If type of the platoon is acceptable, one or more of the following may apply: the WTRU may use found SLSS as SyncRef WTRU, the WTRU may determine the leader Indicator and if the Leader indicator = TRUE, the WTRU may be in-coverage of a Platoon leader, or, if the leader indicator = FALSE, the WTRU may not be in-coverage of a platoon leader, but the WTRU may be in coverage of a platoon follower; or, if the WTRU does not find a platoon, the WTRU may follow one or more implementations (e.g., similar to LTE) which may involve, GNSS, SLSS from in coverage / out of coverage devices, and/or other WTRUs.

[0120] FIG. 7 illustrates exemplary features associated with an example SyncRef WTRU selection 600. At 602, a WTRU may receive a strong SLSS. The strong SLSS may include coverage indicator (e.g., a platoon indicator set to true). For example, the coverage indicator may indicate whether a WTRU is associated with a platoon. An M sequence {e.g., in the SLSS) may include the coverage indicator. For example, a first M sequence may be used to indicate a platoon leader, a second M sequence may be used to indicate a WTRU in-coverage by the platoon leader, and a third M sequence may be used to indicate a WTRU out-of-coverage by the platoon leader. The WTRU may determine, at 604, whether the platoon type of the strong SLSS is the same as the type that the WTRU wants to join. If the platoon type is the same, the WTRU may determine, at 606, whether the platoon has a leader-indicator set to true. If the platoon has a leader-indicator set to true, the WTRU may use the strong SLSS as SyncRef WTRU and/or the WTRU may set a platoon in-coverage indicator to true. The WTRU may determine, at 608, that the strong SLSS has a platoon in-coverage indicator set to false. For example, the WTRU may determine that the strong SLSS is a platoon follower. The WTRU may select the strong SLSS as SyncRef WTRU and/or set a platoon in-coverage indicator to false. If the strong SLSS does not have a platoon leader-indicator, the WTRU may select a SyncRef WTRU using an LTE procedure 610.

[0121] The priority of a platoon may be higher than a priority of the network for SyncRef WTRU selection, however, the platoon Type indicator may not be used. The implementations may be similar but without the verification of platoon type. For example, a WTRU may select a SyncRef WTRU without verifying a type of the platoon. FIG. 8 illustrates exemplary features associated with an example SyncRef WTRU selection 700. At 702, a WTRU may receive a SLSS. The SLSS may include a platoon indicator set to true. The WTRU may determine, at 704, whether the platoon (e.g., to which the SLSS belongs) has a leader-indicator set to true. If the platoon has a leader-indicator set to true, the WTRU may use the SLSS as SyncRef WTRU. The WTRU may determine, at 706, that the SLSS has a platoon leader-indicator set to false. For example, the WTRU may determine that the SLSS is a platoon follower. The WTRU may select the strong SLSS as SyncRef WTRU. If the SLSS does not have a platoon leader-indicator, the WTRU may select a SyncRef WTRU using an LTE procedure 708.

[0122] V2X in-coverage/out-of-coverage and cluster head implementations may be provided.

Implementations using group-based and/or cluster-based approach in combination with unicast, groupcast, or broadcast implementations may be used. Hybrid implementations using a combination of group-based, cluster-based, unicast, groupcast, and/or broadcast may be used. If a WTRU is interested to perform V2X communication on a non-serving frequency, the WTRU may perform one or more measurements on that frequency and/or the frequencies which may provide inter-carrier V2X configuration for that frequency for cell selection and/or intra-frequency reselection. If the WTRU detects a eNB and/or gNB with the frequency which the WTRU may be configured to perform, the WTRU may consider itself to be in-coverage for sidelink operation on that frequency. If the WTRU cannot detect a eNB and/or gNB on that frequency, it may consider itself to be out-of-coverage for sidelink operation on that frequency. When most WTRUs are out of coverage, synchronization and timing reference may become an issue. Approaches for timing synchronisation may be considered, e.g., for multiple WTRUs that are out of coverage, for example centralised (e.g., cluster head approach) and distributed implementations.

[0123] In a centralized approach, one V2X WTRU may be elected / appointed as a cluster head, e.g., to provide a timing reference for V2X WTRUs in the cluster or within its transmission range to synchronize to. There may be a dependency on the cluster head for providing timing reference. If the cluster head is removed or move away from the cluster, implementations to reselect a cluster head may be used (e.g., again). The approach may not be scalable in larger V2X networks due to the limited transmission range and hierarchical expansion may increase management overheads. This may be an approach for platooning use cases where the platoon leader may serve as the cluster head (e.g., always serve as the cluster head). If there is a change in platoon leader, the WTRUs in the platoon may be able to reorganize and elect a platoon leader.

[0124] In a distributed approach, a V2X WTRU may initiate reference timer for other V2X WTRUs within its transmission range. Different V2X WTRUs may participate to provide and maintain this timing reference within their transmission range. The approach may be scalable. Considering wide availability of GNSS and expanding cellular coverage, if one of the WTRUs in this distributed system is in coverage, other WTRUs (e.g., all WTRUs) may have SyncRef which is inCoverage.

[0125] In case of in-platoon communications, a time/frequency reference may be transmitted from the platoon leader for in-platoon V2X communications, e.g., while operating in or outside network coverage, instead of each follower obtaining the synchronization independently from gNB. This may be true for other V2X communications on PC5 interface, where WTRU may get the timing information from eNB, but V2X links may be used for fine timing and fine frequency synchronization.

[0126] Implementations for the time synchronization for platoon may be as follows, a WTRU may be elected as the Platoon Leader or "cluster head.” The WTRU may transmit the synchronization reference. The SLSS may have SLI which may be configured or used for platoon. The PS-BCH may include the information that the SLSS is transmitted by the leader of platoon / head of cluster. After receiving and decoding SLI, platoon follower and other WTRUs may know that SLSS came from platoon leader. Multiple WTRUs may try to elect themselves as the cluster head. A rule may be used to select one WTRU as the cluster head of a given area. This may be situation dependent. In examples, the first vehicle leading the platoon physically may need to be the leader as it may need to react to various road situations. In examples, e.g., if the platoon is too long, the center vehicle may be preferable as it may have lowest latency of communications amongst all member of platoon (especially for relay mode). WTRUs within the coverage of the platoon leader (e.g., some of the platoon followers) may monitor the SLSS and may acquire the timing / frequency reference of communications. Using the timing reference and decoded PSBCH, a WTRU may derive SFN and slot boundaries. The cluster follower may (e.g., if needed) transmit SLSS for the WTRU which couldn't receive SLSS from the platoon leader. A different guard interval (Gl) may need to be used for further communication by the platoon leader, e.g., based on the size of platoon. This may be indicated in SLSS or PSBCH.

[0127] Sidelink capacity enhancement implementations may be provided. Sidelink capacity enhancement may include one or more of the following: NR-PSSS implementations; NR-SSSS implementations; or, NR-SLSS implementations for SyncRef Indication.

[0128] NR-PSSS implementations may be provided. Various coverage indicators may be used, e.g., as opposed to LTE, where there were two states for coverage indicator used for in and out of coverage.

The coverage indicators may be ranked based on synchronization priority. As an example, a WTRU may prefer (e.g., prioritize) the PSSS in SLSS that is in coverage of LTE as well as NR V2X, followed by in coverage LTE Only, and as a last preference out of coverage SLSS.

[0129] For different scenarios a coverage indicator (Cl) may be used. Values of C, may indicate different coverage status. For example, the coverage indicator may indicate whether a WTRU is associated with a platoon. The M sequence (e.g., in a synchronization signal) may include the coverage indicator. For example, a first M sequence may be used to indicate a platoon leader, a second M sequence may be used to indicate a WTRU in-coverage by the platoon leader, and a third M sequence may be used to indicate a WTRU out-of-coverage by the platoon leader. FIG. 5 depicts an example coverage indicator status 450.

For example: C, = 0: In coverage LTE and NR (in this, NR WTRU with NR and LTE coverage may be transmitting NR Sidelink SS); C, = 1 : In-Coverage LTE Only (in this, NR WTRU with LTE only Coverage may be transmitting NR Side-link); C, = 2: Out of coverage (in this C, = 2, NR WTRU without any coverage is transmitting NR Sidelink synchronization).

[0130] The sequence c/ _PSSS (n) for the primary synchronization signal for sidelink may be defined by

M sequence. The M sequence may also define a secondary synchronization signal for sidelink. The sequence may be circularly offset with a different value, which may be function of the Cl (e.g., these may be referred to as roots).

d _FSSS (n) = \ - 2x(m )

m = (n + X x C + Offset) modl27

0 £ n < 127 [0131] In NR, the value of X may be used as 43 and offset as 0. This may generate the roots/offset [0,43,86], Where NR polynomial may be used, e.g., x(/ +7) = (x(/ +4)+x(/))mod2 and NR initialization.

[x(6) x(5) x(4) x(3) x(2) x(l) c(q)] = [ΐ 1 1 0 1 1 o]

[0132] For a sidelink with three coverage indicators, we may use same X = 43, and offset may be floor(X/2) = 21. This may ensure that the roots/offset for these sequences are equally spaced and apart of NR and NR-SL are operating in same band and have least chance of time or frequency ambiguity. This may create the root distribution [21 , 64, 107], This may be well interlaced with NR root distribution. More roots/offset may be used to increase the number of SLI that can be supported.

[0133] A same or different polynomial as NR with same or different initialization may be used to indicate 4 different coverage status. If a different polynomial is selected, cross/auto correlation performance may be used as basis of selection. In examples, 4 different coverage status may be used. If a different polynomial is used a value for X may be of 14, with the Offset of 14. this may create different root/offsets, e.g., [14,28,42,56,70], (or similar distributed within 0-126 along with the NR-PSS roots). As 42 is close to the root 43, e.g., used in NR-PSS, it may create frequency ambiguity, it may be skipped. This results in 4 different in-coverage status of the WTRU, e.g., with root/offsets [14, 28, 56,70], and the following may apply: C, = 0: In coverage LTE and NR; C, = 1 : In-Coverage LTE Only (note value of C, = 2 is skipped as it is close to NR PSS root 43); C, = 3: In coverage NR only (in this NR WTRU with NR only coverage is transmitting NR Sidelink SS); C, = 4: Out of coverage .

[0134] If multiple Cl are included the WTRU may try {e.g., first try) to synchronize with the PSSS with index of most preferred source followed by other sources, e.g., may reduce the complexity.

[0135] One of the C, may be associated with being platoon leader or part of platoon operations. Broadcasting SLI from a range of SLIs associated with this C, may imply being part of platoon. To join a platoon or to be actively part of platoon, the synchronization with this PSSS from the platoon or SyncRef from platoon may be higher priority than using other source(s). Using this signal in the PSSS may be efficient. WTRU may search for PSSS with C, corresponding to platoon instead of searching for PSSS with other C, . Platoon leader may send a separate indication of being the platoon leader in SL-MIB for NR.

[0136] In examples with repeated NR-PSSS case is considered, to reduce the complexity of PSSS detection, 2 (e.g., only 2) PSSS M sequence roots/offsets may be used, e.g., along with an orthogonal cover code (OCC) on top of the repeated PSSS. As an example, this OCC may be a Hadamard code [1 , 1 ; 1 , -1], This OCC may be detected blindly. For first code [1 ,1], PSSS followed by PSSS may be transmitted. For second code [1 -1], 180 phase rotated version of PSSS may be transmitted in repeated symbol of PSSS, e.g., [PSSS, -PSSS], This code may be blindly detected on PSSS by a receiver, e.g., possibly without any additional complexity.

[0137] The OCC may be used to indicate part of C, . OCC may be used to indicate timing bits, OCC may help PBCH combining, e.g., as mentioned in following section. OCC on PSSS may be used to indicate being part of platoon or not.

[0138] To Increase the performance of detection, a longer PSSS generated using higher order polynomial and with different root-offset may be used (e.g.,‘B,’‘C).

d _FSSS (n) = \ - 2x(m )

m = (n + X x C + Offset) mod 255

0 < « < 255

[0139] A primitive polynomial of degree 8 may be used. E.g. x(i + 8) = ( x(i + 4) + x(i + 3) + x(r + 2) + x(i))mod2. An initialization of [0 0 0 0 0 0 0 1] may be used, or any other initialization may be used. The root/offset for the sequence may be equally spaced within the length of the sequence.

[0140] A 127 length sequence may be mapped to 255 sub-carriers with every second subcarrier nulled out. This may create a time repeated structure. OCC may be applied on this time repeated structure, e.g., as described above.

[0141] NR-SSSS implementations may be provided. A structure similar to NR-SSS may be used (e.g., Gold Code) for NR-SSSS. The current structure may support a total of 336 unique Cell-IDs using the SSS alone. To support higher or lower number of SLIs using SSSS, some modification may be applied to generation of NR based sequence.

[0142] In NR, the gold sequence of length 127 may be generated using the following equation where xO and x1 are different M sequence of length 127.

d _s ss (n) = [l - 2x ₀ ((« + m ₀ ) mod 127 )][l - 2x _: ((« + m ₁ ) mod 127 )]

[0143] A different number of circular shifts for both sequences may depend on the number of SLI needed to be supported by the system. Let's consider Msu number of SLI to be supported and Mci number of coverage indicator are supported (In above cases Mci = 3 or 4). To compute different shifts based on SLI and Cl, different methods based on div and mod operation may be used.

[0144] Mci may be split into Mci different parts of length L = and each part may be indicated

using div operation. mO may be function of the index of the part used where SLI is in the section, i.e.

mO may be a function of Mci, Ki, K2 which may be a constant {e.g., which may be 1 ) and Cl which may be used as an offset. Some examples may be: ’"° = ^k1 (ίt])

ml , the shift for other sequence may be index in the section L chosen before. Of a function of SLI, Cl and L. An example is given below.

• ml = SLI mod L

[0145] Using this methodology, large number of Msu may be supported. The same methodology may be applied for generating SSSS with length 255. If SSSS is repeated, OCC may be applied in it. Using blind detection, the OCC at receiver may be detected. This bit indicated using OCC may be used as time information and may help PBCH combining, e.g., as described herein. OCC on SSSS may be used to indicate being part of platoon or not.

[0146] A 127 length sequence may be mapped to 255 sub-carriers with every second subcarrier nulled out. This may create a time repeated structure. OCC may be applied on this time repeated as well.

[0147] NR-SSSS implementations for a SyncRef indication may be provided. NR-PSSS/SSSS may be used to enable faster SyncRef selection. To enable faster reselection NR-PSSS may indicate that the device is in or out of coverage and NR-SSSS may indicate Synch-Ref source from NR-gNB, LTE-eNB, GNSS (e.g., specific SLI value), and/or Platoon-Leader. An M sequence (e.g., in a synchronization signal) may include a coverage indicator. For example, a first M sequence may be used to indicate a platoon leader, a second M sequence may be used to indicate a WTRU in-coverage by the platoon leader, and a third M sequence may be used to indicate a WTRU out-of-coverage by the platoon leader. This may be done by using multiple SLI groups. For example, if Msu number of needs to be supported, and Mci different Cl needs to be supported, SSSS may be a way that one of the M sequence of gold code indicates Mcu and the other M sequence may indicate the Mci. One M sequence may indicate Mcu/K values and another M sequence may indicate MciK values. Mcu/K values and/or MciK values may be indicated using one or more circular shifts of the M sequence.

[0148] In examples, PSSS may indicate the SyncRef WTRU (NR-gNB, LTE-eNB, GNSS, Platoon) and the SSSS may indicate different values [0-333], that may be combined with PSSS to compute SLI. [0149] In examples, the gold code may indicate the Mcu values. Cyclic shifts applied on gold code may be used for indicating the different values of Cl SSSS (n) = e ^jnCl SSSSi (n), 0 < n <

S _sss> £ Ci < M _CI .

[0150] NR-PSBCH detection and soft combining may be provided. In LTE-V2X SLSS may be sent at a sub-frame in a system-frame. The number of sub-frames as well as system frames may be included in the PSBCH. As this keeps changing, it may be difficult to soft combine different PSBCH received at different times which may be transmitted by different vehicles with same SLI. This flexibility of transmitting SLSS at, e.g., at any time, may be needed for V2X communication.

[0151] NR-V2X may be deployed on bands in FR1 or FR2. Multiple and different sub-carrier spacing may be possible depending on the band. For different SCS, the number of slots in system frame may vary. For different SCS, the burst structure length may vary. Multiple burst occasions may be created and it may be possible to transmit a burst at one or more occasion in the system frame. Depending on SCS, number of burst occasion may be different. The used burst occasion (e.g., timing information) may be referred to as SyncBurstOffset. If the SS/PBCH block is transmitted any slot, the SlotOffset may be used. Computation for this may be as follows. For 15 kHz SCS there may be 10 slots in a system frame of NR. Without SS- Burst structure like NR 4 bits may be needed to indicate SlotOffset. NR Burst for 15kHz SCS may occupy 4 slots (for 8 SSBI). Maximum 2 Burst Occasion may be present. 1 Bit may be used to indicate

SyncBurstOffset. For 30kHz SCS there may be 20 slots in a system frame. Without SS-Burst structure like NR 4 bits may be needed to indicate SlotOffset. NR Burst for 30kHz SCS may occupies 4 slots (e.g., for 8 SSBI). A maximum 5 Burst Occasion may be present. 5 Bit may be used to indicate SyncBurstOffset. For 120kHz SCS there may be 80 slots in a system frame. Without SS-Burst structure like NR 7 bits may be needed to indicate SlotOffset. NR Burst for 120kHz SCS may occupy 36 slots (for 64 SSBI). A maximum 2 Burst Occasion may be present. 1 Bit may be used to indicate SyncBurstOffset. For 240kHz SCS there are 160 slots in a system frame. Without SS-Burst structure like NR 8 bits may be needed to indicate SlotOffset NR Burst for 240kHz SCS occupies. 32 slots (for 64 SSBI). A maximum (160/32) 5 Burst Occasion may be present. 5 Bits may be used to indicate SyncBurstOffset.

[0152] This timing information, e.g., where the SS/Burst is located, is used for WTRU synchronization. Considering high velocities and vehicle blocking channels may create a harsh environment where soft combining may be necessary for detection of NR-PSBCH. In NR SS Bursts may be defined, which may be transmitted periodically. Taking advantage of this burst structure and including some time-based information (SSBI) in the PBCH-DMRS, WTRU may take advantage of combining PBCH for reliable reception of PBCH. NR-V2X may use a different Burst structure, but the concept of transmission with different offset may be the same and the combining at the receiver may be the same. [0153] For SLSS transmitting WTRU, one or more of the following may apply. For beam based (e.g., SS Burst based) implementations, Multiple SS Burst Occasion may be defined within System Frame for transmitting NR-SLSS, where SLSS may or may not be transmitted. Periodicity of NR-PSBCFI (P) and SyncBurstOffset may be configured by NR OSI, e.g., over NR-Uu interface or LTE Uu interface, a SIB (e.g., new SIB) may be used to support NR-V2X. The SS Burst may be transmitted when the following condition is true: (10 ^* DFN + slotjiumber) mod P = SyncBurstOffset x nSlotm, where nSloto may change depend on SOS. SSBI may use 3 bits for FR1 , 6 bits for FR2 (e.g., 3 of which may be included in the PSBCH Payload). As described herein SyncBurstOffset may use 1 bit for 15 kHz SOS and 120kHz SOS and up to 3 Bits for 30 kHz SOS and 240kHz SOS. For an Omni implementation (e.g., without NR like SS Burst Structure) SlotOffset and Period P may be configured by NR OSI, e.g., over NR-Uu interface or LTE Uu interface SIB (e.g., new SIB, such as a new SIB used to support NR-V2X ). For omni implementation (10 ^* DFN + slot_number) mod P = SlotOffset.

[0154] For SLSS receiving WTRU: depending on the SyncBurstOffset (e.g., along with SSBI) or SlotOffset used at the transmitter, a different time-stamp may be received at WTRU, which may be used to blindly detect these SyncBurstOffset (e.g., along with SSBI) or SlotOffset. Soft-combining the PSBCH payload may be possible. Here we may assume that the DFN information is in PSBCH. Combining the timing offset and DFN, WTRU may calculate timing, e.g., exact timing. Two bit of SFN may be used for scrambling, e.g., along with SLI.

[0155] In examples, different implementations may be used by SLSS Transmitting WTRU that may preserve soft combining of received PSBCHs from consecutive SS blocks from same source or combine PSBCH from multiple SS block from different WTRUs with different time stamps, e.g., for performance boost. Different implementations may facilitate soft-combining operation (e.g., using Chase combining) across multiple transmissions, for example if the information payload in each transmission is largely same with some change (e.g. in case of 15 kHz SOS, within an SFN, the two transmissions of SL-V2X-MIB correspond to the same set of information except for the slot index which may differ by maximum 4 bits. If X of these bits are indicated outside of SLBCH, 4-X bits may be different in the payload). The principle of soft combining may apply to LDPC and Polar codes, e.g., as they are both linear codes.

[0156] The offset using cyclic shift on SSSS may be indicated. Instead if indicating the SlotOffset or SyncBurstOffset in PSBCH, different cyclic shifts may be applied to SSSS for indicating the SlotOffset or SyncBurstOffset.

SSSS“(n) = e ^ian SSSS _i (n), 0 < n < M _ssss

[0157] After receiving SSSS, a receiver may use different hypothesis on SSSS to identify the cyclic shift used for different Offset indicating the timing. This may be used in conjunction with SSBI transmitted in PSBCH-DMRS. As no time-varying bits are part of PSBCH payload, the payload may be soft-combined by the receiver. The operation of multiplying each bit with e ^ian may be considered as cyclic shift and reading from different position of circular buffer may be considered as circular shift.

[0158] DMRS based time index implementations may be provided. In NR 3 bits of SSBI may be embedded into the PBCH DMRS sequence. A receiver may use GLRT based detection to blindly detect these three bits. This may require that time index signaling be able to maintain good cross correlation property between different time indices, which may be achieved by using shifted PN sequence. Adding up to 3 more bits for SyncBurstOffset or SlotOffset may increase the detection complexity. 3 bits of SSBI may be indicated using DMRS of a first PBCH symbol and/or 3 timing bits {e.g., SyncBurstOffset or SlotOffset) may be indicated using cyclic shift on DMRS of a second PBCH symbol.

[0159] A receiver may use GLRT type of detection on first OFDM symbol DMRS. The receiver may use that as reference to find the cyclic shift used on the second OFDM symbol. This may be used in case more number of PBCH symbols or in LTE like DFT-s-OFDM is used where entire symbol are used as DMRS.

[0160] In this implementation orthogonality (or low cross correlation), different SLID may be needed in synchronous high capacity environment with multiple SLIs. DMRS may use v_shift for sub-carrier locations for DMRS, e.g., computed based on SLI. For example. v_shift = SLI mod 4.

[0161] Hybrid on payload and DMRS may be provided. This may be similar to NR where SSBI is implicitly indicated in PBCH-DMRS, and some timing information is included in in Payload of NR-PBCH. SyncBurstOffset or SlotOffset may be explicitly signaled as part of the PSBCH payload. This may require decoding of PSBCH, e.g., to obtain the time index signaling. To enable soft combining the timing bits may not be scrambled by the first scrambler {e.g., before the CRC and encoder). To perform soft-combining, WTRU may need to perform polar decoding and re-encoding with hypothesized SyncBurstOffset or SlotOffset. Soft-combining may include multiple polar decoding, which may result in bit higher complexity. Existing decoder hardware for PDCCH may be used.

[0162] Use of circularly shifted NR-PSBCH may be provided. The payload in PSBCH may be constant. The information about timing may be encoded in the circular shifts of the data. As the payload may be similar or identical in for received copies of across different SS blocks and SLSS transmitted by different WTRUs, soft combining may be possible at the receiver before decoding. This may enhance the PSBCH performance. At the receiver from the detection complexity perspective may be less. The WTRU may perform bit shifts and CRC checking. In this case shifts may be used to indicate the offset. To indicate X offset (SyncBurstOffset or SlotOffset) we may use X different shifts, e.g., instead of using log2(X) bits. As an example, if the sequence is N bit long, data may be transmitted from circular buffer starting at location separated by floor(N/X) for uniformity. If X>N, N (e.g., only N) number of time offset may be indicated and other offset may be indicated using SSS or PSBCH-DMRS or other mechanism.

[0163] Instead of circular shifts a known permutation pattern may be used. If this permutation pattern mapping from number to permutation of data is known to both transmitter and receiver, the data may be soft-combined and the Offset may be decoded. This is illustrated in FIG. 9. FIG. 9 illustrates an example of PBCH soft combining 800, e.g., using circularly shifted data.

[0164] Using hybrid of circularly shifted and burst may be provided. SSBI may be indicated by DMRS for PSBCH-and the SyncBurstOffset may be indicated by the circular shift of the transmitted polar encoded data of PSBCH. If no burst is used, SlotOffset indication bits may be entirely transmitted by the shift in coded PSBCH data circular shifts. For example, if there are 48 PRB with QPSK modulation used for PSBCH and DMRS density is 1/4, there may be 864 coded bits including, e.g., which may be used to indicate different slot locations. To reduce the blind detection complexity, some information may be indicated using PBCH DMRS {e.g. 3bits) and the rest may be indicated in the circular shift of the encoded data.

[0165] NR-PSBCH soft combining and platoon information may be provided. When a platoon is formed and operational, a vehicle which does not belong to the platoon should be aware the existence of the platoon. For example, the vehicle may move into the middle of the platoon and disrupt the operation of the platoon. Being part of platoon may need to be broadcasted. NR-PSBCH may be used to indicate it. If multiple sub-carrier spacing are supported, the sub-carrier spacing used for data channel in the platoon may be indicated in the PSBCH. This may be used by new out of coverage WTRU joining the platoon. If a WTRU detects that SLSS (using PSSS/SSSS/PSBCH) received is transmitted from WTRU which is part of platoon, WTRU may not soft-combine the SLSS with PSBCH obtained from other NR-SLSS.

[0166] Implementations associated with system information delivery may be provided. LTE Sidelink may obtain (e.g., only obtain) the system information from the eNB, e.g., when it's in RRC_CONNECTED mode. In NR V2X some system information may be transmitted in a side-link by an authorized WTRU, e.g. Platoon leader WTRU to another WTRU. This information may be different than the pre-configuration of the WTRU by the gNB and may have higher priority during the operation of the platoon or till the WTRU is part of platoon.

[0167] Some example information that may be transmitted may include one or more of the following. Different frequency WTRU may anchor for the duration that the WTRU is part of a platoon. These may be called the anchor frequencies for platoon. The resource-pools for Tx and Rx of PSCCH and PSSCH which may be the transmission and reception pools for the communications within the platoon and the configuration used for WTRU autonomous resource selection within the platoon. Resource allocation type or mode such as the adjacency of these PSCCH and PSSCH. Pools for external communications (e.g., external to the platoon) including pedestrian or other vehicles or the network. Bandwidth or bandwidth part (BWP) used for communication within platoon. {E.g., Semi-static) UL/DL slot format configuration used for communication within platoon.

[0168] These rules may set up synchronized environment where the WTRU's of the platoon may not interfere with each other or interference may be minimized. Multiple sub-pool for Tx and Rx within the operational band may be dedicated for platoon operation and may be assigned to platoon leader at the time of initial or channel access or formation of platoon.

[0169] SLSS (including PSBCH) transmitted from the WTRU belonging to platoon or platoon leader may indicate location of Control resource set (CORESET) and/or search space e.g., for PSCCH/PSSCH for this configuration described above. Such indication may include a periodicity for monitoring occasion, actual location, a window, relative offset or similar. Combination of platoon indication and platoon type indication may be associated with CORESET for the platoon. Vehicle or WTRU may use the CORESET dedicated to the platoon and/or platoon type. Vehicle or WTRU who are not part of platoon may discard the CORESET information they receive.

[0170] An association between SLSS and system information e.g., SL-RMSI, SL-OSI or SL-SIB may be used. For example, an association between the location of SLSS and the system information may be in a form of an equation or a function. The association between the location of SLSS and the system information may be a function of numerology or sub-carrier spacing used or FDD/TDD configuration. The association between the location of SLSS and the system information may depend on multiplexing type such as FDM or TDM. The association between the location of SLSS and the system information may be tabulated or parameterized based on system parameters. Configuration for association between the location of SLSS and the system information may be indicated in SLSS or PSBCH. The periodicity, duration, location, offset or window may be preconfigured, indicated or predefined relative to the location of transmitted PSBCH (e.g., which may indicate that it is transmitting platoon information). This may be considered as platoon discovery or platoon discovery window. Within this CORESET/search space/window there may be a PSCCH with a specific RNTI indicating that the PSCCH includes system information for operating a platoon. The PSCCH may include a location of PSSCH with the system information.

[0171] The information may be broadcasted, group-casted or unicasted periodically or transmitted on triggered or requested by a vehicle or WTRU indicating to join the platoon. The request may be sent through Uu interface by the network, where network may trigger the platoon leader to transmit the SLSS.

[0172] Vehicle/WTRU implementations may include one or more of the following. The vehicle/WTRU may receive PSBCH. The vehicle/WTRU may use the indicator to determine that the PSBCH is from platoon leader or member of platoon. The vehicle/WTRU may find information from PSBCH for the SearchSpace/CORESET for PSCCH. This may be preconfigured, indicated or predefined. Depending on the speed of (Tx and Rx) vehicle and surrounding scenario, the SLSS including PSBCH and CORESET comprising PSCCH or PDCCH for System information may not be QCLed for receiver, e.g., even if transmitted in the same beam. The WTRU may indicate the start of the sweep of system information, e.g., if needed. As system information is beam-swept and similar or identical information may be transmitted in the beams (e.g., all the beams), the receiving WTRU may be able to receive the system information if the received power is high enough (e.g., above a threshold). The vehicle/WTRU may find the PSCCH using the dedicated RNTI (e.g., single value or a range of values defined for platoon). GC-PDCCH may be specific to platoon, platoon specific RNTI specific or multiple RNTIs for platoon may be used. The vehicle/WTRU may receive and decode PSSCH. The vehicle/WTRU may configures itself to receive / transmit messages from platoon. This may include one or more of the following: frequencies to use for platoon communications, anchor frequency or primary carrier (bandwidth and/or bandwidth part (BWP) to use for platoon communications); Rx/Tx resource-pool PSCCH and PSSCH to be used for platoon or other nodes; or resource allocation type such as the adjacency of PSCCH and PSSCH or CORESET/Search Space configuration. Higher layer authentication may be performed, e.g., before actual transmission and reception.

[0173] Implementations associated with accessing vehicle platooning may be provided. Vehicle platooning mode may enable the vehicles to dynamically form a "platoon” travelling together. The vehicles in the platoon may obtain information from the leading vehicle to manage this platoon. The information may allow the vehicles to drive closer than normal in a coordinated manner, going to the same direction and travelling together. To form a platoon, vehicles need to exchange intent such as interest to form a platoon, intention to be a leader or follower of the platoon. When a vehicle reaches a destination or has to leave the platoon, this intent should also be exchanged among vehicles of the platoon. The exchange of intent may occur at a time while the platoon is active.

[0174] FIG. 10 illustrates an example associated with joining a vehicle platoon. For example, a WTRU may use one or more of the vehicle platoon joining feature(s) of 900.

[0175] One or more of the following may be used by vehicle or WTRU for joining an existing platoon. Vehicle or WTRU may or may not have Synchronization Source when searching for SLSS of platooning source. Vehicle or WTRU may search for SLSS in which an indication may be used to indicate that the SLSS is transmitted from platoon. Platoon indication may be carried in SS block, SL-SSB, PBCH, RRC, RMSI, SL-RMSI or PSBCH. For example, MIB or MIB-SL may include Platoon indication. The vehicle or WTRU may check SS block, SL-SSB, PBCH, PSBCH, MIB or MIB-SL to obtain the Platoon indication. K-bit indication for platoon information may be included. K may be one or larger than one. For example, K=1 bit may indicate whether this is platoon or not. Different types of platoon may be indicated. K2-bit indication for platoon type information may be included in SS block, SL-SSB, SL-RMSI or the like. If vehicle or WTRU finds a Platoon indication (e.g., vehicle or WTRU finds an SLSS that contains Platoon indication, platoon type indication): vehicle or UE may verify the platoon information that vehicle or WTRU is intending to join, which may include one or more of the following: check the platoon indication, check the platoon type indication, check or compare the SLI with preconfigured SLI or the set of SLI by NR V2X configuration for vehicle platoon; vehicle or WTRU may measure the S-RSRP (RSRP of the sidelink, e.g., measured from the DMRS of PBCH of the NR-SLSS from the platoon) which is greater than threshold configured for detecting platoon; or the threshold may be preconfigured by RRC. Vehicle or WTRU may identify the platoon system information location for this platoon (as described herein). Using this platoon system information or platoon discovery information, vehicle or WTRU may send request to join the platoon (or intent to be follower of the platoon). This may include one or more of the following: this may be in a form of a unicast / groupcast PSSCH (this information may be relayed to platoon leading vehicle); this may be in form of side-link-RACH (SL-RACH), where one or more of the following may apply: RACH Msg1 or preamble partition or different types or groups of Msg1 or preamble may be used to indicate that vehicle or UE may join or leave the platoon or association between RACH Msg1 or preamble and platoon requests, platoon parameters or platoon indications may be used; or, wait for a response from the platoon. Vehicle or WTRU may wait for the response till a specific timer (e.g., configured for SLSS platoon response) expires. The timer may be configured, indicated, or predefined. The SL-RACH power ramp up may be performed. Vehicle or WTRU may look for this response at location / resource that are predefined, configured or indicated. If Vehicle or WTRU receives a response from the platoon, higher layer implementations joining the platoon may be performed, e.g., including security. The response may require resolution of contention if the initial message was in form of SL-RACH. If Vehicle or WTRU doesn't get a response till timer expires, one or more of the following may apply: if Vehicle or WTRU is connected to gNB, vehicle or WTRU may send a request to gNB to trigger the platoon SLSS transmission (e.g., if gNB agrees that WTRU may join the platoon, the gNB may request the platoon leader to send SLSS); or, if vehicle or WTRU is not connected to gNB and still intending to join the platoon, the vehicle or WTRU may restart the SLSS search process.

[0176] Different implementations may be used by the WTRU to join the platoon, which may include random access or scheduled. Depending on which is used, different information may be included in this Platoon control information or system information. [0177] For random access one or more of the following may be provided. PRACH may be (e.g., specifically) defined for Sidelink. The platoon system information may include RACH Occasion,

Configuration index, and/or RAR window etc. Using this configuration, the vehicle or WTRU may send Msg1 as a request to join the platoon (or intent to be follower of the platoon). The vehicle or WTRU may wait for a response from the platoon. If the platoon leader receives the request, the platoon leader may send Msg2, or SL-RAR. WTRU may wait for the response till a specific timer (configured for SLSS platoon response) expires. This timer may be configured. This may include the RACH power ramp up procedure. The WTRU may look for this response at predefined location / resource. A contention resolution may be used. This may use RACH Msg3 and Msg4. Platoon leader may (e.g., after the contention resolution) grant the request and send more RRC configuration. This configuration may include Rx / Tx resource pools and other information that may enable the WTRU to communicate within the platoon. The WTRU may follow similar actions while leaving the platoon.

[0178] For scheduled implementations one or more of the following may be provided. In scheduled implementations the platoon control or system information may include scheduling information or occasion for resources where the WTRUs may be able to transmit PSSCH. On this resource the Vehicle or WTRU may send request to join the platoon (e.g., or intent to be follower of the platoon) in form of PSSCH. This may be in form of broadcast or a groupcast addressed to the SLI received in SLSS. If the request is received by the platoon leader one or more of the following may apply: platoon leader may grant the request and send more RRC configuration; or, this configuration may include Rx / Tx Resource pools and other information that will enable the UE to communicate within the platoon. The WTRU may wait for the response till a specific timer (e.g., configured for SLSS platoon response) expires. This response may be in form of Unicast and addressed to RNTI corresponding to platoon WTRU.

[0179] Although the features and elements of the present disclosure may be described in embodiments or in particular combinations, each feature or element can be used alone without the other features and elements of the preferred embodiments or in various combinations with or without other features and elements of the present invention. Although the solutions described herein consider LTE, LTE-A, New Radio (NR) or 5G specific protocols, it is understood that the features described herein are not restricted to this scenario and are applicable to other wireless systems as well.