Indicating relative location and sidelink synchronization signal identifier for user equipment

Abstract

Various aspects of the present disclosure generally relate to wireless communications. In some aspects, a user equipment (UE), such as a roadside unit (RSU), located in an area with limited or no global navigation satellite system (GNSS) coverage may cycle sidelink synchronization signal (SLSS) neighbor information, such as in the form of an SLSS neighbor list (SNL). The SLSS neighbor information may include one or more of an index number, an SLSS identifier (ID), a timing source in-coverage flag, an RSU ID, a hop ID, a geographic location, a transmit synchronization offset, a synchronization source, and / or a coordinated world time (UTC) time.

Description

Cross Reference to Related Applications

[0001] This patent application claims priority to U.S. Patent Application No. 18 / 467,266, filed September 14, 2023, entitled “INDICATING RELATIVE POSITION AND SIDELINK SYNCHRONIZATION SIGNAL IDENTIFIER OF USER EQUIPMENT,” and assigned to the assignee hereof. The disclosure of the prior application is considered part of and is incorporated by reference into this patent application. TECHNICAL FIELD

[0002] Aspects of the present disclosure relate generally to wireless communication and more specifically to techniques and apparatuses for indicating relative position and sidelink synchronization signal identifier of user equipment. BACKGROUND

[0003] Wireless communication systems are widely deployed to provide various telecommunication services such as telephony, video, data, messaging, and broadcasts. Typical wireless communication systems can employ multiple-access technologies capable of supporting communication with multiple users by sharing available system resources (e.g., bandwidth or transmit power). Examples of such multiple-access technologies include code division multiple access (CDMA) systems, time division multiple access (TDMA) systems, frequency division multiple access (FDMA) systems, orthogonal frequency division multiple access (OFDMA) systems, single-carrier frequency division multiple access (SC-FDMA) systems, time division synchronous code division multiple access (TD-SCDMA) systems, and long term evolution (LTE). LTE / LTE-Advanced is a set of enhancements to the Universal Mobile Telecommunications System (UMTS) mobile standard promulgated by the Third Generation Partnership Project (3 GPP).

[0004] The above multiple access technologies have been adopted in various telecommunication standards to provide common protocols to communicate over the air interfaces. New Radio (NR), which can be referred to as 5G, is a set of enhancements to the LTE mobile standard promulgated by 3GPP. NR is designed to better support mobile broadband Internet access by improving spectral efficiency, lowering costs, improving services, making use of new spectrum, and better integrating with other open standards using OFDM with a cyclic prefix (CP) (CP-OFDM) on the downlink (DL), using CP-OFDM or discrete Fourier transform spread OFDM (DFT-s-OFDM) on the uplink (UL) (a.k.a. single carrier frequency division multiple access (SC-FDMA)), and supporting beamforming, multiple input multiple output (MIMO) antenna technology, and carrier aggregation. As the demand for mobile broadband access continues to increase, further improvements in LTE, NR, and other radio access technologies remain useful.

[0005] A deadlock scenario can occur when user equipment (UE) in a sidelink synchronization signal (SLSS) synchronization mode synchronizes with one or more other UEs, and none of the synchronized UEs are synchronized to a global navigation satellite system (GNSS) for timing. For example, a roadside unit (RSU) in an area without GNSS coverage (e.g., a tunnel) can malfunction, preventing the RSU from forwarding GNSS synchronization information to other RSUs in the area. As a result, the other RSUs can synchronize to each other for frame timing, drifting away from GNSS synchronization over time. Further, when cellular vehicle-to-everything (C-V2X) devices are in the SLSS synchronization mode in GNSS-blocked areas, the C-V2X devices can not obtain coordinated universal time (UTC) over the air (OTA). Further, a UE can perform SLSS muting, which can involve the UE stopping transmission of SLSS at certain times to attempt to decode SLSS signals from other synchronization sources. Additionally, the UE can not connect to the best (e.g., closest) RSU synchronization source in an area without GNSS coverage. SUMMARY

[0006] Some aspects described herein relate to an apparatus for wireless communication at a user equipment (UE). The apparatus can include one or more memories storing processor executable code and one or more processors coupled with the one or more memories. At least one of the one or more processors can be configured to cause the UE to receive a first indication including at least a sidelink synchronization signal (SLSS) identifier associated with a neighboring UE of the UE and an indication of a relative positioning of the neighboring UE within a plurality of UEs. At least one of the one or more processors can be configured to cause the UE to transmit a second indication including at least a SLSS identifier associated with the UE and an indication of a relative positioning of the UE within the plurality of UEs.

[0007] Some aspects described herein relate to a method of wireless communication performed at a UE. The method can include receiving a first indication including at least a SLSS identifier associated with a neighboring UE of the UE and an indication of a relative positioning of the neighboring UE within a plurality of UEs. The method can include transmitting a second indication including at least a SLSS identifier associated with the UE and an indication of a relative positioning of the UE within the plurality of UEs.

[0008] Some aspects described herein relate to a non-transitory computer-readable medium storing a set of instructions for wireless communication. The set of instructions can include one or more instructions. The one or more instructions, when executed by one or more processors of a UE, can cause the UE to receive a first indication including at least a SLSS identifier associated with a neighboring UE of the UE and an indication of a relative positioning of the neighboring UE within a plurality of UEs. The one or more instructions, when executed by the one or more processors of the UE, can cause the UE to transmit a second indication including at least a SLSS identifier associated with the UE and an indication of a relative positioning of the UE within the plurality of UEs.

[0009] Some aspects described herein relate to an apparatus for wireless communication. The apparatus can include means for receiving a first indication including at least a SLSS identifier associated with a neighboring apparatus of the apparatus and an indication of a relative positioning of the neighboring apparatus within a plurality of apparatuses. The apparatus can include means for transmitting a second indication including at least a SLSS identifier associated with the apparatus and an indication of a relative positioning of the apparatus within the plurality of apparatuses.

[0010] Aspects generally include a method, apparatus, system, computer program product, non-transitory computer-readable medium, user equipment, base station, network node, network entity, wireless communication device, or processing system as substantially described with reference to the drawings, as well as as illustrated in the drawings and described previously in the written description.

[0011] The foregoing has outlined rather broadly the features and technical advantages of examples according to the disclosure in order that the detailed description that follows can be better understood. Additional features and advantages will be described hereinafter. The disclosed concepts and specific examples can be readily utilized as bases for modifying or designing other structures for carrying out the same purposes of the present disclosure. Such equivalent constructions do not depart from the scope of the appended claims. The present characteristics of the concepts disclosed herein, both organizational and operational, together with the associated advantages, will be better understood from the following description when considered in connection with the accompanying drawings. Each of the figures is provided for the purpose of illustration and description, and is not intended as a definition of the limits of the claims. BRIEF DESCRIPTION OF DRAWINGS

[0012] So that the above-recited features of the present disclosure can be understood in detail, a more particular description, which aspects refer to some of the aspects illustrated in the appended drawings, will be provided. It is to be noted, however, that the appended drawings illustrate only some typical aspects of the present disclosure and are therefore not to be considered limiting of its scope, as the description can admit to other equally effective aspects. The same reference numerals in different drawings can identify the same or similar elements.

[0013] Figure 1 is a diagram illustrating an example of a wireless network, in accordance with the present disclosure.

[0014] Figure 2 is a diagram illustrating an example of a network node communicating with a user equipment (UE) in a wireless network, in accordance with the present disclosure.

[0015] Figure 3 is a diagram illustrating an example of a device with sidelink synchronization signal (SLSS) capability, in accordance with the present disclosure.

[0016] Figure 4 is a diagram illustrating an example of SLSS propagation in a daisy chain, in accordance with the present disclosure.

[0017] Figure 5 is a diagram illustrating an example of a deadlock scenario, in accordance with the present disclosure.

[0018] Figure 6 is a diagram illustrating an example of synchronization source selection, in accordance with the present disclosure.

[0019] Figure 7 is a diagram illustrating an example of indicating a relative positioning of a UE associated with an SLSS identifier, in accordance with the present disclosure.

[0020] Figure 8 is a diagram illustrating an example of initializing a sidelink neighbor list (SNL) by propagating SNL information across systems, in accordance with the present disclosure.

[0021] Figure 9 This is a diagram illustrating an example of how SNL information is propagated across systems when SNL is in a stable state, according to this disclosure.

[0022] Figure 10 This is a diagram illustrating an example of deadlock mitigation according to this disclosure.

[0023] Figure 11 These are illustrations illustrating examples associated with specific cloud-based implementations according to this disclosure.

[0024] Figure 12 This is a diagram illustrating an example of how a hop identifier is associated with determining a UE according to this disclosure.

[0025] Figure 13 This is a diagram illustrating an example of using jump identifiers to mitigate deadlock according to this disclosure.

[0026] Figure 14 This is a diagram illustrating an example of SLSS propagation in a daisy chain using jump identifiers, according to this disclosure.

[0027] Figure 15 This is a diagram illustrating an example of a deadlock scenario involving a jump identifier according to this disclosure.

[0028] Figure 16 This is a diagram illustrating a continuation of an example of a deadlock scenario involving a jump identifier according to this disclosure.

[0029] Figure 17 This is a diagram illustrating a further example of a deadlock scenario involving a jump identifier according to this disclosure.

[0030] Figure 18 This is a diagram illustrating an example of the selection of a synchronization source according to this disclosure.

[0031] Figure 19 This is a flowchart illustrating an example procedure performed by a UE, for example, to support instruct the UE on its relative positioning and SLSS identifier, according to this disclosure.

[0032] Figure 20 This is a diagram of an example device for wireless communication that supports the relative positioning of the UE and the SLSS identifier according to this disclosure. Detailed Implementation

[0033] Various aspects of this disclosure are described more fully below with reference to the accompanying drawings. However, this disclosure may be embodied in many different forms and should not be construed as limited to any particular structure or function presented throughout this disclosure. Rather, these aspects are provided so that this disclosure will be comprehensive and complete, and will fully convey the scope of protection of this disclosure to those skilled in the art. Those skilled in the art will appreciate that the scope of this disclosure is intended to cover any aspect of this disclosure disclosed herein, whether implemented independently of or in combination with any other aspect of this disclosure. For example, any number of aspects set forth herein may be used to implement an apparatus or practice. Furthermore, the scope of this disclosure is intended to cover such apparatuses or methods implemented using structures, functionalities, or structures and functionalities other than or different from the various aspects of the disclosure set forth herein. Any aspect of this disclosure disclosed herein may be embodied by one or more elements of the claims.

[0034] Several aspects of a telecommunications system will now be presented with reference to various devices and techniques. These devices and techniques will be described in detail below and illustrated in the accompanying drawings by various boxes, modules, components, circuits, steps, processes, or algorithms (collectively, “elements”). These elements may be implemented using hardware, software, or a combination of hardware and software. Whether such elements are implemented as hardware or software depends on the specific application and the design constraints imposed on the system as a whole.

[0035] The lack of Global Navigation Satellite System (GNSS) coverage can lead to deadlock scenarios, inaccurate Coordinated Universal Time (UTC), sidelink synchronization signal (SLSS) silence, and / or connection to suboptimal roadside units (RSUs). Deadlock scenarios can occur when UEs in SLSS synchronization mode are synchronized with each other, but none of these synchronized UEs are synchronized with GNSS for timing. For example, an RSU in an area without GNSS coverage (e.g., a tunnel) may malfunction, preventing it from forwarding GNSS synchronization information to other RSUs in the area. Consequently, other RSUs may synchronize with each other for frame timing, drifting away from GNSS synchronization over time. Furthermore, when a cellular vehicle-to-everything (C-V2X) device is in SLSS synchronization mode in a GNSS-blocked area, the C-V2X device may be unable to obtain Coordinated Universal Time (UTC) from the air (OTA). Additionally, user equipment (UEs) can perform SLSS silence, which may involve the UE stopping SLSS transmission at certain times to attempt to decode SLSS signals from other synchronization sources. Additionally, the UE may not connect to the optimal (e.g., nearest) RSU synchronization source in an area without GNSS coverage.

[0036] Various aspects generally relate to timing synchronization (e.g., using SLSS). Some aspects are more specifically related to timing synchronization in C-V2X implementations with limited or no GNSS coverage. In some aspects, multiple UEs, such as RSUs, located in areas with limited or no GNSS coverage may circulate SLSS neighbor information, such as in the form of an SLSS Neighbor List (SNL). SLSS neighbor information may include one or more of the following: index number, SLSS identifier (ID), timing source coverage flag, RSU ID, hop ID, geographic location, transmission synchronization offset (e.g., synchronization offset for SLSS transmission, such as SLSS synchronization offset), synchronization source, and / or UTC time.

