Method and apparatus for determining one or more RB sets for SSB transmission using side link reserving resources

Abstract

A WTRU may monitor sidelink transmissions from one or more other WTRUs during a resource listening window, and determine reserved sidelink resources before or after a sidelink synchronization signal block (S-SSB) slot based on the monitored sidelink transmissions during the resource listening window. The S-SSB slot may include a plurality of RB sets, and at least one RB set of the plurality of RB sets may be configured as a default RB set. The WTRU may determine one or more other WTRUs that have reserved the reserved sidelink resources, e.g., based on identification information associated with the one or more other WTRUs. The WTRU may transmit the S-SSB information on at least one RB set other than the default RB set based on at least one other WTRU among the one or more other WTRUs that has reserved the reserved sidelink resource on a time slot before or after the S-SSB time slot.

Description

Cross-reference to related applications

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 456,900, filed April 4, 2023, the disclosure of which is incorporated herein by reference in its entirety. Background Technology

[0002] Unlicensed spectrum is frequency resource that can be freely used by different operators using different radio technologies. If channel access is successful, i.e., a Listen-After-Tell (LBT) operation is successful, the transmitter can transmit on the unlicensed spectrum. When LBT fails, the transmitter backs off for a period of time and attempts to access the channel again later. The transmitter continues to attempt to access the channel until it becomes idle. This process can cause transmission delays and increase the uncertainty of the time it takes for a transmission to complete successfully.

[0003] Sidelink synchronization signal blocks (S-SSBs) can be transmitted in the sidelink channel to provide synchronization to sidelink radio transmit / receive units (WTRUs) outside coverage or at the cell edge. A synchronization reference WTRU can be a sidelink WTRU that transmits S-SSBs in the sidelink channel. Other sidelink WTRUs monitor the S-SSBs for synchronization. In existing 5G New Radio (NR) and 3GPP Long Term Evolution (LTE) sidelink systems, S-SSB resources are configured separately from resource pools and cannot be used for sidelink data transmission.

[0004] With the support for sidelinks in unlicensed channels and the uncertainty of channel access, additional S-SSB transmission opportunities can be configured to increase the chances of S-SSB transmission and enhance sidelink synchronization performance. The additional S-SSB resources can be configured as part of a resource pool, meaning that if additional S-SSB resources are not used for S-SSB transmission, they can be opportunistically used for sidelink data. Alternatively, they can be configured separately from the resource pool, meaning the additional S-SSB resources cannot be used for sidelink data transmission. Summary of the Invention

[0005] In an embodiment, the WTRU can be configured to perform a synchronization method for sidelink communication by transmitting sidelink synchronization signal block (S-SSB) information on one or more S-SSB slots. The S-SSB information includes multiple resource block (RB) sets, where at least one RB set is configured as the default RB set. During a resource listening window, the WTRU monitors sidelink transmissions from other WTRUs and determines reserved sidelink resources before and / or after the S-SSB slot to identify other WTRUs that have reserved sidelink resources. If at least one other WTRU has reserved sidelink resources before or after the S-SSB slot, the WTRU can transmit the S-SSB on an RB set other than the default RB set. The WTRU can further determine the Listen-Before-Speak (LBT) type for the S-SSB transmission on that RB set.

[0006] A wireless transmit / receive unit (WTRU) may include a processor, memory, and / or a transceiver. The WTRU may be configured to monitor sidelink transmissions from one or more other WTRUs during a resource listening window. The resource listening window may be determined based on an S-SSB timeslot configuration. The WTRU may be configured to determine reserved sidelink resources before or after a Sidelink Synchronization Signal Block (S-SSB) timeslot based on the sidelink transmissions monitored during the resource listening window. An S-SSB timeslot may include multiple RB sets, and at least one of these RB sets may be configured as a default RB set. The WTRU may identify one or more other WTRUs that have reserved the reserved sidelink resources, for example, based on the sidelink transmissions monitored during the resource listening window. The WTRU may be configured to transmit S-SSB information on at least one RB set other than the default RB set based on at least one of these other WTRUs that has reserved the reserved sidelink resources in a timeslot before or after the S-SSB timeslot.

[0007] The WTRU can determine at least one RB set other than the default RB set based on the priority associated with reserved side crosslink resources before or after the S-SSB time slot. The WTRU can determine the Listen-After-Speak (LBT) type for S-SSB transmissions on at least one RB set other than the default RB set. The LBT type can be a long LBT type or a short LBT type. The WTRU can be configured to send an indication to one or more other WTRUs of the Listen-After-Speak (LBT) type to be used for the reserved side crosslink transmission. Indications to other WTRUs can be sent via the Physical Side Crosslink Broadcast Channel (PSBCH).

[0008] The WTRU can monitor sidelink transmissions during the resource listening window to decode sidelink control information (SCI) sent by one or more other WTRUs that have reserved the reserved sidelink resource. The SCI indicates the reserved sidelink resource before or after the S-SSB time slot. The WTRU can use the SCI to determine the identification information of one or more other WTRUs that have reserved the reserved sidelink resource in the time slots before and after the S-SSB time slot. For example, the WTRU can use the identification information of one or more other WTRUs that have reserved the reserved sidelink resource in the time slots before and after the S-SSB time slot to determine at least one RB set outside the default RB set.

[0009] This document may also describe methods performed by WTRUs (Sync Ref WTRUs and / or Launch WTRUs). Attached Figure Description

[0010] Figure 1A This is a system diagram illustrating an exemplary communication system that can be used to implement one or more of the disclosed embodiments.

[0011] Figure 1B The diagram is available. Figure 1A The system diagram shows an exemplary wireless transmit / receive unit (WTRU) used in the communication system.

[0012] Figure 1C The diagram is available. Figure 1A The system diagram shows an exemplary radio access network (RAN) and an exemplary core network (CN) used in the communication system shown.

[0013] Figure 1D The diagram is available. Figure 1A The system diagram shows another exemplary RAN and another exemplary CN used in the communication system shown.

[0014] Figure 2 This is a flowchart illustrating an example of how the Synchronous Ref (WTRU) uses reserved side link (SL) resources to determine the set of resource blocks (RBs) for SSB transport.

[0015] Figure 3 This is a diagram showing the Channel Occupancy Time (COT) initiated by the transmit (Tx) WTRU on two RB sets that overlap with the S-SSB time slots.

[0016] Figure 4 This is a flowchart illustrating an example of a Tx WTRU recognizing a Sync Ref WTRU and requesting an S-SSB transfer on multiple RB sets.

[0017] Figure 5This is a flowchart illustrating an exemplary process by which a Sync Ref user equipment (UE) indicates the set of RBs used for transmitting S-SSB. Detailed Implementation

[0018] Figure 1A This diagram illustrates an exemplary communication system 100 that can be used to implement one or more of the disclosed embodiments. The communication system 100 can be a multiple access system that provides content (e.g., voice, data, video, messaging, broadcasting, etc.) to multiple wireless users. The communication system 100 enables multiple wireless users to access such content by sharing system resources (including wireless bandwidth). For example, the communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal Frequency Division Multiple Access (OFDMA), Single Carrier Frequency Division Multiple Access (SC-FDMA), Zero-Tail Unique Word DFT Spread Spectrum OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0019] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments consider any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d can be any type of device configured to operate and / or communicate in a wireless environment. For example, any of WTRUs 102a, 102b, 102c, and 102d may be referred to as a “station” and / or “STA”, configured to transmit and / or receive wireless signals, and may include user equipment (WTRU), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated processing chains), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as WTRU.

[0020] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to connect to at least one radio interface of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks (e.g., CN 106 / 115, Internet 110, and / or other networks 112). For example, base stations 114a and 114b may be base transceiver stations (BTS), Node-B, eNode B, home Node B, home eNode B, gNB, NRNodeB, site controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are each depicted as a single unit, it should be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0021] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide radio service coverage for a specific geographic area, which may be relatively fixed or may vary over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver per sector of the cell. In embodiments, 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 can be used to send and / or receive signals in a desired spatial direction.

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

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

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

[0025] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can use NR to establish air interface 116.

[0026] In this embodiment, base station 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can together implement LTE radio access and NR radio access, for example, using the dual connectivity (DC) principle. Therefore, the air interface used by WTRUs 102a, 102b, and 102c can be characterized by multiple types of radio access technologies and / or transmissions to / from multiple types of base stations (e.g., eNBs and gNBs).

[0027] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), GSM Evolution Enhanced Data Rate (EDGE), GSM EDGE (GERAN), etc.

[0028] Figure 1A Base station 114b can be, for example, a wireless router, home Node B, home eNode B, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business premises, home, vehicle, campus, industrial facility, air corridor (e.g., for drone use), road, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. Figure 1A As shown, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may access Internet 110 without needing to go through CN 106 / 115.

[0029] RAN 104 / 113 can communicate with CN 106 / 115, which can be any network type configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU 102a, 102b, 102c, and 102d. Data may have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 can provide call control, billing services, mobile location services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication. Although Figure 1ANot shown, but it should be understood that RAN 104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs that use the same RAT as or a different RAT than RAN 104 / 113. For example, in addition to connecting to RAN 104 / 113, which may utilize NR radio technology, CN 106 / 115 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0030] CN 106 / 115 may also act as a gateway for WTRU 102a, 102b, 102c, 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol Suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 / 113 or a different RAT.

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

[0032] Figure 1B This is a system diagram illustrating an exemplary WTRU 102. (See diagram below.) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmitting / receiving element 122, a speaker / microphone 124, a keyboard 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138, etc. It should be understood that WTRU 102 may include any sub-combination of the foregoing units while remaining consistent with the embodiments.

[0033] Processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. Processor 118 may perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, and transceiver 120 may be coupled to transmitting / receiving element 122. Although Figure 1B The processor 118 and transceiver 120 are depicted as separate components, but it should be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0034] Transmitting / receiving element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via air interface 116. For example, in one embodiment, transmitting / receiving element 122 may be an antenna configured to transmit and / or receive radio front-end (RF) signals. In another embodiment, transmitting / receiving element 122 may be a transmitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In yet another embodiment, transmitting / receiving element 122 may be configured to transmit and / or receive both RF and optical signals. It should be understood that transmitting / receiving element 122 may be configured to transmit and / or receive any combination of wireless signals.

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

[0036] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 may have multi-mode capability. Therefore, transceiver 120 may include multiple transceivers to enable WTRU 102 to communicate via multiple RATs (e.g., NR and IEEE 802.11).

[0037] The processor 118 of WTRU 102 may be coupled to a speaker / microphone 124, a keyboard 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit) and may receive user input data therefrom. The processor 118 may also output user data to the speaker / microphone 124, keyboard 126, and / or display / touchpad 128. Furthermore, the processor 118 may access and store data in any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. 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. Removable memory 132 may include a user identity module (SIM) card, memory stick, secure digital storage (SD) card, etc. In other embodiments, the processor 118 may access and store data in memory that is not physically located on WTRU 102 (e.g., a server or home computer (not shown)).

[0038] The processor 118 may receive power from the power supply 134 and may be configured to distribute power to and / or control other components in the WTRU 102. The power supply 134 may be any suitable device for powering the WTRU 102. For example, the power supply 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, etc.

[0039] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that the WTRU 102 may acquire location information using any suitable location determination method while remaining consistent with the embodiments.

[0040] The processor 118 may be further coupled to other peripheral devices 138, which may include software and / or hardware modules providing one or more additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or videos), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral devices 138 may include one or more sensors, which may include one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors, geolocation sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

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

[0042] Figure 1C This is a system diagram illustrating RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with CN 106.

[0043] RAN 104 may include eNode-Bs 160a, 160b, and 160c, but it should be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. Each of eNode-Bs 160a, 160b, and 160c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Thus, for example, eNode-B 160a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a.

[0044] Each of the eNode-B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in the UL and / or DL, etc. Figure 1C As shown, eNode-B160a, 160b, and 160c can communicate with each other via the X2 interface.

[0045] Figure 1C The CN 106 shown 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 units is depicted as part of CN 106, it should be understood that any of these units may be owned and / or operated by an entity other than the CN operator.

[0046] The MME 162 can connect to each of the eNode-Bs 162a, 162b, and 162c in RAN 104 via the S1 interface and can act as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, and selecting specific service gateways during the initial attachment of WTRUs 102a, 102b, and 102c. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0047] The SGW 164 can connect to each of the eNode Bs 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 typically routes and forwards user data packets to / from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions, such as anchoring the user plane during inter-eNode B handover, triggering paging when downlink (DL) data is available for WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

[0048] SGW 164 can be connected to PGW 166, which can provide WTRU 102a, 102b, 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0049] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, and 102c with access to a circuit-switched network (e.g., PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and traditional wired communication equipment. For example, CN 106 may include or be able to communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server), which acts as an interface between CN 106 and PSTN 108. Furthermore, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0050] Despite WTRU in Figures 1A to 1D While described as a wireless terminal, it is envisioned that in some representative embodiments, such a terminal may use (e.g., temporarily or permanently) a wired communication interface with a communication network.

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

[0052] A WLAN in Basic Services Set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and from the BSS. Traffic from outside the BSS to a STA can be reached and delivered to the STA via the AP. Traffic from a STA to a destination outside the BSS can be sent to the AP for delivery to the corresponding destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be sent between source and destination STAs (e.g., directly between them) via Direct Link Establishment (DLS). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). WLANs using the Standalone BSS (IBSS) mode can function without access points (APs), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as the "ad-hoc" communication mode in this document.

[0053] When operating in 802.11ac infrastructure mode or a similar mode, the AP can transmit beacons on a fixed channel (e.g., the primary channel). The primary channel can be of fixed width (e.g., a 20 MHz bandwidth) or dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by STAs to establish connections with the AP. In some representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) can be implemented, for example in an 802.11 system. For CSMA / CA, STAs including the AP (e.g., each STA) can listen to the primary channel. If a particular STA listens / detects and / or determines that the primary channel is busy, that particular STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

[0054] High-throughput (HT) STAs can communicate using a 40MHz wide channel, for example, by combining a primary 20MHz channel with adjacent or non-adjacent 20MHz channels to form a 40MHz wide channel.

[0055] Very High Throughput (VHT) STAs support wide channels of 20MHz, 40MHz, 80MHz, and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining eight consecutive 20MHz channels, or by combining two non-consecutive 80MHz channels, which is referred to as an 80+80 configuration. For the 80+80 configuration, channel-coded data is delivered via a segmented parser that splits the data into two streams. Each stream can be individually processed using Inverse Fast Fourier Transform (IFFT) and time-domain processing. The streams can be mapped onto the two 80MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the merged data can be sent to Media Access Control (MAC).

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