[0037] In some aspects, the UE may receive a first indication that includes an SLSS ID associated with a neighboring UE (e.g., a neighboring RSU). In some examples, the first indication may also include an indication of time (e.g., UTC time) such as the time when the neighboring UE generated the first indication. In some examples, the first indication may also include a transmission synchronization offset associated with the neighboring UE. In some examples, the first indication may also include an indication of the relative location of the neighboring UE among multiple UEs. For example, the indication of relative location may include the hop ID of the neighboring UE. The UE may receive the first indication from a neighboring UE or from the cloud or network.

[0038] The UE may send a second indication, which includes at least an SLSS identifier associated with the UE and an indication of the UE's relative location among multiple UEs. In some examples, the second indication may also include an indication of time (e.g., UTC time), such as the time the UE generated the second indication. In some examples, the second indication may also include a transmission synchronization offset associated with the UE. In some examples, the second indication may also include an indication of the UE's relative location among multiple UEs. For example, the indication of relative location may include the UE's hop ID. The UE may send the second indication to another neighboring UE or to the cloud or network.

[0039] Specific aspects of the subject matter described in this disclosure can be implemented to achieve one or more of the following potential advantages. In some examples, by receiving a first indication (e.g., a first SNL) and / or sending a second indication (e.g., a second SNL), the described techniques can be used to resolve deadlock scenarios by enabling the UE to determine whether it is in a deadlock scenario (e.g., based on whether the SNL contains SLSS ID 0). For example, an indication of the relative positioning of the UE, including the UE's hop ID, can help prevent UEs from synchronizing with each other without a link to the GNSS-synchronized UE, and thus avoid deadlock.

[0040] The first and / or second indications, including a time indication (e.g., UTC time), can address UTC timing issues by enabling the UE to identify UTC time. The first and / or second indications, including a transmission synchronization offset indication, can address SLSS silencing issues by enabling the UE to identify overlapping SLSS transmissions (e.g., based on SLSS ID, transmission synchronization offset, etc.) without attempting to measure signals from neighboring UEs. The first and / or second indications, including a relative positioning indication, can address issues related to the UE not being connected to the nearest synchronization source by enabling the UE to identify (e.g., based on RSU ID, location, etc.) which RSU is closest to or will be closest to the UE. For example, an indication of the UE's relative positioning, including the UE's hop ID, can assist the UE in selecting the SLSS synchronization source with the smallest timing offset.

[0041] Receiving the first instruction from the cloud or network can help reduce the time between transmissions of the first instruction, because the UE can receive the untruncated SNL from the cloud. Furthermore, sending the second instruction to the cloud or network enables the cloud or network to send the SNL message to the mobile UE. For example, a vehicle can download the SNL from the cloud or network before entering an area with limited or no GNSS coverage (e.g., a tunnel).

[0042] Figure 1 This is a diagram illustrating an example of a wireless network according to the present disclosure. Wireless network 100 may be a 5G (e.g., NR) network or a 4G (e.g., LTE) network, or may include elements of a 5G (e.g., NR) network or elements of a 4G (e.g., LTE) network, etc. Wireless network 100 may include one or more network nodes 110 (shown as network node (NN) 110a, network node 110b, network node 110c, and network node 110d), one UE 120 or more UEs 120 (shown as UE 120a, UE 120b, UE 120c, UE 120d, and UE 120e), and / or other network entities. Network node 110 is the entity that communicates with UE 120. As shown, network node 110 may include one or more network nodes. For example, network node 110 can be an aggregated network node, meaning that the aggregated network node is configured to utilize a radio protocol stack that is physically or logically integrated within a single RAN node (e.g., within a single device or unit). As another example, network node 110 can be a decomposed network node (sometimes referred to as a decomposed base station), meaning that network node 110 is configured to utilize a protocol stack that is physically or logically distributed among two or more nodes (such as one or more central units (CUs), one or more distributed units (DUs), or one or more radio units (RUs)).

[0043] In some examples, network node 110 is or includes network nodes (such as RUs) that communicate with UE 120 via a radio access link. In some examples, network node 110 is or includes network nodes (such as DUs) that communicate with other network nodes 110 via a fronthaul or midhaul link. In some examples, network node 110 is or includes network nodes (such as CUs) that communicate with other network nodes 110 via a midhaul link or with the core network via a backhaul link. In some examples, network node 110 (such as aggregated network node 110 or decomposed network node 110) may include multiple network nodes, such as one or more RUs, one or more CUs, or one or more DUs. Network node 110 may include, for example, NR network nodes, LTE network nodes, Node Bs, eNBs (e.g., in 4G), gNBs (e.g., in 5G), access points or transmit / receive points (TRPs), DUs, RUs, CUs, network mobility elements, core network nodes, network elements, network equipment, and / or RAN nodes. In some examples, network nodes 110 can interconnect with each other or to one or more other network nodes 110 in wireless network 100 using any suitable transport network through various types of fronthaul, midhaul, or backhaul interfaces (such as direct physical connections, air interfaces, or virtual networks).

[0044] Each network node 110 can provide communication coverage for a specific geographic area. In the 3rd Generation Partnership Project (3GPP), depending on the context in which the term is used, the term "cell" can refer to the coverage area of ​​network node 110 or a network node subsystem serving that coverage area.

[0045] Network node 110 can provide communication coverage for macrocells, picocells, femtocells, or another type of cell. A macrocell can cover a relatively large geographic area (e.g., a radius of several kilometers) and allows unrestricted access by UE 120 with a service subscription. A picocell can cover a relatively small geographic area and allows unrestricted access by UE 120 with a service subscription. A femtocell can cover a relatively small geographic area (e.g., a residential area) and allows restricted access by UE 120 associated with that femtocell (e.g., UE 120 in a Closed Subscriber Group (CSG)). Network node 110 for macrocells may be referred to as a macro network node. Network node 110 for picocells may be referred to as a pico network node. Network node 110 for femtocells may be referred to as a femto network node or a home network node.

[0046] Wireless network 100 can be a heterogeneous network, comprising different types of network nodes 110, such as macro network nodes, pico network nodes, femto network nodes, or relay network nodes. These different types of network nodes 110 may have different transmit power levels, different coverage areas, or different effects on interference within wireless network 100. For example, macro network nodes may have high transmit power levels (e.g., 5 watts to 40 watts), while pico network nodes, femto network nodes, and relay network nodes may have lower transmit power levels (e.g., 0.1 watts to 2 watts). Figure 1 In the example shown, network node 110a can be a macro network node for macro cell 102a, network node 110b can be a pico network node for pico cell 102b, and network node 110c can be a femto network node for femto cell 102c. Network nodes can support one or more (e.g., three) cells. In some examples, the cells may not necessarily be stationary, and the geographical area of ​​the cells may move depending on the location of the mobile network node 110 (e.g., a mobile network node).

[0047] In some aspects, the term "base station" or "network node" may refer to an aggregated base station, a decomposed base station, an integrated access and backhaul (IAB) node, a relay node, or one or more components thereof. For example, in some aspects, "base station" or "network node" may refer to a CU, DU, RU, a near real-time (near RT) RAN intelligent controller (RIC), and / or a non-real-time (non-RT) RIC. In some aspects, the term "base station" or "network node" may refer to a device configured to perform one or more functions (such as those described herein in conjunction with network node 110). In some aspects, the term "base station" or "network node" may refer to multiple devices configured to perform one or more functions. For example, in some distributed systems, each of multiple different devices (which may be located in the same geographical location or different geographical locations) may be configured to perform at least a portion of a function, or to repeatedly perform at least a portion of that function, and the term "base station" or "network node" may refer to any one or more of these different devices. In some aspects, the term "base station" or "network node" may refer to one or more virtual base stations or one or more virtual base station functions. For example, in some aspects, two or more base station functions can be instantiated on a single device. In some aspects, the term "base station" or "network node" may refer to one base station function rather than another. Thus, a single device can include more than one base station.

[0048] Network controller 130 may be coupled to or communicate with a group of network nodes 110, and may provide coordination and control for these network nodes 110. Network controller 130 may communicate with network nodes 110 via a backhaul communication link. Network nodes 110 may also communicate directly with each other, or indirectly via a wireless or wired backhaul communication link. In some aspects, network controller 130 may be a CU or a core network device, or network controller 130 may include a CU or a core network device.

[0049] In some examples, the cell may not necessarily be stationary, and the geographical area of ​​the cell may move depending on the location of the mobile network node 110 (e.g., a mobile network node). In some examples, network nodes 110 may interconnect with each other or with one or more other network nodes 110 or network nodes (not shown) in the wireless network 100 using any suitable transport network via various types of backhaul interfaces (such as direct physical connections or virtual networks).

[0050] Wireless network 100 may include one or more relay stations. A relay station is an entity that can receive data transmissions from an upstream station (e.g., network node 110 or UE 120) and transmit data transmissions to a downstream station (e.g., UE 120 or network node 110). A relay station may be a UE 120 that can relay transmissions for other UE 120s. Figure 1 In the example shown, network node 110d (e.g., a relay network node) can communicate with network node 110a (e.g., a macro network node) and UE 120d to facilitate communication between network node 110a and UE 120d. The network node 110 that relays communication may be referred to as a relay station, relay network node, or relay.

[0051] UE 120 may be distributed throughout the wireless network 100, and each UE 120 may be stationary or mobile. UE 120 may include, for example, an access terminal, a terminal, a mobile station, or a subscriber unit. UE 120 may be a cellular phone (e.g., a smartphone), a personal digital assistant (PDA), a wireless modem, a wireless communication device, a handheld device, a laptop computer, a cordless phone, a wireless local loop (WLL) station, a tablet device, a camera, a gaming device, a netbook, a smartbook, an ultrabook, a medical device, a biometric device, a wearable device (e.g., a smartwatch, smart clothing, smart glasses, a smart wristband, smart jewelry (e.g., a smart ring or smart bracelet)), an entertainment device (e.g., a music device, a video device, or a satellite radio), a vehicle component or sensor, a smart meter / sensor, industrial manufacturing equipment, a GPS device, a UE function of a network node, or any other suitable device configured to communicate via a wireless medium.

[0052] Some UEs 120 may be considered Machine-Type Communication (MTC) or Evolved or Enhanced Machine-Type Communication (eMTC) UEs. MTC or eMTC UEs may include, for example, robots, drones, remote devices, sensors, meters, monitors, or location tags that can communicate with network nodes, another device (e.g., a remote device), or some other entity. Some UEs 120 may be considered Internet of Things (IoT) devices or may be implemented as NB-IoT (Narrowband IoT) devices. Some UEs 120 may be considered customer premises equipment. UEs 120 may be included within a housing that houses the components of the UE 120, such as processor components or memory components. In some examples, the processor components and memory components may be coupled together. For example, the processor components (e.g., one or more processors) and memory components (e.g., memory) may be operatively coupled, communicatively coupled, electronically coupled, or electrically coupled.

[0053] Generally, any number of wireless networks 100 can be deployed in a given geographical area. Each wireless network 100 may support a specific RAT and may operate on one or more frequencies. A RAT may also be referred to as a radio technology or air interface. A frequency may also be referred to as a carrier or frequency channel. Each frequency in a given geographical area may support a single RAT to avoid interference between wireless networks using different RATs. In some examples, NR or 5G RAT networks may be deployed.

[0054] In some examples, two or more UEs 120 (e.g., shown as UE 120a and UE 120e) may communicate directly using one or more sidelink channels (e.g., without using network node 110 as an intermediary for communication with each other). For example, UE 120 may communicate using peer-to-peer (P2P) communication, device-to-device (D2D) communication, vehicle-to-everything (V2X) protocols (e.g., which may include vehicle-to-vehicle (V2V) protocols, vehicle-to-infrastructure (V2I) protocols, or vehicle-to-pedestrian (V2P) protocols), or mesh networks. In such examples, UE 120 may perform scheduling operations, resource selection operations, or other operations described elsewhere herein as being performed by network node 110.

[0055] Devices in Wireless Network 100 can communicate using the electromagnetic spectrum, which can be subdivided into various categories, bands, or channels by frequency or wavelength. For example, devices in Wireless Network 100 can communicate using one or more operating bands. In 5G NR, two initial operating bands have been designated as frequency ranges FR1 (410MHz to 7.125GHz) and FR2 (24.25GHz to 52.6GHz). Although a portion of FR1 is greater than 6GHz, FR1 is generally (interchangeably) referred to as the “sub-6GHz” band in various documents and articles. Similar naming issues sometimes arise with FR2, although it is different from the Very High Frequency (EHF) band (30GHz to 300GHz) designated as the “millimeter wave” band by the International Telecommunication Union (ITU), FR2 is generally (interchangeably) referred to as the “millimeter wave” band in various documents and articles.