[0057] WLAN systems supporting multiple channels and channel bandwidths (e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as the primary channel. The bandwidth of the primary channel can be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STAs operating in the BSS that support the minimum bandwidth operating mode. In the 802.11ah example, for STAs that support (e.g., only support) the 1MHz mode (e.g., MTC type devices), the primary channel can be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Assignment Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example because an STA (supporting only the 1MHz operating mode) is transmitting to the AP, the entire available band may be considered busy, even if most of the band is still idle and potentially available.

[0058] In the United States, the available frequency band for 802.11ah is from 902MHz to 928MHz. In South Korea, the available frequency band is from 917.5MHz to 923.5MHz. In Japan, the available frequency band is from 916.5MHz to 927.5MHz. The total available bandwidth for 802.11ah varies from 6MHz to 26MHz depending on the country code.

[0059] Figure 1D This is a system diagram illustrating RAN 113 and CN 115 according to an embodiment. As described above, RAN 113 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR radio technology. RAN 113 can also communicate with CN 115.

[0060] RAN 113 may include gNBs 180a, 180b, and 180c, but it should be understood that RAN 113 may include any number of gNBs while remaining consistent with the embodiments. Each of gNBs 180a, 180b, and 180c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may use beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Thus, for example, gNB 180a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In embodiments, gNBs 180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers (not shown) to WTRU 102a. A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In embodiments, gNBs 180a, 180b, and 180c can implement Coordinated Multipoint (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0061] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable parameter sets. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can differ for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using multiple or scalable length subframes or transmission time intervals (TTIs) (e.g., containing different numbers of OFDM symbols and / or varying absolute time lengths).

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

[0063] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slicing support, dual connectivity, interoperability between NR and E-UTRA, routing of user plane data to User Plane Functions (UPF) 184a and 184b, and routing of control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0064] Figure 1DThe CN 115 shown 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 units is depicted as part of the CN 115, it should be understood that any of these units may be owned and / or operated by an entity other than the CN operator.

[0065] AMF 182a and 182b can connect to one or more of gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can act as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling PDU sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating NAS signaling, mobility management, etc. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the service types being utilized by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services relying on Ultra Reliable Low Latency Communication (URLLC) access, services relying on Enhanced Massive Mobile Broadband (eMBB) access, and services for Machine Type Communication (MTC) access. The AMF162 provides control plane functionality for switching between RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies (such as WiFi).

[0066] SMF 183a and 183b can connect to AMF 182a and 182b in CN 115 via the N11 interface. SMF 183a and 183b can also connect to UPF 184a and 184b in CN 115 via the N4 interface. SMF 183a and 183b can select and control UPF 184a and 184b and configure service routes through UPF 184a and 184b. SMF 183a and 183b can perform other functions, such as managing and allocating WTRU IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0067] UPF 184a and 184b can be connected via the N3 interface to one or more of gNB 180a, 180b, and 180c in RAN 113, thereby providing WTRU 102a, 102b, and 102c with access to a packet-switched network (e.g., Internet 110) to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-destination PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

[0068] CN 115 can facilitate communication with other networks. For example, CN 115 may include or be able to communicate with an IP gateway (such as an IP Multimedia Subsystem (IMS) server), which acts as an interface between CN 115 and PSTN 108. Furthermore, CN 115 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRUs 102a, 102b, and 102c can be connected to local data networks (DNs) 185a and 185b via UPFs 184a and 184b through their N3 interfaces and the N6 interface between UPFs 184a and 184b and DNs 185a and 185b.

[0069] Given Figures 1A to 1D And to Figures 1A to 1D As described herein, one or more of the functions described herein, relating to one or more of the following: WTRU 102a to 102d, base stations 114a to 114b, eNode-B 160a to 160c, MME 162, SGW 164, PGW 166, gNB 180a to 180c, AMF 182a to 182ab, UPF 184a to 184b, SMF 183a to 183b, DN 185a to 185b, and / or any other equipment described herein, may be performed by one or more emulation devices (not shown). Emulation devices may be configured to emulate one or more devices that perform one or more of the functions described herein. For example, emulation devices may be used to test other equipment and / or simulate network and / or WTRU functions.

[0070] Simulation devices can be designed to perform one or more tests on other devices in laboratory and / or carrier network environments. For example, one or more simulation devices may perform one or more functions when fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. One or more simulation devices may perform one or more functions when temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices may be directly coupled to another device for testing purposes and / or may perform tests using over-the-air wireless communication.

[0071] One or more simulation devices may perform one or more (including all) functions when not implemented or deployed as part of a wired and / or wireless communication network. For example, simulation devices may be used in test scenarios within a test laboratory and / or an undeployed (e.g., under test) wired and / or wireless communication network to perform testing of one or more components. One or more simulation devices may be test devices. Simulation devices may transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas).

[0072] In wideband operation, the bandwidth configured for unlicensed spectrum on the sidelink can have multiple 20MHz subbands, each of which is called an RB set. When using wideband operation, the S-SSB can use one RB set or multiple RB sets (e.g., using repeated transmissions across different RB sets) for transmission.

[0073] If an S-SSB transmission is not configured as part of a resource pool and a COT initiated by a WTRU overlaps with an S-SSB slot, the COT may be lost if the Sync Ref WTRU does not transmit an S-SSB as part of the COT to maintain the initiated COT. Transmitting an S-SSB on all RB sets may not guarantee COT maintenance (S-SSB transmissions typically use LBT type 2, and the Sync Ref WTRU is usually near the COT initiator). Potential issues regarding using S-SSB transmissions to maintain COTs are envisioned. Another issue may arise from S-SSB transmissions being configured as part of a resource pool. This issue concerns how the sidelink (SL) WTRU determines which RB set is being used for S-SSB transmissions to combine multiple S-SSB transmissions.

[0074] A Sync Ref WTRU can be an SL Unlicensed (SL U) WTRU of a Transmitter-Side Link Synchronization Signal Block (S-SSB). An SL WTRU can be (pre-)configured with one or more rules to determine whether and / or when it becomes a Sync Ref WTRU.

[0075] SL U broadband can be bandwidth configured for sidelink transmission on unlicensed spectrum, which has multiple 20MHz subbands, each of which is called an RB set.

[0076] A Tx WTRU can be a sidelink WTRU that has sidelink data and / or control information to be transmitted on one or more sidelink channels.

[0077] LBT Type 1 can be a channel access type that requires listening to a random number of listening slots, where the random number can be selected from durations depending on the channel access priority using a uniform distribution. If the channel is listened to as idle, the transmitter can begin transmission.

[0078] LBT Type 2 can be a channel access type that requires listening for a fixed duration (16µs or 25µs) and begins transmission if the channel is determined to be idle. Another subtype of LBT Type 2 allows the transmitter to not listen to the channel at all and allows transmission without listening.

[0079] The Sync Ref WTRU can use one or more reserved SL resources to determine the RB set for SSB transmissions. For example, the Sync Ref WTRU can be configured to determine one or more reserved SL resources during a listening window. For example, the Sync Ref WTRU can monitor sidelink transmissions from one or more other WTRUs during a resource listening window. The Sync Ref WTRU can determine the RB set to be used for transmissions based on the reserved SL resources determined before and after the S-SSB time slot. An S-SSB time slot can include multiple RB sets. At least one of these RB sets can be configured as the default RB set. The Sync Ref WTRU can then maintain COT for other WTRUs.

[0080] A default RB set configuration can be used for S-SSB transmission. The Sync Ref WTRU can be configured to transmit S-SSBs over an SLU bandwidth consisting of multiple RB sets. For example, the bandwidth can consist of RB set 0, RB set 1, ..., RB set K. The Sync Ref WTRU can be configured to periodically transmit S-SSBs over a set of time slots (called S-SSB time slots). Within an S-SSB time slot, the Sync Ref WTRU can be configured to transmit S-SSBs over a default RB set, such as RB set 0. In this case, the Sync Ref WTRU always transmits S-SSBs at least over the default RB set; for example, the Sync Ref WTRU always uses RB set 0 to transmit S-SSBs in the S-SSB time slot. For example, the Sync Ref WTRU is configured to transmit S-SSBs over a bandwidth consisting of 5 RB sets, and the default RB set is RB set 0. In this example, the Sync Ref WTRU always transmits S-SSBs over RB set 0. In another example, the WTRU is configured with the default RB set for S-SSB as RB set 0 and RB set 1. In this example, the Sync Ref WTRU always transmits S-SSB on RB set 0 and RB set 1.

[0081] A Sync Ref WTRU can monitor one or more SLU transmissions. The WTRU can be configured to monitor side-link unlicensed transmissions, for example, after becoming a Sync Ref WTRU. A Sync Ref WTRU can begin monitoring side-link unlicensed transmissions during a resource listening window. This resource listening window can be determined based on the S-SSB slot configuration. A Sync Ref WTRU can be configured to monitor side-link unlicensed transmissions of length W. 侦听 One time slot / symbol and starting before S-SSB time slot transmission T 开始 Monitoring of unlicensed crosslink transmissions begins during resource window listening for each time slot / symbol. 侦听 and T 开始 Configuration can be done per resource pool and / or bandwidth portion. Additionally or alternatively, W 侦听 and T 开始 The value can depend on the Sync Ref WTRU capability. For example, some Sync Ref WTRUs with a first WTRU capability may have a longer T value than Sync Ref WTRUs with a second WTRU capability. 开始 .

[0082] The Sync Ref WTRU can use a resource listener window to determine one or more reserved SLU transmissions. The Sync Ref WTRU can be configured to determine reserved SLU resources by monitoring the resource listener window to decode Side Link Control Information (SCI) sent by a reserved WTRU (e.g., a WTRU that has reserved side link transmissions). For example, an SCI sent by another WTRU can indicate side link resources reserved for future side link transmissions. The Sync Ref WTRU determines reserved side link resources in all frequency resources of the broadband in the time slot preceding the S-SSB time slot, and reserved side link resources in all frequency resources of the broadband in the time slot following the S-SSB time slot. The Sync Ref WTRU can use the WTRU-ID indicated in the SCI or the WTRU-ID provided in a COT sharing information message that can be sent in the unlicensed side link spectrum to determine the WTRU-ID of the WTRU that has reserved side link resources in the time slot preceding and / or following the S-SSB time slot. Then, the Sync Ref WTRU can determine the RB set reserved for each reserved WTRU by determining the RB set to which the reserved resource belongs.

[0083] For each WTRU that has reserved sidelink resources up to the S-SSB time slot, the Sync Ref WTRU can check whether the same WTRU has also reserved sidelink resources after the S-SSB time slot. The Sync Ref WTRU can associate an RB set with a WTRU that has reserved unlicensed sidelink resources on that RB set. Alternatively, the Sync Ref WTRU can associate an RB set with one or more WTRUs that have reserved unlicensed sidelink resources on that RB set.

[0084] The Sync Ref WTRU can determine the RB set for S-SSB transmission based on one or more reserved SLU resources. For example, in addition to the default RB set, the Sync Ref WTRU can determine the RB set for S-SSB transmission based on reserved SLU resources before and / or after the S-SSB slot. In the example, the Sync Ref WTRU can use RB set #j from the pre-configured RB set from the broadband for S-SSB transmission in one or more of the following cases.

[0085] When at least N1 WTRUs reserve resources belonging to RB set #j before the S-SSB time slot, the Sync Ref WTRU can use RB set #j from the pre-configured RB set of the broadband for S-SSB transmission in the S-SSB time slot, where the value of N1 can be configured by the network. The value of N1 can be equal to 1. For example, at least one WTRU reserves resources belonging to RB set #j before the S-SSB time slot. When at least N2 WTRUs reserve resources belonging to RB set #j after the S-SSB time slot, the Sync Ref WTRU can use RB set #j from the pre-configured RB set of the broadband for S-SSB transmission in the S-SSB time slot, where the value of N2 can be configured by the network. The value of N2 can be equal to 1. For example, at least one WTRU reserves resources belonging to RB set #j after the S-SSB time slot. When at least N3 WTRUs reserve resources belonging to RB set #j before and after the S-SSB transmission, the Sync Ref WTRU can use RB set #j from the pre-configured RB set of the broadband for S-SSB transmission in the S-SSB slot, where the value of N can be configured by the network. The value of N3 can be equal to 1. For example, at least one WTRU reserves resources belonging to RB set #j before and after the S-SSB slot.

[0086] In the example, the Sync Ref WTRU can be configured to prioritize the reserved RB set for S-SSB transmission based on the priority associated with sidelink transmissions within the reserved RB set. The Sync Ref WTRU may not be able to use all determined RB sets for S-SSB transmission (e.g., the RB sets are not contiguous in the frequency domain, and the Sync Ref WTRU can only use contiguous RB sets for S-SSB transmission). If an RB set is reserved by the SL WTRU for high-priority transmission, the Sync Ref WTRU may select that RB set for S-SSB transmission.

[0087] In the example, the Sync Ref WTRU can be configured to transmit S-SSBs on the RB set based on the WTRU ID of the SL WTRU that has reserved sidelink resources on the RB set. For example, if the SL WTRU has reserved resources on the RB set and the reserved resources are intended for transmission to the Sync Ref WTRU (e.g., for multicast / broadcast transmission to the Sync Ref WTRU), then the Sync Ref WTRU can be restricted to transmitting S-SSBs on that RB set.

[0088] The Sync Ref WTRU determines the LBT type used for S-SSB transmissions on selected RB sets. After determining the RB sets to be used for S-SSB transmissions, the Sync Ref WTRU can select the LBT type (e.g., short or long LBT) for S-SSB transmissions using one or more RB sets. If the SLU WTRU has reserved sidelink resources within the RB set on the slot preceding the S-SSB slot (e.g., the Sync Ref WTRU shares a COT initiated from a WTRU that has reserved sidelink resources), the Sync Ref WTRU can select LBT type 2 (e.g., short LBT) for S-SSB transmissions on that RB set. The Sync Ref WTRU can further check whether the initiated COT allows for COT sharing. For example, if the S-SSB transmission is within the initiated COT, the Sync Ref WTRU can determine whether the maximum allowed duration of the COT will be exceeded. If the maximum COT duration will be exceeded, the Sync Ref WTRU can use LBT type 1 to transmit the S-SSB on one or more RB sets. If the SL U WTRU reserves sidelink resources in the RB set on a time slot following the S-SSB time slot, the Sync Ref WTRU can select LBT type 1 (e.g., long LBT) for S-SSB transmission on that RB set. When transmitting S-SSB on one or more RB sets, the Sync Ref WTRU can use different LBT types on different RB sets.