[0056] The frequencies between FR1 and FR2 are generally referred to as mid-band frequencies. Recent 5G NR studies have designated the operating bands for these mid-band frequencies as the frequency range designation FR3 (7.125 GHz to 24.25 GHz). Bands falling within FR3 can inherit FR1 or FR2 characteristics, thus effectively extending the features of FR1 or FR2 into the mid-band frequencies. Additionally, higher frequency bands are currently being explored to extend 5G NR operation beyond 52.6 GHz. For example, three higher operating frequency bands have been designated as the frequency range designations FR4a or FR4-1 (52.6 GHz to 71 GHz), FR4 (52.6 GHz to 114.25 GHz), and FR5 (114.25 GHz to 300 GHz). Each of these higher frequency bands falls within the EHF band.

[0057] Considering the examples above, unless otherwise specifically stated, the term "below 6 GHz" as used herein can broadly refer to frequencies less than 6 GHz, within FR1, or including intermediate frequency band frequencies. Furthermore, unless otherwise specifically stated, the term "millimeter wave" as used herein can broadly refer to frequencies that can include intermediate frequency band frequencies, within FR2, FR4, FR4-a, FR4-1, or FR5, or within the EHF band. It is conceivable that the frequencies included in these operating bands (e.g., FR1, FR2, FR3, FR4, FR4-a, FR4-1, or FR5) can be modified, and the techniques described herein are applicable to those modified frequency ranges.

[0058] In some aspects, UE 120 may include a communication manager 140. As described in more detail elsewhere herein, the communication manager 140 may receive a first instruction that includes at least an SLSS identifier associated with a neighboring UE of UE 120 and an indication of the relative position of the neighboring UE among a plurality of UEs; and transmit a second instruction that includes at least an SLSS identifier associated with UE 120 and an indication of the relative position of UE 120 among a plurality of UEs. Additionally or alternatively, the communication manager 140 may perform one or more other operations described herein.

[0059] Figure 2 This is a diagram illustrating communication between an example network node and a UE in a wireless network according to this disclosure. The network node may correspond to... Figure 1 Network node 110. Similarly, the UE can correspond to Figure 1 UE 120. Network node 110 may be equipped with a set of antennas 234a to 234t, such as T One antenna ( T ≥1). The UE 120 may be equipped with a set of antennas 252a to 252r, such as R One antenna ( R ≥1). Figure 2 The network node 110 depicted includes one or more radio frequency components, such as antenna 234 and modem 232. In some examples, network node 110 may include an interface, communication components, or another component facilitating communication with UE 120 or another network node. Some network nodes 110 may not include radio frequency components facilitating direct communication with UE 120, such as one or more CUs or one or more DUs.