[0089] The Sync Ref WTRU may attempt to transmit the S-SSB on one or more of the selected RB sets. The Sync Ref WTRU may also attempt to transmit the S-SSB using the desired LBT type (e.g., short LBT or long LBT) on the selected RB sets. For example, the Sync Ref WTRU may use a short LBT (e.g., listening to the channel for a fixed duration to determine if the channel is idle) or a long LBT (e.g., continuously listening to the channel for a randomly selected number of listening slots, where the range of the random listening slots depends on the channel access priority). After determining that the channel is idle during the listening duration, the Sync Ref WTRU may transmit the S-SSB by repeatedly transmitting the S-SSB across the identified RB sets.

[0090] The Sync Ref WTRU can indicate to the WTRU the LBT type for reserved resources after the S-SSB slot. The Sync Ref WTRU can also indicate to the WTRU that has reserved sidelink resources after the S-SSB slot the LBT type to use when transmitting on the reserved resources after the S-SSB slot. If the Sync Ref WTRU successfully transmits the S-SSB on the determined RB set, the Sync Ref WTRU can instruct the WTRU that reserved the sidelink resources to use LBT type 2. The Sync Ref WTRU can use the Physical Sidelink Broadcast Channel (PSBCH), for example, to instruct the WTRU that reserved the sidelink resources to use type 2 LBT. Additionally or alternatively, the WTRU that reserved the sidelink resources can monitor S-SSB transmissions on one or more RB sets to determine whether an S-SSB has been transmitted.

[0091] Figure 2 This is a flowchart depicting an exemplary process 200 in which a Sync Ref WTRU uses reserved SL resources to determine the set of RBs for SSB transmission. The Sync Ref WTRU can be configured to determine sidelink reserved resources during the listening window. The Sync Ref WTRU can then determine the set of RBs to be used for transmission based on the reserved resources before and after the S-SSB time slot. The Sync Ref WTRU can then maintain COT for other WTRUs.

[0092] In section 210, the Sync Ref WTRU can be configured to transmit S-SSBs over a broadband network consisting of multiple RB sets (e.g., RB set 0, RB set 1, ..., RB set K). One of the RB sets can be configured as the default RB set (e.g., RB set 0). The Sync Ref WTRU can be configured to transmit S-SSBs on S-SSB slots (e.g., periodically transmitting S-SSBs on a set of slots). The Sync Ref WTRU can be further configured to always transmit on the default RB set (e.g., RB set 0) during S-SSB slots. In section 212, the Sync Ref WTRU can monitor one or more sidelink transmissions during a resource listening window.

[0093] At 214, the Sync Ref WTRU can determine the reserved sidelink resources before and / or after the S-SSB time slot. The Sync Ref WTRU can identify the WTRU that has reserved sidelink resources. If the sidelink resources are reserved before and / or after the S-SSB time slot, the Sync Ref WTRU can transmit the S-SSB only on the default RB set at 216. If the reserved sidelink resources are not before and / or after the S-SSB time slot, the Sync Ref WTRU can transmit the S-SSB on the default RB set and / or the RB set to which the reserved resources belong at 218. For example, in addition to the default RB set, if one or more WTRUs have reserved sidelink resources in RB set j on a time slot before the S-SSB time slot transmission, and / or one or more WTRUs have reserved sidelink resources in RB set j on a time slot after the S-SSB time slot transmission, the Sync Ref WTRU can attempt to transmit the S-SSB on RB set j. In section 220, the Sync Ref WTRU can determine the LBT type used for S-SSB transmissions on a given set of RBs. For example, the Sync Ref WTRU can determine whether to use type 1 or type 2 (e.g., long or short LBT) for S-SSB transmissions on a given set of RBs. The Sync Ref WTRU can transmit S-SSBs on the identified set of RBs using the determined LBT type. The Sync Ref WTRU can determine whether an S-SSB has been transmitted by monitoring S-SSB transmissions on one or more sets of RBs using an indicator PSBCH and / or by having a WTRU that has reserved sidelink resources after the S-SSB slot reserved, and instruct the WTRU that has reserved sidelink resources after the S-SSB slot reserved to use the LBT type for the reserved sidelink transmission.

[0094] A Tx WTRU can identify a Sync Ref WTRU and request an S-SSB transfer on one or more RB sets. The Sync Ref WTRU can indicate its WTRU ID. In the example, the Sync Ref WTRU can be configured to include its WTRUID in the PSBCH message. Alternatively or additionally, the Sync Ref WTRU can use a sequence of sidelink secondary synchronization signals (S-SSS) and / or sidelink primary synchronization signals (S-PSS) to indicate its WTRU ID. For example, an S-SSS / S-PSS sequence can be associated with the WTRU ID. Alternatively or additionally, the Sync Ref WTRU can use a PSBCH DMRS sequence to indicate its WTRU ID. For example, a PBSCH DMRS sequence can be associated with the WTRU ID.

[0095] A Tx WTRU can determine the WTRU ID of one or more Sync Ref WTRUs. For example, a Tx WTRU can be configured to monitor S-SSB transmissions to determine the WTRU ID of a Sync Ref WTRU. A Tx WTRU can monitor one or more Sync Ref WTRUs to determine their WTRU IDs. A Tx WTRU can be configured with a communication range within which it attempts to identify a Sync Ref WTRU. In some solutions, a Tx WTRU can be configured to use the WTRU ID included in the PSBCH message to identify a Sync Ref WTRU. Additionally or alternatively, a Tx WTRU can be configured to use an S-SSS / S-PSS sequence to identify a Sync Ref WTRU. For example, an S-SSS / S-PSS sequence can be associated with a WTRU ID. Additionally or alternatively, a Tx WTRU can be configured to use a PSBCH DMRS sequence to identify a Sync Ref WTRU. For example, a PSBCH DMRS sequence can be associated with a WTRU ID.

[0096] A Tx WTRU can initiate a COT (Content Override). For example, a Tx WTRU can determine the number of RB sets required for its data-side traversal transmission in the time slot preceding S-SSB time slot transmission. For instance, a Tx WTRU can be configured for wideband operation with 5 RB sets. Based on Tx WTRU traversal data transmission, the WTRU selects 3 RB sets for traversal data transmission. The Tx WTRU can initiate a COT on the selected RB sets using LBT type 1 to transmit traversal data transmission and traversal control information.

[0097] A Tx WTRU can initiate a COT that overlaps with an S-SSB time slot. When initiating a COT, the Tx WTRU can determine whether its COT overlaps with an S-SSB time slot. For example, a Tx WTRU can initiate a COT lasting M time slots on time slot n. The Tx WTRU can determine that time slot n+2 is configured for S-SSB transmission. After determining that its COT overlaps with an S-SSB time slot, the Tx WTRU can identify the set of RBs required for sidelink data transmission following the S-SSB time slot. For example, a Tx WTRU can initiate a COT on 3 RB sets on time slot n for sidelink data / control transmission. The Tx WTRU can stop transmission in time slot n+2 configured for S-SSB transmission and can determine that 2 RB sets will be needed for sidelink data / control transmission following the S-SSB time slot.

[0098] The Tx WTRU can identify one or more RB sets required after an S-SSB slot. For example, the Tx WTRU can determine the number of RB sets required for a sidelink data / control transmission after an S-SSB slot based on one or more of the following: the Tx WTRU's buffer status, the maximum allowed COT duration of the initiated COT, the number of S-SSB slots, the number of RB sets initiated, or the GAP duration between the end of the TxWTRU transmission and the start of the S-SSB slot. For example, the Tx WTRU can determine the number of RB sets required for a sidelink data / control transmission based on the buffer status and how much data should be transmitted, and / or if the WTRU has a large number of packets to transmit, the WTRU selects the required RB sets to transmit. If transmitting on an RB set after an S-SSB slot will not result in exceeding the maximum allowed COT duration, the Tx WTRU can determine that the RB set is needed for the sidelink data / control transmission. If transmitting that number of S-SSB slots will not result in exceeding the maximum allowed COT duration, the Tx WTRU can determine whether the RB set is needed for the sidelink data / control transmission. If the GAP duration between the end of a Tx WTRU transmission and the start of an S-SSB slot is less than a configured threshold within the RB set, then the RB set can be selected.

[0099] A Tx WTRU can select a Sync Ref WTRU to transmit S-SSB slots on multiple RB sets. After identifying the RB sets required for side link data / control transmissions following the S-SSB slots, the Tx WTRU can request the Sync Ref WTRU to transmit S-SSBs on the identified RB sets. The Tx WTRU can select a Sync Ref WTRU from the identified Sync Ref WTRUs based on one or more of the following: The Tx WTRU can select the Sync Ref WTRU with the highest S-SSB reference signal received power (RSRP), for example, when the Tx WTRU selects the Sync Ref WTRU with the highest received S-SSB RSRP from the identified Sync Ref WTRUs. The Tx WTRU can select a Sync Ref WTRU whose WTRU ID is within the pre-configured WTRU ID range, for example, when the Tx WTRU selects a Sync Ref WTRU whose WTRU ID belongs to the configured WTRU ID list from the identified Sync Ref WTRUs. A Tx WTRU can be selected as a Sync Ref WTRU for unicast communication with another Tx WTRU, for example, when the Tx WTRU selects from the identified Sync Ref WTRUs that is transmitting unicast data to the Tx WTRU. Additionally or alternatively, the Tx WTRU can select from the identified Sync Ref WTRUs that is receiving unicast data from the Tx WTRU. A Tx WTRU can also be selected as a Sync Ref WTRU for multicast / broadcast communication with another Tx WTRU, for example, when the Tx WTRU selects from the identified Sync Ref WTRUs that has an ID for transmitting multicast transmissions to the Tx WTRU. Additionally or alternatively, the Tx WTRU can select from the identified Sync Ref WTRUs that has an ID for receiving multicast transmissions from the Tx WTRU.

[0100] A Tx WTRU can instruct a selected Sync Ref WTRU to transmit S-SSB slots across multiple RB sets. A TX WTRU can instruct a selected Sync Ref WTRU to specify the RB sets within the S-SSB slots used for S-SSB transmission. If the Tx WTRU selects a Sync Ref WTRU that is the target WTRU for unicast / multicast / broadcast transmission within the initiating COT, the Tx WTRU can use SCI to instruct the Sync Ref WTRU to specify the RB sets required for S-SSB transmission to maintain the initiating COT. If the Tx WTRU selects a Sync Ref WTRU that is not the target WTRU for unicast / multicast / broadcast transmission within the initiating COT, the Tx WTRU can use broadcast COT sharing information to instruct the Sync Ref WTRU to specify the RB sets required for S-SSB transmission to maintain the initiating COT. This instruction can be a bitmap of size equal to the number of RB sets within the bandwidth, with a value of 1 used to request S-SSB transmission within the RB sets.

[0101] A Tx WTRU can resume transmission on multiple RB sets after an S-SSB transmission. A Tx WTRU can resume sidelink data / control transmission using an initiated COT after an S-SSB transmission on multiple RB sets. A Tx WTRU can monitor S-SSB transmissions on multiple RB sets within an S-SSB time slot to determine if the Sync Ref WTRU actually transmitted on the requested RB set. A Tx WTRU can resume an initiated COT using LBT Type 2 after an S-SSB transmission. A Tx WTRU can select the LBT Type 2 subtype based on the gap between the S-SSB transmission and the start position of the Tx WTRU transmission.

[0102] Figure 3 An exemplary procedure is described for a Tx WTRU to initiate a COT on two RB sets overlapping with the S-SSB time slot. Figure 3 In this configuration, a Tx WTRU can be configured with bandwidth having three RB sets: RB set 0, RB set 1, and RB set 2. The Tx WTRU can initiate a Coordinating Occurrence (COT) for sidelink data transmission using RB sets 0 and RB sets 1 in time slot 0. The Tx WTRU can select a Sync Ref WTRU and instruct the selected Sync Ref WTRU to transmit S-SSBs on RB sets 0 and RB sets 1. The Tx WTRU can use COT after the S-SSB transmission on RB sets 0 and RB sets 1.

[0103] Figure 4 An exemplary process 400 is described, in which a Tx WTRU identifies a Sync Ref WTRU and requests an S-SSB transfer on multiple RB sets. (e.g.) Figure 4As shown, the Tx WTRU identifies the Sync Ref WTRU and requests an S-SSB transmission on multiple RB sets. The WTRU identifies the adjacent Sync Ref WTRU transmitting an S-SSB in the SL-U. The WTRU then requests the identified Sync Ref WTRU to transmit the S-SSB on one or more RB sets within the COT initiated by the WTRU. After the S-SSB transmission, the WTRU uses LBT type 2 to transmit the SL data on one or more RB sets used for the S-SSB transmission.

[0104] A Sync Ref WTRU may include a Sync Ref WTRU ID in an S-SSB transmission (e.g., using an explicit indication in the PSBCH and / or using an S-SSS / S-PSS / PSBCH-DMRS sequence associated with the WTRU ID). A Tx WTRU may monitor S-SSB transmissions within a configured frequency range and may determine the WTRU ID of one or more Sync Ref WTRUs, as in 410. For example, a Tx WTRU may receive acknowledgment information indicating the frequency range and the WTRU ID of one or more Sync Ref WTRUs. In 412, a Tx WTRU may initiate a COT on one or more RB sets, for example, using LBT type 1 to transmit sidelink data transmissions and / or sidelink control transmissions. The Tx WTRU may determine that the COT overlaps with an S-SSB time slot and that sidelink transmissions are still required after the S-SSB time slot. The Tx WTRU may identify the RB sets required for transmissions after the S-SSB time slot.

[0105] In section 414, the Tx WTRU can select a Sync Ref WTRU. The Tx WTRU can instruct the Sync Ref WTRU to transmit S-SSB on multiple RB sets. For example, the Tx WTRU can select a Sync Ref WTRU based on the following criteria: the Sync Ref WTRU with the highest S-SSB RSRP, the Sync Ref WTRU whose WTRU ID is within the pre-configured WTRU ID range, the Sync Ref WTRU that is a party to unicast communication with the Tx WTRU, and / or the Sync Ref WTRU that is a party to multicast / broadcast communication with the Tx WTRU. The Tx WTRU can instruct the selected Sync Ref WTRU, if the Tx WTRU determines that the Sync Ref WTRU is the "target WTRU" for the expected unicast / multicast / broadcast transmission in the COT, that the WTRU can use the SCI to instruct the Sync Ref WTRU to use the RB set for S-SSB transmission. If the Tx WTRU determines that the Sync Ref WTRU is not the "target WTRU", the Tx WTRU can use broadcast COT sharing information to request the Sync Ref WTRU to transmit S-SSB on multiple RB sets. In section 416, the Tx WTRU can transmit sidelink data transmissions after an S-SSB transmission. For example, the Tx WTRU can use LBT type 2 to transmit SL data transmissions on one or more RB sets used for S-SSB transmissions.