[0060] At network node 110, transmitting processor 220 can receive data from data source 212 intended for use by UE 120 (or a group of UEs 120). Transmitting processor 220 can select one or more modulation and decoding schemes (MCS) for UE 120 based at least in part on one or more channel quality indicators (CQIs) received from UE 120. Network node 110 can process (e.g., encode and modulate) the data for UE 120 based at least in part on the MCS selected for UE 120 and can provide data symbols for UE 120. Transmitting processor 220 can process system information (e.g., semi-static resource partitioning information (SRPI)) and control information (e.g., CQI requests, grants, or upper-layer signaling) and provide overhead symbols and control symbols. Transmitting processor 220 can generate reference symbols for reference signals (e.g., cell-specific reference signals (CRS) or demodulation reference signals (DMRS)) and synchronization signals (e.g., primary synchronization signal (PSS) or secondary synchronization signal (SSS)). The transmit (TX) multiple-input multiple-output (MIMO) processor 230 can perform spatial processing (e.g., pre-decoding) on ​​data symbols, control symbols, overhead symbols, or reference symbols (if applicable), and can direct to a corresponding set of modems 232 shown as modems 232a to 232t (e.g., T A set of output symbol streams (e.g., modems) is provided by a modem. T Each output symbol stream can be provided to a modulator component (shown as MOD) of modem 232. Each modem 232 can use a corresponding modulator component to process the corresponding output symbol stream (e.g., for OFDM) to obtain an output sample stream. Each modem 232 can also use a corresponding modulator component to process (e.g., convert to analog, amplify, filter, or upconvert) the output sample stream to obtain a downlink signal. Modems 232a to 232t can be connected via a corresponding set of antennas 234 (e.g., T Each antenna (shown as antennas 234a to 234t) is used to transmit a set of downlink signals (e.g., T (One downlink signal).

[0061] At UE 120, the set of antennas 252 (shown as antennas 252a to 252r) can receive downlink signals from network node 110 or other network nodes 110, and can transmit signals to the set of modems 254 (e.g., R Each modem (shown as modems 254a to 254r) provides a set of received signals (e.g., REach received signal may be provided to a demodulator component (shown as DEMOD) of modem 254. Each modem 254 may use a corresponding demodulator component to condition (e.g., filter, amplify, down-convert, or digitize) the received signal to obtain an input sample. Each modem 254 may use a demodulator component to further process the input sample (e.g., for OFDM) to obtain a received symbol. MIMO detector 256 may obtain the received symbols from modem 254, perform MIMO detection on the received symbols where applicable, and provide the detected symbols. Receiver processor 258 may process (e.g., demodulate and decode) the detected symbols, provide the decoded data for UE 120 to data sink 260, and provide the decoded control information and system information to controller / processor 280. The term "controller / processor" may refer to one or more controllers and / or one or more processors. The channel processor may determine Reference Signal Received Power (RSRP) parameters, Received Signal Strength Indicator (RSSI) parameters, Reference Signal Received Quality (RSRQ) parameters, or CQI parameters, etc. In some examples, one or more components of UE 120 may be included in housing 284.

[0062] Network controller 130 may include communication unit 294, controller / processor 290, and memory 292. Network controller 130 may include one or more devices, such as those in a core network. Network controller 130 may communicate with network node 110 via communication unit 294.

[0063] One or more antennas (e.g., antennas 234a to 234t or antennas 252a to 252r) may include or be included in the following: one or more antenna panels, one or more antenna groups, one or more collections of antenna elements, or one or more antenna arrays, etc. Antenna panels, antenna groups, collections of antenna elements, or antenna arrays may include one or more antenna elements (within a single housing or multiple housings), a collection of coplanar antenna elements, a collection of non-coplanar antenna elements, or coupled to one or more transmitting or receiving components (such as...). Figure 2 One or more antenna elements (one or more components).

[0064] On the uplink, at UE 120, transmit processor 264 can receive and process data from data source 262 and control information (e.g., for reports including RSRP, RSSI, RSRQ, or CQI) from controller / processor 280. Transmit processor 264 can generate reference symbols for one or more reference signals. Symbols from transmit processor 264 may be pre-decoded by TX MIMO processor 266 where applicable, further processed by modem 254 (e.g., for DFT-s-OFDM or CP-OFDM), and transmitted to network node 110. In some examples, modem 254 of UE 120 may include a modulator and demodulator. In some examples, UE 120 includes a transceiver. The transceiver may include any combination of antenna 252, modem 254, MIMO detector 256, receive processor 258, transmit processor 264, or TX MIMO processor 266. The transceiver may be used by a processor (e.g., controller / processor 280) and memory 282 to perform aspects of any of the methods described herein.

[0065] At network node 110, uplink signals from UE 120 or other UEs may be received by antenna 234, processed by modem 232 (e.g., demodulator component of modem 232, shown as DEMOD), detected by MIMO detector 236 where applicable, and further processed by receiver processor 238 to obtain decoded data and control information transmitted via UE 120. Receiver processor 238 may provide the decoded data to data sink 239 and the decoded control information to controller / processor 240. Network node 110 may include communication unit 244 and may communicate with network controller 130 via communication unit 244. Network node 110 may include scheduler 246 to schedule one or more UEs 120 for downlink or uplink communication. In some examples, modem 232 of network node 110 may include modulator and demodulator. In some examples, network node 110 includes transceiver. The transceiver may include any combination of antenna 234, modem 232, MIMO detector 236, receive processor 238, transmit processor 220, or TX MIMO processor 230. The transceiver may be used by a processor (e.g., controller / processor 240) and memory 242 to perform aspects of any of the methods described herein.

[0066] The controller / processor 240 of network node 110, the controller / processor 280 of UE 120, or Figure 2Any other component may perform one or more techniques associated with indicative of the UE's relative positioning and SLSS ID, as described in more detail elsewhere herein. For example, the controller / processor 240 of network node 110, the controller / processor 280 of UE 120, or... Figure 2 Any other component can execute or direct, for example Figure 19 The operation of process 1900 or other processes as described herein. Memory 242 and memory 282 may store data and program code for network node 110 and UE 120, respectively. In some examples, memory 242 or memory 282 may include a non-transitory computer-readable medium storing one or more instructions (e.g., code or program code) for wireless communication. For example, one or more instructions may cause one or more processors, UE 120, or network node 110 to perform or direct, for example, when executed by one or more processors of network node 110 or UE 120 (e.g., directly, or after compilation, transformation, or interpretation). Figure 19 The process 1900 or other processes as described herein may be used. In some examples, execution instructions may include run instructions, translation instructions, compilation instructions, or interpretation instructions, etc. In some embodiments, one or more of a plurality of memories may be configured to store processor-executable code that, when executed, may configure the one or more processors to perform the various functions described herein (as part of a processing system). In some other embodiments, the processing system may be pre-configured to perform the various functions described herein.

[0067] In some aspects, UE 120 includes components for receiving a first indication, which includes at least an SLSS identifier associated with a neighboring UE of UE 120 and an indication of the relative position of the neighboring UE among a plurality of UEs; and / or components for transmitting a second indication, which includes at least an SLSS identifier associated with UE 120 and an indication of the relative position of UE 120 among a plurality of UEs. Components for UE 120 to perform the operations described herein may include, for example, one or more of the following: communication manager 140, antenna 252, modem 254, MIMO detector 256, receive processor 258, transmit processor 264, TX MIMO processor 266, controller / processor 280, or memory 282.

[0068] Communication systems (such as 5G NR systems) can be deployed in various ways with a variety of components or parts. In a 5G NR system or network, network nodes, network entities, network mobility elements, RAN nodes, core network nodes, network elements, base stations, or network equipment can be implemented in a converged or decomposed architecture. For example, a base station (such as a Node B (NB), evolved NB (eNB), NR base station, 5G NB, access point (AP), TRP, or cell, etc.) or one or more units (or components) performing base station functions can be implemented as a converged base station (also known as a standalone base station or monolithic base station) or a decomposed base station. A "network entity" or "network node" can refer to a decomposed base station or one or more units of a decomposed base station (such as one or more CUs, one or more DUs, and / or one or more RUs).

[0069] Aggregated base stations (e.g., aggregated network nodes) can be configured to utilize a radio protocol stack that is physically or logically integrated within a single RAN node (e.g., within a single device or cell). Decomposed base stations (e.g., decomposed network nodes) can be configured to utilize a protocol stack that is physically or logically distributed across two or more cells (such as one or more CUs, one or more DUs, or one or more RUs). In some examples, the CU may be implemented within a network node, and one or more DUs may be co-located with the CU, or alternatively, may be geographically or virtually distributed across one or more other network nodes. DUs may be implemented to communicate with one or more RUs. Each of the CU, DU, and RU may also be implemented as a virtual cell, such as a Virtual Central Unit (VCU), a Virtual Distributed Unit (VDU), or a Virtual Radio Unit (VRU), etc.

[0070] Base station type operation or network design can take into account the aggregation characteristics of base station functionality. For example, decomposed base stations can be utilized in IAB networks, Open Radio Access Networks (O-RAN (such as network configurations initiated by the O-RAN Alliance)), or Virtualized Radio Access Networks (vRAN, also known as Cloud Radio Access Networks (C-RAN)) to facilitate the scaling of communication systems by separating base station functionality into one or more units that can be deployed independently. Decomposed base stations can include functionality implemented across two or more units at various physical locations, as well as functionality virtually implemented for at least one unit, which enables flexibility in network design. Each unit of a decomposed base station can be configured for wired or wireless communication with at least one other unit of the decomposed base station.

[0071] Figure 3 This is an illustration of example 300 of a device with SLSS capability according to the present disclosure.

[0072] GNSS can be used as the primary synchronization source in C-V2X implementations. However, in some locations, such as tunnels and parking garages, there is no GNSS coverage. In the absence of GNSS coverage, SLSS can be used to maintain C-V2X frame timing and keep the C-V2X implementation operational. For example, equipment with SLSS capability can be deployed as an RSU in areas without GNSS coverage.

[0073] When SLSS is used for timing in C-V2X Mode 4, there are three unique SLSSIDs that can be derived from the DMRS sequence: SLSS ID 0, which can correspond to a device using GNSS as a synchronization source; SLSS ID 168, which can correspond to a device configured for two SLSS offset indicators and not within GNSS coverage; and SLSS ID 169, which can correspond to a device configured for three SLSS offset indicators and not within GNSS coverage.

[0074] SLSS ID 0 can be exclusive, while SLSS IDs 168 or 169 can be used by all other SLSS transmitting devices in a given system. For example, Figure 3 The RSU AG is shown, where each RSU can be configured to send SLSS. Because the RSU DG uses the same SLSS ID and in-coverage flag state (“INC-false”), the UE may not be able to identify the source of the SLSS.

[0075] Therefore, all RSUs after the fourth hop (e.g., RSU D) have the same synchronization source priority, allowing it to be determined which SLSS the UE (e.g., vehicle UE) should use. Furthermore, the SLSS receiving device (e.g., vehicle UE) may not be able to determine which SLSS source to use for timing. Priorities can be assigned to the received SLSS based on the source used for GNSS-based synchronization, as follows: P0: GNSS P1: UEs directly synchronized with GNSS (e.g., RSUs) P2: UE indirectly synchronized with GNSS P6: Remaining UE, which may have the lowest priority. P7: UE internal clock Table 1 below indicates the priority of attribute assignment based on SLSS source.

[0076] Table 1 Although Figure 3The deployment scenarios depicted in the other figures described herein involve two SLSS offsets, but the techniques described herein can be additionally or alternatively applied to deployment scenarios involving three SLSS offsets.

[0077] Figure 4 This is a diagram illustrating example 400 of SLSS propagation in a daisy chain according to this disclosure.

[0078] like Figure 4 As shown, the RSU deep within the tunnel (e.g., RSU G) can be time-synchronized with the rest of the system (e.g., RSU AF and GNSS). The arrows pointing from left to right represent target propagation of the SLSS, and the arrows pointing from right to left represent leakage from adjacent SLSS sources (e.g., unwanted reception of the SLSS).

[0079] Table 2 below shows the SLSS sources that can be decoded on a given UE. For example, Table 2 shows the decoded SLSS sources for each RSU ID, which may correspond to the SLSS receiving UE. Table 2 also shows the identifiers of the decoded SLSSs. For example, the identifier may be the SLSS ID and the SyncOffset subframe of the decoded SLSS, which may correspond to the offset.

[0080] Table 2 Therefore, based on the above combination Figure 3 The priority discussed starts with RSU C, where all decoded SLSS sources have the same priority. When multiple SLSS sources have the same SLSS priority, RSRP can be the sole criterion for determining the SLSS source. Since the RSU receives and transmits SLSS sources, and C-V2X is a half-duplex technology, the UE can receive SLSS at one SLSS offset and transmit it at another SLSS offset.

[0081] Figure 5 This is an example diagram illustrating a deadlock scenario 500 according to this disclosure.

[0082] In Example 500, RSU D can be turned off. Table 3 below shows the decoded SLSSs received by the UE from adjacent SLSSs when RSU D is off. For example, Table 3 shows the source of decoded SLSSs for each RSU ID in the event of a deadlock, which may correspond to the SLSS receiving the UE.

[0083] Table 3 RSU E can initially use RSU F as its timing synchronization source because RSU-F is RSU E's only SLSS source. Therefore, RSU E, RSU F, and RSU G synchronize with each other for frame timing, leading to a timing synchronization deadlock. Over time, RSU-G drifts away from the GNSS-synchronized RSU (e.g., RSU AC) for timing synchronization. The drift may become large enough that when RSU D returns to online, RSU E cannot detect and synchronize with RSU D. This lack of synchronization relative to RSU EG can then cause problems for the Onboard Unit (OBU), depending on the timing provided by the RSU for sending messages (e.g., Basic Safety Messages (BSM)). For example, an OBU synchronized with RSU C will not be able to interoperate with an OBU synchronized with RSU EG, creating a potentially dangerous situation for the driver.

[0084] A UE (e.g., any RSU in RSU EG) may not be able to determine whether the timing source is derived from a GNSS-connected UE (e.g., RSU A). Furthermore, a UE may not be able to determine whether it has entered a deadlock scenario.

[0085] Furthermore, when a C-V2X device is in SLSS synchronization mode in a GNSS-blocked area, it may not be able to obtain UTC time from OTA. However, the ITS stack may require millisecond-level timing accuracy to generate messages. Without UTC time, the ITS stack may not be able to generate messages with millisecond-level timing accuracy. For example, when a device performs a cold start in a location without Wireless Wide Area Network (WWAN) or GNSS coverage (such as a parking garage), the device may not be able to obtain UTC time. Additionally, when a device moves from an area with GNSS coverage to an area without GNSS coverage, the GNSS engine can use the Dead Reckoning (DR) system to continue maintaining the system clock, but not for an extended period. For example, the time accuracy will decrease over time (e.g., the DR time will drift from UTC time).

[0086] Furthermore, when an SLSS device is using one offset for SLSS reception, it can use another offset for SLSS transmission. For example, a UE (e.g., RSU) transmitting SLSS in a subframe may not be able to decode any SLSS signals. Therefore, the UE may not be able to decode SLSS signals from a synchronization source with a higher priority than the current synchronization source and / or from a synchronization source with a stronger priority than the current synchronization source. The UE can perform SLSS silencing, by which the UE stops transmitting SLSS at certain times to attempt to decode SLSS signals from other synchronization sources; however, SLSS silencing may result in dropped SLSS transmissions.

[0087] Figure 6 This is a diagram illustrating example 600 of the synchronization source selection according to this disclosure.

[0088] The OBU can select the SLSS source based on the RSRP. However, in some examples, the OBU can decode multiple SLSS sources with similar RSRPs. For instance, an OBU driven by two RSUs can detect similar RSRPs from one RSU, but one RSU can have a higher timing offset (TO) than the other. Figure 6 As shown, the OBU cannot distinguish the RSRP corresponding to RSU D and RSU E. Therefore, the OBU can choose RSU E as the SLSS source, even if RSU E is associated with a TO higher than RSU D based on the OBU's direction of travel (or will soon be associated with a TO higher than RSU D).

[0089] Furthermore, the RSU (e.g., the receiving SLSS UE) can select a UE farther from the GNSS for synchronization with a UE closer to the GNSS, depending on channel conditions and deployment. For example, if the RSRPs of the farther and closer UEs are indistinguishable, the RSU can select the farther UE. For instance, if RSU E detects power from RSU F that is the same as or stronger than power from RSU-D, RSU E can select RSU F for timing. Therefore, RSU E may experience approximately 6µs of total TO when synchronizing with RSU F, and approximately 4µs of total TO when synchronizing with RSU D.

[0090] Various aspects generally relate to timing synchronization (e.g., using SLSS). Some aspects are more specifically related to timing synchronization in C-V2X implementations with limited or no GNSS coverage. In some aspects, UEs (e.g., RSUs) located in areas with limited or no GNSS coverage may circulate SLSS neighbor information, such as in the form of SNL. This SLSS neighbor information may include one or more of the following: index number, SLSS ID, timing source coverage flag, RSU ID, hop ID, geographic location, transmission synchronization offset, synchronization source, and / or UTC time.

[0091] Specific aspects of the subject matter described in this disclosure can be implemented to achieve one or more of the following potential advantages. In some examples, the described techniques can be used to resolve deadlock scenarios, location and UTC timing issues, SLSS silence issues, and / or problems related to the UE not being connected to the nearest synchronization source, as described above. Figure 5 and Figure 6The issues discussed include: SLSS neighbor information can resolve deadlock scenarios by enabling RSUs to determine whether they are in a deadlock situation (e.g., based on whether the SNL contains SLSS ID 0). SLSS neighbor information can resolve location and UTC timing issues by enabling UEs to identify their location and / or UTC time (e.g., based on geographic location and / or UTC time). SLSS neighbor information can resolve SLSS silencing issues by enabling UEs to identify overlapping SLSS transmissions (e.g., based on SLSS ID, transmission synchronization offset, etc.) without attempting to measure signals from neighboring UEs. SLSS neighbor information can resolve issues related to a UE not being connected to the nearest synchronization source by enabling UEs to identify (e.g., based on RSU ID, location, etc.) which RSU is closest to or will be closest to the UE.

[0092] Figure 7 This is an illustration of example 700 associated with indicating the relative location of the UE using an associated SLSS ID, according to this disclosure. Example 700 may involve communications sent to and from the UE 710 (e.g., RSU).

[0093] As shown by reference numeral 720 in the attached figure, UE 710 receives a first indication, which includes at least an SLSS identifier associated with a neighboring UE (e.g., a neighboring RSU) of UE 710 and an indication of the relative location of the neighboring UE among multiple UEs. The neighboring UEs may be within a threshold distance or hop count from UE 710. In some examples, the neighboring UEs may be adjacent to UE 710. The multiple UEs may be multiple RSUs including UE 710 and the neighboring UEs. In some examples, the multiple UEs may be located in areas with little or no GNSS coverage, such as tunnels, parking garages, etc.

[0094] In some examples, UE 710 can receive a first indication from a neighboring UE, as described below. Figure 8 and Figure 9 This will be discussed in more detail. In some examples, the UE 710 can receive the first instruction from the cloud or network, as described below. Figure 11 This will be discussed in more detail. An indication of the relative location of neighboring UEs can indicate the topological placement of neighboring UEs among multiple UEs. For example, an indication of the relative location of neighboring UEs may include the identifier of the neighboring UE (e.g., RSU ID), the hop ID of the neighboring UE, the geographical location of the neighboring UE, etc. In some examples, the first indication may also include an indication of time (e.g., UTC time) (such as the time when the neighboring UE generated the first indication) and / or a transmission synchronization offset associated with the neighboring UE.

[0095] As shown by reference numeral 730 in the attached figure, UE 710 sends a second indication, which includes at least an SLSS identifier associated with UE 710 and an indication of the relative location of UE 710 among multiple UEs. In some examples, UE 710 may send the second indication to another adjacent UE, as described below. Figure 8 and Figure 9 This will be discussed in more detail. In some examples, the UE 710 can send a second instruction to the cloud or network, as described below. Figure 11 To be discussed in more detail.

[0096] The indication of the relative location of UE 710 can indicate the topological placement of UE 710 among multiple UEs. For example, the indication of the relative location of UE 710 may include the identifier of UE 710 (e.g., RSU ID), the hop ID of UE 710, the geographic location of UE 710, etc. In some examples, the second indication may also include an indication of time (e.g., UTC time) (such as the time when UE 710 generates the second indication) and / or a transmission synchronization offset associated with UE 710.

[0097] In some examples, the first instruction may include a first list (e.g., a first SNL), and / or the second instruction may include a second list (e.g., a second SNL). Example SNLs are provided in Tables 4 and 5 below. Although the information provided in Tables 4 and 5 is presented as a list (e.g., SNL), this information may be provided in any other suitable format.

[0098] Table 4

[0099] Table 5 As shown in the figure, for each UE (e.g., UE 710, neighboring UEs, etc.), the SNL may include an index (“IDX”), SLSSID, an indication of whether the UE is within the coverage of a navigation system (such as GNSS) (e.g., an in-coverage flag (“INC”), an identifier (“RSU ID”), a hop ID (“HopID”), a geographic location (“LOC”), a transmission synchronization offset (“TxSyncOffset”), a synchronization source indication (“Sync Source”), and / or an indication of time such as UTC time (“UTC time”).

[0100] IDX 0 can be associated with self-SLSS information (e.g., SLSS information associated with the sending device), and IDX 1 and subsequent IDXs can be associated with SLSS information associated with neighboring devices (e.g., neighbor list information). For example, a device that generates and sends SNL messages can occupy IDX 0.

[0101] The SLSS ID identifies the SLSS timing source and can be decoded based on the primary synchronization signal (PSS) and secondary synchronization signal (SSS). INC can be an SLSS timing source coverage flag decoded from the Physical Side Link Broadcast Channel (PSBCH). The RSU ID identifies the SLSS transmission synchronization source. The RSU ID can be a Media Access Control (MAC) source ID, such as a self-assigned and / or random L2 MAC source address. The HopID can be selected by each UE and included in the SNL message (e.g., sent in the PSBCH).

[0102] The Location of the Origin (LOC) can be a GNSS location (e.g., latitude and longitude) that provides an accuracy of approximately 100 m. In some examples, the accuracy may be greater than or less than approximately 100 m. The LOC can be set to a pre-configured location based on cached location information, dynamically derived information (e.g., using a DR), etc.

[0103] TxSyncOffset can indicate the synchronization offset used for SLSS transmission. SyncSource can indicate the hop ID of the UE used as the synchronization source for a given UE. UTC time can be the UTC time at the time the SNL message was generated. In some examples, the SNL may also include a TimingOffset field, which may contain an estimated timing offset for the SLSS timing source for each UE.

[0104] Therefore, the SNL can include a list of all adjacent SLSS synchronization sources. In some aspects, multiple UEs can be in SLSS synchronization and can send multiple lists (e.g., SNLs) including indications of multiple synchronization sources once per SLSS cycle via the Physical Side Link Shared Channel (PSSCH). For example, the SNL can be sent every SLSS cycle. X The message is sent once per millisecond (ms) on the PSSCH as an event-driven message. The SNL can be associated with the nearest service per packet priority (PPPP) (e.g., lowest PPPP). For example, each SLSS sending device (e.g., multiple UEs) can generate an SNL. In some examples, UE 710 can use a semi-persistent scheduling (SPS) flow to generate the SNL (e.g., to populate a table) and switch to an event-driven flow after generating the SNL.

[0105] In some aspects, UE 710 can generate a second list (e.g., SNL) for transmission by appending information to a first list (e.g., SNL) received by UE 710. For example, when generating an SNL, UE 710, which has previously decoded an SNL from a neighboring UE, can append unique information from the previous SNL before transmitting the SNL. In some examples, the unique information may include a tuple containing [SLSS ID, INC, RSU ID, LOC, TxSyncOffset]. In some examples, the tuple may also include a hop ID. If an SNL containing an entry has not been decoded within a threshold number of SNL cycles, UE 710 can remove the entry from the SNL.

[0106] Receiving a first indication (e.g., a first SNL) and / or sending a second indication (e.g., a second SNL) can resolve deadlock scenarios by enabling UE710 and / or neighboring UEs to determine whether the UE is in a deadlock scenario (e.g., based on whether the first or second indication contains SLSS ID 0). A first and / or second indication that also includes an indication of time (e.g., UTC time) can resolve location and UTC timing issues by enabling UEs (e.g., UE710, neighboring UEs, etc.) to identify geographic locations and / or UTC time. A first and / or second indication that also includes a synchronization offset can resolve SLSS silencing issues by enabling UEs (e.g., UE710, neighboring UEs, etc.) to identify overlapping SLSS transmissions (e.g., based on SLSS ID, transmission synchronization offset, etc.) without attempting to measure signals from neighboring UEs. Including an indication of relative positioning and / or a first and / or second indication that also includes geographic location can enable UEs (e.g., UE710, neighboring UEs, OBUs, etc.) to identify (e.g., based on RSUID, geographic location, etc.) which RSU is or will be closest to the UE.

[0107] Figure 8 This is a diagram illustrating an example 800 associated with initializing an SNL by propagating SNL information across systems, according to this disclosure. The system may include RSU AGs, which in some examples may be spaced 200 to 300 meters apart, corresponding to a timing delay of 1 μs. However, the RSU AGs may be spaced at any suitable distance and have any suitable corresponding timing delay.

[0108] An RSU using GNSS as its time source (e.g., RSU A) can generate an SNL message before other RSUs. RSU A can send the message, and devices within range of RSU A (e.g., RSU B) can decode the SNL message. Devices can decode the SLSS signal and select the initial synchronization signal.

[0109] In Example 800, a UE (e.g., an RSU) may receive a first list (e.g., a first SNL) that associates a first index (e.g., IDX 0) with an SLSS ID associated with a neighboring UE and an indication of the relative location of the neighboring UE among multiple UEs. For example, RSU B may receive an SNL sent by RSU A, RSU C may receive an SNL sent by RSU B, and so on.

[0110] The UE can send a second list (e.g., a second SNL) that associates a first index (e.g., IDX 0) with an SLSS ID associated with the UE and an indication of the UE's relative location among multiple UEs. The second list can also associate a second index (e.g., IDX 1, IDX 2, etc.) with an SLSS ID associated with a neighboring UE and an indication of the relative location of the neighboring UE. In some aspects, the UE can use the first index to append information to the first list. For example, a device using SLSS can receive an SNL message, append information associated with that device to the SNL (e.g., a table) using IDX 0, and generate and send the SNL message. Thus, for each sent SNL, IDX 0 corresponds to the RSU sending the SNL. For example, in an SNL sent by RSU A, IDX 0 corresponds to RSU A, and in an SNL sent by RSU B, IDX 0 corresponds to RSU B, IDX 1 corresponds to RSU A, and so on.

[0111] Associating a first index (e.g., IDX 0) with the transmitting UE can indicate to the receiving UE which of a plurality of UEs sent the SNL. For example, the receiving UE can identify the transmitting UE and determine that SNL information (e.g., SLSS ID, INC, etc.) is associated with the transmitting UE.

[0112] The total time for a tunnel system to reach equilibrium (equilibrium time, TTE) can depend on the presence of RSUs (Remote Suspension Units) directly connected to the GNSS at both tunnel entrances. In some examples, the TTE... a = c x t x n / g ,in c It is the cycle number before the RSU ID is included or removed in SNL. t It is SNL sending periodically. n It is the total number of RSUs in the chain, and g This refers to the number of RSUs (or UEs) that are synchronized with GNSS. For example, if the RSUs are directly connected to GNSS at both entrances of the tunnel, then the TTE... a = c × t x n / 2If only one RSU is directly connected to the GNSS (e.g., at one entrance to a tunnel), then the TTE... b = c x t × n .

[0113] Figure 9 This is an illustration of example 900 associated with the propagation of SNL information across systems when SNL is in a stable state, according to this disclosure.

[0114] As shown in the figure, once all devices in the system (e.g., RSUs) are sending SNL messages, SNL messages from all devices in the system can contain the same information (except for UTC time). The system can be in a steady state when no additions or deletions are made to the list after the initial threshold number of minutes. If a row is added to or deleted from the SNL after the system has reached a steady state, the UE can send an updated SNL message reflecting that addition or deletion (e.g., the UE can immediately transmit an updated SNL message).

[0115] In some examples, the system can truncate the SNL if it exceeds a threshold message size. For instance, a UE can truncate an SNL into a minimum of three entries, including an entry for the UE, one or more entries for any nearby (decodeable) neighbors, and one or more entries for any priority 1 SLSS synchronization source. RSUs connected to GNSS can set the threshold message size.

[0116] The generated SNL message can be constructed at the Intelligent Transportation System (ITS) stack or independently within the C-V2X modem software stack. The stack signature of the ITS message helps verify the validity of the SNL message being decoded. In some examples, when decoding a transport block containing an SNL message, the received MAC source ID of the verified ITS stack-signed message can be cross-validated against the received MAC source ID. In some examples, the SNL message can be signed at the High-Level Operating System (HLOS).

[0117] As described above, a UE (e.g., an RSU) can receive a first indication (e.g., a first SNL) that includes a first indication of a first time (e.g., a first UTC time), and send a second indication (e.g., a second SNL) that includes a second indication of a second time (e.g., a second UTC time). In some examples, where the UE is directly connected to GNSS (e.g., RSU A), the UE can use the UTC time derived from the GNSS in the SNL message sent by that UE. In some examples, the UE can receive the time indication on the WWAN, such as via SIB16 (for LTE) or SIB9 (for 5G NR). However, a UE that does not receive a time indication (e.g., UTC time) directly from the Global Positioning System (GPS) or WWAN can derive the UTC time from the received SNL message. In some aspects, the UE can derive the UTC time associated with the UE using the UTC time associated with a neighboring UE carried in the first indication, and generate the second indication by appending the UTC time associated with the UE to the first indication. For example, RSU B can derive the UTC time from the SNL message received from RSU A, RSU C can derive the UTC time from the SNL message received from RSU B, and so on. The transmitting UE generating the SNL message (e.g., a UE outside GNSS coverage (OOC)) can derive the UTC time and / or location and append the derived (e.g., calculated) UTC time and / or location. For example, whenever the transmitting UE generates an SNL message, the transmitting UE can update the UTC time column.

[0118] UE can send based on relationship UTC time calculated = SNL UTC + Correction Factor To export UTC time, where SNL UTC It is the latest decoded UTC time indicated in IDX 0 of the most recent SNL message received by the sending UE, and Correction Factor = ( OTA DFN – SNL DFN ) + Interstack delay + TO est ,in OTA DFN It is based on the system frame number (SFN) and / or the direct frame number (DFN) derived from the system frame (SF) of the decoded SNL message. SNL DFN Based on SNL UTC Exported DFN, Interstack delayIt is a constant inter-UE stack latency for each device, and TO est It is to estimate TO (e.g., estimate timing delay).

[0119] A UE that has not yet decoded an SNL message may not adjust its UTC time or apply UTC time at HLOS. The UE can derive its UTC time based on the UTC time in the most recently decoded SNL message. In some respects, the UE can decode multiple indications and identify the UTC time from the indication that was most recently decoded by the UE compared to any other indication among them. The UE can obtain information about its location. Using the location in the SNL message, the UE can determine the nearest UTC synchronization time source. GNSS-based location in the SNL message can help the UE determine an approximate geographic location, which can be applied to geographic polygon features.

[0120] Receiving a first indication of a first time and sending a second indication of a second time can help a UE (e.g., a vehicle UE) obtain UTC time in GNSS-blocked areas. For example, a device in a location without WWAN or GNSS coverage (e.g., performing a cold start in a parking garage or entering an area without GNSS coverage) can obtain UTC time. Therefore, the ITS stack can generate messages with millisecond-level timing accuracy.

[0121] In some aspects, a UE (e.g., RSU) may identify one or more parameters of one or more SLSS transmissions, at least in part, based on an indication that includes at least an SLSS ID associated with a neighboring UE and an indication of the relative position of the neighboring UEs among multiple UEs. For example, based on information in the SNL (e.g., SLSS ID, RSU ID, LOC, UTC time, TxSyncOffset, etc.), an SLSS transmitting UE may identify overlapping SLSS transmissions. In some aspects, a UE may use this indication to identify overlapping SLSS transmissions. For example, a UE may identify overlapping SLSS transmissions without performing SLSS silencing.

[0122] Therefore, an SLSS transmitting device (e.g., a UE) can switch SLSS sources without ceasing (e.g., by silencing) SLSS transmission. For example, a UE can switch SLSS sources without randomly monitoring other SLSS synchronization sources that the UE can use. Thus, the UE can avoid dropping or not transmitting SLSS signals due to SLSS silence. Furthermore, by not measuring neighboring UEs, the UE can avoid the channel estimation required at that time, thereby reducing the burden on the UE's computational resources.

[0123] In some aspects, a mobile (e.g., vehicle) UE can identify a synchronization source from multiple UEs (e.g., multiple RSUs) based on a first indication (e.g., a first SNL) or a second indication (e.g., a second SNL). For example, an SNL message received by a mobile UE can enable the mobile UE to perform a preemptive action based on an SLSS synchronization source (e.g., an RSU) along the path of the mobile UE. The mobile UE can use the RSU ID (e.g., source ID) as a key to associate a channel estimate of a signal from an RSU with the RSU indicated in the decoded SNL message.

[0124] Identifying the synchronization source from multiple UEs according to a first or second indication allows a mobile UE (e.g., a vehicle traveling through a tunnel) to switch to the optimal RSU. For example, the mobile UE can switch to an RSU it is approaching (e.g., rather than an RSU it is leaving). Therefore, the mobile UE can switch to the optimal RSU instead of immediately switching synchronization sources upon detecting a signal from an RSU (where the mobile UE may have little time to reselect a synchronization source while driven by an RSU). Furthermore, compared to performing channel estimation on six resource blocks (RBs) (which is the size of the PSBCH TB), the mobile UE can more easily perform channel estimation on larger transport blocks (TBs).

[0125] Figure 10 This is a diagram illustrating an example 1000 associated with mitigating (e.g., eliminating) deadlock according to this disclosure.

[0126] As shown by reference numeral 1010, a UE (e.g., RSU) that has entered a deadlock scenario can continue decoding SNL messages. As shown by reference numeral 1020, the UE can determine whether the packet error rate exceeds a threshold (e.g., whether SNL_Rx_PER > SNL_PER_Thresh). SNL_PER_Thresh can be a factor of the number of adjacent SLSS-sending UEs and the SNL message generation rate. For example, SNLs from two devices can be expected, meaning that each X ms expects two SNLs.

[0127] As shown by reference numeral 1030 in the attached figure, in response to a packet error rate exceeding a threshold, the UE may trigger an SLSS search. As shown by reference numeral 1040 in the attached figure, in response to a packet error rate not exceeding a threshold, the UE may determine whether the SNL includes any SLSS identifier associated with a navigation system synchronized UE (or another UE synchronized with the navigation system synchronized UE among multiple UEs). For example, the UE may determine whether the SNL contains an SLSS ID 0 entry.

[0128] As shown by reference numeral 1030, in response to the SNL not including any SLSS identifier associated with the navigation system synchronized UE (or another UE synchronized with the navigation system synchronized UE among a plurality of UEs), the UE may trigger an SLSS search. In some examples, the UE may trigger an SLSS search based on an SNL containing information associated only with one other UE. As shown by reference numeral 1010, in response to the SNL including any SLSS identifier associated with the navigation system synchronized UE (or another UE synchronized with the navigation system synchronized UE among a plurality of UEs), the UE may continue decoding the SNL message.

[0129] Triggering an SLSS search can help a UE escape a deadlock scenario. For example, a UE can discard its current synchronization source and search for (directly or indirectly) updated synchronization sources connected to the GNSS. For instance, triggering an SLSS search in response to a packet error rate exceeding a threshold can enable a UE to escape a deadlock scenario, as a high packet error rate can indicate that the UE is time-drifting (e.g., due to a deadlock scenario). Triggering an SLSS search in response to an SNL not containing any SLSS identifier associated with a navigation system-synchronized UE (or another UE among multiple UEs synchronized with the navigation system-synchronized UE) can also enable a UE to escape a deadlock scenario, since the absence of an SLSS ID 0 entry indicates that the UE can communicate directly or indirectly with UEs that are not directly or indirectly communicating with the GNSS.

[0130] Figure 11 This is an illustration of Example 1100 associated with a cloud-based implementation according to this disclosure.

[0131] As shown in the figure, a UE (e.g., RSU A or B) can send an indication to the cloud or network that includes at least the SLSS ID associated with the UE and an indication of the UE's relative position among multiple UEs (e.g., multiple RSUs). For example, an RSU connected to GPS and a WAN may be able to upload its entire SNL to the cloud for that area. Additionally or alternatively, if an RSU has the capability to do so, other RSUs may upload their respective SNLs to the cloud or network. Additionally or alternatively, a UE (e.g., RSU AE) can receive an indication from the cloud or network that includes at least the SLSS ID associated with a neighboring UE (e.g., a neighboring RSU) and an indication of the neighboring UE's relative position among multiple UEs.

[0132] Sending and / or receiving instructions to or from the cloud or network can help reduce the time between instruction transmissions (e.g., SNL messages) because the RSU can receive the uncrunted SNL from the cloud. Furthermore, sending instructions (e.g., SNL messages) to the cloud or network enables the cloud or network to send SNL messages to the mobile UE. For example, the cloud or network can send SNL messages in network-to-vehicle (N2V) or vehicle-to-network (V2N) messages or using a car-to-cloud (Car2Cloud) system. For instance, an OBU about to enter a tunnel can download the SNL in advance from the cloud via a Car2Cloud system or from the network via V2N messaging.

[0133] Figure 12 This is an illustration of example 1200 associated with determining a hop ID of a UE according to this disclosure. The hop ID may indicate the number of hops away from a GNSS that is directly connected to another UE (e.g., another RSU) and resides on a different UE (e.g., an SLSS transmitting UE, such as an RSU).

[0134] As shown in Figure 1210, the UE can receive the hop ID in the Master Information Block (MIB), which reduces the complexity and uncertainty associated with RSU selection based on TO estimation. For example, the UE can decode the Side Link MIB (SL-MIB) from the PSBCH. The SLSS hop identifier can be added to at least a portion of the 27 reserved bits (currently set to all zeros) in the SLSS MIB, as follows: As shown by reference numeral 1220 in the attached figure, the UE can determine whether it is directly connected to the GNSS (e.g., whether the UE has priority P1). As shown by reference numeral 1230 in the attached figure, if the UE is directly connected to the GNSS, the UE can automatically set the hop ID (“hopID”) (“TxSLSS_HopID”) that the UE will send in the SL-MIB to zero.

[0135] The UE can automatically derive the hop ID based on its SLSS synchronization source. For example, if the UE is not directly connected to GNSS and the SLSS synchronization source SL-MIB contains hop IDs, the UE can automatically derive the hop ID. As shown in Figure 1240, if the UE is not directly connected to GNSS, the UE (e.g., an SLSS receiving UE) can identify the SLSS synchronization source with the smallest hop ID among all SLSS synchronization sources detected by the UE and the best SLSS RSRP. "RxSLSS_HopID" (which can be decoded from the MIB) can be the hop ID of the SLSS synchronization source the UE will switch to, "SyncSLSS_HopID" can be the hop ID of the current SLSS synchronization source, "RxSLSS_RSRP" can be the RSRP associated with the SLSS synchronization source the UE will switch to, "SyncSLSS_RSRP" can be the RSRP associated with the current SLSS synchronization source, and "SLSS_RSRP_thresh" can be a threshold.

[0136] As shown by reference numeral 1250 in the attached figure, the UE can reselect an SLSS synchronization source. For example, the UE can switch from its current SLSS synchronization source (“SLSS_sync_Src”) to a new SLSS synchronization source (“RxSLSS_HopID”). For instance, if the UE detects an SLSS from a transmitter with a lower hop ID than the current SLSS synchronization source, and / or the transmitter meets certain criteria, the UE can perform an SLSS synchronization source reselection. If the UE detects multiple identical hop IDs, the UE can select a synchronization source based on synchronization sources that meet certain criteria.

[0137] As shown by reference numeral 1260 in the attached figure, the value of the UE's hop ID can be incremented from the value of the hop ID associated with a neighboring UE (e.g., the hop ID can be incremented based on the neighboring UE to which the UE is currently synchronized). For example, the UE can increment RxSLSS_HopID (e.g., the hop ID associated with a neighboring UE) by one to generate the UE's hop ID ("TxSLSS_HopID"). The UE can set TxSLSS_HopID in the SL-MIB when transmitting SLSS. If the UE is not directly connected to GNSS and the SLSS synchronization source SL-MIB does not contain a hop ID, the UE may not need to populate the HopID field in the MIB when transmitting SLSS. If the UE detects synchronization sources with and without hop IDs, and the synchronization source does not correspond to SLSS ID 0, the UE may prioritize the SLSS synchronization source with the hop ID.

[0138] Figure 13This is an illustration of example 1300 associated with the use of jump IDs to mitigate (e.g., eliminate) deadlock according to this disclosure.

[0139] As shown by reference numeral 1310 in the attached figure, the UE can decode the MIB from the PSBCH and identify the hop ID (“SyncSLSS_HopID”) associated with another UE (such as a neighboring UE). As shown by reference numeral 1320 in the attached figure, the UE can determine whether SyncSLSS_HopID is greater than or equal to TxSLSS_HopID. If SyncSLSS_HopID is less than TxSLSS_HopID, the UE can decode the additional MIB from the PSBCH, as shown by reference numeral 1310 in the attached figure.

[0140] As shown in Figure 1330, a UE can trigger an SLSS search in response to a continuous configuration time duration where the value of the hop ID associated with the UE is less than or equal to the value of the hop identifier of another UE. For example, the configuration time duration could be the duration of an SLSS deadlock timer.

[0141] Triggering an SLSS search in response to a UE's hop ID being less than or equal to another UE's hop identifier for a continuous configuration time duration can help a UE escape deadlock. For example, a UE's hop ID being less than or equal to another UE's hop identifier for at least a configuration time duration can indicate that the UE is in a synchronization deadlock. Example 1300 can be implemented on any UE that can detect a hop ID greater than or equal to the UE's TxSLSS_HopID.

[0142] Figure 14 This is an illustration of example 1400 associated with SLSS propagation in a daisy chain using skip IDs, according to this disclosure. Figure 14 As shown, RSUs deep within the tunnel (e.g., RSU G) can be time-synchronized with the rest of the system (e.g., RSUA-F and GNSS). Arrows pointing from left to right indicate target propagation of SLSSs, and arrows pointing from right to left indicate leakage from adjacent SLSS sources (e.g., unwanted reception from SLSSs). Example 1400 illustrates timing availability when all RSUs are active. As shown in Table 1410, even when SLSS IDs are identical, RSUs (e.g., SLSS transmitting UEs) can be uniquely identified based on hop IDs.

[0143] Figure 15This is a diagram illustrating Example 1500, which describes a deadlock scenario involving a hop ID according to this disclosure. In Example 1500, RSU D can be turned off. Before being turned off, RSU D may have detected a hop ID larger than the hop ID that RSU D used to send. Example 1500 illustrates the timing availability when RSU D does not send SLSS. Therefore, as shown in Table 1510, RSU E can trigger an SLSS search and stop sending SLSS with hop ID 4.

[0144] Figure 16 This is a diagram illustrating Example 1600, a continuation of the deadlock scenario involving hop IDs according to this disclosure. As shown, RSU F may only detect hop IDs larger than the hop ID that RSU F uses to send. Therefore, RSU F may trigger an SLSS search. Example 1600 and Table 1610 illustrate the timing availability of RSU E in search mode.

[0145] Figure 17 This is a diagram illustrating a further continuation of Example 1700, which describes a deadlock scenario involving hop IDs according to this disclosure. As shown, RSU G may only detect hop IDs larger than the hop ID that RSU G uses to send. Therefore, RSU G may trigger an SLSS search. Example 1700 and Table 1710 illustrate the timing availability of RSU E in search mode.

[0146] When RSU D returns to online status, it automatically selects the appropriate hop ID, and other devices in the daisy chain (e.g., RSU EG) can dynamically realign to the associated hop ID. Therefore, the hop ID helps prevent devices from synchronizing with each other without a link to the GNSS-synchronized UE, thus avoiding deadlock. Hop IDs can resolve deadlock scenarios in LTE V2X SLSS synchronization, NR V2X SLSS, and more.

[0147] Figure 18 This is a diagram illustrating example 1800 of the selection of a synchronization source according to this disclosure.

[0148] In Example 1800, the OBU can select the lowest hop ID, which can be associated with the RSU having the lowest TO. For example, the OBU can select RSU D instead of RSU E. The hop ID helps the OBU select the SLSS synchronization source with the smallest timing offset. For example, the hop ID helps the SLSS receiving UE (e.g., the OBU) determine how far the UE is from the true timing reference (e.g., the GNSS-synchronized UE), and thus enables the OBU to select the optimal synchronization source. Therefore, the modem (e.g., associated with the OBU) can select the SLSS synchronization source associated with a UE (e.g., an RSU) that is closer to the UE than other UEs based on the decoded PSBCH for the same SLSS ID (e.g., rather than just RSRP). The hop ID in the SL-MIB eliminates the unreliability of synchronization source selection based on TO estimation, which can vary based on channel conditions.

[0149] Figure 19 This is a flowchart illustrating an example procedure 1900 performed by a UE, for example, to support indicating the relative location and SLSS ID of the UE, according to this disclosure. Example procedure 1900 is an example in which the UE (e.g., UE 120) performs operations associated with indicating the relative location and SLSS ID of the UE.

[0150] like Figure 19 As shown, in some aspects, process 1900 may include receiving a first indication, which includes at least an SLSS identifier associated with a neighboring UE of the UE and an indication of the relative positioning of the neighboring UEs among a plurality of UEs (box 1910). For example, a UE (such as by using...) Figure 20 The communication manager 140 or receiving component 2002 depicted herein may receive a first indication, which includes at least an SLSS identifier associated with a neighboring UE of the UE and an indication of the relative position of the neighboring UE among a plurality of UEs, as described above.

[0151] like Figure 19 As further shown, in some aspects, process 1900 may include sending a second indication, which includes at least an SLSS identifier associated with the UE and an indication of the relative location of the UE among multiple UEs (box 1920). For example, a UE (such as by using...) Figure 20 The communication manager 140 or transmitting component 2004 depicted herein may transmit a second instruction, which includes at least an SLSS identifier associated with the UE and an indication of the relative location of the UE among multiple UEs, as described above.

[0152] Process 1900 may include additional aspects, such as any single aspect or any combination of aspects described in one or more other processes described below or in conjunction with other parts of this document.

[0153] In the first additional aspect, the indication of the relative location of the UE includes the identifier of the UE.

[0154] In the second additional aspect, either alone or in combination with the first aspect, the identifier of the UE is the RSU ID.

[0155] In a third additional aspect, either alone or in combination with one or more of the first and second aspects, the indication of the relative location of the UE includes the hop ID associated with the UE.

[0156] In the fourth additional aspect, receiving a hop ID, either alone or in combination with one or more of the first to third aspects, includes receiving a hop ID in the MIB.

[0157] In the fifth additional aspect, either alone or in combination with one or more of the first to fourth aspects, the hop ID is the first hop ID, and the first value of the first hop ID increments from the second value of the second hop ID associated with the adjacent UE.

[0158] In the sixth additional aspect, either alone or in combination with one or more of the first to fifth aspects, the hop identifier is the first hop identifier, and the process 1900 further includes triggering an SLSS search in response to a second value of the second hop ID of one of the plurality of UEs being less than or equal to a second value of the first hop ID being configured for a duration of time.

[0159] In the seventh additional aspect, either alone or in combination with one or more of the first to sixth aspects, the indication of the relative location of the UE includes an indication of the geographical location of the UE.

[0160] In the eighth additional aspect, either alone or in combination with one or more of the first to seventh aspects, the indication of the relative location of adjacent UEs includes the identifiers of the adjacent UEs.

[0161] In the ninth additional aspect, either alone or in combination with one or more of the first to eighth aspects, the indication of the relative location of adjacent UEs includes the hop ID associated with the adjacent UE.

[0162] In the tenth additional aspect, either alone or in combination with one or more of the first to ninth aspects, the indication of the relative positioning of adjacent UEs includes the indication of the address location of adjacent UEs.

[0163] In the eleventh additional aspect, either alone or in combination with one or more of the first to tenth aspects, the second indication further includes one or more of the following: an index, an indication of whether the UE is within the coverage area of ​​the navigation system, a transmission synchronization offset associated with the UE, or an indication of a first time derived from a second time associated with a neighboring UE.

[0164] In the twelfth additional aspect, either alone or in combination with one or more of the first to eleventh aspects, the indication of the relative location of the UE includes one or more of the following: the UE's identifier, the hop ID associated with the UE, an indication of the UE's geographical location, or an indication of a synchronization source corresponding to a neighboring UE.

[0165] In the thirteenth additional aspect, either alone or in combination with one or more of the first to twelfth aspects, the first indication includes a first list that associates a first index with an SLSS identifier associated with a neighboring UE and with an indication of the relative location of the neighboring UE.

[0166] In the fourteenth additional aspect, either alone or in combination with one or more of the first to thirteenth aspects, multiple UEs are in SLSS synchronization and, within each or more SLSS cycles, multiple lists including a first list and a second list are transmitted once via PSSCH, the multiple lists including indications of multiple synchronization sources.

[0167] In the fifteenth additional aspect, alone or in combination with one or more of the first to fourteenth aspects, process 1900 includes generating a second list by appending information to the first list.

[0168] In the sixteenth additional aspect, generating a second list by appending information to a first list, either alone or in combination with one or more of the first to fifteenth aspects, includes: appending information to the first list using a first index.

[0169] In the seventeenth additional aspect, alone or in combination with one or more of the first to sixteenth aspects, process 1900 includes triggering an SLSS search in response to a grouping error rate exceeding a threshold.

[0170] In the eighteenth additional aspect, alone or in combination with one or more of the first to seventeenth aspects, process 1900 includes triggering an SLSS search in response to a first indication that does not include any SLSS identifier associated with a navigation system synchronized UE among the plurality of UEs or another UE among the plurality of UEs synchronized with the navigation system synchronized UE.

[0171] In the nineteenth additional aspect, either alone or in combination with one or more of the first to eighteenth aspects, the first instruction further includes a first instruction for a first time, and the second instruction further includes a second instruction for a second time derived from the first time.

[0172] In the nineteenth additional aspect, alone or in combination with one or more of the first to eighteenth aspects, process 1900 includes identifying one or more parameters transmitted by one or more SLSSs based at least in part on the first indication.

[0173] In the twenty-first additional aspect, either alone or in combination with one or more of the first to twentieth aspects, the mobile UE identifies a synchronization source from among a plurality of UEs according to a first instruction or a second instruction.

[0174] In the twenty-second additional aspect, either alone or in combination with one or more of the first to twenty-first aspects, the neighboring UE is a first neighboring UE, and receiving the first instruction includes receiving the first instruction from the first neighboring UE, or sending the second instruction includes sending the second instruction to the second neighboring UE.

[0175] In the twenty-third additional aspect, receiving a first instruction, alone or in combination with one or more of the first to twenty-two aspects, includes receiving a first instruction from a cloud or network, or sending a second instruction includes sending a second instruction to a cloud or network.

[0176] In the twenty-fourth additional aspect, either alone or in combination with one or more of the first to twenty-third aspects, process 1900 includes deriving the UTC time associated with the UE using the UTC time associated with the adjacent UE carried in the first indication, and generating a second indication by appending the UTC time associated with the UE to the first indication.

[0177] In the twenty-fifth additional aspect, alone or in combination with one or more of the first to twenty-fourth aspects, process 1900 includes: decoding a plurality of indications including a first indication, and identifying the UTC time of an indication that was more recently decoded by the UE compared to any other indication among the plurality of indications.

[0178] In the twenty-sixth additional aspect, either alone or in combination with one or more of the first to twenty-fifth aspects, process 1900 includes SLSS transmission using a first indicator overlaid.

[0179] although Figure 19 An example box for process 1900 is shown, but in some respects, it differs from... Figure 19Compared to the boxes depicted, process 1900 may include additional boxes, fewer boxes, different boxes, or boxes arranged in a different manner. Additionally or alternatively, two or more boxes in the process 1900 may be executed in parallel.

[0180] Figure 20 This is a diagram of an example device 2000 for wireless communication that supports the relative positioning and SLSS ID of a UE according to this disclosure. Device 2000 may be a UE, or a UE may include device 2000. In some aspects, device 2000 includes a receiving component 2002, a transmitting component 2004, and a communication manager 140 that can communicate with each other (e.g., via one or more buses). As shown, device 2000 can use the receiving component 2002 and the transmitting component 2004 to communicate with another device 2006 (such as a UE, a network node, or another wireless communication device).

[0181] In some respects, the device 2000 can be configured and / or operated to perform the functions described herein. Figures 7 to 18 One or more operations described herein. Additionally or alternatively, the apparatus 2000 may be configured and / or operable to perform one or more processes described herein, such as Figure 19 The process 1900. In some aspects, apparatus 2000 may include the above-described combination. Figure 2 One or more components of the UE as described.

[0182] Receiver 2002 may receive communications from device 2006, such as reference signals, control information, and / or data communications. Receiver 2002 may provide the received communications to one or more other components of device 2000, such as communication manager 140. In some aspects, receiver 2002 may perform signal processing on the received communications (such as filtering, amplification, demodulation, analog-to-digital conversion, demultiplexing, deinterleaving, demapping, equalization, interference cancellation, or decoding, etc.) and may provide the processed signals to one or more other components. In some aspects, receiver 2002 may include the elements described above. Figure 2 The described UE includes one or more antennas, modems, demodulators, MIMO detectors, receiver processors, controllers / processors, and / or memory.

[0183] The transmitting component 2004 can transmit communications, such as reference signals, control information, and / or data communications, to the device 2006. In some aspects, the communication manager 140 can generate communications and send the generated communications to the transmitting component 2004 for transmission to the device 2006. In some aspects, the transmitting component 2004 can perform signal processing (such as filtering, amplification, modulation, digital-to-analog conversion, multiplexing, interleaving, mapping, or encoding) on ​​the generated communications and can send the processed signals to the device 2006. In some aspects, the transmitting component 2004 can include the elements described above. Figure 2 The described UE includes one or more antennas, modems, modulators, transmit MIMO processors, transmit processors, controllers / processors, and / or memory. In some aspects, the transmit component 2004 may co-located with the receive component 2002 in a transceiver.

[0184] Communication manager 140 may receive, or may cause receiving component 2002 to receive, a first indication that includes at least an SLSS ID associated with a neighboring UE and an indication of the relative location of the neighboring UE among multiple UEs. Communication manager 140 may transmit, or may cause sending component 2004 to send, a second indication that includes at least an SLSS identifier associated with a UE and an indication of the relative location of the UE among multiple UEs. In some aspects, communication manager 140 may perform one or more operations as described elsewhere herein by one or more components of communication manager 140. Communication manager 140 may include the foregoing in combination. Figure 2 The controller / processor and / or memory of the described UE.

[0185] The receiving component 2002 can receive a first indication, which includes at least an SLSS ID associated with a neighboring UE of the UE and an indication of the relative position of the neighboring UE among multiple UEs. The transmitting component 2004 can transmit a second indication, which includes at least an SLSS ID associated with the UE and an indication of the relative position of the UE among multiple UEs.

[0186] The communication manager 140 can trigger an SLSS search in response to a packet error rate exceeding a threshold.

[0187] The communication manager 140 may trigger an SLSS search in response to a first indication that does not include any SLSS ID associated with a navigation system synchronized UE among the multiple UEs or another UE among the multiple UEs synchronized with the navigation system synchronized UE.

[0188] The communication manager 140 can identify one or more parameters sent by one or more SLSSs, at least in part, based on a first indication.

[0189] Figure 20 The number and arrangement of components shown are provided as an example. In reality, with... Figure 20 Compared to the components shown, there may be additional components, fewer components, different components, or components arranged in a different manner. Furthermore, Figure 20 The two or more components shown can be implemented within a single component, or Figure 20 The single component shown can be implemented as multiple distributed components. Additionally or alternatively, Figure 20 The collection of (one or more) components shown can perform actions described as being performed by Figure 20 Another set of components shown performs one or more functions.

[0190] The following provides an overview of some aspects of this disclosure: Aspect 1: A method for wireless communication performed at a UE, the method comprising: receiving a first indication, the first indication including at least an SLSS identifier associated with a neighboring UE of the UE and an indication of the relative location of the neighboring UE among a plurality of UEs; and transmitting a second indication, the second indication including at least an SLSS identifier associated with the UE and an indication of the relative location of the UE among the plurality of UEs.

[0191] Aspect 2: According to the method of aspect 1, wherein the indication of the relative positioning of the UE includes the identifier of the UE.

[0192] Aspect 3: According to the method of aspect 2, the identifier of the UE is an RSU identifier.

[0193] Aspect 4: The method according to any one of Aspects 1 to 3, wherein the indication of the relative positioning of the UE includes a hop identifier associated with the UE.

[0194] Aspect 5: According to the method of aspect 4, receiving the hop identifier includes receiving the hop identifier in the MIB.

[0195] Aspect 6: According to the method of aspect 4, the hop identifier is a first hop identifier, and the first value of the first hop identifier is incremented from the second value of the second hop identifier associated with the adjacent UE.

[0196] Aspect 7: According to the method of aspect 4, wherein the hop identifier is a first hop identifier, the method further includes: triggering an SLSS search in response to a second value of a second hop identifier of one of the plurality of UEs being less than or equal to a continuous configuration time duration.

[0197] Aspect 8: The method according to any one of Aspects 1 to 7, wherein the indication of the relative positioning of the UE includes an indication of the geographical location of the UE.

[0198] Aspect 9: The method according to any one of Aspects 1 to 8, wherein the indication of the relative positioning of the adjacent UE includes the identifier of the adjacent UE.

[0199] Aspect 10: The method according to any one of Aspects 1 to 9, wherein the indication of the relative positioning of the adjacent UE includes a hop identifier associated with the adjacent UE.

[0200] Aspect 11: The method according to any one of Aspects 1 to 10, wherein the indication of the relative positioning of the adjacent UE includes an indication of the geographical location of the adjacent UE.

[0201] Aspect 12: The method according to any one of Aspects 1 to 11, wherein the second indication further comprises one or more of the following: an index; an indication of whether the UE is within the coverage area of ​​the navigation system; a transmission synchronization offset associated with the UE; or an indication of a first time derived from a second time associated with the adjacent UE.

[0202] Aspect 13: The method according to any one of Aspects 1 to 12, wherein the indication of the relative positioning of the UE includes one or more of the following: an identifier of the UE; a hop identifier associated with the UE; an indication of the geographical location of the UE; or a synchronization source indication corresponding to the neighboring UE.

[0203] Aspect 14: The method according to any one of Aspects 1 to 13, wherein the first indication includes a first list that associates a first index with the SLSS identifier associated with the neighboring UE and with the indication of the relative positioning of the neighboring UE.

[0204] Aspect 15: According to the method of aspect 14, wherein the second indication includes a second list that associates the first index with the SLSS identifier associated with the UE and the indication of the relative positioning of the UE, and wherein the second list also associates the second index with the SLSS identifier associated with the neighboring UE and associated with the indication of the relative positioning of the neighboring UE.

[0205] Aspect 16: According to the method of aspect 15, wherein the plurality of UEs are in SLSS synchronization, and in each or more SLSS cycles, a plurality of lists including the first list and the second list are transmitted once via PSSCH, the plurality of lists including indications of a plurality of synchronization sources.

[0206] Aspect 17: The method according to aspect 15 further includes generating the second list by appending information to the first list.

[0207] Aspect 18: The method according to any one of Aspect 17, wherein generating the second list by appending information to the first list comprises: appending the information to the first list using the first index.

[0208] Aspect 19: The method according to any one of Aspects 1 to 18, the method further comprising: deriving a UTC time associated with the adjacent UE using a UTC time associated with the adjacent UE carried in the first indication; and generating a second indication by appending the UTC time associated with the UE to the first indication.

[0209] Aspect 20: The method according to any one of aspects 1 to 19, the method further comprising: decoding a plurality of indications including the first indication; and identifying the UTC time from an indication that was more recently decoded by the UE compared to any other indication among the plurality of indications.

[0210] Aspect 21: The method according to any one of aspects 1 to 20, the method further comprising: transmitting an overlapping SLSS using the first indication identifier.

[0211] Aspect 22: The method according to any one of aspects 1 to 21, the method further comprising: triggering an SLSS search in response to a grouping error rate exceeding a threshold.

[0212] Aspect 23: The method according to any one of aspects 1 to 22, the method further comprising: triggering an SLSS search in response to the first indication not including any SLSS identifier associated with a navigation system synchronized UE among the plurality of UEs or with another UE among the plurality of UEs synchronized with the navigation system synchronized UE.

[0213] Aspect 24: The method according to any one of aspects 1 to 23, wherein the first indication further includes a first indication of a first time, and wherein the second indication further includes a second indication of a second time derived from the first time.

[0214] Aspect 25: The method according to aspect 24, wherein the first time is a first UTC time, and wherein the second time is a second UTC time.

[0215] Aspect 26: The method according to any one of aspects 1 to 25, the method further comprising: identifying one or more parameters sent by one or more SLSSs based at least in part on the first indication.

[0216] Aspect 27: The method according to any one of Aspects 1 to 26, wherein the mobile UE identifies a synchronization source from among the plurality of UEs according to the first instruction or the second instruction.

[0217] Aspect 28: The method according to any one of Aspects 1 to 27, wherein the adjacent UE is a first adjacent UE, and wherein receiving the first indication includes receiving the first indication from the first adjacent UE, or sending the second indication includes sending the second indication to a second adjacent UE.

[0218] Aspect 29: The method according to any one of Aspects 1 to 28, wherein receiving the first instruction includes receiving the first instruction from a cloud or network, or sending the second instruction includes sending the second instruction to the cloud or network.

[0219] Aspect 30: An apparatus for wireless communication at a device, the apparatus comprising: a processor; a memory coupled to the processor; and instructions stored in the memory and executable by the processor to cause the apparatus to perform the method according to one or more of aspects 1 to 29.

[0220] Aspect 31: An apparatus for wireless communication, the apparatus comprising a memory and one or more processors coupled to the memory, the one or more processors being configured to perform the method according to one or more of aspects 1 to 29.

[0221] Aspect 32: An apparatus for wireless communication, the apparatus comprising at least one component for performing the method according to one or more of aspects 1 to 29.

[0222] Aspect 33: A non-transitory computer-readable medium storing code for wireless communication, the code including instructions executable by a processor to perform the method according to one or more of aspects 1 to 29.

[0223] Aspect 34: A non-transitory computer-readable medium storing a set of instructions for wireless communication, the set of instructions comprising one or more instructions that, when executed by one or more processors of a device, cause the device to perform the method according to one or more of aspects 1 to 29.

[0224] While the foregoing disclosure provides examples and descriptions, it is not intended to be exhaustive or to limit the aspects to the precise form disclosed. Modifications and variations may be made based on the foregoing disclosure, or from various forms of practice.

[0225] As used herein, the term "component" is intended to be broadly interpreted as hardware or a combination of hardware and software. "Software" should be broadly interpreted as instructions, instruction sets, code, code segments, program code, programs, subroutines, software modules, applications, software applications, software packages, routines, subroutines, objects, executable programs, threads of execution, procedures, or functions, whether referred to as software, firmware, middleware, microcode, hardware description languages, or other terms. As used herein, a "processor" is implemented in hardware or a combination of hardware and software. It will be apparent that the systems or methods described herein can be implemented in various forms of hardware or combinations of hardware and software. The actual dedicated control hardware or software code used to implement these systems or methods is not limited in any way. Therefore, the operation and behavior of these systems or methods are described herein without reference to any specific software code, as those skilled in the art will understand that the software and hardware can be designed to implement these systems or methods, at least in part, based on the description herein.

[0226] As used in this article, depending on the context, "meeting the threshold" can mean a value greater than the threshold, greater than or equal to the threshold, less than the threshold, less than or equal to the threshold, equal to the threshold, not equal to the threshold, etc.

[0227] Although specific combinations of features are set forth in the claims or disclosed in the specification, these combinations are not intended to limit the disclosure of various aspects. Many of these features may be combined in ways not specifically stated in the claims or disclosed in the specification. The disclosure of various aspects includes each dependent claim in combination with each other claim in the claim set. As used herein, the phrase “at least one of” in the list of items refers to any combination of these items, including a single member. As an example, “at least one of a, b, or c” is intended to cover: a, b, c, a+b, a+c, b+c, and a+b+c, as well as any combination having multiple identical elements (e.g., a+a, a+a+a, a+a+b, a+a+c, a+b+b, a+c+c, b+b, b+b+b, b+b+c, c+c, and c+c+c, or any other ordering of a, b, and c).

[0228] No element, action, or instruction used herein should be construed as essential or necessary unless explicitly stated otherwise. Furthermore, as used herein, the articles “a” and “an” are intended to include one or more items and are used interchangeably with “one or more.” Similarly, as used herein, the article “described” is intended to include one or more items mentioned in connection with the article “described” and is used interchangeably with “one or more.” Furthermore, as used herein, the terms “group” and “cluster” are intended to include one or more items and are used interchangeably with “one or more.” If only one item is desired, the phrase “only one” or similar terminology will be used. Moreover, as used herein, the terms “having” and similar terms are intended as open-ended terms that do not limit the elements they modify (e.g., “having” A may also have B). Additionally, the phrase “based on” is intended to mean “at least partially based on” unless otherwise explicitly stated. Furthermore, as used herein, the term “or” is intended to be inclusive when used consecutively and is interchangeable with “and / or” unless otherwise explicitly stated (e.g., if used in conjunction with “either of the two” or “only one of them”).

Claims

1. An apparatus for wireless communication at a user equipment (UE), the apparatus comprising: One or more memories, wherein the one or more memories store processor-executable code; and One or more processors, said one or more processors coupled to said one or more memories, at least one of said one or more processors being configured to cause the UE to: Receive a first indication, the first indication including at least a sidelink synchronization signal (SLSS) identifier associated with a neighboring UE of the UE and an indication of the relative position of the neighboring UE among multiple UEs; and Send a second instruction, which includes at least an SLSS identifier associated with the UE and an indication of the relative position of the UE among the plurality of UEs.

2. The apparatus of claim 1, wherein the indication of the relative positioning of the UE includes an identifier of the UE or an indication of the geographical location of the UE.

3. The apparatus of claim 2, wherein the identifier of the UE is a roadside unit (RSU) identifier.

4. The apparatus of claim 1, wherein the indication of the relative positioning of the UE includes a hop identifier associated with the UE, and wherein at least one of the one or more processors for receiving the hop identifier is configured to cause the UE to receive the hop identifier in a Master Information Block (MIB).

5. The apparatus of claim 4, wherein the hop identifier is a first hop identifier, and wherein the first value of the first hop identifier is incremented from the second value of the second hop identifier associated with the adjacent UE.

6. The apparatus of claim 4, wherein the hop identifier is a first hop identifier, and wherein at least one of the one or more processors is configured to cause the UE to: SLSS search is triggered in response to the first value of the first hop identifier being less than or equal to the second value of the second hop identifier of one of the plurality of UEs for a continuous configuration time duration.

7. The apparatus of claim 1, wherein the indication of the relative positioning of the neighboring UE includes an identifier of the neighboring UE, a hop identifier associated with the neighboring UE, or an indication of the geographical location of the neighboring UE.

8. The apparatus of claim 1, wherein the second instruction further comprises one or more of the following: index; An indication of whether the UE is within the coverage area of ​​the navigation system; The transmit synchronization offset associated with the UE; or An indication of a first time derived from a second time associated with the adjacent UE.

9. The apparatus of claim 1, wherein the indication of the relative positioning of the UE comprises one or more of the following: The identifier of the UE; The hop identifier associated with the UE; Indication of the geographical location of the UE; or The synchronization source indication corresponding to the adjacent UE.

10. The apparatus of claim 1, wherein the first indication includes a first list that associates a first index with the SLSS identifier associated with the neighboring UE and with the indication of the relative positioning of the neighboring UE.

11. The apparatus of claim 10, wherein the second indication includes a second list that associates the first index with the SLSS identifier associated with the UE and the indication of the relative positioning of the UE, and wherein the second list also associates the second index with the SLSS identifier associated with the neighboring UE and associated with the indication of the relative positioning of the neighboring UE.

12. The apparatus of claim 11, wherein the plurality of UEs are in SLSS synchronization and transmit once via the Physical Side Link Shared Channel (PSSCH) each time in one or more SLSS cycles, a plurality of lists including the first list and the second list, the plurality of lists including indications of a plurality of synchronization sources.

13. The apparatus of claim 11, wherein at least one processor is configured to cause the UE to: The second list is generated by appending information to the first list.

14. The apparatus of claim 13, wherein the at least one processor configured to cause the UE to generate the second list by appending information to the first list is configured to cause the UE to: Use the first index to append information to the first list.

15. The apparatus of claim 1, wherein at least one of the one or more processors is configured to cause the UE to: The UTC time associated with the UE is derived using the Coordinated Universal Time (UTC) time associated with the adjacent UE carried in the first indication; and The second indication is generated by appending the UTC time associated with the UE to the first indication.

16. The apparatus of claim 1, wherein at least one of the one or more processors is configured to cause the UE to: Decoding includes multiple indications of the first indication; and The indication that the UE has recently decoded more recently than any other indication among the plurality of indications identifies the Coordinated Universal Time (UTC) time.

17. The apparatus of claim 1, wherein at least one of the one or more processors is configured to cause the UE to: Send the overlapping SLSS using the first indication identifier.

18. A method for wireless communication performed at a user equipment (UE), the method comprising: Receive a first indication, the first indication including at least a sidelink synchronization signal (SLSS) identifier associated with a neighboring UE of the UE and an indication of the relative position of the neighboring UE among multiple UEs; and Send a second instruction, which includes at least an SLSS identifier associated with the UE and an indication of the relative position of the UE among the plurality of UEs.

19. The method according to claim 18, further comprising: SLSS search is triggered in response to the grouping error rate exceeding the threshold.

20. The method according to claim 18, further comprising: An SLSS search is triggered in response to the first indication not including any SLSS identifier associated with a navigation system synchronized UE among the plurality of UEs or another UE among the plurality of UEs synchronized with the navigation system synchronized UE.

21. The method of claim 18, wherein the first indication further includes a first indication of a first time, and wherein the second indication further includes a second indication of a second time derived from the first time.

22. The method of claim 21, wherein the first time is a first Coordinated Universal Time (UTC) time, and wherein the second time is a second UTC time.

23. The method according to claim 18, further comprising: The first indication is used to identify one or more parameters sent by one or more SLSSs.

24. The method of claim 18, wherein the mobile UE identifies a synchronization source from among the plurality of UEs according to the first instruction or the second instruction.

25. The method of claim 18, wherein the neighboring UE is a first neighboring UE, and wherein receiving the first indication includes receiving the first indication from the first neighboring UE, or sending the second indication includes sending the second indication to a second neighboring UE.

26. The method of claim 18, wherein receiving the first instruction includes receiving the first instruction from a cloud or network, or sending the second instruction includes sending the second instruction to the cloud or network.

27. The method of claim 18, wherein the first indication includes a first list that associates a first index with the SLSS identifier associated with the neighboring UE and with the indication of the relative positioning of the neighboring UE, wherein the second indication includes a second list that associates the first index with the SLSS identifier associated with the UE and with the indication of the relative positioning of the UE, wherein the second list also associates a second index with the SLSS identifier associated with the neighboring UE and with the indication of the relative positioning of the neighboring UE, and wherein the plurality of UEs are in SLSS synchronization, and a plurality of lists including the first list and the second list are transmitted once via the Physical Side Link Shared Channel (PSSCH) in each or more SLSS cycles, the plurality of lists including indications of a plurality of synchronization sources.

28. The method of claim 18, wherein the first indication includes a first list that associates a first index with the SLSS identifier associated with the neighboring UE and with the indication of relative positioning of the neighboring UE, wherein the second indication includes a second list that associates the first index with the SLSS identifier associated with the UE and with the indication of relative positioning of the UE, wherein the second list also associates a second index with the SLSS identifier associated with the neighboring UE and with the indication of relative positioning of the neighboring UE, the method further comprising: The second list is generated by appending information to the first list.

29. The method of claim 28, wherein the first indication includes a first list that associates a first index with the SLSS identifier associated with the neighboring UE and with the indication of the relative positioning of the neighboring UE, wherein the second indication includes a second list that associates the first index with the SLSS identifier associated with the UE and with the indication of the relative positioning of the UE, wherein the second list also associates a second index with the SLSS identifier associated with the neighboring UE and with the indication of the relative positioning of the neighboring UE, and wherein generating the second list by appending information to the first list includes: The information is appended to the first list using the first index.

30. The method of claim 18, further comprising: The UTC time associated with the UE is derived using the Coordinated Universal Time (UTC) time associated with the adjacent UE carried in the first indication; as well as The second indication is generated by appending the UTC time associated with the UE to the first indication.

31. The method of claim 18, further comprising: Decoding includes multiple indications of the first indication; as well as The indication that the UE has recently decoded more recently than any other indication among the plurality of indications identifies the Coordinated Universal Time (UTC) time.

32. The method according to claim 18, further comprising: Send the overlapping SLSS using the first indication identifier.

Images