[0106] A Sync Ref WTRU can indicate one or more sets of Restricted Block Controllers (RBs) used for S-SSB transmission. For example, the S-SSB RB set configuration of a Sync Ref WTRU can identify coverage levels. In the example, the Sync Ref WTRU can be configured with different coverage requirement levels. A coverage requirement level can be a communication range target (e.g., distance from the Sync Ref WTRU) with a Block Error Rate (BLER) value. For each coverage requirement level, the Sync Ref WTRU can use certain resources during the S-SSB slot to transmit the S-SSB to meet the coverage requirement level. The Sync Ref WTRU can be configured with a number of RB sets for S-SSB transmission corresponding to the coverage requirement level.

[0107] The S-SSB RB set configuration of the Sync Ref WTRU identifies the synchronization source. For example, the Sync Ref WTRU can be configured with an association between the synchronization source and the number of RB sets used for S-SSB transmission. For each synchronization source, the number of RB sets used for S-SSB transmission can be configured; for example, when using the other side's link WTRU as the synchronization source, the Sync Ref WTRU should use a first number of RB sets for S-SSB transmission. When using a gNB as the synchronization source, the Sync Ref WTRU can use a second number of RB sets for S-SSB transmission. When using GNSS as the synchronization source, the Sync Ref WTRU can use a third number of RB sets for S-SSB transmission.

[0108] The Sync Ref WTRU determines the set of RB sets used for S-SSB transmissions. The Sync Ref WTRU can be configured to determine the RB sets used for S-SSB transmissions in wideband operations based on one or more factors. For example, the coverage requirements for S-SSB transmissions (e.g., coverage requirement levels). For instance, the Sync Ref WTRU can be configured with multiple coverage requirement levels, where each coverage requirement level can be associated with the number of RB sets used for S-SSB transmissions within an S-SSB time slot. Such configurations can be indicated using SIB information. In an exemplary solution, the Sync Ref WTRU can be configured for wideband operations with 3 RB sets and configured with 3 coverage levels. A first coverage level can be associated with S-SSB transmissions using one RB set, a second coverage level can be associated with S-SSB transmissions using two RB sets, and a third coverage level can be associated with S-SSB transmissions using three RB sets. Based on the coverage level operated by the Sync Ref WTRU, it determines the number of RB sets used for S-SSB transmissions. The Sync Ref WTRU determines the coverage level based on V2X service requirements. For example, a Sync Ref WTRU may have a V2X service that requires higher coverage and another V2X service for short-range communication.

[0109] The synchronization source of a Sync Ref WTRU, such as a Sync Ref WTRU using a gNB as its synchronization source, can be configured to transmit S-SSBs using all RB sets of the broadband. In another example, a Sync Ref WTRU using GNSS as its synchronization source can be configured to transmit S-SSBs using only one RB set of the broadband. The Sync Ref WTRU can be configured with an association between the synchronization source and the number of RB sets used for S-SSB transmission within the S-SSB time slot. Furthermore, RB sets reserved by other WTRUs for sidelink data / control transmissions can also be part of the configuration. If the sidelink data transmission priority is higher than a configured threshold, S-SSBs may not be transmitted on that RB set. Otherwise, S-SSBs may be transmitted on that RB set. The Sync Ref WTRU can determine data transmission priority based on sidelink control information (SCI) sent by other WTRUs. As a further example, the congestion level of the RB set can be included; for example, if the Sync Ref WTRU determines that an RB set may be congested, the Sync Ref WTRU will not use that RB set for S-SSB transmission. Furthermore, it may include the number of SL U WTRUs using the RB set, for example, if the Sync Ref WTRU determines that X SLWTRUs use the RB set, then the Sync Ref WTRU transmits S-SSB on that RB set.

[0110] The Sync Ref WTRU can use one or more pre-determined RB sets to transmit the S-SSB. The Sync Ref WTRU may attempt to transmit the S-SSB using the desired LBT type (e.g., short LBT or long LBT) on the selected RB sets. For example, the Sync Ref WTRU may use a short LBT (e.g., listening to the channel for a fixed duration to determine if the channel is idle) or a long LBT (e.g., continuously listening to the channel for a randomly selected number of listening slots, where the range of the random listening slots depends on the channel access priority). After determining that the channel is idle during the listening duration, the Sync Ref WTRU can transmit the S-SSB by repeatedly transmitting the S-SSB across the identified RB sets.

[0111] The Sync Ref WTRU can indicate the set of RBs used for S-SSB transmission to the SL WTRU. In one solution, the Sync Ref WTRU can be configured to use side-link control information (SCI) to indicate the set of RBs used for S-SSB transmission within the S-SSB time slot. This indication can be a bitmap of size equal to the number of RBs within the bandwidth. In another solution, the Sync Ref WTRU can be configured to use the Physical Side-Link Broadcast Channel (PSBCH) to indicate the set of RBs used for S-SSB transmission within the S-SSB time slot. This indication can be a bitmap of size equal to the number of RBs within the bandwidth. Additionally or alternatively, the Sync Ref WTRU can use an S-SSS / S-PSS sequence / PSBCH-DMRS sequence to indicate the set of RBs used for S-SSB transmission within the S-SSB time slot. Sync Ref WTRU uses S-SSS / P-SSS sequences / PSBCH DMRS sequences associated with S-SSB transmissions on a set of RB sets. The association between such RB sets and the S-SSS / P-SSS sequences / PSBCH DMRS sequences can be fixed in the specification.

[0112] Figure 5 An exemplary process 500 is depicted in which a Sync Ref WTRU indicates one or more RB sets used for transmitting an S-SSB. In this example, the Sync Ref WTRU may indicate one or more RB sets used for transmitting an S-SSB. The Sync Ref WTRU may receive a request to transmit an S-SSB on multiple RB sets. The Sync Ref WTRU determines the RB sets used for the S-SSB and indicates the set of RB sets to be used for S-SSB transmission to the SL WTRU. This enables the SL WTRU to receive the RB sets for the S-SSB and combine transmissions from different RB sets.

[0113] In 510, the Sync Ref WTRU can be configured with an association between the number of RB sets used for S-SSB transmission and coverage requirements and / or the synchronization source used to obtain timing. In 512, the Sync Ref WTRU can determine the RB sets used for S-SSB transmission based on the following factors: (1) the coverage requirements for S-SSB transmission; (2) the synchronization source of the Sync Ref WTRU (e.g., a Sync Ref WTRU using a gNB as a synchronization resource can be configured to transmit S-SSB on multiple RB sets); (3) the buffer status of the Sync Ref WTRU; (4) the RB sets reserved by other WTRUs for sidelink data / control transmissions; (5) the congestion level of the RB sets; and / or (6) the number of SLU WTRUs using the RB sets. If the sidelink data transmission priority is higher than the configured threshold, S-SSB may not be transmitted on the RB sets, or S-SSB may be transmitted on the RB sets.

[0114] In 514, the Sync Ref WTRU may use a selected, specific set of RBs to transmit S-SSB. In 516, the Sync Ref WTRU may use one or more of the following to indicate to the SL WTRU the set of RBs to be used for S-SSB: (a) using an SCI to indicate the set of RBs used for S-SSB; (b) using a PSBCH to indicate the set of RBs used for S-SSB; and / or (c) using an implicit indication based on the S-SSS / S-PSS sequence / PSBCH-DMRS sequence. The Sync Ref WTRU may use the S-SSS / P-SSS sequence / PSBCH-DMRS sequence associated with the S-SSB transmission on a set of RBs.

[0115] The following is a list of abbreviations that may be used throughout the application.

[0116] ACK: Confirmation BLER: Block Error Rate BWP: Bandwidth section CAP: Channel Access Priority CAPC: Channel Access Priority Category CCA: Free Channel Assessment CCE: Control Channel Element CE: Control Element CG: Configuration authorization or cell group CP: Cyclic prefix CP-OFDM: Traditional OFDM (depending on the cyclic prefix) CQI: Channel Quality Indicator CRC: Cyclic Redundancy Check CSI: Channel State Information CW: Competition Window CWS: Competition Window Size CO: Channel Occupancy DAI: Downlink Allocation Index DCI: Downlink Control Information DFI: Downlink Feedback Information DG: Dynamic Licensing DL: Downlink DM-RS: Demodulation Reference Signal DRB: Data Radio Bearer eLAA: Enhanced Authorized Access Assistance FeLAA: Further Enhanced Authorized Assisted Access HARQ: Hybrid Automatic Repeat Request LAA: Authorized Assisted Access LBT: Listen first, then speak LTE: Long Term Evolution, such as from 3GPP LTE R8 and above NACK: Negative Acknowledgment MCS: Modulation and Coding Scheme MIMO: Multiple Input Multiple Output NR: New Radio OFDM: Orthogonal Frequency Division Multiplexing PHY: Physical Layer PID: Process ID PO: Paging Timing PRACH: Physical Random Access Channel PSBCH: Physical Side Link Broadcast Channel PSS: Master Synchronization Signal RA: Random Access (or Procedure) RACH: Random Access Channel RAR: Random Access Response RCU: Central Unit of Radio Access Network RF: Radio front end RLF: Radio link failure RLM: Wireless Link Monitoring RNTI: Wireless Network Identifier RO: RACH timing RRC: Radio Resource Control RRM: Wireless Resource Management RS: Reference signal RSRP: Reference Signal Received Power RSSI: Received Signal Strength Indicator SDU: Service Data Unit SRS: Detection Reference Signal SS: Synchronization signal SSS: Secondary Synchronization Signal SWG: Exchange Gap (in a self-contained subframe) SPS: Semi-persistent scheduling SUL: Supplemental Uplink TB: Transport Block TBS: Transport Block Size TRP: Transmit / Receive Point TSC: Time-Sensitive Communication TSN: Time-Sensitive Networking UL: Uplink URLLC: Ultra-Reliable Low-Latency Communication WBWP: Wideband Portion WLAN: Wireless Local Area Network and related technologies (IEEE 802.xx domain)

Claims

1. A wireless transmit / receive unit (WTRU) including a processor configured to: Monitor side link transmissions from one or more other WTRUs during the resource listening window; Based on the sidelink transmissions monitored during the resource listening window, reserved sidelink resources are determined before or after the sidelink synchronization signal block (S-SSB) time slot, wherein the S-SSB time slot includes multiple RB sets, and at least one of the multiple RB sets is configured as the default RB set. Identify one or more other WTRUs that have reserved the reserved side link resources; Based on the one or more other WTRUs that have reserved the reserved side crosslink resources in the time slots before and after the S-SSB time slot, at least one RB set other than the default RB set is determined; and Based on at least one of the other WTRUs that has reserved the reserved side link resources in a time slot before or after the S-SSB time slot, the S-SSB information is transmitted on at least one RB set outside the default RB set.

2. The WTRU of claim 1, wherein the processor is configured to determine the at least one RB set other than the default RB set based on a priority associated with the reserved side link resources before or after the S-SSB time slot.

3. The WTRU of claim 2, wherein the processor is configured to determine the priority associated with the reserved sidelink resources before or after the S-SSB slot based on sidelink control information (SCI) sent by the one or more other WTRUs that have reserved the reserved sidelink resources.

4. The WTRU of claim 1, wherein the processor is configured to determine the Listen-Before-Speak (LBT) type for the S-SSB transmission performed on at least one RB set other than the default RB set.

5. The WTRU of claim 4, wherein the LBT type is a long LBT type or a short LBT type.

6. The WTRU of claim 1, wherein the processor is configured to send a Listen-Before-Speak (LBT) type instruction to the one or more other WTRUs for use in reserved sidelink transmissions.

7. The WTRU of claim 6, wherein the indication to the other WTRU is made by indicating the Physical Side Link Broadcast Channel (PSBCH).

8. The WTRU of claim 1, wherein the processor is configured to monitor the sidelink transmission during the resource listening window to decode sidelink control information (SCI) sent by the one or more other WTRUs that have reserved the reserved sidelink resources.

9. The WTRU of claim 8, wherein the SCI indicates the reserved side link resources before or after the S-SSB time slot.

10. The WTRU of claim 8, wherein the processor is configured to: Based on the SCI, identify the identification information of one or more other WTRUs that have reserved the reserved side crosslink resources in the time slots before and after the S-SSB time slot; and Based on the identification information of one or more other WTRUs that have reserved the reserved side link resources in the time slots before and after the S-SSB time slot, the at least one RB set other than the default RB set is determined.

11. A method comprising: Monitor side link transmissions from one or more other WTRUs during the resource listening window; Based on the sidelink transmissions monitored during the resource listening window, reserved sidelink resources are determined before or after the sidelink synchronization signal block (S-SSB) time slot, wherein the S-SSB time slot includes multiple RB sets, and at least one of the multiple RB sets is configured as the default RB set. Identify one or more other WTRUs that have reserved the reserved side link resources; Based on the one or more other WTRUs that have reserved the reserved side crosslink resources in the time slots before and after the S-SSB time slot, at least one RB set other than the default RB set is determined; and Based on at least one of the other WTRUs that has reserved the reserved side link resources in a time slot before or after the S-SSB time slot, the S-SSB information is transmitted on at least one RB set outside the default RB set.

12. The method of claim 11, further comprising: The at least one RB set other than the default RB set is determined based on the priority associated with the reserved side link resources before or after the S-SSB time slot.

13. The method of claim 12, further comprising: The priority associated with the reserved sidelink resources before or after the S-SSB slot is determined based on the sidelink control information (SCI) sent by one or more other WTRUs that have reserved the reserved sidelink resources.

14. The method of claim 11, further comprising: Determine the Listen-Before-Speak (LBT) type for the S-SSB transmission performed on at least one RB set other than the default RB set.

15. The method of claim 14, wherein the LBT type is a long LBT type or a short LBT type.

16. The method of claim 11, further comprising: Send a Listen-Before-Speak (LBT) type instruction to one or more other WTRUs for use in the reserved side link transmission.

17. The method of claim 16, wherein the indication to the other WTRU is made by indicating the Physical Side Link Broadcast Channel (PSBCH).

18. The method of claim 11, further comprising: During the resource listening window, the sidelink transmissions are monitored to decode the sidelink control information (SCI) sent by the one or more other WTRUs that have reserved the reserved sidelink resources.

19. The method of claim 18, wherein the SCI indicates the reserved side link resources before or after the S-SSB time slot.

20. The method of claim 18, further comprising: Based on the SCI, identify the identification information of one or more other WTRUs that have reserved the reserved side crosslink resources in the time slots before and after the S-SSB time slot; and Based on the identification information of one or more other WTRUs that have reserved the reserved side link resources in the time slots before and after the S-SSB time slot, the at least one RB set other than the default RB set is determined.

Images